I cannot comment on why Apache SOAP implements messaging the way it does.
However, if you are concered about moving your code across different vendors, I
think you would want to target JAXM or JAX-RPC.  While Apache SOAP does not
support either of these, the follow on project, Axis, supports at least JAX-RPC,
and I would expect other SOAP implementations to migrate to these APIs.  The
JAX-RPC leverages some of the technology of RMI, while JAXM is quite like JMS
point-to-point.  While I personally like the approach taken in Apache SOAP RPC
(and that of other vendors) that one need not alter one's code to make it a
service, I will likely migrate to JAX-RPC within the year in the hope that I can
move my byte code across implementations.

Scott

----- Original Message -----
From: "Nilesh Kumar, Koratpallikar" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 6:51 AM
Subject: RE: Apache SOAP RPC vs SOAP Messaging


> Apache soap 2.2 comes with two flavors of writing server side soap services:
>
> 1] RPC Service(invoked by corresponding RPC client)
> 2] Messaging Service(invoked by corresponding Messaging client)
>
> I was trying to compare the way these two kinds of services must be written.
>
> RPC service doesn't necessarily have to use SOAP vendor specific code. The
> wrapper(may be the rpcrouter) takes care of forming SOAP envelopes, and
> sends it back to the calling RPC client
>
> where in Messaging service, the server code must be use SOAP vendor specific
> objects(e.g SOAPContext etc). I was wondering why is this so ? and cant the
> Message service be written independent of SOAP vendor specific objects, and
> the layer above that(messagerouter) take care of formulating SOAP envelop
> and sent it back to the calling Messaging client.
>
> I was trying to understand the interoperability aspect of it.
> i.e  I should be able to write the SOAP services independent of SOAP vendor
> specific objects, so that in future if I have to change my SOAP vendor, I
> dont have to change my server code
>
>
> -----Original Message----Apac-
> From: soap vamsi [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 24, 2002 2:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Apache SOAP RPC vs SOAP Messaging
>
>
> please clarify...
> what is the messaging server(SoapMsgServer) u are talking about?
> vamsi
>
> On Tue, 23 Apr 2002 Nilesh Kumar, Koratpallikar wrote :
> >I have a question related to the way Apache SOAP 2.2 was
> >engineered SOAP RPC
> >as against SOAP Messaging.
> >
> >If You look at the SOAP RPC server, there is nothing which ties
> >the server
> >code to SOAP specific API's.
> >
> >e.g
> >public class SoapSample
> >{
> >
> > public String[] print()
> > {
> > return "Hello World!";
> > }
> >}
> >
> >Its the abstraction level above that(may be the rpcrouter), which
> >gives this
> >piece of code the definition of SOAP RPC server.
> >
> >Now if you look at a SOAP Messagin server,
> >
> >e.g
> >
> >public class SoapMsgServer
> >{
> > public void purchaseOrder(Envelope inputEnv, SOAPContext
> >reqCtx,
> >SOAPContext resCtx)
> > {
> > try
> > {
> >
> > // dummy messaging server.
> >
> > resCtx.setRootPart("Hello from SOAP messaging server!",
> >"text/html");
> > }
> > catch(Exception ex)
> > {
> > ex.printStackTrace();
> > }
> >
> > }
> >}
> >
> >There is a tight coupling, between the server code and the SOAP
> >API's.
> >
> >I was wondering why has the Apache SOAP Message server designed
> >this way.
> >Why cant I return String or some datatype and the layer above
> >that(messagerouter ????) encapsulate the details of forming the
> >SOAPEnvelope
> >and return it back to the client ????
> >
> >Basically its the question of ownership.
> >
> >any takers.....
> >
> >reg
> >Nilesh
> >
> >
>
> _________________________________________________________
> Click below to visit monsterindia.com and review jobs in India or
> Abroad
> http://monsterindia.rediff.com/jobs
>

Reply via email to