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? 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.
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.
Cheers,
Jervis
> -----Original Message-----
> From: Peter Cousins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 13, 2006 7:49 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Binding Context?
>
>
> Jeremy Boynes wrote:
>
> > What concerns me is leaking wiring information to the component
>
> > implementations. That basically violates the entire goal of SCA
> assembly as
>
> > it puts wiring and infrastructure back into application code.
>
> >
>
> > What Peter is describing sounds more like an "infrastructure"
> component
>
> > (tied to the IT structure) rather than true "business"
> (application)
>
> > function. One could say that the application here is an IT one and
> wants the
>
> > entire JMS/SOAP/XML/RMI message - and that the "application" in this
> case is
>
> > wiring-aware (e.g. an RMI mediator may not work well with a SOAP
> message).
>
> >
>
> > I think this can be done using normal SCA components whose service
>
> > interfaces have parameters that are "IT data objects" - for example,
> Peter's
>
> > router could be passed a SDO DataObject containing the full message
> (with
>
> > headers) or an alternative implementation could be passed a JAXB
> object. It
>
> > could flow that on by invoking the appropriate target reference
> passing the
>
> > same or a mutated object.
>
> >
>
> > There is a separate issue about flow-through context that transfers
> from a
>
> > inbound request to an outbound one. However, this is state managed
> totally
>
> > by the framework and would never need to be exposed in the
> application
>
>
> > programming model.
>
> >
>
>
>
> I agree that business application logic should not use this context
> information. Ideally, there would support for users to write simple
> plugins that could run inside the call context as aspects (in the AOP
> sense). Only the aspects would access the context, and these would
> cross cut but supplement the application code. This is
> useful not only
> for routing but for security, version management, compression, context
> propagation, HA and load balancing strategies, pay per use
> billing, and
> so on.
>
>
>
> This would allow a middle ground between applications components that
> shouldn't use this, and "being managed totally by the
> framework", which
> is a less flexible way to manage such information...PC
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
