Title: Nachricht
Steve:
If you would like to discuss this matter
further please propose that this be put on the agenda for our
scheduled 14 Dec Telecon [1]. As it stands, this TN has been
approved: Yes received 11 Votes / No
received 1 Vote [2].
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
[1] http://www.oasis-open.org/committees/event.php?event_id=6545&day=14&wg_abbrev=uddi-spec
[2] http://www.oasis-open.org/apps/org/workgroup/uddi-spec/ballot.php?id=619&
From: Von Riegen, Claus
[mailto:]
Sent: Friday, December 10, 2004
08:34
To: steve capell; Trickovic, Ivana; Luc Clement; ;
;
Cc:
; ; James Bryce Clark;
Mary McRae; Tony Rogers
Subject: AW: [uddi-spec] WS-BPEL TN scope OK -
but how about working with us on a B2B collaboration TN?
Steve,
Thanks
for your feedback.
For
now, the UDDI TC would like to finalize the mapping from BPEL to UDDI.
There is certainly room to develop additional Technical Notes complementary to
the existing ones. Would you mind discussing your ideas at one of the next UDDI
TC meetings?
Thanks,
Claus
-----Ursprüngliche Nachricht-----
Von: steve capell
[mailto:]
Gesendet: Mittwoch, 8. Dezember
2004 22:01
An: Trickovic, Ivana; 'Luc Clement'; ;
; Von Riegen, Claus;
Cc:
; ; 'James Bryce
Clark'; 'Mary McRae'; 'Tony Rogers'
Betreff: [uddi-spec] WS-BPEL TN
scope OK - but how about working with us on a B2B collaboration
TN?
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
