[
Lists Home |
Date Index |
Thread Index
]
Isn't what we talking about here--at the level of business rather than software
operations--long-running processes which maintain their own state over a number
of messaging cycles. For example (and seen entirely from the viewpoint of a
particular process, without reference to the corresponding perspectives of its
counterparties) my process might receive a message from you which it
instantiates locally as an order. That process therefore opens an order in an
'unfilled' state. Following its own business logic, my process then delegates
portions of this order to various suppliers, sending each a message and then
opening a procurement request in an unfilled state for each of them. As response
messages are received from each supplier, those which can be instantiated as
fulfillment, or partial fulfillment, of the earlier requests lead my process to
close the previously open state of the positions associated with each of those
requests. Closing those open items, in turn, leads my process to instantiate
inventory, or otherwise available positions which can then be applied to close
the open state of the original order received.
As business processing, this pattern can often be improved if the process gives
notice of its particular instantiation of each message and perhaps awaits
confirmation of its understanding. In this example, a message describing the
order as originally instantiated would be sent to the source of the message from
which that order was produced. Whether to wait for particular confirmation of
that return message before proceeding with the delegation to suppliers is a
business decision of the tradeoff of speed against certainty and will be
resolved differently by different processes in different circumstances.
Respectfully,
Walter Perry
Jeff Greif wrote:
> Among the ways to do this is CORBA AMI (Asynchronous Messaging). You pass
> the object reference of the object that's waiting for the callback. In some
> CORBA implementations you specify the signature of the synchronous message,
> and indicate as a configuration option that you also want an asynch version,
> and much of the rest is done automatically by the IDL compiler. You still
> have to fill in the implementation of the callback, of course.
>
> Jeff
> ----- Original Message -----
> From: "John Cowan" <cowan@mercury.ccil.org>
> To: <andrzej@chaeron.com>
> Cc: "Michael Brennan" <Michael_Brennan@Allegis.com>; <costello@mitre.org>;
> <xml-dev@lists.xml.org>
> Sent: Monday, February 04, 2002 6:15 PM
> Subject: Re: [xml-dev] Categories of Web Service messages: data-oriented v s
> action-oriented
>
> > Andrzej Jan Taramina scripsit:
> >
> > > True, but the tendancy (including SOAPs RPC) seems to be towards a
> > > synchronous approach. Async request/response usually takes a lot of
> extra
> > > coding (beyond synchronous RPC or even Pub/Sub messaging).
> >
> > What I'd like to see is a convention whereby you can send an async
> > request packaged with a "continuation" to which the reply is sent.
|
