Signals suggestions

[<martin.me.roberts@bt.com>]

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

Work  Items 61 and  59


In the BPSS today there is no mechanism to describe which actual signals are  being used with the patterns.

The two proposals are needed to solve this:

1) allow the BPSS to refer signal descriptions of the signals in a similar fashion as the document envelope document descriptions.  As there are a standard set of signals refered to by the patterns these should be defined directly under the ProcessSpecification element.  I propose that there are 5 possible signals defined:

	receiptAcknowledgement
	receiptAcknowledgementException
	acceptanceAcknowledgement
	acceptanceAcknowledgementException

	and if we agree 

	generalException

under these would be the fields that are used to describe document contents:

	specificationLocation
	specificationID
	specigicationType
	specificationTypeOther

	plus a ConditionExpression Element to add to the specification... fields

2)  Also linked to this is a clear explanation of the causes of the particular signals.  Dale Moberg asked to have a clearer definition of when these signals are to be used.  This could be sorted by more explicit definition of the use of patterns so that the BusinessTransaction element is overloaded with pattern specific types.

3) workitem 59 talks about the use of an optismistic approach with failures.  There may have to be a new set of patterns to cope with this.