That makes sense. thanks keith. -- dims
On Wed, Oct 29, 2008 at 11:21 PM, keith chapman <[EMAIL PROTECTED]> 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 <[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 > -- Davanum Srinivas :: http://davanum.wordpress.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
