> -----Original Message-----
> From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
> Sent: 2006?9?13? 23:35
> To: [email protected]
> Subject: Re: Binding Context?
>
>
> 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.
>
Not sure if I have got the idea. Can we take a more concrete example? Lets say
my interface type is wsdl, a corresponding method in my java component is as
below:
public String getGreetings(String name);
in order to access HTTP query info (this can be useful for a rest service), do
you mean I need to define my method like below?
public String getGreetings(String name, @Autowire String query);
or
@Autowire
public void setQuery(String query) {
this.query= query;
}
As what available from context can be anything, I am not sure what strategy
should be used to extract specific attribute from context then wire it into
component. According to the Autowire attribute name? For example, if I specify
an Autowire attribute named query, I shall expect there is an attribute named
query in the context and its type is String?
> >
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
