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 stephen chan <st...@netnation.com> on 2002/08/03 01:13:59 UTC
May I ask a SOAP rpc vs. message question here?
New to the list.
May I ask a SOAP rpc vs. message question here?
It pertains to Java service to Perl client.
Thanks
Stephen
RE: problem with message service
Posted by stephen chan <st...@netnation.com>.
Sorry Folks. Should have read Apache-SOAP User's FAQ.
It was a XML classloading issue.
This is not the first time I had problems with Tomcat and XML libraries
:-[
Thanks.
Stephen
========================================================================
=========
-----Original Message-----
From: stephen chan [mailto:stephenc@netnation.com]
Sent: Tuesday, August 06, 2002 3:42 PM
To: soap-user@xml.apache.org
Subject: problem with message service
Hello:
I am working through the book examples in Java and SOAP from O'Reilly.
At the beginning of Chapter 8 there's a simple messaging example, I
deployed it like this:
- java org.apache.soap.server.ServiceManagerClient
http://localhost:8080/soap/servlet/rpcrouter deploy WeatherDiary.dd
I can see the above service deployed in SOAP admin. When I run the
corresponding client to talk to the server, I get this:
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Exception while handling service request:
WeatherDiary.recordTemperature(org.apache.soap.Envelope,org.apache.soap.
rpc.SOAPContext,org.apache.soap.rpc.SOAPContext) -- no signature
match</faultstring> <faultactor>/soap/servlet/messagerouter</faultactor>
<detail>
<stackTrace>java.lang.NoSuchMethodException:
WeatherDiary.recordTemperature(org.apache.soap.Envelope,org.apache.soap.
rpc.SOAPContext,org.apache.soap.rpc.SOAPContext) -- no signature match
at
org.apache.soap.util.MethodUtils.getEntryPoint(MethodUtils.java:194)
at
org.apache.soap.util.MethodUtils.getMethod(MethodUtils.java:548)
cut...
Why do I get a "NoSuchMethodException"? I think I have deployed the
service correctly. BTW, the same happened when I tried a messaging
example from another book. I don't have this problem with RPC SOAP
services.
-----------------------------------------------
WeatherDiary.dd
<isd:service
xmlns:isd="http://xml.apache.org/xml-soap/deployment"
id="urn:WeatherDiary" type="message">
<isd:provider
type="java"
scope="Application"
methods="recordTemperature">
<isd:java
class="WeatherDiary"
static="false"/>
</isd:provider>
<isd:faultListener>org.apache.soap.server.DOMFaultListener</isd:faultLis
tener>
<isd:mappings>
</isd:mappings>
</isd:service>
------------------------------------------------------------------------
---
WeatherDiary.java
import java.io.*;
import java.util.*;
import org.apache.soap.*;
import org.apache.soap.rpc.SOAPContext;
import javax.mail.MessagingException;
import org.w3c.dom.*;
public class WeatherDiary
{
Hashtable _diary = new Hashtable();
public void recordTemperature(Envelope env,
SOAPContext reqCtx,
SOAPContext resCtx)
throws Exception
{
Vector v = env.getBody().getBodyEntries();
int cnt = v.size();
String zipcode = null;
String temperature = null;
for (int i = 0; i < cnt; i++)
{
Element e = (Element)v.elementAt(i);
String name = e.getTagName();
if(name.equals("zipcode"))
{
zipcode = e.getFirstChild().getNodeValue();
}
else if(name.equals("temperature"))
{
temperature = e.getFirstChild().getNodeValue();
}
}
if (zipcode == null || temperature == null)
throw new IllegalArgumentException("ZIPCODE and/or
TEMPERATURE Not Specified");
_diary.put(zipcode, temperature);
resCtx.setRootPart("OK", "text/xml");
}
}
------------------------------------------------------------------------
----
WeatherClient.java
import java.io.*;
import java.net.*;
import javax.xml.parsers.*;
import org.w3c.dom.*;
import org.xml.sax.*;
import org.apache.soap.*;
import org.apache.soap.messaging.*;
import org.apache.soap.transport.*;
import org.apache.soap.util.xml.*;
public class WeatherClient {
public static void main (String[] args) throws Exception {
DocumentBuilder xdb = XMLParserUtils.getXMLDocBuilder();
Document doc = xdb.newDocument();
Element elem =
doc.createElementNS(Constants.NS_URI_SOAP_ENV,
"SOAP-ENV:Envelope");
doc.appendChild(elem);
Element sub =
doc.createElementNS(Constants.NS_URI_SOAP_ENV,
"SOAP-ENV:Body");
elem.appendChild(sub);
elem = sub;
sub = doc.createElement("recordTemperature");
sub.setAttribute("xmlns", "urn:WeatherDiary");
elem.appendChild(sub);
sub = doc.createElement("zipcode");
Text txt = doc.createTextNode("");
txt.setData("12345");
sub.appendChild(txt);
elem.appendChild(sub);
sub = doc.createElement("temperature");
txt = doc.createTextNode("");
txt.setData("52.3");
sub.appendChild(txt);
elem.appendChild(sub);
Envelope msgEnv = Envelope.unmarshall(
doc.getDocumentElement());
URL url = new URL(
"http://localhost:8080/soap/servlet/messagerouter");
Message msg = new Message();
msg.send(url, "", msgEnv);
SOAPTransport st = msg.getSOAPTransport();
BufferedReader br = st.receive();
String line;
while ((line = br.readLine()) != null) {
System.out.println(line);
}
}
}
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
RE: problem with message service
Posted by stephen chan <st...@netnation.com>.
Sorry Folks. Should have read Apache-SOAP User's FAQ.
It was a XML classloading issue.
This is not the first time I had problems with Tomcat and XML libraries
:-[
Thanks.
Stephen
========================================================================
=========
-----Original Message-----
From: stephen chan [mailto:stephenc@netnation.com]
Sent: Tuesday, August 06, 2002 3:42 PM
To: soap-user@xml.apache.org
Subject: problem with message service
Hello:
I am working through the book examples in Java and SOAP from O'Reilly.
At the beginning of Chapter 8 there's a simple messaging example, I
deployed it like this:
- java org.apache.soap.server.ServiceManagerClient
http://localhost:8080/soap/servlet/rpcrouter deploy WeatherDiary.dd
I can see the above service deployed in SOAP admin. When I run the
corresponding client to talk to the server, I get this:
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Exception while handling service request:
WeatherDiary.recordTemperature(org.apache.soap.Envelope,org.apache.soap.
rpc.SOAPContext,org.apache.soap.rpc.SOAPContext) -- no signature
match</faultstring> <faultactor>/soap/servlet/messagerouter</faultactor>
<detail>
<stackTrace>java.lang.NoSuchMethodException:
WeatherDiary.recordTemperature(org.apache.soap.Envelope,org.apache.soap.
rpc.SOAPContext,org.apache.soap.rpc.SOAPContext) -- no signature match
at
org.apache.soap.util.MethodUtils.getEntryPoint(MethodUtils.java:194)
at
org.apache.soap.util.MethodUtils.getMethod(MethodUtils.java:548)
cut...
Why do I get a "NoSuchMethodException"? I think I have deployed the
service correctly. BTW, the same happened when I tried a messaging
example from another book. I don't have this problem with RPC SOAP
services.
-----------------------------------------------
WeatherDiary.dd
<isd:service
xmlns:isd="http://xml.apache.org/xml-soap/deployment"
id="urn:WeatherDiary" type="message">
<isd:provider
type="java"
scope="Application"
methods="recordTemperature">
<isd:java
class="WeatherDiary"
static="false"/>
</isd:provider>
<isd:faultListener>org.apache.soap.server.DOMFaultListener</isd:faultLis
tener>
<isd:mappings>
</isd:mappings>
</isd:service>
------------------------------------------------------------------------
---
WeatherDiary.java
import java.io.*;
import java.util.*;
import org.apache.soap.*;
import org.apache.soap.rpc.SOAPContext;
import javax.mail.MessagingException;
import org.w3c.dom.*;
public class WeatherDiary
{
Hashtable _diary = new Hashtable();
public void recordTemperature(Envelope env,
SOAPContext reqCtx,
SOAPContext resCtx)
throws Exception
{
Vector v = env.getBody().getBodyEntries();
int cnt = v.size();
String zipcode = null;
String temperature = null;
for (int i = 0; i < cnt; i++)
{
Element e = (Element)v.elementAt(i);
String name = e.getTagName();
if(name.equals("zipcode"))
{
zipcode = e.getFirstChild().getNodeValue();
}
else if(name.equals("temperature"))
{
temperature = e.getFirstChild().getNodeValue();
}
}
if (zipcode == null || temperature == null)
throw new IllegalArgumentException("ZIPCODE and/or
TEMPERATURE Not Specified");
_diary.put(zipcode, temperature);
resCtx.setRootPart("OK", "text/xml");
}
}
------------------------------------------------------------------------
----
WeatherClient.java
import java.io.*;
import java.net.*;
import javax.xml.parsers.*;
import org.w3c.dom.*;
import org.xml.sax.*;
import org.apache.soap.*;
import org.apache.soap.messaging.*;
import org.apache.soap.transport.*;
import org.apache.soap.util.xml.*;
public class WeatherClient {
public static void main (String[] args) throws Exception {
DocumentBuilder xdb = XMLParserUtils.getXMLDocBuilder();
Document doc = xdb.newDocument();
Element elem =
doc.createElementNS(Constants.NS_URI_SOAP_ENV,
"SOAP-ENV:Envelope");
doc.appendChild(elem);
Element sub =
doc.createElementNS(Constants.NS_URI_SOAP_ENV,
"SOAP-ENV:Body");
elem.appendChild(sub);
elem = sub;
sub = doc.createElement("recordTemperature");
sub.setAttribute("xmlns", "urn:WeatherDiary");
elem.appendChild(sub);
sub = doc.createElement("zipcode");
Text txt = doc.createTextNode("");
txt.setData("12345");
sub.appendChild(txt);
elem.appendChild(sub);
sub = doc.createElement("temperature");
txt = doc.createTextNode("");
txt.setData("52.3");
sub.appendChild(txt);
elem.appendChild(sub);
Envelope msgEnv = Envelope.unmarshall(
doc.getDocumentElement());
URL url = new URL(
"http://localhost:8080/soap/servlet/messagerouter");
Message msg = new Message();
msg.send(url, "", msgEnv);
SOAPTransport st = msg.getSOAPTransport();
BufferedReader br = st.receive();
String line;
while ((line = br.readLine()) != null) {
System.out.println(line);
}
}
}
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
problem with message service
Posted by stephen chan <st...@netnation.com>.
Hello:
I am working through the book examples in Java and SOAP from O'Reilly.
At the beginning of Chapter 8 there's a simple messaging example, I
deployed it like this:
- java org.apache.soap.server.ServiceManagerClient
http://localhost:8080/soap/servlet/rpcrouter deploy WeatherDiary.dd
I can see the above service deployed in SOAP admin. When I run the
corresponding client to talk to the server, I get this:
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Exception while handling service request:
WeatherDiary.recordTemperature(org.apache.soap.Envelope,org.apache.soap.
rpc.SOAPContext,org.apache.soap.rpc.SOAPContext) -- no signature
match</faultstring>
<faultactor>/soap/servlet/messagerouter</faultactor>
<detail>
<stackTrace>java.lang.NoSuchMethodException:
WeatherDiary.recordTemperature(org.apache.soap.Envelope,org.apache.soap.
rpc.SOAPContext,org.apache.soap.rpc.SOAPContext) -- no signature match
at
org.apache.soap.util.MethodUtils.getEntryPoint(MethodUtils.java:194)
at
org.apache.soap.util.MethodUtils.getMethod(MethodUtils.java:548)
cut...
Why do I get a "NoSuchMethodException"? I think I have deployed the
service correctly. BTW, the same happened when I tried a messaging
example from another book. I don't have this problem with RPC SOAP
services.
-----------------------------------------------
WeatherDiary.dd
<isd:service
xmlns:isd="http://xml.apache.org/xml-soap/deployment"
id="urn:WeatherDiary" type="message">
<isd:provider
type="java"
scope="Application"
methods="recordTemperature">
<isd:java
class="WeatherDiary"
static="false"/>
</isd:provider>
<isd:faultListener>org.apache.soap.server.DOMFaultListener</isd:faultLis
tener>
<isd:mappings>
</isd:mappings>
</isd:service>
------------------------------------------------------------------------
---
WeatherDiary.java
import java.io.*;
import java.util.*;
import org.apache.soap.*;
import org.apache.soap.rpc.SOAPContext;
import javax.mail.MessagingException;
import org.w3c.dom.*;
public class WeatherDiary
{
Hashtable _diary = new Hashtable();
public void recordTemperature(Envelope env,
SOAPContext reqCtx,
SOAPContext resCtx)
throws Exception
{
Vector v = env.getBody().getBodyEntries();
int cnt = v.size();
String zipcode = null;
String temperature = null;
for (int i = 0; i < cnt; i++)
{
Element e = (Element)v.elementAt(i);
String name = e.getTagName();
if(name.equals("zipcode"))
{
zipcode = e.getFirstChild().getNodeValue();
}
else if(name.equals("temperature"))
{
temperature = e.getFirstChild().getNodeValue();
}
}
if (zipcode == null || temperature == null)
throw new IllegalArgumentException("ZIPCODE and/or
TEMPERATURE Not Specified");
_diary.put(zipcode, temperature);
resCtx.setRootPart("OK", "text/xml");
}
}
------------------------------------------------------------------------
----
WeatherClient.java
import java.io.*;
import java.net.*;
import javax.xml.parsers.*;
import org.w3c.dom.*;
import org.xml.sax.*;
import org.apache.soap.*;
import org.apache.soap.messaging.*;
import org.apache.soap.transport.*;
import org.apache.soap.util.xml.*;
public class WeatherClient {
public static void main (String[] args) throws Exception {
DocumentBuilder xdb = XMLParserUtils.getXMLDocBuilder();
Document doc = xdb.newDocument();
Element elem =
doc.createElementNS(Constants.NS_URI_SOAP_ENV,
"SOAP-ENV:Envelope");
doc.appendChild(elem);
Element sub =
doc.createElementNS(Constants.NS_URI_SOAP_ENV,
"SOAP-ENV:Body");
elem.appendChild(sub);
elem = sub;
sub = doc.createElement("recordTemperature");
sub.setAttribute("xmlns", "urn:WeatherDiary");
elem.appendChild(sub);
sub = doc.createElement("zipcode");
Text txt = doc.createTextNode("");
txt.setData("12345");
sub.appendChild(txt);
elem.appendChild(sub);
sub = doc.createElement("temperature");
txt = doc.createTextNode("");
txt.setData("52.3");
sub.appendChild(txt);
elem.appendChild(sub);
Envelope msgEnv = Envelope.unmarshall(
doc.getDocumentElement());
URL url = new URL(
"http://localhost:8080/soap/servlet/messagerouter");
Message msg = new Message();
msg.send(url, "", msgEnv);
SOAPTransport st = msg.getSOAPTransport();
BufferedReader br = st.receive();
String line;
while ((line = br.readLine()) != null) {
System.out.println(line);
}
}
}
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
RE: May I ask a SOAP rpc vs. message question here?
Posted by Dan Allen <da...@nist.gov>.
>
> Dan,
>
> Re:
> > Where is this specified in the SOAP specification?
>
> See http://www.w3.org/TR/SOAP/#_Toc478383533 (from the SOAP 1.1 spec)
>
> To quote:
> - The method invocation is viewed as a single struct containing an accessor
> for each [in] or [in/out] parameter. The struct is both named and typed
> identically to the method name.
Thanks for the reference - I must say I've read this and was totally
clueless as to to what it was trying to say. I'm a simple WV boy
who likes simple words for simple ideas ;-)
>
> Also see http://www.w3.org/TR/soap12-part2/#rpcinvocation (from the SOAP 1.2
> spec)
>
> To quote:
> - The invocation is represented by a single struct or array containing an
> outbound edge for each [in] or [in/out] parameter. The struct or array is
> named identically to the procedure or method name.
>
See above for simple word philosophy.
> Re:
> > the truly big loss of encoding is the validation issue.
>
> I agree! You also lose the ability to transform the messages.
>
> Re:
> > I'd suggest that the proper place for this [method] information is
> > in the SOAP Header ala the ebXML Message Specification
>
> The RPC convention dates back to the origins of SOAP -- the first
> incantation was used strictly for RPC functionality, and there weren't
> headers at that point. Old habits are hard to break. With current SOAP, you
> can certainly place the method name information in the SOAP Header, but
> that's not where most SOAP servers look for it. They first look in the
> SOAPAction header, then they look at the SOAP body (the name of the input
> message, whether you're using RPC or Document style, should provide some
> indication of what method is being invoked). If you want to specify the
> method name in the SOAP Header, you'd need to implement a SOAP header
> processor to process it. (More work for the developer!)
>
Not really - as you have mentioned the SOAPAction HTTP header already exists
and is used by some servers. I believe the SOAP spec tippy-toes around
how and when it should be used. All that's needed is a concrete statement
of form and use and you have a concrete specification that can be implemented
in ALL conforming SOAP servers. One of our big areas of emphasis here
at NIST is interoperability and I think it's pretty clear that some aspects
of the current SOAP spec are a little ambiquous/sparse and need clarification
to facilitate this goal. Identifying the target service in a uniform fashion
is one such area in my opinion. I don't really care what the mechanism is as
long as it's well defined.
> Re:
> > RPC style encoding puts the onus back on the application programmer.
>
> It depends on your point of view. If you view SOAP simply as the latest
> incarnation of an RPC middleware technology, then the application developer
> is basically unaware of the fact that SOAP uses XML. XML is treated simply
> as the wire data format (the equivalent to XDR, NDR, or CDR when used with
> Sun ONC, MS and DCE RPC, or CORBA, respectively). And from this perspective,
> XML adds a definite advantage in that it's completely language and platform
> independent -- something the none of these earlier RPC mechanisms could
> claim. (although you're obviously not taking full advantage of the power
> that XML offers -- like being able to validate or transform the messages).
> When you're using RPC/encoded, you're using a powerful, extensible,
> loosely-coupled messaging framework in a remarkably brittle, non-extensible,
> tightly-coupled sort of way. Hence my recommendation to use doc/literal
> unless your data model is very object-oriented in nature.
>
> If you view SOAP as a powerful, extensible, loosely coupled messaging
> framework (doesn't everyone), you probably want to avoid using rpc/encoded.
>
I think we are in total agreement with regard to all of the above,
and most specifically with regard to your recommendation of form.
Nice chatting with you.
Dan
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
RE: May I ask a SOAP rpc vs. message question here?
Posted by Dan Allen <da...@nist.gov>.
>
> Dan,
>
> Re:
> > Where is this specified in the SOAP specification?
>
> See http://www.w3.org/TR/SOAP/#_Toc478383533 (from the SOAP 1.1 spec)
>
> To quote:
> - The method invocation is viewed as a single struct containing an accessor
> for each [in] or [in/out] parameter. The struct is both named and typed
> identically to the method name.
Thanks for the reference - I must say I've read this and was totally
clueless as to to what it was trying to say. I'm a simple WV boy
who likes simple words for simple ideas ;-)
>
> Also see http://www.w3.org/TR/soap12-part2/#rpcinvocation (from the SOAP 1.2
> spec)
>
> To quote:
> - The invocation is represented by a single struct or array containing an
> outbound edge for each [in] or [in/out] parameter. The struct or array is
> named identically to the procedure or method name.
>
See above for simple word philosophy.
> Re:
> > the truly big loss of encoding is the validation issue.
>
> I agree! You also lose the ability to transform the messages.
>
> Re:
> > I'd suggest that the proper place for this [method] information is
> > in the SOAP Header ala the ebXML Message Specification
>
> The RPC convention dates back to the origins of SOAP -- the first
> incantation was used strictly for RPC functionality, and there weren't
> headers at that point. Old habits are hard to break. With current SOAP, you
> can certainly place the method name information in the SOAP Header, but
> that's not where most SOAP servers look for it. They first look in the
> SOAPAction header, then they look at the SOAP body (the name of the input
> message, whether you're using RPC or Document style, should provide some
> indication of what method is being invoked). If you want to specify the
> method name in the SOAP Header, you'd need to implement a SOAP header
> processor to process it. (More work for the developer!)
>
Not really - as you have mentioned the SOAPAction HTTP header already exists
and is used by some servers. I believe the SOAP spec tippy-toes around
how and when it should be used. All that's needed is a concrete statement
of form and use and you have a concrete specification that can be implemented
in ALL conforming SOAP servers. One of our big areas of emphasis here
at NIST is interoperability and I think it's pretty clear that some aspects
of the current SOAP spec are a little ambiquous/sparse and need clarification
to facilitate this goal. Identifying the target service in a uniform fashion
is one such area in my opinion. I don't really care what the mechanism is as
long as it's well defined.
> Re:
> > RPC style encoding puts the onus back on the application programmer.
>
> It depends on your point of view. If you view SOAP simply as the latest
> incarnation of an RPC middleware technology, then the application developer
> is basically unaware of the fact that SOAP uses XML. XML is treated simply
> as the wire data format (the equivalent to XDR, NDR, or CDR when used with
> Sun ONC, MS and DCE RPC, or CORBA, respectively). And from this perspective,
> XML adds a definite advantage in that it's completely language and platform
> independent -- something the none of these earlier RPC mechanisms could
> claim. (although you're obviously not taking full advantage of the power
> that XML offers -- like being able to validate or transform the messages).
> When you're using RPC/encoded, you're using a powerful, extensible,
> loosely-coupled messaging framework in a remarkably brittle, non-extensible,
> tightly-coupled sort of way. Hence my recommendation to use doc/literal
> unless your data model is very object-oriented in nature.
>
> If you view SOAP as a powerful, extensible, loosely coupled messaging
> framework (doesn't everyone), you probably want to avoid using rpc/encoded.
>
I think we are in total agreement with regard to all of the above,
and most specifically with regard to your recommendation of form.
Nice chatting with you.
Dan
RE: May I ask a SOAP rpc vs. message question here?
Posted by Anne Thomas Manes <an...@manes.net>.
Dan,
Re:
> Where is this specified in the SOAP specification?
See http://www.w3.org/TR/SOAP/#_Toc478383533 (from the SOAP 1.1 spec)
To quote:
- The method invocation is viewed as a single struct containing an accessor
for each [in] or [in/out] parameter. The struct is both named and typed
identically to the method name.
Also see http://www.w3.org/TR/soap12-part2/#rpcinvocation (from the SOAP 1.2
spec)
To quote:
- The invocation is represented by a single struct or array containing an
outbound edge for each [in] or [in/out] parameter. The struct or array is
named identically to the procedure or method name.
Re:
> the truly big loss of encoding is the validation issue.
I agree! You also lose the ability to transform the messages.
Re:
> I'd suggest that the proper place for this [method] information is
> in the SOAP Header ala the ebXML Message Specification
The RPC convention dates back to the origins of SOAP -- the first
incantation was used strictly for RPC functionality, and there weren't
headers at that point. Old habits are hard to break. With current SOAP, you
can certainly place the method name information in the SOAP Header, but
that's not where most SOAP servers look for it. They first look in the
SOAPAction header, then they look at the SOAP body (the name of the input
message, whether you're using RPC or Document style, should provide some
indication of what method is being invoked). If you want to specify the
method name in the SOAP Header, you'd need to implement a SOAP header
processor to process it. (More work for the developer!)
Re:
> RPC style encoding puts the onus back on the application programmer.
It depends on your point of view. If you view SOAP simply as the latest
incarnation of an RPC middleware technology, then the application developer
is basically unaware of the fact that SOAP uses XML. XML is treated simply
as the wire data format (the equivalent to XDR, NDR, or CDR when used with
Sun ONC, MS and DCE RPC, or CORBA, respectively). And from this perspective,
XML adds a definite advantage in that it's completely language and platform
independent -- something the none of these earlier RPC mechanisms could
claim. (although you're obviously not taking full advantage of the power
that XML offers -- like being able to validate or transform the messages).
When you're using RPC/encoded, you're using a powerful, extensible,
loosely-coupled messaging framework in a remarkably brittle, non-extensible,
tightly-coupled sort of way. Hence my recommendation to use doc/literal
unless your data model is very object-oriented in nature.
If you view SOAP as a powerful, extensible, loosely coupled messaging
framework (doesn't everyone), you probably want to avoid using rpc/encoded.
Best regards,
Anne
> -----Original Message-----
> From: Dan Allen [mailto:dallen@nist.gov]
> Sent: Thursday, August 08, 2002 1:14 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
>
>
>
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Thursday, August 08, 2002 12:35 PM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
>
> > First let me explain the major differences between the RPC and Document
> > message styles (note that both of these styles are "messages"). The RPC
> > convention formats the input and output messages as XML
> structures. For the
> > input message, the name of the structure (the top level element in the
> > message) is equivalent to the method name. The contents of the
> structure are
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Where is this specified in the SOAP specification? I know it is common
> usage but I haven't seen any explicit statement of this in the spec. I'd
> also suggest that the proper place for this information is in the SOAP
> Header ala the ebXML Message Specification (not that I'm wildly
> in love with
> that monster either!).
>
>
> > I'd say that the more important decision that you need to make
> is not RPC vs
> > Document, but Encoded vs Literal.
> >
> I'd wholeheartedly agree with this statement.
>
> > SOAP encoding provides a much more convenient mechanism to
> encode complex
> > objects -- including cyclic object graphs. BUT: you can't validate an
> > RPC/encoded message. If you intend to pass cyclic object graphs,
> > multidimensional arrays, sparse arrays, etc., you probably want to use
> > RPC/encoded. If you're passing simple objects, then I'd recommend using
> > doc/literal.
>
> Convenience is often in the eyes of the beholder. For
> example, "encoding"
> strings is, in my opinion, massively inconvenient. The
> same goes for
> most if not all of the standard XML data types. But, again
> in my opinion,
> the truly big loss of encoding is the validation issue.
> This is a major
> loss of XML functionality! The power to define a document
> structure using
> a schema and have the XML parser do the egregious work of
> content validation
> is a central design goal of XML schema. RPC style encoding
> puts the onus
> back on the application programmer.
>
> >
> > Best regards,
> > Anne
>
> Just my $.02.
>
> Dan
> >
> >
> >
> > > -----Original Message-----
> > > From: stephen chan [mailto:stephenc@netnation.com]
> > > Sent: Tuesday, August 06, 2002 6:03 PM
> > > To: soap-user@xml.apache.org
> > > Subject: RE: May I ask a SOAP rpc vs. message question here?
> > >
> > >
> > > Anne:
> > >
> > > Thank you for your reply.
> > > I am beginning to understand how SOAP works.
> > > Whether server or client, SOAP transforms the underlying data
> structures
> > > into XML for transport, then each side is responsible for
> de-serializing
> > > the XML back into it's native data format?
> > >
> > > I have a second question. How should one choose when to use RPC vs.
> > > Messaging?
> > >
> > > Thanks
> > > Stephen
> > >
> > >
> =======================================================================
> > >
> > > -----Original Message-----
> > > From: Anne Thomas Manes [mailto:anne@manes.net]
> > > Sent: Tuesday, August 06, 2002 2:26 PM
> > > To: soap-user@xml.apache.org
> > > Subject: RE: May I ask a SOAP rpc vs. message question here?
> > >
> > > Stephen,
> > >
> > > Your Java SOAP server may view the person object as a Java class, but
> > > from a
> > > SOAP perspective, the person object is an XML structure. The
> > > service-side
> > > SOAP runtime engine should perform the transformation between the XML
> > > structure and the Java class for you. Any language SOAP
> client should be
> > > able to talk to your SOAP service. It shouldn't make a difference
> > > whether
> > > your use RPC or document style. You just need to tell the
> client how to
> > > translate the person XML structure into the appropriate language
> > > structure
> > > (in this case, perl). In otehr words, you'll need to write a perl
> > > deserializer for your client. (The same would be true whether you're
> > > using
> > > RPC or document.)
> > >
> > > Best regards,
> > > Anne
> > >
> > > > -----Original Message-----
> > > > From: stephen chan [mailto:stephenc@netnation.com]
> > > > Sent: Tuesday, August 06, 2002 4:50 PM
> > > > To: soap-user@xml.apache.org
> > > > Subject: RE: May I ask a SOAP rpc vs. message question here?
> > > >
> > > >
> > > > Hello:
> > > >
> > > > I have a question to ask regarding java soap server to perl soap
> > > client.
> > > >
> > > > I have a java soap server with one service.
> > > > It is a rpc oriented service.
> > > > It has 2 methods - list, add.
> > > >
> > > > List will return a list of person objects.
> > > > Add will require a person object as a parameter
> > > > person object is a java class with first_name, last_name
> and email.
> > > >
> > > > I can do java soap client to java soap rpc server passing serialized
> > > > person object
> > > >
> > > > Is this possible with let's say perl soap client to java
> soap server?
> > > >
> > > > How do non-java clients de-serialize the person object or create a
> > > > serialized person object to communicate with the java based rpc web
> > > > service?
> > > >
> > > > Maybe this isn't the way to do it. Maybe for cross-language soap
> > > > client/server I should be using message-based soap?
> > > >
> > > > Thanks in advance
> > > >
> > > > Stephen
> > > >
> > > >
> > > > ================================================================
> > > >
> > > > -----Original Message-----
> > > > From: Anne Thomas Manes [mailto:anne@manes.net]
> > > > Sent: Monday, August 05, 2002 9:36 AM
> > > > To: soap-user@xml.apache.org
> > > > Subject: RE: May I ask a SOAP rpc vs. message question here?
> > > >
> > > > Sure thing. Ask away.
> > > >
> > > > > -----Original Message-----
> > > > > From: stephen chan [mailto:stephenc@netnation.com]
> > > > > Sent: Friday, August 02, 2002 7:14 PM
> > > > > To: soap-user@xml.apache.org
> > > > > Subject: May I ask a SOAP rpc vs. message question here?
> > > > >
> > > > >
> > > > > New to the list.
> > > > > May I ask a SOAP rpc vs. message question here?
> > > > > It pertains to Java service to Perl client.
> > > > >
> > > > > Thanks
> > > > > Stephen
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@xml.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@xml.apache.org>
> > > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@xml.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@xml.apache.org>
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@xml.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@xml.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > > For additional commands, e-mail:
> <ma...@xml.apache.org>
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > > For additional commands, e-mail:
> <ma...@xml.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
RE: May I ask a SOAP rpc vs. message question here?
Posted by Anne Thomas Manes <an...@manes.net>.
Dan,
Re:
> Where is this specified in the SOAP specification?
See http://www.w3.org/TR/SOAP/#_Toc478383533 (from the SOAP 1.1 spec)
To quote:
- The method invocation is viewed as a single struct containing an accessor
for each [in] or [in/out] parameter. The struct is both named and typed
identically to the method name.
Also see http://www.w3.org/TR/soap12-part2/#rpcinvocation (from the SOAP 1.2
spec)
To quote:
- The invocation is represented by a single struct or array containing an
outbound edge for each [in] or [in/out] parameter. The struct or array is
named identically to the procedure or method name.
Re:
> the truly big loss of encoding is the validation issue.
I agree! You also lose the ability to transform the messages.
Re:
> I'd suggest that the proper place for this [method] information is
> in the SOAP Header ala the ebXML Message Specification
The RPC convention dates back to the origins of SOAP -- the first
incantation was used strictly for RPC functionality, and there weren't
headers at that point. Old habits are hard to break. With current SOAP, you
can certainly place the method name information in the SOAP Header, but
that's not where most SOAP servers look for it. They first look in the
SOAPAction header, then they look at the SOAP body (the name of the input
message, whether you're using RPC or Document style, should provide some
indication of what method is being invoked). If you want to specify the
method name in the SOAP Header, you'd need to implement a SOAP header
processor to process it. (More work for the developer!)
Re:
> RPC style encoding puts the onus back on the application programmer.
It depends on your point of view. If you view SOAP simply as the latest
incarnation of an RPC middleware technology, then the application developer
is basically unaware of the fact that SOAP uses XML. XML is treated simply
as the wire data format (the equivalent to XDR, NDR, or CDR when used with
Sun ONC, MS and DCE RPC, or CORBA, respectively). And from this perspective,
XML adds a definite advantage in that it's completely language and platform
independent -- something the none of these earlier RPC mechanisms could
claim. (although you're obviously not taking full advantage of the power
that XML offers -- like being able to validate or transform the messages).
When you're using RPC/encoded, you're using a powerful, extensible,
loosely-coupled messaging framework in a remarkably brittle, non-extensible,
tightly-coupled sort of way. Hence my recommendation to use doc/literal
unless your data model is very object-oriented in nature.
If you view SOAP as a powerful, extensible, loosely coupled messaging
framework (doesn't everyone), you probably want to avoid using rpc/encoded.
Best regards,
Anne
> -----Original Message-----
> From: Dan Allen [mailto:dallen@nist.gov]
> Sent: Thursday, August 08, 2002 1:14 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
>
>
>
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Thursday, August 08, 2002 12:35 PM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
>
> > First let me explain the major differences between the RPC and Document
> > message styles (note that both of these styles are "messages"). The RPC
> > convention formats the input and output messages as XML
> structures. For the
> > input message, the name of the structure (the top level element in the
> > message) is equivalent to the method name. The contents of the
> structure are
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Where is this specified in the SOAP specification? I know it is common
> usage but I haven't seen any explicit statement of this in the spec. I'd
> also suggest that the proper place for this information is in the SOAP
> Header ala the ebXML Message Specification (not that I'm wildly
> in love with
> that monster either!).
>
>
> > I'd say that the more important decision that you need to make
> is not RPC vs
> > Document, but Encoded vs Literal.
> >
> I'd wholeheartedly agree with this statement.
>
> > SOAP encoding provides a much more convenient mechanism to
> encode complex
> > objects -- including cyclic object graphs. BUT: you can't validate an
> > RPC/encoded message. If you intend to pass cyclic object graphs,
> > multidimensional arrays, sparse arrays, etc., you probably want to use
> > RPC/encoded. If you're passing simple objects, then I'd recommend using
> > doc/literal.
>
> Convenience is often in the eyes of the beholder. For
> example, "encoding"
> strings is, in my opinion, massively inconvenient. The
> same goes for
> most if not all of the standard XML data types. But, again
> in my opinion,
> the truly big loss of encoding is the validation issue.
> This is a major
> loss of XML functionality! The power to define a document
> structure using
> a schema and have the XML parser do the egregious work of
> content validation
> is a central design goal of XML schema. RPC style encoding
> puts the onus
> back on the application programmer.
>
> >
> > Best regards,
> > Anne
>
> Just my $.02.
>
> Dan
> >
> >
> >
> > > -----Original Message-----
> > > From: stephen chan [mailto:stephenc@netnation.com]
> > > Sent: Tuesday, August 06, 2002 6:03 PM
> > > To: soap-user@xml.apache.org
> > > Subject: RE: May I ask a SOAP rpc vs. message question here?
> > >
> > >
> > > Anne:
> > >
> > > Thank you for your reply.
> > > I am beginning to understand how SOAP works.
> > > Whether server or client, SOAP transforms the underlying data
> structures
> > > into XML for transport, then each side is responsible for
> de-serializing
> > > the XML back into it's native data format?
> > >
> > > I have a second question. How should one choose when to use RPC vs.
> > > Messaging?
> > >
> > > Thanks
> > > Stephen
> > >
> > >
> =======================================================================
> > >
> > > -----Original Message-----
> > > From: Anne Thomas Manes [mailto:anne@manes.net]
> > > Sent: Tuesday, August 06, 2002 2:26 PM
> > > To: soap-user@xml.apache.org
> > > Subject: RE: May I ask a SOAP rpc vs. message question here?
> > >
> > > Stephen,
> > >
> > > Your Java SOAP server may view the person object as a Java class, but
> > > from a
> > > SOAP perspective, the person object is an XML structure. The
> > > service-side
> > > SOAP runtime engine should perform the transformation between the XML
> > > structure and the Java class for you. Any language SOAP
> client should be
> > > able to talk to your SOAP service. It shouldn't make a difference
> > > whether
> > > your use RPC or document style. You just need to tell the
> client how to
> > > translate the person XML structure into the appropriate language
> > > structure
> > > (in this case, perl). In otehr words, you'll need to write a perl
> > > deserializer for your client. (The same would be true whether you're
> > > using
> > > RPC or document.)
> > >
> > > Best regards,
> > > Anne
> > >
> > > > -----Original Message-----
> > > > From: stephen chan [mailto:stephenc@netnation.com]
> > > > Sent: Tuesday, August 06, 2002 4:50 PM
> > > > To: soap-user@xml.apache.org
> > > > Subject: RE: May I ask a SOAP rpc vs. message question here?
> > > >
> > > >
> > > > Hello:
> > > >
> > > > I have a question to ask regarding java soap server to perl soap
> > > client.
> > > >
> > > > I have a java soap server with one service.
> > > > It is a rpc oriented service.
> > > > It has 2 methods - list, add.
> > > >
> > > > List will return a list of person objects.
> > > > Add will require a person object as a parameter
> > > > person object is a java class with first_name, last_name
> and email.
> > > >
> > > > I can do java soap client to java soap rpc server passing serialized
> > > > person object
> > > >
> > > > Is this possible with let's say perl soap client to java
> soap server?
> > > >
> > > > How do non-java clients de-serialize the person object or create a
> > > > serialized person object to communicate with the java based rpc web
> > > > service?
> > > >
> > > > Maybe this isn't the way to do it. Maybe for cross-language soap
> > > > client/server I should be using message-based soap?
> > > >
> > > > Thanks in advance
> > > >
> > > > Stephen
> > > >
> > > >
> > > > ================================================================
> > > >
> > > > -----Original Message-----
> > > > From: Anne Thomas Manes [mailto:anne@manes.net]
> > > > Sent: Monday, August 05, 2002 9:36 AM
> > > > To: soap-user@xml.apache.org
> > > > Subject: RE: May I ask a SOAP rpc vs. message question here?
> > > >
> > > > Sure thing. Ask away.
> > > >
> > > > > -----Original Message-----
> > > > > From: stephen chan [mailto:stephenc@netnation.com]
> > > > > Sent: Friday, August 02, 2002 7:14 PM
> > > > > To: soap-user@xml.apache.org
> > > > > Subject: May I ask a SOAP rpc vs. message question here?
> > > > >
> > > > >
> > > > > New to the list.
> > > > > May I ask a SOAP rpc vs. message question here?
> > > > > It pertains to Java service to Perl client.
> > > > >
> > > > > Thanks
> > > > > Stephen
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@xml.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@xml.apache.org>
> > > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@xml.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@xml.apache.org>
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@xml.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@xml.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > > For additional commands, e-mail:
> <ma...@xml.apache.org>
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > > For additional commands, e-mail:
> <ma...@xml.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
RE: May I ask a SOAP rpc vs. message question here?
Posted by Dan Allen <da...@nist.gov>.
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Thursday, August 08, 2002 12:35 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
> First let me explain the major differences between the RPC and Document
> message styles (note that both of these styles are "messages"). The RPC
> convention formats the input and output messages as XML structures. For the
> input message, the name of the structure (the top level element in the
> message) is equivalent to the method name. The contents of the structure are
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Where is this specified in the SOAP specification? I know it is common
usage but I haven't seen any explicit statement of this in the spec. I'd
also suggest that the proper place for this information is in the SOAP
Header ala the ebXML Message Specification (not that I'm wildly in love with
that monster either!).
> I'd say that the more important decision that you need to make is not RPC vs
> Document, but Encoded vs Literal.
>
I'd wholeheartedly agree with this statement.
> SOAP encoding provides a much more convenient mechanism to encode complex
> objects -- including cyclic object graphs. BUT: you can't validate an
> RPC/encoded message. If you intend to pass cyclic object graphs,
> multidimensional arrays, sparse arrays, etc., you probably want to use
> RPC/encoded. If you're passing simple objects, then I'd recommend using
> doc/literal.
Convenience is often in the eyes of the beholder. For example, "encoding"
strings is, in my opinion, massively inconvenient. The same goes for
most if not all of the standard XML data types. But, again in my opinion,
the truly big loss of encoding is the validation issue. This is a major
loss of XML functionality! The power to define a document structure using
a schema and have the XML parser do the egregious work of content validation
is a central design goal of XML schema. RPC style encoding puts the onus
back on the application programmer.
>
> Best regards,
> Anne
Just my $.02.
Dan
>
>
>
> > -----Original Message-----
> > From: stephen chan [mailto:stephenc@netnation.com]
> > Sent: Tuesday, August 06, 2002 6:03 PM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
> >
> >
> > Anne:
> >
> > Thank you for your reply.
> > I am beginning to understand how SOAP works.
> > Whether server or client, SOAP transforms the underlying data structures
> > into XML for transport, then each side is responsible for de-serializing
> > the XML back into it's native data format?
> >
> > I have a second question. How should one choose when to use RPC vs.
> > Messaging?
> >
> > Thanks
> > Stephen
> >
> > =======================================================================
> >
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Tuesday, August 06, 2002 2:26 PM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
> >
> > Stephen,
> >
> > Your Java SOAP server may view the person object as a Java class, but
> > from a
> > SOAP perspective, the person object is an XML structure. The
> > service-side
> > SOAP runtime engine should perform the transformation between the XML
> > structure and the Java class for you. Any language SOAP client should be
> > able to talk to your SOAP service. It shouldn't make a difference
> > whether
> > your use RPC or document style. You just need to tell the client how to
> > translate the person XML structure into the appropriate language
> > structure
> > (in this case, perl). In otehr words, you'll need to write a perl
> > deserializer for your client. (The same would be true whether you're
> > using
> > RPC or document.)
> >
> > Best regards,
> > Anne
> >
> > > -----Original Message-----
> > > From: stephen chan [mailto:stephenc@netnation.com]
> > > Sent: Tuesday, August 06, 2002 4:50 PM
> > > To: soap-user@xml.apache.org
> > > Subject: RE: May I ask a SOAP rpc vs. message question here?
> > >
> > >
> > > Hello:
> > >
> > > I have a question to ask regarding java soap server to perl soap
> > client.
> > >
> > > I have a java soap server with one service.
> > > It is a rpc oriented service.
> > > It has 2 methods - list, add.
> > >
> > > List will return a list of person objects.
> > > Add will require a person object as a parameter
> > > person object is a java class with first_name, last_name and email.
> > >
> > > I can do java soap client to java soap rpc server passing serialized
> > > person object
> > >
> > > Is this possible with let's say perl soap client to java soap server?
> > >
> > > How do non-java clients de-serialize the person object or create a
> > > serialized person object to communicate with the java based rpc web
> > > service?
> > >
> > > Maybe this isn't the way to do it. Maybe for cross-language soap
> > > client/server I should be using message-based soap?
> > >
> > > Thanks in advance
> > >
> > > Stephen
> > >
> > >
> > > ================================================================
> > >
> > > -----Original Message-----
> > > From: Anne Thomas Manes [mailto:anne@manes.net]
> > > Sent: Monday, August 05, 2002 9:36 AM
> > > To: soap-user@xml.apache.org
> > > Subject: RE: May I ask a SOAP rpc vs. message question here?
> > >
> > > Sure thing. Ask away.
> > >
> > > > -----Original Message-----
> > > > From: stephen chan [mailto:stephenc@netnation.com]
> > > > Sent: Friday, August 02, 2002 7:14 PM
> > > > To: soap-user@xml.apache.org
> > > > Subject: May I ask a SOAP rpc vs. message question here?
> > > >
> > > >
> > > > New to the list.
> > > > May I ask a SOAP rpc vs. message question here?
> > > > It pertains to Java service to Perl client.
> > > >
> > > > Thanks
> > > > Stephen
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@xml.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@xml.apache.org>
> > > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@xml.apache.org>
> > > For additional commands, e-mail:
> > <ma...@xml.apache.org>
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@xml.apache.org>
> > > For additional commands, e-mail:
> > <ma...@xml.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
RE: May I ask a SOAP rpc vs. message question here?
Posted by stephen chan <st...@netnation.com>.
Hello Anne:
Thank you very much for your detailed explanation. I am reading it over
and over to fully digest the content. With your reply in mind, I did
some searching on this subject of SOAP literal vs. encoded and I found
this article on the web:
http://www.vbws.com/tutors/rpcmsg/rpcmsgprint.aspx
Quoted from the last paragraph:
<start>
If you need to achieve interoperability, your best bet is to focus on
XML messaging and use literal-style SOAP. If you just need to call
methods on remote objects over the Web, consider using your platform’s
RPC mechanism instead of SOAP.
<end>
Also, I do recall from the O'reilly book "Java and XML" second edition,
there's a short chapter on SOAP messaging where the author advocates
using SOAP messaging services for inbound requests and then in turn
calls SOAP RPC services internally to do the work before sending out a
SOAP message as a response.
How do you feel about using SOAP this way?
Thanks
Stephen
========================================================================
=
-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Thursday, August 08, 2002 9:35 AM
To: soap-user@xml.apache.org
Subject: RE: May I ask a SOAP rpc vs. message question here?
Stephen,
> Whether server or client, SOAP transforms the underlying data
structures
> into XML for transport, then each side is responsible for
de-serializing
> the XML back into it's native data format?
You're correct.
> I have a second question. How should one choose when to use RPC vs.
> Messaging?
First let me explain the major differences between the RPC and Document
message styles (note that both of these styles are "messages"). The RPC
convention formats the input and output messages as XML structures. For
the
input message, the name of the structure (the top level element in the
message) is equivalent to the method name. The contents of the structure
are
the input parameters. For the output message, the structure contains the
return value plus any output parameters. Note that the RPC convention
doesn't permit you to use attributes. All parameters must be passed as
XML
elements. In most circumstances, the messages are encoded using SOAP
encoding (RPC/encoded)
If you aren't using the RPC convention (i.e., you're using the document
style), then you can format your input and output messages any way you
like.
Note that document style doesn't provide a convention for you to specify
the
name of the method to be invoked. If you need to pass a method name,
most
people use the SOAPAction HTTP header. In most circumstances, the
messages
are encoded according to an XML Schema (document/literal).
If you are simply sending messages and not specifying method names, then
obviously you want to use Document style. But if your service acts like
a
callable procedure, offering one or more methods requiring input and
output
parameters, from a practical point of view, it really doesn't make much
difference which style you use. You can implement RPC-style invocations
using both RPC and Document style messages. The WSDL file specifies the
message format, and your SOAP runtime can convert both RPC and Document
style messages into native language-based objects for you automatically.
I'd say that the more important decision that you need to make is not
RPC vs
Document, but Encoded vs Literal.
SOAP encoding provides a much more convenient mechanism to encode
complex
objects -- including cyclic object graphs. BUT: you can't validate an
RPC/encoded message. If you intend to pass cyclic object graphs,
multidimensional arrays, sparse arrays, etc., you probably want to use
RPC/encoded. If you're passing simple objects, then I'd recommend using
doc/literal.
Best regards,
Anne
> -----Original Message-----
> From: stephen chan [mailto:stephenc@netnation.com]
> Sent: Tuesday, August 06, 2002 6:03 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
>
> Anne:
>
> Thank you for your reply.
> I am beginning to understand how SOAP works.
> Whether server or client, SOAP transforms the underlying data
structures
> into XML for transport, then each side is responsible for
de-serializing
> the XML back into it's native data format?
>
> I have a second question. How should one choose when to use RPC vs.
> Messaging?
>
> Thanks
> Stephen
>
>
=======================================================================
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Tuesday, August 06, 2002 2:26 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
> Stephen,
>
> Your Java SOAP server may view the person object as a Java class, but
> from a
> SOAP perspective, the person object is an XML structure. The
> service-side
> SOAP runtime engine should perform the transformation between the XML
> structure and the Java class for you. Any language SOAP client should
be
> able to talk to your SOAP service. It shouldn't make a difference
> whether
> your use RPC or document style. You just need to tell the client how
to
> translate the person XML structure into the appropriate language
> structure
> (in this case, perl). In otehr words, you'll need to write a perl
> deserializer for your client. (The same would be true whether you're
> using
> RPC or document.)
>
> Best regards,
> Anne
>
> > -----Original Message-----
> > From: stephen chan [mailto:stephenc@netnation.com]
> > Sent: Tuesday, August 06, 2002 4:50 PM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
> >
> >
> > Hello:
> >
> > I have a question to ask regarding java soap server to perl soap
> client.
> >
> > I have a java soap server with one service.
> > It is a rpc oriented service.
> > It has 2 methods - list, add.
> >
> > List will return a list of person objects.
> > Add will require a person object as a parameter
> > person object is a java class with first_name, last_name and
email.
> >
> > I can do java soap client to java soap rpc server passing serialized
> > person object
> >
> > Is this possible with let's say perl soap client to java soap
server?
> >
> > How do non-java clients de-serialize the person object or create a
> > serialized person object to communicate with the java based rpc web
> > service?
> >
> > Maybe this isn't the way to do it. Maybe for cross-language soap
> > client/server I should be using message-based soap?
> >
> > Thanks in advance
> >
> > Stephen
> >
> >
> > ================================================================
> >
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Monday, August 05, 2002 9:36 AM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
> >
> > Sure thing. Ask away.
> >
> > > -----Original Message-----
> > > From: stephen chan [mailto:stephenc@netnation.com]
> > > Sent: Friday, August 02, 2002 7:14 PM
> > > To: soap-user@xml.apache.org
> > > Subject: May I ask a SOAP rpc vs. message question here?
> > >
> > >
> > > New to the list.
> > > May I ask a SOAP rpc vs. message question here?
> > > It pertains to Java service to Perl client.
> > >
> > > Thanks
> > > Stephen
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@xml.apache.org>
> > > For additional commands, e-mail:
> > <ma...@xml.apache.org>
> > >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
RE: May I ask a SOAP rpc vs. message question here?
Posted by Dan Allen <da...@nist.gov>.
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Thursday, August 08, 2002 12:35 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
> First let me explain the major differences between the RPC and Document
> message styles (note that both of these styles are "messages"). The RPC
> convention formats the input and output messages as XML structures. For the
> input message, the name of the structure (the top level element in the
> message) is equivalent to the method name. The contents of the structure are
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Where is this specified in the SOAP specification? I know it is common
usage but I haven't seen any explicit statement of this in the spec. I'd
also suggest that the proper place for this information is in the SOAP
Header ala the ebXML Message Specification (not that I'm wildly in love with
that monster either!).
> I'd say that the more important decision that you need to make is not RPC vs
> Document, but Encoded vs Literal.
>
I'd wholeheartedly agree with this statement.
> SOAP encoding provides a much more convenient mechanism to encode complex
> objects -- including cyclic object graphs. BUT: you can't validate an
> RPC/encoded message. If you intend to pass cyclic object graphs,
> multidimensional arrays, sparse arrays, etc., you probably want to use
> RPC/encoded. If you're passing simple objects, then I'd recommend using
> doc/literal.
Convenience is often in the eyes of the beholder. For example, "encoding"
strings is, in my opinion, massively inconvenient. The same goes for
most if not all of the standard XML data types. But, again in my opinion,
the truly big loss of encoding is the validation issue. This is a major
loss of XML functionality! The power to define a document structure using
a schema and have the XML parser do the egregious work of content validation
is a central design goal of XML schema. RPC style encoding puts the onus
back on the application programmer.
>
> Best regards,
> Anne
Just my $.02.
Dan
>
>
>
> > -----Original Message-----
> > From: stephen chan [mailto:stephenc@netnation.com]
> > Sent: Tuesday, August 06, 2002 6:03 PM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
> >
> >
> > Anne:
> >
> > Thank you for your reply.
> > I am beginning to understand how SOAP works.
> > Whether server or client, SOAP transforms the underlying data structures
> > into XML for transport, then each side is responsible for de-serializing
> > the XML back into it's native data format?
> >
> > I have a second question. How should one choose when to use RPC vs.
> > Messaging?
> >
> > Thanks
> > Stephen
> >
> > =======================================================================
> >
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Tuesday, August 06, 2002 2:26 PM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
> >
> > Stephen,
> >
> > Your Java SOAP server may view the person object as a Java class, but
> > from a
> > SOAP perspective, the person object is an XML structure. The
> > service-side
> > SOAP runtime engine should perform the transformation between the XML
> > structure and the Java class for you. Any language SOAP client should be
> > able to talk to your SOAP service. It shouldn't make a difference
> > whether
> > your use RPC or document style. You just need to tell the client how to
> > translate the person XML structure into the appropriate language
> > structure
> > (in this case, perl). In otehr words, you'll need to write a perl
> > deserializer for your client. (The same would be true whether you're
> > using
> > RPC or document.)
> >
> > Best regards,
> > Anne
> >
> > > -----Original Message-----
> > > From: stephen chan [mailto:stephenc@netnation.com]
> > > Sent: Tuesday, August 06, 2002 4:50 PM
> > > To: soap-user@xml.apache.org
> > > Subject: RE: May I ask a SOAP rpc vs. message question here?
> > >
> > >
> > > Hello:
> > >
> > > I have a question to ask regarding java soap server to perl soap
> > client.
> > >
> > > I have a java soap server with one service.
> > > It is a rpc oriented service.
> > > It has 2 methods - list, add.
> > >
> > > List will return a list of person objects.
> > > Add will require a person object as a parameter
> > > person object is a java class with first_name, last_name and email.
> > >
> > > I can do java soap client to java soap rpc server passing serialized
> > > person object
> > >
> > > Is this possible with let's say perl soap client to java soap server?
> > >
> > > How do non-java clients de-serialize the person object or create a
> > > serialized person object to communicate with the java based rpc web
> > > service?
> > >
> > > Maybe this isn't the way to do it. Maybe for cross-language soap
> > > client/server I should be using message-based soap?
> > >
> > > Thanks in advance
> > >
> > > Stephen
> > >
> > >
> > > ================================================================
> > >
> > > -----Original Message-----
> > > From: Anne Thomas Manes [mailto:anne@manes.net]
> > > Sent: Monday, August 05, 2002 9:36 AM
> > > To: soap-user@xml.apache.org
> > > Subject: RE: May I ask a SOAP rpc vs. message question here?
> > >
> > > Sure thing. Ask away.
> > >
> > > > -----Original Message-----
> > > > From: stephen chan [mailto:stephenc@netnation.com]
> > > > Sent: Friday, August 02, 2002 7:14 PM
> > > > To: soap-user@xml.apache.org
> > > > Subject: May I ask a SOAP rpc vs. message question here?
> > > >
> > > >
> > > > New to the list.
> > > > May I ask a SOAP rpc vs. message question here?
> > > > It pertains to Java service to Perl client.
> > > >
> > > > Thanks
> > > > Stephen
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@xml.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@xml.apache.org>
> > > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@xml.apache.org>
> > > For additional commands, e-mail:
> > <ma...@xml.apache.org>
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@xml.apache.org>
> > > For additional commands, e-mail:
> > <ma...@xml.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
RE: May I ask a SOAP rpc vs. message question here?
Posted by stephen chan <st...@netnation.com>.
Hello Anne:
Thank you very much for your detailed explanation. I am reading it over
and over to fully digest the content. With your reply in mind, I did
some searching on this subject of SOAP literal vs. encoded and I found
this article on the web:
http://www.vbws.com/tutors/rpcmsg/rpcmsgprint.aspx
Quoted from the last paragraph:
<start>
If you need to achieve interoperability, your best bet is to focus on
XML messaging and use literal-style SOAP. If you just need to call
methods on remote objects over the Web, consider using your platform’s
RPC mechanism instead of SOAP.
<end>
Also, I do recall from the O'reilly book "Java and XML" second edition,
there's a short chapter on SOAP messaging where the author advocates
using SOAP messaging services for inbound requests and then in turn
calls SOAP RPC services internally to do the work before sending out a
SOAP message as a response.
How do you feel about using SOAP this way?
Thanks
Stephen
========================================================================
=
-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Thursday, August 08, 2002 9:35 AM
To: soap-user@xml.apache.org
Subject: RE: May I ask a SOAP rpc vs. message question here?
Stephen,
> Whether server or client, SOAP transforms the underlying data
structures
> into XML for transport, then each side is responsible for
de-serializing
> the XML back into it's native data format?
You're correct.
> I have a second question. How should one choose when to use RPC vs.
> Messaging?
First let me explain the major differences between the RPC and Document
message styles (note that both of these styles are "messages"). The RPC
convention formats the input and output messages as XML structures. For
the
input message, the name of the structure (the top level element in the
message) is equivalent to the method name. The contents of the structure
are
the input parameters. For the output message, the structure contains the
return value plus any output parameters. Note that the RPC convention
doesn't permit you to use attributes. All parameters must be passed as
XML
elements. In most circumstances, the messages are encoded using SOAP
encoding (RPC/encoded)
If you aren't using the RPC convention (i.e., you're using the document
style), then you can format your input and output messages any way you
like.
Note that document style doesn't provide a convention for you to specify
the
name of the method to be invoked. If you need to pass a method name,
most
people use the SOAPAction HTTP header. In most circumstances, the
messages
are encoded according to an XML Schema (document/literal).
If you are simply sending messages and not specifying method names, then
obviously you want to use Document style. But if your service acts like
a
callable procedure, offering one or more methods requiring input and
output
parameters, from a practical point of view, it really doesn't make much
difference which style you use. You can implement RPC-style invocations
using both RPC and Document style messages. The WSDL file specifies the
message format, and your SOAP runtime can convert both RPC and Document
style messages into native language-based objects for you automatically.
I'd say that the more important decision that you need to make is not
RPC vs
Document, but Encoded vs Literal.
SOAP encoding provides a much more convenient mechanism to encode
complex
objects -- including cyclic object graphs. BUT: you can't validate an
RPC/encoded message. If you intend to pass cyclic object graphs,
multidimensional arrays, sparse arrays, etc., you probably want to use
RPC/encoded. If you're passing simple objects, then I'd recommend using
doc/literal.
Best regards,
Anne
> -----Original Message-----
> From: stephen chan [mailto:stephenc@netnation.com]
> Sent: Tuesday, August 06, 2002 6:03 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
>
> Anne:
>
> Thank you for your reply.
> I am beginning to understand how SOAP works.
> Whether server or client, SOAP transforms the underlying data
structures
> into XML for transport, then each side is responsible for
de-serializing
> the XML back into it's native data format?
>
> I have a second question. How should one choose when to use RPC vs.
> Messaging?
>
> Thanks
> Stephen
>
>
=======================================================================
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Tuesday, August 06, 2002 2:26 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
> Stephen,
>
> Your Java SOAP server may view the person object as a Java class, but
> from a
> SOAP perspective, the person object is an XML structure. The
> service-side
> SOAP runtime engine should perform the transformation between the XML
> structure and the Java class for you. Any language SOAP client should
be
> able to talk to your SOAP service. It shouldn't make a difference
> whether
> your use RPC or document style. You just need to tell the client how
to
> translate the person XML structure into the appropriate language
> structure
> (in this case, perl). In otehr words, you'll need to write a perl
> deserializer for your client. (The same would be true whether you're
> using
> RPC or document.)
>
> Best regards,
> Anne
>
> > -----Original Message-----
> > From: stephen chan [mailto:stephenc@netnation.com]
> > Sent: Tuesday, August 06, 2002 4:50 PM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
> >
> >
> > Hello:
> >
> > I have a question to ask regarding java soap server to perl soap
> client.
> >
> > I have a java soap server with one service.
> > It is a rpc oriented service.
> > It has 2 methods - list, add.
> >
> > List will return a list of person objects.
> > Add will require a person object as a parameter
> > person object is a java class with first_name, last_name and
email.
> >
> > I can do java soap client to java soap rpc server passing serialized
> > person object
> >
> > Is this possible with let's say perl soap client to java soap
server?
> >
> > How do non-java clients de-serialize the person object or create a
> > serialized person object to communicate with the java based rpc web
> > service?
> >
> > Maybe this isn't the way to do it. Maybe for cross-language soap
> > client/server I should be using message-based soap?
> >
> > Thanks in advance
> >
> > Stephen
> >
> >
> > ================================================================
> >
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Monday, August 05, 2002 9:36 AM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
> >
> > Sure thing. Ask away.
> >
> > > -----Original Message-----
> > > From: stephen chan [mailto:stephenc@netnation.com]
> > > Sent: Friday, August 02, 2002 7:14 PM
> > > To: soap-user@xml.apache.org
> > > Subject: May I ask a SOAP rpc vs. message question here?
> > >
> > >
> > > New to the list.
> > > May I ask a SOAP rpc vs. message question here?
> > > It pertains to Java service to Perl client.
> > >
> > > Thanks
> > > Stephen
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@xml.apache.org>
> > > For additional commands, e-mail:
> > <ma...@xml.apache.org>
> > >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
RE: May I ask a SOAP rpc vs. message question here?
Posted by Anne Thomas Manes <an...@manes.net>.
Stephen,
> Whether server or client, SOAP transforms the underlying data structures
> into XML for transport, then each side is responsible for de-serializing
> the XML back into it's native data format?
You're correct.
> I have a second question. How should one choose when to use RPC vs.
> Messaging?
First let me explain the major differences between the RPC and Document
message styles (note that both of these styles are "messages"). The RPC
convention formats the input and output messages as XML structures. For the
input message, the name of the structure (the top level element in the
message) is equivalent to the method name. The contents of the structure are
the input parameters. For the output message, the structure contains the
return value plus any output parameters. Note that the RPC convention
doesn't permit you to use attributes. All parameters must be passed as XML
elements. In most circumstances, the messages are encoded using SOAP
encoding (RPC/encoded)
If you aren't using the RPC convention (i.e., you're using the document
style), then you can format your input and output messages any way you like.
Note that document style doesn't provide a convention for you to specify the
name of the method to be invoked. If you need to pass a method name, most
people use the SOAPAction HTTP header. In most circumstances, the messages
are encoded according to an XML Schema (document/literal).
If you are simply sending messages and not specifying method names, then
obviously you want to use Document style. But if your service acts like a
callable procedure, offering one or more methods requiring input and output
parameters, from a practical point of view, it really doesn't make much
difference which style you use. You can implement RPC-style invocations
using both RPC and Document style messages. The WSDL file specifies the
message format, and your SOAP runtime can convert both RPC and Document
style messages into native language-based objects for you automatically.
I'd say that the more important decision that you need to make is not RPC vs
Document, but Encoded vs Literal.
SOAP encoding provides a much more convenient mechanism to encode complex
objects -- including cyclic object graphs. BUT: you can't validate an
RPC/encoded message. If you intend to pass cyclic object graphs,
multidimensional arrays, sparse arrays, etc., you probably want to use
RPC/encoded. If you're passing simple objects, then I'd recommend using
doc/literal.
Best regards,
Anne
> -----Original Message-----
> From: stephen chan [mailto:stephenc@netnation.com]
> Sent: Tuesday, August 06, 2002 6:03 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
>
> Anne:
>
> Thank you for your reply.
> I am beginning to understand how SOAP works.
> Whether server or client, SOAP transforms the underlying data structures
> into XML for transport, then each side is responsible for de-serializing
> the XML back into it's native data format?
>
> I have a second question. How should one choose when to use RPC vs.
> Messaging?
>
> Thanks
> Stephen
>
> =======================================================================
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Tuesday, August 06, 2002 2:26 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
> Stephen,
>
> Your Java SOAP server may view the person object as a Java class, but
> from a
> SOAP perspective, the person object is an XML structure. The
> service-side
> SOAP runtime engine should perform the transformation between the XML
> structure and the Java class for you. Any language SOAP client should be
> able to talk to your SOAP service. It shouldn't make a difference
> whether
> your use RPC or document style. You just need to tell the client how to
> translate the person XML structure into the appropriate language
> structure
> (in this case, perl). In otehr words, you'll need to write a perl
> deserializer for your client. (The same would be true whether you're
> using
> RPC or document.)
>
> Best regards,
> Anne
>
> > -----Original Message-----
> > From: stephen chan [mailto:stephenc@netnation.com]
> > Sent: Tuesday, August 06, 2002 4:50 PM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
> >
> >
> > Hello:
> >
> > I have a question to ask regarding java soap server to perl soap
> client.
> >
> > I have a java soap server with one service.
> > It is a rpc oriented service.
> > It has 2 methods - list, add.
> >
> > List will return a list of person objects.
> > Add will require a person object as a parameter
> > person object is a java class with first_name, last_name and email.
> >
> > I can do java soap client to java soap rpc server passing serialized
> > person object
> >
> > Is this possible with let's say perl soap client to java soap server?
> >
> > How do non-java clients de-serialize the person object or create a
> > serialized person object to communicate with the java based rpc web
> > service?
> >
> > Maybe this isn't the way to do it. Maybe for cross-language soap
> > client/server I should be using message-based soap?
> >
> > Thanks in advance
> >
> > Stephen
> >
> >
> > ================================================================
> >
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Monday, August 05, 2002 9:36 AM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
> >
> > Sure thing. Ask away.
> >
> > > -----Original Message-----
> > > From: stephen chan [mailto:stephenc@netnation.com]
> > > Sent: Friday, August 02, 2002 7:14 PM
> > > To: soap-user@xml.apache.org
> > > Subject: May I ask a SOAP rpc vs. message question here?
> > >
> > >
> > > New to the list.
> > > May I ask a SOAP rpc vs. message question here?
> > > It pertains to Java service to Perl client.
> > >
> > > Thanks
> > > Stephen
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@xml.apache.org>
> > > For additional commands, e-mail:
> > <ma...@xml.apache.org>
> > >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
RE: May I ask a SOAP rpc vs. message question here?
Posted by Anne Thomas Manes <an...@manes.net>.
Stephen,
> Whether server or client, SOAP transforms the underlying data structures
> into XML for transport, then each side is responsible for de-serializing
> the XML back into it's native data format?
You're correct.
> I have a second question. How should one choose when to use RPC vs.
> Messaging?
First let me explain the major differences between the RPC and Document
message styles (note that both of these styles are "messages"). The RPC
convention formats the input and output messages as XML structures. For the
input message, the name of the structure (the top level element in the
message) is equivalent to the method name. The contents of the structure are
the input parameters. For the output message, the structure contains the
return value plus any output parameters. Note that the RPC convention
doesn't permit you to use attributes. All parameters must be passed as XML
elements. In most circumstances, the messages are encoded using SOAP
encoding (RPC/encoded)
If you aren't using the RPC convention (i.e., you're using the document
style), then you can format your input and output messages any way you like.
Note that document style doesn't provide a convention for you to specify the
name of the method to be invoked. If you need to pass a method name, most
people use the SOAPAction HTTP header. In most circumstances, the messages
are encoded according to an XML Schema (document/literal).
If you are simply sending messages and not specifying method names, then
obviously you want to use Document style. But if your service acts like a
callable procedure, offering one or more methods requiring input and output
parameters, from a practical point of view, it really doesn't make much
difference which style you use. You can implement RPC-style invocations
using both RPC and Document style messages. The WSDL file specifies the
message format, and your SOAP runtime can convert both RPC and Document
style messages into native language-based objects for you automatically.
I'd say that the more important decision that you need to make is not RPC vs
Document, but Encoded vs Literal.
SOAP encoding provides a much more convenient mechanism to encode complex
objects -- including cyclic object graphs. BUT: you can't validate an
RPC/encoded message. If you intend to pass cyclic object graphs,
multidimensional arrays, sparse arrays, etc., you probably want to use
RPC/encoded. If you're passing simple objects, then I'd recommend using
doc/literal.
Best regards,
Anne
> -----Original Message-----
> From: stephen chan [mailto:stephenc@netnation.com]
> Sent: Tuesday, August 06, 2002 6:03 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
>
> Anne:
>
> Thank you for your reply.
> I am beginning to understand how SOAP works.
> Whether server or client, SOAP transforms the underlying data structures
> into XML for transport, then each side is responsible for de-serializing
> the XML back into it's native data format?
>
> I have a second question. How should one choose when to use RPC vs.
> Messaging?
>
> Thanks
> Stephen
>
> =======================================================================
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Tuesday, August 06, 2002 2:26 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
> Stephen,
>
> Your Java SOAP server may view the person object as a Java class, but
> from a
> SOAP perspective, the person object is an XML structure. The
> service-side
> SOAP runtime engine should perform the transformation between the XML
> structure and the Java class for you. Any language SOAP client should be
> able to talk to your SOAP service. It shouldn't make a difference
> whether
> your use RPC or document style. You just need to tell the client how to
> translate the person XML structure into the appropriate language
> structure
> (in this case, perl). In otehr words, you'll need to write a perl
> deserializer for your client. (The same would be true whether you're
> using
> RPC or document.)
>
> Best regards,
> Anne
>
> > -----Original Message-----
> > From: stephen chan [mailto:stephenc@netnation.com]
> > Sent: Tuesday, August 06, 2002 4:50 PM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
> >
> >
> > Hello:
> >
> > I have a question to ask regarding java soap server to perl soap
> client.
> >
> > I have a java soap server with one service.
> > It is a rpc oriented service.
> > It has 2 methods - list, add.
> >
> > List will return a list of person objects.
> > Add will require a person object as a parameter
> > person object is a java class with first_name, last_name and email.
> >
> > I can do java soap client to java soap rpc server passing serialized
> > person object
> >
> > Is this possible with let's say perl soap client to java soap server?
> >
> > How do non-java clients de-serialize the person object or create a
> > serialized person object to communicate with the java based rpc web
> > service?
> >
> > Maybe this isn't the way to do it. Maybe for cross-language soap
> > client/server I should be using message-based soap?
> >
> > Thanks in advance
> >
> > Stephen
> >
> >
> > ================================================================
> >
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Monday, August 05, 2002 9:36 AM
> > To: soap-user@xml.apache.org
> > Subject: RE: May I ask a SOAP rpc vs. message question here?
> >
> > Sure thing. Ask away.
> >
> > > -----Original Message-----
> > > From: stephen chan [mailto:stephenc@netnation.com]
> > > Sent: Friday, August 02, 2002 7:14 PM
> > > To: soap-user@xml.apache.org
> > > Subject: May I ask a SOAP rpc vs. message question here?
> > >
> > >
> > > New to the list.
> > > May I ask a SOAP rpc vs. message question here?
> > > It pertains to Java service to Perl client.
> > >
> > > Thanks
> > > Stephen
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@xml.apache.org>
> > > For additional commands, e-mail:
> > <ma...@xml.apache.org>
> > >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
problem with message service
Posted by stephen chan <st...@netnation.com>.
Hello:
I am working through the book examples in Java and SOAP from O'Reilly.
At the beginning of Chapter 8 there's a simple messaging example, I
deployed it like this:
- java org.apache.soap.server.ServiceManagerClient
http://localhost:8080/soap/servlet/rpcrouter deploy WeatherDiary.dd
I can see the above service deployed in SOAP admin. When I run the
corresponding client to talk to the server, I get this:
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Exception while handling service request:
WeatherDiary.recordTemperature(org.apache.soap.Envelope,org.apache.soap.
rpc.SOAPContext,org.apache.soap.rpc.SOAPContext) -- no signature
match</faultstring>
<faultactor>/soap/servlet/messagerouter</faultactor>
<detail>
<stackTrace>java.lang.NoSuchMethodException:
WeatherDiary.recordTemperature(org.apache.soap.Envelope,org.apache.soap.
rpc.SOAPContext,org.apache.soap.rpc.SOAPContext) -- no signature match
at
org.apache.soap.util.MethodUtils.getEntryPoint(MethodUtils.java:194)
at
org.apache.soap.util.MethodUtils.getMethod(MethodUtils.java:548)
cut...
Why do I get a "NoSuchMethodException"? I think I have deployed the
service correctly. BTW, the same happened when I tried a messaging
example from another book. I don't have this problem with RPC SOAP
services.
-----------------------------------------------
WeatherDiary.dd
<isd:service
xmlns:isd="http://xml.apache.org/xml-soap/deployment"
id="urn:WeatherDiary" type="message">
<isd:provider
type="java"
scope="Application"
methods="recordTemperature">
<isd:java
class="WeatherDiary"
static="false"/>
</isd:provider>
<isd:faultListener>org.apache.soap.server.DOMFaultListener</isd:faultLis
tener>
<isd:mappings>
</isd:mappings>
</isd:service>
------------------------------------------------------------------------
---
WeatherDiary.java
import java.io.*;
import java.util.*;
import org.apache.soap.*;
import org.apache.soap.rpc.SOAPContext;
import javax.mail.MessagingException;
import org.w3c.dom.*;
public class WeatherDiary
{
Hashtable _diary = new Hashtable();
public void recordTemperature(Envelope env,
SOAPContext reqCtx,
SOAPContext resCtx)
throws Exception
{
Vector v = env.getBody().getBodyEntries();
int cnt = v.size();
String zipcode = null;
String temperature = null;
for (int i = 0; i < cnt; i++)
{
Element e = (Element)v.elementAt(i);
String name = e.getTagName();
if(name.equals("zipcode"))
{
zipcode = e.getFirstChild().getNodeValue();
}
else if(name.equals("temperature"))
{
temperature = e.getFirstChild().getNodeValue();
}
}
if (zipcode == null || temperature == null)
throw new IllegalArgumentException("ZIPCODE and/or
TEMPERATURE Not Specified");
_diary.put(zipcode, temperature);
resCtx.setRootPart("OK", "text/xml");
}
}
------------------------------------------------------------------------
----
WeatherClient.java
import java.io.*;
import java.net.*;
import javax.xml.parsers.*;
import org.w3c.dom.*;
import org.xml.sax.*;
import org.apache.soap.*;
import org.apache.soap.messaging.*;
import org.apache.soap.transport.*;
import org.apache.soap.util.xml.*;
public class WeatherClient {
public static void main (String[] args) throws Exception {
DocumentBuilder xdb = XMLParserUtils.getXMLDocBuilder();
Document doc = xdb.newDocument();
Element elem =
doc.createElementNS(Constants.NS_URI_SOAP_ENV,
"SOAP-ENV:Envelope");
doc.appendChild(elem);
Element sub =
doc.createElementNS(Constants.NS_URI_SOAP_ENV,
"SOAP-ENV:Body");
elem.appendChild(sub);
elem = sub;
sub = doc.createElement("recordTemperature");
sub.setAttribute("xmlns", "urn:WeatherDiary");
elem.appendChild(sub);
sub = doc.createElement("zipcode");
Text txt = doc.createTextNode("");
txt.setData("12345");
sub.appendChild(txt);
elem.appendChild(sub);
sub = doc.createElement("temperature");
txt = doc.createTextNode("");
txt.setData("52.3");
sub.appendChild(txt);
elem.appendChild(sub);
Envelope msgEnv = Envelope.unmarshall(
doc.getDocumentElement());
URL url = new URL(
"http://localhost:8080/soap/servlet/messagerouter");
Message msg = new Message();
msg.send(url, "", msgEnv);
SOAPTransport st = msg.getSOAPTransport();
BufferedReader br = st.receive();
String line;
while ((line = br.readLine()) != null) {
System.out.println(line);
}
}
}
RE: May I ask a SOAP rpc vs. message question here?
Posted by stephen chan <st...@netnation.com>.
Anne:
Thank you for your reply.
I am beginning to understand how SOAP works.
Whether server or client, SOAP transforms the underlying data structures
into XML for transport, then each side is responsible for de-serializing
the XML back into it's native data format?
I have a second question. How should one choose when to use RPC vs.
Messaging?
Thanks
Stephen
=======================================================================
-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Tuesday, August 06, 2002 2:26 PM
To: soap-user@xml.apache.org
Subject: RE: May I ask a SOAP rpc vs. message question here?
Stephen,
Your Java SOAP server may view the person object as a Java class, but
from a
SOAP perspective, the person object is an XML structure. The
service-side
SOAP runtime engine should perform the transformation between the XML
structure and the Java class for you. Any language SOAP client should be
able to talk to your SOAP service. It shouldn't make a difference
whether
your use RPC or document style. You just need to tell the client how to
translate the person XML structure into the appropriate language
structure
(in this case, perl). In otehr words, you'll need to write a perl
deserializer for your client. (The same would be true whether you're
using
RPC or document.)
Best regards,
Anne
> -----Original Message-----
> From: stephen chan [mailto:stephenc@netnation.com]
> Sent: Tuesday, August 06, 2002 4:50 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
>
> Hello:
>
> I have a question to ask regarding java soap server to perl soap
client.
>
> I have a java soap server with one service.
> It is a rpc oriented service.
> It has 2 methods - list, add.
>
> List will return a list of person objects.
> Add will require a person object as a parameter
> person object is a java class with first_name, last_name and email.
>
> I can do java soap client to java soap rpc server passing serialized
> person object
>
> Is this possible with let's say perl soap client to java soap server?
>
> How do non-java clients de-serialize the person object or create a
> serialized person object to communicate with the java based rpc web
> service?
>
> Maybe this isn't the way to do it. Maybe for cross-language soap
> client/server I should be using message-based soap?
>
> Thanks in advance
>
> Stephen
>
>
> ================================================================
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Monday, August 05, 2002 9:36 AM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
> Sure thing. Ask away.
>
> > -----Original Message-----
> > From: stephen chan [mailto:stephenc@netnation.com]
> > Sent: Friday, August 02, 2002 7:14 PM
> > To: soap-user@xml.apache.org
> > Subject: May I ask a SOAP rpc vs. message question here?
> >
> >
> > New to the list.
> > May I ask a SOAP rpc vs. message question here?
> > It pertains to Java service to Perl client.
> >
> > Thanks
> > Stephen
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
RE: May I ask a SOAP rpc vs. message question here?
Posted by stephen chan <st...@netnation.com>.
Anne:
Thank you for your reply.
I am beginning to understand how SOAP works.
Whether server or client, SOAP transforms the underlying data structures
into XML for transport, then each side is responsible for de-serializing
the XML back into it's native data format?
I have a second question. How should one choose when to use RPC vs.
Messaging?
Thanks
Stephen
=======================================================================
-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Tuesday, August 06, 2002 2:26 PM
To: soap-user@xml.apache.org
Subject: RE: May I ask a SOAP rpc vs. message question here?
Stephen,
Your Java SOAP server may view the person object as a Java class, but
from a
SOAP perspective, the person object is an XML structure. The
service-side
SOAP runtime engine should perform the transformation between the XML
structure and the Java class for you. Any language SOAP client should be
able to talk to your SOAP service. It shouldn't make a difference
whether
your use RPC or document style. You just need to tell the client how to
translate the person XML structure into the appropriate language
structure
(in this case, perl). In otehr words, you'll need to write a perl
deserializer for your client. (The same would be true whether you're
using
RPC or document.)
Best regards,
Anne
> -----Original Message-----
> From: stephen chan [mailto:stephenc@netnation.com]
> Sent: Tuesday, August 06, 2002 4:50 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
>
> Hello:
>
> I have a question to ask regarding java soap server to perl soap
client.
>
> I have a java soap server with one service.
> It is a rpc oriented service.
> It has 2 methods - list, add.
>
> List will return a list of person objects.
> Add will require a person object as a parameter
> person object is a java class with first_name, last_name and email.
>
> I can do java soap client to java soap rpc server passing serialized
> person object
>
> Is this possible with let's say perl soap client to java soap server?
>
> How do non-java clients de-serialize the person object or create a
> serialized person object to communicate with the java based rpc web
> service?
>
> Maybe this isn't the way to do it. Maybe for cross-language soap
> client/server I should be using message-based soap?
>
> Thanks in advance
>
> Stephen
>
>
> ================================================================
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Monday, August 05, 2002 9:36 AM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
> Sure thing. Ask away.
>
> > -----Original Message-----
> > From: stephen chan [mailto:stephenc@netnation.com]
> > Sent: Friday, August 02, 2002 7:14 PM
> > To: soap-user@xml.apache.org
> > Subject: May I ask a SOAP rpc vs. message question here?
> >
> >
> > New to the list.
> > May I ask a SOAP rpc vs. message question here?
> > It pertains to Java service to Perl client.
> >
> > Thanks
> > Stephen
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
RE: May I ask a SOAP rpc vs. message question here?
Posted by Anne Thomas Manes <an...@manes.net>.
Stephen,
Your Java SOAP server may view the person object as a Java class, but from a
SOAP perspective, the person object is an XML structure. The service-side
SOAP runtime engine should perform the transformation between the XML
structure and the Java class for you. Any language SOAP client should be
able to talk to your SOAP service. It shouldn't make a difference whether
your use RPC or document style. You just need to tell the client how to
translate the person XML structure into the appropriate language structure
(in this case, perl). In otehr words, you'll need to write a perl
deserializer for your client. (The same would be true whether you're using
RPC or document.)
Best regards,
Anne
> -----Original Message-----
> From: stephen chan [mailto:stephenc@netnation.com]
> Sent: Tuesday, August 06, 2002 4:50 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
>
> Hello:
>
> I have a question to ask regarding java soap server to perl soap client.
>
> I have a java soap server with one service.
> It is a rpc oriented service.
> It has 2 methods - list, add.
>
> List will return a list of person objects.
> Add will require a person object as a parameter
> person object is a java class with first_name, last_name and email.
>
> I can do java soap client to java soap rpc server passing serialized
> person object
>
> Is this possible with let's say perl soap client to java soap server?
>
> How do non-java clients de-serialize the person object or create a
> serialized person object to communicate with the java based rpc web
> service?
>
> Maybe this isn't the way to do it. Maybe for cross-language soap
> client/server I should be using message-based soap?
>
> Thanks in advance
>
> Stephen
>
>
> ================================================================
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Monday, August 05, 2002 9:36 AM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
> Sure thing. Ask away.
>
> > -----Original Message-----
> > From: stephen chan [mailto:stephenc@netnation.com]
> > Sent: Friday, August 02, 2002 7:14 PM
> > To: soap-user@xml.apache.org
> > Subject: May I ask a SOAP rpc vs. message question here?
> >
> >
> > New to the list.
> > May I ask a SOAP rpc vs. message question here?
> > It pertains to Java service to Perl client.
> >
> > Thanks
> > Stephen
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
RE: May I ask a SOAP rpc vs. message question here?
Posted by Anne Thomas Manes <an...@manes.net>.
Stephen,
Your Java SOAP server may view the person object as a Java class, but from a
SOAP perspective, the person object is an XML structure. The service-side
SOAP runtime engine should perform the transformation between the XML
structure and the Java class for you. Any language SOAP client should be
able to talk to your SOAP service. It shouldn't make a difference whether
your use RPC or document style. You just need to tell the client how to
translate the person XML structure into the appropriate language structure
(in this case, perl). In otehr words, you'll need to write a perl
deserializer for your client. (The same would be true whether you're using
RPC or document.)
Best regards,
Anne
> -----Original Message-----
> From: stephen chan [mailto:stephenc@netnation.com]
> Sent: Tuesday, August 06, 2002 4:50 PM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
>
> Hello:
>
> I have a question to ask regarding java soap server to perl soap client.
>
> I have a java soap server with one service.
> It is a rpc oriented service.
> It has 2 methods - list, add.
>
> List will return a list of person objects.
> Add will require a person object as a parameter
> person object is a java class with first_name, last_name and email.
>
> I can do java soap client to java soap rpc server passing serialized
> person object
>
> Is this possible with let's say perl soap client to java soap server?
>
> How do non-java clients de-serialize the person object or create a
> serialized person object to communicate with the java based rpc web
> service?
>
> Maybe this isn't the way to do it. Maybe for cross-language soap
> client/server I should be using message-based soap?
>
> Thanks in advance
>
> Stephen
>
>
> ================================================================
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Monday, August 05, 2002 9:36 AM
> To: soap-user@xml.apache.org
> Subject: RE: May I ask a SOAP rpc vs. message question here?
>
> Sure thing. Ask away.
>
> > -----Original Message-----
> > From: stephen chan [mailto:stephenc@netnation.com]
> > Sent: Friday, August 02, 2002 7:14 PM
> > To: soap-user@xml.apache.org
> > Subject: May I ask a SOAP rpc vs. message question here?
> >
> >
> > New to the list.
> > May I ask a SOAP rpc vs. message question here?
> > It pertains to Java service to Perl client.
> >
> > Thanks
> > Stephen
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
RE: May I ask a SOAP rpc vs. message question here?
Posted by stephen chan <st...@netnation.com>.
Hello:
I have a question to ask regarding java soap server to perl soap client.
I have a java soap server with one service.
It is a rpc oriented service.
It has 2 methods - list, add.
List will return a list of person objects.
Add will require a person object as a parameter
person object is a java class with first_name, last_name and email.
I can do java soap client to java soap rpc server passing serialized
person object
Is this possible with let's say perl soap client to java soap server?
How do non-java clients de-serialize the person object or create a
serialized person object to communicate with the java based rpc web
service?
Maybe this isn't the way to do it. Maybe for cross-language soap
client/server I should be using message-based soap?
Thanks in advance
Stephen
================================================================
-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Monday, August 05, 2002 9:36 AM
To: soap-user@xml.apache.org
Subject: RE: May I ask a SOAP rpc vs. message question here?
Sure thing. Ask away.
> -----Original Message-----
> From: stephen chan [mailto:stephenc@netnation.com]
> Sent: Friday, August 02, 2002 7:14 PM
> To: soap-user@xml.apache.org
> Subject: May I ask a SOAP rpc vs. message question here?
>
>
> New to the list.
> May I ask a SOAP rpc vs. message question here?
> It pertains to Java service to Perl client.
>
> Thanks
> Stephen
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
RE: May I ask a SOAP rpc vs. message question here?
Posted by stephen chan <st...@netnation.com>.
Hello:
I have a question to ask regarding java soap server to perl soap client.
I have a java soap server with one service.
It is a rpc oriented service.
It has 2 methods - list, add.
List will return a list of person objects.
Add will require a person object as a parameter
person object is a java class with first_name, last_name and email.
I can do java soap client to java soap rpc server passing serialized
person object
Is this possible with let's say perl soap client to java soap server?
How do non-java clients de-serialize the person object or create a
serialized person object to communicate with the java based rpc web
service?
Maybe this isn't the way to do it. Maybe for cross-language soap
client/server I should be using message-based soap?
Thanks in advance
Stephen
================================================================
-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Monday, August 05, 2002 9:36 AM
To: soap-user@xml.apache.org
Subject: RE: May I ask a SOAP rpc vs. message question here?
Sure thing. Ask away.
> -----Original Message-----
> From: stephen chan [mailto:stephenc@netnation.com]
> Sent: Friday, August 02, 2002 7:14 PM
> To: soap-user@xml.apache.org
> Subject: May I ask a SOAP rpc vs. message question here?
>
>
> New to the list.
> May I ask a SOAP rpc vs. message question here?
> It pertains to Java service to Perl client.
>
> Thanks
> Stephen
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
RE: May I ask a SOAP rpc vs. message question here?
Posted by Anne Thomas Manes <an...@manes.net>.
Sure thing. Ask away.
> -----Original Message-----
> From: stephen chan [mailto:stephenc@netnation.com]
> Sent: Friday, August 02, 2002 7:14 PM
> To: soap-user@xml.apache.org
> Subject: May I ask a SOAP rpc vs. message question here?
>
>
> New to the list.
> May I ask a SOAP rpc vs. message question here?
> It pertains to Java service to Perl client.
>
> Thanks
> Stephen
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
RE: May I ask a SOAP rpc vs. message question here?
Posted by Anne Thomas Manes <an...@manes.net>.
Sure thing. Ask away.
> -----Original Message-----
> From: stephen chan [mailto:stephenc@netnation.com]
> Sent: Friday, August 02, 2002 7:14 PM
> To: soap-user@xml.apache.org
> Subject: May I ask a SOAP rpc vs. message question here?
>
>
> New to the list.
> May I ask a SOAP rpc vs. message question here?
> It pertains to Java service to Perl client.
>
> Thanks
> Stephen
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>