1. The Field of the Invention
The present invention generally relates to Reliable Messaging protocols for Web Services. More specifically, the present invention provides for a mechanism that leverages characteristics of Reliable Messaging protocols for Web Services (RM-WS) for verifying and maintaining connection liveliness in a sequence session.
2. Background and Related Art
Computer networks have enhanced our ability to communicate and access information by allowing one computer or device to communicate over a network with another computing system using electronic messages. When transferring an electronic message between computing systems, the electronic message will often pass through a protocol stack that performs operations on the data within the electronic message (e.g., parsing, routing, flow control, etc.). The Open System Interconnect (OSI) model is an example of a network framework for implementing a protocol stack.
The OSI model breaks down the operations for transferring an electronic message into seven distinct layers, each designated to perform certain operations in the data transfer process. While protocol stacks can potentially implement each of the layers, many protocol stacks implement only selective layers for use in transferring data across a network. When data is transmitted from a computing system, it originates at the application layer and is passed down to intermediate lower layers and then onto a network. When data is received from a network it enters the physical layer and is passed up to the higher intermediate layers and then is eventually received at that application layer. The application layer—the upper most layer—is responsible for supporting application and end-user processing. Further, within the application layer there may reside several other layers (e.g., the Simple Open Access Protocol (SOAP) layer). Another layer incorporated by most protocol stacks is the transport layer. An example of a transport layer is the Transmission Control Protocol (TCP).
Web Services (WS) have been a driving force in advancing communications between computing systems and are turning the way we build and use software inside-out. Web Services let applications share data and—more powerfully—invoke capabilities from other applications without regard to how these applications where built; what operating systems or platform they run on; and what devices are used to access them. Web Services are invoked over the Internet by means of industry-standard protocols including SOAP, XML (extensible Markup Language), UDDI (Universal, Description, Discovery and Integration), WSDL (Web Service Description Language), etc. Although Web Services remain independent of each other, they can loosely link themselves into a collaborating group that performs a particular task.
Current WS technologies offer direct SOAP-message communication between an initiator (e.g., a client) and an acceptor (e.g., a service). In the common bi-directional messaging case, a SOAP request message is sent from the initiator to the acceptor and a SOAP reply message is sent in response thereto. Another communication variant between endpoints is unidirectional message exchange, where the initiator sends a message to the acceptor with no response.
A key benefit of the emerging WS architecture is the ability to deliver integrated, interoperable solutions. Because, however, Web Services provide various services from different business, originations, and other service providers via unreliable communication channels such as the Internet, reliability of WS becomes an increasing important factor. Reliability of WS is impacted by several factors including but not limited to, the reliability of the Web Service end points; reliability characteristics of the communication channel over which the Web Services are accessed; performance and fault-tolerance characteristics; and the extent to which Web Services can handle concurrent client access.
There have been attempts at accomplishing reliable messaging of Web Services by choosing a reliable transport protocol over which the messages (e.g., SOAP messages) are exchanged between endpoints. For example, a reliable messaging transport such as message-queues can be used to deliver messages reliably between initiators and acceptors. Messing-queuing communication technologies enable applications on different systems to communicate with each other by sending messages to queues and reading messages from queues that are persisted across failures for reliability.
Although queuing systems offer a transport that can be used to carry SOAP messages reliably, there are several drawbacks to such systems. For instance, these systems offer solutions for an asynchronous operation where the requests (and possibly their responses) are transferred and processed with isolation. Accordingly, these systems are typically heavyweight in terms of resources; involving multiple intermediaries with durable transacted message stores and with considerably more complexity in deployment, programming model and management. All of this is unnecessary for reliable direct communication, and detracts from the goal of minimizing latency. Further, the program model does not directly support request-response style programming or sessions. Accordingly, the queued communication model is different from the current “interactive” Web Services model, and does not address critical “connected” scenarios and “interactive” applications. For example, it is not well suited for cases where a response is expected in a timely manner, or for cases where distributed-transaction-context need to be shared between initiator and acceptor.
There have also been attempts at defining reliable transfer layers over fundamentally unreliable transport protocols, e.g., reliable HTTP or HTTPR. A common problem, however, that plagues this solution—as well as the queuing solution—is that reliable messaging can be achieved only if the specific reliable transport protocol is used for communication between the initiator and the acceptor. The fundamental nature of Web Services calls for independence from specific vender platform, implementation languages and specific transport protocols. In a generic case, an initiator may not be able to transmit a message directly to an acceptor using a particular protocol (e.g., acceptor does not support the protocol) or the message may need to pass through multiple hops after leaving the sending node prior to arriving at that destination node. Depending on the nature of the connectivity between the two nodes involved in a particular hop, a suitable transport protocol that does not offer reliable messaging characteristics may have to be chosen.
Intermediaries may also exist at different levels in the protocol stack; and therefore not offer full end-to-end reliability. For example, transport protocols may offer reliability across lower level intermediaries (e.g., IP level intermediaries—e.g., IP routers). The transport protocol may end, however, at a SOAP intermediary or application layer. Accordingly, the transport protocol may not be able to offer reliability across that intermediary, i.e., no end-to-end reliability across the application layer.
More recently, various Reliable Messaging protocols for Web Services (hereinafter referred to as “RM-WS protocols”), e.g., WS-ReliableMessaging, offer solutions to the above identified-deficiencies of current reliable messaging systems. These protocols are transport agnostic connected protocols that allow messages to be delivered reliably between end-point applications in presences of software component, system or network failures. Accordingly, RM-WS protocols offer solutions for reliable, end-to-end, session-oriented communication between an initiator and an acceptor.
These RM-WS protocols are akin to TCP in that TCP offers reliable, exactly-once, in-order delivery of a stream of bytes from a TCP sender to TCP receiver across Internet Protocol (IP) routers and multiple networks. Reliable Messaging protocols for WS offer the same and more for messages (note: the unit of transfer is a message, not a byte or a collection of bytes as is the case for TCP wherein the size of the bytes is determined by the available payload space in the IP packet) across multiple intermediaries (including SOAP level intermediaries), transports and connections. Although TCP and RM-WS protocols are both “reliable” protocols, because RM-WS resides at the application or SOAP layer in the OSI model, RM-WS protocols provide for reliable messaging regardless of the transport protocol used to transfer the data. Accordingly, RM-WS protocols are not tied to a particular transport or other protocol used to transfer message between endpoints.
Although a few RM-WS protocols have been around for some time there are still several drawbacks and deficiencies of these protocol specs. For example, these RM-WS protocols do not provide a way for verifying the connectivity of an established sequence session. Further, the specifications do not provide for a way to maintain the liveliness of a connection and/or to extend the sequence session in the absence of an exchange of messages over an inactivity timeout period. Accordingly, there exists a need to verify and maintain connection liveliness for systems that use a RM-WS protocol.
USPTO Backgrounds
USPTO Backgrounds