Anish,
fwiw my preference is to go ahead and
open this issue so we can discuss the potential resolution.
In terms of what we say about non-SCA
runtimes in your proposed solution, it looks like we are defining two new
conformance targets, and then saying that the SCA runtime must conform
to the statements for each of these, there's nothing what you say below
about stating conformance for non-SCA runtimes. I assume that a non-SCA
runtime could then just refer to this section in the spec and state that
they provide a conformant WSCB Client and WSCB Service as defined in the
WS binding spec section 6.X. I'd be OK with that, as opposed to the
WS binding spec specifically talking about non-SCA runtimes.
Regards, Simon
Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair,
AT&T and Boeing Lab Advocate
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet -
From:
Anish Karmarkar <>
To:
OASIS Bindings <>
Date:
04/03/2010 07:38
Subject:
[sca-bindings] Issue 124: SCA WSCB protocol
conformance
Here are the reasons why I think we need to provide
WSCB-specific
targets and conformance statements:
1) We have relied on WS-* as our route to interoperability when it comes
to SCA. This is one of the key reasons why WS Binding is required for
any SCA runtime.
2) SCA WSCB is a WS-* protocol: it is SOAP/WSDL/Policy based providing
a
functionality on top of those specs.
3) One of the primary reasons for non-binding.sca is to talk to entities
outside a domain. Just within a domain the need for non-binding.sca is
weak at best; after all binding.sca is magic and you can do anything you
want.
4) If we want services and references that use bi-directional interfaces
to be usable from outside the SCA domain, and I'm arguing that we most
certainly do, then it is important that we say exactly what is required
from the implementer of the SCA WSCB protocol. A conformance criteria is
more important for protocols than for systems (like SCA) that focus on
portability and not interoperability). Experience from other protocol
standards suggests that achieving interop on the wire is not easy and
therefore anything that we do to provide clarity wrt conformance would
greatly enhance interop.
One question that was asked on email/previous call was: what would my
proposal be for resolving this issue. I would suggest something along
the lines of:
a) add two new targets. Something like WSCB Service and WSCB Client.
b) refactor numbered stmts in section 5 to use these targets where
appropriate. I don't think this would be too difficult. For example,
BWS50005 current says:
"When the service implementation invokes the callback interface, it
MUST
use the Callback EPR from a request message that invoked the forward
interface."
this would have to be changed to:
"When the --> **WSCB Service** <--- invokes the callback interface,
it
MUST use the Callback EPR from a request message that invoked the
forward interface."
c) Add two new sections 6.x and 6.y for the two new targets (Section 6
is about conformance) and in those section say " ... to conform the
target MUST comply with all statements in Appendix C related to ..."
similar to what we have done for other targets.
d) In section 6.2 SCA Runtime, change bullet 2 and 3 as follows:
"2. The implementation MAY support the SCA Web Services
Callback
Protocol. If it does, it MUST be a compliant WSCB Service and a
compliant WSCB Client.
3. The implementation MAY support the SCA Web Services Callback
Protocol in conjunction with WS-MakeConnection. If it does, it MUST be
a
complient WSCB Service and compliant WSCB Client and it MUST comply with
the requirements of WS-MakeConnection."
-Anish
--
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to 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
