[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] [Issue 2] Scope of our charter and ws-callback[was: Proposal version 3: How to implement SCA callbacks using SOAP]
David Booz wrote: > Thanks again Anish. I still don't buy your argument about charter scope > WRT normative text, but we can put that aside for a moment. > Starting a different thread (with a different subject) so as to not mix the technical and scope arguments. I checked the charter [1]. It does say the following: "Note that the list of out-of-scope features and mechanisms is not exhaustive. In general, areas that are not explicitly listed as within the scope should be considered as out-of-scope." So, for something like ws-callback to be in scope, it (the functionality) has to be explicitly listed in the charter. In the scope section it says: "The TC will not explore areas with general applicability and for which typically standards exist." WS-Callback is of general applicability, but there isn't a standard around. There is a spec [2] for it, but it has been superseded by WS-Addressing W3C Recommendation. This sentence in itself doesn't put ws-callback in scope, but the charter goes on to say: "For each binding specification, the TC shall identify the applicable subset and specify solutions accordingly." and then goes on to list a bunch of things that are in scope. One of which is: "Support for bi-directional and conversational interfaces (as defined in the SCA Assembly specification)" This arguably puts this in scope. Interpretation may of course differ. I think, if the TC really wants to do this there are ways of clarifying the charter. My opinion is that, if we want to do this, we should do this right: create a separate spec that specifies the protocol and the metadata (WSDL extensibility, WS-Policy) associated with it. There is nothing about it that is SCA specific. I don't see why we would not want this to interop with other non-SCA systems. For interop (within SCA or outside of SCA), the spec needs to be well-defined and not a spec by example. Decoupling it from the SCA spec sends the right message to the WS community and will receive review from the right people. Burying a WS-* spec (which is really what we are writing, independent of whether it appears in some appendix or a standalone spec) in an SCA binding spec when it is not SCA-specific will mean that lot of WS-Heads will miss it and is an under-the-radar way of getting a WS-* spec out. I would propose that we should either do it as a separate spec or not do it at all. I do understand the schedule argument and I don't think we need to put this spec on the same schedule as the rest of the SCA specs. My 2 cents. -Anish -- [1] http://www.oasis-open.org/committees/sca-bindings/charter.php [2] http://www.w3.org/Submission/2004/SUBM-ws-messagedelivery-20040426/#callback-pattern > Is the following allowed given your proposal? I think it is, just want > to check. The S messages in your examples look too much like traditional > responses, something which we need to be sensitive to. And in case > anyone asks, R is not multi-threaded. > > R invokes YouRIt(). Let's call this invocation R4 and it sets the > callback address to RC3. > R invokes YouRIt(). Let's call this invocation R5 and it sets the > callback address to RC3. > S then calls NoYouRIt(): S6. > > R4: > > <soap:Envelope ...> > <soap:Header> > <wsa:From> > <wsa:Address>_http://example.com/callback-yetanother_ > <http://example.com/callback-other></wsa:Address> > <wsa:ReferenceProperties> > <myNS:SomeID>3</myNS:SomeID> > </wsa:ReferenceProperties> > </wsa:From> > <wsa:MessageID>urn:uuid:f81d4fae-10dec-11d0-a765-00a0c91e6bf6</wsa:messageID> > ... > </soap:Header> > <soap:Body> > ... > </soap:Body> > </soap:Envelope> > > R5: > > <soap:Envelope ...> > <soap:Header> > <wsa:From> > <wsa:Address>_http://example.com/callback-yetanother_ > <http://example.com/callback-other></wsa:Address> > <wsa:ReferenceProperties> > <myNS:SomeID>3</myNS:SomeID> > </wsa:ReferenceProperties> > </wsa:From> > <wsa:MessageID>urn:uuid:f81d4fae-11dec-11d0-a765-00a0c91e6bf6</wsa:messageID> > ... > </soap:Header> > <soap:Body> > ... > </soap:Body> > </soap:Envelope> > > S6: > > <soap:Envelope ...> > <soap:Header> > <wsa:To>_http://example.com/callback-yetanother_ > <http://example.com/callback-other></wsa:To> > <myNS:SomeID>3</myNS:SomeID> > <wsa:RelatesTo > RelationshipType=_"http://docs.oasis-open.org/opencsa/sca-bindings/callback"_> > urn:uuid:f81d4fae-10dec-11d0-a765-00a0c91e6bf6 > </wsa:RelatesTo> > ... > </soap:Header> > <soap:Body> > ... > </soap:Body> > </soap:Envelope> > > > > Dave Booz > STSM, BPM and SCA Architecture > Co-Chair OASIS SCA-Policy TC and SCA-J TC > "Distributed objects first, then world hunger" > Poughkeepsie, NY (845)-435-6093 or 8-295-6093 > e-mail:booz@us.ibm.com > > Inactive hide details for Anish Karmarkar ---10/29/2008 07:51:53 > PM---Attached. I have converted the HTML version to Word, so tAnish > Karmarkar ---10/29/2008 07:51:53 PM---Attached. I have converted the > HTML version to Word, so that it is easy for folks > > > From: > Anish Karmarkar <Anish.Karmarkar@oracle.com> > > To: > OASIS Bindings <sca-bindings@lists.oasis-open.org> > > Date: > 10/29/2008 07:51 PM > > Subject: > [sca-bindings] [Issue 2] Proposal version 3: How to implement SCA > callbacks using SOAP > > ------------------------------------------------------------------------ > > > > Attached. > I have converted the HTML version to Word, so that it is easy for folks > to comment and make inline changes. > > The big change between v2 and v3 is the addition of faults. My initial > inclination was to define our own faults, but it turns out WS-Addressing > has some pre-defined faults which fit our purpose. So, I have reused > those faults. > > One thing I'm not clear on is whether the TC wishes to define this > SOAP-specific callback mechanism as *one* of the ways callbacks can be > implemented when using SOAP or *the* way callbacks are implemented when > using SOAP. My inclination is to say *the* way, otherwise we have to > invent ways (metadata such as policySets, ws-policy assertion, WSDL > extension, Java annotation) to convey when it is required. > > Comments? > > -Anish > -- > /(See attached file: > SCA-bindings-issue2-proposal-v3.doc)/--------------------------------------------------------------------- > 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 > > > ------------------------------------------------------------------------ > > --------------------------------------------------------------------- > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]