[kepler-dev] Re: type conversion for the web services actor
Chad Berkley
berkley at nceas.ucsb.edu
Wed Mar 3 13:59:05 PST 2004
what was the compile problem? is it something i need to fix?
chad
Matt Jones wrote:
> Hi Ilkay,
>
> Thanks. I tried to check out the new version yesterday, but ran into
> some compile problems related to Chad's checkins for the grass web
> services. I'll look again soon.
>
> Matt
>
> Ilkay Altintas wrote:
>
>> Hi Matt,
>>
>> I have checked in a version of web service actor which works for the
>> basic
>> XSD types.
>> Even for the basic types, there are problems to convert it into the
>> Ptolemy
>> type system.
>> For example, there is no float, date, and short in the PTII type
>> hierarchy.
>> (Correct me if I'm wrong here.)
>> But this should be easy to solve.
>>
>> The next thing I want to explore is the how to send/recieve blobs + web
>> service specific object types. How can we encode them, etc.
>>
>> I'm following:
>> http://www-106.ibm.com/developerworks/webservices/library/ws-soapmap1/
>> as a reference document in Apache->Soap type mapping.
>>
>> A design decision to make is: do we really want to support special object
>> types? This means tightly coupling two web services (which is how people
>> compose home-cooked web services in general). Instead of that, we can
>> create
>> and support web services with output messages contining more than one
>> part.
>> (One example is the output message of the ZipCodes operation at
>> http://webservices.instantlogic.com/zipcodes.ils?wsdl) I'm still
>> trying to
>> find out how to create generic clients for this kind of web services...
>>
>> Another important design decision is how we can make this actor "domain"
>> polymorphic. When exactly should we consume the tokens for it to work in
>> each domain, and how should it behave if there is a failure in getting
>> some
>> of the inputs. Also, should it try to execute again if there is a
>> communication problem with the soap server...
>>
>> I'm looking forward to discussing some of these issues with you and all.
>> There are a lot more things I believe... :)
>>
>> Thanks,
>> Ilkay
>>
>>
>>
>> -----Original Message-----
>> From: Matt Jones [mailto:jones at nceas.ucsb.edu]
>> Sent: Monday, February 09, 2004 5:43 PM
>> To: Ilkay Altintas
>> Cc: kepler-dev at ecoinformatics.org
>> Subject: type conversion for the web services actor
>>
>>
>> Hi Ilkay,
>>
>> I started looking into the changes needed to make the web services actor
>> support non-string data types. Here's a diff (below) showing my changes
>> to start to get this to work (against WebServiceInterface.java, which I
>> later learned is out-of-date code still hanging around in CVS -- sorry).
>>
>> The atomic types (e.g., xsd:int) will be pretty easy to map and cast,
>> but the more complex types (e.g., arrays such as xsd:string[] and
>> user-defined object types) will be more complex because the WSDL has to
>> be parsed for complexType defs that can be fairly arbitrary.
>> Nevertheless, I think both are tractable.
>>
>> The code diff below sets the right Ptolemy type on the actor, but I
>> didn't get to the part where input and output values are propoerly
>> casted when the data is being emitted on the port. That was going to be
>> more confusing.
>>
>> Also, it seemed like your current code used a single return value port
>> rather than setting up the response message output ports. So I was
>> confused about the correct usage of Call.getResponseMessage(),
>> Call.getOutputParams(), Call.getOutputValues(), and
>> Call.getReturnType(). What's your view of the appropriate mapping of
>> the WSDL requestMessage, responseMessage, and returnMessage to Ptolemy
>> ports? I felt like there were multiple options here and wasn't sure how
>> to proceed.
>>
>> Finally, web services can be deployed using several different SOAP
>> message parsing schemes. Axis defines these as "RPC", "Document",
>> "Wrapped", and "Message" (see
>> http://ws.apache.org/axis/java/user-guide.html). Each has a different
>> way of interpreting the SOAP body. Do you think this needs to be
>> exposed through Kepler's WS interface, or can we treat them all
>> uniformly? That is, does the client care at all how the service is
>> deployed?
>>
>> I'd like to continue discussing this design with you, so let me know as
>> you start to work on this. Cheers,
>>
>> Matt
>>
>>
>> Index: src/org/sdm/spa/WebServiceInterface.java
>> ===================================================================
>> RCS file: /cvs/kepler/src/org/sdm/spa/Attic/WebServiceInterface.java,v
>> retrieving revision 1.21
>> diff -r1.21 WebServiceInterface.java
>> 40a41
>> > import ptolemy.data.type.ArrayType;
>> 484d484
>> <
>> 503a504,526
>> > // Get a hash of all of the array type definitions
>> > Hashtable arrayTypes = new Hashtable();
>> > //xPath =
>> "//wsdl:types/schema/complexType/complexContent/restriction/attribute[@ref=\
>>
>> "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: "
>> + arrayName);
>> > //xPath =
>> "//complexContent/restriction/attribute[@ref=\"soapenc:arrayType\"]";
>> > xPath = "//complexContent/restriction/attribute";
>> > NodeIterator typeIterator =
>> XPathAPI.selectNodeIterator(node, xPath);
>> > Node subnode = typeIterator.nextNode();
>> > if (subnode != null) {
>> > System.out.println("Processing subnode...");
>> > String arrayType = ( (Element)
>> subnode).getAttribute("wsdl:arrayType");
>> > System.out.println("Found array type: " + arrayName
>> + " (" + arrayType + ")");
>> > arrayTypes.put(arrayName, arrayType);
>> > }
>> > }
>> >
>> 526a550
>> > System.out.println("Input port: " + partName + " [" +
>> typeStr + "]");
>> 529c553
>> < pin.setTypeEquals(BaseType.STRING);
>> ---
>> > setPortType(arrayTypes, pin, typeStr);
>> 542a567
>> > System.out.println("Output port: " + partName + " [" +
>> typeStr + "]");
>> 545c570
>> < pout.setTypeEquals(BaseType.STRING);
>> ---
>> > setPortType(arrayTypes, pout, typeStr);
>> 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,
>> 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
>> array type!
>> > port.setTypeEquals(new ArrayType(BaseType.STRING));
>> > } else {
>> > port.setTypeEquals(BaseType.STRING);
>> > }
>> > }
>> >
>>
>
More information about the Kepler-dev
mailing list