You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by Je...@manulife.com on 2000/10/19 14:16:29 UTC
ServiceManager on the Client
Has anyone studied the code for the AddressBook example? It seems that
GetAddress spends an awful lot of time trying to set the paramsters for
various SOAP objects. And All these paramters are documented in the
DeploymentDescriptor file. Here, take a look yourself:
SOAPMappingRegistry smr = new SOAPMappingRegistry();
BeanSerializer beanSer = new BeanSerializer();
// Map the types.
smr.mapTypes(Constants.NS_URI_SOAP_ENC,
new QName("urn:xml-soap-address-demo", "address"),
Address.class, beanSer, beanSer);
smr.mapTypes(Constants.NS_URI_SOAP_ENC,
new QName("urn:xml-soap-address-demo", "phone"),
PhoneNumber.class, beanSer, beanSer);
...
call.setSOAPMappingRegistry(smr);
call.setTargetObjectURI("urn:AddressFetcher");
call.setMethodName("getAddressFromName");
call.setEncodingStyleURI(encodingStyleURI);
But the server (RPCROUTER) does not do this. It just calls the servicemanager, and servicemanger has this infromation already.
Shouldn't we have a CLIENT side servicemanger that can do this:
org.apache.soap.client.ServiceManager.configYourselfUsingDescriptorFile("DeploymentDescriptor.xml");
Vector params = new Vector();
params.addElement(new Parameter("nameToLookup", String.class,
nameToLookup, null));
call.setParams(params);
...
Jeff Saremi
Manulife Financial
416.926.3000 x7005
Fax: 416.926.5366
Jeff_Saremi@manulife.com
Re: ServiceManager on the Client
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
I'm afraid this is a subtle issue.
Consider service s with operations o1 and o2 working on types t1, t2
and t3. Apache SOAP supports the authoring of services in Java
(and some scripting languages via BSF). Even for the BSF case,
the actual service invocation occurs via Java, so the baseline
is Java.
The description of the service would be by a WSDL file that has
(amongst other things):
<message name="m1">
<part type="t1"/>
</message>
<operation name="o1">
<input message="m1"/>
<output message="m2"/>
</operation>
(I'm using loose syntax.) The above tells a *user of the service*
all the relevant information about how to invoke the service. Now,
as the author of the service, you have chosen specific language
bindings for the various types t1, t2 and t3 in the implementation
language (Java, in this case), lets say com.foo.t1, com.foo.t2 and
com.foo.t3. The service author then would write a deployment
descriptor file which will tell the server runtime the relationship
between (abstract or schema) types t1, t2 and t3 and com.foo.t1,
com.foo.t2, and com.foo.t3, respectively, as well as the names of
the serializer/deserializer classes to go back and forth between the
abstract/schema type and the concrete Java type.
OK, that's the server (service-author) side. Now consider a user
of the service. That person takes the WSDL description of the
service and decides what types to bind the types t1, t2 and t3
to in their client language / platform. If the client were in
Java, they may choose to use say org.bar.s.t1, org.bar.s.t2
and org.bar.s.t3, respectively for t1, t2 & t3. Then, the client
needs to tell the client library that they wish to map the types
t1 to org.bar.s.t1, t2 to org.bar.s.t2 and t3 to org.bar.s.t3,
respectively. *That's* what you see in the client code.
Yes, the client type bindings look a lot like the server side
stuff. However, one cannot assume that its the same bindings
that are in place for the service author as well as for the
service client. The other point is that a deployment descriptor
file wouldn't exist for the client side stuff .. something
similar *could* exist but its not the same thing because only
some of the info (the type mappings) is relevant.
<plug>
If you use the WSDL toolkit all of this should be transparent
to the client of a service. There you basically point to the
WSDL file and it'll generate you a stub that you can use.
When there are complex types, it generates a default mapping
into Java types as well as serializers/deserializers to
go back and forth between the Java types and the abstract
types. IMO the proper usage for a service is to get its WSDL
description and then use something like the WSDL toolkit to
generate a client stub that hides a lot of low level stuff
(like SOAP and XML) from the service user.
You can get the WSDL toolkit from
http://www.alphaWorks.ibm.com/tech/wsdltoolkit.
</plug>
Sanjiva.
----- Original Message -----
From: <Je...@manulife.com>
To: <so...@xml.apache.org>
Sent: Thursday, October 19, 2000 8:16 AM
Subject: ServiceManager on the Client
> Has anyone studied the code for the AddressBook example? It seems that
> GetAddress spends an awful lot of time trying to set the paramsters for
> various SOAP objects. And All these paramters are documented in the
> DeploymentDescriptor file. Here, take a look yourself:
>
> SOAPMappingRegistry smr = new SOAPMappingRegistry();
> BeanSerializer beanSer = new BeanSerializer();
>
> // Map the types.
> smr.mapTypes(Constants.NS_URI_SOAP_ENC,
> new QName("urn:xml-soap-address-demo", "address"),
> Address.class, beanSer, beanSer);
> smr.mapTypes(Constants.NS_URI_SOAP_ENC,
> new QName("urn:xml-soap-address-demo", "phone"),
> PhoneNumber.class, beanSer, beanSer);
>
> ...
>
> call.setSOAPMappingRegistry(smr);
> call.setTargetObjectURI("urn:AddressFetcher");
> call.setMethodName("getAddressFromName");
> call.setEncodingStyleURI(encodingStyleURI);
>
> But the server (RPCROUTER) does not do this. It just calls the
servicemanager, and servicemanger has this infromation already.
>
> Shouldn't we have a CLIENT side servicemanger that can do this:
>
>
org.apache.soap.client.ServiceManager.configYourselfUsingDescriptorFile("Deplo
ymentDescriptor.xml");
> Vector params = new Vector();
>
> params.addElement(new Parameter("nameToLookup", String.class,
> nameToLookup, null));
> call.setParams(params);
> ...
>
>
> Jeff Saremi
> Manulife Financial
> 416.926.3000 x7005
> Fax: 416.926.5366
> Jeff_Saremi@manulife.com
>
Re: ServiceManager on the Client
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
I'm afraid this is a subtle issue.
Consider service s with operations o1 and o2 working on types t1, t2
and t3. Apache SOAP supports the authoring of services in Java
(and some scripting languages via BSF). Even for the BSF case,
the actual service invocation occurs via Java, so the baseline
is Java.
The description of the service would be by a WSDL file that has
(amongst other things):
<message name="m1">
<part type="t1"/>
</message>
<operation name="o1">
<input message="m1"/>
<output message="m2"/>
</operation>
(I'm using loose syntax.) The above tells a *user of the service*
all the relevant information about how to invoke the service. Now,
as the author of the service, you have chosen specific language
bindings for the various types t1, t2 and t3 in the implementation
language (Java, in this case), lets say com.foo.t1, com.foo.t2 and
com.foo.t3. The service author then would write a deployment
descriptor file which will tell the server runtime the relationship
between (abstract or schema) types t1, t2 and t3 and com.foo.t1,
com.foo.t2, and com.foo.t3, respectively, as well as the names of
the serializer/deserializer classes to go back and forth between the
abstract/schema type and the concrete Java type.
OK, that's the server (service-author) side. Now consider a user
of the service. That person takes the WSDL description of the
service and decides what types to bind the types t1, t2 and t3
to in their client language / platform. If the client were in
Java, they may choose to use say org.bar.s.t1, org.bar.s.t2
and org.bar.s.t3, respectively for t1, t2 & t3. Then, the client
needs to tell the client library that they wish to map the types
t1 to org.bar.s.t1, t2 to org.bar.s.t2 and t3 to org.bar.s.t3,
respectively. *That's* what you see in the client code.
Yes, the client type bindings look a lot like the server side
stuff. However, one cannot assume that its the same bindings
that are in place for the service author as well as for the
service client. The other point is that a deployment descriptor
file wouldn't exist for the client side stuff .. something
similar *could* exist but its not the same thing because only
some of the info (the type mappings) is relevant.
<plug>
If you use the WSDL toolkit all of this should be transparent
to the client of a service. There you basically point to the
WSDL file and it'll generate you a stub that you can use.
When there are complex types, it generates a default mapping
into Java types as well as serializers/deserializers to
go back and forth between the Java types and the abstract
types. IMO the proper usage for a service is to get its WSDL
description and then use something like the WSDL toolkit to
generate a client stub that hides a lot of low level stuff
(like SOAP and XML) from the service user.
You can get the WSDL toolkit from
http://www.alphaWorks.ibm.com/tech/wsdltoolkit.
</plug>
Sanjiva.
----- Original Message -----
From: <Je...@manulife.com>
To: <so...@xml.apache.org>
Sent: Thursday, October 19, 2000 8:16 AM
Subject: ServiceManager on the Client
> Has anyone studied the code for the AddressBook example? It seems that
> GetAddress spends an awful lot of time trying to set the paramsters for
> various SOAP objects. And All these paramters are documented in the
> DeploymentDescriptor file. Here, take a look yourself:
>
> SOAPMappingRegistry smr = new SOAPMappingRegistry();
> BeanSerializer beanSer = new BeanSerializer();
>
> // Map the types.
> smr.mapTypes(Constants.NS_URI_SOAP_ENC,
> new QName("urn:xml-soap-address-demo", "address"),
> Address.class, beanSer, beanSer);
> smr.mapTypes(Constants.NS_URI_SOAP_ENC,
> new QName("urn:xml-soap-address-demo", "phone"),
> PhoneNumber.class, beanSer, beanSer);
>
> ...
>
> call.setSOAPMappingRegistry(smr);
> call.setTargetObjectURI("urn:AddressFetcher");
> call.setMethodName("getAddressFromName");
> call.setEncodingStyleURI(encodingStyleURI);
>
> But the server (RPCROUTER) does not do this. It just calls the
servicemanager, and servicemanger has this infromation already.
>
> Shouldn't we have a CLIENT side servicemanger that can do this:
>
>
org.apache.soap.client.ServiceManager.configYourselfUsingDescriptorFile("Deplo
ymentDescriptor.xml");
> Vector params = new Vector();
>
> params.addElement(new Parameter("nameToLookup", String.class,
> nameToLookup, null));
> call.setParams(params);
> ...
>
>
> Jeff Saremi
> Manulife Financial
> 416.926.3000 x7005
> Fax: 416.926.5366
> Jeff_Saremi@manulife.com
>