You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2008/10/29 15:22:05 UTC
supporting multiple message receivers for a given operation
This is an issue Keith and I discussed (a while ago) and I don't think I
saw it on the list .. I just remembered it hence the sudden email (no
particular urgency on it; it just came up).
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.
We currently can't handle that because the message receiver is associated
with the AxisOperation and not BindingOperation. IMO that was a mistake ..
the detail of how you take the message and construct the data is really
binding dependent and should've been on binding operation in the first
place. (Well we didn't have binding ops in the first place .. so that's
the reason they never went there.)
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.
Thoughts?
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: supporting multiple message receivers for a given operation
Posted by Davanum Srinivas <da...@gmail.com>.
That makes sense. thanks keith.
-- dims
On Wed, Oct 29, 2008 at 11:21 PM, keith chapman <ke...@gmail.com> wrote:
> Hi Dims,
>
> I had a look at JAX-RS and thought of starting on it. Thats where this
> discussion popped up. I was thinking of sending a mail on this to the dev
> list (regarding support for JAX-RS). Currently in order to write a RESTfull
> Service in Axis2 you have to deploy your service using WSDL 2.0 [1] but if
> we have JAX-RS support that will make life easy for users.
>
> Thanks,
> Keith.
>
>
> [1] http://wso2.org/library/3726
>
> On Thu, Oct 30, 2008 at 7:45 AM, Davanum Srinivas <da...@gmail.com> wrote:
>>
>> Keith,
>>
>> Can it wait till we actually decide to do JAX-RS? Why do we need it
>> now in other words, is there an effort to enhance WSDL2Java more to
>> handle these situations?
>>
>> thanks,
>> dims
>>
>> On Wed, Oct 29, 2008 at 10:07 PM, keith chapman <ke...@gmail.com>
>> 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). 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.
>> >
>> > 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?
>> >
>> > Thanks,
>> > Keith.
>> >
>> >
>> > On Thu, Oct 30, 2008 at 12:26 AM, Glen Daniels <gl...@thoughtcraft.com>
>> > 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: axis-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Keith Chapman
>> > Senior Software Engineer
>> > WSO2 Inc.
>> > Oxygenating the Web Service Platform.
>> > http://wso2.org/
>> >
>> > blog: http://www.keith-chapman.org
>> >
>>
>>
>>
>> --
>> Davanum Srinivas :: http://davanum.wordpress.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>
>
>
> --
> Keith Chapman
> Senior Software Engineer
> WSO2 Inc.
> Oxygenating the Web Service Platform.
> http://wso2.org/
>
> blog: http://www.keith-chapman.org
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: supporting multiple message receivers for a given operation
Posted by Amila Suriarachchi <am...@gmail.com>.
Hi Kieth,
On Thu, Oct 30, 2008 at 8:51 AM, keith chapman <ke...@gmail.com>wrote:
> Hi Dims,
>
> I had a look at JAX-RS and thought of starting on it. Thats where this
> discussion popped up. I was thinking of sending a mail on this to the dev
> list (regarding support for JAX-RS). Currently in order to write a RESTfull
> Service in Axis2 you have to deploy your service using WSDL 2.0 [1] but if
> we have JAX-RS support that will make life easy for users.
If your requirement is to support POJOs with SOAP and REST interfaces I
think you can support it at message receiver level.
As I remember Sanka did this change to support binding level security
polices. The message receiver is associated with the AxisOperation. But
MessageContext object it receives has the BindingOperation with it.
Here I think if the binding is given in the url using ServiceName.PortName
it uses the specified binding and if not get the Soap 12 binding default.
So at the message receiver you can process according to the Binding
Operation. You can change the RPCMessageReceiver or create a new message
receiver (say POJOMessageReceiver ) and delegate the correct message
receiver there.
I think this makes minimal changes to Axis2 while supporting your
requirement.
thanks,
Amila.
>
> Thanks,
> Keith.
>
>
> [1] http://wso2.org/library/3726
>
>
> On Thu, Oct 30, 2008 at 7:45 AM, Davanum Srinivas <da...@gmail.com>wrote:
>
>> Keith,
>>
>> Can it wait till we actually decide to do JAX-RS? Why do we need it
>> now in other words, is there an effort to enhance WSDL2Java more to
>> handle these situations?
>>
>> thanks,
>> dims
>>
>> On Wed, Oct 29, 2008 at 10:07 PM, keith chapman <ke...@gmail.com>
>> 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). 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.
>> >
>> > 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?
>> >
>> > Thanks,
>> > Keith.
>> >
>> >
>> > On Thu, Oct 30, 2008 at 12:26 AM, Glen Daniels <gl...@thoughtcraft.com>
>> > 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: axis-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Keith Chapman
>> > Senior Software Engineer
>> > WSO2 Inc.
>> > Oxygenating the Web Service Platform.
>> > http://wso2.org/
>> >
>> > blog: http://www.keith-chapman.org
>> >
>>
>>
>>
>> --
>> Davanum Srinivas :: http://davanum.wordpress.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
>
> --
> Keith Chapman
> Senior Software Engineer
> WSO2 Inc.
> Oxygenating the Web Service Platform.
> http://wso2.org/
>
> blog: http://www.keith-chapman.org
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: supporting multiple message receivers for a given operation
Posted by keith chapman <ke...@gmail.com>.
Hi Dims,
I had a look at JAX-RS and thought of starting on it. Thats where this
discussion popped up. I was thinking of sending a mail on this to the dev
list (regarding support for JAX-RS). Currently in order to write a RESTfull
Service in Axis2 you have to deploy your service using WSDL 2.0 [1] but if
we have JAX-RS support that will make life easy for users.
Thanks,
Keith.
[1] http://wso2.org/library/3726
On Thu, Oct 30, 2008 at 7:45 AM, Davanum Srinivas <da...@gmail.com> wrote:
> Keith,
>
> Can it wait till we actually decide to do JAX-RS? Why do we need it
> now in other words, is there an effort to enhance WSDL2Java more to
> handle these situations?
>
> thanks,
> dims
>
> On Wed, Oct 29, 2008 at 10:07 PM, keith chapman <ke...@gmail.com>
> 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). 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.
> >
> > 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?
> >
> > Thanks,
> > Keith.
> >
> >
> > On Thu, Oct 30, 2008 at 12:26 AM, Glen Daniels <gl...@thoughtcraft.com>
> > 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: axis-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> >>
> >
> >
> >
> > --
> > Keith Chapman
> > Senior Software Engineer
> > WSO2 Inc.
> > Oxygenating the Web Service Platform.
> > http://wso2.org/
> >
> > blog: http://www.keith-chapman.org
> >
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
Re: supporting multiple message receivers for a given operation
Posted by Davanum Srinivas <da...@gmail.com>.
Keith,
Can it wait till we actually decide to do JAX-RS? Why do we need it
now in other words, is there an effort to enhance WSDL2Java more to
handle these situations?
thanks,
dims
On Wed, Oct 29, 2008 at 10:07 PM, keith chapman <ke...@gmail.com> 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). 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.
>
> 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?
>
> Thanks,
> Keith.
>
>
> On Thu, Oct 30, 2008 at 12:26 AM, Glen Daniels <gl...@thoughtcraft.com>
> 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: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>
>
>
> --
> Keith Chapman
> Senior Software Engineer
> WSO2 Inc.
> Oxygenating the Web Service Platform.
> http://wso2.org/
>
> blog: http://www.keith-chapman.org
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: supporting multiple message receivers for a given operation
Posted by keith chapman <ke...@gmail.com>.
Deepal see my comments inline...
On Thu, Oct 30, 2008 at 7:57 AM, Deepal jayasinghe <de...@gmail.com>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
users.
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
> JAX-RS.
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.
Thanks,
Keith.
>
>
> Thank you!
> Deepal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
Re: supporting multiple message receivers for a given operation
Posted by Deepal jayasinghe <de...@gmail.com>.
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.
> 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. 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 :)
>
> 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 ? 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
JAX-RS.
Thank you!
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: supporting multiple message receivers for a given operation
Posted by keith chapman <ke...@gmail.com>.
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
REST.
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?
Thanks,
Keith.
On Thu, Oct 30, 2008 at 12:26 AM, Glen Daniels <gl...@thoughtcraft.com>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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
Re: supporting multiple message receivers for a given operation
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Dude, the details of such mapping is dependent on the actual service at
hand. Again, see WSDL 2.0 HTTP binding (which you know). How do you
propose handling that before the service is determined?
Yes, we can do it in a handler that runs post-dispatch. And the difference
between that and the MR is ??
Sanjiva.
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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: supporting multiple message receivers for a given operation
Posted by Deepal jayasinghe <de...@gmail.com>.
> 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.
Yes , I agree with you. When it come to the MR you should have
everything you need in the OMElement. If the service need some more data
it can take that from the message context.
Deepal
>
> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thank you!
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: supporting multiple message receivers for a given operation
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: supporting multiple message receivers for a given operation
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: supporting multiple message receivers for a given operation
Posted by Deepal jayasinghe <de...@gmail.com>.
> 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.
--
Thank you!
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org