OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebxml-bp] Re: [wsbpel] [uddi-spec] WS-BPEL TN scope OK - but howabout working with us on a B2B collaboration TN?



ebBP members,
There has been discussions on the UDDI list and other inquiries in 
Reg/Rep recently about important white papers regarding how to discover, 
store and associate business processes. I would suggest we consider 
working with some team members to develop a white paper for ebBP in the 
first quarter 2005.
I would encourage comments. Steve, Dale and I would like to discuss this 
with you directly first.

Thanks.

steve capell wrote:

> David,
>
> I have no doubt at all the BPSS is a perfect mechanism for describing 
> B2B collaborations. What I still need to do is to map BPSS to a 
> registry meta-model that can be used at runtime for “complementary 
> service” discovery & binding. So far as I know, nobody has done that 
> either for ebXML RIM or for UDDI. It is not enough just to publish the 
> BPSS as a single tModel (UDDI speak) or extrinsic object (ebXML 
> speak). Nor is it necessary to extract every transaction, requesting 
> responding activity, etc, etc and publish as meta-data. The question 
> is – what is just the right amount of meta data that facilitates the 
> discovery & binding process. We think that is:
>
> UMM domain object
>
> UMM Business area taxonomy
>
> UMM process Area taxonomy
>
> UMM abstract process (ie BDV process)
>
> BPSS process specification (linked to a BPSS instance)
>
> BPSS binary collaboration (derived from BPSS and linked to a CPA 
> template instance)
>
> BPSS role (derived from a BPSS and linked to the BPSS instance)
>
> CPA binding (derived from a CPA template as a concatenation of roleId 
> and channelId)
>
> Each of these objects needs a bunch of associations and 
> classifications including things like “complementaryRole” and 
> “complementaryBinding”
>
> We use that meta data to facilitate bilateral agreement negotiation 
> and then use the result to turn template CPAs into deployment CPAs and 
> push them out to relevant end-points which, in turn automatically 
> process the CPA and BPSS and configure themselves to transact.
>
> But we’d like to see our registry meta-model (or a version of it) 
> become an adopted standard – typically via a published technical note.
>
> Regards,
>
> ------------------------------------------------------------------------
>
> *From:* David RR Webber [mailto:david@drrw.info]
> *Sent:* Thursday, 9 December 2004 8:14 AM
> *To:* steve capell
> *Cc:* BPSS ebXML
> *Subject:* [ebxml-bp] Re: [wsbpel] [uddi-spec] WS-BPEL TN scope OK - 
> but how about working with us on a B2B collaboration TN?
>
> Steve,
>
> I've been working with the US government here on modelling processes 
> using BPSS.
>
> This is well suited to the task of regulatory interactions with formal 
> conditionals and
>
> context requirements.
>
> The new version 2.0 of BPSS includes the ability to have multi-party / 
> multi-role
>
> models along with transaction formats and signals.
>
> You can check out the activity diagram examples and working models 
> that we've
>
> built for industry scenarios at the following location:
>
> http://www.visualscripts.net
>
> And there is also the tutorial there as well. Clearly BPSS excells for 
> B2B models.
>
> I'd be happy to work with you on developing these models to suit the 
> Australian Gov
>
> needs.
>
> Thanks, DW
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]