Re: [sca-bindings] Response to: "Microsoft technical comment: Developinteroperable approach notspecific to SCA for callbacks"

[David Booz <booz@us.ibm.com>]

Jim,

Not to be too pedantic, but the TC cannot decide "to work with other stakeholders in a dedicated TC to define an interoperable standard" because that's outside the scope of this TC. But the members of the TC can agree to do this on a member by member basis (which I believe they would) in some forum or context that is outside the scope of this TC.

The only choices the TC have are either a) status quo or b) remain silent on wire level callback specification. The TC has decided not to wait the 2-3 years for (b) to arrive. You need to convince the TC that waiting is better than having nothing at all. That's the only thing the TC can meaningfully discuss.

FWIW, I agree with your definition of interop.

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

Jim Marino ---10/19/2009 08:43:38 PM---Hi Eric, Comments inline.

From:	Jim Marino <jim.marino@gmail.com>
To:	OASIS Bindings <sca-bindings@lists.oasis-open.org>
Date:	10/19/2009 08:43 PM
Subject:	Re: [sca-bindings] Response to: "Microsoft technical comment: Develop interoperable approach notspecific to SCA for callbacks"

---

Hi Eric,

Comments inline.

Jim

On Oct 16, 2009, at 2:42 PM, Eric Johnson wrote:

Hi Jim,

One response below:

Jim Marino wrote:
2) I suspect that if we went down the road of standardizing a generalized callback mechanism in some new TC, that it would take quite some time to complete.

Yes, I think it would definitely take more time.

Are you happy for there to be no defined way of providing SCA callbacks over Web services for a significant amount of time - with the probable consequence
of vendors building SCA runtimes simply each implementing their own way of doing things in the interim?
</mje>


To be clear, I think it is important to note that the current mechanism does not define an interoperable mechanism for handling callbacks/ bidirectional communication for SCA services. What it defines is a way for an SCA client component hosted in one runtime implementation to invoke a bidirectional service offered by an SCA component hosted in another vendor runtime. IMO, this is of very limited value given that if the current mechanism is used, the target service will not be callable by anything other than an SCA client or a client that directly implements the SCA-specific protocols.

I guess I'm completely confused by your definition of "interoperable". It seems like your definition of interoperable means "works with absolutely everything, without any work." By your own comments, the already defined protocol will work amongst any and all SCA runtimes, and further will interoperate with any client that bothers to understand the specification.

In my opinion, claiming that the SCA callback protocol is interoperable is a stretch. By "interoperable" I mean a platform-independent way of communicating with services. Today, interoperability is defined in a de facto manner by the common set of WS-* standards the major software vendors implement. Based on this definition, I tend to think of interoperability as fairly black-and-white. Either a technology stack is interoperable or it is not. 

In contrast, what the SCA Web Services binding and WCF have done is define proprietary extensions to enable specialized interaction patterns (callbacks/duplex service) that are currently not handled in a standardized manner by WSDL or WS-* specifications. In my opinion, neither of these approaches are interoperable because they do not meet the requirements outlined by the above definition.

So I conclude that there's absolutely nothing defined here that prevents interoperability. To the contrary, this protocol definition is instead built on top of a well-known set of existing specifications.

This argument seems a bit odd. SCA has defined a protocol based on a particular use of WS-* standards that no other technology stack supports, including .NET and the various Java-based programming models (e.g. JAX-WS and Java EE). I don't think it is fair to say the protocol is interoperable. Sure, those other technologies could adopt that approach. However, with that line of reasoning, it would be possible to claim a proprietary binary protocol is interoperable because it is built on TCP (a standard) and other technology platforms could implement it.

Granted, we don't have "universal" interoperability, but I don't know what that would mean.

Interoperability currently is defined by the set of WS-* standards adopted by major technology platforms. Granted, not all WS-* standards are supported by all platforms, but it is fair to say in order for a protocol to be labeled interoperable, it needs to be supported by all the major technology platforms.

That said, I think the alternative of defining this in a non-interoperable way is much worse. It solves the limited use case mentioned above but will lead to serious long-term migration issues for end-users. I think it is safe to say the proposed mechanism will need to be changed if it is to be interoperable. Even in the hypothetical case where the SCA approach is adopted wholesale by other platforms, the namespaces and way of representing callbacks would need to be changed to fit into a more general approach. If the current approach is adopted, there is the real potential that an interoperable approach will be needed later that is incompatible with the former. Existing deployments that used the current approach and switched over to the interoperable approach would either require mediation or duplicate services to avoid breaking existing clients. From a vendor perspective, this would require runtimes to support both approaches for a very long time.

If the current callback mechanism was removed, this would mean there would be no standardized way for a bidirectional service to be called by an SCA client hosted in a different runtime implementation over a Web Service protocol. Given the above scenario, I think this is a good thing for end users. Basically, it requires them to use interoperable mechanisms for communicating outside a domain over Web Services protocols, which would mean services need have either request-response or simple one-way operations. While this inhibits the very specific use case mentioned above, it avoids a migration issue down the road and allows time for a proper mechanism to be defined based on input from other stakeholders (i.e. technology platforms).
An enumeration of possible choices I think we have:
• Do nothing - leave the current spec as is. (partial interoperability now)
• Separate the "callback" specification from the binding.ws spec, but still keep it specific to SCA (partial interoperability now)
• Defer any support of "callback" until an officially blessed "callback" standard exists, apart from SCA (no interoperability now, universal interoperability later)
• Forgo many of the semantics around callbacks from the assembly spec, thus mooting the question.
Did I miss a case?

It seems to me like partial interoperability now is always a better bet than universal interoperability later, because we never know when "later" will be, and whether later will actually achieve the aspirations we pinned on it.

I would phrase the choices differently since I would argue there is no such thing as partial interoperability. Either a runtime is interoperable or it is not. Also, placing the callback mechanism into a separate spec would simply be an administrative change and not impact end-users or SCA as a technology. Consequently, I don't see any real difference between the first two choices.

Basically, I think the choice is between:

a. Maintaining the status quo where SCA defines a protocol for handling callbacks that is not interoperable with non-SCA technologies
b. Agreeing to work with other stakeholders in a dedicated TC to define an interoperable standard that can be used to enable SCA callbacks and other similar interaction patterns in other technology stacks such as WCF

I've already outlined why I think option a is bad for both end-users and vendors in my response to Mike Edwards so I won't reapeat them here.

Jim