[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] Decision vs Fork
JJ, Can you clarify something. If you have any of these with a transaction that does not exit to another fork, join or decision does this effectively give you the possibility to return to the same fork, decision etc What does an OR fork mean? How does the isConcurrent affect these constructs? Martin -----Original Message----- From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] Sent: Fri 06/02/2004 14:44 To: ebxml-bp@lists.oasis-open.org Cc: Subject: [ebxml-bp] Decision vs Fork Hi: I wanted to add from our discussion yesterday that a: a) a fork means that several path are possible but we don't when and which paths will be active b) an XOR fork means that as soon as one of these path are active, all the others become disabled. However, all were possible to start with c) a decision differs from a fork in the sense that a decision selects only one possible path, the other one is automatically disabled. An XOR fork could be designed to operate like a decision, but a decision cannot amount to an XOR fork. Hope this clarifies a bit what we said, JJ- -----Original Message----- From: martin.me.roberts@bt.com [mailto:martin.me.roberts@bt.com] Sent: Friday, February 06, 2004 4:52 AM To: ebxml-bp@lists.oasis-open.org Subject: [ebxml-bp] Signals suggestions As part if the F2F we have discussed the signals issues. Two in particular. The first is how does anyone know which signals content will be used within a given exchange. The second was a request from Dale Moberg to have a more explicit explanation of when signals would occur and what is allowed to occur. The solution to the first is simple: We add a set of signal definitions, similar to the document envelope definitions that allows for each of the signals to be defined. For this there are two options 1) have a discrete set of signals that must be defined 2) have a flexible structure that allows for any type of signal to be attached. With the first option (discrete set of signal defn) we can neatly hook int the existing patterns, but would find that we could not handle other type of business exchanges outside the existing set. This links into the next problem which was how to make it absolutely clear when they would be sent. My suggestion is that we do two things: 1) instead of having BusinessTransaction as a fixed structure we introduce a set of subclasses of it that represent the patterns we wish to represent. These transaction subclasses would define the various parameters required with default values etc and would also describe which signals applied and their appropriate timings. 2) make it absolutely clear which timings are linked with which signal or document. With these two modifications we could allow BPSS to offer support for the default set of patterns, but also we could allow other external subclasses of patterns to be developed to cover off use cases such as those that Anders Tell has requested (revocation based negotiations). As these would not be directly in BPSS, people such as the UBAC team could trial their use before getting them adopted into later BPSS versions. There is a catch though. For the first time the schema of BPSS would be designed to be extended. This would require the use of schema extension models such as the Venetian Blind (noah's ark) in a similar manner to the OAG. Personally I use this technique in my Business documents and have been grateful for the flexibilty it offers. However, it will mean a change to the way the CPA can manipulate timings etc, which leads me to think that this is also linked with the debate on the external context device. Again take care. Martin
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]