The field of invention relates generally to the software arts, and, more specifically, to message processing systems.
The term “web services” is understood to mean a standards-based, service oriented architecture (SOA) than can be used to engage in business relationships in a partially or wholly automated fashion over a communications network.
In a basic web services model a service provider and a service consumer exchange messages over a communications network. A service consumer is understood to be an entity that seeks and uses a particular web service through a network. A service provider is the provider of one or more web services that can be accessed over the network.
According to a widely adopted approach, with respect to the actual communication that occurs between the service consumer and the service provider, such communication is implemented through an exchange of Simple Object Access Protocol (SOAP) text messages written in eXtensible Markup Language (XML). A SOAP message is viewed as being contained within an envelope that further contains a header and a body. As the SOAP protocol is transport-independent a number of protocols may be used to exchange SOAP messages, such as HTTP, HTTPS, SMTP, POP3, and FTP. For a particular web service, the header is typically used to pass “control” information associated with the consumer's web service engagement with the web service provider (e.g., information used for performing encryption/decryption and/or signature checking, information used to ensure proper ordering of SOAP messages, information that identifies the ultimate destination of the SOAP message, etc.). The body is used to pass business data.
In basic cases where a service provider receives a SOAP message sent by a service consumer, or, where a service consumer receives a SOAP message sent by a service provider, the body of the SOAP message essentially represents the purpose of the communication between the service provider and service consumer. For instance, the body may contain a request to perform a specific method and any input parameters that are both needed by the method and determined by the service requester. A web service's “endpoint” is essentially the portion of the service provider's software that is responsible for comprehending the received message's body and taking appropriate action in response (e.g., performing some act and then generating the body of a “response” message that is to be sent to the sender of the message). Thus, a web service's substantive processes (i.e., those relating to the body of its message) are essentially defined by its endpoint's methods.
The web services architecture also supports “extensions” to the SOAP messaging format that are available if desired, but, are not required to be SOAP compatible. For instance, a “WS-Security” extension has been defined that specifies information to be contained within a SOAP message header if encryption/decryption and/or authentication procedures are to be performed upon a SOAP message; a “WS-Addressing” extension has been defined that specifies information to be contained within a SOAP header that describes the destination of the SOAP message in a transport independent fashion.
Thus, in order to effect a particular web services business relationship, those SOAP extensions deemed appropriate for the relationship are effectively implemented into the procedures of the relationship by enhancing the SOAP message header with the corresponding information of each appropriate extension, and, any other SOAP extensions that are not deemed appropriate may simply be ignored.
To support necessary extensions, the web services architecture uses the so-called protocol stack, wherein each extension is a protocol that performs some desired processing. The protocol stack corresponds to the program code used to: 1) process an object-oriented representation of the received message's header information; and, 2) generate an object-oriented representation of the header information for the response message. Different combinations of protocols are used to implement customized SOAP message control treatment on a per web service basis. For instance, if a first web service requires some kind of security operation but does not require any comprehension/manipulation of a SOAP message header by the web service's endpoint, the protocol stack for the first web service would include the WS-Security protocol but not the Headers protocol.
When applications engage into communication, this communication may fail due to a number of reasons. For example, a communications network may experience downtime, servers may crash, or there may be power outage. The problems that occur in the process of communication between two or more applications exist when applications use messages to communicate as well. To ensure that communication between applications proceeds smoothly and completely, it is desired that a way to ensure message delivery is implemented.
A generic way to track and ensure message delivery in prior art frameworks is for communicating entities to confirm receipt of data. For example, a source application initiates communication and transmits data over a communications network to a destination application. Upon receipt of the sent data, the destination application will in turn initiate communication with the source application. The destination application sends a receipt for the received data, that is, acknowledges the receipt of data. With such a confirmation receipt the source application deems the communication successful and completes the communication cycle.
A method and system to reliably exchange messages over a communications network is described. Using the described method, entities engage in communication using messages such as web services messages and track message receipt using an instance of a reliable messaging protocol. Further, entities use a messaging system independent from a web services runtime environment to be able to achieve additional delivery assurance options.
A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:
A message processing system (hereinafter referred to as “web services framework”, “WSF”, or “web services runtime environment”) extends the protocol stack used to process messages with a web services Reliable Messaging (hereinafter referred to as “WS-RM”) protocol. The WS-RM, together with an independent Messaging System (hereinafter referred to as “MS”) provides additional functionality to the WSF. With this enhancement of the WSF and the message handling process, the improved WSF is able to provide a number of benefits, such as ensuring message delivery, providing delivery assurance options, tracking messages, ordering messages, and so on.
The prior art WSF processes messages in the same way, regardless of the location of the processing. This means that the prior art WSF does not distinguish between messages processed on the web services consumer (hereinafter referred to as “Client”) side and messages processed on the web services provider (hereinafter referred to as “Server”) side. In one embodiment of the invention, an improved WSF processes messages differently on the Client and on the Server side. Thus, the WSF on the Client and Server sides is able to differentiate between the specific requirements of message processing depending on the location where the processing takes place.
When an embodiment of the invention processes SOAP messages, it invokes WS-RM on each SOAP request, response, and fault message. The respective interfaces provide methods for handling each message type. To process messages, the WSF creates a configuration context object that includes the SOAP message. This is needed because the WSF does not directly process SOAP messages in the XML format they are received in. The WSF processes object-oriented representations of SOAP messages and also passes administrative information in an object-oriented representation. The administrative information may include instructions for protocols to perform a task, acknowledgements for events, and so on. In this sense, the configuration context is a placeholder for administrative and business data and is the entity that the WSF processes using the protocol stack. Thus, both on the Client and Server sides, each message processing sequence starts with creating a configuration context object, serializing business data (data from applications or data received in the form of a SOAP message), and including the business data in the configuration context object. Moreover, both on the Client and Server sides, the entities that participate in message processing manipulate the configuration context object as necessary to perform the requested communication.
As noted above, improvements over the prior art WSF are achieved with the extension of the protocol stack to include a WS-RM Protocol. Referring to
However, business scenarios may need additional options beside a simple notification of success or failure of communication. Using the MS, the WS-RM extends processing with additional services and is able to request specific options for message delivery and track how messages are delivered to their intended destinations. Referring to
Referring to
With the processing performed by the WS-RM and the MS, an improved WSF is able to serve a number of business scenarios. For example, in a complex communication between two applications over a communications network, in the event of system downtime, the MS is able to recreate the state of the communication from the stored persistent state and correctly schedule remaining parts of the communication. Also, in a complex scenario, as numerous messages are exchanged, it may be required that messages are monitored for performance benchmarking and optimization. Further still, communication over a network may involve a plurality of stakeholders and entities exchanging messages and in such cases the MS can analyze the required order of messages and queue them accordingly.
As the processing of a SOAP message in a WSF is different on the Client and Server sides, the following paragraphs outline the specifics of processing on both sides. Referring to
In the embodiment of the invention discussed above, the Client communicates with the Server via outbound messages only, using handleRequest( ) method calls. However, it is conceivable that in other embodiments of the invention the Client may handle more than one WS-RM sequence for SOAP requests simultaneously. In contrast to the outbound processing discussed above, here the Client processes the message invoking instances of the protocols in reverse order using handleResponse( ) method calls. After all needed protocols have processed the message, the Client deserializes the SOAP message and builds a result for the application that the message is directed to, as shown in
Referring to
After the destination application performs the functions it was requested to do in the request SOAP message, it sends a response. Thus, as shown in
Elements of embodiments of the invention may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cares, propagation media or other type of machine-readable media suitable for storing electronic instructions. For example, embodiments of the invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
It should be appreciated that reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment” or “one embodiment” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the invention.
In the foregoing specification, the invention has been described with reference to the specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.