Bryan,
#1 ok, ##other is fine
#2
I'm not worried about the software that we write, but if WSDM 0.5 cannot be
implemented or used using existing tools, then that is the problem. And I do
not consider assembling SOAP message manually as an XML document as "using
tools". So, if there is a WSDM 0.5-enabled manageable WS somewhere, without
fixing #2, noone having VS.NET as their development environment will be able
to build make use of that WS unless they hand code SOAP messages and discard
WSDL. That is not reasonable.
There are lot of things that one could to with the schema and I don't
know which is right. I don't think anyone has the authority to say whoch is
right, but we can tell which is interoperable and which is not right now.
So,
<manyQnames>a:A b:B</manyQnames>
and
<manyQnames>a:A</manyQnames><manyQnames>b:B</manyQnames>
and
<manyQNames><qname>a:A</qname><qname>b:B</qname></manyQNames>
are essentially equivalent, the later is simpler to
serialize.
#3
[schemaLocation attribute with just the file name - make it only
WS-ResourceProperties.xsd. With this change it should
work.]
No
it will not work. You'd get
I
know it is porobably bug in .NET, but I'd like people using VS.NET to be
able to add a Web reference to the manageability service just like they add
a Web reference to any other service.
So, one way to solve this is to inline the whole WSRP schema directly
in WSDL (which is what I did and it works), or, which is more appropriate
define schema in one namespace and WSDL in another and then import schema
namespace in WSDL. That also works.
-- Igor Sedukhin
.. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
Igor,
My
approach would be to make minor changes to the WS-RP WSDL and schema to make
it work as it appears to be intended by the specification. In order to do
this we temporarily need to have our own copies of the WS-RP files. For .NET
the WSDL tool used should be from the WSE 2.0 toolkit (wsewsdl) rather than
the one shipped with the .NET Framework - there are several bug fixes in it.
For the specific problems you discovered I propose the following
solutions:
#1: I agree with you that the current WSDL does not reflect the
intent of the specification as shown in the example SOAP messages. Your
suggested change should be incorporated into the WSDL except that
namespace="##other" should be added to the any element.
#2: I think the WSDL here is correct and any implementation complying
to this WSDL should interoperate just fine. Clearly it is the intent of the
spec to have a list of QNames as an argument to GetMultiple... So, rather
than changing the operation here, I would suggest that for platforms that do
not support the list construct in schema, that they code around it. This
means that argument would be interpreted as a string by the code and split
into a list internally. This will still interoperate on the message level
with platforms that do support the list construct. I suggest no change
here.
#3: This seems to be a bug in the .NET WSDL tool (including wsewsdl).
Since we temporarily need our own copies of the WSDL and schema files, we
can work around this problem by replacing the value of the schemaLocation
attribute with just the file name - make it only WS-ResourceProperties.xsd.
With this change it should work. I am not sure what the right answer is when
WS-RP files have been fixed and have a final home. The same change is OK in
final files as long as the WSDL and schema files are located in the same
directory. The right answer is to get Microsoft to fix the
tool.
Bryan
I have spent some time trying
to see if the subj. could be implemented and it provides to be quite a
challenge. Here are my findings that I wanted to share with the group and
see if anyone else tried it with a better outcome.
#1
I'm not sure that the following is
right
[<xsd:element name="GetResourcePropertyResponse" type="xsd:anyType"/>]
This definition requires SOAP
serializer to include xsi:type *of the element itself*. This definition
contradicts what the specifications says. What the spec says it should be
[<GetResourcePropertyResponse><abc:property>value</abc:property></GetResourcePropertyResponse>]
According to the above element
declaration, it will *always* be serialized as
[<GetResourcePropertyResponse
xsi:type="whateverAbcPropertyType">value</GetResourcePropertyResponse>]
The response element should be
declared as a container.
[
<xsd:element name="GetResourcePropertyResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:any minOccurs="0" maxOccurs="1"
/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
]
#2
The following does not appear to be
interoperable at all.
[
<xsd:element name="GetMultipleResourcePropertiesRequest">
<xsd:simpleType>
<xsd:list itemType="xsd:QName" />
</xsd:simpleType>
</xsd:element>
]
The simple type list
definition is merely ignored and looks like this [System.Xml.XmlQualifiedName
GetMultipleResourcePropertiesRequest] in
the code.
We can, of course, wait until
it is fixed by Microsoft, but I don't think we can, and so
WS-ResourceProperties must be fixed. Following is one
possibility.
[
<xsd:element name="GetMultipleResourcePropertiesRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="qname" type="xsd:QName" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
]
#3
[
<wsdl:types>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace=
"http://www.ibm.com/xmlns/stdwip/web-services/WS-ResourceProperties">
<xsd:include schemaLocation=
"http://www-106.ibm.com/developerworks/webservices/library/ws-resource/WS-ResourceProperties.xsd"
/>
]
Tools think that two
definitions of the same namespace exist. Both this schema and the included
schema define the same namespace.
Inlining schema in the WSDL of
WS-ResourceProperties helps resolve this. Another approach is to
xsd:import and introduce dummy namespace in WSDL types
section.
-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788