wsdm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsdm] WS-ResourceProperties and .NET implementations
- From: "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
- To: "MURRAY,BRYAN \(HP-Seattle,ex1\)" <bryan.murray@hp.com>,<wsdm@lists.oasis-open.org>
- Date: Mon, 1 Mar 2004 15:12:33 -0500
Title: Message
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]