Hi, Chris.
Please see my comments in line.
Thanks,
Raymond
----- Original Message -----
From: "Chris Wall" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, August 29, 2006 3:00 PM
Subject: Re: How to invoke a web service with complex types? Java object /
SDO conversion?
Hi Raymond.
In our case, the client is privy to the domain objects - Java objects
(interfaces/classes) - used by the web service. For example, locally the
client uses org.client.Patient throughout the application. Before
invoking
a web service the client converts org.client.Patient to
org.service.Patient(provided by service provider), and then invokes
the web service passing
org.service.Patient.
I assume either the org.service.Patient is generated from WSDL2Java or a
custom serializer/deserializer is provided to deal with the XML
marshaling/unmarshaling.
Migrating this code to Tuscany we're finding that SDO handles the outbound
by converting the Patient object to a String (I think). The inbound
doesn't
convert at all, but instead sends back null.
I think we only support Java primitive types and SDO types at this moment.
It would be cool if the binding layer was able to dynamically convert a
Java
object to a schema type matching the package name and class name in the
WSDL. This is the ultimate non-invasive approach.
We're doing that today for SDO types (matching by the QName of the XSD
types). Really, the java/xml binding frameworks provide such capabilties. As
I mentioned before, we're working on a solution to support pluggable
databindings and transformers can be contributed to Tuscany to deal with
data transformations on demand.
It sounds as if the WS binding layer for both Axis2 and Celtix support
only
SDO as of today.
That was a staging hack before the full-blown databinding story is in place.
If this is true, what are the steps to communicate with a
complex type web service? My guess is:
1.) Generate SDO objects from WSDL using tuscany-sdo-plugin.
You can choose to use statically pre-generated SDO classes or dynamic
DataObject reflection APIs.
2.) Create a service component (@Service) that matches the web service's
method signatures.
3.) In the application scdl, import the WSDL into SDO
(<import.sdolocation="..."/>). Although, I'm not sure exactly what
this does.
It asks the SDO model to be loaded for WSDL/XSD or pre-generated SDO
classes. With the metadata, we can resolve the XML/Java type mapping by XML
QNames.
4.) In the application scdl, configure the service component with the
binding.ws.
5.) Within the client application, convert local Java objects to SDO
object
using the Factory created in #1.
Again, ideally, you can plugin a new databinding for your private java
objects and contribute transformers to convert it to AXIOM (or going through
intermediate databindings) and vice versa.
6.) Within the client application, locate the service via Tuscany context
and invoke web service proxy method passing in the SDO object.
How does that sound?
-Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
