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?
</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.
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.
-Eric.
|