Look before you leap: The challenges of implementing web services for
integration projects
Introduction
"Web services" is a big buzzword in the IT industry
today.Much research (and speculation)
has been published indicating the potential of Web services, feeding the
marketing hype machine.Unfortunately,
precious little knowledge has been made available with respect to the
practicalities of actually implementing Web services.
The most common use of Web services today seems to be as a
tool for enterprise integration.The
integration of enterprise applications, methods, and processes is a critical
factor in the survival and continued growth and success of major
corporations.A number of extant tools
for such integration are available: Common Object Request Broker Architecture
(CORBA), Electronic Data Interface (EDI), etc. While none are perfect, they have had time to mature and we know what
their respective strengths and weaknesses are. One must therefore carefully consider the risks in using a new
technology like Web services.
This document will consolidate the literature available on
practical implementation challenges surrounding Web services, especially with
respect to integration projects.It
also describes the lessons learned directly from a project manager at a Fortune
500 corporation who is in the midst of a project to integrate legacy
applications using Web services. Specifically, this document will look at the following four challenges:
making the business case, interoperability, evolving standards, and security.
What are Web services?
There are a lot of answers to the deceptively simple
question, "What are Web services?"The
official answer from the World Wide Web Consortium (W3C) is this:
"A Web service is a software system identified by a URI [RFC 2396],
whose public interfaces and bindings are defined and described using XML. Its
definition can be discovered by other software systems. These systems may then
interact with the Web service in a manner prescribed by its definition, using
XML based messages conveyed by Internet protocols" [1]
The W3C’s definition can be broken down in this manner:
- A Web
service is computer program.This
program is accessed via the World Wide Web (WWW). It has a URL just like a page on the
WWW.
- The
"interfaces" and "bindings" of this program represent the functionality
the program provides.A description
of the functionality and instructions on how to use it are provided via an
Extensible Markup Language (XML) document.
- These
descriptions/instructions are made accessible in public directories,
allowing users to search for and find a Web service that provides some
functionality the user is interested in.
- In
order to take advantage of the functionality, the user interacts with the
Web service by sending XML messages back and forth over the internet
(usually by way of Hypertext Transport Protocol (HTTP), the protocol of
the Web).
What role do Web services play in enterprise
integration?
In practice, Web services are a means for enterprises to
integrate on a number of levels.Web
services can integrate legacy applications within the enterprise, and they can
integrate with customer, supplier, and partner systems outside the
enterprise.Most Web services projects
today appear to concentrate on internal integration.[2]
Web services dovetail nicely with existing Enterprise
Application Integration (EAI) features. There’s a registry with protocols for introspection in both Web services
and EAI.There’s also the common bond
of the service connection over the Transport Control Protocol/Internet Protocol
(TCP/IP).However, according to David
Plesko and J. Michael Lee of Accenture, "Remember, companies that have old
legacy systems must integrate in order to renovate business processes. This is a vital [sic] function. EAI does this today. Web services do not."[3]
Danish Bank would appear to disagree with Messrs. Plesko and
Lee.According to an article in
Computerworld, that organization successfully uses Web services to integrate
legacy systems.As of early 2003, the
bank had 200 services exposed and had planned on exposing 500 more before the
end of the year.The Danish Bank case
provides a lot of encouragement for the use of Web services as an enterprise
integration tool.70% of their
applications are written in COBOL, 20% in Visual Basic, and 10% in Java. That certainly presents an integration
challenge of impressive scale.
For Danish Bank, Web services allowed developers to expose
the functionality of the legacy applications to Visual Basic and Java
applications without the VB and Java developers having to learn the first thing
about COBOL.The described interface of
a Web service is the perfect solution for their situation. One example of a practical application built
through this integration was a portal used by over 7000 users. It presents a unified interface that
prevents the user from having to access a number of disparate systems in order
to obtain the data they need.[4]
Who can we learn from?
Web services is an immature technology, but clearly has
promise to become a major tool in the integration of enterprise applications
and processes.As with all
technologies, there are early adopters who are on the cutting edge of the
technology.They may reap the rewards
of moving first or they pay the price for misjudging Web services. In either case, others can certainly learn
from their experiences.
Danish Bank, as previously discussed, is an example of an
enterprise "blazing the Web services trail." According to one expert, their 200 exposed services and 500 planned puts
them in the top 1% of all enterprises implementing Web services.[4]
The author of this document had the opportunity to interview
a manager working atanother leader in
Web services implementation.The
company, a transportation and logistics giant in the United States, asked to
remain anonymous.They are embarking on
a major project to use Web services to integrate a number of legacy
applications in the invoice processing and inventory management areas. The manager of that project was kind enough
to share his insights on the practical challenges that his organization has
faced in implementing Web services. This document will refer to this anonymous company by the fictional name
"Express Delivery" and the manager by the fictional name "Bob Philips".[5]
There are a large number of companies in the IT industry
that are actively involved not just in implementing Web services, but also in
defining the standards that make up the Web services paradigm. Examples include leaders like Microsoft,
Oracle, Sun Microsystems, and IBM. There are countless smaller players also participating in these
discussions.For the most part, these
large and small companies belong to consortiums that present recommendations to
two standards bodies, Organization for the Advancement of Structured
Information Standards (OASIS) and W3C.
Another source of knowledge in this arena is the consulting
industry.Groups like Accenture and the
Sand Hill Group have done a lot of work with Web services. They have helped clients implement Web services
and they have surveyed the industry for trends in this new frontier.[1,2]
Analysis
While it is easy to see the promise of Web services and get
caught up in the marketing frenzy surrounding them today, one must remember
that this is a new technology.As such,
there are a number of potential pitfalls when it comes to implementing Web
services in an enterprise integration project. These pitfalls are not just relegated to the technical side of the
enterprise, either.Before dealing with
interoperability issues, constantly evolving standards, and securing Web
services, one must first make the business case. None of these challenges is a trivial matter.
Making the business case
Before the first line of code can be written, even before
planning can begin in earnest, a Web services project must generally start with
a business case.As Thomas Hoffman
points out, justifying the costs of potential Web services projects to senior
management is becoming difficult.One
main reason for this is that project managers are finding it difficult to
quantify the payback for such projects. It’s difficult to measure the benefits of an internal integration Web
services project – especially as opposed to a project that interfaces with
customers or suppliers and directly impacts the bottom line. Compounding these difficulties is the fact
that there are few if any best practices for Web services projects. All of this makes predicting return on
investment (ROI) a daunting task.
Once an ROI is established, it will likely be a hard
sell.Senior management may often be
"gun-shy" about too-good-to-be-true ROI estimates. In the past, with over-hyped projects surrounding tools like
CASE, the internet, ERP, etc., such ROI was, in fact, too good to be true. Far too many of these projects failed to
deliver as promised.Managers may see
Web services as another potential failure; such a viewpoint is only prudent.[6]
A possible solution to this challenge is to start your foray
into Web services with small, tightly scoped projects that aim to take the
least amount of risk (investment) and will likely produce a large positive
result.This is the tack employed by
Bob Philips at Express Delivery.He
describes his project as a, "low risk/expense introduction while creating the
biggest positive impact possible."His
plan is to slowly introduce valuable services, gaining client satisfaction and
approval, fueling further development. The project is currently in the
implementation phase, so the actual results of this strategy have yet to be
seen.[5]
Hoffman describes a similar strategy, starting with small
pilot projects that require little investment but can prove ROI. A particular approach he suggests is to
target an area of larger past investment that has not performed according to
expectations, like a large ERP project. If a project can be created to integrate with ERP and enhance the return
of that large investment, the project is likely to be seen as a success.[6]
Such a strategy is exactly what the Sand Hill Group sees
being done by the most successful implementers of Web services. Their research indicates that the most
successful projects will integrate data that is widely used, dynamic, and
currently inaccessible to those who need it. The research suggests that a great way to get a foothold in Web services
is to add Web services to an existing integration project rather than tackling
an entire project from the ground up.
An interesting point in the Sand Hill Group research is
that, in the real world, returns on investment in Web services don’t come with
the first or second project.True
returns are observed with successive iterations as the corporation is able to
reuse and leverage the resulting interfaces. As more applications have services exposed and interfaces are reused,
benefits accumulate.This finding
indicates that small tactical efforts tend to produce results faster than
larger strategic efforts.[2]
Interoperability
The importance of interoperability in Web services (or any
integration technology) is illustrated quite well by an analogy drawn by Lori
MacVittie.She points out that when you
plug a 3Com switch into a Cisco router, you don’t create a months-long project
with a magnificent budget and a team of super-consultants to make sure the
integration happens smoothly.You just
plug in the cable and trust the vendors to have handled the interface such that
packets flow without incident from one device to another.[7] Unfortunately, such trust would be baseless
in the integration software scene.
Where this analogy breaks down is that Ethernet devices
handle interoperability at the network and transport layers. What is important in terms of Web services
is interoperability at the application layer. To achieve this, vendors must work together to implement Web
services specifications according to a unified vision. It is insufficient that the vendors simply
implement the specifications to the letter; there is a spirit of the
specifications that must be adhered to for interoperability to succeed.
The frightening thing for the integration project manager is
that signs of friction between vendors is already apparent. While vendors are all implementing the same
standards, there is a political rift between many of the major players. The most prominent example is the Web
Service Interoperability Organization, a consortium of software and hardware
companies whose goal is to insure the interoperability of Web services. Who is missing from this important
consortium?None other than Sun
Microsystems!Sun has been invited to
join, but refuses to unless it is given "board level" status within the
organization.[6]
Colloquial wisdom states that, "those who do not study
history are doomed to repeat it."In
the context of such a proverb, Web services would do well to learn from the
lessons of Open Systems Interconnect (OSI) history. This set of international standards was aimed at the same
application integration goals as Web services. OSI failed miserably to find widespread implementation in enterprise
integration.The reason: OSI vendors
implemented the standards in differing ways. This resulted in an unusable conglomeration of proprietary products.[8]
It appears that the only solution to this interoperability
pitfall is for enterprise customers to demand in their vendor contracts
specific interoperability capabilities.[6,7 Unless vendors have a financial stake in working
together towards a unified implementation of Web services standards, the
ability of enterprises to switch from one solution to another will be in
jeopardy.[9]
Evolving standards and specifications
While vendors must work together to produce implementations
that follow both the spirit and the letter of Web services standards and
specifications, those standards and specifications must first exist in a stable
form.Integrating enterprise systems
with Web services is particularly difficult because the very standards that
define Web services are immature and continue to evolve.
Even Microsoft, one of the biggest proponents of Web
services through it’s .Net initiative, admits that XML specifications are not
yet nailed down.They point out that
developers have to "roll their own" implementation of specifications or wait
for vendors to catch up and deliver solutions.
In areas where standards exist, there are often choices to
be made by the vendors.Will Web
services be written with XSLT or XML Query? How will messages be implemented – in an object-centric means like SOAP
or in an XML-centric means like Schema? One article points out that "the rift is so deep that Microsoft’s .Net
Web services framework includes two separate XML serialization engines."[10]
Along a similar line, Bob Philips points out that even
intra-corporate standards can present a moving target. In his project, he’s not only having to deal
with vendors who implement XML, but also work with "legacy standards of a major
corporation."Because his company is
taking steps to standardize its internal architecture, bringing in solutions
that represent new technologies takes extra time and effort because of the need
to satisfy corporate standards bodies.[5]
It is in fact a major concern among IT developers and
managers that Web services will be difficult to use for integration projects
because of the immature and sometimes overlapping standards.[9]It
has been suggested that companies must not only believe that vendors are going
to implement standards, but that vendors are going to embrace standards.[2] A
senior executive with LexisNexis, as quoted by Carol Sliwa, says, "My nightmare
would be a standards arms race.That’s
what the world does not need."[9]
Securing Web services
One of the areas in which standards or proposed standards
overlap the most is in arguably the most important area of Web services:
security.Security of Web services is
especially important in integration projects, because such projects bring
together information and functionality previously available only in disparate
systems to unique audiences.Care must
be taken to prevent an unintentional breach of security. The temptation is to focus all efforts on
the goal of integrating the data, methods, or process of an enterprise.
There is significant confusion in industry surrounding Web
services security.The senior executive
at LexisNexis states, "We don’t yet see a clear story of what the security
problems are, the framework for how the security will be provided, and how the
individual efforts fit together."[9]
To provide an idea of the confusion that exists with regards
to Web services security, here is a partial list of security-related
standards that could have some impact on Web services (list and definitions
quoted directly from Carol Sliwa):
- SAML (Security Assertion Markup Language): An XML-based
standard for exchanging authentication and authorization information.
- WS-Security (Web Services Security): A proposed standard that
aims to unify multiple security models and technologies and serve as the
technical foundation for Web services.
- XML Signature: XML syntax and processing rules for creating and
representing digital signatures.
- XML Encryption: A process for encrypting and decrypting digital
content (including XML documents and portions of them) and an XML syntax
used to represent the encrypted content and the information that enables
an intended recipient to decrypt it.
- XACML (Extensible Access Control Markup Language): An XML
specification for expressing policies for information access over the
Internet.
- XRML (Extensible Rights Markup Language): Provides a universal
method for securely specifying and managing rights and conditions
associated with resources such as digital content and services.
- XKMS (XML Key Management Specification): Simplifies the usage,
distribution and management of the keys necessary to create a trust
infrastructure.[9]
Of the major Web services security standards, WS-Security is
probably the most prominent.However,
it is not a single specification; rather, it is a suite of standards, some
developed, some yet to be developed, that portend to specify a very wide range
of Web services security.The
catch?This "standard" has yet to see
the scrutiny of a standards body.The
consortium led by Microsoft and IBM that develops WS-Security says it expects
the specifications to go before OASIS sometime in 2003. Major vendors like Novell and Oracle are
holding off on security implementations because WS-Security isn’t standard yet
and competing standards like Project Liberty just aren’t fully developed.[11]
In the meantime, corporations implementing their Web
services integration projects are left to design security solutions
themselves.Bob Philips’ project uses a
single signon solution that attempts to eliminate authentication from
individual applications.He says that
this solution ties tightly with the enterprise authentication directory as the
primary authentication element.There
is also another element of authentication available through services developed
in accordance with Express Delivery’s mainframe personnel system. For the time being, this type of custom
design is the only way to ensure the security of Web services.[5]
Trends and Conclusions
What is clear is that while Web services certainly offer
some unique opportunities, especially in the area of enterprise integration,
there are significant practical hurdles that must be cleared if a company
intends to implement Web services.
Top challenges
Budget constraints, tight project deadlines, finding and
retaining talented project team members, and technical issues are challenges
that affect virtually any software project.[5] Web services integration projects are not
immune to these challenges.But, the
real roadblocks to a successful "go-live" appear to be the following:
- Making
the business case.Web services
are uncharted territory, so it’s difficult to find benchmarks for
estimating expected returns on internal integration projects. These projects rarely directly affect
the bottom line, making estimation even more difficult. Executives have also been burned by
overly optimistic expectations with past projects like CASE, ERP,
internet, etc., so selling these executives on the benefits of Web
services will not be easy.
- Achieving
interoperability.Until vendors
come together to create implementations that embrace the spirit of the
specifications, Web services is in danger of repeating the history of
OSI.Lack of interoperability
locks an enterprise into a single Web services solution and robs integration
projects of many of their advantages.
- Evolving
standards.The simple fact is that
the standards and specifications that define Web services are
immature.They do, and will
continue to, evolve rapidly. Hitting such a moving target is a difficult task for both vendors
and project managers trying to use these standards to achieve integration
among enterprise applications or processes.
- Security
for Web services.Standards for
Web services security just don’t exist yet. There are proposed solutions available, and organizations
may find ways to integrate Web services security with existing enterprise
security.But, because the
standards are still under development, we can expect the shape of these
solutions to change over time, creating a maintenance and possibly a
security problem.
To leap or not to leap…
The choice on whether or not to use Web services as a
component in an organization’s enterprise integration strategy can only be made
on a case-by-case basis.There are real
potential benefits to using Web services in such a strategy. Companies like Danish Bank prove that
success is at least attainable. Companies like Express Delivery, though, show that the active implementation
of Web services projects will not be easy. Project managers daring enough to tackle this task will face a series of
daunting problems to solve.In today’s
environment, embarking on a Web services project is analogous to taking a "leap
of faith.""Faith" is defined as a
belief in things not seen.The question
of whether to leap or not to leap into Web services depends on your amount of
faith: faith in the benefits of Web services and faith in an enterprise’s
ability to surmount the challenges discussed here. It truly is faith, because for most organizations, these benefits
and abilities are things not yet seen in practice.
Bibliography
[1] Brown, Allen and
Hugo Hoss, ed.: "Web Services Glossary," http://www.w3.org/TR/2003/WD-ws-gloss-20030514/#Webservice;
May 14, 2003.
[2] Nukala, Murthy
and M.R. Rangaswami: "Getting Your Arms Around Web Services," Optimize,
Manhasset; March, 2003.
[3] Plesko, David
and J. Michael Lee: "Web Services and Enterprise Integration: Friends, not
Foes," eBizQ, http://e-serv.ebizq.net/wbs/pleskolee_1.html;
May 5, 2003.
[4] Sliwa, Carol:
"Danish Bank Blazes Web Services Trail," Computerworld, Framingham;
February 17, 2003.
[5] Eckles, Jay:
Interview with IT project manager at large U.S. transportation and logistics
company (manager requested that he and the company remain anonymous). Interview held May 30, 2003.
[6] Hoffman,
Thomas: "Web Services ROI Remains Tough to Prove," Computerworld,
Framingham; October 28, 2002.
[7] MacVittie,
Lori: "Interoperability Revelation," Network Computing, Manhassett;
January 23, 2003.
[8] Wilson, Tim:
"Web Services Must Not Repeat OSI’s History," Internet Week, Manhassett;
November 19, 2001.
[9] Sliwa, Carol:
"Users Cast Wary Eye At Web Services," Computerworld, Framingham;
September 2, 2002.
[10] Box, Don:
"The Continuing Challenges of XML Web Services," MSDN Magazine, http://msdn.microsoft.com/msdnmag/issues/02/02/WebServ/default.aspx;
February, 2002.
[11] Piven,
Joshua: "Consortium batches first WS-Security Specs," Computer Technology
Review, February, 2003.
If you have any questions or would like to contact me for any reason, please email me at j.eckles@computer.org.
|
