You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@ws.apache.org by naveen <na...@amsoft.net> on 2001/12/17 09:46:52 UTC
Messaging vs RPC ???
hi
I am new to soap and i am really confused between the Messaging and RPC
approaches
I have been searching net but could find something useful.
Basically what i want to know is
1)what the factor or issue which should be kept in mind while deciding
between
Rpc/Messaging ?
2)what are the advantages of using messaging over RPC ?
3)More specifically ,In an service which takes a parameter and returns
a object which approach should be taken?
thanks
Naveen
Re: Messaging vs RPC ???
Posted by Chris Malley <cm...@pixelzoom.com>.
naveen wrote:
>
> hi
>
> I am new to soap and i am really confused between the Messaging and RPC
> approaches
> I have been searching net but could find something useful.
>
> Basically what i want to know is
>
>
> 1)what the factor or issue which should be kept in mind while deciding
> between
> Rpc/Messaging ?
>
> 2)what are the advantages of using messaging over RPC ?
>
> 3)More specifically ,In an service which takes a parameter and returns
> a object which approach should be taken?
>
> thanks
> Naveen
Sorry that I don't have time for a lengthy reply, but here are some
pointers.
First, this question has been addressed several times (recently even)
on this mailing list. So have a look at the mailing list archives.
The O'Reilly book "Java & XML, 2nd Edition" has two excellent chapters
on SOAP. Chapter 12 is on RPC-style, Chapter 13 is on message-style,
WSDL, and UDDI. This book was essential to my understanding of SOAP,
particularly RPC- versus messages-style issues, and I find that I refer
to it often for examples. The examples are online at www.oreilly.com.
To answer your last question... If the number & types of parameters to
your service are easy to represent as a function call, then use
RCP-style SOAP. (Think of RPC-style SOAP as a network function call.)
If you need to pass objects of types that are not
part of the xsi:types specification, then you'll need to serialize
them. If your objects are in JavaBeans format, you can use the Apache
SOAP BeanSerializer (example in above book). If your objects are not
in JavaBean format, you'll need to write your own serializer; see the
examples that come with Apache SOAP.
-Chris
Re: Messaging vs RPC ???
Posted by Chris Malley <cm...@pixelzoom.com>.
naveen wrote:
>
> hi
>
> I am new to soap and i am really confused between the Messaging and RPC
> approaches
> I have been searching net but could find something useful.
>
> Basically what i want to know is
>
>
> 1)what the factor or issue which should be kept in mind while deciding
> between
> Rpc/Messaging ?
>
> 2)what are the advantages of using messaging over RPC ?
>
> 3)More specifically ,In an service which takes a parameter and returns
> a object which approach should be taken?
>
> thanks
> Naveen
Sorry that I don't have time for a lengthy reply, but here are some
pointers.
First, this question has been addressed several times (recently even)
on this mailing list. So have a look at the mailing list archives.
The O'Reilly book "Java & XML, 2nd Edition" has two excellent chapters
on SOAP. Chapter 12 is on RPC-style, Chapter 13 is on message-style,
WSDL, and UDDI. This book was essential to my understanding of SOAP,
particularly RPC- versus messages-style issues, and I find that I refer
to it often for examples. The examples are online at www.oreilly.com.
To answer your last question... If the number & types of parameters to
your service are easy to represent as a function call, then use
RCP-style SOAP. (Think of RPC-style SOAP as a network function call.)
If you need to pass objects of types that are not
part of the xsi:types specification, then you'll need to serialize
them. If your objects are in JavaBeans format, you can use the Apache
SOAP BeanSerializer (example in above book). If your objects are not
in JavaBean format, you'll need to write your own serializer; see the
examples that come with Apache SOAP.
-Chris