[ebxml-bp] Decision vs Fork

["Jean-Jacques Dubray" <jeanjadu@Attachmate.com>]

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