Getting Started on Developing Web Services

The concept of Web services is the latest in the evolution of ever more modular and
distributed computing. The industry as a whole has embraced it as the next big thing
despite its technical immaturity. What does this mean to developers? It means that,
without risk of investing in a technology that might lose steam and disappear, you can
become an early adopter, hone your skills, and contribute to its evolution. This article
addresses the topic in the following segments:
• What Are Web Services?
• Web Services Standards
• Implementing Web Services
• What You Need to Know About Today's Web Services Paradigm
• Are You Ready to Develop Web Services?
• Development Tips
• Conclusion

What Are Web Services?

Web services constitute a distributed computer architecture made up of many different
computers trying to communicate over the network to form one system. They consist of a
set of standards that allow developers to implement distributed applications -- using
radically different tools provided by many different vendors -- to create applications that
use a combination of software modules called from systems in disparate departments or
from other companies.
It must be noted that Sun -- unlike Microsoft, which is starting a whole new application
paradigm called .NET -- is promoting the Sun[tm] Open Net Environment (Sun ONE), an
open framework that supports "smart" Web services, and in which the Java[tm] 2
Platform, Enterprise Edition (J2EE[tm]) platform plays a fundamental role. This means
that in the world of Sun developers, Web services will be built using servlets, JSP[tm]
pages, EJB[tm] architecture, and all the other standards that are entwined with J2EE
technology.

Web Services Standards

Web services are registered and announced using the following services and protocols.
Many of these and other standards are being worked out now by the UDDI project, a
group of industry leaders that is spearheading the early creation and design efforts.
• UDDI (Universal Description, Discovery, and Integration) is a protocol for
describing available Web services components. This standard allows businesses to
register with an Internet directory that will help them advertise their services, so
companies can find one another and conduct transactions over the Web. The
online yellow pages directory that UDDI provides is a key part of how Web
services plans such as Sun ONE and Microsoft .NET will work together. This
registration and lookup task is done using XML and HTTP(S)-based mechanisms.
The UDDI project is working to provide a common access method for the
metadata needed to determine if a piece of previously developed code will suffice
and, if so, how to access it.
 • SOAP (Simple Object Access Protocol) is a protocol for initiating conversations
with a UDDI service. SOAP makes object access simple by allowing applications
to invoke object methods, or functions, residing on remote servers. A SOAP
application creates a request block in XML, supplying the data needed by the
remote method as well as the location of the remote object itself.

• WSDL (Web Service Description Language), the proposed standard for how a
Web service is described, is an XML-based service IDL (Interface Definition
Language) that defines the service interface and its implementation
characteristics. WSDL is referenced by UDDI entries and describes the SOAP
messages that define a particular Web service.

• ebXML (e-business XML) defines core components, business processes, registry

and repository, messaging services, trading partner agreements, and security.

Implementing Web Services

Before proceeding with development issues, here's a brief step-by-step on how a Web
service is implemented, with links to Dot-Com Builder's technical overviews. The figure
below provides a diagram of a simple Web services implementation.
 1. A service provider creates a Web service. (Development tips are provided later in
this article.)

2. The service provider uses WSDL to describe the service (to a UDDI registry).

3. The service provider registers the service (in a UDDI registry and/or ebXML
registry/repository).

4. Another service or user locates and requests the registered service by querying
UDDI and/or ebXML registry(ies).

5. The requesting service or user writes an application to bind the registered service
using SOAP (in the case of UDDI) and/or ebXML.

6. Data and messages are exchanged as XML over HTTP.

What You Need to Know About Today's Web Services Paradigm

If you're going to develop Web services now, you'll find yourself creating applications
before the Web services infrastructure and protocols have been set. So ignore the
marketing hype, and don't set your expectations too high. Here's a reality check on the
state of today's Web services paradigm (or rather, non-paradigm).
The technology hasn't yet caught up to the business vision. Most software is less than six
months old, and a lot of it isn't going to work as well or as solidly as your existing
distributed systems software.
Even though Web services are built on existing infrastructure, a lot of the infrastructure
needed to perform wide-area collaboration hasn't even been built yet.
This is the first time a set of independent organizations is evolving a technology space in
parallel. The core architectural foundation of Web services -- XML, XML name spaces,
and XML schema -- enables the distributed evolution of the Web services specifications.
Web services are a supply-side phenomenon where the vendors, not the customers, are
pushing the technology and setting standards. UDDI, SOAP, WSDL, and security
standards are being developed in parallel by different vendors, and it will be some time
before they will be able to converge and agree on a final set of standards. In the
meantime, you'll need to use your programming and network knowledge, along with
today's barely developed tools and your own creativity, to find your own solutions.
Specifications are not complete. Because of the lack of a solid set of standards,
implementation details are left for individuals (that's you, or someone who may have
made design decisions with which you may not agree) to make up as they go along.

Are You Ready to Develop Web Services?

Here's a list of skills that will make it easier for you to start designing Web services right
now:
• Master the skill of non-attachment. Since many of the elements you'll need to
develop Web services will be completely out of your control, you'll get plenty of
practice.
 • Apply your knowledge of large-scale enterprise system deployment. There are
many complex nuances in enterprise systems that are not exclusive to the domain
of Web services, such as high availability, high throughput, clustering, hardware
management, and network topology. If you've deployed a large-scale enterprise
system, you are probably as prepared as you're going to be to develop Web
services.

• Use your knowledge of other kinds of distributed systems. The toolsets you'll
use will be different, but if you have CORBA and EJB architecture training, you'll
be able to transfer your existing design knowledge to Web services development.

• Draw upon your knowledge of servlets, JSP pages, EJB architecture, and
other J2EE technologies. These skills will be extremely useful in Web services
development.

• Learn XML programming skills. The simple fact is that XML is ubiquitous in
Web services architecture because it is open, vendor-supported, and standardized.
You can expose assets and services using WSDL and proxy-generation tools,
which shield you from the underlying messages carried by XML packets in Web
services. However, depending on how deeply you go into Web services, low-level
XML programming skills may be important. Many tools aren't yet fully capable
of shielding you from the details. So if you're developing complex systems, you
may need to write programs that interact with the low-level XML.

• Study XML standards. Web services tools will eventually make XML
transparent, but for now, it's essential that you become comfortable with XML
standards based on SOAP, WSDL, UDDI, or ebXML.

• Learn the tools your organization has chosen for Web services development.
Some of the tools available now are the Forte[tm] for Java[tm] IDE, Oracle
JDeveloper, and WebGain Studio. The future will bring tool suites such as the
J2EE[tm] Web Services Pack that will incorporate JavaServer[tm] Faces, a
standard API for creating GUIs; Tomcat, for implementing JSP pages and servlet
technologies; and the JAX Pack, a collection of XML-based Java APIs for XML
processing registries, messaging, binding, and remote procedure calls (RPC).

Development Tips
Here's what you'll need to consider once you begin designing Web services:
• Requesting a service: Web services have all the same issues as those of
distributed systems. If you've never developed distributed computing systems,
you need to be aware that the service you've requested from a machine over the
network may be a very heavyweight operation, even if it's represented by a single
line of code. Keep in mind that a local operation is much cheaper than a
distributed operation.
 • Control issues: As a developer, you may think of an application as something to
build and control -- and if it doesn't work, you can grab and modify it. However,
with Web services you will be tapping into software modules that are not under
your control. Most of the time, the data or service you request will be sent to you
and everything will work fine. But you'll need to plan for the time when it doesn't
work -- maybe the administrator for the system you're calling (that worked just
fine for months) updated the system to a new version that doesn't work with your
application. So make sure to program in a "Plan B."

• RPC-style architectures: If you've developed in CORBA, you're used to making

a call to a subroutine and expecting a timely return. In Web services, you'll make
the call, but don't expect to get an instant response. Web services support both
asynchronous and synchronous RPC-style architectures as well as messaging, so
that you can create a loosely coupled, asynchronous architecture that allows
functions to continue without network response... up to a point. You won't be able
to count on the reliability of many of the services you call because they aren't
under your control. So you'll need to provide backup plans for important
processes. This is another good opportunity to practice the skill of non-
attachment.

Conclusion
Web services are here to stay, and the good news is that you can transfer a lot of your
existing J2EE technology skills and knowledge of distributed systems to make the shift.
There are plenty of challenging and creative opportunities as only a few development
tools are available at this time. So you'll be working at the nuts and bolts level, as well as
making independent decisions because few standards are solidly in place at this time.
However, you can look forward to participating in the evolution of these standards and
using tools with better integration and reliability as the industry grows.

Overview of ebXML Specifications

The broad-based ebXML initiative aims to standardize and extend XML to build a
globally interoperable business-to-business infrastructure for Web transactions. The
initial phase, an 18-month project spearheaded by OASIS and UN/CEFACT with
international vendors participating from across the IT industry spectrum, culminated
earlier in 2001 with a first-round release of specifications.

Translating From Grand Vision Into Technical Details

Propelling ebXML forward is the vision that no business -- regardless of size -- should
have to reinvent the wheel to engage in Web services. Toward that end, ebXML
specifications prescribe specific business modeling and methodology to derive XML-
based processes from ubiquitous B2B activities. By modeling the standard upon existing
business practices, ostensibly any company could adapt or bridge its internal processes
and data to ebXML.
The distributed infrastructure for executing ebXML services, also detailed in the specs,
lays out a framework intended to foster the development and implementation of
interoperable XML-based software applications and reusable components.
Like any standards effort, ebXML is a work in progress, still in its technological infancy,
along with Web services overall. A look at what is actually contained in the current
ebXML specifications and what remains to be done follows here.
(To view or download the specifications discussed in this article, go to:
http://www.ebxml.org/specs/index.htm.)

ebXML Technical Architecture

Technical Architecture Specification v1.0.4
The ebXML initiative's numerous working technical committees produced a suite of
ebXML specifications, along with a stream of supporting technical documents. The first
document released in February 2001, the Technical Architecture Specification v1.0.4,
maps the overarching business modeling for ebXML processes based upon the UMM
(UN/CEFACT Modeling Methodology) Metamodel. UMM prescribes the rules for
classifying business concepts and interactions so they can be uniformly represented as
business processes. (See the Business Process and Information Modeling section for more
about the business modeling aspects of ebXML.)
The Technical Architecture spec also identifies elements and components comprising the
overall framework for handling business processes and documents using XML-based
services and messaging. ebXML project committees hammered out the details of the
framework's major pieces in individual specifications published in May.

Registry/Repository
Registry Services Specification v1.0/Registry Information Model v1.0
At the hub of ebXML's technical framework are distributed repositories containing all the
necessary XML artifacts for participants to discover and learn about other potential
business partners, establish working agreements, and engage in business transactions.
Repository items can and ultimately should include core components, message
definitions, XML schema, DTDs, and the XML-based business process models and
documents.
Business entities (designated as trading partners) participating in ebXML transactions
are represented within these repositories by XML documents called Collaboration
Protocol Profiles. These CPPs contain data about each trading partner's organization and
services, along with information about how this data is structured and represented. (See
the next section for more information about CPPs.)
ebXML registry services provide storage and interface capabilities for the repository's
CPPs and other contents, which also includes business-modeling information about the
registry itself. Registry and repository functionally perform together as a database, with
shared information maintained in the repository as objects that are managed and queried
through registry services. One of the unique aspects of the registry/repository is the
provision for a classification capability that allows classifications to inherit from other
classifications, enabling powerfully agile repository querying.
Because registries lie at the heart of implementing ebXML, registry services are likely to
attract much initial ebXML development activity. "There will be many more developers
of registry services than implementers of registries themselves," predicts Tim McGrath,
who served as team lead and editor for the ebXML Quality Review Committee, tasked
with reviewing all the specifications, technical reports, and white papers for release.
"Registry services will most likely be integrated with other Web services, for example, a
directory service that supports Universal Description, Discovery, and Integration (UDDI)
and drills down into an ebXML registry. One technical issue still remaining with registry
services is the nature and sophistication of the querying capabilities. I would imagine that
this will be addressed as part of the next specification revision."
One potential implementation scenario is for registries to be built and operated as value-
added services by third-party service providers -- similar to an Electronic Data
Interchange (EDI) value-added network or an Internet application service provider.
Attracting, building, and maintaining repository content will be one of the largest tasks in
implementing ebXML.

Collaboration Protocol Profiles and Agreements

Collaboration Protocol Profile and Agreement Specification v1.0
Collaboration Protocol Profiles (CPPs) are XML components within the registry that
identify participating business entities and describe their capabilities. The CPP forms the
cornerstone of ebXML infrastructure by providing the links between it and the content
layers. The CPP includes the following elements:
• A process-specification layer that defines information about the kinds of
agreements available for request by other business parties.

• A DeliveryChannel binding for document exchange and transport, which together

describe and define a business entity's message-receiving characteristics.

• A DocumentExchange layer defining message-level characteristics, such as

security and reliability.

• The Transport layer describing the technical details (such as endpoint address,
protocol and transport-level security) of the underlying transport protocol (for
example, HTTP).
Collaboration Protocol Agreements (CPAs) represent the technical rules of engagement
for each collaborative business event between two trading partners. A CPA can be
thought of as a shared configuration file derived from trading partners' stored profile
information that ensures technical interoperability between the software at each end. The
CPA provides a canonical means of representing in non-proprietary form all the elements
required by server software, including:
• Interactions between two trading partners, such as messaging transport security
issues.

• Lists of interfaces expressed as business processes.

 • Unique identifiers for each business process.

• Bindings to the relevant business process specifications defining those

interactions.
The CPP-CPA spec also defines specific XML elements, child elements, attributes, and
structures within the CPP. Together, the CPP and CPA formalize traditional EDI-type
trading partner agreements in terms of ebXML technology requirements. Put simply, a
CPP defines what a business entity can do, whereas a CPA defines what a pair of
business partners will do in executing an identified business process.
The current spec is not yet definitive about the process for negotiating CPAs, whether
they are developed manually from scratch or programmatically derived from pairs of
CPPs. Perhaps the technical details may be represented as another business process
between trading partners. In any case, the critical aspect initially is that a CPA can be
shared between parties to become the means of ensuring interoperability.

Messaging Services
Message Service Specification: ebXML Transport, Routing and Packaging v1.0
A messaging service protocol to enable secure, reliable message exchange between
parties is the most mature ebXML specification to date. The ebXML Message Service is
a formally specified set of Simple Object Access Protocol (SOAP) extension elements
and their associated semantic meaning and behavior. Aligning ebXML messaging with
the broadly implemented SOAP protocol signals a technically and strategically
significant move by starting down a clear convergence path between full-blown B2B e-
business and Web services.
ebXML messaging is designed to meet an array of business types and needs through its
essential characteristics: simplicity, reliability, and modularity. By building upon open
standards, such as SOAP and JAXM (Java APIs for XML messaging), businesses are
able to adapt ebXML-messaging implementations to existing code bases.
Core features of the ebXML messaging spec include:
• Packaging specification describing how to package ebXML messages for a
variety of communications protocols, including HTTP, SMTP, and FTP. A
complete message package is a MIME multipart/related object. MIME types are
used to describe all message package contents. The two principal parts of the
message package are a SOAP message container and optional payload containers.
ebXML packaging is defined by the SOAP Messages with Attachments Note
published to the W3C.

• SOAP extensions specific to ebXML enable message structure and composition

essential to successful message generation and processing. Extension elements
include routing information, trading partner information, message identification,
and delivery semantics information. (Because payload is optional to the message
package, it can contain any type of information exchange between parties,
including XML, EDI transactions, binary data, and so on.)
 • Message handler services that interoperate with other message-service handlers
through discovery capabilities, error detection, and error reporting.

• Reliable messaging protocol to guarantee successful message exchange between

any two message service implementations, specifically ensuring one copy of a
message to the recipient and confirmation of its receipt. ebXML messaging
reliability is supported over any transport protocol such as SMTP or HTTP.

• Secure message exchange through use of the joint W3C/IETF XML signature
standard enabling authentication of digitally signed messages, message payload
encryption capabilities based on MIME-based cryptographic standards such as
S/MIME and PGP/MIME, and interoperability with other network protocol
security standards such as SSL and IPSEC.

As currently specified, ebXML messaging services can be implemented for enterprise

applications either through direct integration or interface application software. Direct
integration lets ebXML messaging function seamlessly with existing applications, but
requires the functionality to be added into enterprise software. Business organizations can
opt to develop ebXML messaging interface applications as an incremental step toward
ebXML.

Business Process and Information Modeling

Business Process Specification Schema v1.01
The ebXML Business Process Specification Schema (BPSS) offers some of the most
tangible specifications for translating business processes into ebXML tools and
applications. In essence, the BPSS distills how to describe business processes as XML
artifacts. It does this by providing the semantics, elements, and properties to define binary
business collaborations between two trading partners. (Future revisions to ebXML specs
are expected to address multi-party transactions.) Business collaboration is BPSS
nomenclature for sets or patterns of choreographed roles and transactions.
The BPSS does not provide any direct correlation for formal XML documents and data
structure definitions to be used in direct applications development. Instead, the scope of
the BPSS is the bridging itself between business process modeling and software
components that ultimately run those processes. Toward this end, the functional pieces of
BPSS include:
• A Uniform Modeling Language (UML) road map of all the pieces necessary to
create an ebXML-compliant business process specification.

• An XML version of the same thing, which also serves as the rule book for
converting non-XML business process specs into XML documents.

• Production rules to map UML modeling to XML for the purpose of generating a
DTD of ebXML business process specifications.

• Specification schema defining the XML "business signals" necessary for ebXML
transactions. Business signals are application-level XML documents with a
 specific purpose that is separate from protocol and transport signals.

The BPSS references, but does not define, ebXML business documents. Instead, business
documents are defined as the "points of intersection" between the BPSS and ebXML core
component specifications. Actual ebXML business documents can either be defined
externally or structured by ebXML core components. Together, the BPSS and XML
business documents form the basis of ebXML trade agreements.
So how does BPSS relate to the rest of ebXML architecture? The BPSS requires that any
ebXML business-modeling methodology either uses or supports UN/CEFACT Modeling
Methodology. This UN-established modeling methodology provides process modeling
for different business viewpoints: operations, requirements, transactions, and services.
From a purely technical level, modeling serves as a means for describing business
processes in a manner that can be turned directly into executable software code. Thus, the
specification's authors have stipulated the use of UMM for ebXML theoretically to
encourage globally consistent software modeling. However, this has turned out to be a
somewhat controversial aspect of ebXML for various reasons, not the least of which
being the vast amount of legacy business software potentially bearing no relation to
UMM. But for the purpose of designing ebXML-compliant software, the BPSS is
designated as a subset of UMM with certain elements defined specifically for ebXML.

Core Components
Core Component Overview Technical Report Document Version 1.05
Core components of ebXML are works in progress. Developing core components
involves capturing and aggregating real-world business concepts. Vendors will be the
ones to implement core components by specifying their business processes in XML terms
and then building the tools and APIs needed to bridge their enterprise applications to
ebXML. As these hand-coded building blocks multiply and grow into part of ebXML
infrastructure, more and more will become automated components and evolve into
reusable software commodities.
As such, no formal specifications for core components exist yet, however numerous
technical reports detail critical aspects of core component development including
definition, purpose, context, discovery, naming conventions, structure, and dictionaries.
This is part of ongoing ebXML work now absorbed by UN/CEFACT, which established
an Electronic Business Transition Ad Hoc Working Group (eBTWG) to manage a range
of core component and business process management projects.

XML Schemas
XML Schemas define the syntax of ebXML document structure and provide the basis for
constructing libraries of definitions for commonly used business objects. These are to be
text-based and structured according to ebXML business modeling. However, the ebXML
specs do not delve into XML syntax with respect to document contents. In fact,
UN/CEFACT and OASIS have made it official policy to remain neutral toward the
matter of XML content syntax. This may be one of the more confusing aspects
surrounding ebXML. Although expectations of defining an XML standard geared to "e-
business" might understandably include delivering a specific set of XML DTDs for
things like "Purchase Order" or "Invoice," this is not the case.
The expectation is that ebXML implementers will develop their own XML expressions
for core component definitions as needed. Recognizing that syntax conventions and
programming languages tend to evolve over time, the ebXML specifications instead
attempt to distill only what is known about commonly used business data objects.
Industry groups such as EAN/UCC (European Article Numbering/Uniform Code
Council), AIAG (Automotive Industry Action Group), OAG (Open Applications Group),
and GCI (Global Commerce Initiative) and technology providers like Commerce One and
Ariba are at work now on how to define their XML documents for ebXML-compliance.
However, that is outside the purview of ongoing ebXML work by UN/CEFACT, which
has officially adopted a "syntax-neutral" policy. Eventually the IT industry's inherent
process of natural selection is expected to yield a specific XML syntax for electronic
business that can become the de facto standard through implementation. More recently,
the newly established OASIS Universal Business Language committee has begun
developing context-specific, real-world XML instantiations of ebXML core components.
ebXML specs are based upon W3C XML Schema language specifications although these
are not yet formally part of ebXML. The current versions of ebXML specs were drafted
at a time when W3C had not yet made an official recommendation for XML Schemas.
Now that this has happened, OASIS technical committees are modifying the ebXML
specifications to align with the W3C. OASIS working groups are also addressing errors
and other issues discovered by ebXML implementers to be included in revised specs,
expected by year-end 2001.

What's Happening Now

Upon releasing the current set of ebXML specs, project teams identified and categorized
any remaining tasks. Infrastructure component requirements left uncompleted have been
taken up by OASIS working groups, particularly in the areas of messaging, collaboration
protocols, and registry services.
The matter of content and related issues of business context -- largely unaddressed in
current ebXML specs -- comes under the mission of eBTWG, the UN/CEFACT body
managing a broad range of ongoing ebXML-related projects. One area of functionality
set aside during initial ebXML spec work and now being addressed by eBTWG is the
Business Systems Interface (BSI), with implications for both ebXML infrastructure and
content.
Ultimately, the early adopter industry and user groups undertaking implementation work
are probably the most likely source of influence over the future of ebXML. Like nothing
else, concrete standards for XML syntax and documents are expected to encourage other
business users to adopt ebXML, creating the momentum that leads to real
standardization.
In the words of one ebXML working group participant, "Whether ebXML or Web
services (SOAP, WSDL, UDDI, WSFL), we are not `done' yet by any stretch of the
imagination. There's plenty missing, but that isn't the point. From a developer's
perspective, the point is to build on what works."
Overview of UDDI
This article describes the Universal Description, Discovery, and Integration (UDDI)
standard, an evolving standard for describing, publishing, and finding Web services that a
business provides. In short, UDDI is a specification for a distributed registry of
information on Web services. I'll introduce the capabilities that these registries add to the
WWW, and how they can be used.

The Big Picture

Lately, a lot of hype has been attached to Web services. So what are Web services?
According to The Stencil Group, they are "Loosely coupled, reusable software
components that semantically encapsulate discrete functionality and are distributed and
programmatically accessible over standard Internet protocols." Web services are a new
paradigm in distributed systems development that will provide a platform for all future
B2B e-commerce transactions on the Internet, as well as finally provide a universally
supported approach to B2B integration.
It has always been a challenge for businesses to talk to each other at an application level,
simply because of the vast array of platforms, tools, mechanisms, and processes that each
one uses. The recent popularity of eXtensible Markup Language (XML) among
businesses offers the most promising solution yet for them to seamlessly exchange data.
Also, the evolution of standards such as the Simple Object Access Protocol (SOAP) has
provided an excellent framework for businesses to call each other's services over a
network. OK, so we now have a mechanism by which businesses agree on what to talk to
each other (XML) and how they are going to speak to each other (SOAP), but how do
they know whom to talk to and where to find other businesses? Enter UDDI.

The layers in this table illustrate where UDDI fits in with the rest of the protocols in the
Web services Interop Stack. Following is a detailed description of the stack's elements:

• Common Internet Protocols such as HTTP (and to a certain extent SMTP) lend
the basic communication framework for Web services, even though Web services
need not necessarily be tied to one of these protocols.

• XML is fast becoming the universal standard for exchange of data and its
structure, and forms the foundation of Web services. This article assumes readers
have a basic familiarity with XML. A good introduction to the language is XML
Distilled: Essential Ingredients for Today's Web Applications.

• SOAP provides a simple and lightweight mechanism for exchanging structured

and typed information in a decentralized, distributed environment using XML.
 This article assumes readers are familiar with SOAP. For more information on
SOAP, check out Overview of SOAP.

• UDDI defines a way to publish and discover information about Web services. A
UDDI registry cloud, or business registry, provides "register once, published
everywhere" access to information about Web services.

It must be noted that UDDI/SOAP are not the only models for discovery and messaging
in Web services. ebXML has been developed to do much the same, as well as provide a
business software interface, robust security, and other functions that allow for real e-
business transactions. ebXML and UDDI/SOAP are complementary technologies and
you may, in the long run, end up with both methods in place.

UDDI -- For Real or Yet Another FLAN? (Four-letter Acronym)

As its name indicates, the Universal Description, Discovery, and Integration standard
provides a mechanism for businesses to "describe" themselves and the types of services
they provide and then register and publish themselves in a UDDI Registry. Such
published businesses can be searched for, queried, or "discovered" by other businesses
using SOAP messages. Having discovered other suitable businesses to partner with, using
this mechanism businesses can then "integrate" their services with their partners and
provide service to their customers.
For example, ZipZapZoom Courier is a fast-growing company that specializes in
delivering packages throughout the U.S. It could create a Web service that enables its
vast majority of Internet retailer clients to calculate the cost of shipping an article from
point A to point B, given the weight of the article and the type of service requested. It
could either develop a SOAP wrapper over the existing algorithm that calculates the
shipping cost, or choose to rewrite it to decipher and deliver SOAP messages. This
service could then be published in a UDDI registry, such that clients can invoke the
service. An Internet retailer could then use this Web service while calculating shipping
costs for its customer. The retailer could even choose to list the shipping cost of
ZipZapZoom's competitor, Vroom Shipping, if Vroom also has exposed a similar service
so that customer could choose either shipping service at the time of ordering.

Of Colorful Businesses and White, Yellow, and Green Pages

Conceptually, the information provided in a UDDI business registration consists of the
following three components:
• White pages are much similar to the telephone equivalent and include address,
contact, and known identifiers. ZipZapZoom Courier would have listed itself as:

ZipZapZoom, 123, Swift Drive, Pacer CU

• Yellow pages also parallel their phone equivalent and include industrial
categorizations based on standard taxonomies, such as NAICS, UN/SPC, SIC
code, and so on. Registering information such as industry codes, product codes,
geography codes, and business identification codes (for example, D&B D-U-N-S
Numbers) allows other search services to use this core classification information
 as a starting point to provide better indexing and classification. ZipZapZoom
would categorize itself as a Shipping and Delivery Service under the Couriers
subcategory in the Transportation and Warehouse category, as per the NAICS
classification (NAICS Category number 49211).

• Green pages contain the technical information about services exposed by the
business. They include references to specifications for Web services as well as
support for pointers to various file and URL-based discovery mechanisms if
required. UDDI registry nodes store the preceding information and replicate the
data among them to provide the same directory of information from any of the
nodes. This system is quite similar to how domain names are looked up in the
Web using the DNS architecture.

The Core Structures of UDDI

The information that makes up a registration consists of four data structure types. (Stop
the press: UDDI 2.0 has just added a fifth type.) This figure shows the four structures as
represented in the UDDI specification:

Each of these four XML structures contains a number of fields that serve a business or
technical descriptive purpose. For a detailed explanation of each of these structures,
please refer to the UDDI Data Structure reference document. These structures are
described in the UDDI API Programmer's API Specification and XML Schema.
As illustrated by the bold and dotted lines in the figure, the businessEntity structure
contains one or more unique businessService structures. Similarly, individual
businessService structures contain specific instances of bindingTemplate data, which in
turn contain information including pointers to specific instances of tModel structures. For
a UML representation of these structures, refer to Modeling the UDDI Schema with
UML.
Let's look at each of the previous structures in greater detail:
• businessEntity: This structure captures information about a business or entity and
is used by the business to publish descriptive information about itself and the
services it offers. From an XML standpoint, the businessEntity is the top-level
data structure that holds descriptive information about a business or entity.
Service descriptions and technical information are expressed within a
businessEntity. The businessEntity structure has a unique key that identifies the
business and data that are typically found in the "Yellow pages" and "White
pages" of UDDI. The partial businessEntity structure (with key elements
highlighted) for ZipZapZoom courier, with contact information for its CEO and
COO, as Sir Speedy, follows:
<businessEntity authorizedName="0100003PAJ"
operator="www.ibm.com/services/uddi"
businessKey="83B31400-7581-11D5-
889B-0004AC49CC1E">
<discoveryURLs>
<discoveryURL useType="businessEntity">
http://www-3.ibm.com/services/uddi/
testregistry/uddiget?businessKey=
83B31400-7581-11D5-889B-0004AC49CC1E
</discoveryURL>
</discoveryURLs>
<name>ZipZapZoom Courier</name>
<description xml:lang="en">
Fast and reliable Shipment services
</description>
<contacts>
<contact useType="CEO,COO">
<description xml:lang="en">
All-in-All of the company</description>
<personName>Sir Speedy</personName>
<phone useType="Work">
123-456-7890</phone>
<email useType="">
[email protected]</email>
</contact>
</contacts>

• businessService: This structure represents the services or business processes

provided by the businessEntity. It typically contains the unique key used to
represent the service, the human-readable name of the service, an optional
description, and the bindingTemplate structures that hold the technical
information.

• bindingTemplate: This structure presents the important data that describes the
technical characteristics of the given service implementation. IT has the
information required to actually invoke the service. Each bindingTemplate has a
 single logical businessService parent, which in turn has a single logical
businessEntity parent. Each bindingTemplate has a unique binding key, the
associate service key, and most importantly the accessPoint, and
tModelInstanceDetails. The accessPoint represents the address for calling a given
Web service. This could be a URL, an e-mail address, or, if you can believe it, a
telephone number.

• tModel: The primary role a tModel plays is to represent a technical specification.

To quote the UDDI spec, "The purpose of a tModel within the UDDI registry is to
provide a reference system based on abstraction." It takes the form of "Keyed
metadata (data about data)." A tModel has a key, a name, an optional description,
and a URL from which more information about the data can be retrieved. An
example of a tModel can be a specification that outlines a wire protocol. The
reference to a tModel is a pledge by the company exposing the Web service that it
has implemented the service in a way that is compatible with the tModel being
referenced. In this way, many companies can provide Web services that are
compatible with the same specifications.

Following is a partial businessService structure containing the bindingTemplate and

tModel structures for ZipZapZoom's shipping cost calculation service via phone:

<businessServices>
<businessService serviceKey="
7BB589E0-7586-11D5-889B-0004AC49CC1E"
businessKey="83B31400-7581-11D5-
889B-0004AC49CC1E">
<name>calculateShipping</name>
<description xml:lang="en">
Given the type of service and the weight,
the shipping cost is calculated</description>
<bindingTemplates>
<bindingTemplate bindingKey="
7BB6C260-7586-11D5-889B-0004AC49CC1E"
serviceKey="7BB589E0-7586-
11D5-889B-0004AC49CC1E">
<description xml:lang="en">
The shipping cost can be obtained by
calling the given number
</description>
<accessPoint URLType="phone">
123-456-7890</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="UUID:
38E12427-5536-4260-A6F9-B5B530E63A07" />
</tModelInstanceDetails>
</bindingTemplate>
You can view the Complete XML structure (containing all the structures) for
ZipZapZoom. If your browser cannot read XML, you can save the file as XML and open
it using any text editor.
It is strongly recommended that you examine the XML (from a DOM perspective) for a
good understanding. In addition to these core structures, there are a few "helper"
structures that I'll examine as needed.

Frequently Used Features of UDDI

UDDI provides for two broad categories of APIs, the Publish API and the Inquiry API.
The Publish API provides the mechanism for service providers to register themselves and
their services with the UDDI registry. The Inquiry API allows service subscribers to
search for the available services. The Inquiry API provides for two types of calls, a find
mechanism (representing a drill-down mechanism, whereby you start at top-level
information and keep drilling down till you find the required information); and a get
mechanism, when all the information required to look up a service is readily available.

Publish
The messages in the Publish API represent commands that are used to publish and update
information contained in a UDDI-compatible registry. Each business should initially
select one Operator Site to host its information. Once chosen, information can only be
updated at the site originally selected. Invoking the methods in Publish API requires
authorization and is usually done through a secure mechanism. HTTPS is used for all the
methods in the Publish API. This API consists of the following functions:
• Four messages to save each of the four structures: save_business,
save_service, save_binding, save_tModel. Each save message
accepts as input the authToken and one or more corresponding structures. For
example, the save_business takes as input one or more businessEntity
structures. Alternatively, each save function will also accept as a parameter an
uploadRegister element that can be resolved to an HTTP URL address. The
URL must return a pure XML document that only contains the corresponding
structure expected by the save method.

• Four messages to delete each of the four core structures:

delete_business, delete_service, delete_binding,
delete_tModel. They all accept the corresponding uuid key as the
parameter. Successful completion or failure of the delete messages is indicated
through appropriate codes in the SOAP dispositionReport structure that is
returned. To delete the business that was created for ZipZapZoom, we would pass
the following XML construct:

<delete_business generic="1.0" xmlns="urn:uddi-org:api" >

<authInfo>Some auth info here </authInfo>
<businessKey>83B31400-7581-11D5-889B-
0004AC49CC1E</businessKey>
</delete_business>
Note that the businessKey attribute is the same as that found in the businessKey element
in the businessEntity definition.
• get_auth Token: This function is the programming analog of a login. It is
used to request an authentication token from a UDDI operator. All the Publish
API functions require the use of the token. Please note that this function is
considered optional, and UDDI operators who provide another mechanism of
authentication -- such as a registration-based user-id/password mechanism -- need
not implement this.

• discard_authToken: This function is used to inform the UDDI registry that

the authToken is no longer valid.

• get_registeredInfo: This function is used to get a brief summary of all

information (specifically the businessEntity keys and tModel keys) for the caller.

Find
The messages in the Inquiry API represent queries that anyone can make at any UDDI
registry. The messages can be categorized into two broad patterns -- namely, browse and
drill down:
• Browse: UDDI provides four types of calls under this pattern, and you guessed it,
one for each of the four data types. Typically, a find_business is invoked
with any partial information that is available, and this returns a businessList
structure, which is an abbreviated set of key information from the businessEntity
structure. The businessList can be iterated through for a suitable match, and then
the find_service message can be used to get to particular service types. Each
of the find calls also accepts an optional findQualifiers element that alters
the default search behavior. Examples of findQualifiers include
"exactNameMatch," "caseSensitiveMatch," "sortByNameAsc," and
so on. The find calls also provide a maxRows attribute that specifies the
maximum number of search results to be returned.

• Drill Down: If a key for one of the four main data types is available, the key can
be used to get information regarding a specific instance of that data type. The get
call can be used to get information regarding any of the data types, given the key.
Thus we have a get_businessDetail, get_serviceDetail,
get_bindingDetail, get_tModelDetail, and finally a
get_businessDetailExt, that provides extended businessEntity
information.

Bind and Invocation Pattern

To invoke a service registered in a UDDI registry, an application needs to be aware of the
service. This data is normally incorporated in the application during development time.
Such invocation data, as we discussed, is contained in a "bindingTemplate" data type and
needs to be cached and used at the time of invocation; this way, repeated calls to a service
described by the bindingTemplate can be used without making repeated calls to the
UDDI registry. This mechanism would, however, lead to issues when the remote service
has been relocated without the knowledge of the client (for example, during an upgrade).
The proper behavior to accomplish this would be to:
• Invoke get_bindingDetail passing in the cached bindingTemplate.

• Verify the data returned by get_bindingDetail and invoke the service using
the "new" bindingTemplate if data returned by get_bindingDetail is
different from the cached information.

• Replace the cached information with the new information obtained if the
invocation is successful.

Tying It All Together -- A Sample Application

Having discussed all the basic aspects required for an understanding of UDDI, I'll now
show UDDI in action by invoking the find message on the ZipZapZoom Courier business
that has been created in the IBM UDDI test registry for purposes of this article.
For more information about how to register with the Test registry and create your
businesses, refer to
http://www6.software.ibm.com/developerworks/education/ws~rpws/index.html. Please
note that you must be authorized to access this site.
I'll use the IBM UDDI4J implementation of UDDI. For details on downloading and
installing IBM UDDI4J, please refer to the UDDI4J Project.
Central to the IBM UDDI4J implementation is the UDDIProxy class that is used to
interact with the UDDI registry. The pseudo-code for my application will be something
such as the following:
• Instantiate a UDDIProxy
• Configure it to access a suitable UDDI registry
• Invoke the find_business method
• Iterate through the results to find the required business
I specify the registry to inquire from and the registry to publish to, using the
setInquiryURL(), and the setPublishURL() methods, respectively:
myProxy.setInquiryURL("http://www-3.ibm.com/
services/uddi/testregistry/inquiryapi");
UDDIProxy provides a find_business() method that can be thought of as the Java
wrapper to the find_business message that I discussed earlier.
zipzapList = myProxy.find_business("ZipZapZoom", null, 0);
It accepts three parameters -- the search parameter, the find qualifiers, and the search
limit. It returns an object of type, BusinessList, from which I can access the required
information for the business. The full source code and documentation are as follows:
FindZipZapZoom.java and FindZipZapZoom.class

Summary
This article introduces the technical aspects of UDDI, an evolving standard for locating
businesses and invoking the services they provide. It details the core structures of UDDI
and frequent ways in which they are used, and it illustrates UDDI in action with a sample
find_business application.

Overview of SOAP

Introduction
SOAP, to put it simply, allows Java[tm] objects and COM objects to talk to each other in
a distributed, decentralized, Web-based environment.
More generally, SOAP allows objects (or code) of any kind -- on any platform, in any
language -- to cross-communicate. At present, SOAP has been implemented in over 60
languages on over 20 platforms. Suddenly objects everywhere, local and remote, large
and small, are able to interoperate. Brad Pitt and Edward Norton, like two very different
object types, are finally able to communicate.
In this technology review, I will present SOAP initially in the larger context of Web
services, as a protocol that is paired with UDDI (Universal Description, Discovery and
Integration) to provide registry and messaging services among businesses. I will also
discuss the Web-based underpinnings of the emerging publish-find-bind paradigm, and
reveal the mechanisms of SOAP packaging, transport and delivery.

Evolution of Web Services

Despite all the hoopla, SOAP is simply one component -- albeit a central one -- in the
emerging picture of the Web as a standards-based, language- and platform-neutral
framework for business operations. These operations are commonly lumped under the
generic tag "Web services, " but Web services themselves are only as good as the
infrastructure that supports them. Accordingly, here's a quick, n-tiered look at the
substrata of the Internet.

Network Tiers
Three network tiers are evident in the evolution of Web services: TCP/IP, HTTP/HTML,
and XML. These tiers build successively on top of each other and remain compatible
today.
The first tier, the TCP/IP protocol, is concerned primarily with passing data across the
wire in packets. A protocol that guarantees transmission across public networks, TCP/IP
emphasizes reliability of data transport and physical connectivity. Originally the putty
holding proprietary networks together, it's now the backbone protocol of the Web on
which higher-level, standard protocols such as HTTP rely.
The second tier, HTML over HTTP, is a presentation tier and concerns itself with
browser-based search, retrieval and sharing of information. The emphasis here is on GUI-
based navigation and the manipulation of presentation formats. In many ways, HTML is
more show than go and lacks both extensibility and true programming power.
Nonetheless, sharing hypertext-linked documents in a browser-based environment
revolutionized the way humans communicate text-based information to one another.
Networked desktop environments, burdened with proprietary operating systems and
platform dependent software, are slowly but surely giving way to the standards-based,
open-systems computing of the Internet.
Leading the charge into this brave new standards-based world is XML, the third and
possibly the most compelling tier on the Internet. XML, a strongly-typed data interchange
format, provides a new dimension to the HTTP/HTML tier, one in which machine-to-
machine communication is made possible through standard interfaces. This layer --
variously described as A2A (application to application), B2B (business to business) or
C2C (computer to computer) -- allows programs to exchange data formatted in a
platform- and presentation-independent manner. XSLT style sheets may be added as an
optional presentation and/or transformational component.

XML: The Key to Describing Web Services

The key to making all this possible is machine-to-machine communication, an area in
which XML excels. As a syntax for describing data, XML is definition-driven (through
the use of DTDs and schemas) and allows information to be manipulated
programmatically. This means that most of the guess work can be taken out of B2B
communication. Tags can be agreed upon, interfaces can be defined and processing can
be standardized. Web services are reusable component programs that utilize XML as a
standard, extensible communication framework to facilitate this type of computer-to-
computer communication.
Web services provide interfaces for the transport of component data and business logic
across HTTP. A huge amount of data sits right behind server-side scripts and in legacy
repositories, waiting to be accessed by Web browsers or client applications. Web services
promise to revitalize corporate software assets now lying dormant in many enterprise
domains.
XML plays a crucial role in integrating Web-resident data into enterprise applications and
coordinating the business logic that holds component pieces together. Specific business
tasks and services (including workflow logic, business logic, component sequencing
logic, transaction logic and so on) can be encapsulated in XML documents and integrated
into existing business environments. This allows businesses to leverage existing internal
assets and processes and expose this information as Web services, facilitating business
transactions and supply chain interaction across the Web.
Because XML is human-readable and text-based, it is ideal as a transport framework for
loosely coupled Web services. The bottom line is this: automated transactions increase
productivity, reduce costs and improve services. The presence of standards on the net
make automated transactions possible, resulting in productivity gains across the board.
SOAP is a technology that derives from an earlier XML-based standard (XML-RPC) and,
in some sense, points toward an emerging standard called ebXML (electronic business
XML). ebXML is a work-in-progress, geared toward providing a comprehensive
definition of shared business messages among trading partners. SOAP is more modest in
scope and less complex in implementation.

Loosely Coupled Systems

Web services decouple objects from the platforms that hold them hostage. That is, Web
services facilitate interactions among platform-independent objects, which are able to
access data from anywhere on the Web. As part of the movement away from proprietary
platforms, Web services rely on loose, rather than tight, couplings among Web
components. According to Brian Travis, SOAP consultant and author, "Systems that rely
on propriety objects are called tightly coupled because they rely on a well-defined but
fragile interface. If any part of the communication between application and service object
is disrupted, or if the call is not exactly right, unpredictable results may occur." EDI is an
example of a tightly-coupled framework for doing electronic commerce. Loosely coupled
systems allow for flexible and dynamic interchange in open, distributed Web
environments.

Second Coming of CORBA

Companies on the net today -- IBM, BEA, Sun, to name a few -- simultaneously
cooperate with the very companies they compete against. Standardized network transport
protocols, platform-independent programming languages like Java, XML and industry-
specific dialects, and open component-based server architectures all contribute to this
non-proprietary free-for-all. Now Web services, with its promise of broad-based
application interoperability, arrives on the scene as the ultimate "glue" to make these
technologies interact, if not seamlessly, at least without the excess baggage that
accompanied previous technologies like CORBA and RMI.
In some sense, Web services represent the second coming of CORBA. But whereas
CORBA was an object-oriented, IIOP-based binary communications framework, laden
with stubs, skeletons and vendor-specific ORBs, Web services are lightweight, HTTP-
based, XML-driven, and completely platform- and language-neutral. Where CORBA was
a 600-pound semi-caged gorilla, Web services is a gazelle romping freely through the
vast Internet preserves.

Publish, Bind, and Find

A Web services framework consists of a publish-find-bind cycle, whereby service
providers make data, content or services available to registered service requesters who
consume resources by locating and binding to services. Requesting applications tune
themselves to Web services using WSDL (Web Services Description Language), which
provides low-level technical information about the service desired, grants applications
access to XML Schema information for data encoding, and ensures that the right
operations are invoked over the right protocols.
Publish, bind and find mechanisms have their respective counterparts in three separate
(but somewhat equal) protocols that make up the Web services network stack: WSDL,
SOAP and UDDI (Universal Description and Discovery Interface).
To drill down a little deeper on the CORBA analogy, SOAP plays the role of IIOP in
CORBA (or JRMP in RMI). It's the binding mechanism between conversing endpoints.
WSDL, on the other hand, plays the role of IDL (Interface Definition Language). In this
capacity, WSDL defines Web services as a collection of ports and operations. A WSDL
port is analogous to an interface, and a WSDL operation is analogous to a method.
WSDL publishes Web service interfaces to parties interested in communicating across
heterogeneous platforms.
WSDL, however, goes beyond just being an interface definition language; it also includes
constructs that let you describe address and protocol information for the Web services
you want to publish. The interesting thing about WSDL is that it describes an abstract
interface for Web services while simultaneously allowing you -- in excruciating detail --
to bind a Web service to a specific transport mechanism, such as HTTP. By abstracting
the interface, WSDL functions as a reusable Web service technology. By binding to a
specific transport mechanism, WSDL makes the abstract concrete. If this seems
somewhat schizophrenic, just think of the space shuttle: a reusable, fully functioning
space capsule bound to dedicated, but expendable, booster rockets. The transport
mechanism may change, but the payload persists.
Finally, UDDI acts as a registry for publishing and locating Web services. By exposing
service information and binding interfaces in a Web-based registry, UDDI provides a
shared directory for businesses and customers to locate one another's Web services.

Building Web Services

SOAP lets you build applications by remotely invoking methods on objects. SOAP
removes the requirement that two systems must run on the same platform or be written in
the same programming language. Instead of invoking methods through a proprietary
binary protocol, a SOAP package uses XML, a text-based syntax for making method
calls. All information between the requesting application and the receiving object is sent
as tagged data in an XML stream over HTTP. From a Web services point of view, SOAP
may be implemented as either a client or a server.

SOAP Clients and Servers

A SOAP client is a program that creates an XML document containing the information
needed to invoke remotely a method in a distributed system. SOAP clients need not be
traditional. In addition to being your garden-variety desktop application, a SOAP client
could also be a Web server or a server-based application.
Messages and requests from SOAP clients are typically sent over HTTP. As a result,
SOAP documents are able to traverse almost any firewall, enabling the exchange of
information across divergent platforms.
A SOAP server is simply special code that listens for SOAP messages and acts as a
distributor and interpreter of SOAP documents. External Web services may interact with
application servers based on J2EE[tm] technology, which process SOAP requests from a
variety of clients.
SOAP servers ensure that documents received over a HTTP connection are converted to a
language that the object at the other end understands. Because all communications are
made in the form of XML, objects in one language (say, Java) may communicate through
SOAP with objects in any other language (C++, for example). It's the job of the SOAP
server to make sure the end points understand -- and are happy with -- the SOAP they're
being served.

SOAP and Java Technology

According to the SOAP 1.1 specification, SOAP is "a lightweight protocol for exchange
of information in a decentralized, distributed environment."
SOAP does not mandate a single programming model -- nor does it define language
bindings for a specific programming language. In the context of the Java programming
language, it's up to the Java community to define the specific language binding. Java
language bindings are now being pursued through the JAX-RPC initiative.
In a recent talk on SOAP given at the JavaOne[sm] developer conference, Sun engineers
Roberto Chinnici and Rahul Sharma defined the role of the JAX family of technologies
as "enabling the creation of Web services using the familiar JSP[tm] and EJB[tm]
component technologies for the Java platform." Servlets and stateless session beans were
cited as the two most likely Java technologies for encapsulating Web services.

So What Is SOAP, Really?

Having thoroughly set the stage for SOAP and described its crucial role in Web services,
let's take a closer look at what SOAP really is, what it does, and how it does it.
SOAP is an extensible, text-based framework for enabling communication between
diverse parties -- in general, objects -- that have no prior knowledge of each other or of
each other's platforms. From the point of view of objects on the net, SOAP is the ultimate
blind date. Client applications can interoperate in loosely-coupled environments to
discover and connect dynamically to services without any previous agreements having
been established between them.
SOAP is extensible, because SOAP clients, servers and the protocol itself can evolve
without breaking existing apps. SOAP, moreover, is generous in terms of supporting
intermediaries and layered architectures. This means processing nodes can sit on the path
a request takes between the client and server. These intermediate nodes process parts of
the message specified by SOAP through the use of headers, which allow clients to
identify which node works on what part of the message. This type of intermediate header
processing is performed by private contract between the client application and the
intermediate processing node. SOAP provides a mustUnderstand attribute for
headers, which allows the client to specify whether the processing is mandatory or
optional. If mustUnderstand is set to 1, the server must either perform the
intermediate processing specified in the header or throw a fault.
SOAP also defines data encoding rules, called base level encodings or "Section 5"
encodings, from the section of the SOAP spec that describes them. It should be pointed
out that SOAP encodings take up most of the space in the 40-page SOAP 1.1 spec.
Without getting bogged down too deeply in XML data type specifics -- a swamp still
being drained by experts over at the XML Schema group -- SOAP encodings can be
described briefly as a collection of either simple or compound values.
Simple values are either simple types, like ints, floats and strings, or built-in types as
defined in Part 2 of the XML Schema specification. These include data types such as
arrays of bytes and enumerations.
Compound values include structures, arrays and complex types as defined -- again -- by
the XML Schema group. Last, but certainly not least, SOAP data encodings specify rules
for object serialization; that is, mechanisms for marshaling and unmarshaling data
streams across the net. It's important to note that these "Section 5" encodings are not
mandatory in any way, so clients and servers are free to use different conventions for
encoding data as long as they agree on format. Doing so, however, countermands the
push SOAP gives to standardized services on the net and comes with the usual caveat:
your mileage may vary. Individual clients and servers are nonetheless free to take the
road less traveled.
Finally, SOAP establishes a set of rules that enable clients and servers to do remote
procedure invocation using SOAP as a communications framework. SOAP -- at base a
message-oriented protocol -- can, with these conventions, work well as an RPC-type
protocol. Object serialization is the mechanism that gives SOAP-RPC its punch.

Message Format
SOAP does all this in the context of a standardized message format. The primary part of
this message has a MIME type of "text/xml" and contains the SOAP envelope. This
envelope is an XML document. The envelope contains a header (optional) and a body
(mandatory). The body part of the envelope is always intended for the final recipient of
the message, while the header entries may target the nodes that perform intermediate
processing. Attachments, binary or otherwise, may be appended to the body.
SOAP provides a way for the client to specify which of the intermediate processing nodes
has to deal with what header entry. Because headers are orthogonal to the main content of
the SOAP message, they're useful in adding information to the message that doesn't effect
the processing of the message body.
Headers, for example, may be used to provide digital signatures for a request contained in
the body. In this circumstance, an authentication or authorization server could process the
header entry -- independent of the body -- stripping out information to validate the
signature. Once validated, the rest of the envelope would be passed on to the SOAP
server, which would process the body of the message. A closer look at the SOAP
envelope will help to clarify the placement and purpose of SOAP header and body
elements.

Anatomy of a SOAP Envelope

The SOAP 1.1 spec provides the following sample envelope:

<SOAP-ENV: Envelope
xmlns:
SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI">
SOAP-ENV:mustUnderstand="1"
5
</t:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="some-URI">
<symbol>DEF</Symbol>
</m: GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-Envelope>
In this example, a GetLastTradePrice request is being sent to a stock-quote service
somewhere on the Web. The request takes a string parameter, a ticker symbol, and
returns a float in the SOAP response.
The SOAP envelope is the top element of the XML document that represents the SOAP
message. XML namespaces are used to disambiguate SOAP identifiers from application
specific identifiers. XML namespaces are used heavily in SOAP to qualify or scope
elements in the message to a specific domain. To understand SOAP namespaces, it helps
to be familiar with the namespace spec for XML. If you're not, simply think of
namespaces as neighborhood identifiers that help uniquely identify SOAP elements by
associating them with specific locations, real or imagined.

Namespaces
The first namespace in the example references the SOAP schema, which defines the
elements and attributes in the SOAP message. The second namespace refers to SOAP
encodings, the "Section 5" data types discussed earlier. Since no additional per-element
encoding is specified, this encoding applies to the whole document.

Header
The first element identified in this sample SOAP envelope header is a transaction
element, accompanied by a namespace attribute and by the mustUnderstand attribute
with a value of 1. Since mustUnderstand is set to 1, the server accepting this
message must perform intermediate processing on this transaction node. You can
interpret this to mean that the server and client have previously agreed upon the
semantics that govern the processing of this header element, so that the server knows
exactly what to do with the contents of the element, in this case 5.
If the server receiving this message doesn't understand the semantics of the transaction
header, it is required to reject the request completely and throw a fault. A fault element is
a special part of the SOAP body and a well-defined mechanism to ship error information
back to the client.
Intermediate processing nodes like this are an example of SOAP's extensibility. Clients
include such nodes in a SOAP message to indicate that special processing needs to take
place before the contents of the message body can be processed. Ensuring backward
compatibility with existing servers not capable of providing such processing is simply a
matter of setting the mustUnderstand attribute to 0, which makes the action optional.
In addition to defining transaction nodes like the one described above, a SOAP message
may optionally contain header entries specifying nodes that perform authorization
processing, encryption, persistence of state, business logic processing and so on. Headers
help make SOAP a modular, extensible packaging model. Just keep in mind that header
processing is entirely independent of the SOAP message body.

Body
The SOAP body in the example contains an XML payload, which we can surmise,
without really seeing it spelled out for us, does RPC. SOAP is not only a modular
packaging model, it's also a fairly cryptic packaging model.
Nothing here explicitly shows that RPC is begin done. All we see in the body are a
couple of XML elements, one qualified by a namespace. It's up to the SOAP server to
understand the document semantics and do the right thing. The server, in effect, provides
a framework for dealing with the XML payload in a meaningful way. "Meaningful" here
implies that the server invokes a remote procedure call on some back-end database to
receive the stock price for the stock-symbol element contained in the message body. All
the magic takes place behind the SOAP RPC curtain.

SOAP-RPC
SOAP messages are fundamentally one-way transmissions from a sender to a receiver,
but SOAP messages are often combined to implement request/response mechanisms. To
do RPC using SOAP, a few conventions must be followed. First of all, request and
response messages must be encoded as structures. For each input parameter of an
operation, there must be an element (or member of the input structure) with the same
name as the parameter. And for every output parameter, there must be an element (or
member of the output structure) with a matching name.
Here's a foreshortened, RPC-based view of the SOAP message presented earlier. Only
the body portions of the SOAP request and response envelopes are shown.
Request

<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="some-URI">
<symbol>DEF</Symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>

Response
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="some-URI">
<price>22.50</price>
</m: GetLastTradePriceResponse>
</SOAP-ENV:Body>

The request invokes the GetLastTradePrice method. Notice the response defines a
GetLastTradePriceResponse operation. A convention common to SOAP calls
for appending Response to the end of a Request operation to create a Response
structure. This output structure contains an element called price, which returns the results
of the method invocation, presumably as a float.
It's important to note that nowhere in the SOAP envelope are data types explicitly
delineated, so we really don't know the type of the symbol or the type of the result
parameter price just by looking at the SOAP message. Client applications define data
types either generically through "Section 5" encodings, or privately via agreed-upon
contracts with servers. In either case, these definitions are not explicitly included in the
SOAP message.
Finally, in order to do RPC, a lower-level protocol like HTTP is needed. Although the
SOAP 1.0 specification mandated the use of HTTP as the transport protocol, SOAP 1.1 1
(and its sister specification "SOAP Message with Attachments") permit the use of FTP,
SMTP or even (possibly) raw TCP/IP sockets. All the serialization and encoding rules
general to SOAP apply to RPC parameters as well.

A SOAP Use Case

Now that you've seen the SOAP envelope in detail, it helps to pull back a little and view
SOAP from a use-case perspective to grasp the round-trip processing that takes place in a
distributed Web environment. Here are a few broad, summary propositions that form the
conceptual backbone of Web services and SOAP.
• A client application somewhere on the Internet consumes Web services.
• Web services (via SOAP) expose object methods.
• Object methods access remote data anywhere on the Web.
Applying transitive logic to these network propositions, we can deduce the whole point of
Web services and SOAP: Clients somewhere consume data anywhere on the Web. QED.
Here's the use case in a little more detail.

1. A SOAP client uses the UDDI registry to locate a Web service. Rather than
manipulate WSDL directly, in most cases a SOAP application will be hardwired
to use a particular type of port and style of binding, and it will dynamically
configure the address of the service to be invoked to match the ones discovered
through UDDI.

2. The client application builds a SOAP message, which is an XML document

capable of performing the desired request/response operation.

3. The client sends the SOAP message to a JSP or ASP page on a Web server
listening for SOAP requests.

4. The SOAP server parses the SOAP package and invokes the appropriate method
of the object in its domain, passing in the parameters included in the SOAP
document. Optionally, intermediate processing nodes may have performed special
functions as indicated by SOAP headers prior to receipt of the message by the
SOAP server.

5. The request object performs the indicated function and returns data to the SOAP
server, which packages the response in a SOAP envelope. The server wraps the
SOAP envelope in a response object, such as a servlet or a COM object, which is
sent back to the requesting machine.

6. The client receives the object, strips off the SOAP envelope and sends the
response document to the program originally requesting it, completing the
request/response cycle.

Summary
SOAP is an XML-based protocol for sending messages and making remote procedure
calls in a distributed environment. Using SOAP, data can be serialized without regard to
any specific transport protocol, although HTTP is typically the protocol of choice.
SOAP is good for building platform and language-neutral systems that interoperate.
Overall, SOAP and Web services account for everything needed to build a distributed
application infrastructure on top of XML. SOAP minimizes the problem of multiple-
platform incompatibilities in accessing data by resolving the conflict between the COM
and Java component object models.
To return to the metaphor that kicked off this discussion, SOAP is the perfect medium for
object entities of all types -- even Hollywood types like Brad Pitt and Edward Norton --
to use as a communications medium. As in the film, expect the results of this new
technology to be earth-shaking.
Overview of ebXML
ebXML is a joint initiative of the United Nations (UN/CEFACT) and OASIS, developed
with global participation for global use. This partnership brings a great deal of credibility
to ebXML, representing major vendors and users in the IT industry and support from
leading vertical and horizontal industry groups including RosettaNet, OTA (Open Travel
Alliance) and many others. Membership in ebXML is open to anyone, and the initiative
enjoys broad industry support with hundreds of member companies, and more than 1,400
participants drawn from over 30 countries.
The fundamental goal of ebXML is to create a single global electronic market. This is
accomplished by developing a single set of internationally agreed-upon specifications,
which are developed with the following goals in mind:
• Enable simple, easy and ubiquitous electronic business through the use of XML.
• Minimize costs of doing business electronically.
• Maintain full compliance with W3C XML technical specifications.
• Provide multilingual support.
• Maximize interoperability and efficiency while providing a transition path for
EDI (Electronic Data Interchange).

ebXML was designed primarily for business-to-business interaction. The Web services
protocols UDDI (Universal Description, Discovery and Integration) and SOAP (Simple
Object Access Protocol) provide services that perform many similar functions, but
ebXML is much broader than these standards in scope and functionality. In the real
world, companies will likely use both UDDI/SOAP and ebXML. Both solutions are built
on open standards and rely heavily on XML. For these reasons, ebXML and
UDDI/SOAP may work together through gateways to permit access to even more
businesses.

Architectural Overview
For enterprises to be able to conduct business with each other they must:
• Discover what products and services are being offered.
• Determine which shared process and information exchanges to use for obtaining
these products or services.
• Determine the contact points and establish a form of communication for the
exchange of business documents.
• Agree on the contractual terms, contact points and form of communication.
Once these steps are completed, enterprises can conduct business based on a process
upon which everyone agrees. ebXML is designed to provide this process and is built on
three basic concepts:
1. A robust, reliable, and secure communications infrastructure.
2. A mechanism for modeling business information and processes.
3. A marketplace that allows enterprises to find each other, agree to become trading
partners and conduct business with each other.
Communications Infrastructure
The communications infrastructure is provided through:
• A message transport mechanism with a standard, well defined interface, standard
packaging rules, and predictable delivery and security.
• A "business service interface", i.e., a piece of software that sits at each business to
handle incoming and outgoing messages.
• Integration to existing back-office applications. (This is currently out of the scope
of ebXML, but it probably represents both the biggest challenge and the biggest
opportunity for software providers.)

Business Modeling
Business modeling is provided via the following elements of the ebXML standard:
• A specification for defining business processes and information models.
• A set of reusable business objects based on core components.
• A process for defining message structures.

Marketplace
The marketplace to allow enterprises to find each other and agree to become trading
partners is provided by the following elements of the ebXML standard:
• A shared repository (registry) where enterprises can register and discover each
other.
• A process for defining and agreeing to a formal Trading Partner Agreement
(TPA).

Business Process and Information Model

A large part of conducting business between parties involves understanding each other's
business processes. For example, a buyer orders a set of goods or services from a seller
by issuing a purchase order. The seller delivers the goods or services along with a receipt.
The seller may also send a acknowledgment of the purchase before delivery. This is a
common process that can be modeled as exchanges of predefined documents, but it must
also account for problems that may arise, such as insufficient stock or an inability to meet
a delivery deadline.
The ebXML business process specification provides a standard framework for defining
business transactions. These transactions use signals to acknowledge the exchange of
documents (like purchase orders) and notifications of success or failure. The current
version of ebXML supports binary collaboration (business between two parties). Future
versions will support business collaboration among multiple parties and multiparty
contracts.
The business process and information model includes the following scenarios, each
described in some detail below:
• Defining the business process
• Defining transactions
• Executing the process

Defining the Business Process

A business process is defined in two documents, a class diagram of business objects in
UML and business rules defined in XML. The business objects are modeled just like
objects in any system. The XML process document contains a set of rules that describe
the roles of the trading partners and exchange of documents in a transaction. There are
some other details like Collaboration Protocol Profile (CPP) and Collaboration Protocol
Agreement (CPA) that are used to bridge the gap between the process and the actual
software on each end. The business processes are usually defined by people who
interview professionals with specific knowledge about how a company works.

Defining Transactions
Once the models are prepared in the correct format, an ebXML system can accept them
and build a state machine that can conduct business based on the specified rules. The
rules define transitions between a series of states in the process. For example, a state
transition could be something like "purchase order sent" to "acknowledged purchase
order received."

Executing the Process

Execution of a process is made up of transactions. A transaction is an atomic unit of work
between trading partners which is simply an exchange of documents, such as a purchase
order. A transaction can succeed or fail. If it succeeds, it is legally binding. If it fails, it is
null and void and the transaction is rolled back. Transaction semantics can specify a
number of parameters such as required security, reliability, and timeliness.
Below is an example of a "two-document transaction," which is an order transaction used
by a binary collaboration.

<BusinessTransaction name="Create Order">

<RequestingBusinessActivity name=""
isNonRepudiationRequired="true"
timeToAcknowledgeReceipt="P2D"
timeToAcknowledgeAcceptance="P3D">
<DocumentEnvelope BusinessDocument=
"Purchase Order"/>
</RequestingBusinessActivity>
<RespondingBusinessActivity name=""
isNonRepudiationRequired="true"
timeToAcknowledgeReceipt="P5D">
<DocumentEnvelope isPositiveResponse="true"
BusinessDocument="PO Acknowledgement"/>
</DocumentEnvelope>
</RespondingBusinessActivity>
</BusinessTransaction>

The above order transaction acknowledges a purchase order within a specified time. P2D,
P3D, and P5D are time durations, i.e., period two days, period three days and period five
days, respectively.

Below is an example of binary collaboration (two-party) using the transaction specified

above.
<BinaryCollaboration name="Product Fulfillment"
timeToPerform="P5D">
<Documentation>
timeToPerform = Period: 5 days from start of
transaction
</Documentation>
<InitiatingRole name="buyer"/>
<RespondingRole name="seller"/>
<BusinessTransactionActivity name="Create Order"
businessTransaction="Create Order"
fromAuthorizedRole="buyer"
toAuthorizedRole="seller"
isLegallyBinding="true"/>
<BusinessTransactionActivity
name="Notify shipment"
businessTransaction="Notify of advance shipment"
fromAuthorizedRole="seller"
toAuthorizedRole="buyer"/>
</BinaryCollaboration>
This binary collaboration describes the interaction of two roles, a buyer and a seller. The
buyer initiates a single "create order" transaction. In response, the seller performs a
transaction that sends a notification of shipment. Real business scenarios will probably
include more complex activities and many more transactions.

Sharing Information (ebXML Registry and Repository)

The ebXML registry and repository is a means of sharing information between businesses
interested in becoming trading partners. The ebXML registry and repository can be
located on a Web site or hosted by an Application Service Provider (ASP) or a Virtual
Private Network (VPN) provider. In either case, the information stored can be accessed
by businesses within some domain. That domain could be limited to a few companies, or
it could be available globally.
While the registry is a lookup service similar to the UDDI standard, the ebXML
repository takes it a step further, holding information about how a business works:
business-process documents and Collaboration Protocol Profiles (CPPs). CPPs define the
potential roles of businesses, services offered and the means of accessing these services.
Buyers can query a registry, discover sellers and propose trading agreements in an
ebXML registry. Once a seller agrees to a buyer's terms (contained in the CPP), the buyer
and seller can conduct business by exchanging documents based on their established
business process.

Document Exchange (ebXML Messaging)

To conduct business, a reliable means of exchanging documents is crucial. Although it
sounds simple, there are a lot of details we take for granted in conventional document
exchange. For example, physical mail is considered reliable and legally binding. Only
one copy of a document is sent, and only one is received. This basic requirement must
carry over to the electronic world without adding a too much complexity. In addition,
existing messaging software can be leveraged and reused. The following aspects of
ebXML messaging are described below:
• Specification goals
• Message acknowledgment
• Message service transport
• Message service payload

Specification Goals
The ebXML messaging specification was developed with the following goals in mind:
• Reliable messaging
• Support for a variety of communication protocols (HTTP, SMTP, and so on)
• Support for information of any type
• Simple implementation
• Support for enterprises of all sizes
• Leveraging existing standards wherever possible

Message Acknowledgment
Reliable exchanging messages means that, with respect to sending and receiving
messages, the following is true:
• For any given message sent, the messaging service delivers, at most, one copy of
the message to the receiving application.
• A positive acknowledgment is sent from the receiving messaging service to the
sending messaging service, indicating that the message has been received and
stored persistently.
• If an acknowledgment is not received, the sending messaging service will notify
the sending application.

Message Service Transport

The messaging service is transport neutral, meaning that any underlying transport can be
used. The underlying transport need not be reliable or acknowledge transmission. This
means the messaging service can be used with high-end application servers, Web servers,
or even e-mail servers. This way, businesses of any size can use ebXML without having
to invest in new systems and software.

Message Service Payload

The messaging service is payload neutral, meaning that any kind of information can be
reliably routed. This information can include XML documents, binary data, or EDI
messages. The messages are comprised of a routing header and a payload container. This
is just like conventional mail where addresses are printed on a package which can hold all
kinds of documents. This separation of routing information and data is critical in business
messaging. In many cases, business scenarios will include intermediaries or brokers of
products and services. These intermediaries should be able to reroute messages without
altering their contents, as this would compromise the integrity of the message.

Typical Usage Scenario

This diagram illustrates an implementation of ebXML.
Company A builds and deploys its own ebXML-compliant application. Company A
registers the application, along with its required business profile (including
implementation details and reference links), to the ebXML registry (step 1). The business
profile describes the company.
Company B discovers the existence of the application (step 2) and submits its own
business profile information to the registry (step 3).
Company A explores the business scenarios supported by Company B in the ebXML
registry (step 4) and sends an acknowledgment to Company B confirming (or not) that
the business scenario is compatible.
Company B, in turn, sends a signal to Company A that it would like to engage in a
business scenario (step 5) by submitting a proposed business arrangement directly to
Company A's ebXML-compliant software interface. The proposed arrangement outlines
the mutually agreed-upon business scenarios and specific agreements. The business
arrangement also contains information about the messaging requirements for transactions
to take place, contingency plans and security-related requirements.
When Company A accepts the business, the two parties are ready to engage in e-business
using ebXML (step 6).

Summary
ebXML allows businesses of all sizes to make their products and services available to a
global marketplace. This is accomplished through a set of comprehensive and open
standards based on XML. The use of open standards built on Internet technologies lowers
the barriers to entry to achieve ubiquitous support. Businesses can discover and negotiate
agreements with trading partners automatically and then exchange documents in a secure,
reliable manner.
Overview of WSDL
Web Service Description Language (WSDL) is an XML language that contains
information about the interface, semantics and "administrivia" of a call to a Web service.
Once you have developed a Web service, you publish its description and a link to it in a
UDDI (Universal Description, Discovery and Integration) repository so that potential
users can find it. When someone thinks they want to use your service, they request your
WSDL file in order to find out the location of the service, the function calls and how to
access them. Then they use this information in your WSDL file to form a SOAP (Simple
Object Access Protocol) request to your computer.

The WSDL Standard

The WSDL standard is being worked out by the W3C (World Wide Web Consortium).
That body further defines the standard as "an XML format for describing network
services as a set of endpoints operating on messages containing either document-oriented
or procedure-oriented information. The operations and messages are described abstractly,
and then bound to a concrete network protocol and message format to define an endpoint.
Related concrete endpoints are combined into abstract endpoints (services). WSDL is
extensible to allow description of endpoints and their messages regardless of what
message formats or network protocols are used to communicate."

A Java[tm] API for WSDL (JWSDL)

A Java API for WSDL (JWSDL) specification is currently in the works in the Java
Community Process[sm] (JCP). When released, it will provide an API for manipulating
WSDL documents without directly interacting with the XML documents. While you can
currently achieve the full range of WSDL functionality using JAXP, JWSDL will be
much easier and faster to use, simplifying the developer's work.

How WSDL Works in the World of Java Technology

The following diagram illustrates how a Web service is registered, found and called in a
scenario based on Java technology.
In this diagram, the Web service is registered in a UDDI repository using the Java API
for XML Registries (JAXR), where a business partner or other system can find the
service. The registry information from UDDI is used to locate a WSDL document that
details the call semantics for the Web service. With the WSDL document in hand, the
Java programmer can then feed it to a tool that can generate a Java object proxy to the
Web service, or simply use it as a reference document along with a lower-level SOAP
API.

A Sample WSDL Definition

The WSDL definition shown in the example below contains the following key pieces of
information:
• A description/format of the messages that can be passed (via embedded XML
Schema Definitions) within the <types> and <message> elements

• The semantics of the message passing (e.g. Request-only, request-response,

response-only) within the <portType> element

• A specified encoding (various encodings over a specified transport such as HTTP,

HTTPS, or SMTP) within the <binding> element

• The endpoint for the service (a URL) within the <service> element
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace=
"http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace=
http://example.com/stockquote.xsd
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol"
type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
<message name="GetLastTradePriceInput">
<part name="body" element=
"xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>
<binding name="StockQuoteSoapBinding"
type="tns:StockQuotePortType">
<soap:binding style="document"
transport=
"http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
 <soap:operation
soapAction=
"http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort"
binding="tns:StockQuoteBinding">
<soap:address location=
"http://example.com/stockquote"/>
</port>
</service>
</definitions>