[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Issue 124 proposal version 2
> Anish, > originally I had thought that you intended to provide this context > within > section 6. I don't see it there, and I don't see it addressed > anywhere > else. Perhaps I just missed it. > No you didn't miss it. Actually, even though you explained this concern on the last call, I forgot the details/subtleties when I started looking at it to address comments from the last concall. I should do my AIs right after the call :-( Let's chat on the call in a few minutes. -Anish -- On 3/25/2010 5:18 AM, David Booz wrote: > Commenting only on: > >>> * wrt Dave's comment about BWS5005/7, I'm not sure what needs to change. > > I added a sentence at the beginning of section 5.1 that says that WSCB > service implements the forward interface and the WSCB client implements > the callback interface. > > The conundrum that I see is the conflation of runtime and application > responsibilities depending on the perspective from which you read section > 5. Let's start with the text in BWS50005 as Anish has currently written > it. > > BWS50005: When the WSCB Service invokes the callback interface, it MUST use > the Callback EPR from a request message that invoked the forward interface. > > Earlier in that section, WSCB Service is defined as: a Service that > implements the SCA bidirectional interface using Web services (WSCB > Service) > > In the SCA world, the thing that implements the bidirectional SCA interface > is an application, not the runtime. When the term WSCB Service is used in > BWS50005 within the context of an SCA world, then I argue that BWS50005 > doesn't make any sense because BWS50005 is giving instructions to a runtime > not to an application, yet the definition of WSCB service is pointing to an > application. > > However, in the non-SCA world, the definition of WSCB Service seems > reasonable because outside the scope of SCA the separation between runtime > and application is unknown, and in fact one of those two concepts might not > even exist. As a result, BWS50005 seems fine when read in a non-SCA > context. > > Given that we want non-SCA runtime providers to be able to implement this > protocol without getting confused about what and who implements each piece > of it, then I suggest that what Anish has written in section 5 is fine. > What we need is another section which can put section 5 into context for an > SCA runtime, that is, an SCA centric perspective on section 5. Anish, > originally I had thought that you intended to provide this context within > section 6. I don't see it there, and I don't see it addressed anywhere > else. Perhaps I just missed it. > > > 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 > > > |------------> > | From: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |Anish Karmarkar<Anish.Karmarkar@oracle.com> | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | To: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |sca-bindings@lists.oasis-open.org | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Date: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |03/24/2010 05:54 PM | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Subject: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |Re: [sca-bindings] Issue 124 proposal version 2 | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > > > > > > Version 2 based on feedback from last week's call is attached. > > * Fixed editorial bugs pointed out by EricJ in section 6. > > * I did some due diligence on the question of whether creating > independent conformance points for WSCB service/client results in a > problem (as pointed out by EricJ), since the other non-section5 > conformance items are no longer applicable to WSCB service/client. I > found 5 assertions that are somewhat related (noted below). The others > are about binding.ws syntactic elements/attributes or something similar. > > a) there is MUST for SOAP 1.1 and a SHOULD for SOAP 1.2. Section 5 also > talks in several places about SOAP header blocks. Strictly speaking > there is no necessity to require SOAP (1.1 or 1.2) for this protocol. It > could depend only on WS-Addressing. But that is a separate issue. To fix > this, I have changed the intro to 5.1 to state that this is a > soap/ws-addressing based protocol. I didn't see a reason to introduce > assertions for requiring SOAP/WS-A. It is required by definition. But if > ppl feel strongly we can introduce new conformance items. > > b) There is a requirement for conforming to SCA assembly and policy. I > don't think this is needed (it would defeat the purpose of the issue > itself). > > c) There is a SHOULD for http endpoints to provide a wsdl description > when queried with ?wsdl and a SHOULD for non http endpoints to provide > some way to obtain the WSDL descriptions. I didn't see a need to have > this requirement on WSCB service/client endpoints. I see this as a SCA > runtime requirement not a protocol requirement. > > * wrt Dave's comment about BWS5005/7, I'm not sure what needs to change. > I added a sentence at the beginning of section 5.1 that says that WSCB > service implements the forward interface and the WSCB client implements > the callback interface. > > Comments? > > -Anish > -- > > On 3/18/2010 9:01 AM, Anish Karmarkar wrote: >> Proposal for issue 124 as outlined in [1] is attached. >> >> -Anish >> -- >> >> [1] > http://lists.oasis-open.org/archives/sca-bindings/201003/msg00000.html >> >> >> >> --------------------------------------------------------------------- >> 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 > [attachment "sca-wsbinding-1.1-spec-cd03-rev2_issue124v2.doc" deleted by > David Booz/Poughkeepsie/IBM] [attachment > "sca-wsbinding-1.1-spec-cd03-rev2_issue124v2.pdf" deleted by David > Booz/Poughkeepsie/IBM] > --------------------------------------------------------------------- > 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]