[ogsa-hpcp-wg] Another Problem (maybe?) in the WSDL
Peter G. Lane
lane at mcs.anl.gov
Fri Oct 20 21:48:01 CDT 2006
Mark M. Morgan wrote:
> 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).
We're using Axis version 1.5 and it seems to work fine:
<GetActivityDocuments xmlns="http://schemas.globus.org/gram/2006/05/job/factory">
<ActivityIdentifier xsi:type="wsa:EndpointReferenceType">
<wsa:Address>https://192.168.0.101:8443/wsrf/services/ManagedExecutableJobService</wsa:Address>
<wsa:ReferenceProperties>
<ns1:ResourceID
xmlns:ns1="http://www.globus.org/namespaces/2004/10/gram/job">2e3ee6f0-60ab-11db-bc36-acbb2a153f40</ns1:ResourceID>
</wsa:ReferenceProperties>
<wsa:ReferenceParameters/>
</ActivityIdentifier>
</GetActivityDocuments>
> 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.
While I understand what you're saying, I also think this can be a slippery slope. Admittedly the
change you're asking for is quite minor, but my stubbornness kicks in when I think of it like this:
how do we attain interoperability without making everybody implement N different variations of the
specs we use? If we let people be non-conformant and even bend over backwards when they are
non-conformant, we're putting the burden on everybody to accomodate all non-conformant variations
that may pop up. That's no way to operate in my mind. You should define the dimensions of your
widget and then mass produce it. Slight variations may occur within tolerances, but element refs to
me isn't within tolerances. They're pretty fundamental IMHO.
Anyway, I'm off my soap (no pun intended) box. Since the change is rather benign, I'm not going to
get in a tiff if others agree this is worth doing. But if you want to switch to a working Axis
version, you're welcome to use the Globus Toolkit! ;-)
Peter
> -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 at mcs.anl.gov]
>>>> Sent: Friday, October 20, 2006 5:04 PM
>>>> To: Mark Morgan
>>>> Cc: ogsa-hpcp-wg at 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
>>>>
>>>> Mark Morgan wrote:
>>>>> In trying to interop with Glenn's endpoint, I have found another
>>>>> potential problem with the BES-Factory's WSDL. However,
>>>> the problem
>>>>> 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
>>>> the problem declarations).
>>>>> <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
>>>> 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 at virginia.edu
>>>>> (434) 982-2047
>>>>>
>>>>> --
>>>>> ogsa-hpcp-wg mailing list
>>>>> ogsa-hpcp-wg at ogf.org
>>>>> http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
>>>>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3804 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/ogsa-hpcp-wg/attachments/20061020/0ede6878/attachment-0001.bin
More information about the ogsa-hpcp-wg
mailing list