[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Issue 25: Does binding.ws imply SOAP
Today, you don't need to point to a WSDL with binding.ws. The question we
need to answer is what to do when there is no WSDL? What WSDL binding
should be generated? Is a SOAP binding generated only when the SOAP intent
is specified? What is the default when there are no intents?
Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
Anish Karmarkar
<Anish.Karmarkar@
oracle.com> To
sca-bindings@lists.oasis-open.org
06/26/2008 02:56 cc
AM
Subject
Re: [sca-bindings] Issue 25: Does
binding.ws imply SOAP
I took an AI some time ago to clarify issue 25 [1].
I don't exactly remember the context wrt what I was supposed to clarify,
but from the email discussion it seems clear that the issue is well
understood (at least to some folks). So, I'll add my 2 cents (aka rant)
regarding the issue and a proposal.
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.
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.
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).
Comments?
-Anish
--
[1] http://www.osoa.org/jira/browse/BINDINGS-25
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]