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.
What does this mean in terms of your decision to implement Web services, and how extensively should you deploy them? Once you understand the pros and cons of the technology, it's time to apply that knowledge to the specific applications where it might benefit your organization. In other words, you're ready to do your due diligence on the following topics:
>> Anticipated use
What are the specific business or IT drivers behind your Web services effort? Will you allow external users to access your information or functionality through Web services, or will your users all be internal to your organization? Will you use Web services as a general-purpose integration strategy? As an integration foundation for a SOA? Your answers to these questions will lead to very different business cases.
>> Scope of deploymentAre you considering doing a Web services pilot project, or has your company made a larger commitment to Web services technology? Obviously, the larger the commitment and the more extensive the expected uses, the greater the risk.
>> Technical alternatives
Consider all of the possible alternatives. Newer Web services approaches are emerging, such as RESTful services, and other integration approaches are available as well, including Corba, DCON, Java RMI, various APIs, and some non-Web service-specific options based on an enterprise service bus.>> Reuse of standardized Web services definitions or XML schemas
Does your industry or company have standardized XML schemas that allow for interoperability of information or functionality? List these and use them to the greatest extent they will meet your needs. In the absence of standards, or when existing standards don't meet all your needs, what's the complexity of the semantic content required for your integration? Make sure that XML has sufficient expressive power for your information content.
>> Retrofitting
Adapting legacy systems is often the bane of IT, especially when it comes to new interfaces not intended by a system's original designers. Understand at the outset the number and complexity of these interfaces, and consider whether simple wrappers or service facades will suffice, or whether you'll need complex conversions or new functionality.
>> Managing system interactions
Controlling system interactions at design time, runtime, and change time--this is the classic integration governance issue, and it can cause no end of trouble once you have several Web services in production. If you plan to deploy Web services technologies for service-oriented architecture or general-purpose integration, it's critical to determine up front how you will provide governance across your systems.
>> Availability of interfaces
If your initiative involves Web services interfaces to vendor-provided or commercial off-the-shelf software, you'll need to know whether Web services-compliant interfaces are available, what features or functionality are exposed via those interfaces, and at what cost to your business. If these interfaces are not available, you may need to overlay Web services interfaces the same way you would for legacy systems.
>> Future changes
As systems integration becomes better understood, and as relevant standards and tools mature, Web services technologies will evolve. Don't make the mistake of thinking the best technologies available today will be adequate or appropriate for your business down the road. It's imperative that the systems we build today, and the organizations we lead, be positioned to adapt to these changes and take advantage of improvements still to come.
Bottom line, flexibility is the name of the game, and it will remain so for the foreseeable future. Web services are intended to improve your company's ability to adapt quickly to market changes and meet customer demand. Keep that in mind as you make your deployment decisions.
Get This And
All Our ReportsBecome an InformationWeek Analytics subscriber: $99 per person per month, multiseat discounts available.
Subscribe and get our full report on Web services at informationweek.com/analytics/webservices
This report includes 17 pages of insights and action-oriented analysis, including:
> In-depth discussion and graphics illuminating the various approaches to Web services
> An overview of WS-* standards
> A side-by-side comparison of WS-* vs. REST
Steve Laufmann is the principal at Firefly Strategic Solutions, a consulting firm focusing on enterprise-level architecture and business-IT transformation. Write to us at [email protected]
