Messaging Sequencing (was: TPA and ebXML Header question)

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

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?