axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: supporting multiple message receivers for a given operation
Date Thu, 30 Oct 2008 10:18:14 GMT
That makes sense. thanks keith.

-- dims

On Wed, Oct 29, 2008 at 11:21 PM, keith chapman <keithgchapman@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 <davanum@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 <keithgchapman@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 <glen@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


Mime
View raw message