Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

Embodiments of the present invention enable related parties to setup
asynchronous messaging exchanges between Web services based on Web
service addressing. All the callback address lookup, population and setup
can be performed automatically by the service provider at the
infrastructure level transparent to the user and only the
service/contract itself need to be defined. This description is not
intended to be a complete description of, or limit the scope of, the
invention. Other features, aspects, and objects of the invention can be
obtained from a review of the specification, the figures, and the claims.

Claims:

1. A system to provide callbacks via Web service addressing, comprising:
a client operable to: implement a contract for a Web service by compiling
a software component in accordance with the contract; submit a service
request to a service provider for the Web service via Web service
addressing; and accept a response from the Web service; and said service
provider operable to: define the contract for the Web service; process
the service request from the client; obtain and/or initialize address of
the client from the service request; populate the address of the client
to a callback stub; and invoke the callback stub when the response from
the Web service is available.

2. The system according to claim 1, wherein: the Web service addressing
can be WS-Addressing.

3. The system according to claim 1, wherein: the client is a Web service.

4. The system according to claim 1, wherein: the service provider is
operable to extract the address of the client from the header of the
service request.

5. The system according to claim 1, wherein: the Web service is
asynchronous.

6. The system according to claim 5, wherein: the service provider is
operable to wait for the response from the Web service becomes available
before invoking the callback stub.

7. The system according to claim 5, wherein: the callback stub can be
reused over time once initialized.

8. The system according to claim 1, wherein: the software component is a
stub.

9. The system according to claim 8, wherein: the stub can be included as
a parameter in the service request under a non-conversational scenario or
kept as part of a conversational state on the service provider under a
conversational scenario.

10. A method to provide callbacks via Web service addressing, comprising:
defining a contract for a Web service; implementing the contract by
compiling a software component in accordance with the contract;
submitting a service request from a client to a service provider for the
Web service via Web service addressing; processing the service request to
obtain and/or initialize address of the client; populating the address of
the client to a callback stub; and invoking the callback method when the
response from the Web service is available.

11. The method according to claim 10, further comprising: extracting the
address of the client from the header of the service request.

12. The method according to claim 10, wherein: the Web service is
asynchronous.

13. The system according to claim 12, further comprising: waiting for the
response from the Web service becomes available before invoking the
callback stub.

14. The system according to claim 12, further comprising: Reusing the
callback stub over time once initialized.

15. The method according to claim 10, wherein: the software component is
a stub.

16. The method according to claim 15, further comprising: including the
stub as a parameter in the service request under a non-conversational
scenario or keeping it as part of a conversational state on the service
provider under a conversational scenario.

17. A machine readable medium having instructions stored thereon that
when executed cause a system to: define a contract for a Web service;
implement the contract by compiling a software component in accordance
with the contract; submit a service request from a client to a service
provider for the Web service via Web service addressing; process the
service request to obtain and/or initialize address of the client;
populate the address of the client to a callback method; and invoke the
callback method when the response from the Web service is available.

18. A system to provide callbacks via Web service addressing, comprising:
means for defining a contract for a Web service; means for implementing
the contract by compiling a software component in accordance with the
contract; means for submitting a service request from a client to a
service provider for the Web service via Web service addressing; means
for processing the service request to obtain and/or initialize address of
the client; means for populating the address of the client to a callback
method; and means for invoking the callback method when the response from
the Web service is available.

Description:

CLAIM TO PRIORITY

[0001] This application is a continuation of U.S. patent application Ser.
No. 11/329,898, filed Jan. 11, 2006, which is included herein by
reference in its entirety.

Cross-Reference to Related Applications

[0002] This application is related to the following applications which are
hereby incorporated by reference in their entireties:

[0003] U.S. patent application Ser. No. 11/330,308, filed Jan. 11, 2006,
entitled SYSTEM AND METHOD FOR CALLBACKS BASED ON WEB SERVICE ADDRESSING
by Lei Jun and Brian Zotter.

[0005] A portion of the disclosure of this patent document contains
material which is subject to copyright protection. The copyright owner
has no objection to the facsimile reproduction by anyone of the patent
document or the patent disclosure, as it appears in the Patent and
Trademark Office patent file or records, but otherwise reserves all
copyright rights whatsoever.

INCORPORATION BY REFERENCE

[0006] This application is related to the following publication which is
hereby incorporated by reference in its entirety:

[0008] This invention relates to the field of conversation between clients
and a Web service provider.

BACKGROUND

[0009] Web service addressing, such as WS-Addressing for a non-limiting
example, specifies how to identify address on the Web. When a client
starts a service request to a Web service provider, the service provider
may assign the client a case number. In the future, the client needs to
include that case number for any communication with the service provider
and it will be able to look up the case associated with the client. Web
service addressing provides a way for the service provider to inform the
client about the case number that should be included in every future
communications.

[0010] Web service addressing can define two interoperable constructs that
convey information typically provided by transport protocols and
messaging systems. These constructs normalize this underlying information
into a uniform format that can be processed independently of transport or
application. These two constructs are endpoint (client or service
provider) references (EPRs) and message information headers. A Web
service endpoint (i.e., service provider) is a referenceable entity,
processor, or resource where Web service messages can be targeted.
Endpoint references convey the information needed to identify/reference a
Web service endpoint, and may be used in several different ways: endpoint
references are suitable for conveying the information needed to access a
Web service endpoint, but are also used to provide addresses for
individual messages sent to and from Web services. To deal with this last
usage case, Web service addressing may also define a family of message
information headers that allows uniform addressing of messages
independent of underlying transport. These message information headers
convey end-to-end message characteristics including addresses for source
and destination endpoints as well as message identity. Both of these
constructs are designed to be extensible and re-usable so that other
specifications can build on and leverage endpoint references and message
information headers. Some noticeable applications of Web service
addressing can include but are limited to: conversation, callback, and
asynchronous request response, all discussed in the following context.

BRIEF DESCRIPTION OF THE FIGURES

[0011]FIG. 1 is an illustration of an exemplary conversation framework
based on Web service addressing in one embodiment of the present
invention.

[0012]FIG. 2 is a flow chart illustrating an exemplary process of
conversational Web service based on Web service addressing in one
embodiment of the present invention.

[0013]FIG. 3 illustrates an exemplary state transition diagram for
conversational Web service in accordance with one embodiment of the
present invention.

[0014]FIG. 4 is an illustration of an exemplary conversation framework
using an intermediary Web service in one embodiment of the present
invention.

[0015]FIG. 5 is an illustration of an exemplary callback framework based
on Web service addressing in one embodiment of the present invention.

[0016]FIG. 6 is a flow chart illustrating an exemplary callback process
based on Web service addressing in one embodiment of the present
invention.

[0017] FIGS. 7(a) and 7(b) are illustrations of an exemplary asynchronous
request response framework in one embodiment of the present invention.

[0018] FIG. 8 is a flow chart illustrating an exemplary callback process
based on Web service addressing in one embodiment of the present
invention.

[0019] FIGS. 9(a) and 9(b) are illustrations of an exemplary asynchronous
request response implementation in one embodiment of the present
invention.

DETAILED DESCRIPTION

[0020] The invention is illustrated by way of example and not by way of
limitation in the figures of the accompanying drawings in which like
references indicate similar elements. It should be noted that references
to "an" or "one" or "some" embodiment(s) in this disclosure are not
necessarily to the same embodiment, and such references mean at least
one.

Conversation

[0021] A conversation allows a client to have a stateful interaction with
a (conversational) Web service. It keeps business states of the
conversation in persistence storage, such as a hard disk, and allows
multiple parties to access those states over a long period of time.
Different from sessions, which are transient, associated with a specific
client (to avoid re-computing its data repeatedly), and internal to the
server (service provider), conversations are associated with a business
process that can be contacted by multiple partners and persistent (and
typically long-lived, requiring human interaction). They may also have a
public contract and a strongly defined life cycles.

[0022] Conversations require a programming model for accessing
conversation state and a mechanism for marking a service as
conversational, determining when to start, continue, and terminate a
conversation, correlating an incoming message with a conversation,
persisting and restoring conversation state. They can be characterized by
at least one of the following properties:

[0023] 1. They are long-running. Conversations typically interact with a
variety of outside sources, many of which can take a long time to
respond. For a non-limiting example, fulfilling a purchase order (PO)
typically requires human approval, which could take several days to
obtain. Similarly, fulfilling a quote request might require an inventory
and price update from an outside supplier's systems, which could run in
batch. As a result, conversations often last for extremely long periods
of time--days, weeks, or months.

[0024] 2. They are typically asynchronous. A conversation acts as the
mediator between a number of different systems, many of which are
high-latency, such as batch environments, queues, humans. The typical
flow for a conversation is to receive an incoming message, do some
synchronous processing, post a message to another system, and go back to
sleep until the response arrives.

[0025] 3. They are persistent. Since conversation state is business state,
it absolutely must be persisted, although caching would help since many
times the conversation state just needs to be examined, not updated.

[0026] 4. They can be entered from multiple paths. Conversations must
interact with a variety of back-end systems using different transports,
and must expect to receive callback messages over several different
communication paths. For a non-limiting example, a single conversation
might need to receive callbacks from Web service partners via HTTP, wait
for incoming messages from a messaging service queue, or receive
asynchronous notifications from a connector. It must be possible to route
messages to the correct conversational instance regardless of the
transport and communications protocol.

[0027] 5. They are uniquely identifiable. Every conversation represents a
distinct transaction that is uniquely identifiable. In many cases, the
identity of the conversation can be derived from the identity of a
business entity involved in the conversation. For a non-limiting example,
a purchase order might uniquely identify a PO conversation.

[0028] 6. They have a well-defined life cycle. A conversation is a lot
like a state machine, with well-defined start, intermediate, and
termination nodes. The life cycle might be loosely defined (for a
non-limiting example, it is done when the message is received by the
client) or adhere to a strict state machine.

[0029] Various embodiments of the present invention introduces mechanisms
that allow conversational Web services to have long running business
transactions between multiple parties with persistent states. Web service
addressing is used to exchange conversational identifiers between the
client(s) who requests the service and the server who provides it.
Several new persistence formats and stores are supported. In particular,
conversation state can be shred down to XML or serialized objects in a
transactional file store or in a cluster-wide in-memory object.

[0030] The following is an exemplary conversation consisting of three
parties--an agent purchasing goods from a manufacturer, the manufacturer
selling the goods, and one or more warehouses containing the goods. The
conversation begins with the purchasing agent submitting a purchase order
to the manufacturer. The purchasing agent includes a "ReplyTo" address so
that notifications about the purchase order can be directed to the proper
location via Web service addressing. Upon receipt of the purchase order,
the manufacturer updates a few back-end systems then goes to sleep,
waiting for the purchase order to be approved. It may possibly send out
an e-mail containing a link to an approval screen running in portal. The
user may click on the link to review the purchase order displayed in the
portal, and then clicks on another button to approve the purchase order.
The approval notification awakens the conversation, which sends a
shipment notice to a warehouse containing the goods. The warehouse sets
the shipment in motion, and responds with a shipment confirmation.
Finally, the conversation sends a delivery notice back to the purchasing
agent, along with a request for payment via Web service addressing.

[0031]FIG. 1 is an illustration of an exemplary conversation framework
100 based on Web service addressing in one embodiment of the present
invention. Although this diagram depicts components as functionally
separate, such depiction is merely for illustrative purposes. It will be
apparent to those skilled in the art that the components portrayed in
this figure can be arbitrarily combined or divided into separate
software, firmware and/or hardware components. Furthermore, it will also
be apparent to those skilled in the art that such components, regardless
of how they are combined or divided, can execute on the same computing
device or multiple computing devices, and wherein the multiple computing
devices can be connected by one or more networks.

[0032] Referring to FIG. 1, a server-side conversational Web service 101
is a state machine, which provides well-defined functions to start 104,
continue 105, and to finish 106 a conversation 102 identifiable with an
unique conversation id 103. All the conversation instances can be
persisted in a persistent store 107. A container 108 in which the
conversation service is running can serve as a conversation manager,
which actually create, persist, and delete the conversation upon request
from the client service (party) 109 or 110. These clients (services) may
communicate information, which may include but is not limited to the
conversation id, with the conversational service via Web service
addressing. Securities and roles can be specified for the conversation
service to define access permission for a client to invoke certain
methods of the service. for a non-limiting example, annotations 111 can
be specified for the conversational service to limit access to the
conversation to a client with a specific certificate.

[0033]FIG. 2 is a flow chart illustrating an exemplary process of
conversational Web service based on Web service addressing in one
embodiment of the present invention. Although this figure depicts
functional steps in a particular order for purposes of illustration, the
process is not limited to any particular order or arrangement of steps.
One skilled in the art will appreciate that the various steps portrayed
in this figure could be omitted, rearranged, combined and/or adapted in
various ways.

[0034] Referring to FIG. 2, a party may start a conversational (service)
at step 201 by submitting to a conversation manager a service request,
which contains a "reply to" address, which can be used for receiving
information (conversation id) and/or for the conversation manager to
notify the party. Upon receiving the request, the conversation manager
may process the service request at step 202, create a conversation and a
conversation id at step 203, and provide the conversation id to the party
at the "reply to" address at step 204. Upon accepting the conversation id
from the conversation manager at step 205, the party may then participate
in the conversation (at a later time) by including the conversation id in
a new request for conversation to the conversation manager at step 206.

[0035] In some embodiments, conversational service can act like a state
machine, where only certain operations are allowed at the certain times
node and whether an operation starts or continues a conversation is
clearly identified. Conversation operations can be annotated as, for a
non-limiting example, @Conversation Phase, with allowable values of
"start", "continue", and "terminate". Operations that are not annotated
with a conversation mode will be assumed as "continue".

[0036]FIG. 3 illustrates an exemplary state transition diagram for
conversational Web service in accordance with one embodiment of the
present invention. A client can create a particular conversation with a
unique id to be shared among multiple parties by invoking the start
method and the conversation will switch from the "Non-existence" state
301 to the "Running" state 302. A conversation will start when an
incoming message without a conversation id arrives on an operation with
an annotation of "start". It will be possible to call a start operation
with a conversation id, or to pull the conversation id from a part of the
incoming message body as described in later context. Another client may
join an ongoing conversation identified by the conversation id using one
of a plurality of continue methods, while the conversation remains in the
"Running" state. Messages cannot arrive at a continue/terminate operation
without conversation id, which will be rejected with a fault. Once the
finish method of the conversation service is called by a client, the
current conversation can be closed and switch back to the "Non-existence"
state.

[0037] In some embodiments, a Web service can be denoted as being
conversational via a class-level annotation as shown by the non-limiting
example below:

TABLE-US-00001
public class MyConversationalService {
};

[0038] The instance variables within the service implementation object
form the conversation state. By default, all non-transient members are
considered part of the conversation state.

[0039] In some embodiments, the client may propose the conversation id 103
by sending it in a pre-defined header of the message. The client
application proposes a conversation id either by calling a setter such as
setConversationId( ) on a name stub of the service, or by setting a
property on the stub. The server may then start the conversation with
that id.

[0040] In some embodiments, the service provider may assign a conversation
id if a message arrives for a "start" operation without one.
Server-assigned conversation identifiers can be exchanged through Web
service addressing. A client may initiate a conversation by calling one
of the operations marked "start." If this operation is synchronous, the
response message will contain a "ReplyTo" address with the conversation
id in reference parameters. The client will then echo this conversation
id in all subsequent messages. If the "start" operation is asynchronous
and reliable, the "ReplyTo" address and conversation id are returned
reliably either with an application response message if the original
operation is request/response, or in a separate message if the original
operation is one way. If the "start" operation is asynchronous and
unreliable, the "ReplyTo" address and conversation id will be sent back
unreliably either with an application response message if the original
operation is request/response, or in a separate message if the original
operation is one way. If the "start" operation is asynchronous, and the
conversation id is server-assigned, it is mandatory that the client
(sender) defines a "ReplyTo" address and failure to do so will result in
a server-side fault. Obviously, no further conversational messages are
delivered until the sender received the message containing the
server-assigned ID.

[0041] In some embodiments, the conversation id can be communicated back
to any client who has requested the conversation and also supports Web
service addressing standard, i.e., it mandates that the client to place
its address and a set of other properties in a message or its headers
when communicating with the conversational service and the set of
properties will be echoed back to the client. Here, Web service
addressing can be used to report these headers, so that any
Web-service-addressing-aware client can participate in conversational
communications. The message to and the one echoed back from the service
can occur asynchronously at different time (instead of right away) as
long as the same set of the properties or ids are included in both
messages. In other words, even if the response to a request is sent at
different time, the two can be correlated through the Web service
addressing. It enables the conversational service to communicate with
clients operating across various platforms and protocols as long as all
of them are compliant with (implement) the same Web service addressing
protocol. Such Web service addressing is automated and does not require
human intervention.

[0042] In some embodiments, an intermediary Web service 401 can be
utilized on the client side for Web service addressing to accept and
relay information such as the conversation id between the client service
and the conversational service as shown in the exemplary framework in
FIG. 4. Such an additional service is necessary when the information
communicated between heterogeneous parties needs to be processed first.
For a non-limiting example, some client service may not recognize the
conversation id or Web service address sent from the conversational
service and such information has to be translated into a form
recognizable by the client through the intermediary service.

[0043] In some embodiments, conversation instances can be persisted in a
cluster-wide map of persistent stores, which is responsible for at least
one of:

[0044] 1. Ensuring that conversational instances can be accessed from
anywhere in the cluster of one or more servers (service providers). The
entries in the cluster-wide map may be distributed across servers in the
cluster, with only one server claiming ownership of a particular entry at
a time. For efficiency and correctness, messages will be routed to the
server that owns the entry. Such routing uses Web service addressing
features to have the client echo back the right amount of information in
order to figure out the correct server that the conversational
information resides on.

[0045] 2. Enforcing isolation levels and transactional semantics. The map
will automatically be enlisted as a resource in transactions and will
ensure that conversation instances put into the map are only made visible
when the active transaction commits.

[0046] 3. Implementing conversation eviction policies (based on criteria
such as max-age, max-idle-time), i.e., conversations that have been idle
for a particular length of time, or that have exceeded the lifetime of
the business transaction will be purged.

[0047] In some embodiments, there can be two different map
implementations--transient and persistent. The transient map keeps
entries in-memory (replicated) while the persistent map keeps entries in
a store of transactional file.

Callbacks

[0048] Every Web service may be associated with a single interface that
represents a callback to a client. On the client side, the client may
register an event handler for each callback message it wants to receive.
When a callback arrives, the event handler is triggered. In some
embodiments, the event handler can be automatically created and
registered for the client using annotations. If the client is itself a
stateful service, the callbacks will be directed to the instance that
made the outbound request.

[0049] Traditionally, callbacks are loosely coupled over time with
asynchronous Web service and/or messaging, which enables clients to:
[0050] Not block or remain connected while waiting for a response.
Although simply non-blocking is an important part of asynchrony, it also
critical that clients need not remain up and connected while the response
is being prepared. The main reason is to support operations that may take
a very long time to complete--for a non-limiting example, operations that
interact with asynchronous and high-latency systems that include but are
not limited to, queuing, mainframes, batch systems, other Web services,
and enterprise applications. It also helps to support occasionally
connected/disconnected systems that include but are not limited to,
laptops, PDAs, WiFi devices and cell phone networks. [0051] Receive more
than one message in response to a request. For a non-limiting example,
publish/subscribe is the classic ticker scenario, where an endpoint sends
a subscription message to a server and begins receiving a ticker feed in
response. Market data, news feeds, blog updates, all that stuff fits into
this scenario.

[0052] Traditionally, callback functions cannot recognize the callback
address, which has to be provided by the client explicitly as a parameter
to the service provider. The service provider will then create a stub
(software component) pointing to that address when sending the response
back to the client. Such an approach implemented at the application level
can be very inefficient.

[0053] Various embodiments of the present invention enable related parties
to setup asynchronous messaging exchanges between Web services based on
Web service addressing. A "CallbackTo" header may include the address to
which application level responses are sent. At its most basic,
asynchronous messaging is about callbacks: the client sends a request to
the service provider and provides it with a callback address. When the
response is ready, the service provider sends it to that callback
address. Under the present invention, all the callback address lookup,
population and setup can be performed automatically by the service
provider at the infrastructure level transparent to the user and only the
service/contract itself need to be defined.

[0054]FIG. 5 is an illustration of an exemplary callback framework 500
based on Web service addressing in one embodiment of the present
invention. Although this diagram depicts components as functionally
separate, such depiction is merely for illustrative purposes. It will be
apparent to those skilled in the art that the components portrayed in
this figure can be arbitrarily combined or divided into separate
software, firmware and/or hardware components. Furthermore, it will also
be apparent to those skilled in the art that such components, regardless
of how they are combined or divided, can execute on the same computing
device or multiple computing devices, and wherein the multiple computing
devices can be connected by one or more networks.

[0055] Referring to FIG. 5, service provider 501 may provide an
asynchronous Web service 502, e.g., getQuote( ), which may not provide
quote to the client right away. The service provider may also define a
contract (interface) 503, which any client 504 must implement (by
providing a handler for) in order to communicate with the service
provider. For a non-limiting example, in order to receive the quote from
the service provider later on, the client service must implement a
contract named quoteReceived( ). The service provider may define a
callback variable (stub), which can be annotated by @Callback so that
this stub will be populated with all the information needed to do
callback.

[0056]FIG. 6 is a flow chart illustrating an exemplary callback process
based on Web service addressing in one embodiment of the present
invention. Although this figure depicts functional steps in a particular
order for purposes of illustration, the process is not limited to any
particular order or arrangement of steps. One skilled in the art will
appreciate that the various steps portrayed in this figure could be
omitted, rearranged, combined and/or adapted in various ways.

[0057] Referring to FIG. 6, a client needs to implement a contract defined
by the service provider first at step 601 before it can request for
service. When the client requests for a quote at step 602, it will
automatically compile a software component such as a stub in accordance
with the contract to send the requesting message to the service provider.
When Web service addressing is utilized, the service provider will
automatically process the incoming message and its header from the client
to obtain and/or initialize the address of client (where the message is
coming from) at step 603, and populate it to a callback stub at step 604
so that response will be sent back to the right client at the callback
time. When the quote becomes available, it will invoke the callback
contract implemented by the client at step 605.

[0058] In some embodiments, for integration with conversational service,
the callback proxy stub needs to be part of the conversational state on
the service side to be called back later. The only thing that needs to be
saved is the callback endpoint reference and any invoke properties. On
the client side, the callback objects need to be part of the
conversational state and have to be serializable.

[0059] In some embodiments, the callback can be reused many times over a
period of time once initialized when the service is conversational
(asynchronous) and the service provider may wait for the information to
be available before calling back to the client. Under the conversational
scenario, the stub will be kept as part of the persisted conversational
state; Under the non-conversational scenario, the stub will be related
only to the current calling client and can be created and included
automatically as a method parameter in the incoming request.

Asynchronous Request Response

[0060] Traditionally, a client 701 may invoke a Web service from a service
provider 702 by sending a request 703 to the server and the service
provider will respond 704 via the same http connection 705 as shown in
FIG. 7(a). Such framework may not apply when asynchronous messaging or
callback is utilized as discussed earlier.

[0061] FIG. 7(b) is an illustration of an exemplary asynchronous request
response framework in one embodiment of the present invention. Although
this diagram depicts components as functionally separate, such depiction
is merely for illustrative purposes. It will be apparent to those skilled
in the art that the components portrayed in this figure can be
arbitrarily combined or divided into separate software, firmware and/or
hardware components. Furthermore, it will also be apparent to those
skilled in the art that such components, regardless of how they are
combined or divided, can execute on the same computing device or multiple
computing devices, and wherein the multiple computing devices can be
connected by one or more networks.

[0062] Referring to FIG. 7(b), the server will respond first with a "get
the request" type of response 706 instead of an actual and immediate
response to the user's request, which will be sent later (i.e.,
asynchronously) in a separate message when the response becomes available
at the service provider. Alternatively, the service provider may also
send the actual response to an intermediary Web service 707, which will
translate the response into a format acceptable by the client before
relaying it to the client.

[0063] FIG. 8 is a flow chart illustrating an exemplary asynchronous
request response process in one embodiment of the present invention.
Although this figure depicts functional steps in a particular order for
purposes of illustration, the process is not limited to any particular
order or arrangement of steps. One skilled in the art will appreciate
that the various steps portrayed in this figure could be omitted,
rearranged, combined and/or adapted in various ways.

[0064] Referring to FIG. 8, a client may send a service request to a
service provider at step 801. Instead of responding to such request
immediately, the service provider will respond with a "get the request"
type of response to the client at step 802. At step 803, the service
provider will respond to the client with the actual response to the
service request later when such response becomes available.
Alternatively, the service provider will send the actual response to an
intermediary service at step 804, which will then translate such response
into a format acceptable to the client and send it to the client at step
805.

[0065] In some embodiments, a generic async response service can be
deployed on the same server as the client service, shown as the exemplary
service "Foo" in FIG. 9(a). When the hello world service shown in FIG.
9(b) is invoked from within Foo, a "reply-to" address is included that
points to the async response service. This way, all addressing-aware
servers will send the response back to the async response service.

[0066] In some embodiments, a handler chain can be saved when the service
request is submitted asynchronously so that it can be used later to bind
the result. Message id can be used to save the handler chain in an
in-memory store. In addition, the handler chain and the message context
on the handler chain can be saved in a persistent map within the cluster
as discussed earlier. This way, the result can still be bounded even if
the server goes down. When the response gets to the async response
service, it will look up the handler chain saved and invoke it to bind
the result. If there has been a reboot of the server, the handler chain
will be reinitialized and the message context saved in the persistent map
will be set on the handler chain. Thus, states can always be saved on the
message context as long as it's serializable and should not be saved
within an internal handler if asynchronous request/response is to survive
a reboot.

[0067] One embodiment may be implemented using a conventional general
purpose or a specialized digital computer or microprocessor(s) programmed
according to the teachings of the present disclosure, as will be apparent
to those skilled in the computer art. Appropriate software coding can
readily be prepared by skilled programmers based on the teachings of the
present disclosure, as will be apparent to those skilled in the software
art. The invention may also be implemented by the preparation of
integrated circuits or by interconnecting an appropriate network of
conventional component circuits, as will be readily apparent to those
skilled in the art.

[0068] One embodiment includes a computer program product which is a
machine readable medium (media) having instructions stored thereon/in
which can be used to program one or more computing devices to perform any
of the features presented herein. The machine readable medium can
include, but is not limited to, one or more types of disks including
floppy disks, optical discs, DVD, CD-ROMs, micro drive, and
magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash
memory devices, magnetic or optical cards, nanosystems (including
molecular memory ICs), or any type of media or device suitable for
storing instructions and/or data. Stored on any one of the computer
readable medium (media), the present invention includes software for
controlling both the hardware of the general purpose/specialized computer
or microprocessor, and for enabling the computer or microprocessor to
interact with a human user or other mechanism utilizing the results of
the present invention. Such software may include, but is not limited to,
device drivers, operating systems, execution environments/containers, and
applications.

[0069] The foregoing description of the preferred embodiments of the
present invention has been provided for the purposes of illustration and
description. It is not intended to be exhaustive or to limit the
invention to the precise forms disclosed. Many modifications and
variations will be apparent to the practitioner skilled in the art.
Particularly, while the concept "servlet" is used in the embodiments of
the systems and methods described above, it will be evident that such
concept can be interchangeably used with equivalent concepts such as,
class, method, type, interface, bean, component, object model, and other
suitable concepts. While the concept "interface" is used in the
embodiments of the systems and methods described above, it will be
evident that such concept can be interchangeably used with equivalent
concepts such as, bean, class, method, type, component, object model, and
other suitable concepts. While the concept "configuration" is used in the
embodiments of the systems and methods described above, it will be
evident that such concept can be interchangeably used with equivalent
concepts such as, property, attribute, annotation, field, element, and
other suitable concepts. Embodiments were chosen and described in order
to best describe the principles of the invention and its practical
application, thereby enabling others skilled in the art to understand the
invention, the various embodiments and with various modifications that
are suited to the particular use contemplated. It is intended that the
scope of the invention be defined by the following claims and their
equivalents.

[0070] Appropriate software coding can readily be prepared by skilled
programmers based on the teachings of the present disclosure, as will be
apparent to those skilled in the software art. The invention may also be
implemented by the preparation of application specific integrated
circuits or by interconnecting an appropriate network of conventional
component circuits, as will be readily apparent to those skilled in the
art.

[0071] The present invention includes a computer program product which is
a storage medium (media) having instructions stored thereon/in which can
be used to program a computer to perform any of the processes of the
present invention. The storage medium can include, but is not limited to,
any type of disk including floppy disks, optical discs, DVD, CD-ROMs,
microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs,
DRAMs, VRAMs, flash memory devices, magnetic or optical cards,
nanosystems (including molecular memory ICs), or any type of media or
device suitable for storing instructions and/or data.

[0072] The present invention may be conveniently implemented using a
conventional general purpose or a specialized digital computer or
microprocessor programmed according to the teachings of the present
disclosure, as will be apparent to those skilled in the computer art.
Stored on any one of the computer readable medium (media), the present
invention includes software for controlling both the hardware of the
general purpose/specialized computer or microprocessor, and for enabling
the computer or microprocessor to interact with a human user or other
mechanism utilizing the results of the present invention. Such software
may include, but is not limited to, device drivers, operating systems,
and user applications. Ultimately, such computer readable media further
includes software for performing the present invention, as described
above. Included in the programming (software) of the general/specialized
computer or microprocessor are software modules for implementing the
teachings of the present invention.

[0073] The foregoing description of the present invention has been
provided for the purposes of illustration and description. It is not
intended to be exhaustive or to limit the invention to the precise forms
disclosed. Many modifications and variations will be apparent to the
practitioner skilled in the art. The embodiments were chosen and
described in order to best explain the principles of the invention and
its practical application, thereby enabling others skilled in the art to
understand the invention for various embodiments and with various
modifications that are suited to the particular use contemplated. It is
intended that the scope of the invention be defined by the following
claims and their equivalence.