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