Hi Anish,
Thanks for writing this up.
Anish Karmarkar wrote:
48633D85.50407@oracle.com" type="cite">The
history of binding.ws is in supporting SOAP. Since SOAP bindings in
general are described by WSDL, it did not make sense to reinvent WSDL
in SCA. So we decided to just point to a WSDL document along with a few
default values for the case where either there wasn't a WSDL to point
to or it was thought that generating the WSDL for the simple case was
putting too much burden on the developer/assembler.
One other variant is not necessarily to point at the WSDL, but to
inline the relevant parts in the SCA element. Perhaps that detail is a
distraction, though.
48633D85.50407@oracle.com" type="cite">
So now we have a binding.ws which is WSDL based and can
describe/specify anything that WSDL can. Keep in mind that WSDL is
meant to be extensible wrt bindings. So this means it can describe
pretty much anything. This is unlike the other bindings, for example,
binding.jms where the conformance is clear and very narrow. Conformance
to binding.ws is not. Knowing that a particular runtime supports
binding.ws does not give you any confidence that it will support a
particular WSDL binding pointed to by binding.ws OR that it would
support a SOAP binding described using WSDL (which was the original
intent). IOW the conformance criteria for claiming that a runtime
supports binding.ws is weak.
In the email discussion that has occurred on this issue, two things are
being mixed: interoperability and portability. This issue is not about
interoperability. Yes, binding.ws is going to be SCA's answer to
interoperability. But that is not because binding.ws is going to be
consumed directly by entities outside of SCA that we want to
interoperate with. Such entities will see the WSDL not binding.ws. It
is the WSDL and the associated non-SCA "standard" WSDL bindings that
are going to provide interoperability.
To continue on interoperability, providing a WSDL or even a WSDL SOAP
binding does not necessarily guarantee interoperability, it just
increases the chances of it. For example, the WSDL may have the "wrong"
version of SOAP, the WSDL itself may be the wrong version. It may have
policies in it that are not recognized; it may have WSDL extensions in
it that are not recognized. Typically, the WSDL consumer will look at
the WSDL, process it and decide if the endpoint described by the WSDL
is something that it can talk to.
Wrt portability, as it is defined now, having binding.ws in a SCDL
means that you have to find out not just whether the target runtime
supports binding.ws but also the WSDL binding that binding.ws points
to. If we want to provide a generic WSDL-based binding, there isn't a
way around this.
Proposal:
I see three ways to address this issue:
1) status quo. Lot of flexibility and capability. When deploying such a
binding, one will have to do more work to find out exactly what the
target runtime supports.
2) constrain binding.ws to just SOAP. This would mean that the
conformance requirement for the binding will have some teeth and is
meaningful. Of course there are still no guarantees as the WSDL SOAP
binding may have policies or extensions (eg: a policy that says
WS-Trust is required) that are not supported by the runtime or the
runtime may decide to support SOAP 1.1 and not 1.2. This would mean
'alwaysProvides=soap' must be true for this binding. If we go down this
path I would prefer to rename it binding.soap to make it clear what the
binding is about.
Having discussed this internally, and read through the email thread, I
think I end up with #2.
The key questions for me come back to what the use-cases are for having
a generic WSDL binding? What are the use-cases for having a SOAP
specific binding? If, as Anish suggests, a generic WSDL binding is not
really doing much to improve interoperability or improve portability,
why exactly do we want it, again? And I happen to agree with Anish
that it doesn't improve interoperability or portability.
Given an SCA composite file, it seems like it is a "good thing" to be
relatively specific in modeling what a binding is about. I've brought
this up in the context of the generic operation and data-binding
problem as part of the JMS and JCA bindings. In this context, the same
argument comes back again - shouldn't we be explicit in saying this
defines a use of SOAP by saying "binding.soap." The upsides are
numerous:
- Tighter conformance - must support SOAP 1.1
- WSDL generation description can be explicitly about a well known
binding
- References to WS-I profiles all make sense in all cases
- Developer gets a much clearer understanding of what they get.
It might even make sense to go slightly "tighter" in the definition,
and instead of being "binding.soap", call it "binding.soap_http".
Either that, or binding.soap can be controlled by policy to indicate
which transport *must* be used. I've had discussions at TIBCO with
Sabin, that followed to the extreme,
we could/should instead repackage the "binding.jms" element as a
standard WSDL binding. There's no theoretical limitation against that
that I'm aware of. If you're
resistant to it, that suggests to me that you already recognize that
discriminating at the SCA level, rather than relying
on WSDL to call out the differences, has some significant value. The
key question here:
What are the rules-of-thumb that might push one to define a new SCA
binding, rather than a new WSDL binding? Some answers:
- Using a WSDL binding implies predetermining binding choices. As
a consequence, you may want to define a new SCA binding whenever you
think you might want to define a new policy that controls the binding
(see our current policies that affect SOAP). We could, for example,
think of defining policies for JMS that preclude certain types of
messages (StreamMessage).
- Whenever you change the semantics of the metadata around a
binding. For example, the JMS binding has radically different data
binding questions to answer due to the differences in payload types
(binary and streamed data, vs. XML) as compared to a SOAP binding.
- When your message transport vehicle changes. I immediately
thought of four obvious different message transports: JCA (none
defined), JMS (pure API), SOAP ("layered" on top of existing
protocols), and REST (implies HTTP, uses MIME types, usually uses XML).
- When your "binding" is to an API, rather than to a protocol (JMS,
JCA, Axis2).
- When the quality of service changes dramatically as a result of
the choice. For example, a "binding.smtp" solution has all sorts of
problems with request/reply operations, reliability, and security,
which, while independently all have solutions, collectively the
"solutions" to make this transport choice equivalent to binding.jms
might end up being extremely expensive
I note, for example, that the entire discussion around WSDL generation
has been with respect to SOAP, and even more specifically with respect
to SOAP over HTTP. If we were genuinely considering this as a generic
WSDL binding, we'd be looking seriously at custom WSDL bindings that
we've each encountered, such as the existing SOAP/JMS bindings that you
can find. We're not, so I'm skeptical that the binding.ws is anything
more than a SOAP/HTTP binding. And that's from someone who has been
working on SOAP/JMS for years, so I have reason to be skeptical.
48633D85.50407@oracle.com" type="cite">
3) Create two different bindings binding.soap and binding.ws.
binding.ws would be as it is right now and binding.soap would be as
described in (2). binding.ws in this case then would not support the
default (for SOAP) that we have now.
My preference: Option (1). I like the idea of having a generic
binding.ws that is WSDL based. This means a lot of things can be
supported: WSDL soap 1.1 binding, WSDL soap 1.2 binding, WSDL http
binding etc. This also means that if there is new WSDL binding defined,
we don't need to rev the SCA specs. For example, a WSDL binding
description for SOAP over JMS and SOAP over UDP is likely to happen in
the future. So I prefer the status quo. Wrt portability of binding.ws
that points to WSDL SOAP binding, all one has to check is whether the
target runtime supports binding.ws with 'soap' intent. My second
preference would be (3).
I'm not convinced by the argument about "we don't have to change the
SCA specs." Anyone who introduces a new WSDL binding could equally
well define an new SCA binding element. Vendors are highly likely, and
highly motivated to do this, for differentiation, if nothing else.
Burying the change in the WSDL doesn't make SCA any more or less
flexible, although I think it does make it harder for us vendors to
figure out what is going on in an SCA composite.
48633D85.50407@oracle.com" type="cite">
Comments?
None whatsoever. ;-)
-Eric.
|