Hi Jim,
I have some questions on your following comment: <Jim>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. <Jim>
What do we mean by a more general approach here? I thought
that SCA approach is intended to be the more general and standardized approach
and if there are any technical issues in that we should identify and address
them. If the callback functionality from the SCA WS binding specification were
made available in a modular manner so that it can be used independently in a
standalone manner (without requiring the use of the entire SCA WS binding spec),
would that be the solution here? As far as the namespace (for the callback
functionality) is concerned, whether it is defined by a SCA TC or some other
new TC, how does it matter? Namespaces are supposed to be opaque anyways! Or am
I missing something? It has become hard (for me) to sort out the dialogue in
the below email thread.
Sanjay
From: Jim Marino
[mailto:jim.marino@gmail.com]
Sent: Friday, Oct 16, 2009 3:57 AM
To: OASIS Bindings
Subject: Re: [sca-bindings] Response to: "Microsoft technical
comment: Develop interoperable approach notspecific to SCA for callbacks"
Hi Mike,
Sorry for the delay but I've been traveling
again....Comments inline.
On Oct 13, 2009, at 3:52 PM, Mike Edwards wrote:
Folks,
Thanks to Jim
for these comments - they help the debate here.
I've put
comments inline as:
<mje>....</mje>
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
|
From:
|
Jim
Marino <jim.marino@gmail.com>
|
|
To:
|
OASIS
Bindings <sca-bindings@lists.oasis-open.org>
|
|
Date:
|
10/10/2009
22:24
|
|
Subject:
|
Re:
[sca-bindings] Re: [sca-bindings-comment] Response to: "Microsoft
technical comment: Develop interoperable approach notspecific to SCA for
callbacks"
|
Hi,
Comments inline...
Jim
On Oct 7, 2009, at 7:42 PM, Eric Johnson wrote:
Here are my immediate thoughts,
in response, for the TC's consumption:
Michael Champion wrote:
Thank you for considering Microsoft's
suggestion for improving the SCA Web Services Binding spec's interoperability (http://www.osoa.org/jira/browse/BINDINGS-87).
We suggested that Web Services
callbacks in the SCA Web Services Binging spec should interoperate with
comparable frameworks such as JAX-WS and WCF, and not be limited to various
implementations of SCA. This would promote the original goals of the Web
Services standards to achieve wire-level interoperability among diverse
run-times and platforms.
I'm unaware of anything in
JAX-WS that addresses callbacks, so I don't understand that point, or how it is
comparable. Nor am I aware of anything that we've specified that prevents
a vendor from using JAX-WS to implement callbacks support within the SCA
environment. Presumably implementation experience will reveal details
here?
I have run into a number of difficulties trying to integrate SCA callbacks with
WCF services (specifically, duplex services, see next comment) for a client.
Basically, the way SCA represents callbacks at the protocol level (in WSDL and
on the wire) is not interoperable with WCF. The only way to make these types of
interactions work is to introduce proprietary behavior in an SCA runtime to
support WCF's protocols.
<mje>
So, Jim, do you want to make it an objective that
the SCA Web service binding should be capable of interoperating with the WCF
callback protocol?
Separately, do you want to make the SCA Web services
callback protocol the same as the WCF callback protocol?
To answer the first question, I'd like
mandatory interoperability for the Web Services binding based on
basic profile and for any other capabilities specified by the binding (e.g.
policies) to always support interoperability (otherwise, call it something
other than "Web Services"). For example, if the binding specifies how
callback interactions are manifested, I'd like that to use an interoperable
rather than specific SCA mechanism. While an SCA specific callback mechanism
may add value to the use case where an SCA component needs to talk to a
bidirectional SCA service hosted on a different runtime implementation, I think
it will be extremely limited. This is because the target service will not be
interoperable and will only be callable by another SCA client. In contrast, if
the Web Services binding used an interoperable mechanism for callbacks, the
target service would be callable by other SCA components hosted in different
runtime implementations as well as clients such as .NET, non-SCA BPEL, JAX-WS,
etc. Another advantage to this approach is it would make the development
experience much easier as it is more likely for tooling such as wsimport (JDK)
and SrvUtil (.NET) to support generating proxies for these types of services.
In terms of the second question, my preferred approach would
be to form a separate TC that took as input ideas from the Web Services binding
spec as well as WCF. I have some ideas on how this might look we could explore.
A
separate question: is the WCF callback protocol standardized in any way?
</mje>
Not to my knowledge although it uses standardized
"protocols" (a combination of WS-Addressing and WS-RM).
With
respect to WCF, I'm not aware of its capabilities, and whether or not it
provides anything equivalent to the callback functionality of SCA. Does
anyone else on the TC have insight into this?
The analog of SCA callbacks in WCF is duplex services, which provide
bidirectional communication. One difference between WCF duplex services and SCA
callbacks are the former are stateful. That is, the WCF client instance
originating the forward call will receive callbacks. Prior to the deferral of
conversational services, SCA conversational callbacks could be used to model
this functionality.
<mje>
As far as SCA interoperation is concerned, I forsee
2 cases of interest:
a) WCF client talking to an SCA service which has a
callback
b) SCA client talking to a WCF service with a
callback
Yes although other non-SCA clients and services could be
involved.
a) could be remodelled in WCF as
a stateless client that offers a service which is has the callback interface of
the SCA service
- this clearly is not the same as current WCF
callbacks, but it is a potential practical approach
b) gives the problem that the WCF service may have a
business interface that makes the assumption that there is out-of-band
data that ties the callback messages to a given
forward message. This is indeed tricky to deal with.
</mje>
At the protocol level, duplex services (which use the WCF duplex binding) rely
on WS-RM and sequence ids for correlation. In WSDL, WCF represents duplex
services as a a form of solicit-response with an output/input sequence.
<mje>
For SCA at the binding level, in principle this
could be handled by a particular policy specification which would mandate the
use of WS-RM etc.
This does not solve the statefulness problem of b)
above
</mje>
I'm approaching this from the view that a user wants to
create a bidirectional service which is interoperable and does not place
platform-specific demands on clients. We could define a mapping from SCA
to .NET and vice versa but that wouldn't really be interoperable since it would
require clients to be either SCA or .NET.
At the wire level, what we've
describe remains interoperable and compatible. Seems to me like the
actual issue is at the protocol level.
At the wire level, things as they currently stand are not strictly
interoperable because SCA callbacks are stateless and WCF duplex services are
stateful.
The SCA Binding TC responded
by saying that the SCA Web Services binding protocol "defines an *SCA* Web
service callback protocol standard” and that it "is not meant to
satisfy general purpose callback requirements with a broadest scope
possible". In other works, the TC believes that the SCA Web Services
callbacks will NOT be interoperable with non-SCA implementations
That sounds incorrect to me. Seems like it is completely out of scope for
an SCA TC to dictate how or if any standard outside of SCA reaches
compatibility with something inside of SCA. Nothing prevents other
implementations (Mike Champion's word choice) from achieving interoperability.
The TC's response goes on to
say that "This TC does believe that it should define an interoperable Web
services protocol that implements SCA callback and it has done that. It does
not believe that it is in the scope or interest of this TC to define a callback
protocol for all architectures and programming models." We respectfully
find this statement contradictory, unless the TC defines the term
"interoperability" in its narrowest form: SCA implementations will
only be interoperable amongst themselves, and not with other frameworks and
runtimes. We would find this unfortunate, as OASIS is committed to broad
interoperability, especially when it comes to use of Web Service wire
protocols. It would be better to standardize a Web Services callback in a
separate spec, with the participation of all vendors who build platforms and
products that support Web Services wire protocols.
Yes, we define interoperability amongst SCA runtimes (including from different
vendors), since that's within the scope of our charter. The
"narrowest" sense would be only interoperability among a single
vendor (see JMS itself, the "binding.sca" binding, and various
Microsoft networking protocols, at some point in time.). So I disagree
with the characterization of this as the "narrowest" possible form of
interoperability. Further, we don't deny the utility of a broad
specification, and yes, we believe interoperability at a larger scale would be
useful. It just isn't in our charter.
Is Microsoft explicitly requesting a change in charter? If so, they
should explicitly state that.
It is clear from [1]
that the TC is aware that interoperability with non-SCA runtimes is an issue.
The TC discussed the idea of moving the callback portion of the protocol into
its own document in order to address "the use case of non-SCA clients does
walk into the more general territory alluded to by MS." We highly
recommend that the Binding and Assembly TCs work together to design a Web
Services Binding spec that is interoperable with non-SCA technologies.
Without interoperability, software developers and users will find it
difficult to use SCA in the heterogeneous, multi-vendor environments that all
our customers live in.
Absolutely nothing here prevents vendors from building compatible systems with
both SCA and non-SCA parts that interact. In fact, we expect it.
Further, when bridging from a non-SCA environment to an SCA environment,
a vendor such as Microsoft should only have to implement compatibility with the
SCA WS Callbacks mechanism once, and it should work with all vendors providing
SCA environments. If they believe this last point is incorrect, it would
be enormously useful for Microsoft to identify the specific oversights of the
currently specified approach.
-Eric.
These last statements seem a bit odd. I thought one of the purposes of the web
services binding was to provide interoperability into and out of a domain.
For example, I think the requirement to integrate with WCF and non-SCA
software will be much more common than integration between different SCA vendor
runtimes. Of course, other systems could integrate with SCA by implementing
support for proprietary SCA protocols but that kind of defeats the purpose of
interoperability (a general integration mechanism).
It seems that Microsoft is proposing the SCA TCs not define a callback
mechanism and instead work jointly in some other TC to define an interoperable
protocol for bidirectional communication. If this is the case, such an approach
would provide a lot more value to end-users than a proprietary SCA mechanism
since it would allow SCA, WCF, JAX-WS, etc. to interoperate at a much deeper
level. Maybe this is something we should ask Microsoft if they would be
interested in pursuing?
<mje>
1) Are you proposing that we should remove the
current SCA callback description from the specification?
Yes, with the idea that a separate interoperable mechanism
will replace it.
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.
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).
|