← Prev in month ← Prev in thread
Next in thread → Next in month →

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

From
"steve capell"
Date
2004-12-01T11:59:26+00:00
ID
200412012300734.SM01000@scapelldt
Thread
[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
← Prev in month ← Prev in thread
Next in thread → Next in month →