[kepler-dev] RE: type conversion for the web services actor

Mon Feb 9 23:58:31 PST 2004

just my $.02 below

>>>>> "IA" == Ilkay Altintas <altintas at sdsc.edu> writes:
IA> I have looked at the code below a little bit.
IA> Looks like it is close to what I had in mind for the xsd base types.
IA> Handling the user-defined types will be more complex as you said.
IA> I don't know how to do it yet but there must be a standard way of doing it.
IA> 
IA> We need to generate our own services to test the new features as all the web
IA> services I know have string as datatypes.

that is telling! So you say that all existing web services from
xmethods etc that you've worked with accept and return plain "string"
types? 

That explains why it wasn't a priority to have full XSD support. 

Matt: I have also a question for you. Assume you have a web service
that inputs or outputs a complex, user-defined XML type, say sth like
 person = (name, ssn, address)
 address = (street, city , ..)
Obviously this is serialized into an XML string and thus will need to
be parsed on the receiving side, right?

So we will get an advantage of recognizing whether two connected ports 
are XML type compatible, but we won't gain any performance if they
actually are!?

I buy into the importance of good/strict typing, but it's full
potential will only be realized with semantic types to mediate between
structurally incompatible types.

IA> I don't think the client needs to know about how the web service is
IA> deployed. At least that was my conclusion when I looked into it the first
IA> time.

as for the RPC vs wrapped vs document etc: I guess RPC is a good
starting point. We also need to look what people are using. 

Whenever we can, we should hide complexities from the user.

RPC was there from the beginning of internet time (for me: the
80ies). So I guess it's meant to stay ;-)

Bertram

IA> 
IA> I will send another email on the design for discussion when I start working
IA> on this in more detail this week.
IA> 
IA> Best,
IA> Ilkay
IA> 
IA> 
IA> 
IA> -----Original Message-----
IA> From: Matt Jones [mailto:jones at nceas.ucsb.edu]
IA> Sent: Monday, February 09, 2004 5:43 PM
IA> To: Ilkay Altintas
IA> Cc: kepler-dev at ecoinformatics.org
IA> Subject: type conversion for the web services actor
IA> 
IA> 
IA> Hi Ilkay,
IA> 
IA> I started looking into the changes needed to make the web services actor
IA> support non-string data types.  Here's a diff (below) showing my changes
IA> to start to get this to work (against WebServiceInterface.java, which I
IA> later learned is out-of-date code still hanging around in CVS -- sorry).
IA> 
IA> The atomic types (e.g., xsd:int) will be pretty easy to map and cast,
IA> but the more complex types (e.g., arrays such as xsd:string[] and
IA> user-defined object types) will be more complex because the WSDL has to
IA> be parsed for complexType defs that can be fairly arbitrary.
IA> Nevertheless, I think both are tractable.
IA> 
IA> The code diff below sets the right Ptolemy type on the actor, but I
IA> didn't get to the part where input and output values are propoerly
IA> casted when the data is being emitted on the port.  That was going to be
IA> more confusing.
IA> 
IA> Also, it seemed like your current code used a single return value port
IA> rather than setting up the response message output ports.  So I was
IA> confused about the correct usage of Call.getResponseMessage(),
IA> Call.getOutputParams(), Call.getOutputValues(), and
IA> Call.getReturnType().  What's your view of the appropriate mapping of
IA> the WSDL requestMessage, responseMessage, and returnMessage to Ptolemy
IA> ports?  I felt like there were multiple options here and wasn't sure how
IA> to proceed.
IA> 
IA> Finally, web services can be deployed using several different SOAP
IA> message parsing schemes.   Axis defines these as "RPC", "Document",
IA> "Wrapped", and "Message" (see
IA> http://ws.apache.org/axis/java/user-guide.html).  Each has a different
IA> way of interpreting the SOAP body.  Do you think this needs to be
IA> exposed through Kepler's WS interface, or can we treat them all
IA> uniformly? That is, does the client care at all how the service is deployed?
IA> 
IA> I'd like to continue discussing this design with you, so let me know as
IA> you start to work on this.  Cheers,
IA> 
IA> Matt
IA> 
IA> 
IA> Index: src/org/sdm/spa/WebServiceInterface.java
IA> ===================================================================
IA> RCS file: /cvs/kepler/src/org/sdm/spa/Attic/WebServiceInterface.java,v
IA> retrieving revision 1.21
IA> diff -r1.21 WebServiceInterface.java
IA> 40a41
>> import ptolemy.data.type.ArrayType;
IA> 484d484
IA> <
IA> 503a504,526
>> // Get a hash of all of the array type definitions
>> Hashtable arrayTypes = new Hashtable();
>> //xPath =
IA> "//wsdl:types/schema/complexType/complexContent/restriction/attribute[@ref=\
IA> "soapenc:arrayType\"]";
>> xPath = "//types/schema/complexType";
>> System.out.println("Searching for: " + xPath);
>> contextNode = doc.getDocumentElement();
>> i = XPathAPI.selectNodeIterator(contextNode, xPath);
>> // For each node
>> while ( (node = i.nextNode()) != null) {
>> String arrayName = ( (Element) node).getAttribute("name");
>> System.out.println("Processing a complexType element: "
IA> + arrayName);
>> //xPath =
IA> "//complexContent/restriction/attribute[@ref=\"soapenc:arrayType\"]";
>> xPath = "//complexContent/restriction/attribute";
>> NodeIterator typeIterator =
IA> XPathAPI.selectNodeIterator(node, xPath);
>> Node subnode = typeIterator.nextNode();
>> if (subnode != null) {
>> System.out.println("Processing subnode...");
>> String arrayType = ( (Element)
IA> subnode).getAttribute("wsdl:arrayType");
>> System.out.println("Found array type: " + arrayName
IA> + " (" + arrayType + ")");
>> arrayTypes.put(arrayName, arrayType);
>> }
>> }
>> 
IA> 526a550
>> System.out.println("Input port: " + partName + " [" +
IA> typeStr + "]");
IA> 529c553
IA> <               pin.setTypeEquals(BaseType.STRING);
IA> ---
>> setPortType(arrayTypes, pin, typeStr);
IA> 542a567
>> System.out.println("Output port: " + partName + " [" +
IA> typeStr + "]");
IA> 545c570
IA> <               pout.setTypeEquals(BaseType.STRING);
IA> ---
>> setPortType(arrayTypes, pout, typeStr);
IA> 601a627,654
>> /**
>> * Set the type of a port based on a string representation of that type
>> * that was extracted from the WSDL description.
>> *
>> * @param arrayTypes a hash of defined array types by name
>> * @param port the port whose type is to be set
>> * @param typeStr the string representation of the type to be set
>> */
>> private void setPortType(Hashtable arrayTypes, TypedIOPort port,
IA> String typeStr) {
>> if (typeStr.equals("xsd:int")) {
>> port.setTypeEquals(BaseType.INT);
>> } else if (typeStr.equals("xsd:long")) {
>> port.setTypeEquals(BaseType.LONG);
>> } else if (typeStr.equals("xsd:double")) {
>> port.setTypeEquals(BaseType.DOUBLE);
>> } else if (typeStr.equals("xsd:string")) {
>> port.setTypeEquals(BaseType.STRING);
>> } else if (typeStr.startsWith("impl:")) {
>> String match = typeStr.substring(5);
>> String matchedType = (String)arrayTypes.get(match);
>> System.out.println("Setting type to: " + matchedType);
>> // FIXME: need to actually set the type to the right
IA> array type!
>> port.setTypeEquals(new ArrayType(BaseType.STRING));
>> } else {
>> port.setTypeEquals(BaseType.STRING);
>> }
>> }
>> 
IA> 
IA> 
IA> _______________________________________________
IA> kepler-dev mailing list
IA> kepler-dev at ecoinformatics.org
IA> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev