Answering the critical Web services questions
- By Peter Fischer
- July 1, 2002
The IT industry is currently swept up in the latest buzzword -- Web services.
The hoopla accompanying the emergence of this new technology darling has vendors
scrambling to bring supporting products to market.
But it is time to move past the hype and uncover the truth about Web
services. My goal is to set the record straight and answer three critical
questions about Web services: What are Web services? Why are they important? And
how can they help solve IT problems?
Armed with these answers you will be prepared to go into battle with Web
services as a part of your IT solutions toolkit. And you will understand how Web
services are enabling two important trends: enterprise portals and app
Web services are evolutionary; they represent a progression of existing
distributed computing models. And they are revolutionary; they will
fundamentally change the way we build and deploy applications over a global
Web services' capabilities and features are not new. The idea of providing
distributed software services has been around for more than a decade.
Technologies like RPC, DCOM and CORBA were built from a client/server foundation
focused on creating a standard technology platform on which to accomplish ''true''
app-to-app communication by providing access to remote methods. Messaging then
came along and freed us from the shackles of synchronous communication, enabling
point-to-point and Publish/Subscribe communication models utilizing messages as
the ''exchange currency.''
Web services build on these technologies and simplify the development and
deployment of distributed app systems. They do this by combining a
standards-based approach to distributed computing with the availability and
accessibility of the Internet. HTML and HTTP were two catalysts of the first Web
revolution, providing standard technologies for creating webs of
human-accessible content. But while HTML and HTTP opened up a web of related
information, they did not simplify access to business systems and services. The
missing ingredient was the ability to share processes and data across a global
network: the Internet.
A Web services platform provides the foundation for the next generation of
distributed computing, enabling the creation of a web of collaborative services
that are machine-accessible and peer-to-peer in nature. Web services' value is
that it enables pervasive machine-to-machine computing over the Internet. It is
this platform of technologies that will enable us to achieve the true benefits
of distributed computing that have historically eluded us.
The ticket to Web services' success is that it is based on fundamental
standard technologies that everyone agrees on, including companies like IBM, BEA
Systems and Microsoft. Using these standards, Web services provide
''between-the-boxes'' communication capability by specifying the semantics of
information via standard message exchange technology protocols, as well as the
format of these messages.
Web services will change the way we architect, build and deploy the next
generation of distributed apps. This new breed of ''aggregate apps'' is built
from a set of loosely coupled components with Web services providing the
foundation ''glue,'' and loosely coupled connections to make these components
The technologies that work together to provide this ubiquitous standard
connectivity are XML, SOAP, WSDL and UDDI. These technologies work together to
provide a Web services model with important functionality: a loosely coupled
model for exchanging information; a standard format for packaging and sending
data over the wire; the ability to make interface definitions available; the
ability to locate and register interest in a service; and the ability to
describe the capabilities of a service and information about how to access a
The Web services technology stack is penetrated through the use and leverage
of XML. XML provides the lingua franca of Web services; every other Web
services technology eats and breathes XML. I use the term ''informational
middleware'' to describe XML's power, applicability and potential. Web services
finally realize XML's promise by providing the standard format for specifying
both application interfaces and application messages.
SOAP defines an XML-based message protocol that provides a standard way of
passing XML-encoded data and remotely accessing services and objects in a
platform-independent way. SOAP messages are packaged into HTTP messages,
enabling message and method invocation over the Internet using existing
communication technologies. And SOAP is firewall-friendly; it does not require
changes to existing corporate Internet firewalls.
A SOAP message is wrapped within an HTTP message and consists of a mandatory
SOAP envelope, an optional SOAP header and a mandatory SOAP body defined as an
XML document. The HTTP header contains the traditional HTTP request and response
information and wraps the SOAP machinery. It specifies the action of the SOAP
message with the SOAPAction parameter, which typically indicates the target
destination address as a URL for the message.
The technical end of the SOAP message is the SOAP envelope, which defines the
framework for describing the contents and processing of the message. It can
specify a set of encoding rules for serializing app-defined data over the wire.
Both the provider and requester must agree on this ''language,'' usually by
referring to the same schema that defines them. The envelope and the encoding
rules are defined using different XML namespaces.
The optional SOAP header contains service- and request-specific information,
and is the ''extensibility'' point for the SOAP message. It provides the
mechanism for extending SOAP in place to include additional capabilities such as
security, transactions and quality-of-service features for the request.
The business end of the SOAP message is the SOAP body, which contains the
app-defined data being exchanged. The data is specified using XML and can be
expressed as a single self-describing structure or as an RPC-style interface
that includes method name and typed parameters. The latter is remote method
invocation that uses XML to describe the complete request.
The SOAP communication model exchanges messages between a requester and a
provider. To invoke a remote method, the requester sends a SOAP request message
to the provider indicating the action to be performed and passing the required
parameters in the SOAP body. The provider replies by sending a response message
with the requested data in the SOAP body. If an error occurs, a detailed error
message is sent back to the requester describing the fault.
SOAP's power is its simplicity. The specification is aimed at specifying a
basic mechanism for routing a request to its target by providing the required
information to enable the invocation. Those who criticize SOAP as slow and see
it as a performance bottleneck in app-to-app communication are missing the
point, and are overlooking SOAP's value and merit.
One cannot deny that CORBA and DCOM have better performance by the numbers.
After all, DCOM and IIOP provide ''on-the-wire'' interoperability and perform
better because they are not required to propagate any meta-information between
partners. This comes from their connection-oriented nature; components
participating in an exchange have a persistent and transactional connection
The connectionless nature of the Internet and its supporting technologies do
not provide this capability. To enable effective communication over the
Internet, SOAP provides an ''over-the-wire'' protocol that specifies a standard
way to package requests based on XML that can be sent wrapped in HTML over
commodity connectivity technologies like HTTP.
SOAP provides leverage in helping us overcome the challenges of component
model and platform integration. The IT industry has been playing the component
and platform integration game for a while, and my article, ''Renew, don't
rewrite, legacy systems'' in ADT's December 2001 issue detailed some
recent advances in the field. However, these solutions still fall short and it
is still not easy to get CORBA objects to interoperate effectively with DCOM
objects. SOAP provides the answer to this dilemma with its ability to express
methods and parameters as XML -- SOAP provides the basis for component model
integration without bridges.
SOAP ''cleans up'' the interoperability issues and challenges that have
plagued business-to-business and app-to-app initiatives by providing the
universal messaging currency. In the case of Web services, when you think of
SOAP, think of pervasive and large-scale interoperability and not performance.
After all, when you use the Internet as a communication medium, all bets are off
on predicting performance. SOAP also provides the messaging to support the other
two key Web services technologies, WSDL and UDDI.
WSDL provides the ''datasheet'' for Web services, but instead of rendering
the information in .pdf, it renders it in XML. WSDL provides the complete
interface for a Web service and is the IDL for a Web service. The XML grammar
for WSDL is rich and provides everything a service requester needs to know to
bind to a Web service and utilize its methods, including:
* A definition of the message format the Web service accepts and sends using
the and elements, as well
as appropriate schema definitions;
* The methods of the service using ;
* The semantics of the service that define how the methods of a service are
called, such as synchronous request/reply, asynchronous and so on;
* The end point and transport of the service using the element; and
* The specific protocol used to bind to the service, including HTTP, HTTPS
and JMS. WSDL provides both static and dynamic binding. Static binding uses a
development tool to generate code to invoke the methods on a Web service.
Dynamic binding is provided via the automatic creation of the appropriate access
code at runtime. This 'tooling' makes it easier to write code that accesses Web
services. WSDL must be located in a public repository to allow service
requesters to look up binding information for Web service providers.
UDDI provides a standard interface to WSDL repositories and defines several
lookup services that allow requesters to locate and retrieve the WSDL for Web
service providers. A UDDI repository is a broker of information about the Web
services that have been registered with it, and is similar to a CORBA interface
UDDI provides three ways to look up a Web service: white pages, which locates
a Web service by name; yellow pages, which locates a Web service by type of
offering or topic; and green pages, which locates a Web service by its
Adopting and applying Web services to real solutions
services can revolutionize the way we build and deploy B2B and B2C
functionality. Pulling these technologies together provides the foundation for
an extensible and flexible computing platform that provides access to small
granular services and opens the door for large-scale services access and app
We are currently in the early adopter phase, and many firms are trying to
fight the hype and use Web services to deploy simple service-based functionality
over the Internet. Much of this hype is about deploying simple Web services
front ends over isolated code and functionality, making it available to the
''masses.'' Some examples are the credit card authorization, shipment tracking,
currency conversion and simple calculation Web services that can be invoked from
''Web services sites.'' While providing functionality such as credit card
authorization via a Web service is valuable, this adoption of Web services ''in
the small'' only offers an incremental benefit over existing mechanisms.
Web services' true value will emerge when business functions and services are
wrapped and made available on demand to a larger audience, including business
partners and corporate users. The second generation of Web services
implementations will be focused on wrapping business assets to provide the
foundation for the adoption of Web services ''in the large.''
Web-based access to integrated information has been the focus of app portals.
Current portal solutions provide simple, customizable content integration within
HTML, offering single-point access to key and related information both within an
enterprise and between an organization and its customers. However valuable these
portals are for providing one-stop shopping for information content, the true
value of a portal as a ''view'' into an organization's business environment will
not be realized until it is integrated with business IT assets, including
corporate business functions, services and processes. The next generation of
portals, the Enterprise Information Portal (EIP), will be a full-featured
environment that provides true portals into the business of the enterprise.
Enterprise portals will require integration of enterprise apps that execute
across a heterogeneous set of apps. Web services provides the ''plugs'' that
connect the source back-end systems to user interface components, called
portlets, that provide a focused view into a business service. A portal can
provide a dashboard of services to the user, in our case a customer service
representative who needs access to legacy processing systems and databases. This
dashboard is easily built by deploying the appropriate portlets into the
With Web services-based components, firms can begin to architect and deploy
this new generation of portals that are aggregate apps whose constituent
services can execute anywhere on the 'Net. These portals provide access to the
business IT infrastructure of a company, allowing customers, employees and
business partners to be ''integrated'' with the business.
A snapshot of the Web services industry shows that a large contingent of
early adopters are firms seeking both cost- and time-effective approaches and
technologies for implementing their demand-chain and supply-chain solutions. A
few years ago, some of these same companies were looking to EAI to create these
solutions. Many experts expected EAI would be an integral part of the
standardization of interfaces and messages that would enable these firms to
communicate with their partners more effectively.
But recently, firms have shied away from EAI implementations that require
significant up-front investment of resources and financial commitment with no
measurable short- or medium-term ROI. The business case for creating these
integration points still exists; but with shrinking IT budgets and the market
demand for rapid deployment of solutions, the model has shifted to building app
integration solutions in an incremental way using more ''commodity''
From a technical perspective, Web services fills in what EAI lacked -- a
standard, on-the-wire format to enable app components to exchange messages in an
implementation-independent way. Web services, through SOAP and XML, provides
this format and ''XML-itizes'' app integration. Combining its loosely coupled
nature with standard-driven technologies that are ''toolable,'' Web services is
a good approach to app integration in the small.
The sweet spot for Web services is sharing business logic in a non-intrusive
way. Existing interfaces can be ''e-nabled'' for integration within the
enterprise and between partners and customers. Web services provide an ''inside
out'' approach to app integration where existing interfaces are wrapped as
components with interfaces specified in XML in WSDL files.
To move from packaging and making functionality available via Web services to
using Web services effectively, we must create an architecture that enables
large-scale and pervasive use of Web services assets. Web services' benefits do
not come from the mechanisms of the technologies that support it, but from the
architecture and implementation that uses the technologies to expose useful,
discrete components of the corporate IT infrastructure in a secure, reliable and
Combining Web service app integration points with a service-oriented
architecture provides the foundation for a Web service-oriented app integration
platform, which enables integration solutions to be deployed in an incremental
way. The Service Information Bus provides the universal circuit board for
collaborative distributed computing by extending the Web service communication
model from simple point-to-point message exchange to more complex many-to-many
exchanges where multiple providers and requesters participate transparently.
Web services provides the plugs for connecting service requesters and
providers to the bus, while the bus provides the intelligence for routing
service requests to the target providers. The bus provides the information
current and the ability to harmonize information and services across the
enterprise, creating logical circuits between requesters and providers. This
leads to the creation of a true web of services that supports the ability to
create aggregate apps.
This architecture integrates heterogeneous information sources and consumers
over a scalable and extensible infrastructure. The information current can be
extended to partners and other business units. Using Web services, B2B
Information Plugs are created that enable the bus to extend logical circuits to
partners, trading exchanges and marketplaces. EAI plugs extend the information
current to other business units, enabling standard cross-division integration
points. If these all speak Web services, it is plug and play.
The good news is that building this architecture does not require a
significant amount of effort and cost up front. For example, if your
organization uses the J2EE platform for app development, the solutions you are
building and deploying are easy to extend to Web services if they are
architected and designed properly. J2EE-based service providers and requesters
can be plugged into the service bus by creating adapters that ''Web servicize''
existing J2EE components. These adapters, which wrap the methods on the remote
interfaces of Session or Entity beans, can be created using either the Java Web
Services Development Kit or commercially available products. For the Service
Information Bus, combining a UDDI-based repository with a Java Messaging Service
Provider is all you need to get started. If your organization already has
investments in EAI technology, those products can be used as the foundation for
implementing the bus.
In my December 2001 article, I discussed how to integrate legacy assets into
an architected component-based framework. This approach is based on the
well-known Model-View-Controller pattern. It uses J2EE technology to enable
legacy assets to be re-factored into reusable components called eaiComponents.
Existing legacy data assets are re-faced as Entity Bean model components that
can be used in multiple transactions and business processes using controller
eaiComponents deployed as Session Beans. Session Bean view eaiComponents wrap
this functionality as a set of related business service methods, making it
simple to invoke an operation such as AddCustomer. Under the covers, the
framework of model and controller beans executes the supporting processes to
support the business service request.
This model's power is its simple extensibility to Web services. Wrapping the
View eaiComponents with Web services is straightforward, requiring the creation
of a simple adaptation layer. The Customer Management eaiComponent's three
service methods are provided as Web services to the bus via a Web service
adapter. Now the functionality represented by these three business services is
available to all requesters connected to the bus. Enterprise portals can also be
plugged into the bus, allowing the rich array of business services and functions
to be readily available to portal users. Web services become basically
'in-place' solutions, extending existing models with new and expanded
I envision Web services adoption occurring in four phases. We are currently
moving from a simple wrapped Web services model to the first generation of app
integration solutions. These second-generation solutions will evolve from
providing efficient access to services, to providing effective use of business
services within the enterprise and with partners and customers. The third
generation requires a service-oriented infrastructure that provides pervasive
service access. This universal availability of information, functionality and
services provides the foundation for fourth-generation solutions -- business
Web services gives us a cornerstone for B2B process integration by allowing
new and existing functionality to be plugged into the information circuit of the
service information bus, creating integrated business process circuits that
execute within the enterprise and to ''connected'' partners. Programming complex
business processes that span the enterprise and partner networks creates a
''process network'' enabling services to be integrated and new business
processes to be created using existing assets to ''connect the dots.''
A work in progress
Firms should not delay in adopting
Web services as an integral component of their IT toolkits. Despite the fact
that interfaces like UDDI are still maturing, and security is still a work in
progress, the foundation technologies of XML, SOAP and WSDL are mature and well
For firms looking for a way to take services and offerings to market quickly,
Web services is a great place to start because it can define and enable standard
access. For enterprises still confronted with an app integration problem and
paralyzed by the cost and fear of adopting ''heavy'' EAI platform solutions, Web
services provides a fast path by wrapping existing processing assets using
standard technologies. This will allow the infrastructure to grow on demand
while meeting the short-term business needs of the company. The attraction for
Web services is enabling organizations to make the transition from efficiency
gains in providing Web-based access to simple functionality, to business
effectiveness that enables organizations to create new business value through
the unique combination of their existing IT infrastructure and business
While Web services cannot end world hunger, I believe they provide the answer
to app integration's Holy Grail -- a non-intrusive integration solution that
uses standard and commodity technologies. The cost model, rapid time to market
and standards-based nature of the platform is a hard-to-beat combination.
Web services have promise and a bright future. Stay tuned -- we have only
begun this wild yet rewarding ride.