axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "keith chapman" <>
Subject Re: supporting multiple message receivers for a given operation
Date Thu, 30 Oct 2008 03:35:42 GMT
Deepal see my comments inline...

On Thu, Oct 30, 2008 at 7:57 AM, Deepal jayasinghe <>wrote:

> keith chapman wrote:
> > Let me clarify the need for multiple MR's. If we think of codegen, as
> > of now Axis2 generates the serverside code based on the portType of a
> > WSDL (It does not take the binding into consideration).
> Well that is the idea , binding is for the client side not for the
> server side, at the server side what we need to care is the porttype.

This was the initial design and it had to be that because Axis2 did not have
the concept of a binding hierarchy, but now it does have that concept so why
not use it?
I think your missing my point. Yes a service is binding independent (It
should not care whether a parameter was present in the url, soap body, http
header or even a JMS header) but the MR should be binding dependent. The MR
is the guy who should know where to pluck the parameter off in order to
inject it into the service.

> > Imaging a user has a WSDL such that the response SOAP message should
> > have a custom SOAP header when the request is SOAP 1.1 or 1.2 and a
> > custom http header when the request is REST.
> Well , you should not forget that Axis2 is transport independent ,
> meaning at the service level it does not have any idea how the request
> came and how the response should be serialized.

I already answered this above. The service will always be transport
independent and it should.

And Axis2 is a SOAP
> engine and we have support for REST . We do not need to make it a REST
> engine.  :) , so REST related serialization should be at the transport
> level , you may have all the necessary data in the MC.
> >
> > Now axis2 codegen cannot handle the above scenario.
> Well it can handle SOAP scenario :)

Not unless the user writes a module. If we had the concept of multiple MR's
codegen could have handled this easily which means we take the burden off

Codegen can handle this on the client side very nicely cause it is aware of
bindings. For e.g If the WSDL said that a particular operation needs a http
header named foo the operation in the stub would have foo as a parameter.
The fact that it is not a part of the payload and is an http header is
hidden in the implementation details of the stub. This is what I'm proposing
that we do for the service too.

> >
> > Now the only way to do this as of now is to write a module and then do
> > the checks within that module and add these headers, but these are
> > really binding details of a service and the AxisBinding
> This is exactly the right way to do , I mean REST is an extension in
> Axis2 , so the idea or module is  to handle extensions.
> > hierarchy contains these details and it should have been the
> > responsibility of the MessageReceiver to do this. That means we have a
> > MR per binding or a single MR with a lot of if conditions (I prefer
> > having a MR per binding).
> hmm , what happen if we start to generate JMS binding , then do we need
> to have some other MR for that ?

Well I didn't intend to say that "YOU MUST ALWAYS HAVE A MR PER BINDING"
what I mean is you "SHOULD" be able to. And the default case should work as
it is.

> I think answer is no . And before
> calling the AxisEngine everything has to be converted into a SOAP message.

> >
> > This is where the need for multiple MR's come in.
> >
> > Glen/Deepal I agree that taking parts off the path/query/body and
> > binding the SOAP infoset is part of the builder but imaging this
> > situation. Think of having JAX-RS support in Axis2.
> Well we do not need to talk about that since we do not have support for

See my reply below. We do need to talk about this cause this is the start of
the discussion as to how we could bring JAX-RS support into Axis2.


> Thank you!
> Deepal
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.


View raw message