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 02:07:25 GMT
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). 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

Now axis2 codegen cannot handle the above scenario.

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 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).

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. JAX-RS allows users to annotate a parameter
saying that its a http header. Now the cleanest way to handle this is to
have multiple MR's, where the MR is fully aware of how to get this parameter
that the service needs. This cannot be done at the builder level cause the
builders work according to the schema of an incoming message (the fact that
this parameter is an http header is not described in schema, but it is
available in the axisBinding hierarchy).

Do you see its need now?


On Thu, Oct 30, 2008 at 12:26 AM, Glen Daniels <>wrote:

> The job of the MessageReceiver is to take a "normalized" message (i.e.
> something that looks like SOAP) and "do some valid work" with it - so this
> might mean mapping to a Java method and databinding, or calling out to a
> piece of hardware, or handing the contents of the body to a cached instance
> of a particular class.  It's the job of the earlier parts of the system -
> the transport code, the Builder, etc - to map the real wire message to the
> normalized form.
> If we're using the MessageReceiver to do things like pull data from query
> parameters, then I put forth that we've designed that system incorrectly,
> and should fix it.  Some earlier chunk of code should do this.
> Thanks,
> --Glen
> Sanjiva Weerawarana wrote:
>> Deepal, the REST "deserialization" requires one to know the binding to
>> know where to pull stuff from (query params, payload etc.). See WSDL 2.0
>> HTTP binding to understand how that works.
>> So that has to happen post-dispatch.
>> Sanjiva.
>> Deepal jayasinghe wrote:
>>> It is possible that a single POJO (for example) can offer both a
>>>> RESTful interface and a normal SOAP interface. In fact, that can
>>>> happen by having both JAX-RS and JAX-WS annotations on the same pojo.
>>> Well even without having those annotation we can expose a POJO as a SOAP
>>> and REST. I mean REST and SOAP just the wire format , internally what
>>> happen is everything get converted into SOAP and at the end POJO class
>>> receive a SOAP message.
>>>> We currently can't handle that because the message receiver is
>>>> associated with the AxisOperation and not BindingOperation. IMO that
>>>> was a mistake ..
>>> Well no , because BindingOperation introduced after the AxisOperation :)
>>> .
>>>> So what we talked about was to introduce the ability to set the MR on
>>>> the binding operation but to keep the ability to set it on the
>>>> operation itself. That allows us to be totally backwards compatible
>>>> but it solve the problem for wanting both a RESTful and a WS-* binding
>>>> for the same operation for example.
>>> I can not still understand why we need new MR , because at the core what
>>> we use is SOAP not anything else , and at the end I mean at the
>>> Transport sender level we serialize that to REST or SOAP. Which is done
>>> by Message formatters.
>>> -Deepal
>>>> Thoughts?
>>>> Sanjiva.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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


View raw message