RE: [ebxml-bp] Proposal for dynamic context for BPSS

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

Dear all,
  I would like to add my weight to this as I feel that if we want to keep 2.0 of the BPSS to a reasonable scope, we are going to have to accept that late binding really is outside of the BPSS.
 
  One concern I have is that we have two problems which David RR suggests can be fixed by the one mechanism.  They are input of context details to manage the document content that will be exchanged and the manipulation of the BPSS/CPA based information that is controlling the exchange.
 
I feel that both of the above are very much needed to plug the gaps we have today.  
However, there seems to be a push back that says the BPSS/CPA flexibility should be expressedin the BPSS if that is know at the time of the BPSS design - i.e. transaction timeToPerform is based on field x plus 24 hours.  John Yunker said this was not an agreement time arrangement but part of the business level process definition.
With that in mind we have to build a bridge between these views.  My feeling is that anything we do quickly that introduces flexibility in the BPSS also will greatly complicate the resulting structures and therefore could lead to an unclear solution rather than making life easier.  
 
For this reason I propose that the BPSS does not attempt to address this issue as part of the BPSS 2.0 spec, but instead we need to discuss this with a joint team of CPA and BPSS.  This would make a great topic for New Orleans?
 
There is another reason why I think this should be done outside the BPSS 2.0.  I am very concerned that any expression language we say we want to use will either prove very coomplex or too simple.  We would have to choose a default language if we are to encourage the feature to be interoperable, but we do not have the time to work through this to a point where we could be comfortable that we have enough to do the job but not too much that no one really understands the implications.
 
Take care.
 
Martin

	-----Original Message----- 
	From: David RR Webber [mailto:david@drrw.info] 
	Sent: Thu 05/02/2004 21:23 
	To: BPSS ebXML 
	Cc: Monica Martin 
	Subject: [ebxml-bp] Proposal for dynamic context for BPSS
	
	
	Monica,
	 
	As requested today, here is the text of the
	context proposal.
	 
	Use Cases:
	=========
	 
	Given that BPSS should:
	 
	a) support late binding of specific parameters within 
	    the BPSS based on business factors that
	    occur during a BPSS use
	b) support business modellers being able to 
	    identify critical factors during creation of a BPSS
	    that effect linking and switching within a process
	    and be able to specify those and quantify their
	    details - 
	    (e.g. deliveryCountry = Mexico, USA, Canada).
	c) support ability to configure BPSS flows to match 
	    locale or other factors globally based on context
	    provided when a CPA is determined between
	    participants based on their own transaction
	    needs (e.g. produceType="mustRefridgerate")
	d) provide context to external components that 
	    may be directed by BPSS - such as transaction
	    handling software (Java, EDI Mapper, XSLT, CAM, 
	    EAI adaptor, et al), or web service step.
	e) have a mechanism to determine pre-conditions 
	    for BPSS and outcomes - start, wait, or skip
	    that allows implementers to configure when
	    a BPSS should commence.
	 
	Approach:
	=======
	 
	Provide an XML instance, separate from but
	relating to the BPSS, specifically for managing 
	context, and link to that from BPSS either 
	directly (URL) or indirectly via reference in CPA
	(CPA can provide link to constrained BPSS
	 context set verified by collaboration 
	 participants as they define their CPA).
	 
	In constructing context rules within this XML
	instance simple XML will be used along with
	XPath expressions and a basic datatyping
	system founded on the W3C foundation
	data types.  This will be supplemented
	with a limited set of string referencing 
	functions necessary to complete the
	data model of context rule parameters.
	 
	The aim is to make this rapidly implementable
	with off the shelf simple XML development
	tools, and concise and complete to be specified
	with a supplemental Context Technical Note
	specification of 15 pages or less.  This 
	supplemental document will follow the model
	used by the Registry team for their supplemental
	notes to their main specifications.
	 
	Rationale:
	=======
	 
	1) A well featured context mechanism will set
	    BPSS V2.0 apart as the premier approach to
	    business orchestration using the latest
	    techniques for integration into the SOA 
	    solution stack.
	 
	2) The cost of documenting the technical
	    note in 15 pages is comparable to 
	    defining a lesser capability within the
	    existing BPSS with mostly the
	    same effort (XPath expression
	    definition and control mechanisms).
	 
	3) Setting this feature now for V2.0 will
	    set the foundation for V3.0 and beyond,
	    without requiring implementers to "two-step",
	    (supporting a lesser V2.0 capability that
	    then is extended later with attendent need
	    to support two related mechanisms).
	 
	4) Having a consistent context mechanism
	    that BPSS can use to manage not only
	    its own needs but can be referenced by
	    any other component that relates to the
	    BPSS provides a single consistent
	    system across the ebXML stack.
	 
	5) The context mechanism proposed is 
	    already known and therefore the level
	    of effort and risk in designing it is 
	    significantly less than involved in 
	    starting with nothing.  
	 
	6) Having a well featured context
	    system that is extensible ensures
	    that all the use cases a) thru e) 
	    can be accommodated sufficiently
	    in V2.0 - therefore significantly 
	    enhancing the value and utility of 
	    the BPSS specification.
	 
	Technical Detail:
	============
	 
	The draft proposed initial Context Technical Note
	document will be posted separately for
	reference, but it is anticipated that this
	will be completed as a work item for V2.0
	and agreed to as part of that process, by
	BPSS team members.  Input from all
	6 use cases and worked examples can then
	be generated as part of the deliverable too.
	 
	Thanks, DW.