Dave,
You've identified one of the sub-issues
of BINDINGS-25, namely whether conformant implementations have to support
the use of the bare <binding.ws/> element. Which begs a broader question
- does a conformant implementation have to support all valid expressions
of the binding schema. The opposite view might be an implementation
that ONLY supports <binding.ws/> and does not allow you to point
to a WSDL document - does that break conformance? That's down to
us to define I guess as part of our conformance statements, either via
a broad statement or through conformance statements that address each case
individually.
My preference is also to keep the status
quo. The opposite approach that I have some sympathy with would be
to say that in theory any SCA service can be described in WSDL, regardless
of the type of binding on the SCA service, so why should we have a special
binding.ws. Just use binding.soap, binding.jms, etc. and allow all
of those to be configured by or to publish WSDL descriptions. Indeed, I
would hope that over time the number of SCA bindings that can be described
in WSDL will increase, as I believe that that should be the public representation
of services that is exchanged with non-SCA runtimes. What you lose
there is the flexibility of WSDL extensions to describe something that's
outside of the current set of supported bindings - you have to create a
new SCA binding for each new WSDL binding, something we did discuss early
on with the concensus that that was not desirable.
Another aspect of this discussion was
raised by Mike E, I think, which is whether the binding definition implies
a constraint on the access provided to the component to which the service
is wired. So if I wire a component to an SCA service with binding.ws,
and I have an intent that requires encryption, does a conformant implementation
have to guarantee that that component can only be accessed via suitably
encrypted web service invocation? Or is it simply saying that when accessed
via the endpoint corresponding to the service/binding configuration, encryption
must be used, with the runtime at liberty to provide alternative endpoints
with different access methods and constraits?
So I think the questions we have to
answer to fully resolve this issue and the WSDL generation are:
1) Does every conformant implementation
have to support the bare <binding.ws/> element?
2) Do we want to change the description
of the bare <binding.ws/> element so that it does not always provide
SOAP?
3) Does every conformant implementation
have to support referencing existing WSDL documents?
4) Is a conformant implementation limited
to exposing access to a service only in the manner described by that service's
bindings?
Regards, Simon
Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet -
David Booz <>
26/06/2008 13:21
To
cc
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:
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
Anish Karmarkar
<Anish.Karmarkar@
oracle.com>
To
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
---------------------------------------------------------------------
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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
