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

Title: Nachricht

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:] 

Gesendet: Mittwoch, 1. Dezember 2004 12:59
An: 'Luc 
Clement'; ; 
Cc: 
; ; '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:] 
Sent: Saturday, 27 November 2004 12:47 
  AM
To: ; 
  
Cc: 
  ; ; '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:] 
Sent: Tuesday, August 03, 2004 
  20:59
To: ; 
  
Cc: 
  ; ; 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:

  
    
Enable the automatic 
    registration of BPEL4WS definitions in UDDI 
    
Enable optimized and flexible 
    UDDI queries based on specific BPEL4WS artifacts and metadata 
    
    
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:

  
    
PDF: 
    http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/8442/uddi-spec-tc-tn-bpel-20040725.pdf 
    
    
MSWord: http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/8441/uddi-spec-tc-tn-bpel-20040725.doc 
    

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

  
    
To: Claus von 
    Riegen, SAP (), 
    

    
cc: (UDDI 
    Chairs): ; 
    

    
cc: 
    

  
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