WS Notes

http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jst.ws.axis2.ui.doc.
user%2Ftopics
%2Ftaxis2td.html
http://www.ibm.com/developerworks/webservices/tutorials/ws-jax/section4.html
http://www.mkyong.com/webservices/jax-ws/deploy-jax-ws-web-services-on-tomcat/
http://docs.oracle.com/cd/E17802_01/webservices/webservices/docs/2.0/jaxws/wsgen.html
http://jax-ws.java.net/nonav/2.1.4/docs/index.html
http://java.dzone.com/articles/creating-and-deploying-jax-ws
http://www.ibm.com/developerworks/webservices/library/ws-apacheaxis/section2.html
http://axis.apache.org/axis2/java/core/docs/userguide-buildingservices.html#deploypojo
http://www.webservicesarchitect.com/content/articles/samtani01.asp
http://www.ibm.com/developerworks/ibm/library/i-mexch8/index.html
http://www.coderanch.com/t/220493/Web-Services/java/webservices-vs-CORBA
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
jaxb-impl-2.1.4
jaxb-xjc-2.1.4
jaxws-rt-2.1.4
jaxws-tools-2.1.4
stax-ex-1.2
streambuffer-0.8
http://www.coderanch.com/t/501314/Web-Services/java/Simple-Unwrapped-Wrapped-SOAP-
messages
http://www.khanna111.com/articles/SOAP_Styles_Differences.html
http://www.servicetechspecs.com/ws-businessactivity
An introduction to SOAP
1. SOAP message structure

SOAP is a simple, flexible XML-based protocol that provides a standard way to carry out
platform-independent distributed computing.
The SOAP specification is the most widely accepted open standard at the messaging layer.
Note
Formerly, SOAP was an acronym for Simple Object Access Protocol, but the original name was
misleading because SOAP is not object-based. Because of this, SOAP is now used as a name in its
own right, and is not an abbreviation.
The SOAP specification is the work of the W3C and is currently at version 1.2.
SOAP 1.2 has been written in terms of the XML infoset - an abstract model of all of the
information contained within an XML document or fragment.
SOAP defines a messaging framework for passing SOAP messages between web services.
SOAP messages are XML documents that encapsulate the information that needs to be
transmitted between web services.
The principal features of the SOAP specification include
 a message structure
 a mechanism for data representation
 an RPC mechanism
 a processing model
 a protocol-binding framework
 extensibility mechanisms
 an error-handling mechanism
a message structure
The SOAP message is the basic unit of communication in SOAP-based web services. The data in
the communication is enclosed in a SOAP envelope that can have a body and one or more
optional headers. The message body contains the XML dataset. The headers hold extra data
such as extensibility information.
a mechanism for data representation
To engage in SOAP messaging, you must represent familiar programmatic data structures, such
as objects, arrays, and variables, in XML. The SOAP data model provides an abstract
representation of programmatic data structures. SOAP encoding provides a set of rules to map
the data model into XML so it can be transmitted in SOAP messages.
an RPC mechanism
Remote procedure calls (RPCs), and responses to these calls, can be represented in XML form
in SOAP messages.
a processing model
The processing model is a set of rules that defines how SOAP messages are dealt with by the
nodes that receive them.
a protocol-binding framework
The SOAP protocol-binding framework makes it possible to build bindings between SOAP and
different transport protocols, so that SOAP messages can be transported over them. SOAP is
most commonly used with HTTP for Internet-based communications.
extensibility mechanisms
You can place extensibility information in headers in SOAP messages to extend basic SOAP
functionality. Different headers may be designed to target different nodes on the SOAP
message's path.
an error-handling mechanism
SOAP faults enable you to locate and determine the cause of errors in a SOAP message
exchange. Error data can be transferred in SOAP fault messages between sender and receiver in
a SOAP exchange.
Because SOAP is deliberately designed as a lightweight protocol, certain complex features

typical of many distributed systems are not supported by SOAP. These include
 activation
 distributed garbage collection
 message batching
 objects by reference
activation
Activation refers to the process by which a remote server object is activated only when a call to
the server is made. The alternative to activation is to have remote objects continuously waiting on
standby for client requests.
distributed garbage collection
Distributed garbage collection involves the disposal from memory of remote objects when their
local and remote references are no longer active.
message batching
Message batching involves the grouping of multiple messages into a single entity – a batch – that
is then sent to a message dispatcher. Using a batch, multiple messages can be placed in the
same TCP packet.
objects by reference
In many distributed object systems, applications interact with remote objects by reference – the
application never gets a copy of the actual object, just a reference to it. Through this reference,
an application communicates with the actual object instance, which resides on the remote
machine.
The SOAP specification defines a syntax for SOAP messages that contains a number of
components, including
 an envelope
 message headers
 header entries
 message body
 message payload
an envelope
The SOAP envelope contains the entire SOAP message.
message headers
A SOAP envelope can optionally contain a number of headers. The SOAP headers contain
supplementary information not part of the message itself.
header entries
You use SOAP headers to hold header entries that provide supplementary data, such as security
or policy settings. You can use header entries to extend the basic functionality of SOAP.
message body
The message body holds the message payload. It follows the headers, if there are any.
message payload
The message payload is the data or instructions in XML format that need to be passed between
the web services. It can also be a SOAP fault if an error occurs during processing.
Question
Match each component of a SOAP message to the role it plays.
Options:
1. Body
2. Envelope
3. Header
Targets:
A. Contains extra information outside of the message payload

B. Contains the message payload
C. Encloses the entire message
Answer
The body contains the message payload. The envelope encloses the message. Headers contain
extra information outside of the message payload.
The message body holds the message payload. It follows the headers, if there are any.
The envelope holds both the optional headers and the message body.
Headers optionally provide extra information outside of the message payload. A single message can
contain multiple headers.
The SOAP data model can be described visually using graphs to represent data and
relationships.
A graph provides a neutral way of describing the data model that relates equally to both
programming languages and corresponding XML code.
A graph connects nodes to other nodes using edges. The nodes are values, while the edges are
labels. Each edge has a direction, whether outgoing or incoming.
A node with one or more outgoing edges is known as a compound-value node. And a node with
one or more incoming edges is known as a simple-value node.
A named edge is the equivalent of an XML element.
The simple node to which a named edge points contains the value of the element. Or it may
point to subelements, depending on the structure of the graph.
SOAP encoding provides a set of rules that translates a SOAP data model graph into XML code.
So SOAP encoding is used to transform programmatic entities, such as objects, arrays, and
variables, into XML.
A SOAP Message Exchange Pattern (MEP) specifies how SOAP messages are exchanged in a
particular interaction between SOAP nodes.
It specifies the number of messages involved, where the messages originate, and where they
go.
Each SOAP binding must support at least one MEP.
In SOAP 1.2, two MEP types are supported:

 Request-Response
 SOAP Response
Request-Response
Request-Response involves the requesting node sending an initial SOAP message to the
responding node. The responding node replies with an answering SOAP message.
The elements of the response must map to the elements of the request so that the requesting
node can interpret the response. Any faults generated at the responding node are compulsorily
returned to the requesting node in the response.
SOAP Response
In SOAP Response, the requesting node sends an initial non-SOAP message to the responding
node. The responding node replies with a SOAP message. This makes it possible to respond to,
for example, an HTTP request with a SOAP message.
Question
Which of these are involved in SOAP Response MEPs?
Options:
1. An initial non-SOAP message

2. An initial SOAP message
3. A non-SOAP response
4. A SOAP response
Answer
The SOAP Response MEP involves an initial non-SOAP message and a SOAP response.
Option 1 is correct. While the initial message is non-SOAP, the response is always a SOAP
message.
Option 2 is incorrect. The Request-Response MEP involves an initial SOAP message.
Option 3 is incorrect. Neither MEP involves non-SOAP responses.
Option 4 is correct. The request is non-SOAP but the response is a SOAP message.
2. SOAP communication styles

The following two communication styles are supported by SOAP 1.2:
 Remote Procedure Call (RPC)-style messaging
 Document-style messaging
Remote Procedure Call (RPC)-style messaging

RPC is the process by which a client application calls a method in an application or service on
another computer.
RPC is a common mechanism for web service interaction.
You can use a SOAP message to send a remote procedure call to a web service.
The SOAP message payload contains a reference to the method to be invoked.
It also specifies the relevant parameters, if there are any – these are always passed by value in
the case of web services - as well as the target method's URI.
This information is encoded according to the SOAP encoding standard, which guarantees that
XML elements in the message map correctly to programmatic entities in the referenced web
service.
When the target method is executed, appropriate information is returned to the caller, again
encapsulated in a SOAP message.
RPC-style messages can be synchronous or asynchronous.
RPC is suited to situations in which
 you want to make an existing component available as a web service

 the programmatic entities encoded in the message must retain referential integrity over multiple
references to the same object
A major disadvantage of RPC-style messages is that, because SOAP Encoding allows a non-
deterministic set of valid serializations for the same object, they can't be easily validated using
XML schemas.
In addition, in RPC messages, the data structure depends on the structure of the method being
called. This limits the extent to which RPC SOAP code can be extended.
And there is tighter coupling between the message structure and the web service implementation
code than in the case of document-style messaging.
Document-style messaging
The body of a document-style SOAP message contains an unencoded XML document or
fragment.
Document-style messages can be synchronous or asynchronous.
For document-style SOAP messaging to be effective, there must be a guarantee that the web
service that receives the message is able to parse it in the correct way.
Historically, document-style SOAP messaging was used primarily when no response was
required, such as for transmitting notifications and status information.
However, you can correlate document-style messages by passing one or more unique identifiers
in the SOAP request.
These are returned in the SOAP response and enable the client to associate the response with
the correct request.
You can use document-style SOAP messaging when you have preexisting XML structures that
you want to use - encoding is not necessary in this case.
When you need to validate the XML contained in SOAP messages, you should also use
document-style messaging because it is relatively difficult to develop an XML schema to validate
a SOAP-encoded data model.
Because of issues with SOAP encoding, document-style messaging is sometimes used in favor
of RPC messaging for calling remote methods.
One reason for this is that document-style SOAP messages can be extended more easily than
RPC messages.
Question
Which of these situations are well suited to document-style SOAP messaging?
Options:
1. Ensuring that the structure of your XML exactly maps to the structure of the remote method you
wish to call
2. Ensuring that the XML you transmit can be validated
3. Passing parameters to a web service method
4. Sending a notification
5. Transmitting existing XML documents
Answer
You use document-style SOAP messaging when you want to transmit existing XML documents,
when you want to send a notification, and when you want to ensure that the XML you transmit can
be validated.
Option 1 is incorrect. Because you use SOAP Encoding to do this, an RPC-style SOAP message is
most appropriate to this situation.
Option 2 is correct. It is easier to validate the XML contained in SOAP messages when you use
document-style messaging than it is in the case of RPC-style messaging.
Option 3 is incorrect. In RPC-style messaging, information such as parameters is encoded

according to the SOAP Encoding standard. This guarantees that XML elements in the message
map correctly to programmatic entities in the referenced web service.
Option 4 is correct. Document-style SOAP messages are more appropriate to situations in which no
response is required, such as when you send a notification.
Option 5 is correct. There is no need to encode existing XML documents, so document-style SOAP
messaging is appropriate in this case.
3. SOAP transport bindings

A SOAP binding comprises the rules that specify a way of transmitting SOAP infosets over
specific transport protocols from one SOAP node to another.
For example, in the case of the SOAP HTTP binding, the rules specify how the SOAP infoset is
serialized across an HTTP connection between nodes.
The SOAP transport-protocol binding framework is designed to enable SOAP messages to be

transmitted over any protocol.
The SOAP HTTP binding is included in the SOAP specification as an example of how to create
a SOAP binding.
Many bindings, including the SOAP HTTP binding, require that the infoset should be serialized
using the XML 1.0 serialization specification.
However, bindings can also use custom serializations, as long as the infoset reaches its
destination intact.
Such custom serializations may have advantages in terms of data compression or security, for
example.
The source and destination node must initially agree on the binding to use.
For this reason, URIs are used to identify each binding.
Note
The SOAP HTTP binding URI is found on the World Wide Web Consortium web site.
Different bindings offer different levels of capability.
For example, some bindings might guarantee arrival, such as Java Message Service, while
others might not. And some might offer enhanced security, such as HTTPS - a secure form of
HTTP that uses the Secure Sockets Layer (SSL).
Binding to the multicast IP protocol could offer the capability to broadcast the infoset to multiple
recipients at once.
The transport protocol most commonly used with SOAP is HTTP. HTTP supports both types of
SOAP MEP but is essentially a request-response protocol.
In the case of the Request-Response MEP, the SOAP request is encapsulated in an HTTP
request and the SOAP response is encapsulated in an HTTP response.
The SOAP Response MEP uses an HTTP GET request and the SOAP response is
encapsulated in an HTTP response.
SOAP message exchanges using HTTP most commonly involve the POST HTTP method.
However, there are a range of other HTTP methods you may wish to use.
To accommodate these, SOAP 1.2 defines the Web Method feature, which defines a single
property that takes as its value the name of the relevant HTTP method.
The HTTP binding can use the value held by Web Method instead of the default POST method.
SOAPAction is a custom HTTP header compulsory with the SOAP 1.1 HTTP binding that
differentiates SOAP traffic from other XML documents being transmitted across HTTP.
In SOAP 1.2, this is replaced by the application/soap+xml media type, which can be used in the
HTTP Content-Type header.
Question
Which of these are characteristics of the SOAP 1.2 HTTP binding?
Options:
1. Only the Request-Response MEP can be used with the SOAP HTTP binding
2. The content of the HTTP request or response must be designated using the SOAPAction header
3. The SOAP response is always encapsulated in an HTTP response
4. The Web Method feature defines a single property that takes as its value the name of the relevant
HTTP method to be used
Answer
The SOAP response is always encapsulated in an HTTP response and both SOAP MEPs can be
used with the SOAP HTTP binding.
Option 1 is incorrect. Both MEPs are supported by the SOAP HTTP binding.
Option 2 is incorrect. The SOAPAction header is valid only in SOAP 1.1.
Option 3 is correct. However, a GET HTTP request may be used instead of a SOAP request.
Option 4 is correct. The POST method is its default value.
Extending SOAP messages
1. Using headers
The message header, along with the message body, is one of the elements of the SOAP
envelope. The message header, which is optional, contains supplementary information about
the SOAP message.
You use headers to extend the functionality of SOAP - for example, you can add features to the
SOAP message and convey application-specific information. This is known as vertical
extensibility.
You can use the message header in a SOAP envelope to
 extend the messaging structure

 define orthogonal data
extend the messaging structure

Extending the messaging structure allows you to define additional metadata - related to routing,
message correlation, or security for example - without changing the payload of the message.
Extending message structure in this way is useful for middleware, which can define infrastructure
headers. This means the application that is the message's eventual recipient sees only the effects
of the header, without having to process it itself.
define orthogonal data
Orthogonal data is data separate from, but related to, the data in the body of the SOAP envelope.
For example, you can use headers to send extra data to accompany nonextensible body
elements. This data is most useful for the recipient application processing the message.
In the SOAP envelope, the Header element represents the message header.
When using the message header option, you must ensure that the Header element is the first
child of the Envelope element.
<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<img:reference xmlns:img="http://www.imagenie.com/">
uuid:054n6bn5-m572-667m-ak4d-hjen45yo8i6e</img:reference>
<img:dateAndTime>2004-10-17T09:30:00.000-05:00</img:dateAndTime>
<c:custInfo xmlns:c="http://www.imagenie.com/customers"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<c:custID>jgol001</c:custID>
<c:Password>3r56tru8g</c:Password>
<c:email>jgold@brocadero.com</c:email>
</c:custInfo>
</env:Header>
<env:Body>
<c:customer xmlns:c="http://www.imagenie.com/customers">
<c:customerName>
<c:firstName>Jonathan</c:firstName>
<c:lastName>Gold</c:lastName>
</c:customerName>
<c:customerAddress>
<c:street>4801 Long Street</c:street>
<c:city>New York</c:city>
<c:country>USA</c:country>
<c:phoneNumber>923-406-7890</c:phoneNumber>
</c:customerAddress>
</c:customer>
</env:Body>
</env:Envelope>
Suppose you have a Header element with several entries.
First you want to pass the reference to a graphic, and the date and time the message was sent.
You use the user-defined header reference, and include the details of the image - in this
case, a universally unique ID for it - and the dateAndTime element, so as to include a
timestamp.
<env:Header>
</c:custInfo>
</env:Header>
<env:Body>
<c:customerName>
</c:customerName>
<c:customerAddress>
</c:customer>
</env:Body>
</env:Envelope>
You also want to send customer information in the header entry, custInfo.
In your business scenario, this data is crucial to processing the message, so the receiver needs
to be able to interpret the content of this entry and process it in the correct way.
<env:Header>
</c:custInfo>
</env:Header>
<env:Body>
<c:customerName>
</c:customerName>
<c:customerAddress>
</c:customer>
</env:Body>
</env:Envelope>
To indicate that the receiver must be able to handle the header, you use the mustUnderstand
attribute.
This ensures the targeted SOAP nodes do not ignore header blocks if they don't know how to
process them.
You can use this global attribute on any header block, which then becomes a mandatory header.
<env:Header>
</c:custInfo>
</env:Header>
<env:Body>
<c:customerName>
</c:customerName>
<c:customerAddress>
</c:customer>
</env:Body>
</env:Envelope>
In SOAP 1.2, the mustUnderstand attribute takes the following values:
 1/true
 0/false
1/true
The values "1" or "true" indicate that processing of the element is mandatory. Receivers can't
process the message unless they can first handle and process the header that contains the
mustUnderstand attribute. If they can't handle the header, they must return a SOAP fault
message.
In SOAP 1.1, the only legal mustUnderstand value for indicating mandatory processing is 1.
0/false
The values "0" or "false", which are the defaults for mustUnderstand, indicate that processing
of the element is optional. Receivers unfamiliar with the extension can safely ignore it.
In SOAP 1.1, the only legal mustUnderstand value for indicating optional processing is 0.
The mustUnderstand attribute can also be used in RPC-style messages. Suppose you have a
header in an RPC request message that contains transaction information - to indicate that the
exchange of which it is part should be treated as a single transaction, for instance.
To carry the information, you use the header entry ent:transaction, and direct it at the
ultimate recipient by leaving out the env:role attribute.
<env:Header>
<ent:transaction xmlns:ent="http://www.easynomadtravel.com/
transactions"
env:encodingStyle="http://www.easynomadtravel.com/encoding"
env:mustUnderstand="true">Required</ent:transaction>
</env:Header>
<env:Body>
<img:orderProduct
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:img="http://www.imagenie.com/">
<p:product xmlns:p="http://www.imagenie.com/codes">
<p:productCode>aw34zp0</p:productCode>
</p:product>
<c:id>ENT01</c:id>
<c:name>Jonathan Gold</c:name>
<c:address>51 East Street</c:address>
</c:customer>
</img:orderProduct>
</env:Body>
</env:Envelope>
You use the mustUnderstand attribute to ensure the receiver agrees to the terms of the
transaction header's extension specification.
The value "Required" is a transaction identifier set by and meaningful to the application, and it
must be understood and processed appropriately by the receiver.
<env:Header>
<ent:transaction xmlns:ent="http://www.easynomadtravel.com/
transactions"
env:encodingStyle="http://www.easynomadtravel.com/encoding"
env:mustUnderstand="true">Required</ent:transaction>
</env:Header>
<env:Body>
<img:orderProduct
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:img="http://www.imagenie.com/">
<p:product xmlns:p="http://www.imagenie.com/codes">
<p:productCode>aw34zp0</p:productCode>
</p:product>
<c:id>ENT01</c:id>
<c:name>Jonathan Gold</c:name>
<c:address>51 East Street</c:address>
</c:customer>
</img:orderProduct>
</env:Body>
</env:Envelope>
Question
You want to use the mustUnderstand attribute to ensure that the targeted SOAP nodes do not
ignore your header message.
Which of the following uses of the mustUnderstand attribute would be appropriate for this in
SOAP 1.2?
Options:
1. mustUnderstand="0"
2. mustUnderstand="1"
3. mustUnderstand="true"
4. mustUnderstand="yes"
Answer
To ensure the targeted SOAP nodes do not ignore your header message, you can use
mustUnderstand="1" or mustUnderstand="true".
Option 1 is incorrect. The default value "0" indicates that the element is optional.
Option 2 is correct. In SOAP 1.2, you can also use the value "true" with the mustUnderstand
attribute to indicate that the element is mandatory. In SOAP 1.1, the only legal value to indicate a
mandatory header is "1".
Option 3 is correct. In SOAP 1.2, you can also use the value "1" with the mustUnderstand
attribute to indicate that the element is mandatory. In SOAP 1.1, the only legal value to indicate a
mandatory header is "1".
Option 4 is incorrect. The values "1" or "true" indicate that the element is mandatory.
2. Using intermediaries
SOAP was built to accommodate SOAP intermediaries. These are processing nodes that exist
along the path of a SOAP message as it travels from sender to receiver.
These processing node applications can inspect, insert, delete, or forward the message. And
because several nodes may process the same message, it is useful to direct processing of
different parts of the message to different nodes. This is known as horizontally extending the
SOAP message.
Intermediaries are essential for creating scalable systems, as they facilitate load balancing and
more efficient message routing. For example, e-mail is a highly scalable distributed system that
requires flexible buffering of messages.
This requirement is based not only on message parameters, but also on system factors such as
the availability and load of its nodes, as well as network traffic data. Intermediaries perform this
work on behalf of the message originators and final recipients.
You use SOAP intermediaries to provide value-added services, such as
 securing message exchanges

 notarizing messages
 tracing messages
securing message exchanges

You can secure SOAP messages by passing them through an intermediary that encrypts and
then digitally signs them. This is particularly useful when passing messages through
untrustworthy domains. Security intermediaries are often transparent intermediaries, which
means that the client doesn't know or need to know about them when sending a message.
notarizing messages
By using a notarizing intermediary, the sender and receiver of a SOAP message can make a third
party record of the interaction. The service requestor sends a message to the intermediary, which
makes a persistent copy of the request and then sends it to the service provider. Both sender and
receiver receive a token through which they can reference the transaction record. Notarizing
intermediaries are explicit intermediaries, which means that the client is aware of them when
sending a message.
tracing messages
The recipient of a SOAP message can trace messages to find out the path they followed, times of
arrivals and departures, and the intermediaries used. This information is useful when measuring
quality of service, auditing systems, and identifying scalability bottlenecks.
SOAP provides two types of intermediaries:
 forwarding
 active
forwarding
A forwarding intermediary is a SOAP node that processes a message based on the semantics of
the message's headers and then forwards it to another node.
active
An active intermediary is a SOAP node that performs additional processing on SOAP messages,
where this processing is not based on the message's semantics. For example, a security
intermediary may encrypt a message, even though none of the message's headers specifically
request encryption.
If the message path has a number of nodes, you can address a Header element to a particular
intermediary by using the role attribute, whose value is a URI indicating the intermediary's
name.
The targeted intermediary processes the header targeted at it and removes it before forwarding
the message.
<env:Header>
env:relay="true">
</c:custInfo>
</env:Header>
<env:Body>
<c:customerName>
</c:customerName>
<c:customerAddress>
</c:customer>
</env:Body>
</env:Envelope>
Note
In SOAP 1.1, the role attribute was known as actor. The attribute's name has been changed
because a group of nodes, not just a single actor, may play the same role.
If this attribute is not present, the header element is retained and forwarded to the next node in
the message path.
<env:Header>
env:relay="true">
</c:custInfo>
</env:Header>
<env:Body>
<c:customerName>
</c:customerName>
<c:customerAddress>
</c:customer>
</env:Body>
</env:Envelope>
The special values of the role attribute are
 next
 none
 ultimateReceiver
next
The URI
http://www.w3.org/2003/05/soap-envelope/role/next
indicates that the recipient of the header entry is the next SOAP node that processes the
message.
none
The URI
http://www.w3.org/2003/05/soap-envelope/role/none
indicates that any headers whose role attribute has this value should never be processed,
although they can be used to carry information.
ultimateReceiver
The URI
http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver
indicates the final recipient of the SOAP message, which is the node that processes the body of
the message. You can indicate the same thing by setting the role attribute's value to an empty
string.
When processing a SOAP message, a node first identifies the headers targeted to it by their
role attributes.
If the role attribute of a header matches any of the roles that the node plays, the node collects
the header.
For example, in the header entry custInfo, the value of the role attribute is next, meaning
the recipient of the header entry is the next SOAP node that processes the message.
<env:Header>
env:relay="true">
</c:custInfo>
</env:Header>
<env:Body>
<c:customerName>
</c:customerName>
<c:customerAddress>
</c:customer>
</env:Body>
</env:Envelope>
You can use the next role setting together with another attribute, relay, with header blocks
that carry information which is expected to persist along a SOAP message path.
Although a node normally removes headers targeted at it, even if it does not understand them,
when set to true, the relay attribute indicates that the node must relay headers targeted at it,
even if not processed because they are not understood.
The relay attribute, when used with the next role, therefore ensures that each intermediary
has a chance to examine the header.
env:relay="true">
Question
Match each special value of the role attribute to the correct description.
Options:
1. http://www.w3.org/2003/05/soap-envelope/role/next
2. http://www.w3.org/2003/05/soap-envelope/role/none
3. http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver
Targets:
A. Indicates that nodes should never process headers addressed to this role
B. Indicates the final recipient of the SOAP message
C. Indicates that the recipient of the header entry is the following node that processes the message
Answer
The URI
http://www.w3.org/2003/05/soap-envelope/role/next
indicates that the recipient of the header entry is the next node that processes the message.
The URI
http://www.w3.org/2003/05/soap-envelope/role/none
indicates that nodes should never process headers addressed to this role.
The URI
http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver
indicates the final recipient of the SOAP message.
The short-name for this value is "next".
The short name for this value is "none".
The short name for this value is "ultimateReceiver".
3. The SOAP Processing Model

The steps that a SOAP processor must perform on receiving a SOAP message are
 determining the roles that apply to it

 identifying mandatory headers
 generating faults, if necessary
 processing mandatory headers
 relaying the message
determining the roles that apply to it

The SOAP processor first determines the set of roles in which the node where it runs must act.
To do this, the processor can inspect the entire contents of the SOAP envelope, including the
body and the header, if present.
identifying mandatory headers
The SOAP processor next identifies all mandatory header blocks targeted at the node.
generating faults, if necessary
If the node fails to understand one or more of the SOAP header blocks in the previous step, the
SOAP processor generates a single SOAP fault with the value of the Code element set to
env:mustUnderstand. If a fault is issued, the processor must not continue processing.
processing mandatory headers

If all mandatory headers are understood, the SOAP processor next processes them. A SOAP
node can also process nonmandatory SOAP header blocks.
relaying the message
Finally the SOAP processor relays the message.
The SOAP Processing Model shows how an intermediary relays a SOAP message. This occurs
when the SOAP message exchange pattern, and processing results, require that the
intermediary send the SOAP message further along the SOAP message path.
Question
Rank the steps involved in implementing the processing model.

Options
Option Description
A Generate faults, if necessary
B Determine the roles
C Process mandatory headers
D Relay the message
E Identify the mandatory headers
Answer
Correct ranking
Option Description
B Determine the roles

The SOAP processor first determines the set of roles in which the node must act.
E Identify the mandatory headers

The SOAP processor next identifies all header blocks targeted at the node that are
mandatory.
A Generate faults, if necessary

If the node fails to understand one or more of the SOAP header blocks in the previous step,
the SOAP processor generates a single SOAP fault with the Code value set to
env:mustUnderstand. If a fault is issued, the processor must not process any further.
C Process mandatory headers

If a fault was not generated, the SOAP processor next processes all mandatory SOAP header
blocks identified in step 2.
D Relay the message

The SOAP Processing Model means that an intermediary relays a SOAP message when the
SOAP message exchange pattern and results of processing require that the SOAP message
be sent further along the SOAP message path.
Differences between SOAP 1.1 fault messages and SOAP 1.2 fault
messages
SOAP 1.2 uses the element names Code and Reason. In SOAP 1.1, these elements were called
faultcode and faultstring, respectively.
SOAP 1.2 allows multiple language versions of the fault reason by enabling multiple
Text child elements of Reason qualified by xml:lang.
SOAP 1.2 provides a hierarchical structure for the mandatory SOAP Code subelement
in the Fault element. It also introduces two optional subelements, Node and Role.
SOAP 1.2 has no distinction between header and body faults, as indicated by the
presence of the Details element in Fault.
In SOAP 1.2, the Details element has no significance as to which part of the fault
SOAP message is processed.
<p> This page contains a JavaScript function that prints out the current frame document. To
print out the document without using JavaScript, you need to press Control P.<br />< /p>
| Print | Contents | Close |
SOAP faults
Learning objective
After completing this topic, you should be able to identify the syntax used to transmit fault
information in SOAP messages.
1. SOAP fault structure

During the processing of a SOAP message, endpoints may encounter errors as they verify
header entries or execute body entries.
The processing application's ability to transmit fault information depends on the underlying
message transport mechanism, and is one aspect of binding SOAP to a particular protocol.
The mechanism must be capable of signaling the faults generated while processing received
messages.
When faults arise in the processing of a message, SOAP provides a means for indicating the
cause - the SOAP fault message.
This message not only indicates that an error has occurred, but also communicates the reason
for the failure to the originator of the message.
A SOAP fault message is an ordinary SOAP message that contains in its body the Fault
element.
This optional element reports all SOAP-specific and application-specific faults.
For example, suppose a SOAP RPC message requests a procedure that doesn't exist, and
causes a fault. The fault message returned will be similar to the one shown here.
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:rpc="http://www.w3.org/
2003/05/soap-rpc">
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>rpc:ProcedureNotPresent</env:Value>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text xml:lang="en-US">Unknown service request</env:Text>
</env:Reason>
<env:Detail>
<img:imgFaultDetails
xmlns:img="http://www.imagenie.com/errors">
<img:message>The method requested does not exist at this
endpoint
</img:message>
</img:imgFaultDetails>
</env:Detail>
</env:Fault>
</env:Body>
</env:Envelope>
The Fault element has several important subelements.
 Code
 Subcode
 Reason
 Detail
Code
The Code element is a required one, and its Value subelement contains the fault code, which is
a predefined XML qualified name. In this case, the fault value is Sender, which indicates that the
message contains a syntactical error or inappropriate data from the sender. Other fault values
include Receiver, mustUnderstand, and VersionMismatch, which is generated when the
sender is using a SOAP version not supported by the receiver.
Subcode
The Subcode element is an optional one that provides a further level of detail about the fault.
Like Code, it contains a required Value subelement, which in this case indicates that a
procedure was not present.
Reason
The Reason element is required, and it contains a human-readable description of the fault. In this
case, the Reason element indicates that the sender has made an unknown or unrecognized
request. Reason is a subelement of the Fault element.
Detail
The Detail element contains machine-readable data on the fault. In this case, the Detail
element passes back the message that the method requested does not exist at this endpoint.
Detail is an optional subelement of the Fault element.
SOAP 1.2 has overhauled the fault message from SOAP 1.1.
Supplement
Selecting the link title opens the resource in a new browser window.
Launch window
View the differences between SOAP 1.1 fault messages and SOAP 1.2 fault messages.
Question
Which are subelements in a SOAP Fault element?
Options:
1. Detail
2. Reason
3. Sender
4. Subcode
Answer
Important elements in a SOAP Fault element include Detail, Reason, and Subcode.
Option 1 is correct. The Detail element contains machine-readable data on the fault.
Option 2 is correct. The Reason element contains a human-readable description of the fault.
Option 3 is incorrect. The Sender value is a predefined one used by the Code element's Value
subelement to indicate that the message contains a syntactical error or inappropriate data from the
sender.
Option 4 is correct. The Subcode element provides a further level of detail about the fault.
2. Using headers in faults

SOAP defines two new headers specifically for use in faults.
 The NotUnderstood header

 The Upgrade header
The NotUnderstood header

When sending back a mustUnderstand fault, a SOAP processor should use a
NotUnderstood header to indicate each header in the original message that it didn't
understand.
Suppose you have a header called ent:transaction in an RPC request message.
The sender of this request uses the mustUnderstand header to ensure that the receiver
processes the header.
In this case, the value "Required" is a header value set by and meaningful to the application.
The code highlighted is ent:transaction.
If the processor doesn't understand the mustUnderstand header, the sender should receive the
fault message shown.
The fault message contains the NotUnderstood header, which indicates a failure to process the
transaction header block.
The code highlighted is NotUnderstood.

The NotUnderstood header has a qname attribute that contains the qualified name of the
header that the processor didn't understand - in this case, ent:transaction.
The code highlighted is ent:transaction.
The MustUnderstand fault code appears in the body of the message, between the Value tags.
The code highlighted is MustUnderstand.
The NotUnderstood header is useful for SOAP messages with multiple mustUnderstand
headers.
If several mandatory header blocks were not understood, the sender could identify each quickly
by searching the qname attributes within a series of NotUnderstood headers.
The Upgrade header

When a SOAP node generates a VersionMismatch fault, it should provide an Upgrade SOAP
header block in the generated fault message.
The Upgrade header details the qualified names of the SOAP envelopes that the SOAP node
supports.
The code highlighted is Upgrade.
The Upgrade header, which appears in the SOAP namespace, contains one or more
SupportedEnvelope elements.
Each element indicates the qname of a supported Envelope element, as well as the namespace
for the envelope.
The code highlighted is <env:SupportedEnvelope qname="soap-ns1:Envelope"

xmlns:soap-ns1="http://www.w3.org/2003/05/soap-envelope"/>
<env:SupportedEnvelope qname="soap-ns2:Envelope"
xmlns:soap-ns2="http://schemas.xmlsoap.org/soap/envelope"/>
The Upgrade header orders the SupportedEnvelope elements by preference, from the most
preferred to the least.
For example, the fault shown

indicates that the node supports both SOAP 1.1 and 1.2, but prefers 1.2.
The code highlighted is http://www.w3.org/2003/05/soap-envelope
Question
What is the purpose of the NotUnderstood header?
Options:
1. Ensuring that the receiver processes certain headers

2. Identifying the offending header in a SOAP fault
3. Indicating that the receiving node cannot play the role specified in the original message
4. Indicating which versions of SOAP a node supports
Answer
The NotUnderstood header identifies the offending header in a SOAP fault that is generated when
the processor doesn't understand a mandatory header.
Option 1 is incorrect. The mustUnderstand attribute ensures that the receiver processes certain
headers.
Option 2 is correct. When sending back a mustUnderstand fault, a SOAP processor should use a
NotUnderstood header to indicate each header in the original message that it didn't understand.
Option 3 is incorrect. In fact, if a header targets a particular role and the receiving node does not
play that role, it simply forwards the header to the next node in the message path.
Option 4 is incorrect. The Upgrade header indicates which versions of SOAP a node supports.
Summary
You use the optional SOAP Fault element to store error and status information for SOAP
messages. The Fault element's subelements include Code, Subcode, Reason, and Detail.
The Code element indicates the cause of the fault. The Subcode element provides a further
level of detail about the cause. The Reason element contains human-readable information in
the fault. The Detail element houses machine-readable data.
SOAP defines two headers specifically for use in faults - NotUnderstood and Upgrade. The
NotUnderstood header identifies the offending header in a SOAP fault. The Upgrade header
indicates which versions of SOAP a node supports.
<p> This page contains a JavaScript function that prints out the current frame document. To
print out the document without using JavaScript, you need to press Control P.<br />< /p>
| Print | Contents | Close |
Concrete elements in WSDL 1.1 documents

Learning objective
After completing this topic, you should be able to identify the syntax used to construct concrete
elements in a WSDL document.
1. Binding in a WSDL document

While the abstract part of the WSDL document provides data and port type definitions, the
concrete part, also known as the service implementation definition, defines the binding of port
types to protocols and provides the locations of service endpoints.
The binding element in a WSDL document indicates to the service requester how the
message should be formatted for particular protocols.
One or more binding elements can be associated with each portType. The binding
element describes how to invoke operations using a particular transport protocol.
Generally, however, WSDL documents only contain one binding element.
This WSDL document provides a web service that converts an integer value in dollars to its
equivalent in euros.
<?xml version="1.0" encoding="UTF-8"?>

<definitions targetNamespace="http://www.imagenie.com/converter"
xmlns:tns="http://www.imagenie.com/converter"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<types/>
<message name="convertAmountRequest">
<part name="amount" type="xsd:double"/>
</message>
<message name="convertAmountResponse">
<part name="result" type="xsd:double"/>
</message>
<portType name="CurrencyConverter">
<operation name="convertAmount" parameterOrder="amount">
<input message="tns:convertAmountRequest"
name="convertAmountRequest"/>
<output message="tns:convertAmountResponse"
name="convertAmountResponse"/>
</operation>
</portType>
You want to add a binding element to the WSDL document. This element takes two attributes.
The binding element contains two attributes: <binding name="CurrencyConverterSoapBinding"
type="tns:CurrencyConverter">
 name
 type
name
The name attribute is used to uniquely identify the binding, and is conventionally made up of the
portType name and the protocol to which the portType is bound.
In this case the name is CurrencyConverterSoapBinding, where CurrencyConverter is

the name of the portType and SOAP is the protocol to which it is mapped.
type
The value of the type attribute is a fully qualified reference to the portType that this binding is
for.
In this WSDL document there is only one portType – CurrencyConverter. The tns prefix is
used to qualify the reference to indicate that it's a portType in the current document.
The current WSDL specification allows bindings to be extended with elements from different
XML namespaces, so that bindings can map to any number of messaging and transport
protocols.
The WSDL 1.1 specification defines three standard binding extensions:

SOAP 1.1 over HTTP, HTTP GET/POST and SOAP 1.1 with Multipurpose Internet Mail
Extensions (MIME) attachments.
</operation>
</portType>
<binding name="CurrencyConverterSoapBinding"
<soap:binding
In this case, the binding is to the SOAP protocol, so the binding element soap:binding is
used.
</operation>
</portType>
<soap:binding
The CurrencyConverterSoapBinding element will define the full binding for the
CurrencyConverter portType in four ways:
1. invocation style
2. SOAPAction value
3. input message format
4. output message format
</operation>
</portType>
<soap:binding
The SOAP binding's invocation style is specified using the style attribute.
</portType>
<soap:binding style
The style attribute can have one of two values:
 rpc
 document
rpc
The rpc value means that the SOAP message represents a Remote Procedure Call as defined in
the SOAP specification.
document
The document value refers to document-style messaging. When this is used, the body of the
resulting SOAP message is an ordinary XML document.
However, the document style can be used only for messages whose part elements use the
element attribute. You should use rpc for messages that use the type attribute in their part
elements.
In this example, the style invocation is RPC.
</portType>
<soap:binding style="rpc"
Next, you insert the transport attribute into the SOAP binding element. This indicates that the
requester should send the SOAP message over HTTP.
</portType>
transport="http://schemas.xmlsoap.org/soap/http"/>
You could also set the transport attribute to use SMTP or FTP by using the appropriate URI.
However, if you do define other bindings for a service, you should also define one binding for
SOAP/HTTP, to maintain your web service's interoperability.
Each operation defined in the portType element must be referred to here, using the same
WSDL operation element. So you begin with the operation named convertAmount.
</operation>
</portType>
<operation name="convertAmount">
Note
You can override the overall portType binding style by placing a style declaration in any of the
child operation elements. However, this is not recommended.
When the binding is SOAP, each operation has a subelement, also called operation, but
which is bound to the SOAP namespace.
</portType>
<soap:operation
soapAction="http://imagenie/axis/services/converter/convertAmount"/>
This operation element has an attribute called soapAction that defines the value placed in
the SOAPAction header of the actual SOAP message. The SOAPAction header, in turn,
describes the intent of the SOAP message.
Having inserted the opening tag for this WSDL soap:operation element, you are now ready
to define some child elements.
This operation element must specify the same elements used in the portType element.
Since the CurrencyConverter operation followed a request-response model, you used both
an input and output element, so you must specify these elements here.
You begin with the input element, providing it with the same name attribute,
convertAmountRequest, that you used for the input element in the portType operation.
</operation>
</portType>
<soap:operation
<input name="convertAmountRequest">
Each input or output element describes how the input or output to the service appears in the
SOAP message. In this case the body element, in the SOAP namespace, indicates that the
input and output form the body of the SOAP messages.
You may also define zero or more SOAP header elements here, but you decide not to do so in
this case.
</portType>
<soap:operation
<soap:body
As you have specified the binding style to be rpc, you must now provide the SOAP body with
the appropriate attributes for that style.
</portType>
<soap:operation
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://www.imagenie.com/converter" use="encoded"/>
Three attributes are defined on this element.
 encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
 namespace="http://www.imagenie.com/converter"
 use="encoded"
The value of the encodingStyle attribute is a URI, which indicates how the data will be
encoded in the SOAP message. The value here –
http://schemas.xmlsoap.org/soap/encoding/ – is the only permitted value for SOAP
1.1 encoding.
namespace="http://www.imagenie.com/converter"
For RPCs, the data in the SOAP message itself is contained within a wrapper element, whose
name is identical to that of the operation. This element is in the namespace defined with this
namespace attribute.
use="encoded"
The required use attribute controls whether the data is encoded within the SOAP message. If the
value is encoded, then the value of the encodingStyle attribute dictates the encoding. The
other possible value is literal, which indicates that the SOAP binding style is document and
that the message is included in the SOAP message as ordinary XML.
This input element is now complete, so you insert a closing tag.
</portType>
<soap:operation
<soap:body
</input>
The output element is defined in exactly the same way.
Since the convertAmount operation defined in the portType element only contained input
and output elements, the binding of this operation is now complete.
</portType>
<soap:operation
<soap:body
</input>
<output name="convertAmountResponse">
<soap:body
</output>
</operation>
</binding>
Question
Match the SOAP encoding attributes from the binding element's subelements to the appropriate
description.
Options:
1. encodingStyle
2. namespace
3. style
4. use
Targets:
A. Indicates how the data is encoded in the SOAP message

B. Controls whether the data is encoded or appears literally within the SOAP message
C. Defines the RPC wrapper element
D. Determines whether the binding is for an RPC or document-oriented message
Answer
encodingStyle indicates how the data is encoded in the SOAP message. The use attribute
controls whether the data is encoded or appears literally within the SOAP message. namespace
defines the namespace for an RPC wrapper element. style determines whether the binding is for
an RPC or document-oriented message.
The value of the encodingStyle attribute is a URI. The URI

http://schemas.xmlsoap.org/soap/encoding/ is the only permitted value for SOAP 1.1
encoding.
For RPCs, the data in the SOAP message itself is contained within a wrapper element, whose name
is identical to that of the operation.
This is the declaration of the SOAP binding's invocation style. The rpc value indicates a Remote
Procedure Call, whereas document indicates document-style messaging.
If the value for use is encoded, then the value of the encodingStyle attribute dictates the
encoding. The other possible value is literal, which is used when the binding style is document.
Question
Which of these accurately describe the binding element?
Options:
1. Contains operation elements that are the same as those in the portType section
2. It specifies the transport protocol used for a web service
3. Its type attribute refers to a datatype defined in the types section
4. You can use more than one binding for a single portType
Answer
The binding element contains operation elements that are the same as those in the portType
section. It specifies the transport protocol used for a web service and you can use more than one
binding for a single portType.
Option 1 is correct. Each operation defined in the portType element must be referred to in the
binding element, using the same WSDL operation element.
Option 2 is correct. If you use

http://schemas.xmlsoap.org/soap/http
as the transport attribute in the binding element, you're indicating that the requester should send the
SOAP message over HTTP.
Option 3 is incorrect. The value of the type attribute refers to the portType that this binding is for.
Option 4 is correct. One or more binding elements can be associated with each portType.
Generally, however, most WSDL documents only contain one binding element.
2. Service and ports in a WSDL document

The service element of a WSDL document contains a set of related ports. Each port
specifies the actual endpoint of the web service – that is, it contains the URL at which the web
service is actually located.
This service element begins with a name attribute, CurrencyConverterService in this

case, which acts as a unique identifier for the service.
Although a WSDL document can contain several service elements, it's recommended that you
use only one for each document.
<soap:operation
<soap:body
</input>
<output name="convertAmountResponse">
<soap:body
</output>
</operation>
</binding>
<service name="CurrencyConverterService">
The documentation element can appear in any WSDL document section, and is used to
supply information about the document.
</binding>
<documentation>Currency Converter web service - US dollars to
Euros</documentation>
Every web service is a collection of ports related to the portType elements defined in the
WSDL document.
</binding>
<port binding="tns:CurrencyConverterSoapBinding" name="converter">
The port subelement and the address subelement contained within it are used to bind the
location of the web service to the portType. The port subelement appears as follows: <port
binding="tns:CurrencyConverterSoapBinding" name="converter"> <soap:address
location="http://imagenie/axis/services/converter"/>
 port
 soap:address
port
The port subelement contains a binding attribute, which refers to a binding element in the
same document.
In this case there is only one, CurrencyConverterSoapBinding. The reference in the service
section to this binding is namespace-qualified. The port subelement also contains a name
attribute, converter in this case.
soap:address
Because this service uses a SOAP binding, it contains an address subelement from the SOAP
namespace. This element takes one attribute, location, which identifies the URL of the web
service.
The service element is now complete, so you insert the appropriate closing tags.
This is also the last element in this WSDL document, so you insert the closing tag for the root
definitions element.
</binding>
<port binding="tns:CurrencyConverterSoapBinding" name="converter">
<soap:address
location="http://imagenie/axis/services/converter"/>
</port>
</service>
</definitions>
Question
Suppose you are defining a port subelement within the service element of a WSDL document.
The portType you want to use is called Multiply, whereas the binding for this portType is
called MultiplySoapBinding, both of which are defined in the current WSDL document.
Which of these pieces of code do you think you use for the opening tag of the port subelement?
Options:
1. <port binding="MultiplySoapBinding" name="Multiply">

2. <port binding="tns:MultiplySoapBinding" name="Multiply">
3. <port location="MultiplySoapBinding" name="Multiply">
4. <wsdlsoap:address="MultiplySoapBinding" name="Multiply">
Answer
The correct code is
<port binding="tns:MultiplySoapBinding" name="Multiply">.
Option 1 is incorrect. The reference to the binding is not qualified. It needs to use the tns prefix to
indicate that it refers to a binding in this document's namespace.
Option 2 is correct. This code correctly qualifies the reference to MultiplySoapBinding. The
binding element defines a concrete message format and a protocol for a portType element.
Option 3 is incorrect. The reference to the binding is missing the tns prefix and so is not qualified. It
also incorrectly uses the location attribute instead of the binding attribute.
Option 4 is incorrect. You should use the port element to identify the binding used - the SOAP
address element is a child element of port.
Summary
The binding element of a WSDL document defines a concrete message format and a protocol.
It takes two attributes, style and transport. Three binding protocols are defined in the
WSDL 1.1 specification – SOAP/HTTP, HTTP GET/POST, or SOAP with Multipurpose Internet
Mail Extensions (MIME) - and the child elements present within a specific binding element will
depend upon which protocol is used.
The service element of a WSDL document specifies the URL of the web service's endpoint. It
contains a port subelement that defines the port required for a web service. A port element
that uses SOAP has an address subelement, which takes one attribute, location, the value
of which is the actual location of the web service.
WS-ReliableMessaging
The WS-RM protocol defines and supports a number of Delivery Assurances. These are:
 AtLeastOnce - Each message will be delivered to the AD at least once. If a message

cannot be delivered, an error must be raised by the RMS and/or the RMD. Messages may
be delivered to the AD more than once (i.e. the AD may get duplicate messages).
 AtMostOnce - Each message will be delivered to the AD at most once. Messages may not
be delivered to the AD, but the AD will never get duplicate messages.
 ExactlyOnce - Each message will be delivered to the AD exactly once. If a message
cannot be delivered, an error must be raised by the RMS and/or the RMD. The AD will
never get duplicate messages.
 InOrder - Messages will be delivered from the RMD to the AD in the order that they are
sent from the AS to the RMS. This assurance can be combined with any of the above
assurances.
WS-Security
WS-Security describes three main mechanisms:
 How to sign SOAP messages to assure integrity. Signed messages also provide non-repudiation.
 How to encrypt SOAP messages to assure confidentiality.
 How to attach security tokens to ascertain the sender's identity.
WS-Addressing
WS-Addressing is a standardized way of including message routing data within SOAP headers.
Instead of relying on network-level transport to convey routing information, a message utilizing
WS-Addressing may contain its own dispatch metadata in a standardized SOAP header. The
network-level transport is only responsible for delivering that message to a dispatcher capable of
reading the WS-Addressing metadata. Once that message arrives at the dispatcher specified in
the URI, the job of the network-level transport is done.
WS-Coordination
The WS-Coordination specification defines a coordination framework that comprises the following
services:
 activation service
 registration service
 coordination service
activation service
The activation service starts a new activity and specifies the coordination protocols it employs. To do
this, it uses CreateCoordinationContext and CreateCoordinationContextResponse
messages. It can also be used to indicate relationships between new and existing activities.
registration service
The registration service registers the participants and specifies the protocol used for activity
coordination. It also specifies the transaction protocols and properties the web service supports. The
Registration phase consists of a Register message followed by a RegisterResponse message.
coordination service
The coordination service uses the selected coordination protocol to control the activity completion
processing for registered participants. In atomic transactions, the coordinator sends prepare, commit,
and rollback messages. The participant sends prepared and committed responses.
AXIS 2
Choosing a Client Generation Method

Axis2 gives you several options when it comes to mapping WSDL to objects when
generating clients. Three of these options are Axis2 DataBinding Framework, XMLBeans,
and JiBX databinding. All of these methods involve using databinding to create Java
objects out of the XML structures used by the service, and each has its pros and cons. You
can also generate XML in-out stubs that are not based on databinding.
Axis2 Databinding Framework (ADB): ADB is probably the simplest method of generating
an Axis2 client. In most cases, all of the pertinent classes are created as inner classes of a
main stub class. ADB is very easy to use, but it does have limitations. It is not meant to be
a full schema binding application, and has difficulty with structures such as XML Schema
element extensions and restrictions.
XMLBeans: Unlike ADB, XMLBeans is a fully functional schema compiler, so it doesn't carry
the same limitations as ADB. It is, however, a bit more complicated to use than ADB. It
generates a huge number of files, and the programming model, while being certainly
usable, is not as straightforward as ADB.
JiBX: JiBX is a complete databinding framework that actually provides not only WSDL-to-
Java conversion, as covered in this document, but also Java-to-XML conversion. In some
ways, JiBX provides the best of both worlds. JiBX is extremely flexible, enabling you to
choose the classes that represent your entities, but it can be complicated to set up. On
the other hand, once it is set up, actually using the generated code is as easy as using
ADB.
In the end, for simple structures, ADB will likely be enough for you. If, on the other hand
you need more power or flexibility, whether you choose XMLBeans or JiBX depends on
how much power or flexibility you need and your tolerance for complexity.
Starting Tomcat:
1. Set <<JRE_HOME>> to the directory of the JRE installation. (NO bin, lib required)
2. Set <<CATALINA_HOME>> to the directory of the tomcat installation. (NO bin, lib required)
3. Execute startup.bat from <<CATALINA_HOME>>/bin.
http://axis.apache.org/axis2/java/core/docs/quickstartguide.html
http://axis.apache.org/axis2/java/core/docs/reference.html#wsdl2code
set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_23
Take note that there are no double quotes or usage of %20%
D:\workshop\axis2-1.6.2\bin>wsdl2java -uri "D:\workshop\BuildService\wsdl\Area.wsdl" -ss -sd -g –or

-o "D:\workshop\BuildService" -p "com.cts.service"
Creating Service Archive
D:\workshop\BuildService>jar cvf AreaService.aar -C bin/ .

D:\workshop\BuildService\bin>%AXIS2_HOME%/bin/java2wsdl –cp . –cn
com.cts.concept.StockQuoteService

WS Notes

Uploaded by

Copyright:

Available Formats

You might also like

WS Notes

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WS Notes

Uploaded by

Copyright:

Available Formats

http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jst.ws.axis2.ui.doc.

1. SOAP message structure

The principal features of the SOAP specification include

Because SOAP is deliberately designed as a lightweight protocol, certain complex features

Match each component of a SOAP message to the role it plays.

A. Contains extra information outside of the message payload

A named edge is the equivalent of an XML element.

Each SOAP binding must support at least one MEP.

In SOAP 1.2, two MEP types are supported:

Which of these are involved in SOAP Response MEPs?

1. An initial non-SOAP message

Option 2 is incorrect. The Request-Response MEP involves an initial SOAP message.

Option 3 is incorrect. Neither MEP involves non-SOAP responses.

2. SOAP communication styles

Remote Procedure Call (RPC)-style messaging

RPC is a common mechanism for web service interaction.

The SOAP message payload contains a reference to the method to be invoked.

RPC-style messages can be synchronous or asynchronous.

RPC is suited to situations in which

 you want to make an existing component available as a web service

Document-style messages can be synchronous or asynchronous.

Which of these situations are well suited to document-style SOAP messaging?

Option 3 is incorrect. In RPC-style messaging, information such as parameters is encoded

3. SOAP transport bindings

The SOAP transport-protocol binding framework is designed to enable SOAP messages to be

For this reason, URIs are used to identify each binding.

Different bindings offer different levels of capability.

Which of these are characteristics of the SOAP 1.2 HTTP binding?

Option 2 is incorrect. The SOAPAction header is valid only in SOAP 1.1.

Option 4 is correct. The POST method is its default value.

Extending SOAP messages

You can use the message header in a SOAP envelope to

 extend the messaging structure

extend the messaging structure

Suppose you have a Header element with several entries.

In SOAP 1.2, the mustUnderstand attribute takes the following values:

You use SOAP intermediaries to provide value-added services, such as

 securing message exchanges

securing message exchanges

SOAP provides two types of intermediaries:

The special values of the role attribute are

The short name for this value is "none".

The short name for this value is "ultimateReceiver".

3. The SOAP Processing Model

 determining the roles that apply to it

determining the roles that apply to it

processing mandatory headers

Rank the steps involved in implementing the processing model.

A Generate faults, if necessary

B Determine the roles

C Process mandatory headers

D Relay the message

E Identify the mandatory headers

B Determine the roles

E Identify the mandatory headers

A Generate faults, if necessary

C Process mandatory headers