Yes, there are compelling reasons to implement Web services--from standardizing basic content integration to supporting complex service-oriented architectures. But before you dive into any Web services deployment, it's essential to understand precisely what the technology can--and can't--do. That will help determine how likely your investment is to advance the goals of your IT organization and the business overall. Web services offer tremendous opportunity for company growth and flexibility, but the technology does have limitations.
The simplest and lowest-risk approach to a Web services implementation is to use their original Web context as mechanized interfaces-- application-to-application--to content on a Web server. It's effective, though it provides minimal business benefits because it applies these technologies only at the edge of the application space, mainly for business-to-business or business-to-consumer integration.
A more extensive yet still moderate option for many companies is to use Web services for general-purpose systems integration. Referred to as "Just a Bunch of Web Services" (JBOWS), this approach uses Web services technologies but is independent of any particular architectural style--for example, the JBOWS approach is distinguished from SOAs that use Web services as part of the integration layer. This means a bigger commitment in exchange for greater flexibility.
The most complex approach, but the one that provides the greatest potential reward, is the use of Web services as the integration layer for a true service-oriented architecture. With a SOA, the toolsets extend Web services technologies to address more complex integration issues, such as orchestration, registries, testing, reuse, and runtime management. By making Web services the foundation of a SOA, you stand to reap tremendous business benefits over time.
Pros And Cons
There's a slew of positive factors to suggest that some use of Web services would be beneficial to almost any company. Web services technology tends to work well across and through security firewalls, for instance, so it's effective for both business-to-business and business-to-consumer transactions. And it's standards-based--in fact, the recent proliferation of WS-* standards extends Web services standardization into the more complex facets of integration, including WS-Addressing, WS-Transaction, WS-Security, and WS-Policy. These offer powerful extensions to basic Web services technologies and enormous potential to further reduce the costs associated with integration (see table below).
On the negative side, however, Web services' reliance on XML can translate into high overhead in the form of oversized, sluggish messages. This can mean an investment in XML appliances or other software to optimize validation, parsing, and analysis of XML messages. Ka-ching! And because Web services operate autonomously, with no centralized control, users may find them unpredictable, necessitating IT to provide service guarantees or service-level agreements.
To read the rest of the article, download a free PDF