[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC