04029437
m1.33
The fact that
faultcode
,
faultstring
,
faultactor
, and
detail
elements in the
above example do not have a namespace qualifier does not indicate that they are
not part of the
soapenv
namespace. This is because the parent
Fault
elements is
fully qualified and, unlike the
Body
element, we know what child-elements to
expect in the
Fault
element.
The current SOAP schema defines much the same semantics, but it uses different
elements [Gud+07]. This schema describes five elements,
Code
,
Reason
,
Node
,
Role
, and
Detail
.
Code
and
Reason
are essentially the same as the
faultcode
and
faultstring
elements.
However instead of inserting the data directly they employ the additional child-
elements
Value
and
Subcode
to hold the data. Note that
Subcode
has its own
Value
child-
element and
Subcode
is optional.
Node
, and
Detail
are essentially the same as the
faultactor
, and
detail
elements.
Role
is
used to identify the role the node identified in
Node
was playing. The table below, taken
from W3C [Gud+07] describes the values the
Role
can be (no other values can be used):
Short-name
Description
next
Each SOAP intermediary and the ultimate SOAP receiver MUST act in this
role.
none
SOAP nodes MUST NOT act in this role.
ultimateReceiver
The ultimate receiver MUST act in this role.
2.6.3 WSDL and UDDI
WSDL (Web Service Description Language) documents are XML files that describe ways
in which a client and server can interact with a given Web-Service [CCMW01]. WSDL is
often associated with SOAP because there has been wide adoption of WSDL in the
SOAP community. It is now unusual to come across SOAP Web-Services without WSDL
[New02].
WSDL is not restricted to describing SOAP Web-Services.
In many respects one can liken a WSDL file with a
BeanInfo
class in Java. WSDL and
SOAP rely on the same encoding, in the same way that a
Bean
and
BeanInfo
are
represented as Java classes. WSDL files and
BeanInfo
classes provide metadata about
specific resources. And, by association, WSDL therefore provides clients with a form of
introspection.
Returning to the example in section 2.6.2 we can examine the WSDL file associated with
the Microsoft Live Search Web-Service. Of most interest are the
portType
elements, these
describe the various procedures that we can remotely execute and the input and output
data associated with them. The code below is a snippet taken from the WSDL file (the
locations of the schemas have been replaced with
uri
, to make it easier to read) [MS05]:
Code Sample 29
<wsdl:portType name="MSNSearchPortType">
<wsdl:operation name="Search">
<wsdl:input message="tns:SearchMessage" wsa:Action="uri" />
<wsdl:output message="tns:SearchResponseMessage" wsa:Action="uri" />
