WO2010086224A1

WO2010086224A1 - Data transmission and processing for web services

Info

Publication number: WO2010086224A1
Application number: PCT/EP2010/050317
Authority: WO
Inventors: Luigi Lo Iacono; Nils Gruschka
Original assignee: Nec Europe Ltd.
Priority date: 2009-01-29
Filing date: 2010-01-13
Publication date: 2010-08-05

Abstract

A method for a session based transmission of data messages between two Web Service endpoints (1, 2), wherein the method comprises a session initiation phase (a) with the steps: al initiating a session between the two Web Service endpoints by sending from a first endpoint (1) to a second endpoint (2) a first data set in form of a message skeleton (11) which comprises common information for two or more requests which should be sent/exchanged during the session; a2) sending from the first endpoint (1) to the second endpoint (2) a second data set (12) indicating the location of the differences between the two requests; a3) exchanging at least one secret key being used inside of the session for encryption and/or signature. Subsequently a session execution phase (b) is executed with the steps: b1) extracting from each message to be transmitted parts of the data addressed by the location defined during step a2); b2) serialising the extracted parts; b3) bundling the serialised different into a diff-message; and sending at least one diff-message (13) from the first endpoint (1) to the second endpoint (2).

Description

Data Transmission and Processing for Web Services

The present invention relates to a system and method for data transmission and processing. In particular, the present invention relates to a session-based SOAP transmission and processing, e.g., for high-volume services or transmission and processing between devices with limited computing resources. According to the present invention a preferably secure connection between two communication endpoints, e.g., a client and a service (e.g. a Web Service), is preferably provided by a method which reduces the amount of data to be transmitted and the processing costs are reduced such that an efficient transmission and processing is provided. BACKGROUND

A Web Service is traditionally defined by the W3C as a system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically Web Services Description Language, WSDL). Other systems interact with the Web Service in a manner prescribed by its description using SOAP messages, typically conveyed using HTfP with an XML serialization in conjunction with other web-related standards.

The concepts of Service-Oriented Architectures [10] and its most common realization - the SOAP-based Web Services [2] have become very popular and widespread used in the last years. Some applications like SaaS [23, 27] or Cloud Computing [6] (e.g. the most prominent Amazon's Elastic Compute Cloud (EC2) [3]) are unimaginable without Web Services. There are a number of reasons for this high popularity. Web Services allow creating interoperable services with loosely- coupled interaction and rapid service integration. Additionally, the large amount of more and more mature specifications, the strong industry support and the large number of Web Service frameworks for nearly all programming language have boosted acceptance and usage.

While the use of an XML-based protocol has a lot of advantages like message extensibility, human readability and utilization of standard XML processing components, SOAP also inherits all of XML's issues. The main problems - used by critics since the start of Web Services - are verbosity' of transmitted messages and high resource requirements for processing [11]. These issues are further increased when using SOAP security. For securing SOAP messages a lot of specifications have been created, e.g. WS-Security for integrity' and confidentiality or SAML for expressing and exchanging security assertions. The use of this SOAP security⁷ means typically imposes a high overhead [18]. First, they lead to a blow up of the message size. Additionally, the effort for processing is raised, e.g. through the need of handling larger messages and performing cryptographic operations.

These problems are especially severe for example for mobile devices with limited computing resources and low bandwidth network connection [14] or for high-volume Web Sendee transactions.

The inventors of the present invention noted that if such high- volume service invocations are performed between two communication endpoints, the exchanged messages mostly show a veiy high similarity. The main reasons for this behaviour are due the following: First of all - regarding message formatting - messages created by the same Web Service framework have a high similarity concerning namespace declaration, line-breaking etc. Secondly - regarding the message content - most non-functional parameters like cryptographic algorithms or keys are not changed frequently.

An example for such a high-volume transaction system is a service for validating credit card numbers offered by a credit card company and used by an online store. Comparing two typical messages in this scenario, only small differences can be observed. These are mainly the (eventually encrypted) credit card number and some security related elements like timestamp or signature value. This leads to a high overhead regarding the message size during transport but also for creating the message at the client side and processing the message at the server side.

There exist several solutions for reducing SOAP overhead regarding message size or processing performance. Depending on the scenario either one the aims is more important. Ln [26] solutions for mobile device are observed. The authors suggest compression for reducing the XML payload. While this is important for devices in low bandwidth networks, the performance of SOAP processing can not be reduced. In [19] a binary transport encoding for SOAP is proposed. This leads to slightly smaller messages and reduced parsing effort, but discussions on integrating SOAP security means to this approach are missing.

Additionally, both approaches do not take similarity between subsequent messages as optimization possibility into account.

This similarity property is used in [1] to increase processing performance at the service side. However, the difference between messages are identified for each invocation and security integration remains open. A similarity approach specific for SOAP security is presented in [20], yet they use fixed templates and the differences can not be dynamically negotiated.

All solution presented above still transmit the whole SOAP message. The inventors of the present invention noted that this gives potential for reducing message size and also processing effort away. The approach presented in [9] tries to close this gap. Based on SOAP multicast techniques [24] their system aggregates a number of SOAP messages at the Web Service client side, taking advantages of the message similarity. While this greatly reduces message size and processing (esp. security processing) effort, this solution can increase the response latency as the client has to wait until enough request messages have been collected to an outgoing aggregated messages. Additionally, common message parts are sent more then once.

In particular, regarding a sequence of Web Service invocations between two fixed communication endpoints, one can observe that the exchanged messages mostly show a vciy high similarity. As an example, the similarity of two digitally signed invocation of the same service with distinct parameters is up to 85% (see also the evaluation results given below). The main reasons for this behaviour are due the following: First of all — regarding the message content - in the functional part of the message only parameters of one particular operation are changed and most nonfunctional parameters like cryptographic algorithms or keys are not changed frequently. Secondly - regarding message formatting - messages created by the same Web Service framework have a high similarity concerning namespace declaration, line-breaking etc.

It is an object of the present invention to overcome the shortcomings of the prior art. In particular, it is an object to provide a system and a method for data transmission, in particular secure data transmission, with a reduced amount of data to be transferred.

These objects are achieved by the features of the accompanying claims and the embodiments as discussed below.

SUMMARY OF THE INVENTION

SOAP-based Web Services enable flexible software system integration especially in heterogeneous environments and is a driving technology for inter-organization business processes. Yet, the verbosity of the XML-based protocol and its accompanying standards posses performance challenges which need to be addressed and solved to obtain the efficiency and scalability required by large information systems. The present invention proposes a novel approach to overcome these performance issues in scenarios where multiple service invocations occur between a requester and a service. In particular, a protocol is introduced which allows negotiating common and distinctive parts of the SOAP message. Thereby, a session is established between these two endpoints in which preferably only distinctive parts of the SOAP message are subsequently transferred over the wire. This results in a significant efficiency improvement regarding transmission as well as processing costs.

Efficiency applies here to message size as well as message processing costs. Additionally, the solution according to the present invention preferably considers SOAP security, conserves message transparency, respects existing Web Service specifications and/or allows sticking to the programming model of contemporary Web Service frameworks.

In particular, the present invention provides a solution for reducing transmission size (data) and increases processing performance, in particular for scenarios of data transmission with similar messages. In particular, the present invention proposes a solution for reducing transmission size and increasing processing performance for such scenarios of high- volume Web Services (which include a high similarity between the exchanged messages). The solution of the present invention is preferably based on creating an invocation context for negotiation of message differences, a session protocol for transmission of message differences and a Web Sen-ice framework architecture for efficient message processing.

In particular, according to the present invention a method is provided which reduces the amount of data (size of data) to be transmitted from one endpoint to the other such that an efficient transmission, in particular, for high-volume Web Sendees or transmission between devices with limited computing resources is efficiently provided. According to the present invention the messages to be exchanged between the client and a service, in particular, a Web Service is preferably provided by a method which reduces the processing costs to create and serialize as well as de-serialize the message by maintaining message fragments within the scope of a session. According to the present invention the messages to be exchanged between the client and a service, in particular, a Web Service can be secured between the two endpoints without the loss of the efficient transmission and processing.

The present invention may be characterized by the following preferred aspects:

1. A method for data transmission and/or processing between two communication endpoints by using a transport protocol, wherein the method comprises steps of a) session initiation and b) session execution.

2. The method according to aspect 1, wherein the step of a) session initiation comprises steps of: al) initiating the session by sending a message skeleton comprising common information for requests exchanged during the session; preferably a2) providing a second set of information indicating the location of the differences between the two communication endpoints where such information is preferably gathered automatically from analysing the messages exchanged between the endpoints: and preferably a3) exchanging a secret key being used inside of the session for encryption or signature.

3. The method according to aspect 2, wherein the two endpoints communicate by using a difference transport part of the SSTP protocol once the session has been established.

4. The method according to aspect 3, wherein the step of b) session execution comprises steps of: bl) extracting parts of the data addressed by the location defined during the step a); b2) serialising the extracted parts; and b3) bundling the serialised parts by a root element to one differences message (diff-message for short).

5. The method according to aspect 4, wherein the root element of the diff- message relates to diff-element and contains the extracted parts embedded as part-elements. 6. The method according to any one of preceding aspects, wherein the transmission and/processing of data is Web Sen-ice compliant.

7. The method according to any one of preceding aspects, wherein the data to be transmitted is a SOAP-Message.

8. The method according to any one of preceding aspects, wherein the method allows efficient transport of similar SOAP messages between two communication endpoints.

9. The method according to an}' one of preceding aspects, wherein one of the two communication endpoints is a client and the other one a Web Service.

10. The method according to any of the preceding aspects, wherein the method is applied to the request and/or to the response message of a Web Sendee. 1 1. The method according to any of the preceding aspects, wherein the Web

Services client and the services communicate during the session execution by using the difference transport part of the SSTP protocol.

12. System for providing a method for reducing data transmission size between two Web Service endpoints, in particular, between a client and a Web Service, when a system is adapted to perform the method steps according to any of the preceding method aspects.

13. A computer program product directly loadable into the internal memory of a digital computer, comprising software code portions for performing the steps of any of aspects 1 to 12 wherein the product is run on a computer.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now⁷ be described in detail with respect to preferred embodiments with reference to the accompanying drawings, wherein Figure 1 shows a basic concept of a Session-based SOAP Transmission Protocol

(SSTP) according to a preferred embodiment according to the present invention:

Figure 2 shows a SOΛP message skeleton for session initiation according to the present invention;

Figure 3 shows an embodiment of a processing chain for a SSTP inside client; and

Figure 4 shows a processing chain for SSTP inside service according to a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE PRESENT INVENTION AND PREFERRED

EMBODIMENTS

In the following Web Service Security (WS-Security), as preferably used according to the present invention will be discussed.

In contrast to most ''classic^"" communication protocols, Web Services do not rely on transport oriented security means (like SSL) but on message oriented security. A preferred specification addressing security needs of Web Services is WS-Security [22]. It collaborates with the SOAP specifications, providing integrity', confidentiality and authentication for Web Services. WS- Security⁷ defines a SOAP header block (Security) that carries the WS-Security extensions. Additionally, it defines how existing XML security standards like XML Signature [4] and XML Encryption [13] are applied to SOAP messages.

XML Signature allows XML fragments to be digitally signed to ensure integrity or to proof authenticity. The XML Signature element has the following (slightly simplified) structure:

< /SignedInf o>

<SignacureValue> . . . </SignatureValue> </Signature> The signing process preferabl> works as follows: For ever} message part to be signed a Reference element is created and this message part is canonicalized and hashed. The resulting digest is added into the DigeεtValue element, a reference to the signed message pat is entered into the URJ attribute. Finally the Signedlnf o element is canonicalized and signed. The result of the signing operation is placed in the SignatureValue element and the Signature element is added to the security header.

XML Encryption allows XML fragments to bε encrypted to ensure data confidentiality. The encrypted fragment is replaced by an ΞncrypnedData element containing the ciphertext of the encrypted fragment as content.

Further, XML Encryption defines an Encrypt edKey element for key transportation purposes. The most common application for an encrypted key is a hybrid enciyption: an XML fragment is encrypted with a randomly generated symmetric key. which itself is encrypted using the public key of the message recipient. In SOAP messages, the EncryptedKey element - if present - typically appear inside the security header.

In addition to encryption and signatures, WS- Security defines security tokens suitable for transportation of digital identities, e.g. X.509 certificates. WS-SecurityPoIicy

An important characteristic of the mechanisms used in WS-Security is their high flexibility. They are applicable to arbitrary parts of the SOAP message, leaving all other parts unattended. As a consequence. Web Service servers and clients preferably negotiate a security' policy defining the WS-Security elements to be used.

WS-SecurityPolicy [17] provides an XML syntax for declaring such security policies. In extension to the Web Service description (WSDL [7]), a server may use a WS-SecurityPolicy document for declaring its security needs. W^TS-SecurityPolicy allows to specify the parts of a SOAP message that shall be encrypted or signed, the algorithms to use and the required security tokens. WS-SecureConversation may be based on the OASIS standard ([16]). In particular. WS- SecureConversation defines, on top of the basic mechanisms provided by WS-Security', secure messaging semantics for multiple message exchanges. It introduces a security context and specifies extensions for security context establishment and sharing, alongside session key derivation. This enables sessions to be established and potentially more efficient keys or new key material to be exchanged, thereby increasing the overall performance and security- of the subsequent exchanges. A security' context is established using a Security Context Token (SCT), which provides the session keys. The SCT can be retrieved using WS-Trust, perhaps by mutually agreeing on an SCT using a challenge-and-response protocol. A preferred embodiment according to the present invention will be called "Session-based SOAP Transmission Protocol" (SSTP) in the following. The SSTP allows efficient transport of similar SOAI³ messages between two Web Service endpoints. Figure 1 shows the scheme of the SSTP with the two protocol phases: the session initiation and the session execution. The SSTP can be applied to the request as well as the response message for a Web Sendee. For the sake of readability, only the request direction will be discussed in the following embodiment. The response direction works analogical. Session Initiation According to a preferred embodiment, WS-SecureConversation [16] is used to establish a security context and to start a Web Service session between two Web Service endpoints. The protocol according to the present invention was extended to the session initiation portion of the SSTP. In addition to exchanging security credentials, it allows negotiation of parameters for efficient transport of the SOAP message, starting a SSTP session. The session initiation works as follows. The client sends a message skeleton containing those parts of the SOAP message that are common for all requests exchanged during the session. Figure 2 shows this message skeleton for the example of the credit card validation service. The bold printed elements are those that differ amongst two service invocation and therefore are empty in the skeleton (see also Fig. 1 ).

The second set of data exchanged during session initiation are the locations of the differences between two SOAP messages. This is specified for example by XPath [8] expression. One can distinguish between functional differences which originate from the application payload data and are located inside the SOAP body and non-functional differences which are originated from the so- called non-functional data (e.g. routing, security) of the message are (mostly) located inside the SOAP header. For the example according to the present invention, there are two locations (see also figure 2):

/soap : Envelope / & Dctp : Header /wr se : Securi^t y

,'wc c¹ : PecurityCont ext Token fwr c : I dent if i ;-r

/ soap : Envel c pe/ soap : Pody

, nc : checkCredi^~Wcrthmer>s

/nr: :

''xenc : Encrypt edD at a

/ xenc : J iphe z Dat a / xenc ; C iphe r Value

The first location refers to a non-functional difference, the second one to a functional difference.

Both the message skeleton and the difference locations are preferably transported inside a WS-Trust [21] entity, which are used by WS-SecureConversation. For this purpose, the XML schema [25] for ^"W^TS-Trust contains extension points, which allows adding user specific elements. These extension points may be used to define the (SSTP) session initiation according to the present invention which is compliant to the WS-SecureConversation specification. The W⁷S- SecureConversation message for the SSTP session initiation according to the present invention looks preferably like this:

Enveloρe> <3oap : Heaάsr>

^•^/soap : Header-* <.3oaρ : B3dy>

-'wst : RΘqueGt3ecurityToken> <wst : Toks>nType> http: //docs .oasis-open . org/ws-sx

.' ws-securedonversati or. / 200512/ set '/ wst : TukenType> '-WSt : Request Tvpe> ht^~p: / /docs . oasis-open . org/ws-sx

/ws-t rust /200512 /Issue < /wst : RhqiiestTvpe •- < /wst : RequectSecuri tyToken> <sbst: skeleton>

SQAP message skeleton </ sb3r : skelet cn> < sbct, : 1Dcation>

XPath expression for d±ff location <V,:-.bst :xpath>

Finally, the session initiation is used for exchanging a secret key. TMs key (or a series of derived keys) can be used inside the session for asymmetric encryption or for HTvlAC(Hash-based

Message Authentication Code)-based signatures [15]. WS -SecureConversation defines a number of possibilities for exchanging and deriving secret keys. According to the present invention it is preferred that at the end of the session initiation both communication endpoints share symmetric cryptographic secrets and inside the session secret keys can be used for cryptographic operations. in the example of the present invention, the message is only secured regarding confidentiality.

Another, very typical securing scenario is securing the SOAP message with a digital signature for ensuring authentication and integrity. Such a signature usually embraces the SOAP body and a timestamp [5], For such a message the non-functional differences for the SSTP are (It is assumed for this example that the elements Body and Timestamp have IDs attributes with the respective identical value):

/soap: Envelope/ soap : Header/wβse : Security

/wsU: Timesta.mp /soap: Envelope/kcap : Header/wεse : Security

/ds : Signature/ ds : Siqnedlnfo

/ ds ;Reference

/ds tDiges^Value /soap : Envelope /soap : Header/wsse : Security

/ds : Signaτ.tire/ds : Signsdlnfo

/ds : Reference [ @URI-^~\ "Itimestamp/ " ]

/ ds : Digez~Va1ue / soap : Envel zψe/ soap : Header/wsse : Security

/ds ; Signature/as : Signature/value One can see that even for the rather complex XML Signature messages (compares also to the signature template as discussed above) only differ in some (in this case three) simple text nodes. Session Execution

Once the session has been established, the Web Service client and' the service communicate using the difference transport part of the SSTP protocol. The full SOAP message to be transmitted is processed the following way: the parts addressed by the locations defined during session initiation are extracted from the message, serialized into <part> elements and all together bundled by a <diff> element to one DiffMessage. For our example a sample message looks like this:

<sbσt : diffs> <sbst : ρart> uuid: 6B29FC40 </sbst : part> <sbst:part> xdHX21MtmESC6Sqmf9SDrz YnDwL9+4T2jixuc7FeEOo= </sbst : part> </sbst:diffs>

Architecture for Implementing the SSTP Protocol The following presents how the method according to the present invention, in particular the

SSTP protocol can be implemented and how this implementation can be integrated into common Web Service frameworks' processing architecture. The realization leads to efficient SOAP message transport and processing with minimal modification of existing processing flows. Thereby, a widespread DOM-based message flow inside the Web Service framework is assumed. Client Side Figure 3 shows the architecture for the SSTP integration into a Web Service client. The whole process of creating the message (from the client application to the SOAP message) remains untouched. The only requirement or extension for the security component is the support for

WSSecureConversation enabling the use of a secret key. The effect on the security processing is as follows:

• Adding a reference to security context identifier instead of a BinarySecurityToken and possibly an encrypted key to the SOAP header. β Using HMAC instead of asymmetric algorithms (e.g. RSA) for digital signatures.

• Encrypting message parts solely using symmetric algorithms. Apart from this, the only change for realizing the SSl^'P is modifying the XML serializer and adding a component for initializing the SSTP session. For the latter one, the message skeleton and the list of difference locations must be created. The simplest possibility is setting the difference locations manually. Looking at the example in figure 2, one can see that this is a rather easy task for a human. This location list can be applied to a single full SOAP message to gain the message skeleton as DOM-tree (the dashed box) and from this as serialized XML document. Alteroath ely, the difference locations can be gathered by analysing a large number of SOAP messages with XML comparing methods (e.g. [28]).

Once a session has been initiated, the difference location are used for extracting the differences from the current outgoing message. These difference are assebled to a SSTP DiffMessage and sent to the server. Server Side

Integrating SSTP on the Web Service server side (see figure 4 is slightly more complex, but even here the basic processing flow is not changed. The message skeleton document (received during session initiation) is parsed and transformed to a message skeleton DOM-tree. This tree works as a template for creating the actual SOAP message tree. Using the difference location the SSTP aware XML parser creates from the diff message and the skeleton tree the full SOAP message. This SOAP message can be further processed in the Web Service framework (nearly) the same way as without the usage of SSTP. The only difference is - like at the client side - the support of WSSecureConversation for processing the message's security means. Additionally, the policy validation can be optimized using SSlT. WS-SecurityPolicy allows mainly specifying which parts of the SOAP message have to be secured (either by signing or encrypting) and which algorithm and token type to be used. The inventors of the present invention analysed typical scenarios for securing a SOAP message and observed that it is often sufficient to perform policy validation on the message skeleton. As an example reconsider the credit card verification example presented above. A suitable (greatly simplified) security policy for that scenario looks like this:

^;'sp : Se cu rit yOonf ^xt Tokens

-' ' cp : Se curity^{( 1}crjtextTokeri>

_"". s p : AIg o r i t hπi3ui t =; >

>

<r~,p : B<f si cl l ό Λ

< /w3p : E C'li cv ^y "-/ sp : Al q ^ri t hmSuit^ ^*-

^•-■. c p : C o n t e n t E n c r y p t e d E 1 ÷- me n t s > ■-" si' : XFath>

/ soap : Envelope cz ap : Body

/rir : chβ chC reditKorthine s s / n s : c r e di r C a r dN urπb e r <- ^/ sp : ΣPath-> </ sp : Cent ent En crypt edEl eir.^n^~ s >

TMs exemplary policy claims that the content of the element creditCardNumber has to be encrypted using a seciirit}' context token and the algorithm AES-128 (AES-128 is defined as symmetric algorithm for the algorithm suite Basicl 28). Regarding the message skeleton in figure 2, one can see that the security policy is true for all messages constructed from this skeleton. Thus, as WS-SecurityPolicy checking is a complex task (see e.g. [12]) it is a good idea to perform this check only once per session.

Based on these considerations, the policy validation for a SSTP enabled sendee work as follows. During the session initiation, the message skeleton is checked for conformance to the security policy. If the policy can not be fulfilled by a message based on the skeleton the session initiation is stopped. If the policy is fulfilled for all messages based on the skeleton the policy checking inside the session can be skipped. Of course, this provisional policy validation works only under the assumption that certain security constraints are true, e.g. the signature value is correct. However, these conditions are checked by the security processing component. In the third case, where the policy compliance can not be decided beforehand the (normal) policy during session execution is performed.

Evaluation of SSTP Performance In the following the influence of the SSTP protocol on resource consumption (mainly network bandwidth and server processing load) are discussed and results from practical evaluation are presented. As this is usually more relevant, we focus here on the service side. From the design of the protocol and its realisation the following benefits from using the SSTP are expected:

• reduced message transmission size from:

- using security context tokens

- difference approach

• reduced processing time from:

- skeleton-based policy validation

- using symmetric ΗMAC algorithms

- efficient parsing

Of course, these benefits concern only the session execution part. Howe\er, as a SSTP session is created for a large number of inner-session invocations, the effort for the session initiation can be neglected.

To prove the benefits listed above, the SSTP was evaluated based on a prototype implementation. The evaluation was done using the credit card validation service in two different (very common) security scenarios. In the first scenario, the credit card number is encrypted (like in the examples above); in the second scenario, the message body is signed. In each scenario, sample messages were send and processed using three different processing systems. The first system was a standard SOAP framework (here: Apache Axis), the second system also uses standard SOAP message and additionally WS-SecureConversation for creating a security context, and finally the third system was based on the SSTP prototype. The measured variables are: SOAP request message size on the wire, message parsing time and security processing time (for WS-SecureConversation and SSTP for inner-session communications)..

The above table shows the results of the evaluation. It can be seen, that - for both security scenarios - SSTP drastically decreased message size and parsing time compared to standard SOAP message usage as well as WS-SecureConversation (WS-SC). The message size is reduced by up to 94%, the parsing time by up to 87%. Additionally, for the security processing (which is in SSTP the same operation as in WS-SecureConversation) the processing time can be greatly reduced by up to 80% through avoiding asymmetric cryptographic operations.

In conclusion, high performance SOAP transmission and processing is still an open research topic and an important issue for many practical applications. As a contribution to this topic, the present invention provides a session-based SOAP transmission protocol which takes advantage of the high similarity of subsequently exchanged message between two endpoints. It allows a priori negotiation of common parts of the message as well as cryptographic keys and transmits only distinctive message parts inside the session. It was also presented how to integrate the SSTP into common Web Service framework architectures to decrease message processing costs while keeping the message processing flow. Finally, the evaluation of the implementation shows that SSTP can greatly reduce message size as well as parsing and security processing time.

References [l] N. Abu-Ghazaleh and M. J. Lewis. Differential Deserialization for Optimized SOAP Performance, hi SC '05: Proceedings oft he 2005 ACWlEEE conference on Super computing, page 21. Washington, DC, USA, 2005. IEEE Computer Society. [2] G. Alonso, F. Casati. H. Konu, and V. Machiraju. Web Services. Springer, 2004. [3] Amazon Elastic Compute Cloud (EC2). htlp://aws. arnayon.com/ec2. [4] M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon. XML-Signature Syntax and

Processing. W3C Recommendation, 2002.

[5] K. Bhargavan, C. Fournet, A. D. Gordon, and G. O^'Shea. An Advisor for Web Services Security Policies. In SWS '05: Proceedings of the 2005 workshop on Secure Web Services, pages 1-9. New York, NY, USA, 2005. ACM Press. [6] R. Buyya, C. S. Yeo, and S. Venugopal. Market-Oriented Cloud Computing: Vision, Hype, and Reality for Delivering IT Services as Computing Utilities. High Performance Computing and Communications, 10th IEEE International Conference on, 0:5-13, 2008.

[7] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web Services Description Language (WSDL) 1.1. W3C Note, 2001.

[8] J. Clark and S. DeRose. XML Path Language (XPath) Version 1.0. W3C Recommendation,

1999. [9] E. Damiani and S. Marrara. Efficient SOAP message exchange and evaluation through XML similarity. In SWS '08: Proceedings of the 2008 ACM workshop on Secure web services, pages 29-36, New York. NY, USA. 2008. ACM. [10] T. ErI. Service-Oriented Architecture - Concepts, Technology, and Design. Prentice

Hall, 2005. [11] M. Govindaraju, A. Slominski. K. Chiu, P. Liu. R. van Engelen, and M. J. Lewis. Toward

Characterizing the Performance of SOAP Toolkits. In GRID '04: Proceedings of the

Fifth IEEE/ACM International Workshop on Grid Computing (GRID '04 J, pages 365-

372, Washington, DC. USA, 2004. IEEE Computer Society.

[12] N. Gruschka, R. Herkenhδner, and N. Luttenberger. WS-SecurityPolicy Decision and Enforcement for Web Service Firewalls. In Proceedings of the IEEE/IST Workshop on

Monitoring, Attack Detection and Mitigation, page 19-25, 2006. [13] T. Imamura, B. Dillaway, and E. Simon. XML Encryption Syntax and Processing. WBC

Recommendation, 2002.

[14] J. Kangasharju. Efficient Implementation of XML Security for Mobile Devices. In Proceedings ofthe 2007 IEEE International Conference on Web Services (ICWS 2007), pages 134-141, 2007. [15] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: KeyedHashing for Message

Authentication. IETF request/or comments, RFC 2104, 1997.

[16] K. Lawrence and C. Kaler. Web Services Secure Conversation Language (WS- SecureConversation) 1.3. OASIS Standard, 2007.

[17] K. Lawrence and C. Kaler. Web Sendees Security Policy Language (WS-SecurityPolicy)

IA. Oasis Standard, 2007. [18] H. Liu, S. Pallickara. and G. Fox. Performance of Web Services Security. In Proceedings ofthe 13th Annual Mardi Gr as Conference, February 2005. [19] W. Lu, K. Chiu, and D. Gannon. Building a Generic SOAP Framework over Binary

XML. In The 15th IEEE International Symposium on High Performance Distributed

Computing (HPDC-15), 2006. [20] S. Makino, M. Tatsubori, K. Tamura, and Y. Nakamura. Improving WS-Security

Performance with a Template-Based Approach. In Proceedings of the International Conference on Web Services (ICWS 2005), pages 58 1-588. 2005.

[21 ] A. Nadalin, M. Goodner. M. Gudgin. A. Barbir, and

H. Granqvist. WS-Trust 1.3. OASIS Standard, 2007. [22] A. Nadalin. C. Kaler. R. Monzillo, and P. Hallam-Baker. Web Services Security: SOAP Message Security 1.1 (WS-Security 2004). 2006. [23] M. P. Papazoglou. Service -Oriented Computing: Concepts, Characteristics and Directions.

Web Information Systems Engineering, International Conference on, 0:3. 2003. [24] K. A. Phan, Z. Tari, and P. Bertok. Optimizing Web Services Performance by Using Similarity-Based Multicast Protocol. European Conference on Web Services, 0:119-128,

2006. [25] H. S. Thompson. D. Beech, M. Maloney, and N. Mendelsohn. XML Schema Part 1:

Structures Second Edition. W3C Recommendation, 2004.

[26] M. Tian, T. Voigt, T. Naumowicz, H. Ritter, and J. Schiller. Performance Considerations for Mobile Web Services. Computer Communications, 27(11): 1097-1105, 2004.

[27] M. Turner, D. Budgen, and P. Brereton. Turning Software into a Service. Computer,

36(10):38-44, 2003. [28] Y. Wang, D. J. De Witt, and J.-Y. CaL X-Diff: An Effective Change Detection Algorithm for

XML Documents. Data Engineering. International Conference on, 0:519. 2003.

Claims

1. A method for a session based transmission and processing of data messages between two Web Service endpoints (1, 2). wherein the method comprises a session initiation phase (a) with the steps of: al) initiating a session between the two Web Service endpoints (1, 2) by sending from a first endpoint (1) to a second endpoint (2) a first data set in form of a message skeleton (11) which comprises common information for two or more requests which should be sent/exchanged during the session: a2) sending from the first endpoint (1) to the second endpoint (2) a second data set (12) indicating the location of the differences between the two requests; a3) exchanging at least one secret key being used during the session for encryption and/or signature: and subsequently a session execution phase (b) with the steps of: bl) extracting from each message to be transmitted parts of the data addressed by the location defined during step a2); b2) serialising the extracted parts; b3) bundling the serialised different into a diff-message; and sending at least one diff-message (13) from the first endpoint (1 ) to the second endpoint (2).

2. The method according to claim 1, wherein the data message is a SO AP -message.

3. The method according to claim 2, wherein a reference to security context identifier in stead of a BinarySecurityToken and optional an encrypted key is added to a header of the SOAP-message.

4. The method according to claim 2 or 3, wherein an HMAC ke> is used as secret key.

5. The method according to any of the preceding claims, wherein the extracted parts of the data messages are encrypted and/or signed by using the at least one secret key of step a3) before sending.

6. The method according to any of the preceding claims, wherein each diff-message (13) comprises a session ID and encrypted data and/or digital signatures.

7. The method according to any of preceding claims, wherein the method is Web Service compliant, in particular integrated in a common Web Service framework processing architecture.

8. The method according to any of preceding claims, wherein one of the two endpoints (1, 2) is a client (1) and the other is a Web Service (2).

9. The method according to any of the preceding claims, wherein the method is applied to the request and/or to the response message of a Web Service.

10. System for providing a method for reducing data transmission size between two Web Service endpoints (1, 2), in particular, between a client (1) and a Web Service (2), wherein the system is adapted to perform the method steps according to any of the preceding method claims.

11. A computer program product directly loadable into the internal memory of a digital computer, comprising software code portions for performing the steps of any of claims

1 to 9 wherein the product is run on a computer.