[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Issue 124: SCA WSCB protocol conformance
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/ > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]