Thanks, Davanum, I shall that out.

I'm generally snowed under with existing SOAP-based work and I really like
Axis handler functionality for things like user authentication. I haven't
even got around to checking out what SOA has to offer yet. I am half
expecting to run across some must-have aspect of SOAP that stops me moving
to REST in the future but currently I find a URL-referenced XML document
world enticing.


Jeff


----- Original Message ----- 
From: "Davanum Srinivas" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, June 29, 2005 11:37 AM
Subject: Re: REST again


If you are hooked to REST, check out Axis2. Plan is to do both in Axis2.

-- dims

On 6/28/05, Jeff <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Some of my customers use REST. Initially, I thought that it was a little
> dumb, given the possibility of orthogonal services from SOAP. I came to
the
> conclusion a few months ago that REST is actually better than SOAP for
many
> situations! I still use Axis daily but for future projects I am likely to
> stop. Here's why...
>
> First of all, I only ever write document-literal web services. I prefer to
> move documents around because they are something that have more of a
> tangible existence than mere parameters. I am happy using non-Axis
> technologies to read/write XML payloads, I don't need the Axis data model.
> That is not sufficient reason not to use Axis, of course.
>
> Consider signing and encrypting SOAP messages: upon receipt the payload is
> extracted by decryption and the signature is checked BUT thenceforth the
> security has gone. In my situation it's better to sign and/or encrypt
> documents so that when SOAP envelopes are discarded I still have security.
I
> can move documents around at will and their original signature is in
place.
>
> Routing SOAP messages is a good example of an orthogonal service that SOAP
> provides but how many people actually use routing? I guess SOA stuff does.
> Those people who need routing can just as easily redirect URLs in REST.
>
> As I said, I started off convinced that SOAP was the way to go and,
without
> any pressure from any REST person, I came to the conclusion that REST is
> simpler and better. Here's what pushed me over the edge: when using
document
> payloads, the documents often reference other documents but for such
things
> to work seamlessly with SOAP we have to think about endpoints and all that
> stuff. With REST, we simply have another URL. In the REST world, all
> resources are readily accessible as URLs and this simplicity provides a
more
> uniform environment without losing functionality.
>
> As originally conceived, SOAP provided a way for doing RPC over the web
and
> was driven by the desire for Microsoft to achieve the platform
independence
> of Java without actually having to support other platforms. For RPC that's
> still valid. For documents, we already have a document-centric
> infrastructure provided by HTTP.
>
>
> Jeff
>
>
> ----- Original Message -----
> From: "Richard Wallis" <[EMAIL PROTECTED]>
> To: <[email protected]>; "Anne Thomas Manes" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 29, 2005 11:09 AM
> Subject: RE: REST again
>
>
> To quote a famous tennis player "You can not be serious!"
>
> Having defined an implementation independent interface to a service
> [using WSDL] and built functionality to deliver it [greatly helped by
> the auto-generation of objects by wsdl2java] having the inputs & outputs
> validated by the underling Axis-SOAP infrastructure you are suggesting
> that the best way to get at the same service via a different protocol is
> to go off and recreate the core functionality.
>
> Apart from the obvious can of worms you would be building up for future
> code maintenance, the fact that the XML output from a REST service call
> would be identical to the contents of the envelope body from its SOAP
> equivalent leads one to consider that there should be a massive
> opportunity for reuse here.
>
> I have been thinking about this since my original posting, whilst
> digging around in the Axis code base especially in areas such as
> AxisServlet.doGet(), and org.apache.axis.transport.http.QSMethodHandler
> [which almost does what I want except it makes some strange assumption
> that the service method and the root data element of the request body
> have the same name].
>
> It should not be too difficult to create QSMethodHandler equivalent
> which maps url parameters to a SOAP request body [based upon the wsdl
> for the relevant service] and then call the service within the currently
> running Axis engine.  In the same way extracting the contents of the
> response body and returning that as the REST response should not be too
> difficult.  Or am I being naive?
>
> If I'm not being naive, I would be willing to take a look at doing it
> but would need some help from members of the community who know their
> way around the code line far better than I do.
>
> Thoughts, comments, and offers of help ?
>
> Richard.
>
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]
> > Sent: 28 June 2005 12:27
> > To: [email protected]
> > Subject: Re: REST again
> >
> > REST works on the assumption that your applications are
> > working directly with the XML and not attempting to map Java
> > objects to XML.
> > If your assignment is to provide the same service in REST,
> > then you should in fact recreate all the functionality, but
> > this time using DOM in your application rather than mapping
> > everything to objects.
> >
> > Anne
> >
> > On 6/22/05, Richard Wallis <[EMAIL PROTECTED]> wrote:
> > > Following the 'Start with the WSDL!' principle of web service
> > > development, I have produced a successful service which
> > works in both
> > > Axis & .net, greatly helped by the classes produced by wsdl2java.
> > >
> > > So far so good.  Now I have a requirement to provide the
> > same service
> > > via REST.  Being lazy I don't want to recreate all the
> > functionality
> > > so intend to directly call the service method in the auto-generated
> > > xxSoapBindingImpl class.  I can easily create the correct Object to
> > > pass as a parameter.
> > >
> > > The problem I next have is to be able to create a response XML
> > > Document from the Object returned from the method.  Axis
> > must do this
> > > when it is creating the response SOAP Body.
> > >
> > > Does anyone know how I can easily access this functionality.
> > >
> > > Richard.
> > >
> > >
> > > Register your interest now
> > > Insight 2005 : 15th & 16th November
> > > Register your interest now http://www.talis.com/events
> > >
> > >
> > >
> > > Any views or personal opinions expressed within this email
> > may not be those of Talis Information Ltd. The content of
> > this email message and any files that may be attached are
> > confidential, and for the usage of the intended recipient
> > only. If you are not the intended recipient, then please
> > return this message to the sender and delete it. Any use of
> > this e-mail by an unauthorised recipient is prohibited.
> > >
> >
> >
>
>
> Register your interest now
> Insight 2005 : 15th & 16th November
> Register your interest now http://www.talis.com/events
>
>
>
> Any views or personal opinions expressed within this email may not be
those
> of Talis Information Ltd. The content of this email message and any files
> that may be attached are confidential, and for the usage of the intended
> recipient only. If you are not the intended recipient, then please return
> this message to the sender and delete it. Any use of this e-mail by an
> unauthorised recipient is prohibited.
>
>


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Reply via email to