Sample chapter from: Web Services Implementation Guide
Authors:
Brian Travis and Mae Ozkan
About the book:
Getting value from stuff you don't own is a compelling idea. Just think, someone else has created something that has value, and has made it available to you. You can now leverage its value in ways that makes all parties richer. That's the promise of web services.
You need to know about web services. The advent of standards-based web services marks a new era of system development. First mainframe, then client-server, the Web, now web services makes it possible to leverage every legacy system of the past and do so much more with your information assets.
This book will show you what a web service is, and how you can align your systems to take advantage of this new concept in system integration. This book covers the concepts and technologies of web services.
Web Services Implementation Guide is a multiple-volume set. Volume 1 shows you how to align your thinking and systems to get the most of web services. Volume 2 is a technical treatise for developers. Volume 3 discusses real-life implementations of web services solutions.
Get programs talking to each other, because we want to leverage
the existing technology.
Be cheap, compact and scalable for all parties, because we
want to have web services everywhere, providing services to
everyone, using any device.
Build on the infrastructure, because it's already paid for.
The best way to get there is to build an environment based on standards that
everyone agrees on.
In this chapter, we will build a house of standards showing where each one
fits, and how they relate to each other. It is only by using internationally recognized
standards that you can create systems that can communicate with your trading
partners around the world.
Why Standards?
Standards are designed to be suitable for a broad segment of users. The standards
business is one that we would classify with the creation of laws and sausage. That is, if
you want to respect any of them, do not watch them being made.
Standards are created by a form of government called "standards committees".
By government, we do not necessarily mean some national bureaucracy that deals
with everything from the definition of "free range chicken" to the defense of national
borders. By government, we are talking about an organization that is chartered with
deciding or determining influence.
One way of describing the people who populate standards committees is to
think about your high school graduating class. Remember the guy who was really
smart? This is the guy who did not really excel at anything in particular, but you knew
that he would make a difference some day. This is the guy who could have gone into
medicine or law or technology. He was really smart, but you knew he could probably
never run his own organization because he did not have the entrepreneurial spirit. The
word "nerd" comes to mind, but we mean that in the most endearing way.
That guy is now on a standards committee somewhere. He is doing his best to
represent the needs of his constituency. That constituency consists of the people and
organizations deemed by his employer to be important to the success of the organization.
If it were up to him to come up with a standard, it would look just like his employer's
specification for a particular solution.
If you put a dozen people like this in a room for a year with a typewriter, they
would either run from the room screaming, or they would agree on a compromise
that met the expectations of at least a majority of the members.
This is how we get most of our international standards. It is the result of a dozen
nerds in a room for a year.
There is not a single standard that everyone agrees is the best possible specification.
Rather, standards are "good enough" to be implemented. They get their value,
not from their superior technology, but from the fact that everyone agrees they are
good enough.
Let us say that again. Standards are good because everyone agrees they are
good.
Because standards are good enough, there are plenty of organizations that will
implement them. "Plenty of organizations" means that there is a market for other organizations
that want to sell their solutions. If a solution consisted of a proprietary
implementation designed for two organizations to exchange information, then the
market for a third-party solutions provider would be a grand total of two.
However, if everyone agrees that a particular implementation of a technology is
a Good Thing, then the potential market for solution provider products is much
larger. This means that there are more solution providers competing for the attention
of everyone who wants a solution. This competition will provide more opportunities
for everyone and drive the price down according to supply-and-demand curves.
So, standards mean that implementations are cheap.
In this chapter, we will discuss several different standards that are either completed
or are under development to be completed soon.
XML is The Alphabet
The first of these important worldwide standards is XML. XML is the specification that
is at the basis of all of the web services standards being implemented today.
XML stands for "Extensible Markup Language". However, its name is a misnomer.
XML is not really a markup language according to the traditional definition of
that term.
Rather, XML is a syntax that allows you to create your own markup languages.
XML only specifies a syntax and a set of constraints that defines a structure for marking
up your information set. The actual information set that is defined is up to you.
XML does not specify a set of tags. It is your job to define the set of tags that reflects
your data for your purposes.
XML is the foundation standard for our house of standards, as shown in Figure
27, XML is The Alphabet.
You can find out more about XML in Chapter 5, Extensible Markup Language
(XML) on page 89.
The Schema is The Vocabulary
An XML document, by itself, is not really good enough for cross-enterprise integration.
Because of the syntax rules of XML, anyone can create an XML document that is
perfectly conformant with the W3C XML specification, but is completely unreadable
by anyone else.
That is because the W3C XML specification only defines the syntax for creating a
markup language, but does not specify the tags that make up the markup language.
In order to create an environment where we can use a specific set of elements
with specific relationships to each other, we need two things.
First, we need a formal specification that all parties can agree on.
Second, we need some way to enforce that all parties are creating documents
that adhere to that agreed-upon specification.
This set of tags is commonly called a vocabulary. The formal definition of the
vocabulary is called a schema, and the tool that is used to enforce adherence to the vocabulary
is called a validating XML parser.
There are many different schema syntaxes that have been created since XML was
born. Two of these syntaxes are worldwide standards.
The first schema syntax is called the Document Type Definition (DTD). It was
published along with XML 1.0 as a formal way of creating a set of tags called a "document
type". The DTD has been implemented by all XML parsers that adhere to the
W3C XML specification.
There are some problems with the DTD syntax, however. First of all, the DTD is
expressed in a syntax that is not XML. That is, a DTD is not an XML document. Once
you learn XML syntax, you need to learn another syntax in order to create your
markup language or vocabulary if you use the DTD.
Another problem with the DTD is that it only has one data type, characters. The
DTD was designed to describe legacy typeset documents. To do that, it was acceptable
to consider everything to be a character. However, with a more modern data processing
environment, it became evident that data types other than characters would be
nice to have.
In 2001, the W3C adopted a schema syntax called XML Schema Definition, or
XSD. XSD was designed to overcome the limitations of the DTD, and provide a standard
way of defining an XML-based markup language vocabulary with rich data types.
An XSD schema can be indicated by an XML document through the use of another
W3C specification called "namespaces".
Continuing with our analogy of building a house of standards, Figure 28,
Schema is The Vocabulary shows that schemas provide a vocabulary for XML documents.
You can find out more about schemas in Chapter 5, Extensible Markup Language
(XML) on page 89.
Programming Models
Your XML documents, whether they adhere to a schema or not, are beautiful by themselves,
but really cannot do much until they are processed by an application.
There are several different programming models that can be used to process an
XML document. The two most popular are the Document Object Model (DOM) and
the Simple API for XML (SAX). These two programming models both process XML
documents, but are radically different in their approach to the interface between your
XML document and your application.
The Document Object Model provides an in-memory structure that is a tree
representation of the XML document. See Figure 29, The Document Object Model.
Because of its static nature, programming using the DOM is very easy. Once the
document is loaded, the entire structure becomes available to the programmer by using
many different built in methods and properties.
The main drawback of the DOM is its large memory footprint. The size of the
document in-memory will vary according to the size of the document and the complexity
of the structure, but it is at least twice the size of the original XML document,
after accounting for Unicode bloating.
So what if you have large documents, or are running in an environment that has
a small memory footprint? You can use another popular programming model, SAX.
SAX reads an XML document and sends a series of events to a program. The program
needs to create "handlers" that listen for these events and do something useful.
SAX is illustrated in Figure 30, The Simple API for XML.
As a result, the SAX model is very fast and efficient, because it provides information
about the document as the document is read. However, it is harder to program,
because all of the management of the document structure is the responsibility of the
programmer.
Continuing our house of standards, you can think of programming models as
creating speech. That is, doing something with the vocabulary that was defined using
the XML document and schema.
You can find out more about programming models in Chapter 6, Programming
Models on page 121.
The Simple Object Access Protocol (SOAP)
The next standard is probably the most important protocol for web services. The Simple
Object Access Protocol (SOAP) started life as a way to make it easier to access objects
over heterogeneous platforms.
The problem with heterogeneous platforms is that they each speak a different
language. They are also difficult to integrate because they are on different physical machines,
with all of the networking and firewall considerations that come with that.
SOAP was designed to be a standard envelope for delivering method invocations
across different platforms. A SOAP document usually takes the form of an HTTP POST
document, which means it can be created easily and read by any HTTP server you
have. Inside the payload of the POST document is an XML document. To illustrate
SOAP, think about making a request of a business partner about the status of a part required
for manufacture. This is shown in Figure 32, SOAP for RPC.
In this situation, a SOAP request document has the information to ask for the
product lead time. That information is packaged in a standard way by using the open
standards HTTP and XML. TheWeb server at the vendor receives this package, parses it
to find out what the request is, then initiates a workflow to determine what the product
lead time is.
Then, the vendor's system will create a SOAP response document, which is also
encapsulated as an HTTP package, and sends it back to the customer. The customer
will receive the document, parse it to determine the information returned, and continue
with his process.
In this example, we see a synchronous process. That is, the customer will send
the request and wait for a response before moving on.
SOAP can also be used for asynchronous business document transportation, as
shown in Figure 33, SOAP for Messaging.
In this example, a business document is sent from a customer's procurement application
to a vendor's resource planning application. This document is also packaged
inside of an HTTP POST document, so it can easily be read by the vendor'sWeb server.
The vendor reads the document, enters the order, and sends back a confirmation
that the order has been received.
Several days later, the goods are shipped and it is time to invoice. This is shown
in Figure 34, SOAP Business Document Response.
The vendor now creates the SOAP request document, which contains another
business document, the invoice. The customer receives it, parses the document to determine
its contents and structure, then enters it into an accounts payable system.
Then, the customer creates a SOAP response document to acknowledge that the
invoice was received, and will be paid.
The only difference between SOAP for RPC and SOAP for Messaging is conceptual.
The same standards are being used, but the way of dealing with the data is
slightly different.
Adding to our house of standards, we need three more entries, as shown in Figure
35, SOAP is The Envelope.
Low level protocols, like TCP and UDP, form the equivalent of the post office.
This is the infrastructure that moves the packages around the network. On top of that
are the transport protocols, HTTP, SMTP, and FTP, that can be used to reliably get messages
from one place to another. These protocols are the physical-world equivalent of
the mailman.
Finally, SOAP provides a standard envelope into which anything can be placed
for transport.
You can find out more about SOAP in Chapter 7, Simple Object Access Protocol
(SOAP) on page 139.
SOAP Implementations as Frameworks
SOAP, by itself, is about as useful as a paper envelope. That is, anything can be put inside,
with no rules guiding the process.
There have been several initiatives to formalize certain parts of the SOAP specification
to provide interoperability and reliable messaging.
BizTalk Framework
One of the first of these frameworks was BizTalk. BizTalk was created by a consortium
of about 80 companies that needed a way of reliably transporting messages between
trading partners. The BizTalk specification was actually created at the same time as the
SOAP specification. In fact, the first draft of BizTalk created its own envelope for sending
business documents.
With the second draft of the BizTalk Framework, the designers extended the
SOAP envelope to provide the reliable messaging, routing, and identification that is
critical to any robust e-commerce application.
You can learn more about BizTalk in Chapter 10, Web Service Frameworks on
page 219.
ebXML
Another initiative to use SOAP as a transport envelope was a team driven by the
United Nations body for Trade Facilitation and Electronic Business (UN/CEFACT)
and OASIS, an XML industry group.
Their work, ebXML Electronic Business XML), was designed to provide an
XML-based infrastructure to facilitate global trade. Their goal was to lower the barriers
of entry for small and medium size enterprises and developing nations around the
world.
The ebXML SOAP document has similar functionality to the BizTalk Framework
document.
You can learn more about ebXML in Chapter 10, Web Service Frameworks on
page 219.
Web Services Description Language (WSDL)
SOAP provides a standard envelope, but how do we know what to put inside of that
envelope? How do we know how to construct the body of the envelope and where to
send it? How do we know how to interpret the SOAP response document when it comes
back from the service?
To answer these questions, we need some kind of specification. If you and I
wanted to do business, you could post your specification on a Web site or give me a
paper. I could then take that information and code my system to create a SOAP request
and interpret the SOAP response.
However, this reliance on humans will certainly make things more difficult, and
will introduce the possibility of error.
Just like a schema is a formal description of the XML document, we need a formal
description of our web service interactions.
That formal description is called the Web Services Description Language,
WSDL. WSDL is a W3C specification that describes the services and operations that a
web service offers, and then specifies in detail how to create and interpret both sides of
the transaction.
The WSDL document acts as a contract for enabling web service interaction. The
conversation between the client and the server is illustrated in Figure 36, WSDL Contract
Negotiation.
Usually at design time, a client application will ask the web service what kind of
services and operations it offers. The web service will reply with a complete list and
detailed information about how to make them work.
The WSDL document forms a web services contract, as shown in our house of
standards in Figure 37, WSDL is The Contract.
You can find out more about WSDL in Chapter 8, Description and Discovery on
page 165 and WSDL Syntax on page 170.
Universal Description, Discovery, and Integration (UDDI)
We need one more piece before we can start using web services. As a review, we now
know that XML provides an open data description that anyone can read with an XML
parser. SOAP provides a cross-platform envelope for reliable data transfer. WSDL describes
web services by specifying details for a two-way SOAP transaction.
But what if we have a great web service that we want to tell everyone about?
How do we describe our service and get the word out? Then, how do others discover
that we have this great service? We need some kind of phone book for web services.
That phone book is the Universal Description, Discovery, and Integration
(UDDI) initiative.
UDDI was created by a consortium of organizations that needed a standard way
of describing and discovering web services. The UDDI framework consists of a series
of five powerful servers around the globe. These five servers work using the DNS
model, so any additions or changes to one gets propagated among the rest within 48
hours.
The UDDI servers maintain a database called the UDDI Business Registry (UBR).
The UBR has information about organizations in three different areas, which are
shown in Figure 38, UDDI Business Registry.
The white pages has information about an organization, such as the name of the
organization, its physical address, telephone numbers, and Web site information.
Each organization can have as many yellow pages entries as necessary. A yellow
page entry describes a single product or service, and can be classified according to a
number of different taxonomies, such as geographical area, industry code, product
type, etc.
A green pages entry tells the discoverer how to "do" e-commerce with the organization.
This might be a pointer to a Web site for more information, or it can be a
telephone number of someone in the sales department. It can also be a reference to a
WSDL document.
Adding UDDI to our house of standards, we can think of it as a phone book.
You can find out more about UDDI in UDDI on page 180.
Web Services Interoperability (WS-I)
The good news is that we have all these standards that can we can use to provide a
baseline for communicating between organizations. The bad news is that there are
too many standards, and the standards are so flexible that two parties can interpret
them in different ways and be completely incompatible.
This problem is showing up as vendors try to build tools to allow ubiquitous
interoperability among all parties.
Several high-profile vendors are attempting to fix this problem by forming an
organization devoted to interoperability among web services. This organization,Web
Services Interoperability (WS-I) is tasked with creating profiles for interoperability.
Their first profile will interpret four existing standards in a single way, allowing
all those who use the standards to use them in the same way. This is illustrated in Figure
40, Web Services Interoperability.
So why is not this work being done by existing standards organizations? Why
do we need another industry consortium when there are already plenty around? WS-I
was formed to integrate standards from other organizations. Therefore, according to
the organization's documents, it was best to set up another organization to provide
interoperability guidelines.
Making these four specifications work together will provide a good foundation
for interoperability between vendors.
The group does not intend to be a police force for verifying that certain solutions
are compatible. Rather, they will just publish these profiles, and allow the marketplace
to work out the details.
Standards Frameworks
Commerce usually involves two or more parties. Standardization is the key to any
commerce. Mailing a letter between countries is possible because of international
standards and treaties. Roads and signs are standardized. Railways work on standardized
gauges. If you want to build a house, you can choose from many different products
that work together because they are based on standard sizes.
Standards are very important in commerce. Once products, interfaces, and entities
associated with a particular trade are standardized, it paves the way for high-volume,
low-cost trading. Standards provide the infrastructure for commerce. Without
standards, the parties in a transaction would need to define everything themselves. As
a result, trade would be more costly and less profitable for all parties. However, the
mere presence of standards is not enough. There is no lack of standards for doing
e-commerce. However, these standards must be put together in an intelligent way to
be effective.
A collection of standards to achieve a specific goal is called a "framework". As
we write this, there is not a consensus on how web services frameworks should be put
together. There are many different building blocks being built, each one solving a particular
problem, such as how to send a document reliably, how to route it through intermediaries,
how to apply security, and how to orchestrate the entire process from
start to finish.
E-commerce applications from solution providers solve these problems in a proprietary
way, at best. Data should not reside in proprietary formats in e-commerce
when cross-domain interactions are required. Every specific e-commerce implementation
used by an organization requires explanation with their partners. Plus, all parties
need to keep up with changes.
As we move forward, frameworks will allow different organizations' architectures
and implementations to integrate more effectively. The World Wide Web Consortium
(W3C), Web Services Interoperability (WS-I), Universal Description,
Discovery and Integration organization (UDDI), and the Organization for the Advancement
of Structured Information Standards (OASIS) are among many consortiums
that are working on standardized e-commerce applications, just like the
standardization of roads and railways created the ability for trucks and trains carry
goods for physical commerce.
In summary, standards for applications integration and communication must
exist as:
Open
Horizontal
International
Implementation Planning
Most current integration solutions and system architectures only address integration
problems inside enterprises. They are built on distributed systems that trust each
other. The clients and servers, requestors, and responders know about each other.
They know their objects' names, they know the protocols that they respond to, and
the languages that they speak. In a web-service environment, however, many of these
things cannot be taken for granted.
Think about exposing your processes to external partners. If your internal integration
architecture is applied on the Internet in a cross-enterprise integration scenario,
it probably would not work. Systems on the Internet are independent and
untrusted.
If your architecture for distributed computing will be built on the Internet, the
integration architectures we have are not enough. The closed and proprietary standards
such as COM/DCOM and CORBA cannot be deployed on the Web because they
require a system where the program state can be tracked. Such a "statefull" system is
opposite the Internet, which provides a stateless architecture.
An organization will determine a list of services it wants to deliver over theWeb
and those that they need to receive. In order to accomplish a system with such
interactivity, we need a new architecture that uses open protocols, languages and standards
to turn these new business ideas into a reality.
When two external applications are integrated, they should be architected such
that the client is unaware of the implementation details of the server. The only knowledge
required is the information required to call the server, and what to expect in return.
This is called "loosely coupled" architecture, and we discuss it on Chapter 9,
Integration Models on page 187.
Today when organizations pass paper documents from one to another, they do
not know each other's implementation details. Therefore, some electronic equivalent
of paper, a message-based system, gives the same opportunity: hiding implementation
details from one another. A standard that enables "mutual ignorance" is needed.
Real-time Service Access
If an organization uses paper documents in order to communicate and integrate with
their partners, then the integration scenario is an asynchronous process. The answer
to the paper document does not come in real time. However, real-time response is a
big opportunity in business. In addition to replacing paper, what if we go one step
further and ask for an integration scenario where information is delivered in real-time;
a synchronous integration throughout theWeb? Synchronous access gives businesses
many opportunities to leverage their important business data.
We need standards that turn new business ideas into frameworks that build on
top of the XML foundation. We need to standardize cross-enterprise integration. We
need to digitize the contracts between two partners and formalize and automate the
handshakes of communications and dialogs.
All of these, and more, will enable programs to talk to each other. Humans need
sounds, mailmen, post offices, contracts, and dialogs in order to communicate. Likewise,
the building blocks on top of XML need to be standardized in the digital world
so that programs can talk to each other.
A New Look at Your Company's Business: Service-Oriented View
Web services can be deployed not only among external partners but also among departments
or applications within the organization.
Application integration problems among homogeneous-platform applications
are already solved. Java-based applications can be accessed with Java clients.
COM-based applications can be accessed with Microsoft clients. In addition to that, in
some organizations, in-house application-to-application integration problems that
reside in different platforms are solved in fast and scalable solutions using EAI and
middleware technologies as are discussed in SOAP in Application-to-Application Integration
on page 204.
SOAP is not fast and scalable enough for high-traffic application-to-application
integration just yet. Therefore, it does not suit many application-to-application integration
scenarios. Binary transports with SOAP are needed for such scalability, but are
not standardized yet. However, most organizations have one or more application integration
solutions that already solves their application-to-application integration
problems.
So how does SOAP play a role in internal application-to-application integration?
An organization has different services inside its organization, such as accounting, purchasing
and procurement, customer relationship management. Integration between
these services within the organization can be solved by SOAP, using a web services architecture.
We, as programmers and architects, have been seeing the Information
Technology solutions as applications, programs and objects. However, now it is time
to group already existing applications, programs and objects into service definitions.
Therefore, web services are not only embracing cross-enterprise integration.
Getting the most out of web services requires looking at applications, solutions, departments,
and organizations from a "services" point-of-view and integrating these
ervices by building communication blocks between them using the XML-based standards.
Integration and communication among external and internal web services will
be done using XML standards. These standards are not just implemented at the communication
and translation level. They will also embrace other implementation problems
at the application level. Solutions to the problems such as security, reliability,
routing, and versioning are required. Web services standards are being developed to
offer a complete framework, an infrastructure, for doing commerce between heterogeneous
applications and across organizations.
Conclusion
Now that we have built a house of web services standards, it is time to use these standards
in an intelligent way.
The rest of this book will show you how you can apply these standards to your
web services architecture, and how they fit together.
There are many more standards that are in process right now, and we are sure
there will be plenty more in the years to come. Most of these standards will be based
on the standards presented in this chapter. Your understanding of this house of standards
will be essential as you learn more about web services and the new standards
that support them.
