Title: Message
Dear
Ugo and others,
First
I have to say that the opinions expressed in this mail are my own individual
opinions based on my current understanding (that is always amenable to update on
the absorption of new information!).
Saying
that a minimum of one portType must obey the WS-I Basic Profile is an
interesting get out, but it raises other issues as Peter has shown and fudges
the real issue - see below.
It
seems that the application of the BP will not material affect the BPEL language
itself except possibly in some details (but this could be significant - the
devil is sometimes in the detail!).
However the BP, if applied strictly - which is its whole purpose - will
effect BPEL driven communications.
My
impression is that the prime motivation for BPEL is portability. If
the TC is going to adopt interoperability as a first rank goal, then I think we
should recognise this and maybe even have a vote on whether this should be a
prime goal.
BPEL
demands the use of WSDL and if we then apply the BP then this not only
constrains the WSDL but also demands the constrained use of SOAP, HTTP,
and XML. For instance SOAP over SMTP is clearly
non-conformant
(BP
1.0a R0001 --> R2401 (R2702) --> R1141(R1140) R4004 R2800 &
R2801
Let us
take a step back for a moment.
It
seems to me that if we do accept BPEL instance run time interoperability as
a major goal (and as I have stated above I think that is an issue the TC should
explicitly decide on) then there are two extreme ways to achieve this - and
probably a spectrum of options in between.
At one
extreme you specify just one way of doing something and everyone has to
implement all that is specified in the complete stack. Nothing is optional
to implement and the meaning of everything is made as clear as possible
(this is always good independent of the approach!). Not everything has to
be used on each instance of communication but this is the only kind of
optionality permitted. It must always be possible to initiate a
communication and get an understandable response (which is why only one way is
supported in this case SOAP over a particular HTTP style and SOAP over SMTP is
not supported). This is the approach taken by the WS-I
BP.
Pro: The approach has worked well in the past. Con: It
limits flexibility in the cause of interoperability.
The
other extreme is specify whatever might be reasonably implemented and used, and
to let partners agree which particular set of options they will use for
communication between them. This is essentially the approach used for EDI
(through Message Implementation Guidelines) and this approach has been brought
up to date in ebXML with the concept and use of a CPA. The CPA is an
agreed format configuration file that a group of partners agree to apply to
their systems when engaging in the specified business process(es). It can
be agreed manually or semi-automatically. It fixes the options to be used
for those instances of communications and different CPAs can be applied
dynamically if required.
Pro: Allows flexibility in specification and implementation.
Con: Automation of this approach is relatively new and it would require
the development of a CPP/A for web services (the existing ebXML one could be
used as a basis if it was modularised so that unwanted modules could be omitted
and new web service relevant ones introduced)
In
between these two extreme there is an approach that specifies a basic
communications stack that must always be implemented, which allows the dynamic
negotiation of additional features on any instance of
communication.
Variations on these major possibilities are clearly possible such as
having 2 or 3 (or more, but a small number) of 'Basic Profiles' and a very
simple pre- communication agreement mechanism (slim line CPA) to agree which to
use.
I
think this is the territory we have, perhaps somewhat unwittingly, strayed into
with the raising of the application of the WS-I BP, or not.
Best
Regards,
Tony
Tony
Fletcher
Technical
Advisor
Choreology
Ltd.
68, Lombard Street, London EC3V 9L J
UK
Phone:
+44
(0) 870 7390076
Mobile:
+44
(0) 7801 948219
Fax:
+44
(0) 870 7390077
Web:
www.choreology.com
Cohesions™
Business
transaction management software for application
coordination
Work:
Home:
-----Original Message-----
From: Ugo Corda
[mailto:]
Sent: 01 October 2003
18:55
To: Satish Thatte; Prasad Yendluri
Cc: BPEL
OASIS
Subject: RE: [wsbpel] Issue 47 and WS-I BP
1.0
I see a few
separate issues/questions connected to the relationship of BP 1.0 and
BPEL.
1- Would BP
1.0 be restricting BPEL to the point that some of BPEL's functionality would
not be available?
I cannot think of
any such restriction off the top of my head.
2- Would the fact
that BP 1.0 only addresses the SOAP/HTTP binding imply that also BPEL should
be limited to that type of binding?
I don't think that
anybody would imply that.
3- Should a BPEL
process be offered as a Web service that is BP 1.0
compliant?
My answer would be
yes.
3- Would it be
fair to limit BPEL use to interacting with BP 1.0 compliant Web services
only?
My personal answer
would be yes. But I am a member of WS-I, and I understand other people might
have different answers.
Ugo
