← Prev in month ← Prev in thread

Re: [sca-bindings] [Issue 2] Proposal version 3: How to implement SCAcallbacks using SOAP

From
David Booz <>
Date
2008-10-30T13:27:33+00:00
ID
Thread
Re: [sca-bindings] [Issue 2] Proposal version 3: How to implement SCAcallbacks using SOAP
I appreciate the work you've done here Anish.  In no way do I mean to diminish your work.

But I feel the need to point out, again, that I think this work goes beyond what our charter allows in that it is defining a protocol.  Your observation that this is a WS-Callback spec makes my point.  A WS-Callback spec is exactly the right way to address the issue.  It's just out of our scope.

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:

Anish Karmarkar ---10/29/2008 07:58:40 PM---I forgot to mention that when this proposal is combined with Mike's idea  of defining a WSDL extensi

From:

Anish Karmarkar <>

To:

OASIS Bindings <>

Date:

10/29/2008 07:58 PM

Subject:

Re: [sca-bindings] [Issue 2] Proposal version 3: How to implement SCA callbacks using SOAP

I forgot to mention that when this proposal is combined with Mike's idea 

of defining a WSDL extension to indicate the callback interface (similar 

to the @Callback Java annotation), what we have is a WS-Callback 

specification (I know, yet another WS-Splat spec). Such a spec could be 

a stand-alone spec independent of SCA and would result in non-SCA 

systems being able to talk to SCA services that offer bi-directional 

interfaces.

-Anish

--

Anish Karmarkar wrote:

> 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

> -- 

> 

> 

> ------------------------------------------------------------------------

> 

> ---------------------------------------------------------------------

> 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
← Prev in month ← Prev in thread