Re: Messaging Sequencing (was: TPA and ebXML Header question)

[Martin W Sachs/Watson/IBM <mwsachs@us.ibm.com>]

Except for the basic question of ordering of messages sent by the Messaging
Service, the functions that Dale is discussing belong in a combination of
the CPA and the application-support services function in the B2B
middleware.

IBM's tpaML proposal (and the soon-to-appear TP team specification version
0.0) defines sequencing rules which specify the order in which defined
requests can be issued to each partner, primarily on a 1-at-a-time basis.
The kind of joins Dale mentions is one possible extension.  All-or-nothing
semantics is a possible extension of the join. A more general
event-condition-action state machine, briefly discussed in last week's TP
Face to Face meeting is another.

Verifying the order of issuing requests, performing the join, and similar
functions are ideal candidates for implementation by the application
support services function since the implementation can be
application-independent, with the CPA specifying the functions to be
performed for a particular application between a particular pair of parties
under a particular CPA.

The functions performed by the ConversationId will be specified in the CPA
specification (and are specified in the tpaML proposal).  Briefly, the
Conversation is a session-like construct (unit of business) which is part
of the Business Process domain. Conversation support is another
application-independent function that can be performed by the
application-support services function. The Messaging Service need do
nothing more than put the ConversationId into the message header.  Possibly
a future enhanced Reliable Messaging function might make use of the
ConversationId to recognize relationships among the messages.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



"Moberg, Dale" <Dale_Moberg@stercomm.com> on 10/19/2000 12:11:16 PM

To:   Martin W Sachs/Watson/IBM@IBMUS, Henry Lowe <hlowe@omg.org>
cc:   ebxml-transport@lists.ebxml.org, ebxml-tp@lists.ebxml.org
Subject:  Messaging Sequencing (was: TPA and ebXML Header question)



I am now realizing that there are several
interesting but different concerns being expressed
int this thread. I think I now understand Henry's
issue correctly and will
talk about that first. I basically will report
on the RM discussion at the WG F2Faces. There
is also another question about TRP, BP and
"support" for BP sequencing rules within the
implementational framework supplied by TRP MSH.
(whew.)

I believe that the current RM treatment
allows messages from a given sender to a given
receiver to be made available to the receiver
in an order differing from the order
the sender sent them; also I believe that
this treatment was a deliberate
choice. In other words, the original Fujitsu proposal
had an implementation that would have guaranteed
the "order of delivery matches order of sending".
However, a side-effect of that is that the RM
"channel" would be blocked from sending messages
until an acknowledgement of delivery arrived.
Many WG participants objected to this, and wanted
concurrency of RM messaging. Concurrency means
that we don't wait for delivery before sending
and we accept that "order of delivery may not
match order of sending". The analysis was that
RM did not entail sequencing preservation--that
was something extra. At any rate, this is my
understanding of what transpired.

A different question concerns what implementational level
support, if any, should exist for business process
sequencing requirements.  Here sequencing
is much more general than "order of delivery matches
order of sending" of messages. (Or even "responses to first
request must arrive before a second request is sent")
Here is where I have heard many engineers and analysts
both talking about "forks and joins", or the equivalent.

Here is a simple example. A business marketplace
storefront generates a combined XML document
combining shipping requirements, payment info,
and item requested. The web backend wants
to respond with "in stock, tracking id, and
credit approved." Three concurrent requests
go out to financial, logistics, and ERP inventory
control. All responses must join back together before
the business response to the marketplace user
is sent. Such tracking and coordination might be done outside
the constituent business applications,
(inStock, creditOK, and deliveryScheduled).

The question I have is that I think the BP group
is going to be discussing business processes with
"dependencies" like the previous simple one, but
more complex. TRP MSH has made a deliberate
choice of scope not to take on how the ebxml
implementational framework at the MS level can realize these
complicated business processes involving forks
and joins. There is a Conversation Id but little
discussion just what this id can help with in
terms of tracking, synchronization etc. So there
seem to be requirements coming down from above (BP
and maybe TPA) that exceed the defined capabilities
of what is being fleshed out down below (TRP). I am
trying to discover whether this is a covered topic
or not. If it is, what group or groups handle(s) it?