Strangely enough, the JSDL doesn't have problems. And, as a matter of fact, the same pattern shows up in the result types and those are OK as well. It only occurs for the client sending outgoing requests. I'm not sure what the difference would be though since the same tooling generates both the client stubs and the server side skeleton. Interestingly enough, I would expect your own clients to exhibit this behavior as well unless you have replaced or manually edited the Axis WSDL2Java tooling (forgive me if I'm making a stupid assumption, but I am under the impression that Globus is based off of the same version of Axis that I use). At anyrate, if this problem does turn out to be the tooling in Axis, not only would I be OK with the changes making it back into the BES group, but I would sincerely hope that the whole point of this excersize is to provide useful feedback to that group about issues like this. After all, the goal of OGSA, OGF, and the BES and HPC working groups is to promote interoperability and to maximize everyone's chances at equally interoperating with each other. To my way of thinking, this explicitly means that if two pieces of WSDL describe the same exact wire format, but one works with a larger set of tooling, then despite the correctness of the other, we as an open standards organization have an obligation to use the format that works for everyone, even the broken tooling sets. -Mark On Fri, Oct 20, 2006 at 04:41:55PM -0600, Peter G. Lane wrote:
Doesn't JSDL cause problems for your tooling as well? Element refs are a very common XMLSchema feature. JSDL uses quite a number of them. What about the HPCProfileApplication schema? I'm wondering whether changing the BES schema would actually help that much. I'm also worried that changing the demo copy of the schema for broken tooling would cause those changes to get propagated to the normative BES schema. My personal preference is that you change it locally rather than forcing us to endorse the change.
Peter
Mark Morgan wrote:
OK -- I thought as much. So, my tooling is bad -- can we change the WSDL anyway since the change shouldn't only be duplicate information for other peoples tooling (the goal is to be maximally interoperable right?). Ofcourse, I have to change the WSDL one way or the other, would just like to use the same WSDL everyone else is using.
-Mark
-----Original Message----- From: Peter G. Lane [mailto:lane@mcs.anl.gov] Sent: Friday, October 20, 2006 5:04 PM To: Mark Morgan Cc: ogsa-hpcp-wg@ggf.org Subject: Re: [ogsa-hpcp-wg] Another Problem (maybe?) in the WSDL
From the XMLSchema spec (http://www.w3.org/TR/xmlschema11-1/#cElement_Declarations):
"The (top-level) element declaration .resolved. to by the .actual value. of the ref [attribute]."
This means essentially that the global element declaration will be substituted for the element reference. In other words, the name must be "ActivityIdentifier" in the bes-factory namespace. If your tooling isn't doing this then it's non-compliant.
Peter
In trying to interop with Glenn's endpoint, I have found another potential problem with the BES-Factory's WSDL. However,
is at a level of WSDL that is slightly beyond my experience. In particular, the problem is with two message types; the GetActivityDocuments message type, and the TerminateActivitiesType message. Both problems are identical. In brief, here are three elements from the WSDL (the first of which is an example of a type declaration which works for me, and the latter two being
<xsd:complexType name="GetActivityStatusesType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" type="wsa:EndpointReferenceType" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="GetActivityDocumentsType"> <xsd:sequence> <xsd:element ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="TerminateActivitiesType"> <xsd:sequence> <xsd:element ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
The first one works for me, and the last two do not. The
Mark Morgan wrote: the problem the problem declarations). problem with
the second and third ones is that my tooling doesn't know what name to give the element for the EPRs inside of the message elements.. In otherwords, it generates messages which look like the following:
<GetActivityDocuments xmlns="http://schemas.ggf.org/bes/2006/08/bes-factory"> <item xmlns="" xmlns:ns3="http://www.w3.org/2005/08/addressing" xsi:type="ns3:EndpointReferenceType">
<ns3:Address>https://wincluster1.cs.virginia.edu/HPCP/HPCPServ ice.asmx</ns3:
Address> <ns3:ReferenceParameters> <jobID xmlns="http://schemas.ggf.org/hpcp/2006/07/hpcp-app">113</jobID> </ns3:ReferenceParameters> </item> </GetActivityDocuments>
<TerminateActivities xmlns="http://schemas.ggf.org/bes/2006/08/bes-factory"> <item xmlns="" xmlns:ns3="http://www.w3.org/2005/08/addressing" xsi:type="ns3:EndpointReferenceType">
<ns3:Address>https://wincluster1.cs.virginia.edu/HPCP/HPCPServ ice.asmx</ns3:
Address> <ns3:ReferenceParameters> <jobID xmlns="http://schemas.ggf.org/hpcp/2006/07/hpcp-app">113</jobID> </ns3:ReferenceParameters> </item> </TerminateActivities>
Notice the child element called "item" in each message.
The simple (and obvious to me) fix was to change the GetActivityDocuemntsType and TerminateActivitiesType type definitions to specify the name of the inner element, i.e. to change them to:
<xsd:complexType name="GetActivityDocumentsType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="TerminateActivitiesType"> <xsd:sequence> <xsd:element name="ActivityIdentifier" ref="bes-factory:ActivityIdentifier" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
I know that these are legitimate fixs, the questions are, A) are these in fact real errors that my tooling is finding and thus the WSDL is in error, and B) can we make these changes permanent in the BES-Factory WSDL to fix these problem?
-Mark
-- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.cs.virginia.edu mmm2a@virginia.edu (434) 982-2047
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg