Next in thread →
Next in month →
RE: [wsbpel] Issue 72 and WS-I BP 1.0
Title: Message
Tony,
What I said before
regarding the binding is that we can have a BP-compliant BPEL
deployment as long as such a deployment provides at least one
port with SOAP/HTTP binding. The same deployment could also support other ports
with bindings to MQSeries or whatever else (from your quote below: "it does
not preclude WSDL documents from containing non-conformant wsdl:binding
elements").
So it would still be
fine for us to say that we follow the BP 1.0 profile, and at the same
time talk about MQSeries bindings in our use cases, as long as the assumption is
that a SOAP/HTTP binding would also be provided by the particular deployment
described in our use case.
Ugo
-----Original Message-----
From:
Fletcher, Tony [mailto:]
Sent: Friday,
October 03, 2003 1:23 PM
To: Ugo Corda
Cc: BPEL
OASIS
Subject: RE: [wsbpel] Issue 72 and WS-I BP
1.0
Dear
Ugo,
Not
really. The point I was making is that one way to achieve a high
probability of interoperation between two or more independently implemented
systems is for the implementers to follow specifications that have no
options. So to achieve its goal the WS-I BP has to be very
restrictive. If it has get out clauses - and implementers make use of
them then it does not achieve its goal. There are alternative
approaches to achieving interoperability that I suggested and these include a
basic 'no-options' communications stack and the ability to negotiate the use
of other functions / features dynamically at run time, and a flexible approach
coupled with the use of 'agreements' between groups that wish to interoperate
for a particular purpose (which is essentially the CPP/A
approach).
So
complying with the BP whilst using something else that SOAP over HTTP is a
side issue. But while we are on it perhaps you could explain it in more
detail as I still do not see it. Please refer to the trail of
Requirements that I gave - see below. But in particular I
read:
5.5.1 Use of SOAP Binding
The Profile limits the choice of bindings to the well defined and most
commonly used SOAP binding. MIME and HTTP GET/POST bindings are not permitted
by the Profile.
R2401 A
wsdl:binding element in a DESCRIPTION MUST use WSDL SOAP Binding
as defined in WSDL 1.1 Section 3.
Note that this places a requirement on the construction of conformant
wsdl:binding elements. It does not place a requirement on
descriptions as a whole; in particular, it does not preclude WSDL documents
from containing non-conformant wsdl:binding
elements
This
seems to make the requirement fairly clear. It says elsewhere that only
only Rnnnn statements count when it comes to considering conformance.
The note is purely informative but that says you can include other kinds of
binding in a WSDL document but they are non-conformant.
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: 03 October 2003
16:11
To: Fletcher, Tony
Cc: BPEL
OASIS
Subject: RE: [wsbpel] Issue 47 and WS-I BP
1.0
Hi
Tony,
It looks like
one of your major concerns about using BP 1.0 is its alleged prohibition of
using any WSDL bindings other than SOAP/HTTP. Please look at my previous
notes for my elaboration on this subject.
Ugo
-----Original Message-----
From: Fletcher, Tony
[mailto:]
Sent: Friday, October 03,
2003 7:11 AM
To: Ugo Corda
Cc: BPEL
OASIS
Subject: RE: [wsbpel] Issue 47 and WS-I BP
1.0
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:
Next in thread →
Next in month →