On Sep 13, 2006, at 7:50 AM, Liu, Jervis wrote:
Hi, I understand there is an on-going process in the spec group to
define a JAX-WS integration with SCA, it would be interesting to
look into this context issue from the aspect of JAX-WS services.
According to JAX-WS spec, a thread local WebServiceContext object
needs to injected into an endpoint if it is declared as below:
1 @WebService
2 public class Test {
3 @Resource
4 private WebServiceContext context;
5
6 public String reverse(String inputString) { ... }
7 }
In this case, do we consider the availability of WebServiceContext
to JAX-WS endpoint as an information leak?
Yes. Simply because it couples this application component to the
binding. For example, this probably will not work (well) with other
bindings.
What we have here is no longer a POJO but a JAX-WS-JO.
Secondly, how does the context flow through inbound and outbound?
The context info required by Peter is normally available from
specific bindings(http, jms etc), I can see a following context flow:
binding specific context object -> sca context -> JAX-WS
WebServiceContext.
If you remove infrastructure context from the application programming
model then flow-through can be handled by the container. This has a
whole bunch of advantages such as maintaining integrity of the caller
identity, inter-binding transformations (e.g. WS-Security -> CSIv2,
XML->JSON, etc.). By definition, it's not part of the application model.
However, if the application code wants that info then the programming
model should allow it to express that as a dependency (as it is one).
One simple method is to allow the user specify that in the service
contract e.g. as a parameter on the component's interface. One good
thing about SCA is that the service contract on either end of a wire
does not have to be identical, just compatible.
IMO, to support JAX-WS frontend in Tuscany, as long as the JAX-WS
endpoint declares a resource of WebServiceContext, it should be
Tuscany runtime's responsibility to propagate whatever context info
from binding specific context to a Tuscany context then inject it
into endpoint. For non-JAX-WS components, accessing context info
should be similar to JAX-WS, i.e., declare a context resource that
can be injected in the runtime.
Funny, I see it more the other way around. IOW, to support a JAS-WS-
JO then the user would use a JAX-WS component and it would be the job
of the JAS-WS container to set up the JAX-WS context. That would
include setting up a WebServiceContext as that is part of the JAX-WS
programming model. What the frontend is to that (e.g. say its RMI) is
irrelevant. However, for the two to be wirable the runtime needs to
be able to map the semantic content between the two.
That mapping becomes easier the more information that the programmer
gives to the runtime. For example, Peter's routing component may not
need transaction or security information, just the destination
address. If it had a way of declaring that then the container would
not need to map the unused information and that might make his
component generally more useful (never mind simpler and more robust).
Ideally, the runtime would be able to figure out what the component
actually needed without the programmer having to explicitly specify
it; one way to do that is through making things available though
constructs natural to the programming language.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
