WO2005099217A1 - System, apparatus, and method for using reduced web service messages - Google Patents

System, apparatus, and method for using reduced web service messages Download PDF

Info

Publication number
WO2005099217A1
WO2005099217A1 PCT/IB2005/000668 IB2005000668W WO2005099217A1 WO 2005099217 A1 WO2005099217 A1 WO 2005099217A1 IB 2005000668 W IB2005000668 W IB 2005000668W WO 2005099217 A1 WO2005099217 A1 WO 2005099217A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
web service
reduced
redundancy agreement
redundancy
Prior art date
Application number
PCT/IB2005/000668
Other languages
French (fr)
Inventor
Frederick Hirsch
Original Assignee
Nokia Corporation
Nokia, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Corporation, Nokia, Inc. filed Critical Nokia Corporation
Priority to EP05708753A priority Critical patent/EP1741257B1/en
Priority to AT05708753T priority patent/ATE465586T1/en
Priority to DE602005020764T priority patent/DE602005020764D1/en
Publication of WO2005099217A1 publication Critical patent/WO2005099217A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • This invention relates in general to Web services, and more particularly, to communications involving Web service messages.
  • Web services are network-based (particularly Internet-based) applications that perform a specific task and conform to a specific technical format.
  • Web services may be implemented using a stack of emerging standards that describe a service- oriented application architecture, collectively providing a distributed computing paradigm having a particular focus on delivering services across the Internet.
  • Web services are implemented as self-contained modular applications that can be published in a ready-to-use format, located, and invoked across networks. When a Web service is deployed, other applications and Web services can locate and invoke the deployed service. They can perform a variety of functions, ranging from simple requests to complicated business processes.
  • Web services are typically configured to use standard Web protocols such as Hypertext Transfer Protocol (HTTP) and formats such as the Extensible Markup Language (XML) but may use other protocols and formats as well.
  • HTTP Hypertext Transfer Protocol
  • XML Extensible Markup Language
  • Web services are distinguished through the use of SOAP (the first version was an acronym for Simplified Object Access Protocol) and are commonly associated with a Web Services Description Language (WSDL) description.
  • HTTP is an application-level protocol commonly used to transport data on the Web.
  • XML is a mechanism to define markup languages. Some markup languages (e.g., HTML) are used mainly to describe how a document is to be formatted for display. Others are defined to describe application data.
  • SOAP is a markup language for message encapsulation and is typically used to transmit messages that invoke remote procedure calls, return the results from such invocation, or transmit documents. [0006] The availability of Web services makes the Web an even more powerful communications medium. Web services enable a service-oriented architecture to be created using existing Web technologies.
  • Any Web-services-aware program can invoke other services, enabling applications to be dynamically composed from reusable components.
  • Web services can be a part of a program carrying out any kind of computation, yet can be accessed and run anywhere due to the ubiquity of the Internet and its associated protocols.
  • the Web service standards can be adapted handle almost any type of data, due to the use of extensible languages such as XML.
  • SOAP come at a cost, however.
  • the text based, tagged format of XML is quite verbose.
  • Such XML text representations are preferred for Web services because they enable interoperability and are easy to read and debug.
  • text representations are not the most efficient form in which to transmit data, and therefore require more bandwidth to transmit than is theoretically necessary.
  • the tags and other required fields in XML increase the data overhead when using these types of Web services, especially on small, simple transactions.
  • a method involves invoking a Web service of a network entity.
  • a redundancy agreement message is sent to the network entity.
  • the redundancy agreement message describes a redundancy agreement for invoking the Web service using reduced messages.
  • a reduced message is formed based on the redundancy agreement and a non-redundant portion of a Web service message configured for invoking the Web service.
  • the reduced message is sent to the network entity and the Web service is invoked at the network entity based on the reduced message and the redundancy agreement.
  • any of the Web service message, reduced message, and the redundancy agreement message may include a SOAP message.
  • the redundancy agreement message may include a binary formatted message.
  • the redundancy agreement may include mapping of identifiers to content strings.
  • the content strings are based on a non-redundant portion of the Web service message.
  • the content strings may be base64 encoded.
  • the method may involve sending a redundancy agreement reply message from the network entity in response to the redundancy agreement message.
  • the redundancy agreement reply message may include a suggested modification to the redundancy agreement.
  • the redundancy agreement message may be included in a non-reduced Web service message, such as in a message header of the non-reduced Web service message.
  • Invoking the Web service at the network entity based on the reduced message and the redundancy agreement may involve creating a template based on the redundancy agreement and forming a replicated Web service message from the template by replacing portions of the template with selected portions of the reduced message.
  • the selected portions of the reduced message and the portions of the template may include any combination of LISP encoded values, base64 encoded values, and XML elements.
  • the reduced message may include one or more XML processing instructions indicating the portions of the template to be replaced and the selected portions of the reduced message.
  • the one or more XML processing instructions may be base64 encoded.
  • the reduced message may also use XML tags as replacement indicators, placing encoded processing instructions or LISP encodings within these XML elements.
  • the method involves determining a quality measurement based on sizes of the reduced message and the Web service message. The quality measurement may be used to determine whether to utilize the redundancy agreement and/or used to determine a form of the redundancy agreement.
  • a computing arrangement includes a network interface, a memory capable of storing at least one of a redundancy agreement module and a Web services processing module, and a processor coupled to the memory.
  • the processor is configured by redundancy agreement module to form redundancy agreement messages describing redundancy agreements for invoking Web services using reduced messages.
  • the processor is configured by the Web services module to send the redundancy agreement messages and the reduced messages via the network interface using a Web service protocol for purposes of invoking the Web service.
  • the network interface may include a wireless network interface and the computing arrangement may include a mobile terminal.
  • a messaging system includes means for sending a redundancy agreement message to a network entity.
  • the redundancy agreement message describes a redundancy agreement for invoking the Web service using reduced messages.
  • the system also includes means for forming a reduced message based on the redundancy agreement and a non-redundant portion of a Web service message configured for invoking the Web service, means for sending the reduced message to the network entity, and means for invoking the Web service at the network entity based on the reduced message and the redundancy agreement.
  • the system may also include means for determining a quality measurement based on the sizes of the reduced message and the Web service message.
  • a computer- readable medium has instructions stored which are executable by a computing arrangement for performing steps that include sending a redundancy agreement message to a network entity for purposes of invoking a Web service.
  • the redundancy agreement message describes a redundancy agreement for invoking the Web service using reduced messages.
  • the steps also include forming a reduced message based on the redundancy agreement and a non-redundant portion of a Web service message configured for invoking the Web service, sending the reduced message to the network entity, and invoking the Web service at the network entity based on the reduced message and the redundancy agreement.
  • the redundancy agreement message describes a redundancy agreement for invoking the Web service using reduced messages.
  • the computing arrangement includes means for receiving a reduced message based on the redundancy agreement and a non-redundant portion of a Web service message configured for invoking the Web service, and means for invoking the Web service based on the reduced message and the redundancy agreement.
  • the computing arrangement may also include means for sending a reduced response message to the network entity in response to invocation of the Web service. The reduced response message is based on a second redundancy agreement established between the computing arrangement and the network entity.
  • a computing arrangement is configured to act as a proxy for providing a Web service.
  • the computing arrangement includes means for receiving a redundancy agreement message from a first Web service entity.
  • the redundancy agreement message describes a redundancy agreement for supporting the Web service invocation using reduced messages.
  • the computing arrangement includes means for receiving a reduced message based on the redundancy agreement and a non-redundant portion of a Web service message configured f to support the Web service invocation, means for converting the reduced message to a replica of the Web service message based on the reduced message and the redundancy agreement, and means for sending the replica of the Web service message to a second Web service entity in support of the Web service invocation.
  • the computing arrangement may also include means for receiving a Web service response message from the second Web service entity; and means for sending to the first Web service entity a reduced response message.
  • the reduced response message is based on the Web service response message and a second redundancy agreement established between the computing arrangement and the first Web service entity.
  • FIG. 4 illustrates a system environment in which a Web service messaging according to embodiments of the present invention may be employed;
  • FIG. 5 illustrates an arrangement for providing Web service messaging with redundancy agreements between network entities according to embodiments of the present invention;
  • FIG.6 illustrates another arrangement for providing Web service messaging with redundancy agreements between network entities according to embodiments of the present invention; and
  • FIG. 7 illustrates a computing arrangement for processing of reduced messages according to embodiments of the present invention.
  • the present disclosure is directed to a system, apparatus, and method that reduces the size of Web service messages communicated between network entities.
  • the Web service messages can be partitioned into redundant and non- redundant data.
  • the redundant data does not change for all invocations of the same interface between two entities, so may be unnecessary for repeated, similar Web service transactions.
  • the redundant data can be removed from the messages by negotiating a redundancy agreement between two network entities. Once the agreement is accepted by both entities, a reduced message can be formed from the non-redundant data and sent over a communications link.
  • XML and XML-based Web services e.g.,
  • SOAP offer a major advantage of interoperability. This is important in a service-oriented architecture, where new relationships and services are to be dynamically added without requiring extensive re-engineering. This ability to dynamically adapt Web services is extremely valuable from a business perspective and can override technical issues. Thus, when attempting to improve SOAP message performance, it is important to maintain the business benefits of XML. [0030] SOAP messages can be large due to the XML serialization that introduces much redundancy. The verbosity of XML can be useful for readability and extensibility, but is inefficient from the perspective of network usage. Use of SOAP messages can be an issue when network bandwidth is constrained, increasing latency and costs.
  • Communicating parties may also be aware of large redundant strings, such as namespace URLs or other strings and wish to encode these strings with shorter abbreviations.
  • This disclosure describes a dynamic means to manage such definitions.
  • Much redundancy can be found across a series of messages between communicating parties when considering all messages sent over time (not limited to a single message exchange pattern). For example, if a SOAP message is used like a form where most of the message is fixed and only small amounts of information are changed, then much redundancy can be removed by only sending a reduced message with only the changed data.
  • Utilizing reduced messages requires the sender and receiver to agree on the form and what is sent.
  • the agreements on the redundant and non- redundant data may be presumptive, that is, established before any communications have taken place.
  • a presumptive agreement may be difficult to implement, especially when interactions are established dynamically or as forms change over time.
  • the approaches described herein may allow dynamic decisions to be made between parties as to what is redundant data without requiring a presumptive, pre-agreement.
  • Creating a generalized global redundancy system is intractable. A major problem is to establish globally unique identifiers for redundant text while keeping these identifiers small. It will be appreciated that if the identifiers grow large, it will defeat the benefits of redundancy reduction. It is also a challenge to ensure the consistency of this representation among SOAP nodes regardless of communication patterns.
  • FIG. 1 illustrates inter-nodal Web services communications according to embodiments of the present invention.
  • the nodes 102, 104, 106 and 108 may each engage in data communications with each other.
  • the problem with attempting to make global redundancy in such a scenario can be demonstrated with the steps 120, 122, and 124 (illustrated as arcs in FIG.
  • Step 120 Node 102 agrees with node 108 that " ⁇ soap:Envelope>" is represented with “l.”
  • Step 122 Meanwhile node 106 agrees with node 104 that " ⁇ order>” is represented with “l.”
  • One approach to solve the above problem would be to have an administrative protocol running continuously to update all nodes with global information. Such an administrative protocol would introduce overhead, reducing the benefits of redundancy removal. Even if such a protocol could effectively reduce overall redundancy, such an update mechanism would be subject to potential race conditions.
  • Step 124A Node 104 agrees with node 108 that " ⁇ soap:Envelope>" is represented with "2.”
  • This disclosure is related to a protocol that uses pair-wise agreements for redundancy removal in Web service communications. This is useful between parties that have a long-running communication pattern involving many Web service messages, thereby reducing the impact of protocol overhead. Managing redundancy independently between pairs of communicating parties avoids the need for global consistency management, and scales by leveraging support for existing communication patterns.
  • the redundancy protocol can also use a header mechanism to avoid changes to payload for agreement, allowing it to be used with a variety of application defined payloads.
  • the protocol can also make it possible to transfer the payload as well as redundancy agreement protocol information in one message, using such "piggybacking" to reduce the overhead of redundancy control.
  • the protocol mechanism may include the ability to bootstrap, either for a new participant or to recover from errors and to re-establish synchronization.
  • the redundancy removal mechanism is general purpose, allowing different granularities of information to be encoded, including: 1.
  • Strings e.g., whitespace delimited strings found in the body, headers or markup.
  • Tags e.g., ⁇ soap:Envelope>.
  • Arbitrary XML e.g., ⁇ x:Address> ⁇ street>57 Oak St ⁇ /street> ⁇ city>Cambridge ⁇ /city> ⁇ state>MA ⁇ /state> ⁇ countryCode>US ⁇ /countryCode> ⁇ /x:Address> 4.
  • Binary content e.g., a base64 encoded X.509 certificate.
  • XML content with substitutions enabling XML to be treated like a form. [0044] How parties choose the redundancy may be application dependent.
  • the parties may choose the redundancy agreement based on knowledge of message meaning and level of redundancy. For example, the application may detect that this is an XML form. The parties may also choose the redundancy agreement using a predictive scheme based on previous message content. For example, the application may track pattern frequencies to predict redundancy.
  • Components of an exemplary redundancy removal mechanism include: (1) a Redundancy Agreement Protocol (RAP) - protocol used to agree on what redundant information to encode and how to encode it; (2) a Replacement Encoding Indicator (REI) - a procedure for replacing content with message encoding indicator; (3) LISP Encoding for SOAP messaging (LES) - Use of LISP to capture hierarchical XML structure, eliminating need for XML end tags; and (4) Redundancy Reduction Quality Measure (RRQM) - an optional mechanism to dynamically track redundancy reduction quality.
  • RAP Redundancy Agreement Protocol
  • REI Replacement Encoding Indicator
  • LES LISP Encoding for SOAP messaging
  • RRQM Redundancy Reduction Quality Measure
  • Reducing redundancy requires an agreement between communicating parties on how to represent the redundant information so that they can consistently recreate the information in its original form.
  • the potential difficulty is that multiple parties may all communicate with each other in different patterns dynamically establishing different incompatible redundancy mechanisms.
  • An agreement mechanism that does not attempt to achieve global consistency solves this problem in a scalable manner since the agreements only involve parties that already manage information about each other.
  • long-term communications are between small numbers of parties.
  • Each communicating party agrees with a single partner which redundancy mechanism to use with that party - recording this information allows communication between the two parties and does not interfere with communication with others.
  • Redundancy removal may be accomplished by maintaining a synchronized mapping at the two communicating parties, e.g., mapping small integers (e.g., 1, 2,3) with the corresponding redundant content. Rather than sending the content, the identifying number is sent.
  • the table is established and managed using SOAP headers designed to function as a redundancy removal agreement protocol.
  • a message sender decides which text is potentially redundant and chooses to map each section of redundant text to a small unique identifier that it has not already used with the receiver of the message. If the sender already has an identifier for redundant information for that party then it uses that identifier again and there is no need to re-establish the agreement.
  • Redundancy mapping element For each new piece of redundant information the sender generates an XML redundancy mapping element to map the identifier to the redundant information: ⁇ map> ⁇ id>2 ⁇ /id> ⁇ content>abc ⁇ /content> ⁇ /map> [0051] Redundant text may also include "holes", e.g. portions that may be filled in using values matching the mapping template.
  • the ⁇ map> element supports definition of a value marker used in the definition of redundant content.
  • the optional "cnt" attribute specifies the number of replacements to be expected. Note that unique replacement strings could be defined for each replacement. This could be done with repeated occurrences of the "repl" and "content” elements within the map element, or by using additional map elements having a different ID. However, where the replacements are ordered, this is unnecessary and would add overhead. Ordered replacements can be handled by including a single value marker in the "content” element wherever a replacement is needed. When placing the replacement values in the template, the values are provided as a collection, or list. Each value is taken off the list and consecutively inserted in place of each marker. [0053] Although placing redundant XML in the map element may keep the
  • ⁇ content encoding ' b64 ' > Y W Jj ⁇ content>
  • This example shows a specific XML tag (content) and attribute (encoding) to signify base64 encoding, but other tag and attribute names could be used for this purpose.
  • One or more ⁇ map> elements may be contained in a single
  • a receiver processes the header block by examining each ⁇ map> element to determine if that ID has been used and also if that text is already stored for the sender.
  • the following possibilities may exist: 1) The text has no entry and the ID has not been used; The receiver may "accept” this proposal; 2) The text has no entry but the ID has been used; This may occur if this receiver has sent a proposal to the sender and used this ID for different text. The two messages "crossed" during communication. The receiver may propose a different ID. 3) The text has an entry for the same ID. The receiver may "accept” this proposal. The sender must have cleared its table for some reason. 4) The text has an entry for a different ID. The receiver may propose this different ID. Responses are OK (accept) or Map (provide mapping). [0057] The response header block may contain an OK statement for each ⁇ map> element to determine if that ID has been used and also if that text is already stored for the sender.
  • the following possibilities may exist: 1) The text has no entry and the ID
  • the response header block may also contain a map statement for each new ID proposal. For example: ⁇ ok>l ⁇ /ok> ⁇ map> ⁇ id>7 ⁇ /id> ⁇ content>abc ⁇ /content> ⁇ /map> [0058]
  • the protocol exchange continues until all IDs have been agreed upon. This means that if a response has a map statement, or an ID has been ignored that is not agreed, the party must either accept the proposed ID, or suggest a mapping with a different ID that was proposed (or ignored).
  • Another approach is for the sender to assign IDs starting at the low end (e.g. 1) and for the receiver to assign them starting at the high end (e.g.
  • redundancy reduction techniques may be integrated with XML canonicalization processing, thus reducing the overhead of reduction, since that processing is performed anyway. This can be used in conjunction with a minimalist SOAP profile, for example.
  • Redundancy may be reduced by not sending the redundant information and either 1) knowing what it is out of band or 2) sending an identifier to indicate the information that should be restored at which spot.
  • REI replacement encoding indicator
  • XML processing instructions can be used as REIs.
  • a replacement encoding indicator may be implemented using XML processing instructions, a LISP serialization, or an XML replacement encoding.
  • XML processing instructions have the advantage that they are a well-defined XML construct and are not a legal SOAP messaging construct (but neither is LISP encoding). Use of disallowed characters for REI is not workable, not to mention dangerous, as is the use of entity references. Additional XML markup may be used for REI, but this would defeat the purpose of redundancy removal. XML processing instructions are short and well suited to the purpose. [0063] Given that XML processing instructions are disallowed by the
  • Each value is preferably base64 encoded to ensure that all spacing is preserved and then placed within parentheses, creating a list of values within the processing instruction following the redundancy agreement template value, (e.g., ⁇ ?6 (value 1) (value2)?>).
  • a LISP encoding of XML data can provide significant message size reduction by removing redundancy inherent in the XML end tags.
  • LISP serialization replaces start and end tags with a list structure of the following form: (tag-name ((argument 1 value 1) (argument2 value2)%) element-content )
  • tag-name ((argument 1 value 1) (argument2 value2)
  • the LISP serialization may involve variations on how the arguments are quoted in the LISP representation, or whether they are included in a sub- list. Note that this applies regardless of the XML quoting used, either single or double quotes.
  • An XML replacement encoding is necessary when the receiver needs to be able to use a standard XML and SOAP parser to process the message.
  • portions of the XML may be replaced with redundancy encoding indicators, but the use of XML processing instructions or pure LISP encoding may cause the standard SOAP processing to fail.
  • the redundancy encoding indicator may be an XML tag in a unique XML namespace, containing a base64 encoded processing instruction or LISP encoding of the redundancy information.
  • the value of the "r:r” element is a base64 encoded processing instruction ⁇ ?1?> that represents the replaced address XML text.
  • the type parameter indicates that the format of the base64-encoded content (processing instruction or LISP form) is the processing instruction form.
  • a default attribute value may allow this XML attribute to be omitted.
  • the "r" prefix is arbitrary and that the meaning is indicated by the XML namespace. This tag and prefix could be different in an implementation without changing this application.
  • Systems utilizing reduced messages may require a quality measure that describes the data reduction resulting from RAP mechanisms. The quality of redundancy reduction can be measured and updated with each SOAP message received.
  • TotalXfer the total SOAP message bytes received
  • TotalApp the total SOAP application bytes received
  • the TotalXfer value includes the size of reduced data messages as well as the size of RAP messages exchanged.
  • the TotalApp value includes the total XML encoded data message bytes received; redundant content and XML serialization is restored before measuring. These totals can be used to calculate the current average redundancy removal percentage over the lifetime of measurement: (TotalApp - TotalXfer)/TotalApp.
  • an example SOAP message exchange 200 is shown that utilizes redundancy mechanisms according to embodiments of the present invention.
  • the message exchanges in FIG. 2 relate to a hypothetical airline reservations request between a requestor 202 and a reservation service 204. Without any redundancy mechanisms, the typical exchange of this sort would involve standard SOAP messages for a reservation request 210, a clarification request 216, and a clarification response 222.
  • Using the redundancy agreement may involve exchanging additional RAP messages so that the core messages 210, 216, 222 can be exchanged in a reduced format.
  • the additional RAP messages include redundancy agreements 206,
  • redundancy agreements 206, 212, and 218 associated with each SOAP message 210, 216, and 222, respectively.
  • the receiver of a redundancy agreement will respond with an acceptance or rejection, as indicated by the acceptance messages 208, 214, and 220 associated with the redundancy agreements 206, 212, and 218. It will be appreciated that if the result of a redundancy agreement were a rejection or error then the exchange would continue using standard, unreduced, SOAP messages. [0073] It will also be appreciated that the redundancy agreements 206, 212, and 218 and responses 208, 214 and 220 only need to be used the first time this type of exchange occurs between the requestor 202 and the service 204.
  • Listings 1-6 Some example messages for the exchanges of FIG. 2 are shown below in Listings 1-6.
  • the examples of Listings 1-6 illustrate messages 206, 208, and 210 of FIG. 2.
  • Listing 1 shows a SOAP reservation request 210 formed according to the SOAP standard (with lines reformatted for readability):
  • Listing 2 illustrates a redundancy agreement message for the SOAP message of Listing 1.
  • the base64 block in Listing 2 contains the substitution template that includes the "V parameters that mark locations for insertion of the non- redundant data.
  • the use of base64 encoding ensures the SOAP message of Listing 2 is well formed.
  • Listing 3 shows the decoded representation of the base64 encoded block of Listing 2.
  • ⁇ env: Envelope xmlns : env "http: //www. 3. org/2003/2017soap-envelope">
  • ⁇ r:rap xmlns : r http: //www. nokia .
  • Listing 4 illustrates the response message 208 of FIG. 2 that indicates the redundancy agreement of Listing 2 has been accepted.
  • a flowchart 300 of FIG. 3 illustrates an example procedure of performing Web service communications using redundancy agreements according to embodiments of the present invention.
  • the procedure begins with a first network entity forming a Web service message (304), e.g., a SOAP message.
  • the Web service message does not necessarily need to be formed as a fully formatted XML message, but generally the information needed to form the message (e.g., an XML InfoSet, information for a remote method invocation, a document and related message information, etc.) is in place such that a standard SOAP message could be formed.
  • a redundancy agreement is then formed (306) based on at least the non-redundant parts of the Web service message.
  • the redundancy agreement is sent (308) across a network or other communication means and targeted for a second data processing entity.
  • the second network entity may be the destination of the SOAP message, or may be some intermediate entity.
  • the first network entity receives a reply in response to the redundancy agreement, and checks (310) the result of the reply. If the result is a SOAP fault or other rejection of the redundancy agreement, the Web service message is sent (312) in its original format to the destination, where it is processed (314). However, if the check (310) results in an acceptance of the redundancy agreement (or negotiations ensue (321) that result in a mutually acceptable agreement), a reduced message is formed (316) by the first network entity and sent (318) to the destination where it is processed (320).
  • the processing (320) of the message may occur by converting the reduced message to a fully formed SOAP message which is then forwarded on to a SOAP processing module, or by processing only the data contained in the reduced message.
  • the module that reduces the message acts as a "front-end" to a standard SOAP processing stack.
  • the reduced messaging functionality may be included in the SOAP processing stack, such that there is no need to convert the reduced message to a fully formed SOAP message.
  • the network clients, servers and other data processing elements for providing Web service messaging systems in connection with the present invention may be any type of computing device capable of processing and communicating digital information. Referring now to FIG.
  • a representative system environment 400 is illustrated in which Web services may be employed according to embodiments of the present invention.
  • Web services may be communicated using a reduced Web service message 402 and a redundancy agreement 403, which may take the form of a Web service message.
  • the Web service messages 402, 403 may be communicated between target devices in any number of known manners. These manners include via a landline network(s) 404, which may include a Global Area Network (GAN) such as the Internet, one or more Wide Area Networks (WAN), Local Area Networks (LAN), and the like.
  • GAN Global Area Network
  • WAN Wide Area Networks
  • LAN Local Area Networks
  • Any computing device or other electronic device that supports Web services may be the target system that utilizes the present invention, such as servers 406, desktop computers 408 or workstations, laptop or other portable computers 410, or any other similar computing device capable of communicating via the network 404, as represented by generic device 412.
  • the Web service messages 402, 403 may be communicated via one or more wireless networks 414, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Personal Communications Service (PCS), Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), or other mobile network transmission technology.
  • GSM Global System for Mobile Communications
  • UMTS Universal Mobile Telecommunications System
  • PCS Personal Communications Service
  • TDMA Time Division Multiple Access
  • CDMA Code Division Multiple Access
  • any mobile electronic device can communicate with Web service message 402, 403, such as laptop or other portable computers 416, mobile phones 418 A and other mobile communicators, Personal Digital Assistants (PDA) 420, or any other similar computing device capable of communicating via the wireless network 414, as represented by generic device 422.
  • the Web service messages 402, 403 may be transferred between devices using short-range wireless technologies 424, such as Bluetooth, Wireless Local Area Network (WLAN), infrared (IR), etc.
  • the Web service messages 402, 403 can also be distributed using direct wired connections, such as depicted by connection path 426.
  • the present invention is applicable regardless of the manner in which data is provided or distributed between the target devices.
  • the mobile phone 418B includes, for example, a radio transceiver 434 and hardware (including the processor) coupled to an operating system (OS) 430.
  • a Web services interface 432 may be implemented as firmware or as a program running on the OS 430.
  • the Web services interface 432 may use any combination of Web service protocols known in the art, including SOAP, XML-Remote Procedure Call (XML-RPC) and others, and may be described and discovered using Universal Description, Discovery and Integration (UDDI), and Web Services Description Language (WSDL), among other possibilities.
  • the Web services interface 432 communicates using a reduced Web service message 402 according to embodiments of the present invention.
  • the reduced Web service message 402 is formed based on a redundancy agreement 403 maintained between the mobile phone 432 and another entity on the network.
  • the redundancy agreement 403 may be used to convert between a standard Web service message and the reduced message 402.
  • FIGS. 5 and 6 a system 500 of directly communicating network entities utilizes redundancy agreements in accordance with embodiments of the present invention.
  • the system includes a first network entity 502 and a second network entity 504 that are coupled via a network 506.
  • the first and second network entities 502, 504 each include redundancy agreement modules 508, 510 that work in concert with Web services processing stacks 512, 514, respectively.
  • the redundancy agreement modules 508, 510 and Web services processing stacks 512, 514 communicate over the network 506 through respective network interfaces 516 and 518.
  • the network interfaces 516, 518 may include protocol stacks (e.g., TCP/IP, UDP/IP) and hardware drivers and devices (e.g., Ethernet, FDDI, etc.).
  • the entities 502 and 504 include ability to communicate redundancy agreements 520 for the purposes of Web service communications using reduced messages 522.
  • the redundancy agreement modules 508, 510 provides the capability to form redundancy agreements, control RAP message exchanges, maintain state of all current redundancy agreements, and use the redundancy agreements to form and/or interpret Web service messages.
  • the modules 508, 510 may be separate add-ons to the respective Web services stacks 512, 514, and/or may be completely incorporated into the stacks 512, 514.
  • the redundancy agreement modules 508, 510 can be configured to initiate and maintain redundancy agreements with any or all Web services communications between various network hosts.
  • the redundancy agreement modules 508, 510 store data related to the redundancy agreements in storage arrangements 524, 526 of the respective entities 502, 504. It will be appreciated that the data may be host dependent. For example, redundancy agreements stored on the first network entity 502 for communications with the second network entity 504 are maintained separately from agreements with, for example, a third network entity 528. [0091] The arrangement shown in FIG.
  • FIG. 6 an alternate system 600 of providing Web services using redundancy agreements is illustrated according to embodiments of the present invention.
  • a first entity 602 and a second entity 604 may include standard Web service interfaces, 606 and 608, respectively.
  • the source and destination entities 602, 604 can utilize existing Web service software modules, programming tools, and procedure calls.
  • One or more intermediate nodes may act as proxies or gateways for Web service communications using reduced messaging.
  • the intermediate nodes 610, 612 typically include standard Web service interfaces, 614, and 616.
  • the intermediate nodes 610, 612 communicate with respective entities 602, 604 using the standard Web services interfaces 614, 616, but the intermediate nodes 610, 612 can communicate with each other using the RAP interfaces 618, 620. This allows redundancy agreements to be used in a way that is transparent to end points such as entities 602, 604.
  • a Web service message 630 sent from the first entity 602 is received at the Web service interface 614 of intermediate node 610.
  • the intermediate node 610 translates this message 630 to a reduced message 632 based on a redundancy agreement 622 between the intermediate entities 610, 612.
  • the reduced message 632 is sent from a reduced message interface 618 of intermediate node 610 to a reduced message interface 620 of intermediate node 612.
  • Intermediate node 612 uses a compatible set of criteria based on the redundancy agreement 622 to form a reproduced message 634 from the reduced message 632.
  • the reproduced message 634 is sent from the Web service interface 616 to the SOAP interface 608 of the second entity 604. Sending messages in the other direction, from entity 604 to entity 602, operates similarly, with the intermediate nodes 610, 612 forming reduced messages and/or reproduced messages as appropriate.
  • the system 600 shown in FIG. 6 allows a legacy Web service infrastructure to benefit from the use of redundancy agreements.
  • the system 600 may also allow standard Web service message exchanges to occur directly between entities 602, 604, as represented by the path 636.
  • the intermediate nodes 610, 612 may also be configured to handle only portion of standard Web service messaging (e.g., without forming reduced messages) between endpoints 602, 604, while other messages take the direct path 636 between entities 602, 604.
  • the use of intermediary nodes 610, 612 is useful when a data path
  • the gateway nodes 610, 612 includes a low-bandwidth connection.
  • a network entry point such as a mobile data client.
  • This data client may be represented in FIG. 6 as a unit 640 that encompasses both the network entity 602 and the intermediate node 610.
  • the intermediate node 610 could be implemented as a processing module within the mobile device.
  • Such a processing module may be an extension of the SOAP protocol stack, or may be implemented as a separate process that interfaces with the stack.
  • the reduced message interface 618 of the unit 640 communicates with the intermediate node 612.
  • the intermediate node 612 may be located anywhere on the network, preferably where the connection 642 between the intermediate node 612 and entity 604 includes a high bandwidth connection.
  • Hardware, firmware, software or a combination thereof may be used to perform the various messaging functions and operations described herein.
  • the computing structure 700 of FIG. 7 is an example computing structure that can be used in connection with such a Web services messaging system.
  • the example computing structure 700 suitable for performing the messaging activity in accordance with the present invention includes a computing arrangement 701.
  • the computing arrangement 701 may act a server, client, gateway, proxy, router, or any other network entity used for processing and delivering Web service messages using redundancy agreements.
  • the computing arrangement 701 includes a central processor (CPU)
  • the processor 702 may communicate with other internal and external components through input/output (I/O) circuitry 708 and bussing 710, to provide control signals and the like.
  • the memory of the computing arrangement 701 may be used to store processor executable instructions for carrying out various Web service related tasks. For example, processing of Web services messages and reduced messages, such as those exemplified in FIG. 3, may be performed by the computing arrangement 701 via a RAP processing module 738.
  • the RAP module 738 may create and maintain redundancy agreements and messages related to those agreements.
  • the RAP processing module 738 can provide Web services communications using reduced messages. For example, the RAP processing module 738 may translate reduced messages into fully formed Web services messages for further processing by the Web services modules. In another arrangement, the RAP processing module 738 may add logic to the Web services module 740 such that reduced messages and redundancy agreements are processed by different instructions than standard Web service messages.
  • the RAP processing module 738 and Web services messaging module 740 can be integrated into a single module or included as separate modules. Generally, the modules 738, 740 work in concert to invoke remote Web services by sending reduced messages and/or process Web services requests invoked via reduced messages.
  • External data storage devices such as databases, used for accessing message reduction criteria, may be coupled to I/O circuitry 708 to facilitate messaging functions according to the present invention.
  • databases may be locally stored in the storage/memory of the computing arrangement 701, or otherwise accessible via a local network or networks having a more extensive reach such as the Internet 728.
  • the processor 702 carries out a variety of functions as is known in the art, as dictated by software and/or firmware instructions.
  • the computing arrangement 701 may also include one or more data storage devices, including hard and floppy disk drives 712, CD-ROM drives 714, and other hardware capable of reading and/or storing information such as DVD, etc.
  • software for carrying out the messaging operations in accordance with the present invention may be stored and distributed on a CD-ROM 716, diskette 718 or other form of media capable of portably storing information. These storage media may be inserted into, and read by, devices such as the CD-ROM drive 714, the disk drive 712, etc.
  • the software may also be transmitted to computing arrangement 701 via data signals, such as being downloaded electronically via a network, such as the Internet 728.
  • the computing arrangement 701 may be coupled to a display 720, which may be any type of known display or presentation screen, such as LCD displays, plasma display, cathode ray tubes (CRT), etc.
  • a user-input interface 722 may be provided, including one or more user interface mechanisms such as a mouse, keyboard, microphone, touch pad, touch screen, voice-recognition system, etc.
  • the computing arrangement 701 may be coupled to other computing devices, such as landline and or wireless terminals via a network, for Web service messaging.
  • the server may be part of a larger network configuration as in a global area network (GAN) such as the Internet 728, which allows connections to the various landline and/or mobile devices, such as host 730.
  • GAN global area network
  • the computing arrangement 700 of FIG. 7 is provided as a representative example of a computing environment in which the principles of the present invention may be applied.
  • desktop computing devices similarly include a processor, memory, a user interface, and data communication circuitry.
  • the present invention is applicable in any known computing structure where data may be communicated via a network.
  • the invention may be implemented as a machine, process, or article of manufacture by using standard programming and/or engineering techniques to produce programming software, firmware, hardware or any combination thereof.
  • Any resulting program(s), having computer- readable program code, may be embodied on one or more computer-usable media, such as disks, optical disks, removable memory devices, semiconductor memories such as RAM, ROM, PROMS, etc.
  • Articles of manufacture encompassing code to carry out functions associated with the present invention are intended to encompass a computer program that exists permanently or temporarily on any computer-usable medium or in any transmitting medium that transmits such a program. Transmitting mediums include, but are not limited to, transmissions via wireless/radio wave communication networks, the Internet, intranets, telephone/modem-based network communication, hard-wired/cabled communication network, satellite communication, and other stationary or mobile network systems/communication links.

Abstract

A Web service of a network entity (504) can be invoked using reduced messages (522). A redundancy agreement message (520) is sent to the network entity. The redundancy agreement message (520) describes a redundancy agreement for invoking the Web service using reduced messages (522). A reduced message is formed based on the redundancy agreement and a non-redundant portion of a Web service message (630) that may be used for invoking the Web service. The reduced message (522) is sent to the network entity (504) and the Web service is invoked at the network entity (504) based on the reduced message (522) and the redundancy agreement message (520).

Description

SYSTEM, APPARATUS, AND METHOD FOR USING REDUCED WEB SERVICE MESSAGES
FIELD OF THE INVENTION [0001] This invention relates in general to Web services, and more particularly, to communications involving Web service messages.
BACKGROUND OF THE INVENTION [0002] The World Wide Web is most commonly associated with the access and display of content (e.g., text, graphics) in Web browsers. However, the emergence of what are known as "Web services" has been used to extend the World Wide Web's usefulness by providing access to computational procedures over the Web. Web services use some of the same open and extensible protocols and formats that have made Web browsers so useful, yet allow information to be accessed by programs and applications besides browsers. As a result, Web services can be powerful tools for providing distributed data access in many application domains. [0003] Web services are network-based (particularly Internet-based) applications that perform a specific task and conform to a specific technical format. Web services may be implemented using a stack of emerging standards that describe a service- oriented application architecture, collectively providing a distributed computing paradigm having a particular focus on delivering services across the Internet. [0004] Generally, Web services are implemented as self-contained modular applications that can be published in a ready-to-use format, located, and invoked across networks. When a Web service is deployed, other applications and Web services can locate and invoke the deployed service. They can perform a variety of functions, ranging from simple requests to complicated business processes. [0005] Web services are typically configured to use standard Web protocols such as Hypertext Transfer Protocol (HTTP) and formats such as the Extensible Markup Language (XML) but may use other protocols and formats as well. Web services are distinguished through the use of SOAP (the first version was an acronym for Simplified Object Access Protocol) and are commonly associated with a Web Services Description Language (WSDL) description. HTTP is an application-level protocol commonly used to transport data on the Web. XML is a mechanism to define markup languages. Some markup languages (e.g., HTML) are used mainly to describe how a document is to be formatted for display. Others are defined to describe application data. SOAP is a markup language for message encapsulation and is typically used to transmit messages that invoke remote procedure calls, return the results from such invocation, or transmit documents. [0006] The availability of Web services makes the Web an even more powerful communications medium. Web services enable a service-oriented architecture to be created using existing Web technologies. Any Web-services-aware program can invoke other services, enabling applications to be dynamically composed from reusable components. Hence, Web services can be a part of a program carrying out any kind of computation, yet can be accessed and run anywhere due to the ubiquity of the Internet and its associated protocols. Further, the Web service standards can be adapted handle almost any type of data, due to the use of extensible languages such as XML. [0007] The flexibility and extensibility of typical Web services such as
SOAP come at a cost, however. The text based, tagged format of XML is quite verbose. Such XML text representations are preferred for Web services because they enable interoperability and are easy to read and debug. However, text representations are not the most efficient form in which to transmit data, and therefore require more bandwidth to transmit than is theoretically necessary. The tags and other required fields in XML increase the data overhead when using these types of Web services, especially on small, simple transactions. [0008] Although the Web network infrastructure is increasingly adding bandwidth capacity, many users are forced to rely on limited bandwidth connections. This is especially true of mobile device users. The physics of wireless data transfer makes it much more difficult to provide high bandwidth at a reasonable cost. As a result, the bandwidth available to mobile devices is not necessarily catching up to the processing power provided in the devices themselves. As a result of bandwidth limitations, users of mobile devices may not be able to efficiently use Web services utilizing protocols such as SOAP without consideration of these factors. SUMMARY OF THE INVENTION [0009] The present disclosure relates to a system, apparatus, and method for using reduced Web services messages. In accordance with one embodiment of the invention, a method involves invoking a Web service of a network entity. A redundancy agreement message is sent to the network entity. The redundancy agreement message describes a redundancy agreement for invoking the Web service using reduced messages. A reduced message is formed based on the redundancy agreement and a non-redundant portion of a Web service message configured for invoking the Web service. The reduced message is sent to the network entity and the Web service is invoked at the network entity based on the reduced message and the redundancy agreement. [0010] In more particular embodiments, any of the Web service message, reduced message, and the redundancy agreement message may include a SOAP message. The redundancy agreement message may include a binary formatted message. The redundancy agreement may include mapping of identifiers to content strings. The content strings are based on a non-redundant portion of the Web service message. The content strings may be base64 encoded. [0011] In other configurations, the method may involve sending a redundancy agreement reply message from the network entity in response to the redundancy agreement message. The redundancy agreement reply message may include a suggested modification to the redundancy agreement. The redundancy agreement message may be included in a non-reduced Web service message, such as in a message header of the non-reduced Web service message. [0012] Invoking the Web service at the network entity based on the reduced message and the redundancy agreement may involve creating a template based on the redundancy agreement and forming a replicated Web service message from the template by replacing portions of the template with selected portions of the reduced message. In one arrangement, at least one of the selected portions of the reduced message and the portions of the template may include any combination of LISP encoded values, base64 encoded values, and XML elements. The reduced message may include one or more XML processing instructions indicating the portions of the template to be replaced and the selected portions of the reduced message. The one or more XML processing instructions may be base64 encoded. The reduced message may also use XML tags as replacement indicators, placing encoded processing instructions or LISP encodings within these XML elements. [0013] In more particular embodiments, the method involves determining a quality measurement based on sizes of the reduced message and the Web service message. The quality measurement may be used to determine whether to utilize the redundancy agreement and/or used to determine a form of the redundancy agreement. [0014] In another embodiment of the present invention, a computing arrangement includes a network interface, a memory capable of storing at least one of a redundancy agreement module and a Web services processing module, and a processor coupled to the memory. The processor is configured by redundancy agreement module to form redundancy agreement messages describing redundancy agreements for invoking Web services using reduced messages. The processor is configured by the Web services module to send the redundancy agreement messages and the reduced messages via the network interface using a Web service protocol for purposes of invoking the Web service. The network interface may include a wireless network interface and the computing arrangement may include a mobile terminal. [0015] In another embodiment of the present invention, a messaging system includes means for sending a redundancy agreement message to a network entity. The redundancy agreement message describes a redundancy agreement for invoking the Web service using reduced messages. The system also includes means for forming a reduced message based on the redundancy agreement and a non-redundant portion of a Web service message configured for invoking the Web service, means for sending the reduced message to the network entity, and means for invoking the Web service at the network entity based on the reduced message and the redundancy agreement. The system may also include means for determining a quality measurement based on the sizes of the reduced message and the Web service message. [0016] In another embodiment of the present invention, a computer- readable medium has instructions stored which are executable by a computing arrangement for performing steps that include sending a redundancy agreement message to a network entity for purposes of invoking a Web service. The redundancy agreement message describes a redundancy agreement for invoking the Web service using reduced messages. The steps also include forming a reduced message based on the redundancy agreement and a non-redundant portion of a Web service message configured for invoking the Web service, sending the reduced message to the network entity, and invoking the Web service at the network entity based on the reduced message and the redundancy agreement. [0017] In another embodiment of the present invention, a computing arrangement configured to provide a Web service includes means for receiving a redundancy agreement message from a network entity. The redundancy agreement message describes a redundancy agreement for invoking the Web service using reduced messages. The computing arrangement includes means for receiving a reduced message based on the redundancy agreement and a non-redundant portion of a Web service message configured for invoking the Web service, and means for invoking the Web service based on the reduced message and the redundancy agreement. The computing arrangement may also include means for sending a reduced response message to the network entity in response to invocation of the Web service. The reduced response message is based on a second redundancy agreement established between the computing arrangement and the network entity. [0018] In another embodiment of the present invention, a computing arrangement is configured to act as a proxy for providing a Web service. The computing arrangement includes means for receiving a redundancy agreement message from a first Web service entity. The redundancy agreement message describes a redundancy agreement for supporting the Web service invocation using reduced messages. The computing arrangement includes means for receiving a reduced message based on the redundancy agreement and a non-redundant portion of a Web service message configured f to support the Web service invocation, means for converting the reduced message to a replica of the Web service message based on the reduced message and the redundancy agreement, and means for sending the replica of the Web service message to a second Web service entity in support of the Web service invocation. The computing arrangement may also include means for receiving a Web service response message from the second Web service entity; and means for sending to the first Web service entity a reduced response message. The reduced response message is based on the Web service response message and a second redundancy agreement established between the computing arrangement and the first Web service entity. BRIEF DESCRIPTION OF THE DRAWINGS [0019] The invention is described in connection with the embodiments illustrated in the following diagrams. [0020] FIG. 1 illustrates network connectivity related to reduced message processing; [0021] FIG. 2 illustrates an example Web service message exchange according to embodiments of the present invention; [0022] FIG. 3 illustrates a procedure for implementing Web service redundancy agreements according to embodiments of the present invention; [0023] FIG. 4 illustrates a system environment in which a Web service messaging according to embodiments of the present invention may be employed; [0024] FIG. 5 illustrates an arrangement for providing Web service messaging with redundancy agreements between network entities according to embodiments of the present invention; [0025] FIG.6 illustrates another arrangement for providing Web service messaging with redundancy agreements between network entities according to embodiments of the present invention; and [0026] FIG. 7 illustrates a computing arrangement for processing of reduced messages according to embodiments of the present invention.
DETAILED DESCRIPTION OF THE INVENTION [0027] In the following description of the example embodiments, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration various example embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized, as structural and operational changes may be made without departing from the scope of the present invention. [0028] Generally, the present disclosure is directed to a system, apparatus, and method that reduces the size of Web service messages communicated between network entities. The Web service messages can be partitioned into redundant and non- redundant data. The redundant data does not change for all invocations of the same interface between two entities, so may be unnecessary for repeated, similar Web service transactions. The redundant data can be removed from the messages by negotiating a redundancy agreement between two network entities. Once the agreement is accepted by both entities, a reduced message can be formed from the non-redundant data and sent over a communications link. [0029] It will be appreciated that XML and XML-based Web services (e.g.,
SOAP) offer a major advantage of interoperability. This is important in a service-oriented architecture, where new relationships and services are to be dynamically added without requiring extensive re-engineering. This ability to dynamically adapt Web services is extremely valuable from a business perspective and can override technical issues. Thus, when attempting to improve SOAP message performance, it is important to maintain the business benefits of XML. [0030] SOAP messages can be large due to the XML serialization that introduces much redundancy. The verbosity of XML can be useful for readability and extensibility, but is inefficient from the perspective of network usage. Use of SOAP messages can be an issue when network bandwidth is constrained, increasing latency and costs. It can also impact storage requirements at processing nodes that must store messages (e.g., when waiting to aggregate information). [0031] Within a single SOAP message, there are some redundancies that can be addressed. For example, each start tag is replicated with an end tag. SOAP and XML best practices recommend long, readable tags. By reducing or eliminating some of these tags, the reduction in space can be large when big messages are processed. Using end tags results in duplicating these large tags. Similarly, namespace declarations are often long strings that are redundantly used many times. [0032] A simple encoding that eliminates all end-tags can produce a 20% savings or more with minimal processing. Use of a LISP representation allows this encoding to retain the essential XML InfoSet structure without the use of end tags. Communicating parties may also be aware of large redundant strings, such as namespace URLs or other strings and wish to encode these strings with shorter abbreviations. This disclosure describes a dynamic means to manage such definitions. [0033] Much redundancy can be found across a series of messages between communicating parties when considering all messages sent over time (not limited to a single message exchange pattern). For example, if a SOAP message is used like a form where most of the message is fixed and only small amounts of information are changed, then much redundancy can be removed by only sending a reduced message with only the changed data. [0034] Utilizing reduced messages requires the sender and receiver to agree on the form and what is sent. In one example, the agreements on the redundant and non- redundant data may be presumptive, that is, established before any communications have taken place. A presumptive agreement may be difficult to implement, especially when interactions are established dynamically or as forms change over time. The approaches described herein may allow dynamic decisions to be made between parties as to what is redundant data without requiring a presumptive, pre-agreement. [0035] Creating a generalized global redundancy system is intractable. A major problem is to establish globally unique identifiers for redundant text while keeping these identifiers small. It will be appreciated that if the identifiers grow large, it will defeat the benefits of redundancy reduction. It is also a challenge to ensure the consistency of this representation among SOAP nodes regardless of communication patterns. Consider the example of FIG. 1 where four SOAP nodes all communicate with each other. [0036] The diagram 100 of FIG. 1 illustrates inter-nodal Web services communications according to embodiments of the present invention. The nodes 102, 104, 106 and 108 may each engage in data communications with each other. The problem with attempting to make global redundancy in such a scenario can be demonstrated with the steps 120, 122, and 124 (illustrated as arcs in FIG. 1): Step 120: Node 102 agrees with node 108 that "<soap:Envelope>" is represented with "l." Step 122: Meanwhile node 106 agrees with node 104 that "<order>" is represented with "l." Step 124: Next node 104 communicates with node 108 but cannot agree on an encoding for "<soap:Envelope>" since both nodes 104 and 108 have used "1" inconsistently. [0037] One approach to solve the above problem would be to have an administrative protocol running continuously to update all nodes with global information. Such an administrative protocol would introduce overhead, reducing the benefits of redundancy removal. Even if such a protocol could effectively reduce overall redundancy, such an update mechanism would be subject to potential race conditions. In the previous example, an update would need to happen after step 120 but before step 122, yet in reality these steps could be happen simultaneously in a distributed environment, creating a race condition. [0038] Creating long unique identifiers based on the content to be reduced might work in the scenario described above, but collisions are inevitable if a larger space is mapped to a smaller space. By using pair-wise agreements, these problems may be avoided. Pair-wise agreements may still introduce the overhead of establishing and maintaining these agreements. This overhead may be acceptable if the parties are already communicating and the overhead is small relative to the overall communication. [0039] In the case of pair- wise agreements the previous scenario is not an issue. The first two steps 120, 122 are the same as above, but with the following third step: Step 124A: Node 104 agrees with node 108 that "<soap:Envelope>" is represented with "2." [0040] This disclosure is related to a protocol that uses pair-wise agreements for redundancy removal in Web service communications. This is useful between parties that have a long-running communication pattern involving many Web service messages, thereby reducing the impact of protocol overhead. Managing redundancy independently between pairs of communicating parties avoids the need for global consistency management, and scales by leveraging support for existing communication patterns. [0041] One of the advantages of a service oriented architecture, and of
Web services in particular, is that an application can dynamically compose services as well as change providers without extensive re-engineering, interoperation testing, or static configuration management. The benefits of flexibility would be lost if a performance mechanism required static configuration. Static configuration is also more labor intensive, costly and error-prone. This suggests that communicating end parties first agree to use redundancy removal, and then agree what is to be encoded as part of an agreement protocol. Although redundancy agreement protocols are described herein using SOAP/XML examples, it will be appreciated that these concepts are equally applicable to other service-oriented architectures and protocols. [0042] A redundancy protocol implemented in SOAP/XML should use a
SOAP header block mechanism to allow it to be composed with other SOAP extensions, such as SOAP message security, for example. The redundancy protocol can also use a header mechanism to avoid changes to payload for agreement, allowing it to be used with a variety of application defined payloads. The protocol can also make it possible to transfer the payload as well as redundancy agreement protocol information in one message, using such "piggybacking" to reduce the overhead of redundancy control. The protocol mechanism may include the ability to bootstrap, either for a new participant or to recover from errors and to re-establish synchronization. [0043] The redundancy removal mechanism is general purpose, allowing different granularities of information to be encoded, including: 1. Strings, e.g., whitespace delimited strings found in the body, headers or markup. 2. Tags, e.g., <soap:Envelope>. 3. Arbitrary XML, e.g., <x:Address> <street>57 Oak St</street> <city>Cambridge</city> <state>MA</state> <countryCode>US</countryCode> </x:Address> 4. Binary content, e.g., a base64 encoded X.509 certificate. 5. XML content with substitutions, enabling XML to be treated like a form. [0044] How parties choose the redundancy may be application dependent.
The parties may choose the redundancy agreement based on knowledge of message meaning and level of redundancy. For example, the application may detect that this is an XML form. The parties may also choose the redundancy agreement using a predictive scheme based on previous message content. For example, the application may track pattern frequencies to predict redundancy. [0045] Components of an exemplary redundancy removal mechanism include: (1) a Redundancy Agreement Protocol (RAP) - protocol used to agree on what redundant information to encode and how to encode it; (2) a Replacement Encoding Indicator (REI) - a procedure for replacing content with message encoding indicator; (3) LISP Encoding for SOAP messaging (LES) - Use of LISP to capture hierarchical XML structure, eliminating need for XML end tags; and (4) Redundancy Reduction Quality Measure (RRQM) - an optional mechanism to dynamically track redundancy reduction quality. [0046] The first component of a redundancy removal mechanism, the RAP, is discussed first. Reducing redundancy requires an agreement between communicating parties on how to represent the redundant information so that they can consistently recreate the information in its original form. The potential difficulty is that multiple parties may all communicate with each other in different patterns dynamically establishing different incompatible redundancy mechanisms. [0047] An agreement mechanism that does not attempt to achieve global consistency solves this problem in a scalable manner since the agreements only involve parties that already manage information about each other. Generally, long-term communications are between small numbers of parties. Each communicating party agrees with a single partner which redundancy mechanism to use with that party - recording this information allows communication between the two parties and does not interfere with communication with others. [0048] Redundancy removal may be accomplished by maintaining a synchronized mapping at the two communicating parties, e.g., mapping small integers (e.g., 1, 2,3) with the corresponding redundant content. Rather than sending the content, the identifying number is sent. The table is established and managed using SOAP headers designed to function as a redundancy removal agreement protocol. [0049] A message sender decides which text is potentially redundant and chooses to map each section of redundant text to a small unique identifier that it has not already used with the receiver of the message. If the sender already has an identifier for redundant information for that party then it uses that identifier again and there is no need to re-establish the agreement. [0050] For each new piece of redundant information the sender generates an XML redundancy mapping element to map the identifier to the redundant information: <map> < id>2</id> <content>abc</content> </map> [0051] Redundant text may also include "holes", e.g. portions that may be filled in using values matching the mapping template. The <map> element supports definition of a value marker used in the definition of redundant content. This marker specifies where replacement values go, "V" in this example: <map> <id>3</id> <repl cnt='T">V</repl> <content><a>V</a></content> </map> [0052] The optional "cnt" attribute specifies the number of replacements to be expected. Note that unique replacement strings could be defined for each replacement. This could be done with repeated occurrences of the "repl" and "content" elements within the map element, or by using additional map elements having a different ID. However, where the replacements are ordered, this is unnecessary and would add overhead. Ordered replacements can be handled by including a single value marker in the "content" element wherever a replacement is needed. When placing the replacement values in the template, the values are provided as a collection, or list. Each value is taken off the list and consecutively inserted in place of each marker. [0053] Although placing redundant XML in the map element may keep the
XML well-formed, it is preferable that all content be base64 encoded before mapping. This assures that the description is well-formed and, therefore, that a SOAP message header containing it is well-formed and valid. Before base64 encoding, replacement markers may be placed in the redundant content, to allow it to act as a template. An example is shown below: <map> <Id>2</Id> <b64>YWJj</b64> </map> Note that the redundancy agreement mechanism described in this application may also support other encodings than base64. Such encodings may be represented using other tags, as would be known to those familiar with the art. Note also that an alternative implementation could use type attribute with the content tag to represent various encodings of the value, for example: <content encoding=' b64 ' > Y W Jj <content> This example shows a specific XML tag (content) and attribute (encoding) to signify base64 encoding, but other tag and attribute names could be used for this purpose. [0054] One or more <map> elements may be contained in a single
Redundancy Agreement Protocol SOAP header block: <r:rap xmlns:r="http://www.nokia.com/rap" role="next" mustUnderstand="l"> </r:rap > [0055] If a target SOAP role does not understand the header block it generates a SOAP fault and this redundancy reduction mechanism is not used. It is also possible to determine through the service description, or by out of band mechanisms or through the use of policy headers whether redundancy reduction is supported, allowing the sender to only request it when appropriate. It is also possible for a receiver to indicate that it does not support the mechanism. [0056] If the redundancy agreement protocol is supported, then a receiver processes the header block by examining each <map> element to determine if that ID has been used and also if that text is already stored for the sender. The following possibilities may exist: 1) The text has no entry and the ID has not been used; The receiver may "accept" this proposal; 2) The text has no entry but the ID has been used; This may occur if this receiver has sent a proposal to the sender and used this ID for different text. The two messages "crossed" during communication. The receiver may propose a different ID. 3) The text has an entry for the same ID. The receiver may "accept" this proposal. The sender must have cleared its table for some reason. 4) The text has an entry for a different ID. The receiver may propose this different ID. Responses are OK (accept) or Map (provide mapping). [0057] The response header block may contain an OK statement for each
ID that has been accepted. The response header block may also contain a map statement for each new ID proposal. For example: <ok>l</ok> <map> < id>7</id> <content>abc</content> </map> [0058] The protocol exchange continues until all IDs have been agreed upon. This means that if a response has a map statement, or an ID has been ignored that is not agreed, the party must either accept the proposed ID, or suggest a mapping with a different ID that was proposed (or ignored). [0059] Another approach is for the sender to assign IDs starting at the low end (e.g. 1) and for the receiver to assign them starting at the high end (e.g. 1024) minimizing collisions if the range is large enough. This minimizes the need for multiple agreement messages for IDs. Other redundancy options may also be agreed upon using the RAP SOAP header. Specifically, the encoding attribute may be used to agree upon LISP serialization (default, "LISP") or XML serialization ("XML"). Note that redundancy reduction techniques may be integrated with XML canonicalization processing, thus reducing the overhead of reduction, since that processing is performed anyway. This can be used in conjunction with a minimalist SOAP profile, for example. [0060] Once the RAP has established an agreed upon scheme for sending reduced messages between entities, each entity utilizes a mechanism for translating between the messages in original and reduced form. These mechanisms include formatting/ordering the non-redundant data for transmission by sending entity and interpreting the reduced message at the receiving entity. [0061] Redundancy may be reduced by not sending the redundant information and either 1) knowing what it is out of band or 2) sending an identifier to indicate the information that should be restored at which spot. These techniques require a mechanism to distinguish between mapped content and unmodified original content, since the two may be mixed. The locations of the data within the reduced messages may be indicated by a replacement encoding indicator (REI). In one example, XML processing instructions can be used as REIs. A replacement encoding indicator may be implemented using XML processing instructions, a LISP serialization, or an XML replacement encoding. [0062] Use of XML processing instructions has the advantage that they are a well-defined XML construct and are not a legal SOAP messaging construct (but neither is LISP encoding). Use of disallowed characters for REI is not workable, not to mention dangerous, as is the use of entity references. Additional XML markup may be used for REI, but this would defeat the purpose of redundancy removal. XML processing instructions are short and well suited to the purpose. [0063] Given that XML processing instructions are disallowed by the
SOAP standard, it is unlikely that a processing instruction will be present for any reason other than redundancy removal. Even if so, it is also unlikely that a processing instruction matching the form used for redundancy removal will be present. [0064] When using XML processing instructions to implement a replacement encoding indicator, two forms may be used. If the replacement text is constant, then that replacement content may be indicated with an agreed upon number placed as the sole value of the XML processing instruction (e.g., <?7?>). If value substitution is to be used, then the processing instruction must also contain the values to substitute in the redundancy template, placed as an ordered list following the number indicating replacement content. Each value is preferably base64 encoded to ensure that all spacing is preserved and then placed within parentheses, creating a list of values within the processing instruction following the redundancy agreement template value, (e.g., <?6 (value 1) (value2)?>). [0065] As previously described, a LISP encoding of XML data can provide significant message size reduction by removing redundancy inherent in the XML end tags. LISP serialization replaces start and end tags with a list structure of the following form: (tag-name ((argument 1 value 1) (argument2 value2)...) element-content ) This corresponds to the XML: <tag-name argument 1=" value 1" argument2="value2">element content</tag-name> [0066] When using LISP encoding, each argument that is present in the original start tag denoted using argument- Value" now has the argument as the first item in a parenthesized list and the quoted value as the second item. The "=" sign is removed. If the start tag had no arguments then the tag name is followed by an empty LISP list, e.g. (). It will be appreciated that the LISP serialization may involve variations on how the arguments are quoted in the LISP representation, or whether they are included in a sub- list. Note that this applies regardless of the XML quoting used, either single or double quotes. [0067] Note that the end tag-name overhead is eliminated, the parentheses for the element and the argument list use the same space as the original start and end tag brackets, and that one of the parentheses for each argument list replaces each equals sign. The savings in the end tag text must balance the extra parenthesis for each argument. [0068] An XML replacement encoding is necessary when the receiver needs to be able to use a standard XML and SOAP parser to process the message. In this case portions of the XML may be replaced with redundancy encoding indicators, but the use of XML processing instructions or pure LISP encoding may cause the standard SOAP processing to fail. In this case the redundancy encoding indicator may be an XML tag in a unique XML namespace, containing a base64 encoded processing instruction or LISP encoding of the redundancy information. For example, the following XML message may need to remain intact to allow SOAP processing, yet may have redundant portions of the payload replaced: <env: Envelope xmlns : env="http: //www. w3. org/2003/05/soap-envelope"> <env:Header>...</env:Header> <env:Body> <x:Address xmlns :x="http: //www. example. com/address"> <x:street>57 Oak St</x: street> <x : city>Cambridge</x : city> <x : state>MA</x : state> <x : countryCode>US</x : countryCode> </x: Address> </env:Body>
The address portion may be removed in a redundancy encoding as follows: <env: Envelope xmlns : env="http: //www. w3. org/2003/05/soap-envelope"> <env: Header>... </env: Header> <env:Body> <r :r xmlns :r=' http: //www. example. com/rr' type='pi' >PD8xPz K</r : r> </env:Body>
[0069] In this example the value of the "r:r" element is a base64 encoded processing instruction <?1?> that represents the replaced address XML text. The type parameter indicates that the format of the base64-encoded content (processing instruction or LISP form) is the processing instruction form. Note that a default attribute value may allow this XML attribute to be omitted. Note also that the "r" prefix is arbitrary and that the meaning is indicated by the XML namespace. This tag and prefix could be different in an implementation without changing this application. [0070] Systems utilizing reduced messages may require a quality measure that describes the data reduction resulting from RAP mechanisms. The quality of redundancy reduction can be measured and updated with each SOAP message received. This can be used to control how redundancy processing is performed, or whether it is used at all. In one example, two totals are maintained: 1) the total SOAP message bytes received (TotalXfer), and 2) the total SOAP application bytes received (TotalApp). The TotalXfer value includes the size of reduced data messages as well as the size of RAP messages exchanged. The TotalApp value includes the total XML encoded data message bytes received; redundant content and XML serialization is restored before measuring. These totals can be used to calculate the current average redundancy removal percentage over the lifetime of measurement: (TotalApp - TotalXfer)/TotalApp. [0071] A more particular example of RAP mechanisms is presented herein.
In reference FIG. 2, an example SOAP message exchange 200 is shown that utilizes redundancy mechanisms according to embodiments of the present invention. The message exchanges in FIG. 2 relate to a hypothetical airline reservations request between a requestor 202 and a reservation service 204. Without any redundancy mechanisms, the typical exchange of this sort would involve standard SOAP messages for a reservation request 210, a clarification request 216, and a clarification response 222. Using the redundancy agreement may involve exchanging additional RAP messages so that the core messages 210, 216, 222 can be exchanged in a reduced format. [0072] The additional RAP messages include redundancy agreements 206,
212, and 218 associated with each SOAP message 210, 216, and 222, respectively. The receiver of a redundancy agreement will respond with an acceptance or rejection, as indicated by the acceptance messages 208, 214, and 220 associated with the redundancy agreements 206, 212, and 218. It will be appreciated that if the result of a redundancy agreement were a rejection or error then the exchange would continue using standard, unreduced, SOAP messages. [0073] It will also be appreciated that the redundancy agreements 206, 212, and 218 and responses 208, 214 and 220 only need to be used the first time this type of exchange occurs between the requestor 202 and the service 204. Once the redundancy agreements 206, 212, and 218 have been established, any future, similar exchanges between these entities 202, 204 can use reduced messages, with only the non-redundant data altered between subsequent invocations. [0074] Some example messages for the exchanges of FIG. 2 are shown below in Listings 1-6. In particular, the examples of Listings 1-6 illustrate messages 206, 208, and 210 of FIG. 2. Listing 1 shows a SOAP reservation request 210 formed according to the SOAP standard (with lines reformatted for readability):
<env: Envelope xmlns : env="http: //www. 3. org/2003/05/soap-envelope"> <env:Header> <m: reservation xmlns :m="http: //travelcompany. example. org/reservation" env: role="http: //www. w3. org/2003/05/soap- envelope/role/next" env :mustUnderstand="true"> <m:reference>uuid: 093a2dal-q345-739r-ba5d- pqff98fe8j7d</m:reference> <m:dateAndTime>2001-11-29T13: 20: 00.000-05 : 00</m:dateAndTime> </m: reservation> <n: passenger xmlns :n="http: //mycompany. example . com/employees" env: role="http: //www. w3. org/2003/05/soap- envelope/role/next" env : mustUnderstand="true"> <n:name>Ake Jόgvan 0yvind</n:name> </n:passenger> </env: Header> <env: Body> <p: itinerary xmlns :p="http: //travelcompany. example . org/reservation/travel"> <p:departure> <p : departing>New York</p : departing> <p : arriving>Los Angeles</p : arriving> <p:departureDate>2001-12-14</p:departureDate> <p : departureTime>late afternoon</p : departureTime> <p: seatPreference>aisle</p: seatPreference> </p : departure> <p: return> <p : departing>Los Angeles</p : departing> <p : arriving>New York</p : arriving> <p:departureDate>2001-12-20</p:departureDate> <p:departureTime>mid-morning</p:departureTime> <p: seatPreference/> </p: return> </p : itinerary> <q: lodging xmlns : q="http: //travelcompany. example .org/reservation/hotels"> <q:preference>none</q:preference> </q: lodging> </env:Body> </env : Envelope> Listing 1
[0075] Listing 2 illustrates a redundancy agreement message for the SOAP message of Listing 1. Note that the base64 block in Listing 2 contains the substitution template that includes the "V parameters that mark locations for insertion of the non- redundant data. The use of base64 encoding ensures the SOAP message of Listing 2 is well formed. Listing 3 shows the decoded representation of the base64 encoded block of Listing 2. <env: Envelope xmlns : env="http: //www. 3. org/2003/05/soap-envelope"> <env:Header> <r:rap xmlns : r="http: //www. nokia . com/rap" role="next" mustUnderstand="l"> <map> <id>K/id> <repl cnt="14">V</repl> <b64> KGVudjpFbnZlbG9wZSAoKHhtbG5zOmVudiBodHRwOi8vd3d3LnczLm9yZy8yMDAzLzAl L3NvYXAtZ 52ZWxvcGUpKSAgDQogKGVudjpIZ FkZXIgKCkgDQogIChtOnJlc2VydmF0 a 9uICgoZW520nJvbGUgaHR0cDovL3d3dy53My5vcmcvMjAwMy8wNS9zb2FwL VudmVs b3BlL3JvbGUvbmV4dCkoZ 52Omllc3RVbmRlcnN0YW5kIHRyd UpKHhtbG5zOm0gaHR0 cDovL3RyYXZlbGNvbXBhbnkuZXhhbXBsZS5vcmcvcmVzZXJ2YXRpb24pKSANCiAgICht OnJlZmVyZ 5jZSAoKSBWKQ0KICAgKG06ZGF0ZUFuZFRpbWUgKCkgVikNCiAgKQ0KICAo bjpwYXNzZ 5nZXIgKCh4b xuczpuIGh0dHA6Ly9te NvbXBhbnkuZXhhbXBsZS5jb20v Z lwbG95Z VzKShlbnY6bXVzdFVuZGVyc3RhbmQgdHJlZSkoZ 52OnJvbGUgaHR0cDov L3d3dy53My5vcmcvMjAwMy8wNS9zb2FwLWVudmVsb3BlL3JvbGUvbmV4dCkpIA0KICAg KG46bmFtZSAoKSB KQ0KICApDQogKQ0KIChlbnY6Qm9keSAoKSANCiAgKHA6aXRpbmVy YXJ5ICgoeGlsbnM6cCBodHRwOi8vdHJhdmVsY29tcGFueS51eGFtcGxlLm9yZy9yZXNl cnZhdGlvbi90cmF2Z wpKSANCiAgIChwOmRlcGFydHVyZSAoKSANCiAgICAgKHA6ZGVw YXJOaW5nICgpIFYpDQogICAgIChwOmFycml2aW5nICgpIFYpDQogICAgIChwOmRlcGFy dHVyZURhdGUgKCkgVikNCiAgICAgKHA6ZGVwYXJ0dXJlVGltZSAoKSB KQ0KICAgICAo cDpzZWF0UHJlZmVyZW5jZSAoKSB KQ0KICAgKQ0KICAgKHA6cmV0dXJuICgpIA0KICAg ICAocDpkZXBhcnRpbmcgKCkgVikNCiAgICAgKHA6YXJyaXZpbmcgKCkgVikNCiAgICAg KHA6ZGVwYXJ0dXJlRGF0ZSAoKSBWKQ0KICAgICAocDpkZXBhcnRlcmVUa llICgpIFYp DQogICAgIChwOnNlYXRQcmVmZXJlbmNlICgpIFYpDQogICApDQogICkNCiAgKHE6bG9k Z21uZyAoKHhtbG5zOnEgaHR0cDovL3RyYXZlbGNvbXBhbnkuZXhhbXBsZS5vcmcvcmVz ZXJ2YXRpb24vaG90Z xzKSkgDQogICAocTpwcmVmZXJlbmNlICgpIFYpDQogICkNCiAp DQopDQo= </b64> </map> </r : rap> </env:Header> <env: Body> </env: Body> </env: Envelope> Listing 2
(env: Envelope ( (xmlns : env http: //www. w3. org/2003/05/soap-envelope) ) (env:Header () (m: reservation ((env:role http://www.w3.org/2003/05/soap- envelope/role/next) (env:mustUnderstand true) (xmlns :m http: //travelcompany. example. org/reservation) ) (m: reference () V) (m:date ndTime () V) ) (n:passenger ((xmlns:n http: //mycompany . example . com/employees) (env:mustUnderstand true) (env: role http: //www. w3. org/2003/05/soap-envelope/role/next ) ) (n:name () V) ) (env: Body () (p:itinerary ((xmlns:p http:/ /travelcompany. example . org/reservation/travel) ) (p: departure ( ) (p:departing () V) (p: arriving () V) p:departureDate () V) p:departureTime () V) (p: seatPreference () V) (p: return () (p: departing () V) (p: arriving () V) (p:departureDate () V) (p:departureTime () V) (p: seatPreference () V) ) ) (q= lodging ( (xmlns :q http: //travelcompany. example . org/reservation/hotels) ) (q preference () V) ) ) ) Listing 3
[0076] Listing 4 illustrates the response message 208 of FIG. 2 that indicates the redundancy agreement of Listing 2 has been accepted.
<env: Envelope xmlns : env="http: //www. 3. org/2003/05/soap-envelope"> <env: Header> <r : rap xmlns : r="http : //www. nokia . com/rap" role="next " mustUnderstand="l "> <ok>K/ok> </r : rap> </env: Header> <env : Body> </env : Body> </en : Envelope> Listing 4 [0077] The message in Listing 5 is the reduced message that includes a list entry for each value, a base64 encoded value used to avoid problems with whitespace handling. This information can be combined with the redundancy agreement template of Listing 2 to form a message equivalent to that shown in Listing 1. Listing 6 shows the message of Listing 5 without the base64 encoding, to clarify how the mechanism functions.
<?ι (dXVpZDowOTNhMmRhMSlxMzQlLTczOXItYmElZClwc ZmOThmZThqN2Q=) (MjAwMSOxMSOyOVQxMzoyMDowMC4wMDAtMDU6MDA=) (d2tlIEp6Z3ZhbiB4eXZpbmQ=) (TmV3IFlvcms=) (TG9zIEFuZ2VsZXM=) (MjAwMS0xMi0xNA==) (bGF0ZSBhZnRlcm5vb24=) (Y lzbGU=) (TG9zIEFuZ2VsZXM=) (TmV3IFlvcms=) (MjAwMS0xMi0yMA==) (bWlkL lvcm5pbmc=) 0 (bm9uZQ==) ?> Listing 5 <?ι uuid:093a2dal-q345-739r-ba5d-pqff98fe8j7d 2001-11-29T13: 20: 00.000-05: 00 wke Jzgvan xyvind New York Los Angeles 2001-12-14 late afternoon aisle Los Angeles New York 2001-12-20 mid-morning none ?> Listing 6
[0078] It will be appreciated that the message reduction techniques described in relation to Listings 1-6 can be applied to the remaining message exchanges illustrated in FIG. 2. In general, the message reduction techniques described herein may be applied to set of Web service messages that are exchanged between hosts. The use of redundancy agreements allows these exchanges to be ad hoc, only requiring that the hosts be able to understand and apply the redundancy agreements before utilizing the reduced messages. Where redundancy agreements cannot be made, message exchanges can resume according to the default Web service standards. [0079] A flowchart 300 of FIG. 3 illustrates an example procedure of performing Web service communications using redundancy agreements according to embodiments of the present invention. The procedure begins with a first network entity forming a Web service message (304), e.g., a SOAP message. The Web service message does not necessarily need to be formed as a fully formatted XML message, but generally the information needed to form the message (e.g., an XML InfoSet, information for a remote method invocation, a document and related message information, etc.) is in place such that a standard SOAP message could be formed. A redundancy agreement is then formed (306) based on at least the non-redundant parts of the Web service message. The redundancy agreement is sent (308) across a network or other communication means and targeted for a second data processing entity. The second network entity may be the destination of the SOAP message, or may be some intermediate entity. [0080] The first network entity receives a reply in response to the redundancy agreement, and checks (310) the result of the reply. If the result is a SOAP fault or other rejection of the redundancy agreement, the Web service message is sent (312) in its original format to the destination, where it is processed (314). However, if the check (310) results in an acceptance of the redundancy agreement (or negotiations ensue (321) that result in a mutually acceptable agreement), a reduced message is formed (316) by the first network entity and sent (318) to the destination where it is processed (320). [0081] The processing (320) of the message may occur by converting the reduced message to a fully formed SOAP message which is then forwarded on to a SOAP processing module, or by processing only the data contained in the reduced message. In the former case, the module that reduces the message acts as a "front-end" to a standard SOAP processing stack. In the latter case, the reduced messaging functionality may be included in the SOAP processing stack, such that there is no need to convert the reduced message to a fully formed SOAP message. [0082] The network clients, servers and other data processing elements for providing Web service messaging systems in connection with the present invention may be any type of computing device capable of processing and communicating digital information. Referring now to FIG. 4, a representative system environment 400 is illustrated in which Web services may be employed according to embodiments of the present invention. In the representative system environment 400, Web services may be communicated using a reduced Web service message 402 and a redundancy agreement 403, which may take the form of a Web service message. [0083] The Web service messages 402, 403 may be communicated between target devices in any number of known manners. These manners include via a landline network(s) 404, which may include a Global Area Network (GAN) such as the Internet, one or more Wide Area Networks (WAN), Local Area Networks (LAN), and the like. Any computing device or other electronic device that supports Web services may be the target system that utilizes the present invention, such as servers 406, desktop computers 408 or workstations, laptop or other portable computers 410, or any other similar computing device capable of communicating via the network 404, as represented by generic device 412. [0084] The Web service messages 402, 403 may be communicated via one or more wireless networks 414, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Personal Communications Service (PCS), Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), or other mobile network transmission technology. Again, any mobile electronic device can communicate with Web service message 402, 403, such as laptop or other portable computers 416, mobile phones 418 A and other mobile communicators, Personal Digital Assistants (PDA) 420, or any other similar computing device capable of communicating via the wireless network 414, as represented by generic device 422. [0085] The Web service messages 402, 403 may be transferred between devices using short-range wireless technologies 424, such as Bluetooth, Wireless Local Area Network (WLAN), infrared (IR), etc. The Web service messages 402, 403 can also be distributed using direct wired connections, such as depicted by connection path 426. The present invention is applicable regardless of the manner in which data is provided or distributed between the target devices. [0086] An example of a target device that utilizes Web service messaging is illustrated as the mobile phone 418B. The mobile phone 418B includes, for example, a radio transceiver 434 and hardware (including the processor) coupled to an operating system (OS) 430. A Web services interface 432 may be implemented as firmware or as a program running on the OS 430. The Web services interface 432 may use any combination of Web service protocols known in the art, including SOAP, XML-Remote Procedure Call (XML-RPC) and others, and may be described and discovered using Universal Description, Discovery and Integration (UDDI), and Web Services Description Language (WSDL), among other possibilities. [0087] The Web services interface 432 communicates using a reduced Web service message 402 according to embodiments of the present invention. The reduced Web service message 402 is formed based on a redundancy agreement 403 maintained between the mobile phone 432 and another entity on the network. The redundancy agreement 403 may be used to convert between a standard Web service message and the reduced message 402. [0088] Although the Web service exchanges using redundancy agreements may be employed on any network arrangement, more particular arrangements are shown in FIGS. 5 and 6. In FIG. 5, a system 500 of directly communicating network entities utilizes redundancy agreements in accordance with embodiments of the present invention. The system includes a first network entity 502 and a second network entity 504 that are coupled via a network 506. The first and second network entities 502, 504 each include redundancy agreement modules 508, 510 that work in concert with Web services processing stacks 512, 514, respectively. The redundancy agreement modules 508, 510 and Web services processing stacks 512, 514 communicate over the network 506 through respective network interfaces 516 and 518. The network interfaces 516, 518 may include protocol stacks (e.g., TCP/IP, UDP/IP) and hardware drivers and devices (e.g., Ethernet, FDDI, etc.). [0089] The entities 502 and 504 include ability to communicate redundancy agreements 520 for the purposes of Web service communications using reduced messages 522. The redundancy agreement modules 508, 510 provides the capability to form redundancy agreements, control RAP message exchanges, maintain state of all current redundancy agreements, and use the redundancy agreements to form and/or interpret Web service messages. The modules 508, 510 may be separate add-ons to the respective Web services stacks 512, 514, and/or may be completely incorporated into the stacks 512, 514. [0090] Generally, the redundancy agreement modules 508, 510 can be configured to initiate and maintain redundancy agreements with any or all Web services communications between various network hosts. The redundancy agreement modules 508, 510 store data related to the redundancy agreements in storage arrangements 524, 526 of the respective entities 502, 504. It will be appreciated that the data may be host dependent. For example, redundancy agreements stored on the first network entity 502 for communications with the second network entity 504 are maintained separately from agreements with, for example, a third network entity 528. [0091] The arrangement shown in FIG. 5 assumes that each entity engaged in Web service communication has the necessary redundancy agreement logic (such as in the modules 508, 510). However, there may be situations where it is difficult or impractical to implement RAP into the Web services logic at the network endpoints. In such a situation, the advantages of using redundancy agreements can still be obtained by using intermediate network entities as shown in FIG. 6. [0092] In FIG. 6, an alternate system 600 of providing Web services using redundancy agreements is illustrated according to embodiments of the present invention. In this system 600, a first entity 602 and a second entity 604 may include standard Web service interfaces, 606 and 608, respectively. The source and destination entities 602, 604 can utilize existing Web service software modules, programming tools, and procedure calls. One or more intermediate nodes, as represented by intermediate nodes 610 and 612, may act as proxies or gateways for Web service communications using reduced messaging. The intermediate nodes 610, 612, typically include standard Web service interfaces, 614, and 616. The intermediate nodes 610, 612 communicate with respective entities 602, 604 using the standard Web services interfaces 614, 616, but the intermediate nodes 610, 612 can communicate with each other using the RAP interfaces 618, 620. This allows redundancy agreements to be used in a way that is transparent to end points such as entities 602, 604. [0093] A Web service message 630 sent from the first entity 602 is received at the Web service interface 614 of intermediate node 610. The intermediate node 610 translates this message 630 to a reduced message 632 based on a redundancy agreement 622 between the intermediate entities 610, 612. The reduced message 632 is sent from a reduced message interface 618 of intermediate node 610 to a reduced message interface 620 of intermediate node 612. Intermediate node 612 uses a compatible set of criteria based on the redundancy agreement 622 to form a reproduced message 634 from the reduced message 632. The reproduced message 634 is sent from the Web service interface 616 to the SOAP interface 608 of the second entity 604. Sending messages in the other direction, from entity 604 to entity 602, operates similarly, with the intermediate nodes 610, 612 forming reduced messages and/or reproduced messages as appropriate. [0094] In general, the system 600 shown in FIG. 6 allows a legacy Web service infrastructure to benefit from the use of redundancy agreements. The system 600 may also allow standard Web service message exchanges to occur directly between entities 602, 604, as represented by the path 636. The intermediate nodes 610, 612 may also be configured to handle only portion of standard Web service messaging (e.g., without forming reduced messages) between endpoints 602, 604, while other messages take the direct path 636 between entities 602, 604. [0095] The use of intermediary nodes 610, 612 is useful when a data path
638 between the gateway nodes 610, 612 includes a low-bandwidth connection. A more typical situation, however, is where the low-bandwidth connection exists at a network entry point, such as a mobile data client. This data client may be represented in FIG. 6 as a unit 640 that encompasses both the network entity 602 and the intermediate node 610. For example, if the unit 640 represents a mobile device, the intermediate node 610 could be implemented as a processing module within the mobile device. Such a processing module may be an extension of the SOAP protocol stack, or may be implemented as a separate process that interfaces with the stack. In such an arrangement, the reduced message interface 618 of the unit 640 communicates with the intermediate node 612. The intermediate node 612 may be located anywhere on the network, preferably where the connection 642 between the intermediate node 612 and entity 604 includes a high bandwidth connection. [0096] Hardware, firmware, software or a combination thereof may be used to perform the various messaging functions and operations described herein. The computing structure 700 of FIG. 7 is an example computing structure that can be used in connection with such a Web services messaging system. The example computing structure 700 suitable for performing the messaging activity in accordance with the present invention includes a computing arrangement 701. The computing arrangement 701 may act a server, client, gateway, proxy, router, or any other network entity used for processing and delivering Web service messages using redundancy agreements. [0097] The computing arrangement 701 includes a central processor (CPU)
702 coupled to random access memory (RAM) 704 and read-only memory (ROM) 706. The ROM 706 may also be other types of storage media to store programs, such as programmable ROM (PROM), erasable PROM (EPROM), etc. The processor 702 may communicate with other internal and external components through input/output (I/O) circuitry 708 and bussing 710, to provide control signals and the like. [0098] The memory of the computing arrangement 701 may be used to store processor executable instructions for carrying out various Web service related tasks. For example, processing of Web services messages and reduced messages, such as those exemplified in FIG. 3, may be performed by the computing arrangement 701 via a RAP processing module 738. The RAP module 738 may create and maintain redundancy agreements and messages related to those agreements. [0099] The RAP processing module 738 can provide Web services communications using reduced messages. For example, the RAP processing module 738 may translate reduced messages into fully formed Web services messages for further processing by the Web services modules. In another arrangement, the RAP processing module 738 may add logic to the Web services module 740 such that reduced messages and redundancy agreements are processed by different instructions than standard Web service messages. The RAP processing module 738 and Web services messaging module 740 can be integrated into a single module or included as separate modules. Generally, the modules 738, 740 work in concert to invoke remote Web services by sending reduced messages and/or process Web services requests invoked via reduced messages. [00100] External data storage devices, such as databases, used for accessing message reduction criteria, may be coupled to I/O circuitry 708 to facilitate messaging functions according to the present invention. Alternatively, such databases may be locally stored in the storage/memory of the computing arrangement 701, or otherwise accessible via a local network or networks having a more extensive reach such as the Internet 728. The processor 702 carries out a variety of functions as is known in the art, as dictated by software and/or firmware instructions. [00101] The computing arrangement 701 may also include one or more data storage devices, including hard and floppy disk drives 712, CD-ROM drives 714, and other hardware capable of reading and/or storing information such as DVD, etc. In one embodiment, software for carrying out the messaging operations in accordance with the present invention may be stored and distributed on a CD-ROM 716, diskette 718 or other form of media capable of portably storing information. These storage media may be inserted into, and read by, devices such as the CD-ROM drive 714, the disk drive 712, etc. The software may also be transmitted to computing arrangement 701 via data signals, such as being downloaded electronically via a network, such as the Internet 728. The computing arrangement 701 may be coupled to a display 720, which may be any type of known display or presentation screen, such as LCD displays, plasma display, cathode ray tubes (CRT), etc. A user-input interface 722 may be provided, including one or more user interface mechanisms such as a mouse, keyboard, microphone, touch pad, touch screen, voice-recognition system, etc. [00102] The computing arrangement 701 may be coupled to other computing devices, such as landline and or wireless terminals via a network, for Web service messaging. The server may be part of a larger network configuration as in a global area network (GAN) such as the Internet 728, which allows connections to the various landline and/or mobile devices, such as host 730. [00103] The computing arrangement 700 of FIG. 7 is provided as a representative example of a computing environment in which the principles of the present invention may be applied. From the description provided herein, those skilled in the art will appreciate that the present invention is equally applicable in a variety of other currently known and future mobile and landline computing environments. For example, desktop computing devices similarly include a processor, memory, a user interface, and data communication circuitry. Thus, the present invention is applicable in any known computing structure where data may be communicated via a network. [00104] Using the description provided herein, the invention may be implemented as a machine, process, or article of manufacture by using standard programming and/or engineering techniques to produce programming software, firmware, hardware or any combination thereof. Any resulting program(s), having computer- readable program code, may be embodied on one or more computer-usable media, such as disks, optical disks, removable memory devices, semiconductor memories such as RAM, ROM, PROMS, etc. [00105] Articles of manufacture encompassing code to carry out functions associated with the present invention are intended to encompass a computer program that exists permanently or temporarily on any computer-usable medium or in any transmitting medium that transmits such a program. Transmitting mediums include, but are not limited to, transmissions via wireless/radio wave communication networks, the Internet, intranets, telephone/modem-based network communication, hard-wired/cabled communication network, satellite communication, and other stationary or mobile network systems/communication links. From the description provided herein, those skilled in the art will be readily able to combine software created as described with appropriate general purpose or special purpose computer hardware to create a messaging system, apparatus, and method in accordance with the present invention. [00106] The foregoing description of the various embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. Thus, it is intended that the scope of the invention be limited not with this detailed description, but rather determined from the claims appended hereto.

Claims

WHAT IS CLAIMED IS: 1. A processor-implemented method for invoking a Web service of a network entity, comprising: sending a redundancy agreement message to the network entity, the redundancy agreement message describing a redundancy agreement for invoking the Web service using reduced messages; forming a reduced message based on the redundancy agreement and a non- redundant portion of a Web service message configured for invoking the Web service; sending the reduced message to the network entity; and invoking the Web service at the network entity based on the reduced message and the redundancy agreement.
2. The method according to Claim 1, wherein the Web service message comprises a SOAP message.
3. The method according to Claim 1, wherein the reduced message comprises a SOAP message.
4. The method according to Claim 1, wherein the redundancy agreement message comprises a SOAP message.
5. The method according to Claim 1, wherein the redundancy agreement message comprises a binary formatted message.
6. The method according to Claim 1, wherein the redundancy agreement comprises a mapping of identifiers to content strings, wherein the content strings are based on a non-redundant portion of the Web service message.
7. The method according to Claim 6, wherein the content strings are base64 encoded.
8. The method according to Claim 1, further comprising sending a redundancy agreement reply message from the network entity in response to the redundancy agreement message.
9. The method according to Claim 8, wherein the redundancy agreement reply message comprises a suggested modification to the redundancy agreement.
10. The method according to Claim 1, wherein the redundancy agreement message is included in a non-reduced Web service message.
11. The method according to Claim 10, wherein the redundancy agreement message is included in a message header of the non-reduced Web service message.
12. The method according to Claim 1, wherein invoking the Web service at the network entity based on the reduced message and the redundancy agreement comprises creating a template based on the redundancy agreement; and forming a replicated Web service message from the template by replacing portions of the template with selected portions of the reduced message.
13. The method according to Claim 12, wherein at least one of a) the selected portions of the reduced message and b) the portions of the template, comprise LISP encoded values.
14. The method according to Claim 12, wherein at least one of a) the selected portions of the reduced message and b) the portions of the template, comprise base64 encoded values.
15. The method according to Claim 12, wherein at least one of a) the selected portions of the reduced message and b) the portions of the template, comprise XML elements.
16. The method according to Claim 12, wherein the reduced message includes one or more XML processing instructions indicating the portions of the template to be replaced and the selected portions of the reduced message.
17. The method according to Claim 16, wherein the one or more XML processing instructions are base64 encoded.
18. The method according to Claim 1, further comprising determining a quality measurement based on sizes of the reduced message and the Web service message.
19. The method according to Claim 18, wherein the quality measurement is used to determine a form of the redundancy agreement.
20. The method according to Claim 18, wherein the quality measurement is used to determine whether to utilize the redundancy agreement.
21. A computing arrangement, comprising: a network interface; a memory capable of storing at least one of a redundancy agreement module and a Web services processing module; a processor coupled to the memory and the network interface and configured by redundancy agreement module to form redundancy agreement messages describing redundancy agreements for invoking Web services using reduced messages, the processor configured by the Web services module to send the redundancy agreement messages and the reduced messages via the network interface using a Web service protocol for purposes of invoking the Web service.
22. The computing arrangement according to Claim 21 , wherein the Web services processing module comprises a SOAP processing module.
23. The computing arrangement according to Claim 21 , wherein the reduced message comprises a SOAP message.
24. The computing arrangement according to Claim 21, wherein the redundancy agreement message comprises a SOAP message.
25. The computing arrangement according to Claim 21 , wherein the redundancy agreement message comprises a binary formatted message.
26. The computing arrangement according to Claim 21, wherein the redundancy agreement comprises a mapping of identifiers to content strings, wherein the content strings are based on a non-redundant portion of a Web service message configured for invoking the Web service.
27. The computing arrangement according to Claim 21 , wherein the processor is further configured to receive a redundancy agreement reply message in response to the redundancy agreement message.
28. The computing arrangement according to Claim 27, wherein the redundancy agreement reply message comprises a suggested modification to the redundancy agreement.
29. The computing arrangement according to Claim 21, wherein the redundancy agreement message is included in a non-reduced Web service message.
30. The computing arrangement according to Claim 21 , wherein the reduced message includes one or more XML processing instructions indicating a non- redundant portion of a Web service message configured for invoking the Web service.
31. The computing arrangement according to Claim 21 , wherein the processor is further configured by the redundancy agreement module to determining a quality measurement based on sizes of the reduced message and a Web service message configured for invoking the Web service.
32. The computing arrangement according to Claim 31 , wherein the quality measurement is used to determine whether to utilize the redundancy agreement.
33. The computing arrangement according to Claim 31 , wherein the quality measurement is used to determine a form of the redundancy agreement.
34. The computing arrangement according to Claim 21 , wherein the network interface comprises a wireless network interface.
35. The computing arrangement according to Claim 34, wherein the computing arrangement comprises a mobile terminal.
36. A messaging system, comprising: means for sending a redundancy agreement message to a network entity, the redundancy agreement message describing a redundancy agreement for invoking the Web service using reduced messages; means for forming a reduced message based on the redundancy agreement and a non-redundant portion of a Web service message configured for invoking the Web service; means for sending the reduced message to the network entity; and means for invoking the Web service at the network entity based on the reduced message and the redundancy agreement.
37. The messaging system according to Claim 36, further comprising means for determining a quality measurement based on the sizes of the reduced message and the Web service message.
38. A computer-readable medium having instructions stored thereon which are executable by a computing arrangement for performing steps comprising: sending a redundancy agreement message to a network entity for purposes of invoking a Web service, the redundancy agreement message describing a redundancy agreement for invoking the Web service using reduced messages; forming a reduced message based on the redundancy agreement and a non- redundant portion of a Web service message configured for invoking the Web service; sending the reduced message to the network entity; and invoking the Web service at the network entity based on the reduced message and the redundancy agreement.
39. The computer-readable medium according to Claim 38, wherein the redundancy agreement message comprises a SOAP message.
40. The computer-readable medium according to Claim 38, wherein the redundancy agreement message comprises a binary formatted message.
41. The computer-readable medium according to Claim 38, wherein the redundancy agreement comprises a mapping of identifiers to content strings, wherein the content strings based on a non-redundant portion of the Web service message configured for invoking the Web service.
42. The computer-readable medium according to Claim 38, further comprising sending a redundancy agreement reply message from the network entity in response to the redundancy agreement message.
43. The computer-readable medium according to Claim 42, wherein the redundancy agreement reply message comprises a suggested modification to the redundancy agreement.
44. The computer-readable medium according to Claim 38, wherein the redundancy agreement message is included in a non-reduced Web service message.
45. The computer-readable medium according to Claim 44, wherein the redundancy agreement message is included in a message header of the non-reduced Web service message.
46. The computer-readable medium according to Claim 38, wherein the reduced message includes one or more XML processing instructions indicating a non- redundant portion of the Web service message.
47. The computer-readable medium according to Claim 38, wherein the steps further comprise determining a quality measurement based on the sizes of the reduced message and the Web service message.
48. The computer-readable medium according to Claim 47, wherein the quality measurement is used in determining whether to form the redundancy agreement.
49. A computing arrangement configured to provide a Web service, comprising: means for receiving a redundancy agreement message from a network entity, the redundancy agreement message describing a redundancy agreement for invoking the Web service using reduced messages; means for receiving a reduced message based on the redundancy agreement and a non-redundant portion of a Web service message configured for invoking the Web service; and means for invoking the Web service based on the reduced message and the redundancy agreement.
50. The computing arrangement according to Claim 49, further comprising means for sending a reduced response message to the network entity in response to invocation of the Web service, the reduced response message based on a second redundancy agreement established between the computing arrangement and the network entity.
51. A computing arrangement configured to act as a proxy for supporting a Web service invocation, comprising: means for receiving a redundancy agreement message from a first Web service entity, the redundancy agreement message describing a redundancy agreement for supporting the Web service invocation using reduced messages; means for receiving a reduced message based on the redundancy agreement and a non-redundant portion of a Web service message configured to support the Web service invocation; means for converting the reduced message to a replica of the Web service message based on the reduced message and the redundancy agreement; and means for sending the replica of the Web service message to a second Web service entity in support of the Web service invocation.
52. The computing arrangement according to Claim 51, further comprising: means for receiving a Web service response message from the second Web service entity; means for sending to the first Web service entity a reduced response message, the reduced response message based on the Web service response message and a second redundancy agreement established between the computing arrangement and the first Web service entity.
PCT/IB2005/000668 2004-04-07 2005-03-14 System, apparatus, and method for using reduced web service messages WO2005099217A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP05708753A EP1741257B1 (en) 2004-04-07 2005-03-14 System, apparatus, and method for using reduced web service messages
AT05708753T ATE465586T1 (en) 2004-04-07 2005-03-14 SYSTEM, APPARATUS AND METHOD FOR USING REDUCED WEB SERVICE MESSAGES
DE602005020764T DE602005020764D1 (en) 2004-04-07 2005-03-14 SYSTEM, DEVICE AND METHOD FOR USING REDUCED WEB SERVICE NEWS

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/819,711 2004-04-07
US10/819,711 US7509387B2 (en) 2004-04-07 2004-04-07 System, apparatus, and method for using reduced Web service messages

Publications (1)

Publication Number Publication Date
WO2005099217A1 true WO2005099217A1 (en) 2005-10-20

Family

ID=35061825

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2005/000668 WO2005099217A1 (en) 2004-04-07 2005-03-14 System, apparatus, and method for using reduced web service messages

Country Status (5)

Country Link
US (1) US7509387B2 (en)
EP (1) EP1741257B1 (en)
AT (1) ATE465586T1 (en)
DE (1) DE602005020764D1 (en)
WO (1) WO2005099217A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8019884B2 (en) 2007-12-27 2011-09-13 International Business Machines Corporation Proxy content for submitting web service data in the user's security context

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7904595B2 (en) 2001-01-18 2011-03-08 Sdl International America Incorporated Globalization management system and method therefor
US8195789B2 (en) * 2005-04-20 2012-06-05 Oracle International Corporation System, apparatus and method for characterizing messages to discover dependencies of services in service-oriented architectures
US7650609B2 (en) * 2005-07-05 2010-01-19 Sap Ag Multi-environment document management system access
EP1955281A4 (en) 2005-12-01 2009-03-11 Firestar Software Inc System and method for exchanging information among exchange applications
US7808975B2 (en) * 2005-12-05 2010-10-05 International Business Machines Corporation System and method for history driven optimization of web services communication
US20070288254A1 (en) * 2006-05-08 2007-12-13 Firestar Software, Inc. System and method for exchanging transaction information using images
US7746250B2 (en) * 2008-01-31 2010-06-29 Microsoft Corporation Message encoding/decoding using templated parameters
US8285790B2 (en) * 2008-09-26 2012-10-09 International Business Machines Corporation Virtual universe avatar activities review
US9569285B2 (en) * 2010-02-12 2017-02-14 International Business Machines Corporation Method and system for message handling
US8880725B2 (en) * 2010-05-26 2014-11-04 Microsoft Corporation Continuous replication for session initiation protocol based communication systems
CN102098331B (en) * 2010-12-29 2013-06-19 北京锐安科技有限公司 Method and system for reducing WEB type application contents
US10657540B2 (en) 2011-01-29 2020-05-19 Sdl Netherlands B.V. Systems, methods, and media for web content management
US9547626B2 (en) * 2011-01-29 2017-01-17 Sdl Plc Systems, methods, and media for managing ambient adaptability of web applications and web services
US10580015B2 (en) 2011-02-25 2020-03-03 Sdl Netherlands B.V. Systems, methods, and media for executing and optimizing online marketing initiatives
AU2012297524B2 (en) * 2011-08-16 2017-07-20 Destiny Software Productions Inc. Script-based video rendering
US9430449B2 (en) 2012-03-30 2016-08-30 Sdl Plc Systems, methods, and media for managing editable previews of webpages
US9773270B2 (en) 2012-05-11 2017-09-26 Fredhopper B.V. Method and system for recommending products based on a ranking cocktail
US10452740B2 (en) 2012-09-14 2019-10-22 Sdl Netherlands B.V. External content libraries
US11386186B2 (en) 2012-09-14 2022-07-12 Sdl Netherlands B.V. External content library connector systems and methods
US11308528B2 (en) 2012-09-14 2022-04-19 Sdl Netherlands B.V. Blueprinting of multimedia assets
US9215075B1 (en) 2013-03-15 2015-12-15 Poltorak Technologies Llc System and method for secure relayed communications from an implantable medical device
US10733237B2 (en) 2015-09-22 2020-08-04 International Business Machines Corporation Creating data objects to separately store common data included in documents
US10614167B2 (en) 2015-10-30 2020-04-07 Sdl Plc Translation review workflow systems and methods
US10467275B2 (en) 2016-12-09 2019-11-05 International Business Machines Corporation Storage efficiency

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030084177A1 (en) * 2001-10-26 2003-05-01 Nokia Corporation Mobile client provisioning web service
US20030133554A1 (en) * 2002-01-11 2003-07-17 Nokia Corporation System and method for facilitating access to network based services
US20040045005A1 (en) * 2002-02-22 2004-03-04 Todd Karakashian Web services programming and deployment
US20040045004A1 (en) * 2002-08-29 2004-03-04 Manoj Cheenath System for runtime web service to java translation
US20050060431A1 (en) * 2003-09-12 2005-03-17 Lewontin Stephen Paul System, apparatus, and method for using reduced web service messages
US20050071423A1 (en) * 2003-09-26 2005-03-31 Jaakko Rajaniemi System, apparatus, and method for providing Web services on mobile devices

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6772413B2 (en) 1999-12-21 2004-08-03 Datapower Technology, Inc. Method and apparatus of data exchange using runtime code generator and translator
US6606525B1 (en) 1999-12-27 2003-08-12 Motorola, Inc. System and method of merging static data in web pages
US6694336B1 (en) * 2000-01-25 2004-02-17 Fusionone, Inc. Data transfer and synchronization system
US20040049737A1 (en) * 2000-04-26 2004-03-11 Novarra, Inc. System and method for displaying information content with selective horizontal scrolling
JP4774145B2 (en) * 2000-11-24 2011-09-14 富士通株式会社 Structured document compression apparatus, structured document restoration apparatus, and structured document processing system
CA2406079C (en) 2002-09-30 2010-03-30 Ibm Canada Limited-Ibm Canada Limitee System and method for synchronizing data repositories
US20040268238A1 (en) * 2003-06-30 2004-12-30 Peiya Liu Systems and methods for processing documents using an XML-based process flow description language

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030084177A1 (en) * 2001-10-26 2003-05-01 Nokia Corporation Mobile client provisioning web service
US20030133554A1 (en) * 2002-01-11 2003-07-17 Nokia Corporation System and method for facilitating access to network based services
US20040045005A1 (en) * 2002-02-22 2004-03-04 Todd Karakashian Web services programming and deployment
US20040045004A1 (en) * 2002-08-29 2004-03-04 Manoj Cheenath System for runtime web service to java translation
US20050060431A1 (en) * 2003-09-12 2005-03-17 Lewontin Stephen Paul System, apparatus, and method for using reduced web service messages
US20050071423A1 (en) * 2003-09-26 2005-03-31 Jaakko Rajaniemi System, apparatus, and method for providing Web services on mobile devices

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8019884B2 (en) 2007-12-27 2011-09-13 International Business Machines Corporation Proxy content for submitting web service data in the user's security context

Also Published As

Publication number Publication date
ATE465586T1 (en) 2010-05-15
US7509387B2 (en) 2009-03-24
DE602005020764D1 (en) 2010-06-02
US20050228865A1 (en) 2005-10-13
EP1741257B1 (en) 2010-04-21
EP1741257A1 (en) 2007-01-10

Similar Documents

Publication Publication Date Title
EP1741257B1 (en) System, apparatus, and method for using reduced web service messages
CN101341724B (en) System and method for history driven optimization of web services communication
US8151003B2 (en) System and method for routing data by a server
US7539734B2 (en) Systems for dynamic inter-operability of nodes in service grids
US8424020B2 (en) Annotating portions of a message with state properties
CA2556862C (en) System and method for communicating asynchronously with web services using message set definitions
US8527577B2 (en) System and method for configuration-driven deployment
US20070011126A1 (en) Service-oriented architecture
US7475145B2 (en) Dynamic invocation of web services
US20050050228A1 (en) Method and apparatus for the use of dynamic XML message formats with web services
US20050060431A1 (en) System, apparatus, and method for using reduced web service messages
US20040194105A1 (en) System and method of compact messaging in network communications
Lund et al. Using web services to realize service oriented architecture in military communication networks
US20040215830A1 (en) System and method for compression of wireless applications expressed in a structured definition language
US7853695B2 (en) Using expressive session information to represent communication sessions in a distributed system
AU2005201783B2 (en) Computer system and method for providing a failure resistant data processing service
US20200162410A1 (en) Management of messaging in heterogeneous iot / iiot messaging environments
Johnsen Pervasive web services discovery and invocation in military networks
Zaplata et al. Realizing mobile web services for dynamic applications
US11855902B2 (en) Device and method for splitting data for transmission
Cinque et al. ESPERANTO: a middleware platform to achieve interoperability in nomadic computing domains
Oh et al. Optimizing web service messaging performance using a context store for static data
Athanasopoulos et al. Unified description and discovery of P2P services.
Oh et al. Architecture for high-performance web service communications using an information service.
Wesenberg REST versus SOAP as Architectural Style for Web Services

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWE Wipo information: entry into national phase

Ref document number: 2005708753

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2005708753

Country of ref document: EP