SW719 Topic 1

Technologies and Standards for Service-Oriented
Architecture Project Implementation

© copyright IBM Corporation 2005. All rights reserved.
Table of Contents
Web services standards
About this module 2
Introduction 3
What is the Web services stack? 4
What is a "standard"? 6
Key XML and Web services standards bodies (1 of 3) 7
IBM's role in developing XML and Web services standards 10
IBM: The leader in Web services standards development 11
IBM: Leadership in implementing Web services standards 12
IBM emerging technology and standards process 14
IBM development platform: Built upon standards 16
Web services standards and specifications 17
Web services and ebXML 19
Web services standards: Key standards 20
Messaging and encoding (1 of 3) 21
Description and discovery (1 of 4) 29
Tying together the base protocols 38
Web services standards: Quality of service (1 of 4) 39
Web services standards: Enterprise 49
Enterprise standards (1 of 7) 50
Web services standards: User experience 64
Web services standards: Interoperability (1 of 4) 67
Web services standards: Bringing Web services to Java and J2EE (1 of 5) 74
Emerging standards for Web services and J2EE (1 of 2) 83
Emerging standards for Web services and J2EE (2 of 2) 84
Summary 87
References 88
Test your knowledge 89
Technologies and Standards for Service-Oriented Architecture Project Implementation
Web services standards
Page 1
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
About this module

This module provides an overview of the key Web services standards and specifications. Many of the
initiatives discussed are in various stages of acceptance across the industry and within standards boards.
You will examine key standards and how they can be used to solve business and technical challenges
encountered when designing and implementing SOA. The level of detail provided regarding specific
standards will vary, depending upon the maturity and importance of the standard.
Objectives
Once you have completed this module, you should be able to:
■ Describe the Web services standards and how they support the principles of
service-oriented architecture
■ Describe the Web services Standards stack and explain the relative positioning of various
standards within this stack
■ Describe the various standard bodies engaged in the process of drafting Web services
standards
■ Describe IBM’s leadership role in XML and Web services standards
■ Describe common usage scenarios for the various Web services standards
■ Describe the basic Web services standards: SOAP, WSDL and UDDI
■ Describe standards in the area of messaging and encoding such as SOAP 1.2, MTOM,
ASAP, Ws-Addressing, WS-Notification and WS-Eventing
■ Learn standards in the area of description and discovery such as WSDL, WS-Policy and
WS-MetadataExchange
■ Describe standards that define and regulate quality of service for Web Service applications
such as WS-Security (and its related standards such as WS-SecurityPolicy, WS-Trust,
WS-Privacy, WS-SecureConversation, WS-Federation, WS-Authorization) and
WS-ReliableMessaging
■ Describe standards that enable Web services to be deployed at an enterprise level. These
include WS-Transactions, BPEL4WS, WSDM, WS-ResourceFramework
■ Recognize standards built on top of Web services, for example, grid, and standards that
bring together WS and grid such as WS-Resource Framework
■ Explain Web services interoperability: WS-I and interoperability profiles, areas strong in
interoperability, and challenges areas
■ State the relationship between SOA, WS, and the grid architecture and standards
■ Learn about the Java and J2EE 1.4 Web Services standards - JAX-RPC, JSR109, SAAJ
and JAX-R
■ Learn about emerging J2EE technologies related to Web services
■ Learn about SDO
Before completing this module

This module is written based on the assumption that you can describe the basic concepts in a
service-oriented architecture (SOA), including the motivation and benefits for using SOA in an enterprise.
You should be able to describe the concepts underlying the three basic Web service specifications:
SOAP, WSDL, and UDDI. You should also be familiar with core XML standards used in Web services,
such as XML schema and namespace.
After completing this module
When you have completed this module, you should move on to the next module, IBM software support for
SOA and Web services.
Page 2
Introduction
How Web services standards support the principles of service-oriented architectures
Although it is possible to build service-oriented architectures without using Web services and associated
standards, Web services can provide a number of benefits to developers and architects.
Web services leverage open standards, making the architecture more flexible and durable, and also
greatly improves interoperability, both across systems and partners. As a result, you can implement Web
services more quickly and at a lower cost. Use of Web services standards is a key enabler to designing
and building service-oriented architectures.
Page 3
What is the Web services stack?

Promoting the concept of open standards, the Web services stack arranges standards needed for the
enterprise adoption of SOA into discrete domains. The standards listed in the stack allow disparate
systems to communicate with each other without using proprietary libraries. By providing a set of open
standards encompassing all aspects of Web services, it eliminates code dependencies between the client
and server on all levels of the stack, in effect promoting SOA. Each layer in the stack extends or
composes the standards available at a lower layer; therefore additional protocols can be gradually
introduced, and organizations need only use the protocols necessary to describe their particular service.
For instance, Web services that do not need reliable message delivery need not provide such information
in their messages. Similarly, protocols to support increasingly complex patterns of behavior or support
emerging requirements can be added to the stack without affecting existing protocols.
Web services stack
Page 4
Page 5
What is a "standard"?
Proposed specifications, not recognized standards, fill many parts of the Web services stack. Current
practice is that various standards bodies declare whether a specification is final. However, some
standards bodies command greater respect from the industry than others, so their pronouncements are
more widely heeded. There are also "de facto" standards, where a published specification has been so
widely adopted that it becomes a standard over time. Finally, one or more companies publish
specifications as a method of gathering input to develop a standard, a first attempt at a standard or a de
facto standard.
The rate of adoption of a specification and its acceptance by various groups depends on factors beyond
the specification itself. The prestige of the submitters and the specification's relevance to other activities,
specifications, and standards in the same area all influence industry users, middleware vendors, and even
standards bodies. Sometimes, competing specifications emerge simultaneously, leading to confusion in
the marketplace.
IBM has been a major force in moving Web services specifications into acceptance as standards. The
company partners with Microsoft and other companies in the industry to promote wide adoption of
specifications. It also invests heavily in various standards bodies by participating in many of these groups.
The next section examines the various organizations that manage specifications as they evolve into
standards.
The following figure shows that Web services are based on open industry standard architecture. For
instance, Java/J2EE provides an industry standard language and platform for building portable service
implementation. XML is an industry standard for portable data definition and description. A variety of open
source initiatives (at various stages of maturity) exists to support Web service deployment (such as Linux
OS). In addition, mature industry and widely used standards are available for the Network infrastructure –
these provide a communication layer for Web services.
Web services are based on open, industry standard architecture
Page 6
Key XML and Web services standards bodies (1 of 3)

Organization for the Advancement of Structured Information Standards (OASIS)
OASIS is a not-for-profit global consortium that focuses on the development, convergence, and adoption
of e-business standards. Members themselves set the OASIS technical agenda, using a lightweight, open
process expressly designed to promote industry consensus and unite disparate efforts. OASIS produces
worldwide standards for security, Web services, XML conformance, business transactions, electronic
publishing, topic maps, and interoperability within and between marketplaces.
OASIS drives the development and adoption of Web services, security, e-business, and public sector and
application-specific standards: Electronic Business Extensible Markup Language (ebXML), UDDI, WSRP,
WS-Security, and others. Founded in 1993, OASIS has more than 3,000 participants from 600
organizations in 100 countries.
For more information, check the Web site: http://www.oasis-open.org .
World Wide Web Consortium (W3C)
The World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines,
software, and tools) to lead the Web to its full potential. W3C is a forum for information, commerce,
communication, and collective understanding.
The W3C covers HTML, HTTP, XML, SOAP, and others. It was founded in 1994 and includes 350
member organizations from around the world.
For more information, check the Web site: http://www.w3.org .
Java Community Process (JCP)
The JCP is an open organization of international Java developers and licensees whose charter is to
develop and revise Java technology specifications, reference implementations, and technology
compatibility kits. Both Java technology and the JCP were originally created by Sun Microsystems.
However, the JCP has evolved from the informal process that Sun used beginning in 1995 into a
formalized process overseen by representatives from many organizations across the Java community.
The JCP holds the responsibility for the development of Java technology. It primarily guides the
development and approval of Java technical specifications called Java specification requests (JSRs). JCP
is controlled by Sun, but it is open to everyone. IBM, BEA, Oracle, Novell, JBoss, America Online, Inc.
(AOL), Art Technology Group (ATG), Secure Association Service (SAS), Sybase, Borland, Macromedia,
and Hewlett Packard are among the many other contributors.
For more information, check the Web site: http://www.jcp.org .
The three standards bodies listed above are by far the best known for Web services. IBM participates
heavily in leading committees and submitting specifications across these organizations. Another industry
organization that is key for Web services standards and which IBM cofounded is the Web Services
Interoperability Organization (WS-I).
Page 7

Web Services Interoperability Organization (WS-I)
WS-I is an open industry organization chartered to promote Web services interoperability across
platforms, operating systems, and programming languages. It works across the industry and standards
organizations to respond to customer needs by providing guidance, best practices, and resources for
developing Web services solutions.
For more information, check the Web site: http://www.ws-i.org .
IBM also cofounded the organization UDDI.org, which developed the UDDI standard with wide
participation across industries.
For more information, check the Web site: http://www.uddi.org .
UDDI.org was first launched as a joint initiative by Microsoft, IBM, and Ariba in September 2000 to provide
a standard way to identify trading partners' Web services. The group recently submitted its third version
for review. Since UDDI's inception, a wide array of companies – including Microsoft, IBM, Sun
Microsystems, and BEA Systems – have built and sold products that support UDDI. It is one of several
XML-based standards for Web services, including WSDL and SOAP, which solution providers say will be
key to the broad adoption of Web services in the industry.
The UDDI.org work was turned over to an OASIS committee in the summer of 2002.
Page 8

Object Management Group (OMG)
OMG was formed in 1989 to create a component-based software marketplace by accelerating the
introduction of standardized object software. The group has approximately 800 members. Standards
include Model Driven Architecture, CORBA, IIOP, UML, XMI, MOF, Object Services, Internet Facilities,
and Domain Interface specifications.
For more information, check the Web site: http://www.omg.org .
Internet Engineering Task Force (IETF)
The Internet Engineering Task Force (IETF) is a large, open international community of network
designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture
and the smooth operation of the Internet. It is open to any interested individual.
Standards include IPv6, IPSEC, TCP, PKI X.509, LDAP, WebDAV, and other standards. ITEF has over
120 working groups.
For more information, check the Web site: http://www.ietf.org .
United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT)
The UN/CEFACT is a United Nations body that governs technical development in the areas of trade
development and e-business.
For more information, check the Web site: http://www.unece.org/cefact/ .
Global Grid Forum (GGF)
GGF promotes and supports the development implementation of grid technologies and applications by the
creation of "best practices" - technical specifications, user experiences, and implementation guidelines.
Grid is a system that is concerned with the integration, virtualization, and management of services and
resources in a distributed, heterogeneous environment that supports the collections of users and
resources (virtual organizations) across traditional administrative and organizational domains (real
organizations). Participants to the GGF come from 400 organizations in over 50 countries.
For more information, check the Web site: http://www.ggf.org .
International Organization for Standardization (ISO)
ISO is a network of the national standards institutes of 148 countries (one member per country).
Standards range from paper formats (like A4) to transportation, electronics, materials and construction,
quality management (ISO 9000) and environmental management. The world's largest developer of
standards, ISO is responsible for 14,251 standards as of 2003.
For more information, check the Web site: http://www.iso.org .
Page 9
IBM's role in developing XML and Web services standards

IBM support of open standards
IBM’s software strategy for middleware and tooling is based on open standards. IBM owes much of its
success in software over the past seven years to the company’s drive to encourage open standards. XML
and Web services standards fit with IBM’s support of Java, Linux, Eclipse, TCP, and others.
IBM is a key contributor in the areas of Linux, J2EE and Apache, Eclipse, and Web services. IBM donated
approximately $40 million (USD) for the initial technology initiative behind Eclipse; further, IBM is the
number one commercial investor in Linux to date.
IBM’s support of open standards
In the area of application servers and Web services, IBM has again led the way by contributing
approximately 80% of what is known as J2EE today and by helping to form the Apache Software
Foundation.
As Web services specifications are further examined, it will be obvious that IBM is very involved in the
creation of many of the key Web services standards in place today and continues to invest heavily in this
effort.
Page 10
IBM: The leader in Web services standards development

IBM is a leader in the new and evolving standards in the Web services space. The following lists the
leadership positions that IBM plays in the current Web services standards work.
Java community process contributions
■ Chair and submitter
a. JSR 74, Public Key Cryptography Standards 1.0

b. JSR 104, XML Trust Service APIs
c. JSR 105, XML Digital Signature APIs
d. JSR 106, XML Digital Encryption APIs
e. JSR 109, Implementing Enterprise Web Services
f. JSR 110, Java APIs for WSDL
g. JSR 183, Web Services Message Security APIs
■ Expert group member in many other JSRs
Open source contributions

■ WSIF, Xerces/Xalan, SOAP4J, WSIL4J to Apache, active contributor to many Apache
projects (for example, AXIS)
■ WSDL4J, WS-Transaction, WS-Coordination, BPWS4J, UDDI4J, Emerging Technologies
(Web services and grid) Toolkit to alphaWorks.ibm.com
W3C, OASIS and WS-I.org submissions

■ Author, XML Schema Primer
■ Chair, Web services Coordination Group
■ Chair, XML Protocol (SOAP) Working Group
■ Editor, Web Services Description Working Group
■ Cofounder, WS-I.org, developed test suite
■ Co-author, Web Services Architecture
■ Co-author, BPEL4WS specification
■ Co-author, WS-Coordination, WS-Transaction
■ Co-author, WSDL specification
■ Co-author, UDDI specification
■ Co-author, WS-Security specification
■ Co-author, WS-ReliableMessaging
■ Coordinating editor and voting member, OASIS Security Services Technical Committee
Page 11
IBM: Leadership in implementing Web services standards

W3C participation comparison
IBM is routinely first to ship new implementations of Web services specifications in WebSphere.
IBM has made significant investments in the Web services standards bodies such as W3C and OASIS.
IBM’s participation in the W3C and OASIS standards bodies is significant and places them in an industry
leader position. While IBM is a clear leader in the area of Web services standards, it should be noted that
Microsoft is also a significant player in the Web services standards space.
OASIS participation comparison
IBM works with Microsoft, as well as other vendors, to drive cross-platform and industry acceptance, along
Page 12
with speeding acceptance of the specifications. This benefits the industry as a whole. The cross-vendor
work also increases the possibility that the technologies will work together upon implementation. IBM
invests in these cross-vendor initiatives by means of dedicated project offices.
Page 13
IBM emerging technology and standards process

IBM has helped the standards process evolve over the last six years through work with Java, XML, and
Web services. The process begins with the innovative work of some of the industry’s top thought leaders
at IBM collaborating among them and with other industry leaders to determine the next evolution of
technologies and standards to be addressed. The outcome of this work is specifications and standards
that outline the next evolutionary steps. Technical previews are built around the standards and often made
available on alphaWorks for the development community to start working with, thus validating the
implementation and allowing for early adoption of the standards. For example, the Web services Toolkit
(WSTK) was made available on alphaWorks, along with the early versions of SOAP, WSDL, and UDDI.
This availability allowed early adopters to work with the technology before it was available in standard
product offerings.
IBM alphaWorks
The specifications and standards also benefit the open source initiatives. IBM often donates the work
products developed from specification and standards work or implementations from alphaWorks to the
open source community. Examples are donations to Apache and work underway with Eclipse.
Innovation, standardization and deployment
Page 14
Feedback and exploration done by means of the alphaWorks and the open source initiatives are then
used as input to the product development cycle, where the standards become integrated in the IBM
product set. The final step of the process is the use of the products in service engagements with
customers. It is important to note that the two-way feedback loop between the services engagements and
products, along with the connection between alphaWorks and the open source efforts, are critical to the
process of IBM delivering state-of-the-art products in an area that is evolving very quickly.
Page 15
IBM development platform: Built upon standards

The IBM development platform is built on widely used standards as indicated by the table below:
Standards Description
Eclipse Universal platform for integrating development tools (IBM contribution to
the industry)
SWT (Standard Widget Designed to provide efficient, portable access to the user interface of
Toolkit) the operating system on which it is implemented
EMF (Eclipse Modeling Used to define and implement structured data models
Framework)
UML (Unified Modeling IBM Rational influenced standard, at the core of the IBM Development
Language) Platform
XMI (XML metadata Interchange format for sharing objects using XML
Interchange)
The development platform supports the standards throughout the development suite:
Standards Support
Web Advanced HTML and JSP designer, site template tools, Web site
import, and more
Web services Supports wide spectrum of WS specifications, including WS-I, UDDI,
WS-Security
J2EE (Java 2 Enterprise Full support for the latest specification with ability to deploy to any major
Edition) J2EE runtime environment
BPEL (Business Process Model, simulate, design and debug business processes in WebSphere
Execution Language) Business Integration Modeler and WebSphere Studio Application
Developer Integration Edition (WebSphere Studio Application
Developer-IE)
SQL (Structured Query Schema design and generation, SQL builder wizards, and more
Language)
XML (Extensible Markup Tools for XML and XSL manipulation, XSLT debugger, editors, and
Language) XML and Java builders
Page 16
Web services standards and specifications

IBM has had some key ways of viewing Web services; the Web services stack diagram already shown
identifies the variety of Web services standards required for enterprise adoption of SOA. IBM views Web
services standards development to be in three phases. These phases are developed by providing a
foundation first, and then addressing the most critical problems facing the adoption of Web services. Web
services evolve by addressing such pain points while moving to adoption. Such pain points include:
■ Availability of mature, open industry standards that address quality of service capabilities
such as security and reliability and capabilities required for enterprise scale deployment of
Web service applications such as transactions, management, business process and
workflow management.
■ Availability of mature products that support such standards and are interoperable across
cross-vendor products while supporting ease of development and deployment.
As a result, not all aspects of a phase are developed at the same pace. Currently, emerging technologies
can be in Phase III of the evolutionary process while they may still also be involved in Phase I and Phase
II issues.
Evolution of standards within IBM
There is no standard definition of the Web services protocol stack, though the W3C organization has
formed a Web services architecture working group. Combining the protocol stack seen earlier and the
evolutionary pass, the current state of the standards can be represented by the diagram below. This
diagram is used throughout the remainder of this section as a reference in exploring the current state of
the Web services standards.
Web services standards and specifications
Page 17
First to be discussed are the foundation layers of the Web services protocol stack, then moving up to the
enterprise and user experience portions of the stack. You can see as you explore the Web services
specifications that make up the protocol stack that, moving up the stack, the specifications become less
mature. Toward the top of the stack, specifications are still emerging and often competing specifications
have been published. You can also see that as you proceed higher in the stack, the specifications depend
on the foundation defined by the specifications below them in the stack.
The degree of industry consensus on Web services protocols has been significant. Though alternative
proposals have been made in some areas, the formation of an appropriate working group in either W3C or
OASIS has usually resulted in the ability to develop a consensus.
However, there are currently alternative proposals, namely in the areas of reliable messaging,
orchestration, and most recently, coordination and transactions. The alternatives reflect an IBM/Microsoft
led initiative on one side, and another side led by Sun and Oracle. The W3C organization has developed a
WS-Choreography (orchestration) working group and OASIS has a Reliable Messaging Technical
Committee without IBM or Microsoft's participation. Subsequently, IBM, Microsoft, and their partners
formed the Web services Business Process Execution Language Technical Committee at OASIS to
further their BPEL4WS proposals as a direct alternative to W3C WS-Choreography.
Sun, Oracle, and others have also published the WS-Composite Application Framework as an alternative
to the WS-Coordination proposal from IBM, Microsoft, and BEA.
In general, the IBM-Microsoft proposals are more advanced than the alternatives and have broad support
from key industry leaders, including a number of companies such as SAP and TIBCO, who originally
backed WS-Choreography but have now also joined WS-BPEL. It is still early in the standardization
process for protocols in these areas, and it is anticipated that ultimately there will be convergence and
consensus as in the other areas. For example, WS-Choreography has now evolved to be complimentary
to BPEL, and recognizes it as one of the languages that could be used for choreography.
Page 18
Web services and ebXML

Whereas Electronic Data Interchange (EDI) for years has provided a usable but expensive way for
companies to exchange information in an automated manner, Electronic Business XML, or ebXML, now
provides a means for companies to integrate their processes much more easily. Based on XML, it
provides a methodology for business to determine what information they should exchange and how, as
well as a set of specifications to allow automation of the process. ebXML is a set of specifications that
together enable a modular electronic business framework. The vision of ebXML is to enable a global
electronic marketplace where enterprises of any size and in any geographical location can meet and
conduct business with each other through the exchange of XML-based messages. Or, in other words, the
hope is that ebXML can succeed EDI as the dominant, lower-cost means for companies to exchange
information.
The initiative to support ebXML is endorsed by hundreds of large companies, associations, and
government standards organizations worldwide.
Computer and technology companies are not the only entities that endorse ebXML; backers include a
large number of industrial, shipping, banking, and other general-interest companies. The direct sponsors
of ebXML are OASIS (Organization for the Advancement of Structured Information Standards) and
UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business). Many standards
bodies are involved, including NIST (National Institute of Standards and Technology) and W3C (World
Wide Web Consortium).
Some overlap has occurred between the Web services initiative and the ebXML initiative. ebXML uses
SOAP at the transport level, but has its own registry and orchestration. Though ebXML is an approved,
robust standard, its applicability is far narrower than Web services. As an evolution of EDI, it primarily
addresses B2B only. As such, the Web services protocols that are designed to address multiple
requirements will prove more valuable in time; ebXML, then, will probably evolve to adopt additional Web
service protocols as they mature and are approved. More recently, UN/CEFACT allows for either ebXML
or the whole of the Web services protocol stack to be used.
Protocol or Description Standards Initially Current Alternatives
initiative or proposed status
administrative
by
body
ebXML ebXML's mission is to OASIS, Harbinger, Open Various
provide an open UN/CEFACT IBM standard overlapping
XML-based infrastructure (some parts) WS
enabling the global use specifications
of electronic business
information in an
interoperable, secure and
consistent manner by all
parties. For more
information, check the
Web site:
http://www.ebxml.org/ .
Page 19
Web services standards: Key standards

The foundation
The base of the Web services protocol stack is the foundation standards. In this category are the base
specifications centered on the XML technologies that form the foundation for the other specifications in the
Web services stack. In this category are key standards such as:
■ XML (Extensible Markup Language)

■ JAXP (Java API for XML Parsing)
■ XML schema
A detailed exploration of these standards is outside the scope of this course. A base understanding of the
relevant XML standards is assumed.
Page 20
Messaging and encoding (1 of 3)

Messaging is a key concept in the Web services technologies. Services communicate by means of
messages, and thus the next layer of the protocol stack involves the messaging and encoding
technologies. Included in this group are the core technologies that J2EE developers already know such as
JMS, HTTP, and RMI/IIOP. The key specification in the messaging and encoding portion of the Web
services stack is SOAP.
Simple Object Access Protocol (SOAP)
What is SOAP?
Key to the Web services stack is SOAP, Simple Object Access Protocol. It is a lightweight protocol
intended for the exchange of structured information using XML. It defines a runtime message format for
service requests and responses. SOAP is independent of any particular transport and implementation
technology. Thus, it is important to understand that while SOAP is commonly used in preference to HTTP,
it is also a viable protocol to be used over any other protocol, for example JMS, in the Web services
protocol stack.
How does SOAP work?
SOAP messages are fundamentally one-way transmissions from a sender to a receiver. Remote
procedure call (RPC) can be simulated using two one-way messages:
■ One for the RPC request

■ One for the RPC response
Other communication patterns can be simulated as well, but SOAP only defines a convention for RPC.
The SOAP specification does not enforce anything about the "real" contents of the message as long as it
is valid XML.
■ Use of SOAP encoding is anticipated, but not required
a. The SOAP specification was finalized before the XML schema specification; as a result,
message encoding had to be addressed in the SOAP specification at that point in time.
The encoding spelled out on the SOAP specification, known as SOAP encoding, is not as
robust as the encodings defined by follow-on specifications such as JAX-RPC.
Consequently, the SOAP specification anticipates the use of SOAP encoding, but does
not require it.
■ There are strict rules for how the messages elements map to a method call.
■ As noted before, SOAP does not require HTTP, though the SOAP specification only
addresses SOAP over HTTP.
Finally, the SOAP model for message processing allows one or more intermediate nodes (intermediaries)
to process a message before the message reaches its final destination.
SOAP defines the message structure itself. It defines an "envelope" that wraps the message itself. Within
the envelope are one or more header elements and the body element that contains the application specific
data. The schema for the SOAP envelope is defined by the SOAP specification. The message is a
different vocabulary, and the information in the message is specific to the application sending or receiving
the message. As of this writing SOAP 1.2 has received W3C recommendation although most products
only support SOAP 1.1.
The following figure illustrates SOAP Envelope concept
Page 21
Message Transmission Optimization Mechanism (MTOM)

A SOAP message may need to be transmitted together with attachments of various sorts, ranging from
facsimile images of legal documents to engineering drawings. Such data are often in some binary format.
For example, most images on the Internet are transmitted using either GIF or JPEG data formats. The
SOAP Messages with Attachment (SW/A) specification specifies a standard way to associate a SOAP
message with one or more attachments in their native format in a multipart MIME (Multipurpose Internet
Mail Extensions) structure for transport. This standard is a W3C submission that is yet to be approved as
W3C recommendation. However SW/A is not supported by all Web service vendors. For instance,
Microsoft's .NET Web services engine does not support SW/A, so if you want to interoperate with .NET,
you must use some other alternative. An alternative standard SOAP Message Transmission Optimization
Mechanism (MTOM) has received W3C recommendation as of January 25 2005. This standard provides
an alternate way to transmit binary attachments with SOAP messages and, being a W3C
recommendation, stands a good chance of being supported by majority of Web Service vendors. With
respect to the business value, in SW/A, the binary data is carried outside the XML payload (via MIME
attachments). In MTOM, they are carried in a similar fashion; however, they are part of the SOAP infoset.
Therefore, it’s now possible to XML-validate the SOAP message (and gain the performance benefits of not
inlining the binary data). In addition, it’s also possible to secure the binary data since the data is logically
part of the XML infoset.
Asynchronous Service Access Protocol (ASAP)
As the SOAP specification has been refined and received industry acceptance, the Asynchronous Service
Access Protocol (ASAP) specification work has begun.
The purpose of the ASAP is to create a very simple extension of Simple Object Access Protocol (SOAP)
that enables generic asynchronous Web services or long-running Web services. The ASAP specification
was proposed by AmberPoint, Computer Associates, DataPower, Fujitsu, and iWay. It has since been
taken over by OASIS, and an OASIS technical committee is developing the draft of the standard.
Page 22

WS-Addressing
WS-Addressing helps enable organizations to build reliable and interoperable Web services applications
by defining a standard mechanism for identifying and exchanging Web services messages between
multiple endpoints. With a standard way to express where a message should be delivered in a Web
services network, developers are able to simplify Web services communication and development and
avoid the need to develop costly, ad hoc solutions that are often difficult to interoperate across platforms.
The joint submission of WS-Addressing represents a milestone in the collaboration among BEA, IBM,
Microsoft, SAP and Sun to further advance Web services technology and enable customers to build
interoperable Web services applications. Backed by significant industry support, the submission of
WS-Addressing is also a part of a longer-term effort to provide a standards-based foundation for the
development of secure, transacted, asynchronous, and reliable Web services.
WS-Addressing is a key part of the core Web services architecture. In particular, the specification is
designed to underlie other specifications, such as WS-ReliableMessaging, WS-Federation and
WS-AtomicTransaction, to provide a protocol-independent, common way to locate Web services in
support of features such as transactions, security, reliable message delivery, and identity federation.
WS-Addressing provides transport-neutral mechanisms to address Web services and messages.
Specifically, this specification defines XML elements to identify Web services endpoints and to secure
end-to-end endpoint identification in messages. This specification enables messaging systems to support
message transmission through networks that include processing nodes such as endpoint managers,
firewalls, and gateways in a transport-neutral manner.
WS-Addressing has been submitted to W3C. W3C has published working draft specifications in February
2005.
For further details see the developerWorks article found at
http://www.ibm.com/developerworks/webservices/library/ws-address.html
(001) <S:Envelope xmlns:S="http://www.w3.org/2002/12/soap-envelope"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
(002) <S:Header>
(003) <wsa:ReplyTo>
(004) <wsa:Address>http://business456.com/client1</wsa:Address>
(005) </wsa:ReplyTo>
(006) <wsa:To>http://fabrikam123.com/Purchasing</wsa:To>
(007) <wsa:Action>http://fabrikam123.com/SubmitPO</wsa:Action>
(008) </S:Header>
(009) <S:Body>
(010) ...
(011) </S:Body>
(012) </S:Envelope>
WS-Notification
Other specifications worthy of note in the messaging space are WS-Notification and WS-Eventing.
WS-Eventing was initiated by Microsoft, BEA, and TIBCO. Subsequently IBM and other vendors such as
SUN and CA have also joined in drafting the specification. WS-Notification was initiated by IBM, Akamai,
Hewlett Packard, SAP, Sonic Software, the Globus Alliance, and TIBCO. WS-Notification was submitted
to OASIS Web Services Notification (WSN) technical committee in April 2004. As of this writing this
technical committee is working on the draft of the standard.
The event-driven, or notification-based, interaction pattern is a commonly used pattern for inter-object
communications. Examples exist in many domains, for example, in publish/subscribe systems provided by
message-oriented middleware vendors, or in system and device management domains. This notification
pattern is increasingly being used in a Web services context.
Web Services Notification (WS Notification) is a family of related white papers and specifications that
define a standard Web services approach to notification using a topic-based publish/subscribe pattern. It
includes:
Page 23
■ Standard message exchanges to be implemented by service providers that wish to

participate in notifications
■ Standard message exchanges for a notification broker service provider (allowing publication
of messages from entities that are not themselves service providers)
■ Operational requirements expected of service providers and requesters that participate in
notifications
■ An XML model that describes topics
The Web Services Notification family of documents includes a white paper, "Publish-Subscribe Notification
for Web services", as well as three normative specifications: WS-BaseNotification,
WS-BrokeredNotification, and WS-Topics.
■ WS-BaseNotification defines the Web services interfaces for NotificationProducers and

NotificationConsumers. It includes standard message exchanges to be implemented by
service providers that wish to act in these roles, along with operational requirements
expected of them. This is the base specification on which the other WS-Notification
specification documents depend. An implementer interested simply in direct, point-to-point
notification needs only to read this WS-BaseNotification specification, together with the
"Publish-Subscribe Notification for Web services" white paper.
■ WS-BrokeredNotification defines the Web services interface for the NotificationBroker. A
NotificationBroker is an intermediary that, among other things, allows publication of
messages from entities that are not themselves service providers. It includes standard
message exchanges to be implemented by NotificationBroker service providers, along with
operational requirements expected of service providers and requesters that participate in
brokered notifications. This work relies upon WS-BaseNotification and WS-Topics, as well as
the "Publish-Subscribe Notification for Web services" document.
■ WS-Topics defines a mechanism to organize and categorize items of interest for
subscriptions known as "topics." These are used in conjunction with the notification
mechanisms defined in WS-BaseNotification. WS-Topics defines three topic expression
dialects that can be used as subscription expressions in subscribe-request messages and
other parts of the WS-Notification system. It further specifies an XML model for describing
metadata associated with topics. This specification should be read in conjunction with the
WS-BaseNotification specification and the "Publish-Subscribe Notification for Web services"
document.
WS-Eventing
Web Services Eventing, or WS-Eventing, defines how to support the simplest levels of Web services
interfaces for notification producers and consumers for a distributed event management system.
The WS-Eventing specification defines a baseline set of operations that allows Web services to provide
asynchronous notifications to interested parties. WS-Eventing defines the simplest level of Web services
interfaces for notification producers and notification consumers, including standard message exchanges to
be implemented by service providers that wish to act in these roles, along with operational requirements
expected of them.
Web services often want to receive messages when events occur in other services and applications. A
mechanism for registering interest is needed because the set of Web services interested in receiving such
messages is often unknown in advance or will change over time. This specification defines a protocol for
one Web service (called a "subscriber") to register interest (called a "subscription") with another Web
service (called an "event source") in receiving messages about events (called "notifications" or "event
messages"). The subscriber may manage the subscription by interacting with a Web service (called the
"subscription manager") designated by the event source.
To improve robustness, a subscription may be leased by an event source to a subscriber, and the
subscription expires over time. The subscription manager provides the ability for the subscriber to renew
or cancel the subscription before it expires.
There are many mechanisms by which event sources may deliver events to event sinks. This specification
provides an extensible way for subscribers to identify the delivery mechanism they prefer. While
Page 24
asynchronous pushed delivery is defined here, the intent is that there should be no limitation or restriction
on the delivery mechanisms capable of being supported by this specification.
WS-Eventing specification provides similar functionality to that of WS-BaseNotification. In comparison to
WS-Eventing, the WS-Notifications specifications provide a rich set of functions supporting
publish/subscribe required by robust, scalable enterprise applications including message brokering and
topic based subscription management. IBM joined the WS-Eventing author group to support the
interoperability requirements of customers by driving work to align the two specifications and reduce the
potential for overlap and incompatibilities. The new version of WS-Eventing includes improvements such
as the use of endpoint references in place of subscription ID to enhance interoperability, new delivery
modes that allow events to be pushed asynchronously, and the addition of extensibility points to allow the
possibility of adding other modes in the future.
Page 25

Encoding specifications summary
administrative
by
body
SOAP Simple Object Access W3C DevelopMentor,
V1.2
Protocol. Provides the IBM, recommendation
definition of the Microsoft,
XML-based information Lotus,
that can be used for UserLand
exchanging structured Software
and typed information
between peers in a
decentralized, distributed
environment. Part of
W3C XML Protocol
Group: See URL 1
below. MTOM enables
encoding of binary
attachment with SOAP
messages: See URL 2
below.
ASAP Asynchronous Service OASIS AmberPoint, OASIS
Access Protocol. The Computer technical
purpose of the ASAP Associates, committee
Technical Committee is DataPower, working on
to create a very simple Fujitsu, iWay the draft of
extension of SOAP that the standard.
enables generic
asynchronous Web
services or long-running
Web services. See URL
3 below.
WS-Addressing
This specification Submitted to BEA, Specification
enables messaging W3C. W3C Microsoft, published by
systems to support has IBM, TIBCO vendors.
message transmission in
a transport-neutral
manner through networks
that include processing
nodes such as endpoint
managers, firewalls, and
gateways. Previously
known as WS-Routing,
WS-Referral and SOAP
Routing Protocol
(SOAP-RP). See URL 4
below.
Page 26

administrative
by
body
published a W3C has
second published a
working second
draft. working
draft.
WS-Notification
Web Services Submitted to IBM, Specification
Notification, which OASIS. Akamai, HP, published by
includes the OASIS WSN SAP, Sonic vendors.
WS-BaseNotification, technical Software, theOASIS
WS-BrokeredNotification, committee is Globus standard is
and WS-Topics working on Alliance, yet to be
specifications, the TIBCO published.
implements the developing
Notification pattern, the standard.
where a service provider
or other entity initiates
messages based on a
subscription or
registration of interest
from a service requester.
It defines how the
publish/subscribe pattern
commonly used in
message-oriented
middleware products can
be realized using Web
services. This includes
brokered as well as direct
publish/subscribe, which
allows the
publisher/subscribers to
be decoupled and
provides greater
scalability. See URLs 5
and 6 below.
WS-EventingWS-Eventing describes Not yet Microsoft, Specification WS-Notification
how to construct an submitted BEA, TIBCO,published by
event-oriented message CA, IBM, vendors
exchange pattern using Sun, TIBCO
WS-Addressing
concepts, allowing Web
services to act as event
sources for subscribers.
It defines the operations
required to manage
subscriptions to event
sources, as well as how
the actual event
Page 27

administrative
by
body
messages are
constructed. See URLs 7
and 8 below.
1. http://www.w3.org/TR/2002/CR-soap12-part0-20021219/
2. http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/
3. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=asap
4. http://www.ibm.com/developerworks/webservices/library/ws-add/
5. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
6. http://www.ibm.com/developerworks/library/ws-resource/?ca=dgr-lnxw57WSN&WSRF
7. http://msdn.microsoft.com/webservices/understanding/specs/default.aspx?pull=/library/en-us/dnglobspec/html/ws-even
8. http://xml.coverpages.org/WS-Eventing200408.pdf
Page 28
Description and discovery (1 of 4)

Given that SOAP defines the protocol used for communicating between services, the next issue is
description and discovery of the services. The two key standards in the categories of description and
discovery are:
■ Web Services Description Language (WSDL) describes a Web service. It provides a

programmatic way to describe what a service does, paving the way for automation.
■ Universal Discovery, Description, Integration (UDDI) is a cross-industry initiative to
create a standard for service discovery together with a registry facility that facilitates the
publishing and discovery processes.
Page 29

Web services Description Language (WSDL)
WSDL is a description technology. Service description is the key to the interoperability of services. The
description serves as a recipe for automating the details involved in applications communication. The
notion of describing a service in a language-neutral standardized way is key to SOA.
The specification itself describes WSDL as an XML format for describing network services as a set of
endpoints operating on messages. The operations and messages are described abstractly, and then
bound to a concrete network protocol and message format.
WSDL describes two main features of the service:
Feature Description
Service interface definition The Service interface definition is an implementation-independent
description of the service.
Service implementation The Service implementation definition defines where the service is
definition located and how it should be invoked.
The key benefits WSDL provides are:
■ A simple, standardized way for service providers to describe the basic format of requests to
and any responses from their system
■ A "contract" between the client and server that is crucial to interoperability
WSDL document structure
Page 30
A WSDL document defines "services" as collections of network endpoints, or ports. In WSDL, the abstract
definition of endpoints and messages is separated from their concrete network deployment or data format
bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the
data being exchanged, and port types, which are abstract collections of operations. The concrete protocol
and data format specifications for a particular port type constitute a reusable binding. A "port" is defined by
associating a network address with a reusable binding, and a collection of ports define a service. Hence, a
WSDL document uses the following elements in the definition of network services:
Element Description
Types A container for data type definitions using some type system, such as
XML schema
Messages An abstract, typed definition of the data being communicated
Operation An abstract description of an action supported by the service
Port type An abstract set of operations supported by one or more endpoints
Binding A concrete protocol and data format specification for a particular port
type
Port A single endpoint defined as a combination of a binding and a network
Page 31
Element Description
address
Service A collection of related endpoints
XML schemas are used within WSDL for defining data types and structures within XML messages
exchanged with Web services.
Page 32

WS-Policy
The Web services Policy Framework (WS-Policy) provides a general purpose model and corresponding
syntax to describe and communicate the policies of a Web service. WS-Policy provides a flexible and
extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in
an XML Web services-based system. WS-Policy defines a framework and a model for the expression of
these properties as policies. Policy expressions allow for both simple declarative assertions as well as
more sophisticated conditional assertions.
WS-Policy defines a policy to be a collection of one or more policy assertions. Some assertions specify
traditional requirements and capabilities that will ultimately manifest on the wire (for example,
authentication scheme, and transport protocol selection). Some assertions specify requirements and
capabilities that have no wire manifestation yet are critical to proper service selection and usage (for
example, privacy policy, QoS characteristics). WS-Policy provides a single policy grammar to allow both
kinds of assertions to be reasoned about in a consistent manner.
WS-Policy stops short of specifying how policies are discovered or attached to a Web service. Other
specifications are free to define technology-specific mechanisms for associating policy with various
entities and resources. Subsequent specifications will provide profiles on WS-Policy usage within other
common Web services technologies.
The goal of WS-Policy is to provide the mechanisms needed to enable Web services applications to
specify policy information. Specifically, this specification defines the following:
■ An XML infoset called a policy expression that contains domain-specific, Web Service policy
information.
■ A core set of constructs to indicate how choices and combinations of domain-specific policy
assertions apply in a Web services environment.
WS-Policy is designed to work with the general Web services framework, including WSDL service
descriptions and UDDI service registrations.
WS-Policy will be fully extensible and will not place limits on the types of requirements and capabilities
that may be described; however, the specification will likely identify several basic service attributes
including privacy attributes, encoding formats, security token requirements, and supported algorithms.
This specification will define a generic SOAP policy format, which can support more than just security
policies. This specification will also define a mechanism for attaching or associating service policies with
SOAP messages.
WS-Policy has been further refined to include four documents:
■ A policy framework (WS-Policy) document that defines a grammar for expressing Web
services policies
■ A policy attachment (WS-PolicyAttachment) document that defines how to attach these
policies to Web services
■ A set of general policy assertions (WS-PolicyAssertions)
■ A set of security policy assertions (WS-SecurityPolicy)
The policy framework is designed to allow extensibility. "Policy" is a broad term that encompasses a range
of disciplines like security, reliability, transactions, privacy, and others. Similarly, the ability to express
policies is not limited to the expression of general policies or security policies. The intent is for the basic
policy framework to accommodate the expression of domain-specific policy languages in a way that
leverages different domain knowledge within a consistent Web services framework.
WS-PolicyAttachment offers several ways to advertise policy assertions with Web services. It builds on the
existing WSDL and UDDI specifications but also supports extensibility.
There will be domain-specific policies (for example, security policy) along with common policies for Web
services – a common example is a requesting service that may look for a service provider that offers
Page 33
processing in a particular human language (for example, German). The requesting service thus applies a
policy assertion, that is, the need for German language support. The provider could also make this
assertion by advertising that it can offer its service in German. The WS-Policy Assertions Language offers
this type of common policy expression. It defines a generic set of policy assertions for Web services.
To date, the WS-Policy specification, initiated by BEA, IBM, Microsoft, and SAP, VeriSign and Sonic
Software has been published but has not been submitted to a standards organization.
WS-MetadataExchange
The previous section described how Web services use metadata to describe what other endpoints need to
know to interact with them. Specifically, WS-Policy describes the capabilities, requirements, and general
characteristics of Web services; WSDL describes abstract message operations, concrete network
protocols, and endpoint addresses used by Web services; XML schema describes the structure and
contents of XML-based messages received and sent by Web services.
In order to interact with the Web service, a mechanism is required to retrieve these types of metadata.
WS-MetadataExchange specification defines three request/response message pairs to retrieve these
three types of metadata: one retrieves the WS-Policy associated with the receiving endpoint or with a
given target namespace, another retrieves either the WSDL associated with the receiving endpoint or with
a given target namespace, and a third retrieves the XML schema with a given target namespace.
Together these messages allow efficient, incremental retrieval of a Web service’s metadata.
WS-MetadataExchange specification has been developed by IBM, Microsoft, SAP, CA, Sun, BEA and
webMethods. The specification was published in March 2004 and updated in September 2004.
Description specifications summary
administrative
by
body
WSDL Web services Description W3C Ariba, IBM, V2.0 working
Language (WSDL) Microsoft draft
provides a model and an
XML format for
describing Web services.
WSDL enables one to
separate the description
of the abstract
functionality offered by a
service from concrete
details of a service
description such as
"how" and "where" that
functionality is offered.
See URL 1 below.
WS-Policy Provides a Not yet BEA, IBM, Originally
general-purpose model submitted Microsoft, published as
and corresponding SAP, joint IBM,
syntax to describe and VeriSign, BEA, SAP,
communicate the policies Sonic and
of a Web service. See
URLs 2 and 3 below.
Page 34

administrative
by
body
Software Microsoft
specification
in May 2003.
Recently
updated in
September
2004.
WS-MetadataExchange
A set of Web service Not yet IBM, Specification
mechanisms to exchangesubmitted Microsoft, published
policies, WSDL, and SAP,CA, March 2004
potentially other Sun, BEA and updated
metadata among two or and September
more parties. See URL 4 webMethods 2004.
below.
1. http://www.w3.org/2002/ws/desc/
2. http://msdn.microsoft.com/ws/2002/12/Policy/
3. http://www.ibm.com/developerworks/library/specification/ws-polfram/
4. http://www.software.ibm.com/software/developer/library/
Page 35

Universal Discovery, Description, Integration (UDDI)
A registry allows organizations to publish and discover Web services. Currently, two registry standards
dominate: UDDI (Universal Description, Discovery, and Integration) and ebXML. With either of these,
businesses can publish a set of Web services so their internal or external business partners can discover
them. However, integrating Web services' discovery and registration regardless of the supported registry
standard can prove challenging for businesses.
Note : ebXML is being superseded over time with the relevant Web services specifications.
The purpose of UDDI is to facilitate service discovery, both at design time and at run time. UDDI is:
■ A platform-independent framework for describing services, discovering businesses, and

integrating business services using the Internet
■ A directory for storing information about Web services
■ A support for many types of service descriptions
■ A means to enable establishment of a potential relationship between a service provider and
a service requester
UDDI makes use of the lower level protocols such as SOAP, XML, and base Internet protocols.
administrative
by
body
UDDI Universal Description, OASIS Ariba, IBM, V2 - OASIS ebXML
Discovery, and Microsoft Standard, V3 registry
Integration defines a - OASIS service
SOAP-based Web Committee
service for locating draft
WSDL-formatted protocol
descriptions of Web
services. UDDI provides
a foundation for
developers and
administrators to readily
share information about
internal Web services
across the enterprise and
public Web services
across the Internet. See
URL 1 below.
ebXML Electronic Business XML OASIS, Harbinger, Open Various
(ebXML) has as its
mission providing an
open, XML-based
infrastructure enabling
the global use of
electronic business
information in an
interoperable, secure,
and consistent manner
by all parties. See URL 2
below.
Page 36

administrative
by
body
UN/CEFACT IBM standard overlapping
(some parts) WS
specifications
1. http://www.uddi.org
2. http://www.ebxml.org/
Page 37
Tying together the base protocols

SOAP, WSDL, and UDDI are the base protocols that formed the initial specification for Web services.
They have effectively become the industry standards with universal acceptance and widespread
implementation by vendors. The following diagram depicts the interaction of these standards as they form
the base of the Web services protocol stack.
SOAP, WSDL and UDDI provide foundation for Web services stack
Page 38
Web services standards: Quality of service (1 of 4)

Having laid the foundation of the Web services protocol stack, the next issue of concern is quality of
service. In the quality of service portion of the Web services protocol stack, there are two key
specifications:
■ WS-Security
■ WS-ReliableMessaging
Page 39

WS-Security
Security is key to describing quality of service for Web services. The area of security and Web services
encompasses many specifications building on the foundation on SOAP messaging. A significant amount
of work has gone into the Web services security standards. A complete analysis of all the WS-Security
specifications is out of the scope of this course. Many of the specifications in the roadmap have been
published, and several will go into products soon.
Web services security stack
WS-Security describes enhancements to SOAP messaging that provide quality of protection through
message integrity, message confidentiality, and single message authentication. WS-Security defines a set
of SOAP extensions that can be used to accommodate a wide variety of security models and encryption
technologies. The specification defines a model for storing security metadata into the SOAP message
header. The goal of WS-Security is to enable applications to construct secure SOAP message exchanges.
This specification is intended to provide a flexible set of mechanisms that can be used to construct a
range of security protocols; in other words, this specification intentionally does not describe explicit fixed
security protocols. WS-Security provides a general-purpose mechanism for associating security tokens
with messages. No specific type of security token is required by WS-Security. It is designed to be
extensible (that is, to support multiple security token formats). Specifically, WS-Security provides support
for multiple security tokens, multiple trust domains, multiple signature formats, and multiple encryption
technologies. The token formats and semantics for using these are defined in the associated profile
documents.
The WS-Security Username Token Profile describes how to use the UsernameToken with the
WS-Security specification. More specifically, it describes how a Web service consumer can supply a
UsernameToken as a means of identifying the requester by “username”, and optionally using a password
(or shared secret, or password equivalent) to authenticate that identity to the Web service producer.
The WS-Security X.509 Certificate Token Profile specification describes the use of the X.509
authentication framework with the WS-Security specification. An X.509 certificate specifies a binding
between a public key and a set of attributes that includes (at least) a subject name, issuer name, serial
number, and validity interval. This binding may be subject to subsequent revocation advertised by
mechanisms that include issuance of CRLs, OCSP tokens, or mechanisms that are outside the X.509
framework, such as XKMS. An X.509 certificate may be used to validate a public key that may be used to
authenticate a SOAP message or to identify the public key with SOAP message that has been encrypted.
Additionally, WS-Security describes how to encode binary security tokens. Specifically, the specification
describes how to encode X.509 certificates and Kerberos tickets as well as how to include opaque
encrypted keys. It also includes extensibility mechanisms that can be used to further describe the
Page 40
characteristics of the credentials that are included with a message.

WS-Security was initially submitted by IBM, Microsoft, and VeriSign and is now an OASIS standard.
Also included in the category of Web services security specifications are many other specifications.
Initial specifications
■ WS-Security describes how to attach signature and encryption headers to SOAP
messages. In addition, it describes how to attach security tokens to messages. WS-Security
profile documents such as WS-Security Username Token Profile and WS-Security X.509
Certificate describe the use of Username Token and X.509 Certificate token with
WS-Security.
■ WS-Policy will describe the capabilities and constraints of the security (and other business)
policies on intermediaries and endpoints (for example, required security tokens, supported
encryption algorithms, and privacy rules).
■ WS-Trust will describe a framework for trust models that enables Web services to securely
interoperate.
■ WS-Privacy will describe a model for how Web services and requesters state privacy
preferences and organizational privacy practice statements.
Follow-on specifications
■ WS-SecureConversation will describe how to manage and authenticate message
exchanges between parties, including security context exchange and establishing and
deriving session keys.
■ WS-Federation will describe how to manage and broker the trust relationships in a
heterogeneous federated environment, including support for federated identities.
■ WS-Authorization will describe how to manage authorization data and authorization
policies.
WS-Policy
The WS-Policy specification can be extended to describe security requirements. Policy is a broad term
and encompasses a range of disciplines like security, reliability, transactions, privacy, and so forth.
Similarly, the ability to express policies is not limited to the expression of general policies or security
policies. The intent is for the basic policy framework to accommodate the expression of domain specific
policy languages in a way that leverages different domain knowledge within a consistent Web services
framework. WS-SecurityPolicy represents an extension of WS-Policy framework for the security domain.
It proposes a language to express security related policies and assertions that could be communicated
using WS-Security.
WS-Trust
In the Web services paradigm, the trust between a service requester and a service provider is established
through the exchange of information between the two parties in an expected and understood manner. The
WS-Security specification already defines the basic mechanisms to securely exchange messages using
security tokens. The WS-Trust specification builds on this model by defining how such security tokens are
issued and exchanged.
WS-Trust starts the work of defining trust relationships by defining a set of interfaces that a secure token
service may provide for the issuance, exchange, and validation of security tokens. It is designed to
support the creation of multiple security token formats to accommodate a variety of authentication and
authorization mechanisms. An issuing security token service takes an input request and typically proof of
identity and responds with a token that the named identity has requested (that is, a particular business
certification).
The description of this expected behavior within the security space can also be expressed as a "trust
policy" and the WS-Policy framework supports trust partners expressing and exchanging their statements
of trust.
WS-Trust will describe the model for establishing both direct and brokered trust relationships (including
Page 41
third parties and intermediaries).

This specification will describe how existing direct trust relationships may be used as the basis for
brokering trust through the creation of security token issuance services. These security token issuance
services build on WS-Security to transfer the requisite security tokens in a manner that ensures the
integrity and confidentiality of those tokens.
This specification then will describe how several existing trust mechanisms may be used in conjunction
with this trust model.
Finally, the trust model will explicitly allow for, but will not mandate, delegation and impersonation by
principals. Note that delegation is consistent with impersonation, but provides additional levels of
traceability.
WS-Privacy
Organizations creating, managing, and using Web services often need to state their privacy policies and
require that incoming requests make claims about the senders' adherence to these policies.
By using a combination of WS-Policy, WS-Security, and WS-Trust, organizations can state and indicate
conformance to stated privacy policies. This specification will describe a model for how a privacy language
may be embedded into WS-Policy descriptions and how WS-Security may be used to associate privacy
claims with a message. Finally, this specification will describe how WS-Trust mechanisms can be used to
evaluate these privacy claims for both user preferences and organizational practice claims.
WS-SecureConversation
WS-SecureConversation builds on this concept of trust based on security tokens. It describes how
security tokens can be used within the context of policy-defined trust relationships to allow multiple service
requesters and service providers to securely exchange information over the duration of a conversation.
While WS-Trust defines the behavior of overall trust relationships, WS-SecureConversation focuses on
defining a security context (security token) for secure communications.
WS-SecureConversation will describe how a Web service can authenticate requester messages, how
requesters can authenticate services, and how to establish mutually authenticated security contexts.
This specification will describe how to establish session keys, derived keys, and per-message keys.
Finally, this specification will describe how a service can securely exchange context (collections of claims
about security attributes and related data). In order to accomplish this, the specification will describe and
build upon the concepts of security token issuance and exchange mechanisms defined in WS-Security
and WS-Trust. Using these mechanisms, a service might, for example, support security tokens using
weak symmetric key technology as well as issue stronger security tokens using non-shared (asymmetric)
keys.
WS-SecureConversation is designed to operate at the SOAP message layer so that the messages may
traverse a variety of transports and intermediaries. This does not preclude its use within other messaging
frameworks. In order to further increase the security of the systems, transport-level security may be used
in conjunction with both WS-Security and WS-SecureConversation across selected links.
WS-Federation
This specification will define how to construct federated trust scenarios using the WS-Security, WS-Policy,
WS-Trust, and WS-SecureConversation specifications. For example, it will describe how to federate
Kerberos and PKI infrastructures (as described in the scenarios below).
A trust policy is also introduced to indicate, constrain, and identify the type of trust that is being brokered.
This specification also defines mechanisms for managing the trust relationships.
WS-Authorization
This specification will describe how access policies for a Web service are specified and managed. In
particular, it will describe how claims may be specified within security tokens and how these claims will be
interpreted at the endpoint.
This specification will be designed to be flexible and extensible with respect to both authorization format
Page 42
and authorization language. This enables the widest range of scenarios and ensures the long-term
viability of the security framework.
Page 43

Equally as important as ensuring the security of a message is ensuring that messages are delivered.
Reliability, then, is extremely important. Consider the scenario where messages exchanged between the
distributor and supplier travel over multiple nodes, some on the public Internet. This means that some
messages may be lost in transit. Additionally, it is possible that either the supplier's or the distributor's
system may fail while a message is in transit, leaving the still-running system in a state of confusion as to
whether a given message has been processed or not. The goal of reliable messaging in Web services is
to allow applications to send and receive messages simply, reliably and efficiently even in the face of
application, platform or network failure. The WS-ReliableMessaging specification published by BEA, IBM,
Microsoft and TIBCO defines a protocol and a set of mechanisms that allow developers of Web services
to ensure that messages are delivered reliably between two endpoints, and supports a broad spectrum of
delivery assurance and robustness characteristics. The protocol defined in this specification depends
upon other Web services specifications for the identification of service endpoint addresses and policies.
The basic model of WS-ReliableMessaging is fairly simple to understand. Under WS-ReliableMessaging,
the source node sends a normal Web service message containing a WS-ReliableMessaging header.
Upon receipt of the message, the destination node sends an acknowledgement message back to the
source indicating that the message was successfully delivered. The following figure illustrates this model.
In this figure, the application source sends a message for reliable delivery. The Reliable Messaging (RM)
source accepts the message and transmits it one or more times. After receiving the message, the RM
destination acknowledges the message. Finally the RM destination delivers the message to the
application destination. The application source represents the endpoint that sends the message. The RM
source is the endpoint that transmits the message. The RM destination is the endpoint that receives the
message. The application destination is the endpoint to which the message is delivered.
Reliable messaging model
WS-ReliableMessaging takes advantage of the algorithms used in reliable messaging and transaction
protocols. Specifically, WS-ReliableMessaging provides a flexible acknowledgement scheme in which
receivers can efficiently convey the range of messages that have (and have not) been received.
WS-ReliableMessaging also provides an efficient ordering mechanism to ensure that receivers can
process messages in the same order in which they were sent, even in the face of reordering due to
retransmissions or multipath routing.
WS-ReliableMessaging was designed to compose with the existing Web service infrastructure. In
particular, WS-ReliableMessaging is meant to layer on existing application protocols and interfaces
described in WSDL and XML schema. This means that the distributor and supplier do not need to
redesign their application-level message schemas or exchange patterns. The applications'
implementations use the WSDL and XML schema that define the business interfaces of the services. The
infrastructure software providing the Web services protocols compose the reliable messaging functions
Page 44
with the Web services protocols.

WS-ReliableMessaging is not bound to underlying transport protocols or sessions. This means that the
lifetime of a WS-ReliableMessaging conversation can span long periods of time (days, weeks) even when
one or both systems are rebooted. This allows conversations to be suspended midstream (for example, to
allow system maintenance) and then resumed without needing to retransmit the entire conversation.
The WS-ReliableMessaging specification was initially published in March 2004 by IBM, Microsoft, BEA
and TIBCO. An updated version of this specification was released in February 2005. In the latest version,
WS-ReliableMessaging is published as two separate specifications: one for the core protocol elements
and one for the related policy assertion. The new Web Services Reliable Messaging Policy Assertion
(WS-RM Policy) specification refactors the Reliable Messaging policy assertion into a discrete
specification. The Web Services Reliable Messaging Policy Assertion (WS-RM Policy) specification
describes a domain-specific policy assertion for WS-ReliableMessaging that that can be specified within a
policy alternative as defined in WS-Policy Framework .
The architecture of WS-ReliableMessaging supports composition with other messaging and Web service
specifications and standards. In order to deliver the quality of service required, WS-ReliableMessaging
relies on several other specifications. The reliable messaging area of the Web services stack consists of
the following specifications. Those specifications that are listed below but not covered in the course so far
are described in detail later in this course.
Specification Description
WS-ReliableMessaging A protocol that allows messages to be delivered reliably between
distributed applications in the presence of software component, system,
or network failures
WS-Addressing A framework to identify Web service endpoints and to ensure
end-to-end endpoint identification in messages
WSDL A set of constructs to specify Web service interfaces and bindings for
endpoints
WS-Policy A base set of constructs that can be used and extended by other Web
services specifications to describe a broad range of requirements,
preferences, and capabilities of service interfaces
WS-Transactions, A set of Web service interface definitions and protocols that support
WS-Coordination participant control and agreement on the outcome of distributed,
multi-party interactions
WS-MetadataExchange A set of Web service mechanisms to exchange policies, WSDL, and
potentially other metadata among two or more parties
WS-Security Web service security that supports, integrates, and unifies several
popular security models, mechanisms, and technologies
WS-Reliability
Also to be watched in this space is the specification work currently under OASIS called WS-Reliability.
WS-Reliability covers much of the same ground as WS-Reliable Messaging such as defining a
specification for open, reliable Web services messaging, including guaranteed delivery, duplicate
message elimination and message ordering, and enabling reliable communication between Web services.
WS-Reliability version 1.1 is now an OASIS standard. The WS-Reliability specification has been
produced by members of the OASIS Web Services Reliable Messaging (WSRM) Technical Committee.
OASIS Sponsor Member companies supporting development of the WSRM specification include Booz
Allen Hamilton, Cyclone Commerce, Fujitsu, Hewlett-Packard, Hitachi, NEC Corporation, Novell, Oracle,
SeeBeyond Technology Corporation, and Sun Microsystems.
WS-Reliability provides a method to guarantee message delivery over the Internet, enabling companies
to conduct reliable business-to-business trading or collaboration using Web services. It defines a
SOAP-based protocol for exchanging SOAP messages with guaranteed delivery, no duplicates, and
guaranteed message ordering. WS-Reliability is defined as SOAP header extensions and is independent
of the underlying protocol, but the specification also provides a binding to HTTP. This model enables a
sender (that is, a SOAP node with reliable messaging functions for sending) to send a message to a
Page 45
receiver (that is, a SOAP node with reliable messaging functions for receiving) that can accept an
incoming connection.
WS-Reliability defines reliability in the context of current Web services standards and is designed for use
in combination with other complementary protocols. It builds upon previous development experiences, for
example, the ebXML Message Service Specification (ebMS). WS-Reliability also defines how to use
reliability in compliance with WS-I Basic Profile 1.1.
Page 46

Quality of service specifications summary
administrative
by
body
WS-Security Describes enhancements OASIS IBM OASIS
to SOAP messaging to standard Microsoft, standard
provide quality of VeriSign
protection through
message integrity,
message confidentiality,
and single message
authentication. See WS
Security Services. See
URL 1 below.
WS-Policy Provides a Not yet BEA, IBM, Specification
general-purpose model submitted Microsoft, published
and corresponding SAP
syntax to describe and
communicate the policies
of a Web service. See
URL 2 below.
WS-Trust Defines extensions that Not yet IBM, Specification
build on WS-Security to submitted Microsoft, published
request and issue RSA,
security tokens and to VeriSign
manage trust
relationships. See URL 3
below.
Describes a protocol that Not yet BEA, IBM, Specification WS-Reliability
allows messages to be submitted Microsoft, published in
delivered reliably TIBCO March 2004.
between distributed An updated
applications in the version
presence of software released in
component, system, or February
network failures. See 2005 that
URL 4 below. includes
WS-RM
Policy
specification.
WS-ReliabilitySpecification for open, OASIS Oracle, Sun V1.1 WS-ReliableMessaging
reliable Web services and other released in
messaging including vendors November
guaranteed delivery, 2004
duplicate message
elimination and message
ordering, enabling
reliable communication
between Web services.
Page 47

administrative
by
body
See URL 5 below.
1. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
2. http://www.ibm.com/developerworks/webservices/library/ws-polfram/
3. http://www.ibm.com/developerworks/webservices/library/ws-trust/
4. http://www.ibm.com/developerworks/webservices/library/ws-rm/
5. http://developers.sun.com/techtopics/webservices/ws-reliability.v1.0.pdf
Page 48
Web services standards: Enterprise

Systems integration requires more than the ability to conduct simple interactions by using standard
protocols. The full potential of Web services as an integration platform will be achieved only when
applications and business processes are able to integrate their complex interactions by using a standard
process integration model.
The interaction model that is directly supported by WSDL is essentially a stateless model of synchronous
or uncorrelated asynchronous interactions. Models for business interactions typically assume sequences
of peer-to-peer message exchanges, both synchronous and asynchronous, within stateful, long-running
interactions involving two or more parties. To define such business interactions, a formal description of the
message exchange protocols used by business processes in their interactions is needed. The definition of
such business protocols involves precisely specifying the mutually visible message exchange behavior of
each of the parties involved in the protocol, without revealing their internal implementation.
Separating public and private aspects of business process behavior
There are two good reasons to separate the public aspects of business process behavior from internal or
private aspects:
■ First, businesses do not want to reveal all their internal decision-making and data
management to their business partners.
■ Second, even when the first reason is not applicable, separating public from private process
provides the freedom to change private aspects of the process implementation without
affecting the public business protocol.
Business protocols must be clearly described in a platform-independent manner and capture all behavioral
aspects that have cross-enterprise business significance. Each participant can then understand and plan
for conformance to the business protocol without engaging in the process of human agreement that adds
so much to the difficulty of establishing cross-enterprise automated business processes today.
Page 49
Enterprise standards (1 of 7)
As the foundation grows in the Web services protocol, stack specifications are evolving to support the
enterprise nature of Web services. To realize the enterprise nature of Web services, specifications are
needed around transactions and management, along with business processes. Web services increasingly
tie together a number of participants, forming large, distributed applications. The resulting activities may
have complex structure and relationships. As a result, several specifications become important in
expressing the enterprise nature of Web services applications. Of importance are:
■ WS-Transactions
■ BPEL4WS
■ WSDM
■ WS-Resource Frameworks
In addition standards in the area of applying Web services to grid computing are emerging. The following
is an overview of each of them.
Page 50
WS-Transactions
WS-Transactions was originally published as a joint IBM, BEA, and Microsoft specification in August 2002.
It was superseded by two joint IBM, BEA, Microsoft specifications, WS-AtomicTransactions in September
2003 and WS-BusinessActivity in January 2004. WS-Transactions are thus a family of specifications
including:
■ WS-Coordination – provides a pluggable coordination framework supporting

WS-AtomicTransactions and WS-BusinessActivity
■ WS-AtomicTransaction – provides a two-phase commit protocol that can be plugged into
WS-Coordination
■ WS-BusinessActivity – provides a protocol that can be plugged into WS-Coordination to
implement long running, compensation based transaction protocols
WS-Coordination
This specification describes an extensible framework for providing protocols that coordinate the actions of
distributed applications. Such coordination protocols are used to support a number of applications,
including those that need to reach consistent agreement on the outcome of distributed activities.
The framework defined in this specification enables an application service to create a context needed to
propagate an activity to other services and to register for coordination protocols. To establish the
necessary relationships among participants, messages exchanged among participants carry a
CoordinationContext. The CoordinationContext includes a Registration Service Endpoint Reference of a
Coordination service. Participants use that registration service to register for one or more of the protocols
supported by that activity.
The framework enables existing transaction processing, workflow, and other systems for coordination to
hide their proprietary protocols and to operate in a heterogeneous environment.
WS-AtomicTransaction
This specification provides the definition of the atomic transaction coordination type that is to be used with
the extensible coordination framework described in the WS-Coordination specification. The specification
defines three specific agreement coordination protocols for the atomic transaction coordination type:
completion, volatile two-phase commit, and durable two-phase commit. Developers can use any or all of
these protocols when building applications that require consistent agreement on the outcome of
short-lived distributed activities that have the all-or-nothing property.
Atomic transactions commonly require a high level of trust between participants and are short in duration.
The Atomic Transaction specification defines protocols that enable existing transaction processing
systems to wrap their proprietary protocols and interoperate across different hardware and software
vendors. WS-AtomicTransaction includes support for volatile and durable versions of 2PC (two-phase
commit). In the case of durable 2PC, the actions taken prior to commit are only tentative (that is, they are
neither persistent nor visible to other activities). When an application finishes, it requests the coordinator
to determine the outcome for the transaction. The coordinator determines if there were any processing
failures by asking the participants to vote. If the participants all vote that they were able to execute
successfully, the coordinator commits all actions taken. If a participant votes that it needs to abort or a
participant does not respond at all, the coordinator aborts all actions taken. Commit makes the tentative
actions visible to other transactions. Abort makes the tentative actions appear as if the actions never
happened. In the case of volatile 2PC, some of the participants might be managing volatile resources such
as in-memory cache – such participants will register for volatile 2PC. All participants registered for volatile
2PC must respond before a prepare is issued to participants registered for durable 2PC. A volatile
participant is not guaranteed to receive notification of transaction’s outcome. Atomic transactions have
proven to be extremely valuable for many applications. They provide consistent failure and recovery
semantics, so the applications no longer need to deal with the mechanics of determining a mutually
agreed outcome decision or to figure out how to recover from a large number of possible inconsistent
states.
By using the SOAP and WSDL extensibility model, SOAP-based and WSDL-based specifications are
designed to work together to define a rich Web services environment. As such, WS-AtomicTransaction
Page 51
alone does not define all features required for a complete solution. WS-AtomicTransaction is a building
block used with other specifications of Web services (for example, WS-Coordination, WS-Security) and
application-specific protocols that are able to accommodate a wide variety of coordination protocols
related to the coordination actions of distributed applications.
WS-BusinessActivity
This specification provides the definition of the business activity coordination type that is to be used with
the extensible coordination framework described in the WS-Coordination specification. The specification
defines two specific agreement coordination protocols for the business activity coordination type:
BusinessAgreementWithParticipantCompletion and BusinessAgreementWithCoordinatorCompletion.
Developers can use any or all of these protocols when building applications that require consistent
agreement on the outcome of long-running distributed activities.
The current set of Web services specifications, WSDL and SOAP, define protocols for Web service
interoperability. Web services increasingly will tie together a number of participants, forming large
distributed applications. The resulting activities may have complex structures and relationships.
This specification provides the definition of a business activity coordination type used to coordinate
activities that apply business logic to handle business exceptions. Actions are applied immediately and are
permanent. Compensating actions may be invoked in the event of an error. The Business Activity
specification defines protocols that enable existing business process and work flow systems to wrap their
proprietary mechanisms and interoperate across trust boundaries and different vendor implementations.
Business activities have the following characteristics:
■ A business activity may consume many resources over a long duration.

■ A significant number of atomic transactions may be involved.
■ Individual tasks within a business activity can be seen prior to the completion of the business
activity; their results may have an impact outside of the computer system.
■ Responding to a request may take a very long time. Human approval, assembly,
manufacturing, or delivery may have to take place before a response can be sent.
■ In the case where a business exception requires an activity to be logically undone, abort is
typically not sufficient. Exception handling mechanisms may require business logic, for
example, in the form of a compensation task, to reverse the effects of a completed business
task.
■ Participants in a business activity may be in different domains of trust where all trust
relationships are established explicitly.
These characteristics lead to a design point, with the following assumptions:
■ All state transitions are reliably recorded, including application state and coordination
metadata.
■ All notifications are acknowledged in the protocol to ensure a consistent view of state
between the coordinator and participant.
■ Each notification is defined as an individual message. Transport level request/response retry
and timeout are not sufficient mechanisms to achieve end-to-end agreement coordination for
long-running activities.
This specification leverages WS-Coordination by extending it to support business activities. It does this by
adding constraints to the protocols defined in WS-Coordination and by defining its own coordination
protocols.
WS-Composite Application Framework
WS-Composite Application Framework (WS-CAF) is alternative to WS-Transactions for addressing
transactional processing requirements for Web services. WS-CAF was proposed by Arjuna, IONA, Oracle,
Fujitsu, and Sun and was submitted to WS-CAF technical committee in October 2003.
Page 52
Business Process Execution Language (BPEL4WS)
The BPEL4WS standard is currently at version 1.1. It was developed by IBM, Microsoft, Siebel Systems,
BEA, and SAP and has been submitted to OASIS organization. An OASIS technical committee has been
formed, but a draft specification has not yet been published.
What are the concepts required to describe business protocols? And, what is the relationship of these
concepts to those required to describe executable processes? To answer these questions, consider the
following:
■ Business protocols invariably include data-dependent behavior. For example, a supply-chain

protocol depends on data such as the number of line items in an order, the total value of an
order, or a deliver-by deadline. Defining business intent in these cases requires the use of
conditional and timeout constructs.
■ The ability to specify exceptional conditions and their consequences, including recovery
sequences, is at least as important for business protocols as the ability to define the
behavior in the "all-goes-well" case.
■ Long-running interactions include multiple, often nested units of work, each with its own data
requirements. Business protocols frequently require cross-partner coordination of the
outcome (success or failure) of units of work at various levels of granularity.
BPEL4WS defines a model and a grammar for describing the behavior of a business process based on
interactions between the process and its partners. The interaction with each partner occurs through Web
services interfaces, and the structure of the relationship at the interface level is encapsulated in what is
called a "partner link." The BPEL4WS process defines how multiple service interactions with these
partners are coordinated to achieve a business goal, as well as the state and the logic necessary for this
coordination. BPEL4WS also introduces systematic mechanisms for dealing with business exceptions and
processing faults. Finally, BPEL4WS introduces a mechanism to define how individual or composite
activities within a process are to be compensated in cases where exceptions occur or a partner requests
reversal.
BPEL4WS processes and Web services
Page 53
BPEL4WS is layered on top of several XML specifications: WSDL 1.1, XML Schema 1.0, and XPath 1.0.
WSDL messages and XML schema type definitions provide the data model used by BPEL4WS
processes. XPath provides support for data manipulation. All external resources and partners are
represented as WSDL services. BPEL4WS provides extensibility to accommodate future versions of these
standards, specifically the XPath and related standards used in XML computation.
Among these XML specifications, WSDL has the most influence on the BPEL4WS language. The
BPEL4WS process model is layered on top of the service model defined by WSDL 1.1. At the core of the
BPEL4WS process model is the notion of peer-to-peer interaction between services described in WSDL;
both the process and its partners are modeled as WSDL services. A business process defines how to
coordinate the interactions between a process instance and its partners. In this sense, a BPEL4WS
process definition provides or uses one or more WSDL services and provides the description of the
behavior and interactions of a process instance relative to its partners and resources through Web
services interfaces. That is, BPEL4WS defines the message exchange protocols followed by the business
process of a specific role in the interaction.
The definition of a BPEL4WS business process also follows the WSDL model of separation between the
abstract message contents used by the business process and deployment information (messages and
Page 54
portType versus binding and address information). In particular, a BPEL4WS process represents all
partners and interactions with these partners in terms of abstract WSDL interfaces (portTypes and
operations); no references are made to the actual services used by a process instance.
However, the abstract part of WSDL does not define the constraints imposed on the communication
patterns supported by the concrete bindings. Therefore, a BPEL4WS process may define behavior relative
to a partner service that is not supported by all possible bindings, and it may happen that some bindings
are invalid for a BPEL4WS process definition. The BPEL4WS process is a reusable definition that can be
deployed in different ways and in different scenarios, while maintaining a uniform application-level
behavior across all of them. Note that the description of the deployment of a BPEL4WS process is out of
scope for this specification.
BPEL4WS also depends on the WS-Addressing specification previously discussed. The dependency on
WS-Addressing is meant to avoid inventing a private BPEL4WS mechanism for Web service endpoint
references – such references are obviously a very general requirement in the usage of Web services.
Web Services Choreography Description Language (WS-CDL)
An alternative standard known as Web Services Choreography Description Language (WS-CDL) offers an
XML-based language that describes peer-to-peer collaborations of parties by defining, from a global
viewpoint, their common and complementary observable behavior; where ordered message exchanges
result in accomplishing a common business goal. The Web Services Choreography specification is
targeted for composing interoperable, peer-to-peer collaborations between any type of party regardless of
the supporting platform or programming model used by the implementation of the hosting environment.
This specification is currently W3C working draft.
Page 55
Web Services Distributed Management (WSDM)
To perform the appropriate Web services management, it is best to manage across the whole Web
services stack. Doing so involves management from the infrastructure layer up to the Web services
(application) layer.
As Web services become pervasive and critical to business operations, the task of managing Web
services and implementations of the Web services architecture will be imperative to the success of
business operations. The importance of a standardized management model for Web services and the
promise of Web services as a management integration technology have driven industry leaders in Web
services and management technologies and applications to form a technical committee in OASIS called
the Web Services Distributed Management (WSDM) Technical Committee.
The OASIS WSDM Technical Committee’s intention is primarily to provide protocols to enable the runtime
management of Web services and enable Web service platforms to feed relevant information to traditional
systems management tools.
The Web Services Distributed Management (WSDM) Model for managing distributed services, as defined
by OASIS, is pronounced "wisdom." WSDM seeks to specify a model for Web services management that
allows interoperability between multiple environments. IBM and Novell co-chair the OASIS WSDM
Technical Committee.
The OASIS WSDM Technical Committee is defining two sets of specifications: Web Services Distributed
Management: Management Using Web Services (MUWS) and Web Services Distributed Management:
Management of Web Services (MOWS) specifications.
Management Using Web services
WSDM MUWS 1.0 defines how to represent and access the manageability interfaces of resources as Web
services. It is the foundation of enabling management applications to be built using Web services and
allows resources to be managed by many managers with one set of instrumentation. This specification
provides interoperable, base manageability for monitoring and control managers using Web services.
WSDM MUWS 1.0 has been defined in two specifications, MUWS Part 1, which defines the base
architectural concepts and required components, and MUWS Part 2 which defines standard composable
support for manageability capabilities.
Management of Web Services
WSDM MOWS defines the manageability model for managing Web services as a resource and how to
describe and access that manageability using MUWS.
Management of Web Services
Page 56
WSDM – Status
IBM, Talking Blocks and CA and published the initial specification called WS-Manageability in April 2004.
The specification was then submitted to OASIS WSDM technical committee. As of this writing, OASIS
WSDM TC has approved the Web Services Distributed Management: Management Using Web Services
(MUWS) 1.0 specification and Web Services Distributed Management: Management of Web Services
(MOWS) 1.0 specification for public review. There is another specification in WS-Management that
addresses similar issues and is developed by Microsoft, Intel and others.
Related specifications
Two additional specifications are available in the area of Web services management.
The Service Provisioning Markup Language (SPML) is an OASIS approved standard intended to define
and standardize an XML based framework for exchanging user, resource and service provisioning
information.
WS-Provisioning is a specification developed by IBM to facilitate interoperability between provisioning
systems in a consistent manner. The specification has been submitted to OASIS Provisioning Services
Technical Committee to be considered for inclusion in SPML V2.0 standard.
Page 57
Web Services Resource Framework (WS-RF)
Web service interfaces frequently provide a user with the ability to access and manipulate state, that is,
data values that persist across, and evolve as a result of, Web service interactions. In other words, the
message exchanges that Web services implement are frequently intended to enable access to stateful
resources. However, the notion of stateful resources acted upon by the Web service implementation is not
explicit in the interface definition. The messages that the services send and receive imply (or encourage
programmers to infer) the existence of an associated stateful resource type.
It is desirable to define Web service conventions to enable the discovery of, introspection on, and
interaction with stateful resources in standard and interoperable ways. Most importantly, such an
approach improves the robustness of design-time selection of services during application assembly and
runtime binding to specific stateful resource instances.
Consider an example that illustrates a requirement to access and modify state. An online airline
reservation system must maintain state concerning flight status, reservations made by specific customers,
and the system itself: its current location, load, and performance. Web service interfaces that allow
requesters to query flight status, make reservations, change reservation status, and manage the
reservation system must provide access to this state.
These observations motivated the WS-Resource approach to modeling state in a Web services context. A
WS-Resource is defined as the composition of a Web service and a stateful resource that is (i) expressed
as an association of an XML document with defined type with a Web services portType, and (ii) addressed
and accessed according to the implied resource pattern, a conventional use of WS-Addressing endpoint
references. In the implied resource pattern, a stateful resource identifier is encapsulated in an endpoint
reference and used to identify the stateful resource to be used in the execution of a Web service message
exchange. The WS-Resource framework allows WS-Resources to be declared, created, accessed,
monitored for change, and destroyed via conventional Web services mechanisms, but does not require
that the Web service component of the WS-Resource that provides access to the associated stateful
resources be implemented as a stateful message processor.
The WS-Resource framework consists of a family of specifications that define the normative description of
the WS-Resource approach in terms of specific Web services message exchanges and related XML
definitions. It includes the WS-ResourceProperties, WS-ResourceLifetime, WS-BaseFaults, and
WS-ServiceGroup specifications.
WS-ResourceProperties provides a definition of a WS-Resource, and mechanisms for retrieving,
changing, and deleting a WS-Resource. It defines how the data associated with a stateful resource can be
queried and changed using Web services technologies. This allows a standard means by which data
associated with a WS-Resource can be accessed by clients. The declaration of the WS-Resource’s
properties represents a projection or a view of the WS-Resource’s state. This projection represents an
implied resource type that serves to define a basis for access to the resource properties through Web
service interfaces.
WS-ResourceLifetime defines two ways of destroying a WS-Resource: message exchanges that allow a
requester to destroy a WS-Resource, either immediately or by using a time-based scheduled resource
termination mechanism. This allows designers flexibility to design how their Web services applications can
clean up resources no longer needed.
WS-Renewable References: A conventional decoration of a WS-Addressing endpoint reference with
policy information needed to retrieve an updated version of an endpoint reference when it becomes
invalid.
WS-BaseFaults defines an XML schema type for a base fault, along with rules for how this fault type is
used by Web services. A designer of a Web services application often uses interfaces defined by others.
Managing faults in such an application is more difficult when each interface uses a different convention for
representing common information in fault messages. Support for problem determination and fault
management can be enhanced by specifying Web services fault messages in a common way. When the
information available in faults from various interfaces is consistent, it is easier for requesters to understand
faults. It is also more likely that common tooling can be created to assist in the handling of faults.
WS-ServiceGroup defines a means by which Web services and WS-Resources can be aggregated or
Page 58
grouped together for a domain-specific purpose. In order for requesters to form meaningful queries
against the contents of the ServiceGroup, membership in the group must be constrained in some fashion.
The constraints for membership are expressed by intension using a classification mechanism. Further, the
members of each intension must share a common set of information over which queries can be
expressed.
Page 59
Grid computing
In grid computing, two main component types exist – the server and the client. The server is used to
distribute work requests and holds information about the individual work units that make up the work as a
whole. The client (or more typically, clients) processes the individual work units.
The two communicate with each other in a number of different ways, but at the heart of the system is the
distribution of work. Again, the system works in one of two ways – either the clients manage their own
work flow and request new work units from the server, or the server distributes work units to the client.
Communication does not stop there, either; often there will be additional servers and services used to
support the grid server infrastructure, and these need to talk to each other and exchange information.
The key point is that often with a grid solution, you are exchanging fairly discrete pieces of information.
Between the client and the server, the information will be the original work unit and the processed
response. Even in a situation where the data load is particularly high, as in data processing or video
rendering, you are still exchanging packets of information rather than requiring full-blown, two-way,
permanent communication between the client and server elements. The more radical grid ideas, like the
new WebSphere extensions, which allow Web requests to a WebSphere application to be distributed
across a grid of WebSphere servers, are another example where both the grid management and the
actual work distribution can be handled through fairly simple data exchange.
There are exceptions to the rule, of course. Not all grid systems rely on such a straightforward exchange
of simple packets. Resource grids, for example, often rely on fairly heavy intercommunication between
grid providers (the clients) to enable requests for storage to be made in real time across the grid. In these
situations though, even when communicating directly between clients, it is still a basic exchange of
information.
So if you are simply exchanging information, surely there must be a standard method to communicate
between the servers and the clients. This is where Web services comes in. So far, you have examined a
grid technology that works by exchanging information, either between servers and clients or directly
between clients, to process and distribute information. But that exchange system needs a way of actually
communicating the information. Over the years, a number of systems have been used, including the FTP
protocol and custom-built protocol systems. Meanwhile, within Web services is a generic tool that can be
used to exchange information between two machines, be that a request to execute a particular function
(such as getnewworkunit()) or simply to exchange information between the two. Because Web services
are based on other standards like XML, they are very easy to develop and extend into a wide variety of
environments, and they are also easy to deploy. You get rid of all of the problems of exchanging data
between differing systems, and you do not need to worry about the endian-ness (the order of bits in a
byte) of the processor, or how to convert the information you are sending into a neutral format because
the Web service standards take care of that.
Because you need some kind of listener-dispatch service to process requests, distribute work, and collect
it back, a Web service is ideal to use. The major benefit of the Web services system is that, because it
relies on the HTTP protocol, it is very easy to integrate Web services into your existing HTTP platforms,
routing, firewalls, and other systems. Most organizations are already running an HTTP service, so you can
support your grid system using existing technology and security systems without compromising your
network or limiting the facilities of your grid system. Developing a grid system that uses Web services
therefore has a number of distinct benefits, including:
■ Increased compatibility
■ Increased flexibility
■ Cross-platform-enabled development by eliminating the complexities of exchanging data
■ Easy deployment using an existing Web server
■ Easily secured by using existing HTTP security and firewall support
■ Easy communication and accessibility by making it simple to contact the grid components
over an intranet or Internet
For all these reasons, and many more, Web services has become part of the new grid services standard,
Page 60
the Open Grid Services Architecture (OGSA), and its companion, the Open Grid Services Infrastructure
(OGSI). The Globus Toolkit 3.0, the first grid platform to fully support the OGSA/OGSI standard, supports
Web services as a data exchange platform. IBM, a key proponent of the OGSA standard and the Globus
system, is a strong supporter of Web services and is now recommending them for use across the
business development platform. Globus supports the SOAP Web services protocol.
There are additional benefits to the Web services approach. Web services can publish their existence
through a number of different Web services directories and systems, including systems like Universal
Description, Discovery, and Integration (UDDI) and Web Services Description Language (WSDL). For grid
computing to be easy to deploy, publication is needed through such directories and systems.
The next evolution is starting to show the following for grid:
■ Distributed platform services:
a. Enable a consistent end-to-end view of a heterogeneous, multi-OS, multi-middleware,

multi-component system.
b. Workload distribution and management, surge protection, monitoring and administration,
resource utilization and allocation, security, unit of work management, subscriber, and
metering and billing support.
■ Large-scale allocation and management of information system resources:
a. To achieve a set of demand and service level goals.

■ Grid services define the basis for the next generation of Web services standards:
a. Everything about grid services has broader applicability to general business services in a
service-oriented architecture.
Page 61
Enterprise standards summary
administrative
by
body
WS-AtomicTransaction,
WS-AtomicTransaction BEA, Specification WS-CAF
WS-Coordination,
provides the definition of Microsoft, published
WS-BusinessActivity
the atomic transaction IBM
(supersedes coordination type that is
WS-Transaction)
to be used with the
extensible coordination
framework described in
the WS-Coordination
specification.
WS-BusinessActivity
provides the definition of
the business activity
coordination type that is
to be used with the
extensible coordination
framework described in
the WS-Coordination
specification. See URL 1
below.
BPEL4WS Business Process OASIS BEA, V1.1 of the WS-Choreography
Execution Language Microsoft, specification
defines a notation for IBM published by
specifying business
process behavior based
on Web services.
Business processes can
be described in two
ways. Executable
business processes
model actual behavior of
a participant in a
business interaction.
Business protocols, in
contrast, use process
descriptions that specify
the mutually visible
message exchange
behavior of each of the
parties involved in the
protocol, without
revealing their internal
behavior. See URLs 2
and 3 below.
Page 62

administrative
by
body
vendors.
OASIS
technical
committee is
still working
on draft of
the standard.
WSDM (Web WS Distributed OASIS IBM, CA, OASIS WS-Management
Services Management. The TalkingBlocksWSDM
Distributed purpose of this Technical Technical
Management)Committee is to define Committee is
Web services working on
management, including the draft of
using Web services the standard.
architecture and
technology to manage
distributed resources.
This Technical
Committee will also
develop the model of a
Web service as a
manageable resource.
See URL 4 below.
WS-Provisioning
Facilitate interoperability Submitted to IBM OASIS is
between provisioning OASIS reviewing the
systems in a consistent specification
manner. for possible
inclusion in
SPML V2.0
standard.
WS-RF The WS-Resource Submitted to IBM, Published by
WS-Resourceconstruct has been OASIS Akamai, HP, vendors in
Framework proposed as a means of March 2004 SAP, Sonic January
expressing the Software, the2004. OASIS
relationship between Globus Technical
stateful resources and Alliance, Committee
Web services. TIBCO has
published
working
drafts in
June 2004.
1. http://msdn.microsoft.com/webservices/understanding/advancedwebservices/default.aspx?pull=/library/en-us/dnglobsp
2. http://www.ibm.com/developerworks/webservices/library/ws-bpel/
3. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
4. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm
Page 63
Web services standards: User experience

Web Services for Remote Portals
The WSRP specification defines a Web service interface for accessing and interacting with interactive
presentation-oriented Web services. This enables:
■ Portal servers to provide portlets as presentation-oriented Web services

■ Portal servers to consume presentation-oriented Web services provided by portal or
non-portal content providers.
This specification accounts for the fact that Producers (Web services conforming to WSRP) and
Consumers (applications consuming Producers in a manner conforming to WSRP) may be implemented
on very different platforms, be it as a J2EE based Web service, a Web service implemented on Microsoft's
.NET platform or a portlet published directly by a portal. Special attention has been taken to ensure this
platform independence. Producers determine how their content and applications are visualized for users
and to which degree adaptation, transcoding, translation, and others may be allowed. WSRP V1.0 is an
approved OASIS standard.
WSRP services can be published into public or corporate service directories (UDDI,) where they can
easily be found by intermediary applications that want to display their content. Web application
deployment vendors can wrap and adapt their middleware for use in WSRP-compliant services. Vendors
of intermediary applications can enable their products for consuming Web Services for Remote Portals.
Using WSRP, portals can easily integrate content and applications from many internal and external
content providers. The portal administrator simply picks the desired services from a list and integrates
them. No programmers are required to tie new content and applications into the portal.
To accomplish these goals, the WSRP standard defines a Web services interface description using WSDL
and all the semantics and behavior that Web services and consuming applications must comply with in
order to be pluggable as well as the meta-information that has to be provided when publishing WSRP
services into UDDI directories. The standard allows WSRP services to be implemented in very different
ways – as a Java/J2EE based Web service, a Web service implemented on Microsoft's .NET platform, or
a portlet published as a WSRP service by a portal. The standard enables use of generic adapter code to
plug in any WSRP service into intermediary applications rather than requiring specific proxy code.
WSIA (Web Services Interactive Applications) Framework for interactive Web applications is closely allied
with WSRP. WSIA aims to bring together earlier work on various specifications, including IBM's Web
Services Experience Language (WSXL) and Epicentric's Web services User Interface (WSUI) initiative, to
create a platform-neutral standard based on XML and Web services for presenting interactive Web
applications to users.
WSRP services are WSIA component services built on standard technologies including SOAP, UDDI, and
WSDL. WSRP adds several context elements including user profile, information about the client device,
locale, and desired markup language passed to them in SOAP requests. A set of operations and contracts
are defined that enable WSRP plug-n-play.
When aggregating pages for portal users, portals typically invoke all portlets belonging to a user’s page
through a Portlet API for locally installed portlets. There are two different kinds of portlets:
■ Local portlets run on the portal server itself. They may be deployed by installing portlet
archive files on portal servers and are typically invoked by the portal server directly through
local method calls.
■ Remote portlets run as Web services on remote servers that are published in a UDDI
directory to allow for easy finding and binding. Typically portlet proxies (generic local
placeholders) will invoke WSRP services to which they are bound by means of the SOAP
protocol.
In the following figure, the Bank portal has two local portlets: Account Portlet and Stock Portlet. Both are
made available as presentation-oriented Web services as per the WSRP protocol. They can then be
accessed as remote portlets from the corporate Employee Portal. You see that Employee Portal has a
WSRP Proxy portlet AccountProxy that represents a local portlet, and that invokes the Account Web
Page 64
service to render the remote Account Portlet on the Employee Portal page. The figure shows several
examples of local and remote portlets that are made available as WSRP. In the following diagram, PProxy
stands for Portlet Proxy.
Web Services for Remote Portals (WSRP)
Page 65
Page 66
Web services standards: Interoperability (1 of 4)

Web Services Interoperability (WS-I) organization
The key to successful interoperability is resolving the ambiguities, discrepancies, and outright conflicts in
the Web services standards. This is the goal of the WS-I organization.
WS-I is an open industry group that was formed in 2002 to promote Web services interoperability across
platforms, operating systems, and programming languages. Though this would appear to be the basic
premise of Web services and the role of standards bodies, WS-I still has a useful role to play, for example:
■ Standards specifications are always open to interpretation to some extent. WS-I will provide
guidelines and tools to help measure the conformance of various implementations, and to
enable their interoperability.
■ As standards evolve, there is a need to understand which different versions might
interoperate.
■ WSI-I publishes interoperability profiles to reflect the above; it is one of the key deliverables
of WS-I.
The Web Services Interoperability Organization (WS-I.org) is an open industry effort chartered to meet
that challenge to promote and ensure Web services interoperability across platforms, applications, and
programming languages. It was a joint creation of IBM, Microsoft, HP, Oracle, SAP, BEA, Fujitsu,
Accenture, and Intel and supports other key Web services vendors with the goal of bringing technology
vendors, both large and small, and their customers – the people actually using Web services to solve
business objectives – together to provide standards guidance, recommended practices, and supporting
resources for developing interoperable Web services.
To meet the challenge that it has been given, the organization gathers use cases that help identify and
address Web service interoperability issues and requirements. Its members then reach consensus on their
collective requirements, identify the specifications that best satisfy those requirements, address any
deficiencies found with these specifications, and agree on which optional aspects of the specification are
either required or should be disallowed to promote increased potential for interoperability. The results of
their work are published as a WS-I profile, supplemented with tools that can be used to test conformance
to the profile, and sample applications that demonstrate usage of the profile to aid developers in
understanding the intended use of these technologies. Since WS-I's inception in February 2001,
worldwide membership has grown quickly to over 160 companies, spanning IT vendors, service providers,
and user companies demonstrating the marketplace need for Web services interoperability.
Page 67

IBM's role in WS-I
IBM is clearly a significant participant in WS-I. IBM is active in all areas of WS-I holding key leadership
roles in technical working groups and board committees. IBM has developed and is continuing to develop
the development tools and runtime platforms that its customers and partners need to create and run
interoperable Web services based on the work of the WS-I. IBM supplies the solutions that both the
company and its customers need to exploit Web services within their businesses and leverage underlying
interoperable Web services interfaces between their solutions and those of IBM’s partners and
competitors. IBM uses Web services as a tool to assist in the integration of applications, both internally
and externally between partners and customers.
Page 68

WS-I deliverables
WS-I has four main deliverables:
■ Use cases and usage scenarios: Use cases and usage scenarios capture (respectively)
business and technical requirements for the use of Web services. These requirements
reflect the classes of real-world requirements supporting Web services solutions and provide
a framework to demonstrate the guidelines described in WS-I profiles.
■ Profiles: Profiles are comprised of a set of named and versioned Web services
specifications together with a set of implementation and interoperability guidelines
recommending how the specifications may be used to develop interoperable Web services.
■ Sample applications: Sample applications demonstrate the implementation of applications
that are built from Web services usage scenarios and use cases, and that conform to a given
set of profiles. Implementations of the same sample application on multiple platforms,
languages, and development tools demonstrate interoperability in action and provide readily
usable resources for the Web services practitioner.
■ Testing tools: Testing tools are used to monitor and analyze interactions with a Web
service to determine whether or not the messages exchanged conform to WS-I profile
guidelines.
WS-I deliverables
The WS-I process begins with the definition of use cases that describe how Web services can be applied
to meet real-world business needs. These use cases are then decomposed into usage scenarios
supporting various aspects of the use cases and design patterns. The usage scenarios describe the ways
in which Web services are employed in the context of the collected use cases. This work aids in the
Page 69
demonstration of how Web services specifications are used individually, in concert with one another, or
both.
Use case analysis forms the foundation for profile requirements to be defined. Each profile is based on a
specific set of Web services specifications, each at a particular version and revision level. Profiles provide
a refined usage of these specifications and standards through implementation and interoperability
guidelines, which, in many cases, are captured as a set of test assertions that can be used to verify a
given Web service implementation's conformance with the profile.
WS-I then develops specifications for and implements sample applications. The supporting
implementations are developed in multiple programming languages, such as C# (C sharp) and Java
programming language, and are deployed on multiple platforms, including Java 2 Platform, Enterprise
Edition (J2EE), and .NET. This activity illustrates profile interoperability by developing solutions to the use
cases and usage scenarios that the profiles are intended to address.
Finally, to close the loop, WS-I is developing testing tools for use by Web services practitioners, including
those members of the WS-I Working Groups developing sample applications. These tools are used to
verify that the interactions observed with the monitored Web service conform to the set of guidelines and
test assertions that define the interoperability profiles.
Page 70

What is a profile?
A profile is:
■ A named set of Web services specifications; for example, SOAP, WSDL, UDDI
■ Base specifications are normative unless:
a. Profile adds constraints and guidance as to their interoperable usage based upon
implementation experience
b. Organized around base specifications
The following table details the philosophy of a profile.

Philosophy Explanation Current status
No guarantee of Goal is to improve It is impossible to completely guarantee the interoperability of
interoperability the potential for a particular service. However, the profile does address the
interoperability most common problems that implementation experience has
revealed to date.
Application Out of scope. Left to Although communication of application semantics can be
semantics the vendor facilitated by the technologies that comprise the profile,
implementations. assuring the common understanding of those semantics is
Similar to J2EE. not addressed by it.
Testability Design of the profile When possible, the profile makes statements that are
to be testable; some testable. However, such testability is not required. Preferably,
things are not testing is achieved in a non-intrusive manner (for example,
testable; can only examining artifacts "on the wire").
test what is on the
wire; not intrusive.
Strength of Identify "musts" and The profile makes strong requirements (for example, must,
requirements "must nots" to have must not) wherever feasible; if there are legitimate cases
the requirements as where such a requirement cannot be met, conditional
specific as possible requirements (for example, should, should not) are used.
Optional and conditional requirements introduce ambiguity
and mismatches between implementations.
Restriction versus Ideally the profile When amplifying the requirements of referenced
relaxation would be a list of specifications, the profile may restrict them, but does not
specifications. relax them (for example, change a must to a may).
When an assertion
is made by a
specification, it is
not relaxed by this
standard, but when
there is a choice, it
is further restricted.
Multiple When multiple If a referenced specification allows multiple mechanisms to
mechanisms mechanisms are be used interchangeably, the profile selects those that are
identified for a well-understood, widely implemented, and useful. Extraneous
particular instance or underspecified mechanisms and extensions introduce
the specification complexity and therefore reduce interoperability.
identifies one.
Page 71
Philosophy Explanation Current status

Reduce ambiguity,
which is at the root
of interoperability
problems.
Future compatibility Work to stay in sync When possible, the profile aligns its requirements with
with the future work in-progress revisions to the specifications it references (for
of the W3C, WSDL, example, SOAP 1.2, WSDL 1.2). This aids implementers by
and XML working enabling a graceful transition, and assures that WS-I does
groups not 'fork' from these efforts. When the profile cannot address
an issue in a specification it references, this information is
communicated to the appropriate body to assure its
consideration.
Compatibility with Delicate balance Backwards compatibility with deployed Web services is not a
deployed services needs to be goal for the profile, but due consideration is given to it; the
achieved to ensure profile does not introduce a change to the requirements of a
that existing referenced specification unless doing so addresses specific
services do not interoperability issues.
need extensive
changes.
Focus on Avoid the Although there are potentially a number of inconsistencies
interoperability temptation to fix and design flaws in the referenced specifications, the profile
things not specified only addresses those that affect interoperability.
in the specifications.
Specification
moderation.
Conformance Identify Where possible, the profile places requirements on artifacts
targets conformance target (for example, WSDL descriptions, SOAP messages) rather
points to further than on the producing or consuming software's behaviors or
clarify the roles. Artifacts are concrete, making them easier to verify and
interoperability therefore making conformance easier to understand and less
points. Also to error-prone.
assist in identifying
assertions points for
testing
Lower-layer Do not address The profile addresses interoperability at the application layer;
interoperability lower level it assumes that interoperability of lower-layer protocols (for
interoperability example, TCP, IP, Ethernet) is adequate and
issues, such as in well-understood. Similarly, statements about application-layer
the network layer substrate protocols (for example, SSL/TLS, HTTP) are only
made when there is an issue affecting Web services
specifically; WS-I does not attempt to assure the
interoperability of these protocols as a whole. This assures
that WS-I's expertise in and focus on Web services standards
is used effectively.
WS-I Basic Profile 1.0

The WS-I Basic 1.0 Profile specification defines conformance of a Web service instance. This profile was
published by WS-I in April 2004. The profile consists of the following set of non-proprietary Web services
specifications:
■ SOAP 1.1
■ WSDL 1.1
Page 72
■ UDDI 2.0
■ XML 1.0 (Second Edition)
■ XML Schema Part 1: Structures
■ XML Schema Part 2: Data types
■ RFC2246: The Transport Layer Security Protocol V1.0
■ RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
■ RFC2616: Hypertext Transfer Protocol 1.1
■ RFC2818: HTTP over TLS
■ RFC2965: HTTP State Management Mechanism
■ The Secure Sockets Layer Protocol V3.0
The profile provides constraints and clarifications to those base specifications with the intent to promote
interoperability. Where the profile is silent, the base specifications are normative. If the profile prescribes a
requirement or constraint, it supersedes the underlying base specification. Some of the constraints
imposed by the profile are intended to restrict, or require, optional behavior and functionality, to reduce the
potential for interoperability problems. Some of the constraints or requirements are provided to clarify
language in the base specification that may be the source of frequent misinterpretation and resultant
interoperability problems.
The following highlights the key constraints imposed by the profile:
■ Precludes the use of SOAP encoding

■ Requires the use of HTTP binding for SOAP
■ Requires the use of HTTP 500 status response for SOAP Fault messages
■ Requires the use of HTTP POST method
■ Requires the use of WSDL1.1 to describe the interface of a Web service
■ Requires the use of rpc/literal or document/literal forms of the WSDL SOAP binding
■ Precludes the use of solicit-response and notification style operations
■ Requires the use of WSDL SOAP binding extension with HTTP as the required transport
■ Requires the use of WSDL1.1 descriptions for UDDI tModel elements representing a Web
service
WS-I Basic Profile 1.1

WS-I Basic Profile 1.1 was published by WS-I in August 2004. It is derived from the Basic Profile 1.0 by
incorporating any errata to date and separating out those requirements related to the serialization of
envelopes and their representation in messages. Such requirements are now part of the Simple SOAP
Binding Profile 1.0, identified with a separate conformance claim. This separation is made to facilitate
composability of Basic Profile 1.1 with any profile that specifies envelope serialization, including the
Simple SOAP Binding Profile 1.0 and the Attachments Profile 1.0. Attachment Profile 1.0 adds support for
sending interoperable attachments with SOAP messages. It does so by defining a MIME multipart
structure for packaging attachments with SOAP messages. A combined claim of conformance to both the
Basic Profile 1.1 and the Simple SOAP Binding Profile 1.0 is roughly equivalent to a claim of conformance
to the Basic Profile 1.0 plus published errata. This profile, composed with the Simple SOAP Binding Profile
1.0 supersedes the Basic Profile 1.0. In a similar fashion Attachment Profile 1.0 can be combined with
Basic Profile 1.0.
Page 73
Web services standards: Bringing Web services to Java and J2EE (1 of 5)

J2EE Web services extensions
Perhaps the most significant, and most consequential, additions to J2EE 1.4 are the new interoperation
requirements. The requirements prescribe support for SOAP (Simple Object Access Protocol) 1.1 in the
J2EE presentation layer to facilitate XML message exchange. J2EE 1.4-compliant containers must also
support the WS-I (Web services Interoperability Consortium) Basic Profile. Since XML message exchange
in J2EE depends on JAX-RPC, the JAX-RPC specifications now mandate WS-I Basic Profile support, as
well.
The result is that a J2EE 1.4-based application can be invoked as a Web service, even from applications
not written in the Java programming language. While that is an evolutionary step for J2EE, since the
platform has long embraced non-Java based systems, it is possibly the most direct way to facilitate
interaction with Windows-based technologies that rely on .Net.
A J2EE-based service's client does not have to be aware of how a service is implemented. Rather, that
client can use the service by relying entirely on the service's WSDL (Web services Description Language)
definition. While the J2EE specifications do specifically state the exact mechanics of such interaction,
J2EE 1.4's embrace of the WS-I Basic Profile, which Microsoft also claims to follow, will likely make
J2EE-.Net interaction common.
To facilitate access to WSDL definitions, J2EE 1.4 adds support for the JAXR (Java API for XML
Registries) standard. The JAXR libraries are now a required part of the J2EE application client, EJB
(Enterprise JavaBeans), and Web containers (not the applet container, though). Since WS-I Basic Profile
mandates support for UDDI (Universal Description, Discovery, and Integration) 2.0, J2EE clients, as well
as EJB components and servlets, can interact with public Web service registries. The following figure
illustrates the additional Web service-related libraries supported by J2EE 1.4.
J2EE 1.4 Web services support
There are three major parts to a Web services solution:
■ A programming model
a. How you write clients to access Web services
Page 74
b. How you write service implementations

c. How you handle other parts of the SOAP specification (headers, attachments, and so on)
■ A deployment model
a. Deployment descriptors to map service implementations to SOAP messages

b. Type mapping for parameters
■ An engine
a. Code to receive SOAP messages and invoke service implementations

b. Code to map Java types to XML
JAX-RPC and JSR 109 are the two key Java standards that address the Web services solution in Java.
Page 75

Java API for XML-based RPC (JAX-RPC) 1.1
Portable Web services applications (JSR 101), better known as JAX-RPC, defines the standard
programming model for Web services in Java. JAX-RPC is defined to be protocol-neutral and defines:
■ The mapping of WSDL to Java and the reverse

■ A client API to invoke a remote Web service
■ A runtime environment for JavaBean as an implementation of a Web service
■ A handler model that provides a mechanism to manipulate or view the SOAP message
produced as part of serializing or deserializing the Java to XML and vice versa
JAX-RPC is designed for portability of code across multiple vendors. It has a very RMI-like flavor in its
definition and is intended to provide a definition such that any client or service implementation should be
portable across any vendor that supports JAX-RPC. The following diagram depicts the basic JAX-RPC
working model.
JAX-RPC client/server model
JAX-RPC is based on a few basic concepts (very similar to the concepts behind EJBs). JAX-RPC defines:
■ Service implementation is a Java class conforming to JAX-RPC rules that implements the
methods of a WSDL-Described interface.
■ A Service Endpoint Interface (SEI) provides a Java "view" of the WSDL-described interface.
Clients interact with objects implementing this interface.
A service mediates access to the ports (acts as a factory for ports).JAX-RPC 1.1 addresses
interoperability issues by requiring the code generators (that generate the WSDL and underlying SOAP
message) to adhere to WS-I Basic Profile 1.0. JAX-RPC relies on SAAJ (explained below) for producing
and consuming SOAP 1.1 message as well as for manipulating SOAP messages within handlers.
Standardized mapping for WSDL/XML – Java mappings
Page 76
Page 77

SAAJ 1.2
A SOAP message can be generated and sent manually, but the SOAP with Attachments API for Java
(SAAJ) – an offshoot of the Java API for XML Messaging (JAXM) developed by the JSR 67 expert group –
automates many of the required steps, such as creating connections or creating and sending the actual
messages.
SAAJ provides a convenient API for constructing SOAP messages without having to directly create the
XML yourself. The final release of this specification (JAXM V1.0) provided two different but related
facilities:
■ Core functionality concerned with manipulating SOAP messages in a generic way, together
with the ability to send a SOAP message from one entity to another
■ A higher-level messaging facility that included reliable delivery of messages and support for
messaging profiles, which requires SOAP messages to be constructed in specific ways
During the maintenance cycle for JSR 67, it was decided to unbundle the low-level SOAP message
creation features into a separate specification, thus creating SAAJ 1.1, leaving the higher-level features to
form JAXM V1.1. At the same time, minor modifications were made to the API to remove a dependency
that would otherwise have had the undesirable effect of making SAAJ 1.1 dependent on JAXM 1.1. The
result is that it is possible to use SAAJ as a lightweight library for building and exchanging SOAP
messages, without requiring the inclusion of JAXM 1.1, which provides facilities that go beyond the
requirements of many Web service clients. JAX-RPC, in particular, uses SAAJ to construct and decode
SOAP messages, but it does not require reliable messaging and therefore is not dependent on the
presence of a JAXM implementation.
SAAJ provides a standard way to send XML documents over the Internet from the Java platform. SOAP
with Attachments API for Java (SAAJ) is used for SOAP messaging that works behind the scenes in the
Java API for XML-based RPC (JAX-RPC) implementation. You can also use this API to directly write
SOAP messaging applications rather than using JAX-RPC. SAAJ allows you to do XML messaging from
the Java platform by making method calls by creating, sending, and consuming XML messages over the
Internet.
The two main types of SOAP messages are messages with attachments and messages without
attachments. SAAJ provides the SOAPMessages class to represent a SOAP message, the SOAPPart
class to represent the SOAP part, and the SOAPEnvelope interface to represent the SOAP envelope. A
SOAP message can also include one or more attachment parts in addition to the SOAP part. The SOAP
part must only contain XML content. If any of the message content is not in XML format, it must occur in
an attachment part. SAAJ provides the AttachmentPart class to represent the attachment part of a SOAP
message.
SAAJ provides the following key benefits to users:
■ SAAJ can be used within JAX-RPC handlers to enable user to modify or manipulate SOAP
header (for example, to log a message, add a context, and so on).
■ JAX-RPC allows the SOAP payload to be returned on the application interface. This allows
the application to more directly manipulate the SOAP message using SAAJ. This method is
often employed by applications for constructs that are not easy to represent using the
standard JAX-RPC type mapping or in cases where applications want the flexibility to deal
with the underlying SOAP message.
Page 78

Enterprise Web services (JSR-109)
The Enterprise Web services (JSR 109) specification addresses the deployment model for Web services
into a J2EE container. The 1.1 version of this specification is also part of J2EE 1.4 and was published as
JSR 921, though it is still commonly referred to as JSR 109.
■ Conceptually enhances JSR101

■ Defines a J2EE compliant deployment/packaging model for Web services on the server side
and for the client
■ Defines deployment descriptors for Web services
■ Defines a server-side programming model
■ Describes the behavior of stateless session EJB as an implementation of a Web service
■ Includes a client-side programming model
■ EJBs, servlets, JSPs, and application clients as client to Web services
■ J2EE Container required
■ Provides support for handlers and MessageContext within EJB container
A key Web services objective is to achieve interoperability across heterogeneous platforms and runtime
environments. JSR 109 fills the gaps that the JAX-RPC specification left open for use of Web services in a
J2EE application server.
Specifically, JSR 109:
■ Facilitates the building of interoperable Web services in J2EE

■ Standardizes of the deployment of Web services in a J2EE container
a. Client access to Web services

b. Web service life cycle
c. Web service deployment
The JSR 109 programming model leverages the work in JAX-RPC defining Web services support within a
J2EE environment, starting with the client programming model depicted below.
JSR 109 client/server model
JSR 109 then defines a deployment model for deploying the service into a J2EE container. The
deployment model includes several deployment descriptors that work in conjunction with the standard
Page 79
J2EE deployment descriptors like application.xml and web.xml.

The JSR 109 deployment model is depicted below and is accomplished by the indicated combination of
tooling and runtime implementations.
JSR 109 deployment model
Page 80

Java API for XML Registries (JAXR)
UDDI definitions are sufficiently general to accommodate services of different kinds, which are not
necessarily SOAP services. A UDDI definition could represent a faxing service or a telephone service.
UDDI, being a registry, is typically implemented using a database of sorts. In this database, there is a data
model allowing publishing and querying of these pieces of information.
The Java API for XML Registries (JAXR) is a Java XML API for working with service registries. All
elements of a UDDI are described using XML documents. JAXR provides a standard API for publication
and discovery of Web services through underlying registries.
JAXR does not define a new registry standard. Instead, this standard Java API performs registry
operations over a diverse set of registries and defines a unified information model for describing registry
contents. Regardless of the registry provider accessed, your programs use common APIs and a common
information model. The JAXR specification defines a general-purpose API, allowing any JAXR client to
access and interoperate with any business registry accessible via a JAXR provider. In this sense, JAXR
provides a "write once, run anywhere" API for registry operations, simplifying Web services development,
integration, and portability. JAXR v1.0 has been integrated into J2EE as a core library in the J2EE 1.4
specification
JAXR's expert group wanted the API to support a union of the best features of UDDI and ebXML, rather
than intersect common features. As described in the JAXR, the API is not a least common denominator
API. Below are the stated goals for JAXR:
■ Support for industry-standard XML registry functionality

■ Support for registration of member organizations and enterprises
■ Support for submission and storing of arbitrary registry content
■ Support for life cycle management of XML and non-XML registry content
■ Support for user-defined associations between registry content
■ Support for user-defined multilevel classification of registry content along multiple
user-defined facets
■ Support for registry content querying based on defined classification schemes
■ Support for registry content querying based on complex ad hoc queries
■ Support for registry content querying based on keyword-based search
■ Support for sharing of Web services
■ Support for sharing of business process between partners
■ Support for sharing of schemas between partners
■ Support for sharing of business documents between partners
■ Support for trading partner agreement assembly and negotiation
■ Support for schema assembly
■ Support for heterogeneous distributed registries
■ Support for enabling publish/subscribe XML Messaging between parties
JAXR is expected to support not only UDDI, but other similar registry standards (such as ebXML), as well.
JAX-R provides Java XML API for working with service registries
Page 81
Page 82
Emerging standards for Web services and J2EE (1 of 2)

J2EE Evolution
Several standards are emerging in the J2EE space that related to Web services; some will be ready for
inclusion within J2EE 1.5. Here is a brief overview of each of them:
■ Java Architecture for XML Binding (JAXB): The goal of JAXB is to provide a mapping
between XML and Java that will enable users to manipulate and create XML documents by
binding the elements to a set of Java classes that can be more easily manipulated. This
includes support or validation, marshaling, and unmarshaling of data. User benefits of JAXB
would include a much easier model to manipulate XML instance documents than a pure
DOM model. The Java objects produced can easily be traversed, added, and deleted as part
of a normal Java programming model. JAXB 1.0 came out January 2003. JAXB 2.0 is
currently underway, and it is being incorporated with the JAX-RPC 2.0 specification for J2EE
1.5. This will enable a common binding mechanism for all of XML schema.
■ Web services metadata for Java Platform (JSR 181): This JSR reduces the amount of
information required to implement Web services on J2EE by using metadata to declaratively
specify the Web service that each application provides. The metadata annotates the Java
source file that implements the Web service. While the metadata is human readable and
editable using a simple text editor, graphical development tools can represent and edit the
Java source file using higher levels of abstraction specific to Web services. This specification
relies on JSR 175 specification: "A Program Annotation Facility for Java programming
language."
■ JSR 224 (JAX-RPC 2.0): JAX-RPC 2.0 will enhance the support offered in JAX-RPC 1.1 to
include the following:
a. Delegate data binding related tasks to JAXB 2.0

b. Support SOAP 1.2, WSDL 2.0
c. Support WS-I Basic Profile 1.1
d. Support JSR 175, JSR 181
e. Support Web services security (JSR 183)
f. Support document and message centric usage by supporting client side asynchronous
operations, non-HTTP transports, and session management
Page 83
Emerging standards for Web services and J2EE (2 of 2)

Service Data Objects
Service Data Objects (SDO) is a standard that seeks to simplify and unify the way in which applications
handle data. Using SDO, application programmers can uniformly access and manipulate data from
heterogeneous data sources, including relational databases, XML data sources, Web services, and
enterprise information systems. The specification is intended to simplify the programming model for data
access.
The problem
Several challenges are encountered in designing and implementing data access layers within applications.
These include:
■ Many different models and APIs exist for data retrieval, data representations, metadata
retrieval, metadata representations, and logic components
■ No reasonable API available for “typed” XML data
■ Lack of support for standard application patterns such as optimistic concurrency, and
pagination of large data sets
■ Programmers focus on learning technologies, rather than solving business problems
■ Programmers do a lot of low-level coding
■ Tooling does not offer an easy development experience for J2EE application developers
Data access problem and the Service Data Object’s solution
Service Data Objects (SDO) are a data programming architecture and API for the Java platform that
unifies data programming across data source types, provides robust support for common application
patterns, and enable applications, tools, and frameworks to more easily query, view, bind, update, and
introspect data.
Service Data Objects simplifies and unifies the way in which applications handle data. Using SDO,
application programmers can uniformly access and manipulate data from heterogeneous data sources,
including relational databases, XML data sources, Web services, and enterprise information systems. For
more information about the goals and architecture of SDO, see the white paper titled "Next-Generation
Data Programming: Service Data Objects," available at
http://www.ibm.com/developerworks/java/library/j-sdo/index.html .
SDO solution
Page 84
As the above figure demonstrates, SDO is based on the concept of disconnected data graphs. Under the
disconnected data graphs architecture, a client retrieves a data graph (that is, a collection of
tree-structured or graph-structured data objects) from a data source, mutates the data graph, and can
then apply the data graph changes back to the data source.
The task of connecting applications to data sources is performed by data mediator services. Client
applications can query data mediator services and get a data graph in response. Client applications can
then send an updated data graph to a data mediator service to have the updates applied to the original
data source. This architecture allows applications to deal principally with data graphs and data objects.
SDO enables both a static (or strongly typed) programming model and a dynamic (or loosely typed)
programming model. This enables a simple programming model without sacrificing the dynamic model
needed by tools and frameworks.
SDO provides a core set of components and services, which are then augmented by SDO-enabled tools
and frameworks. The SDO architecture includes the following components.
SDO core The core SDO specification contains the primary components
that programmers routinely work with, including data objects,
which represent the data, and data graphs, which represents
the data graph. The SDO specification also provides a
metadata API that allows clients to introspect the data model.
The SDO metadata API enables the tools and frameworks to
work uniformly with heterogeneous data sources. The metadata
API supports essential concepts from other more
comprehensive metamodels, such as W3C XML schema, the
SQL relational model, and the Essential Meta Object Facility
(EMOF).
SDO data mediator A data mediator service provides access to data sources. Data
services mediator services can create data graphs by reading data from
back-end data sources, and can update data sources based on
changes made to data graphs. Data mediator services can
come in various shapes and sizes, and could include, for
example, XML mediators that can read and write to XML data
sources, relational mediators that can read and write to
JDBC-based data sources, application-defined entity models, or
even mediators that accept XML query and read and write a
variety of XML and non-XML data sources. Specifications for
data mediator services are on the SDO roadmap.
SDO-enabled tools SDO-enabled tools include code generators, meta-model

converters, schema converters, data modeling tools, schema
Page 85
modeling tools, and others.
SDO-enabled The runtime environments and frameworks work with the

runtime various components in SDO to perform a variety of tasks, such
environments and as data binding to user interface components. The SDO
frameworks architecture is a key enabler for these runtime environments
and frameworks.
SDO components and services
IBM and BEA jointly developed SDO 1.0 specification in November 2003. SDO was submitted as JSR 235
to the JCP for inclusion with other Java specifications. Eclipse has an open-source (EMF-based)
implementation of SDO available for users to use today. WebSphere Application Server 6.0 supports SDO
1.0.
Page 86
Summary
Web services protocol adoption
In this module, you have examined the key Web services protocols as they are defined to date. As the
Web services technologies have matured, you have seen the foundation protocols of SOAP, WSDL and
UDDI build the platform for the addition of quality of service using the WS-Security and
WS-ReliableMessaging specifications. Along with laying a solid foundation for the growth of Web services
standards, you are also seeing the evolution of the foundation protocols in specifications such as SOAP,
MTOM, and ASAP. Along with the foundation evolution, new specifications are beginning to appear
around the enterprise space to address such things as transactions, business process management, and
manageability.
The following table summarizes the adoption of the Web services protocols to date.
Adoption of Web services protocols
The following list details each section of the table above.
■ Mainstream - Standard ratified or wide-scale adoption.

■ Early adoption - More robust implementations available and protocol well into standards
process, encourages production usage by user organizations.
■ Experimentation - The protocols listed under experimentation are not yet approved
standards, but implementations of them are available and can be used for research, or by
organizations that are comfortable adopting the leading edge.
■ Specification - Exists only as draft specification. Any usage requires hand-coding.
Page 87
References
The following resources provide further reading or sources of help.
■ Apache Foundation. http://xml.apache.org

■ IBM alphaWorks. http://www.alphaworks.ibm.com
■ IBM developerWorks Web services. http://www.ibm.com/developerworks/webservices/
■ IBM Web services. http://www.ibm.com/software/solutions/webservices/
■ Java Community Process (JCP). http://www.jcp.org
■ Organization for the Advancement of Structured Information Standards (OASIS).
http://www.oasis-open.org/
■ SDO specification at http://www.ibm.com/developerworks/library/j-commonj-sdowmt/
■ Web Services Interoperability Organization (WS-I). http://www.ws-i.org
■ Web Services Protocol Summary. http://roadmap.cbdiforum.com/reports/protocols
■ White paper: Next-Generation Data Programming: Service Data Objects at
http://www.ibm.com/developerworks/java/library/j-sdo/index.html
■ World Wide Web Consortium (W3C). http://www.w3.org
Page 88
Test your knowledge

The online version of this lecture contains a quiz you can take to test what you learned in this module.
Correct responses and your score are displayed after you answer the questions, but the scores are not
reported or recorded. You may take the quiz as often as you want.
To find the quiz, open the online version of Web services standards to the Test your knowledge page in
the module.
Page 89

SW719 Topic 1

Uploaded by

Document Information

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

SW719 Topic 1

Uploaded by

Copyright:

Available Formats

Technologies and Standards for Service-Oriented

Architecture Project Implementation

Web services standards

About this module

Before completing this module

What is the Web services stack?

Web services stack

Web services are based on open, industry standard architecture

Key XML and Web services standards bodies (1 of 3)

Key XML and Web services standards bodies (2 of 3)

Key XML and Web services standards bodies (3 of 3)

IBM's role in developing XML and Web services standards

IBM’s support of open standards

IBM: The leader in Web services standards development

a. JSR 74, Public Key Cryptography Standards 1.0

Open source contributions

W3C, OASIS and WS-I.org submissions

IBM: Leadership in implementing Web services standards

OASIS participation comparison

IBM emerging technology and standards process

Innovation, standardization and deployment

IBM development platform: Built upon standards

Web services standards and specifications

Evolution of standards within IBM

Web services standards and specifications

Web services and ebXML

Web services standards: Key standards

■ XML (Extensible Markup Language)

Messaging and encoding (1 of 3)

■ One for the RPC request

■ Use of SOAP encoding is anticipated, but not required

The following figure illustrates SOAP Envelope concept

Message Transmission Optimization Mechanism (MTOM)

Messaging and encoding (2 of 3)

■ Standard message exchanges to be implemented by service providers that wish to

■ WS-BaseNotification defines the Web services interfaces for NotificationProducers and

Messaging and encoding (3 of 3)

Protocol or Description Standards Initially Current Alternatives

Protocol or Description Standards Initially Current Alternatives

Description and discovery (1 of 4)

■ Web Services Description Language (WSDL) describes a Web service. It provides a

Description and discovery (2 of 4)

The key benefits WSDL provides are:

WSDL document structure

Description and discovery (3 of 4)

Protocol or Description Standards Initially Current Alternatives

Description and discovery (4 of 4)

■ A platform-independent framework for describing services, discovering businesses, and

Protocol or Description Standards Initially Current Alternatives

Tying together the base protocols

Web services standards: Quality of service (1 of 4)

Web services standards: Quality of service (2 of 4)

Web services security stack

characteristics of the credentials that are included with a message.

third parties and intermediaries).

Web services standards: Quality of service (3 of 4)

Reliable messaging model

with the Web services protocols.

Web services standards: Quality of service (4 of 4)

Protocol or Description Standards Initially Current Alternatives

Web services standards: Enterprise

■ WS-Coordination – provides a pluggable coordination framework supporting

■ A business activity may consume many resources over a long duration.