[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] 1/7/2004: BPSS Elements and Reusability
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. 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. 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. 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. 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). 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. 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 5) Parties may only choose to share a sub-BPSS with a participant - and not the overall master-BPSS. 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. > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]