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

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

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


Subject: WG: [wsbpel] [uddi-spec] some comments on "Using BPEL4WS in a UDDI registry" Technical Note


Title: Nachricht
forwarding the message since Ivana is not a UDDI TC member
 
-----Ursprüngliche Nachricht-----
Von: Trickovic, Ivana
Gesendet: Dienstag, 7. Dezember 2004 16:33
An: 'steve capell'; 'Luc Clement'; drj@us.ibm.com; jevdemon@microsoft.com; Von Riegen, Claus; 'amarten@us.ibm.com'
Cc: uddi-spec@lists.oasis-open.org; wsbpel@lists.oasis-open.org; 'James Bryce Clark'; 'Mary McRae'; 'Tony Rogers'
Betreff: AW: [wsbpel] [uddi-spec] some comments on "Using BPEL4WS in a UDDI registry" Technical Note

Steve,

 

The use case you mentioned below is interesting and it has been considered. It is not supported in the technical note because modeling multi-party B2B processes (collaborative processes) using BPEL4WS abstract processes is limited to modeling the behavior of each of participants separately and only binary relationships between them. This limitation must be addressed outside of the UDDI TC and work on this technical note. From our point of view, the primary purpose of BPEL4WS abstract processes is to extend the WSDL service definition with the behavioral aspects – to specify observable behavior of Web services.

 

As you also pointed out, the concept of role and relationships between roles within a scenario are critical features for modeling collaborative processes. BPEL4WS provides only a limited view on collaborative processes specifying all binary relationships between involved parties. Roles defined within bpel partner link types are fine granular roles. A role within a collaborative process might be refined into 2 or more bpel roles. Another point is that it is unlikely that roles will be globally unique. A role has meaning only within a context (= scenario/collaborative process), so that context needs to be published in UDDI as well. There is a need for explicit notion of collaborative processes - it is a container for all roles involved in a conversation.

 

These are the reasons why we decided to restrict the scope of the first version of the technical note. The use case it covers is clear and we believe the proposal can be easily extended as soon as open questions mentioned above are addresses. We do not think that the questions will be addresses by the WS-BPEL TC (collaborative processes are not part of the TC Charter).

 

Regarding your doubt: The reason why we included all port types is that operations partners must implement describe messages partners must be able to consume (and produce, in case of request-response operations) but do not prescribe any specific behavior (e.g. whether messages are received in sequence or not). They only describe requirements for the service consumer(s) (in the same sense in which the abstract process of the service provider does).

 

Kind regards,

 

Ivana 

 -----Ursprüngliche Nachricht-----
Von: steve capell [mailto:steve.capell@redwahoo.com]
Gesendet: Mittwoch, 1. Dezember 2004 12:59
An: 'Luc Clement'; drj@us.ibm.com; jevdemon@microsoft.com
Cc: uddi-spec@lists.oasis-open.org; wsbpel@lists.oasis-open.org; 'James Bryce Clark'; 'Mary McRae'; 'Tony Rogers'
Betreff: [wsbpel] [uddi-spec] some comments on "Using BPEL4WS in a UDDI registry" Technical Note

Hello all,

 

I think the BPEL technical note is pretty good but it seems to me that there is a potentially very useful little bit of meta-data missing:

 

An Abstract BPEL is supposed to model a multi-party long running process.  The series of interactions in the process are broken down into bilateral conversations modelled by the partnerlink Type element that defines the two roles (and the port types they implement) involved in the conversation.  

 

It seems to me that a common application of abstract BPEL will be to model B2B processes and the choreography of interactions within a two-party conversation.  For two parties to engage in such a conversation they must play COMPLEMENTARY roles in the conversation.  Accordingly a common query that might be made by a business entity that plays the role “seller” in the “eancom procurement process” bpel could be “show me all business Entities in my geography that provide a business service that supports the role seller in the eancom procurement process”.  In short the seller is trying to find customers that have a compatible (ie complementary) interface.

 

Now the problem is that the TN (so far as I can see) only results in publication of one tModel for the process.  The TN says that “all port types used in the process” are listed in the process tModel using the wsdl portTypeReference tModel.  If a particular bpel references (say) 4 port types in various namespaces, there is no way to support this query because we don’t know which of the four port types is linked to which role and therefore which ones are complementary.  Would it not make sense to also have a tModel for each ROLE in the bpel (defined by the partnerlink types) and a new tmodel keyed reference that points to the “complementary role”.  In this case the model would look more like:

 

Process tModel (with links to roles via a roleReference category bag element)

Role tModel (with links to the portTypes provided by the Role via the wsdl portType reference AND a link to the complementary Role with a new reference tModel)

PortType tModel – as per TN2 standard.

 

Also - just a point of clarification here, when the TN says that the process tModel references that “all port types used in the process” - I assume this means ALL port types in the BPEL, whether in an <invoke> element or a <receive> element?  Ie all port types whether they are PROVIDED by the bpel or CONSUMED by the bpel?  If so then my previous discussion make some sense.  If only the portTypes PROVIDED by the bpel are included then the whole discussion around complementary roles is invalid and the eancom seller can’t find his potential customers.

 

In our implementation of UDDI in Australia, we are taking a very process centric view of B2B collaborations and this whole story of roles and complementary roles is fundamental to the architecture.

 

Of course there is an entirely separate discussion about whether abstract BPEL is an appropriate standard to model collaborative B2B processes in the first place (they are really choreographies whilst bpel is an orchestration language).  That aside, I am sure that at some point bpel will be targeted at describing abstract conversations and then this issue of how you represent them in uddi becomes quite important.

 

Sorry this is so late in the day (but it is still before the 3rd December deadline!).

 

Regards

 


From: Luc Clement [mailto:luc.clement@systinet.com]
Sent: Saturday, 27 November 2004 12:47 AM
To: drj@us.ibm.com; jevdemon@microsoft.com
Cc: uddi-spec@lists.oasis-open.org; wsbpel@lists.oasis-open.org; 'James Bryce Clark'; 'Mary McRae'; 'Tony Rogers'
Subject: [uddi-spec] RE: [wsbpel] "Using BPEL4WS in a UDDI registry" OASIS UDDI Spec TC Technical Note - Review Requested

 

Having provided sufficient time to review the "Using BPEL4WS in a UDDI Registry" Technical Note it is the UDDI Spec TC’s opinion this Technical Note is ready to be published. It is our intent to publish this TN by the end of this calendar year. That said, should you have additional feedback please provide it no later than 3 Dec so it may be considered prior to the expected ratification of the TN by this TC in mid-Dec.

We understand that there may be unresolved issues relating to the relevance of abstract processes as it relates to the WSBPEL specification. We would like to draw your attention to the fact that the TN applies to the BPEL4WS 1.1 specification submitted to the WSBPEL TC and which defines the concept of abstract processes. The decision to map BPEL4WS 1.1 was deliberate – the TN aims at addressing current market needs.

 

Luc Clément
Senior Program Manager, Systinet
Co-Chair OASIS UDDI Spec TC
Tel: +1.617.768.4268 / Cell: +1.978.793.2162 /
www.systinet.com

 


From: Luc Clement [mailto:luc.clement@systinet.com]
Sent: Tuesday, August 03, 2004 20:59
To: drj@us.ibm.com; jevdemon@microsoft.com
Cc: uddi-spec@lists.oasis-open.org; wsbpel@lists.oasis-open.org; Karl F. Best; James Bryce Clark; Mary McRae; Tony Rogers
Subject: [wsbpel] "Using BPEL4WS in a UDDI registry" OASIS UDDI Spec TC Technical Note - Review Requested

Dear WSBPEL Chairs,

The UDDI Spec TC has been working on a “Using BPEL4WS in a UDDI registry” Technical Note (TN) that it would like your input on before proceeding to ratify this TN.

The TN provides a mapping for publishing BPEL4WS abstract processes into a UDDI registry. The primary goals of mapping BPEL4WS artifacts to the UDDI model are to:

  1. Enable the automatic registration of BPEL4WS definitions in UDDI
  2. Enable optimized and flexible UDDI queries based on specific BPEL4WS artifacts and metadata
  3. Provide composability with the mapping described in the "Using WSDL in a UDDI Registry, Version 2.0.2" [1] Technical Note.

We would like to invite the BPEL TC to review and comment on the document and ask that you assign two or more reviewers.

The TN is posted at the following locations by format:

We would appreciate comments as soon as possible but preferably before 31 Aug 04. Please submit comments:

To: Claus von Riegen, SAP (claus.von.riegen@sap.com),

cc: (UDDI Chairs): luc.clement@systinet.com; tony.rogers@ca.com

cc: uddi-spec@lists.oasis-open.org

Thanks in advance

Luc Clément                       

Co-Chair OASIS UDDI Spec TC

Systinet Corporation
Tel: +1.617.395.6798

 

 

[1] OASIS UDDI Spec TC Technical Note: “Using WSDL in a UDDI Registry, Version 2.0.2”, http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm#WSDLTNV2



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