Re: [sca-bindings] Issue 124: SCA WSCB protocol conformance

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Yes, I'll come up with a proposal.

-Anish
--

On 3/8/2010 3:18 AM, Simon Holdsworth wrote:
>
> Anish,
>
> Would you be able to turn your suggestion into a more formal proposed
> resolution? This is now the only open issue against the WS binding spec
> so we need a proposal if we want this resolved prior to the next CD/PR
>
> Thanks, 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 - Simon_Holdsworth@uk.ibm.com
>
> Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote on 04/03/2010 17:05:25:
>
>  > [image removed]
>  >
>  > Re: [sca-bindings] Issue 124: SCA WSCB protocol conformance
>  >
>  > Anish Karmarkar
>  >
>  > to:
>  >
>  > sca-bindings
>  >
>  > 04/03/2010 17:11
>  >
>  > On 3/4/2010 5:24 AM, Simon Holdsworth wrote:
>  > >
>  > > 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.
>  >
>  > That's what section 6.x and 6.y would do. A WSCB service/client does not
>  > necessarily have to be an SCA runtime.
>  >
>  > > 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.
>  >
>  > Yes, that's the idea. In any case, that is what I had in mind. There
>  > might be better ways of dealing with this, but we are getting into
>  > solution space.
>  >
>  > -Anish
>  > --
>  >
>  > > 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 - Simon_Holdsworth@uk.ibm.com
>  > >
>  > >
>  > > From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
>  > > To: OASIS Bindings <sca-bindings@lists.oasis-open.org>
>  > > 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/
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  >
>  > ---------------------------------------------------------------------
>  > 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/
>
>
>
>
>
>