OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi Jim,

One response below:

Jim Marino wrote:
93448C76-AE7F-4E24-B27C-65BFC5DE3FE5@gmail.com" type="cite">
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?

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.

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.

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

93448C76-AE7F-4E24-B27C-65BFC5DE3FE5@gmail.com" type="cite">

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]