[kepler-dev] Re: type conversion for the web services actor
Matt Jones
jones at nceas.ucsb.edu
Wed Mar 3 14:41:17 PST 2004
Chad,
Some package imports and associated class files for grass couldn't be found
when I tried to compile WebService.java.
It seemed like a hack to me, and I thought you
might have just accidentally committed it while you were testing. But now
that I've checked out the source again, I'm not seeing those issues. Sooo...
for now I don't know if its a problem or not. I'll let you know if it
crops up again.
Matt
On Wed, 3 Mar 2004, Chad Berkley wrote:
> 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);
> >> > }
> >> > }
> >> >
> >>
> >
>
>
--
******************************************************************
Matt Jones jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/ Fax: 425-920-2439 Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
******************************************************************
More information about the Kepler-dev
mailing list