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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > > 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: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > > > -- > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
