Re: [ebxml-bp] 1/7/2004: BPSS Elements and Reusability

["Monica J. Martin" <Monica.Martin@Sun.COM>]

David RR Webber wrote:

>Monica,
>
>I think this needs a complete re-evaluation.
>
>What I'd like to see is a specific <include> statement aimed
>at providing re-usable chunks of BPSS.
>
mm1: We do have reusable chunks, Dave - they are called business 
transactions.

>We of course had to address this early in CAM - providing
>sub-assembly - and I must say - we're still not done
>tweaking it all - but at least for V1.0 we have the basics
>done and a reasonable simple approach - including ability
>to treat sub-assemblies as objects.
>
>I think the whole issue of ID's here is a red-herring frankly,
>and we should drive around that thinking.
>
mm1: As we discussed Monday 1/5, we will allow the GUID instruction to 
be an implementation detail.  You have to be able to uniquely identify 
at least the core BPSS elements.

>Here's what I think we might be better off brainstorming on.
>
>1) In a simple party collaboration with a single logical thread
>    (step A, then B, then C, then D) - re-use is directed via
>   the CPA configuring of party profiles.
>
mm1: That is what is defined in binary collaboration and the use of 
business transaction activities, that use business transactions.

>2) In a multi-party collaboration with multi-threads - each
>    such thread can potentially be a sub-BPSS of a standard
>    business function (example - shipment delivery).  What
>    we really need is the ability to provide linkage control,
>    (aka linkage area in BPEL) and common signalling
>   techniques - so when you plug-in the sub-BPSS - it
>   seats into place with the other parts automatically.
>  
>
mm1: See comment above. We will have more discussions on MPC and have 
several work items as well. The idea of a package is also important to 
the composition of collaborations.

>3) The notion of the master-BPSS into which you include
>     re-usable sub-BPSS makes most sense.  An override
>     approach (again in CAM we've specified how to do
>     this generically for any aspect - and then limited it
>     in V1.0 so people are trying to do silly things).
>  
>
mm1: As we discussed Monday 1/5, the implementer may choose one of 
several mechanisms for override given what is to be accomplished.  BPSS 
should indicate what if any of these elements is capable of being 
overridden. Again, another discusssion item for the team.

>4)  What this means is that the sub-BPSS cannot be
>      run on its own - its specifically designed to be
>      included in - and only contains certain things.
>      Similarly you cannot include just any BPSS into
>      another one - it has to be designed to work as
>      a sub-BPSS and be pluggable.  You should be
>      able to follow some steps to convert a working
>      standalone BPSS into a sub-BPSS.
>  
>
mm1: The inner collaboration is designed to not run by itself. These 
capabilities exist in BPSS today.

>Overall the idea is to have a simple and obvious way
>to allow sub-BPSS re-use across an industry domain,
>that is useful - without making it so complicated that
>implementers and users alike will never be able to
>use it anyway.
>
>This begs the question - what makes a good re-usable
>sub-BPSS - can we can figure a few of those use cases
>out - then we can make a first cut and getting something
>worth using?  Dare I say this - but the AutoTech GM/Nissan
>is a nice example IMHO - where the parts suppliers are
>mostly using the same sub-BPSS - while GM and Nissan
>control the master-BPSS.... which points up another
>aspect of this
>  
>
mm1: See previous comments.

>5) Parties may only choose to share a sub-BPSS with a
>     participant - and not the overall master-BPSS.
>  
>
mm1: Same.

>Thanks, DW.
>
>----- Original Message ----- 
>From: "Monica J. Martin" <Monica.Martin@Sun.COM>
>To: "Jean-Jacques Dubray" <jeanjadu@Attachmate.com>; <jjdubray@hotmail.com>;
>"Dale Moberg" <dmoberg@cyclonecommerce.com>; <martin.me.roberts@bt.com>
>Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>; "Yunker, John"
><yunker@amazon.com>
>Sent: Thursday, January 08, 2004 12:43 AM
>Subject: [ebxml-bp] 1/7/2004: BPSS Elements and Reusability
>
>
>  
>
>>When we discussed Work Item 43 in Monday's teleconference call, Dale
>>raised a point about reusability related to BPSS elements. This was
>>prompted from our discussion of name and nameID, and the use of GUID and
>>GUIDREF.
>>
>>The team asked if we could explain previous discussions that lead to the
>>use of GUID and GUIDREF, and explain the intent for reusability.
>>
>>The earlier discussion stemmed from public comments received on the
>>nameID [1]
>><<According to the UEB architecture v0.32, line 821-827 the parameters
>>in BPS document are to be considered as default values and a TPA may
>>override these. If the TPA does so the TPA values take precedence. This
>>indicates a need of being able to uniqually identify all or most
>>elements of BPSS documents such as BinaryCollaborations, Transitions,
>>Business states etc. I dont think the current spec contains such
>>statement. There are at least two ways to go.1. Add 'ID' identifiers to
>>all specifications elements such as adding/moving ID to BusinessState
>>and adding ID to Transition.2. Explicitly state that all Composite
>>associations are *ordered* and therefore positional/index references may
>>be used in references. The second solution may also solve the problem
>>with ConditionalExpression and firing priorities/conflict resolution
>>since the document order of Transitions may be the algorithm to use.....>>
>>
>>Resolution at that time was to: Check in specification for elements
>>without identifiers – Name – attribute with a type of ID, example.
>>Didn’t use the XML Schema ID type because when you have a package, the
>>IDs may not be unique. Explain ID type must be unique within a given
>>document.In addition, for packaging, this could be handled with an
>>include (see BPSS 1.01, line 1722, section 8.1) that existed for the
>>ProcessSpecification. Also see ProcessSpecification in 1.05 (See Section
>>8.1.15). Package specified at 8.1.19.Have a NAME with an associated NAME
>>ID.XSD ID preferred.NAME within a package (PIP ID in name field for
>>RosettaNet )
>>
>>As you can see some of the changes were in answer to this comment and
>>the need to effectively handle packages.
>>
>>Martin, JJ, and John Yunker, if you can add to this discussion, I
>>encourage you to do so. Thanks.
>>
>>[1] Comments from Anders Tell.
>>
>>
>>
>>
>>    
>>
>
>  
>