thanx scott for the info -----Original Message----- From: Scott Nichol [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 24, 2002 6:58 PM To: [EMAIL PROTECTED] Subject: Re: Apache SOAP RPC vs SOAP Messaging
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 >
