Hi there,
We're having an internal debate about whether the element name in a WSDL
is
part of the interface contract, or whether the root element name of the
inbound message can be named anything provided the complex type is the
same.
This question came about because we've published a WSDL that is used to
define both "Request" and "Response" messages for our orchestration.
However
we're only exposing a SOAP receive location using the BizTalk Web
Publi****ng
Wizard for the inbound "Request" messages, and require our consuming
clients
service to use the "Response" message types defined in our WSDL to expose
a
service to which we can post our response asynchronously. (FYI We can't
use
synchronous request-response semantics because the orchestration is
long-running, and we have to use SOAP as the trans****t).
Further, our public XSD schemas (and thus the generated WSDL) uses
lowerCamelCase for root-node element names (e.g. "requestMessage") and
UpperCamelCase for all complex types (e.g. "RequestMessage").
<s:element name="CommitRequest">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="requestMessage"
type="tns:RequestMessage" />
</s:sequence>
</s:complexType>
</s:element>
But when the client's development team add a web reference based on our
WSDL, then use those types to expose a service for us to post our
responses
to, the root element names (i.e. the message names) in their derived WSDL
all
become UpperCamelCased, and thus different to our lowerCamelCased element
names in the original XSD. This occurs because the web reference tool
generates local copies of the XSD's based on the complex type of the
element
in the original WSDL (which are UpperCamelCase), despite the actual
original
element name being lowerCamelCased.
Phew, still with me?
So we want to dictate to the consuming client that they "must" expose a
response service for us to consume with lowerCamelCased root element names
as
per the WSDL. Which means they need to deal with the way the Visual
Studio
2005 "Add Web Reference" process consumes our WSDL, because it is
"breaking
the contract" by changing the case of the element name. But there is
disagreement about whether we can demand that as part of the interface
contract, because it has been suggested that the actual root element name
does not form part of the contract thus we have no right to dictate both
the
message element name and the complex type.
Hence the original question, whether the element name in a WSDL is "part
of
the interface contract" and thus "must" be enforced in the message. Or
can
the root element name of the inbound message be any named anything and we
need to deal with different element names arriving at our service
Thanks in advance for any assistance.
Dean
|
