[uddi-spec] WS-BPEL TN scope OK - but how about working with us on a B2B collaboration TN?

Title: Nachricht

Ivana,

 

Thank you for your response.  I am pleased
to see that SAP has considered the use case B2B use case - and I do understand
your concerns about the ability of abstract BPEL to model B2B collaborative
processes.  In that context I agree with the scope of your BPEL TN and
am happy to remove my objection.

 

However I would like to mention that we
are actively engaged with the Australian government in modelling B2B processes in
order to develop a national standard. The deployment framework does include the
use of a services registry (UDDI or ebXML).  Therefore our need still remains
and I would like to ask SAP and/or anyone else on the TC whether they would be
interested to work with us on a registry meta-model for B2B collaborative
processes (based on UN/CEFACT UMM).  At present we have done some work on
mapping UMM to BPSS and CPA and from there to UDDI.  The UDDI meta-model does
include explicit enumeration of multi-party collaborations, roles within those
collaborations, binary contracts, and bindings.  We would be willing to
contribute this work to form the basis of a TN on the subject and would be
happy to work with SAP on developing the material further.

 

Regards,

 

Steve

 

From:
Trickovic, Ivana [mailto:] 

Sent: Wednesday, 8 December 2004
2:33 AM

To: steve capell; Luc Clement;
; ; Von Riegen, Claus; 

Cc: ;
; James Bryce Clark; Mary McRae; Tony Rogers

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

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