This article continues from the Web Services Journal article
"Building Blocks - An overview of Web services technology" (WSJ Vol.
2, issue 7). In Part I, I provided a functional classification of
Web services technologies and examined technologies in the areas of
service description, communication protocols, complex payloads,
on-site inspection, and general discovery. In this installment, we
examine technologies that address enterprise strength issues, such as
transactions, security, and routing, and technologies that enable B2B
collaboration.
Transactions
There are two kinds of transactions in the Web services space:
background transactions and foreground transactions.
Background Transactions
Web services are typically front-end applications that deal with some
back-end systems for persistent data storage and manipulation. Though
a particular Web service may not support user-initiated transactions,
simple invocation of the service may trigger transactional operations
on the back-end systems that the Web service deals with. For example,
a Web service performing updates on back-end systems may operate
transactionally in order to guarantee ACID semantics. Transactions
that take place without the involvement of the Web service user are
called background transactions. In a background transaction, the Web
service doesn't support the concept of transaction at its interface
level, and hence doesn't allow itself to be invoked transactionally.
To implement a Web service that performs only background
transactions, we don't need any new technologies. The transaction
semantics provided by the back-end systems with which the Web service
interacts provide the intended behavior. For example, if a Web
service deals with a database to accomplish its job, it can rely on
the transactional interface (such as XA or simple SQL commands like
"begin transaction") provided by the database. Similarly, if a Web
service is dealing with CORBA or EJB back ends, the respective
transactional interfaces (such as OTS or JTS) provided by the
back-end systems would suffice.
Note: In order to ensure background transactional capabilities, the
back-end system must support transactions. It's possible to aggregate
Web services in such a way that a Web service may become a back end
for another Web service. To ensure background transactional
characteristics, however, the Web service at the back end must
support transaction at its interface level.
Foreground Transactions
Unlike background transactions, foreground transactions allow users
to initiate and terminate transactions on the Web service, thus
combining many operations (and possibly using many Web services)
under one transaction.
Existing transaction technologies such as XA, OTS, and JTS cannot be
directly applied to support foreground transactions on Web services.
In the Web services world, transactions can span corporate boundaries
with no single coordinating authority. Transactions can be long; the
systems and resources involved are loosely coupled, and they work
over networks prone to failure. Foreground transactions in Web
services don't typically fit the traditional XA notion of a
transaction.
New efforts are under way to arrive at standardized message formats
and interaction models to support foreground transactions. In March
2001, OASIS formed a technical committee to work on an XML-based
technology for transactions on the Internet. On May 1, 2002, that
group released a 0.9.6.2 draft version of the specification called
BTP.
BTP - Business Transaction Protocol
The Business Transaction Protocol (BTP) is designed to allow
coordination of application work between multiple participants
controlled by autonomous organizations. BTP's ability to coordinate
between services offered by autonomous organizations makes it ideally
suited for Web services. At its core, BTP is an interoperation
protocol that defines roles played by participating software
entities, the messages that pass between such entities, and the
obligations and commitments of participating entities.
BTP is based on a concept of a business transaction that differs from
traditional ACID transactions. Business transactions carry a more
relaxed notion of a transaction than ACID transactions. For ACID
transactions, there's only one successful outcome to a transaction -
the transaction completely succeeds. In a business transaction,
multiple successful outcomes are possible. Business rules determine
the outcome of a transaction. In a business transaction, participants
can come and go and transactions can proceed to a commit, even though
some participants may not favor the final outcome. In a business
transaction, there is no central coordinating authority. Parties
involved in a business transaction have distinct and autonomous
application systems, and they communicate through well-defined
service interfaces.
BTP provides a layered approach to meet the requirements of business
transactions. It uses a two-phase coordination protocol to ensure
the overall consistent state of the application. At its lowest
levels, BTP supports two types of transactions: Atoms and Cohesions.
An Atom is the standard atomic transaction that behaves like the
existing XA-based, two-phase commit transactions. Within an Atom, the
transaction either fully succeeds or rolls back. BTP demands that
ACID properties be maintained within an Atom.
A Cohesion is a non-ACID transaction that can move to a successful
outcome even if some participants don't favor the final outcome. A
Cohesion typically consists of a set of Atoms manipulated by the
business rules of the initiator of the transaction. It is run by a
voting process in which the initiator holds the final approval or
rejection vote. Many Atoms can be enlisted as part of the
transaction, and Atoms are free to join or leave the transaction
using an enrollment or resign process.
The transaction model of BTP identifies the different roles played by
the participating entities and defines the relationships,
commitments, obligations, and interaction model between the different
roles. The specification defines the messages that flow between
different roles at different stages of the transaction.
BTP messages are encoded in XML, allowing easy integration with
XML-based Web services. BTP defines default binding to the SOAP and
SOAP with Attachments specifications, further facilitating its use in
Web services.
Security
As Web services becomes mainstream, a key issue is security. Ensuring
integrity, confidentiality, message authentication, and security is
critical to the acceptance and use of Web services.
The issue of online security isn't new to the industry. There are
many existing security technologies, such as the public key
infrastructure, Kerberos, X.509 certificates, and SSL. There are also
many new security initiatives in the XML area, some of which
specifically target Web services. This section focuses on these new
XML-based security initiatives, which apply to XML-based messaging in
general and to Web services in particular.
Some of the main XML-based security initiatives are:
- XML Encryption
- XML
- XKMS
- WS-Security
- SAML
- XACML
XML Encryption
The XML Encryption initiative is an effort by the W3C to specify a
process for encrypting data and representing the result in XML. An
XML document can be encrypted in its entirety using existing
encryption technologies. However, there's no standard way to apply
different encryption treatments to different parts of the document.
The ability to encrypt individual XML elements or groups of elements
enables authorized viewing of different pieces of the document by
different parties.
The XML Encryption Specification achieves just that. Using XML
Encryption, we can encrypt only the content of an element, or an
entire element, or the entire document. In these cases, the encrypted
portion is replaced with an EncryptedData element. An example of
encrypting a part of a simple XML document is shown in Listing 1.
Listing 2 shows the encryption of the entire CreditCard element
(encrypted document). This example is taken from Section 2.1 of the
XML Encryption Specification (www.w3.org/TR/xmlenc-core).
The raw encrypted data is contained in the CipherValue element.
Unlike the example, if the encrypted data is referred through a URI,
the reference is contained under a CipherReference element. XML
Encryption allows encryption of EncryptedData elements. However, the
EncryptedData element cannot be a parent or child of another
EncryptedData element. Also important in XML Encryption is the
EncryptedKey element, which is similar to EncryptedData, except that
the data encrypted is always a key value. The schema for both the
EncryptedData and the EncryptedKey element allow other optional
information, such as encryption algorithm and key information.
The W3C published a Candidate Recommendation in March 2002.
XML Signature Specification
The XML Signature Specification was jointly developed by the IETF and
W3C and published as a W3C Recommendation in February 2002. The XML
Signature Specification defines XML syntax and processing rules for
creating and representing digital signatures. As with XML Encryption,
existing technologies can be successfully used for digitally signing
an XML document as a whole. However, difficulty arises when parts of
an XML document need to be signed by different parties. The XML
Signature Specification enables digital signing of specific parts of
an XML document.
The XML Signature Specification defines a schema for capturing the
result of a digital signature operation applied to any arbitrary
data. It can be applied to any digital content and is not limited to
XML content. XML Signatures are represented by the Signature element.
Listing 3 details the structure of the Signature element.
The SignedInfo element contains the information actually signed,
while the SignatureValue carries the value of the encrypted digest of
the SignedInfo element. The CanonicalizationMethod specifies the
algorithm used to canonicalize the SignedInfo element before it's
digested, and the SignatureMethod specifies the algorithm used to
convert the canonicalized SignedInfo into SignatureValue. The
Reference element carries the digest method and the digest value of
the resource to be signed. The resource is identified by the URI
attribute. Signature validation requires that the signed data object
be accessible as a URI referenced from XML Signature or be embedded
within the XML Signature. The KeyInfo element indicates the key to be
used to validate the signature. The Transforms element lists the
processing steps applied to the resource's content before it was
digested.
The XML Signature Specification is an important security technology
in XML with widespread adoption.
XML Key Management Specification
XKMS specifies protocols for distributing and registering public keys
for use with
XML Signature and XML Encryption. XKMS greatly simplifies the
management of authentication and XML Signature key elements by
creating a Trust Service based on the Web services model using SOAP
1.1 and WSDL. The client of the service can delegate part or all of
the tasks required to process XML Signature KeyInfo elements. The
service insulates user applications from the complexity and syntax of
the underlying public key infrastructure (PKI), enabling the PKI to
be based upon a different specification, such as X.509/PKIX, SPKI, or
PGP.
XKMS is an important component in security as applied to XML
documents. It has been published as a W3C Note, and W3C has started
an XML Key Management working group.
WS-Security
While XML Encryption, XML Signature, and XKMS deal with security
related to XML documents in general, WS-Security deals with encoding
security information in Web services, specifically in SOAP messages.
In a nutshell, WS-Security defines a standard set of SOAP headers
that can be used to implement message integrity, message
confidentiality, and propagation of security information in Web
services. WS-Security itself doesn't define any new method for
message integrity or confidentiality, but rather provides a standard
way to encode this information in SOAP messages.
WS-Security achieves this by leveraging XML Signature and XML
Encryption in conjunction with security tokens. A security token is
defined as a representation of security-related information, such as
a user name, an X.509 certificate, or a Kerberos ticket. WS-Security
defines a general-purpose mechanism for associating these security
tokens. In WS-Security encoding, all the security-related information
is carried under a Security header element that can be targeted to
any SOAP node using the SOAP actor attribute.
The WS-Security Specification was published jointly by IBM,
Microsoft, and VeriSign in April 2002 and had at the time of this
writing not been submitted to any standards body. IBM and Microsoft
have also proposed other security initiatives.
Security Assertion Markup Language
SAML is an effort by the OASIS Security Services technical committee
to develop an XML-based framework for exchanging security
information. Though SAML supports other usage scenarios, its main
goal is to enable single sign-on. SAML envisions a scenario where
users can log on to a site, submit their credentials to the SAML
security engine on that site, get security information as a response,
do their work, and move on to another site with the SAML security
information traveling along with them, avoiding another logon session
at the new site.
Security information is expressed in the form of assertions about
subjects, where a subject is an entity with an identity (either human
or computer). Assertions convey information about attributes of
subjects, authentication acts performed by subjects, and
authorization decisions about subjects' access rights. Assertions are
issued by SAML authorities (any SAML-aware security engines).
SAML defines a schema for the assertions and a request-response
protocol for the client-SAML authority communication. Though this
protocol can be bound to many underlying communication and transport
protocols, SAML defines a default binding to SOAP over HTTP. As part
of this binding, SAML defines how assertions can be carried in SOAP
messages.
SAML 1.0 was published in April 2002 but is yet to be approved as a
final specification. SAML relies on XML Signature for the signing of
request-response messages. While there is no conflict of interest
between WS-Security and SAML, it appears that some coordination is
possible between the SOAP binding of SAML and WS-Security SOAP
headers.
Extensible Access Control Markup Language
XACML is closely related to SAML but focuses more on access control
and rights management by providing a representation for expressing
policies and rules for information access. Specifically, XACML is
expected to define XML representations for rules that specify who can
exercise which access privileges for a particular XML document.
XACML is also from OASIS, which is expected to coordinate closely
with SAML and to adopt SAML work as baseline documents. By May 2002,
this group had published a 0.13 version of the proposal.
With all these new initiatives, good progress is being made in the
area of Web services security, although there's still a long way to
go to provide convenience of use, reliability, and robustness.
Routing
In the Web services model, communication protocols such as SOAP
depend on binding to underlying transport protocols to actually
exchange a message. These transport protocols define their own
message path models and message exchange patterns, which differ from
the communication protocols message model. This section looks at
technologies that define message routing in communication protocols.
Microsoft announced a SOAP-based routing protocol called WS-Routing
in October 2001.
WS-Routing
Although SOAP supports the notion of intermediaries and provides some
ability to address parts of a message to intermediaries, it doesn't
define a mechanism for sending a message from one node to another.
WS-Routing is a simple, stateless protocol that enables the routing
of it messages in an asynchronous manner over a variety of
transports, such as TCP, UDP, and HTTP. WS-Routing enables the entire
message path to be described directly within the SOAP Envelope. To
enable such routing, WS-Routing defines a new SOAP header named Path
containing four new elements: from, to, fwd, and rev.
The from element indicates the originator, the to element indicates
the ultimate receiver, the fwd element contains the forward message
path, and the rev element contains the reverse message path. The
reverse message path is optional and exists to support two-way as
well as one-way messages. WS-Routing doesn't expect the entire
message path to be determined in advance; with some restrictions, the
intermediaries can dynamically insert additional intermediaries into
the message path.
It's important to note that WS-Routing doesn't define the means for
reliable or secure messaging. However, WS-Routing may possibly be
combined with WS-Security and new SOAP-based reliability protocols to
provide reliable and secure messaging.
Microsoft published the WS-Routing specification in October 2001, but
it hasn't yet been submitted to any standards body. Microsoft has
also released a closely related protocol called WS-Referral, which
allows SOAP nodes in a message path to be dynamically configured to
delegate part or all of their processing responsibilities to other
SOAP nodes. Discussing WS-Referral goes beyond the scope of this
article.
B2B Collaboration
In Part I, we discussed service description standards as part of the
discovery stack of Web services technologies. At the higher end of
the discovery stack are the standards that help model business
processes to enable cross-enterprise business-process automation for
higher levels of automated B2B collaboration. Automating business
processes across corporate boundaries is key to truly realizing the
potential and promise of e-commerce.
Complete Protocols
So far, we've looked at technologies that address discrete functional
areas of Web services. There are also some efforts that provide
several of these technologies under one umbrella. One of the
well-known efforts in this area is ebXML.
EbXML
EbXML is the result of a joint effort by UN/CEFACT and OASIS to
develop an XML-based, modular, end-to-end solution for enabling
secure, global, electronic interoperability using open standards and
replacing EDI (Electronic Data Exchange). EbXML is based on three
main goals:
1. To provide an infrastructure for data communication
2. To provide a framework for commercial interoperability
3. To provide a mechanism to discover, agree, and conduct business
Based on these goals, the group published a set of three core
specifications in May 2001. They are:
1. The Messaging Service Specification
2. The Registry and Repository Specification
3. The CPPA Specification
These specifications don't depend on one another and can be used separately.
Although it's been a year since the release of the ebXML
specifications, there are few implementations that support it. Most
of the focus is on WSDL, SOAP, UDDI, and other developing standards.
Note that ebXML is still an ongoing effort and that different groups
are in the process of releasing newer versions.
Conclusion
This two-part article has provided a high-level overview of the
technologies that address the different functional areas of Web
services. So far, preliminary development in these areas has come
from individual companies, groups of companies, and in some cases
standards organizations. Interoperable standards are a must for Web
services to enable cross-enterprise communication and loosely coupled
systems. Consortiums and standards bodies are getting more and more
involved in adapting and building on these early developments. These
efforts should help move Web services from the current era of trial
applications into mainstream use.
Resources
Author Bio
Murali Janakiraman is Rogue Wave's software architect for the XML
Products team. He has been a developer, senior developer, and tech
lead on almost all of Rogue Wave's database products, including
DBTools.h++, JDBTools, DBTools.h++ XA, and RWMetro.
murali@roguewave.com
Building Blocks, Part II, by Murali Janakiraman
WSJ Vol 02 Issue 08 - pg.60
Listing 1: Encrypting part of an XML document
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith</Name>
<CreditCard Limit='5,000' Currency='USD'>
<Number>4019 2445 0277 5567</Number>
<Issuer>Example Bank</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
Listing 2: Encryption of the entire CreditCard element
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith</Name>
<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</PaymentInfo>
Listing 3: XML digital signature structure
<Signature ID?>
<SignedInfo>
<CanonicalizationMethod/>
<SignatureMethod/>
(<Reference URI? >
(<Transforms>)?
<DigestMethod>
<DigestValue>
</Reference>)+
</SignedInfo>
<SignatureValue/>
(<KeyInfo>)?
(<Object ID?>)*
</Signature>
Note: ? denotes zero or one occurrence, + denotes one
or more occurrence, and * denotes zero or more occurrences.
All Rights Reserved
Copyright © 2004 SYS-CON Media, Inc.
E-mail:
info@sys-con.com
