Re: [sca-bindings] Issue 25: Does binding.ws imply SOAP

[Mike Edwards <mike_edwards@uk.ibm.com>]

Folks,

Comments inline as <mje>...</mje>

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

Simon Holdsworth/UK/IBM@IBMGB

06/06/2008 11:28

To	"OASIS Bindings" <sca-bindings@lists.oasis-open.org>
cc
Subject	Re: [sca-bindings] Issue 25: Does binding.ws imply SOAP

I think there may be more to binding.ws than purely being able to express
things in WSDL.  Folks could reasonably expect that binding.ws would
be the place where you would find support for WS-* defined capabilities,
e.g. WS-RM, WS-AT, WS-Security etc., whereas you would not expect those
to be available in binding.jms or binding.jca (or whatever else).  While
none of these mandate SOAP, in practice they typically only have a SOAP
binding standardised, so would not really be useable in the absence of
SOAP. 

<mje> I agree with
this view.  <binding.ws/> IS where the use of WS-* specs would
be expected to be found.
However, I am wary of saying
that <bindng.ws/> implementations MUST support particular WS-* specifications,
due to the wide range of
implementations and devices that we're looking to support.

I could live with a requirement
to support WS-I Basic Profile, and, if supporting Security features at
all, a requirement
to support WS-I Basic Security
Profile - but I note that this implies support for HTTP and SOAP is required....
</mje>

I'm pretty much in agreement with Mike's list below, however I do feel
that a stronger statement is required for use of binding.ws - that all
implementations that support binding.ws MUST support the use of the binding.ws
element with no WSDL document, and therefore MUST support SOAP 1.1 or 1.2
and MUST support HTTP.  Otherwise the capability of the binding becomes
more vague and SCA runtime vendors will end up having to define a profile
that defines which aspects of binding.ws are supported and which are not.
 Having said that there will always have to be such a profile that
defines what WSDL bindings are supported and which are not.  Ideally
in many cases developers should just be able to say <binding.ws/>
when exposing web service endpoints, and know that this will be supported
on the target SCA runtime in a way that is interoperable with SCA references
that also use <binding.ws/>. 

<mje> I agree that
there is a tension here and that maybe we should give interop a higher
level of importance than flexibility.

I was thinking of the case
where you have a JMS implementation that supports SOAP over JMS.  That
looks like it can support
<binding.ws/> - unless
there is also a requirement that you support SOAP over HTTP too, which
then drags in the need for an
HTTP stack too.  In
which case you have to build a hybrid binding implementation that combines
the 2 stacks, which bulks the
code.  Maybe we need
a "plugin" design for the implementation of <binding.ws/>
to permit different underlying protocols to be
plugged in as desired.

I am also noodling about
the REST case.  That may best be handled by <binding.rest/>
or <binding.http/> or whatever - there
is no guarantee of a WSDL
in these cases (WADL or no interface description???).  If this is
the case, then we don't need to
bend <binding.ws/>
to accommodate it....

</mje>

If we don't take this approach we could end up with a situation where the
JMS binding is more interoperable than the WS binding ;-)

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 - Simon_Holdsworth@uk.ibm.com

Mike Edwards/UK/IBM@IBMGB

02/06/2008 08:52

To	"OASIS Bindings" <sca-bindings@lists.oasis-open.org>
cc
Subject	Re: [sca-bindings] Issue 25: Does binding.ws imply SOAP

Folks, 

I agree with the general direction advocated here:

1) <binding.ws/> implies a WSDL-related binding

2) <binding.ws/> SHOULD imply a SOAP binding

3) <binding.ws/> WITHOUT an explicitly supplied WSDL MUST support
SOAP & HTTP 

4) An implementation of binding.ws MAY implement a limited subset of WSDL
bindings - and the list of supported 
bindings MAY exclude SOAP and MAY exclude HTTP 

5) SOAP support, when present, MUST include EITHER SOAP 1.1 OR soap 1.2,
both preferably... 


I also agree with the need to have a RESTful binding.  
Who would like to work on a spec for such a binding? (I'm looking for volunteers)


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

Bryan Aupperle <aupperle@us.ibm.com>

30/05/2008 16:27

To	sca-bindings@lists.oasis-open.org
cc
Subject	[sca-bindings] Issue 25: Does binding.ws imply SOAP

I was persuaded by Simon N.'s comment about keeping binding.ws as flexible
as possible, but I also recognize the interoperability concern.  Following
from that, I believe that we could reasonably take the following position:

- binding.ws requires an interface described by WSDL (either explicitly
or implicitly) with no restriction on WSDL binding from an SCA standpoint.
 Any given implementation MAY limit the WSDL bindings it supports

- A new binding (binding.http?) is needed for RESTful interfaces that are
not described with WSDL - as Anish pointed out use of WSDL is objectionable
to many REST supporters. 

This does waken the concept that binding.ws is guaranteed to be interoperable
since we no longer know that a SOAP binding is provided, but I believe
that if we have the alternative binding that a significant percentage of
the binding.ws implementations would support a SOAP binding.  If we
wanted to be clear about this we could state that implementations of binding.ws
SHOULD support a SOAP binding. 

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect

Research Triangle Park,  NC 
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

---

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

---

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

---

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