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

[Henry Lowe <hlowe@omg.org>]

Dale,

I wasn't in Dallas so missed this.  If everyone is happy with 
non-sequential delivery, that's OK.  However, on this list, 
folk seemed seemed to be trying to add a sequential guarantee.

On your second point, for the example, a separate MIME part 
for each of "in stock, tracking id, and credit approved" 
messages would items in the manifest for each will do the trick 
without the MS having to add XML to bundle the three together.
Of course there are other ways.  If you have a generic service 
interface, you'd want parameters for each manifest item.  This 
of course, assumes the three departments that handle these 
three requests are all sharing the same node -- the distributed 
case gets a bit trickier ;-)

Speaking of "trickiness", it this was the "smiple" case, how 
complicated does it get?  What is the general service that the 
business processes folk want?  TRP should probably know ASAP 
(if not earlier).

Best regards,
henry
-----------------------------
At 12:11 PM 10/19/2000 -0400, Moberg, Dale wrote:
>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?