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: tony.fletcher@choreology.com
|
Home:
amfletcher@iee.org |