Prev
Page | Table of Contents
Appendix:
Standards
|
| - Advertising - |
 |
The Reactivity XML Firewall delivers instant and sustainable
XML Web services security in an appliance securing all XML Web
services traffic. The Reactivity XML Firewall allows enterprises
to protect against XML Threats while maximizing application
productivity. The Reactivity XML Firewall is the market's most
powerful and configurable security policy manager, with turnkey
infrastructure integration and optimized traffic throughput.
Learn more
about Web Services Security... |
| |
|
|
The following is a more detailed discussion of critical industry
standards discussed in the paper. It should be noted that while
vendors try to present the emerging Web Services platform as coherent,
it's really a series of in-development technologies. Often there
are, and may remain, multiple approaches to the same problem.
SOAP (Simple Object Access Protocol)
SOAP and WSDL are document formats. SOAP is used to encode messages
such as remote procedure calls (RPC) for request-response messages.
WSDL is used to describe a Web Service's interface. In essence,
SOAP and WSDL facilitate distributed computing. SOAP provides a
simple distributed computing mechanism that can be used over multiple
transports. It also defines a way to perform RPC's using HTTP as
the underlying communication protocol.
Traditionally, distributed computing standards have been based
on binary protocols that require a particular infrastructure. SOAP,
in contrast, is flexible in nature. Any application that can open
a connection to the server, pass an XML document, and receive one
in return can be a client. SOAP is agnostic with respect to programming
language, platform, infrastructure, and vendor.
Submitted in 2000 to the W3C by IBM, Microsoft, UserLand, and DevelopMentor,
the further development of SOAP is now in the care of the W3C's
XML Protocols Working Group. This effectively means that SOAP is
frozen and stable until such time as the W3C Working Group delivers
a new specification.
WSDL (Web Services Description Language)
It is necessary to have a standard way to document what messages
the Web Service accepts and generates the Web Service agreement
(or contract). The WSDL is an XML-based contract language jointly
developed by Microsoft and IBM. WSDL provides a way for service
providers to describe the basic format of Web Service requests over
different protocols. WSDL is used to describe what a Web Service
can do, where it resides, and how to invoke it. UDDI registries
describe numerous aspects of Web Services, including the binding
details of the service. WSDL fits into the subset of a UDDI service
description. Having this standard mechanism makes it easier for
developers to access tools to create and interpret contracts.
WSDL 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 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; a collection of ports
defines a service.
UDDI (Universal Description, Discovery and Integration Service)
UDDI specifies a mechanism for Web Service providers to advertise
the existence of their Web Services and for Web Service consumers
to locate Web Services of interest. Using a UDDI interface, businesses
can dynamically connect to services provided by external business
partners.
UDDI provides three basic functions known as publish, find, and
bind:
- Publish: How the provider of a Web Service registers itself
- Find: How an application finds a particular Web Service
- Bind: How an application connects to and interacts with a Web
Service
A UDDI registry contains three kinds of information, described
in terms of telephone directories:
- White pages: Information such as the name, address, telephone
number, and other contact information of a given business
- Yellow pages: Information that categorizes businesses
- Green pages: Technical information about the Web Services provided
by a given business
A UDDI registry is similar to a common object request broker (CORBA)
trader, or it can be thought of as a DNS service for business applications.
A UDDI registry has two kinds of clients: businesses that want to
publish a service (and its usage interfaces), and clients who want
to obtain services of a certain kind and bind programmatically to
them.
For more advanced applications, technologies such as XAML, XLANG,
and XKMS, may be also be integrated. Although not universally adopted
as mandatory, these other services are being developed rapidly so
readers should understand what they do.
XLANG (XML-based language)
XLANG is an XML-based language that supports complex transactions
that may involve multiple Web Services. XLANG is the business process
automation language utilized by Microsoft's BizTalk Server. Automation
of business processes based on Web Services requires a notation
for the specification of message about exchange behavior among participating
Web Services. An XLANG service description extends a WSDL service
description with an element describing the behavioral aspects of
the service. XLANG is expected to serve as the basis for automated
protocol engines that can track the state of process instances and
help enforce protocol correctness in message flows. XLANG makes
a notation for expressing the compensatory actions for any request
that needs to be undone. The Web Services infrastructure can leverage
XLANG specifications to perform complex undo operations.
XAML (Transaction Authority Markup Language)
XAML is intended to enable a whole new class of dynamic, highly
distributed computer interactions known as "business web transaction
processing" or BWTP, as distinguished from OLTP, or classical
online transaction processing. Business web transactions involve
Web Services from multiple organizations on the web and must coordinate
the low-level operations of commit, cancel, retry, and compensate
(undo or reverse), in order to ensure business-level transaction
integrity. The XAML initiative is so named because it is an application
of XML that defines transactional interaction among Web Services,
based on interfaces as defined by the widely adopted XA (Transaction
Authority) standard and by JTA (Java Transaction API).
XKMS (XML Key Management Specification)
XKMS is an effort by Microsoft and Verisign to integrate PKI and
digital certificates (which are used for securing Internet transactions)
with XML applications. The key idea is to delegate the signature
processing to a trust server on the Web, so that thin or mobile
clients don't have to carry around the knowledge to do this themselves.
XKMS relies on the XML Signature specification already being worked
on by W3C and on anticipated work at W3C on an XML encryption specification.
WS-License
WS-License describes a set of commonly used license types (credentials
that are signed assertions) and describes how they can be placed
within the WS-Security credentials tag. Specifically, the WS-License
specification describes how to encode X.509 certificates and Kerberos
tickets as well as how to include opaque encrypted keys. WS-License
includes extensibility mechanisms that can be used to further describe
the characteristics of the licenses that are included with a message.
WS-Referral
WS-Referral is a protocol that enables the routing strategies used
by SOAP nodes in a message path to be dynamically configured. SOAP
itself provides a distributed processing model where SOAP messages
can have content destined for specific processing nodes. WS-Routing
adds to SOAP the capability of describing the actual message path.
WS-Referral provides a mechanism to dynamically configure SOAP nodes
in a message path to define how they should handle a SOAP message.
It is a configuration protocol that enables SOAP nodes to delegate
part or all of their processing responsibility to other SOAP nodes.
WS-Routing
WS-Routing is a simple, stateless, SOAP-based protocol for routing
SOAP messages in an asynchronous manner over a variety of transports
like TCP, UDP, and HTTP. With WS-Routing, the entire message path
for a SOAP message (as well as its return path) can be described
directly within the SOAP envelope. It supports one-way messaging,
two-way messaging such as request/response and peer-to-peer conversations,
and long running dialogs.
WS-Security
WS-Security provides a security language for Web services. WS-Security
describes enhancements to SOAP messaging providing three capabilities:
credential exchange, message integrity, and message confidentiality.
These three mechanisms can be used independently or in combination
to accommodate a wide variety of security models and encryption
technologies. WS-Security provides a general-purpose mechanism for
associating licenses with messages. No specific type of credential
is required. Message integrity is provided by leveraging XML Signature
and licenses to ensure that all messages are transmitted without
modifications. Similarly, message confidentiality leverages XML
Encryption and licenses to keep portions of a SOAP messages confidential.
These are a small subset of Web Services standards; for a more
complete set of standard definitions, visit XML.com.
XML.com features a rich mix of information and services for the
XML community.
The standards glossary can be found at http://www.xml.com/pub/a/2002/01/09/soap.html.
Prev Page | Table
of Contents
Barbara Angius Saxby (barbara@accelentmarketing.com)
founded Accelent (www.accelentmarketing.com)
to help software startups accelerate marketing strategies, planning,
and execution. She specializes in positioning and launching enterprise
infrastructure and application companies. Barbara is a senior marketing
executive with over 20 years experience in strategic marketing management
and has done extensive work internationally.
| 
