Be Nimble, But Be Safe

Indeed, most development environments that support Web services provide a mechanism by which developers can load the WSDL (Web Services Definition Language) file of an application providing a Web services interface and automatically generate a client interface, giving the developers more time to focus on adding the appropriate business logic.

The second driver is that Web services can ease business interactions by significantly reducing the time needed to implement and deploy B2B relationships. Assuming your supplier supports a Web services interface, your developer can download the WSDL, generate a client and write the business logic that will integrate the remote system into your business processes. We reviewed Web services platforms and their development environments (see "Serving Up SOAP," page 43) and were pleased to see that such automation is not a pipe dream.

The payoff behind Web services is business agility--the ability to respond quickly and cost-effectively to a changing economic environment. Today, for example, an enterprise may use the same component in any number of applications that perform a business task. If that task changes, it's necessary not only to change that specific component but to redeploy all applications that rely on the component. With Web services in play, however, you may only need to change a single component.Sounds great. But industry experts agree that security is a major source of angst. "Security is the primary and most immediate roadblock to Web services adoption today," says Ronald Schmelzer, senior analyst with ZapThink, a research firm focused on XML and Web services. "It's not simply because XML is text-based and sent over transparent protocols like HTTP. Common encryption technologies like SSL can solve that problem. The bigger problem is one of authentication and authorization."

This is the crux of the problem: WSDL provides a human-readable pointer into your internal business process and data structures--possibly exposing juicy field-level details such as credit card and authorization numbers and shipping addresses. With a single WSDL file, anyone can see what services you have available and, worse, how to access them. With such information readily available, it's imperative that services are invoked by authorized users only.

Consider, too, your B2B Web services. You don't want just anyone submitting purchase orders or invoices. You need to keep firm control over access and ensure you have a way to audit who has been making use of your Web services.While SSL is commonly accepted as the best way to keep prying eyes from your data during transport, it is not a panacea. SSL protects a transaction only while it is in transit. Unless you're taking advantage of client-side certificates to authenticate the consumer of a Web service, SSL is not going to provide the needed level of security.

Several standards attempt to address these security concerns, although some are still works in progress. WS-Security, XML-SIG and XML-Encryption are among the earliest such specifications. WS-Security (now under OASIS) introduces a set of SOAP (Simple Object Access Protocol) extensions that can be used to implement message-level security. WS-Security aims to define a framework for basic Web services security. It does not, in and of itself, comprise a complete security solution; designed simply to assist in building a secure system, WS-Security can be successful only when used in concert with other security products, such as X.509 certificates.

XML-Encryption defines a mechanism for securing the actual data being exchanged--down to the element level, if necessary. Using this standard, you can encrypt small, single data elements. And XML-SIG describes how individual elements or entire XML documents can be digitally signed to provide nonrepudiation.

Yet none of these standards addresses the real issue of securing individual services, because none prevents an unauthorized user from invoking a service. This type of security needs to be integrated at the code level or, ideally, managed by an external system designed to secure Web services at several levels. Appliances and software like those from DataPower, Reactivity and Westbridge Technologies offer a single point of entry to Web services in the enterprise. This approach provides a centralized point at which Web services can be secured via your existing security infrastructure. In addition, you'd have the capability of keeping detailed logs on the use of your Web services. While Web services platforms can provide the level of detail necessary, this generally involves modifying the underlying code.

Web services security breaks down into four distinct categories:• Secure Transport: Shields data from prying eyes

a) SSL--At the network level

b) XML-Encryption--at the data level

• Data Integrity: Ensures data is unchanged in transit

a) XML-Encryption--Encrypts data and uses checksum to ensure integrityb) XML-SIG--Signs elements or documents and provides nonrepudiation

• Authentication: Identification of client

a) WS-Security--Token-based identification

b) SSL--Client-side digital certificates

• Authorization: Determine client access to servicesWS-Security--Message-level access, tokens

The potential for disaster here is huge, including the possible violation of federal regulations in some organizations, so build your Web services infrastructure with security in mind from day one. You must also calculate quantifiable risks--not just security implications, but the uncertainty inherent in using a new technology dependent on nascent standards that may change during development. The good news on the standards front is that while there's still some infighting between the leading Web services vendors, SOAP and WSDL have been reasonably stable for a year, and though software vendors argue about the standards before they are defined, they appear willing to accept them once agreement has been reached. Web services will remain unified at the level of the core standards through 2004, according to Gartner. We agree, especially given that this prediction was offered at a time when Sun Microsystems' application to be a founding member of WS-I (Web Services Interoperability Organization) was up in the air.

Sun has since been accepted as a board member, and the outlook for the stability of the core standards is good. While there will always be some risk associated with the implementation of new standards, a complete diversion by one or more members of WS-I is unlikely in the foreseeable future.

Down to the Numbers

Say you're ready to pitch the idea of using Web services, but you need to justify the initiative via an ROI model. One readily apparent return is in lower costs over the development life cycle versus conventional software-development techniques. Unfortunately, this is a cost savings model; you won't bring in hard dollars, so this particular justification may be less than successful in convincing financial types to take advantage of Web services.However, implementing Web services also decreases the time it takes to deploy a B2B solution. Business agility can be as concrete as the ability to perform just-in-time switching to the lowest-cost supplies based on availability of a particular product component or as abstract as the ability to immediately react to changing market conditions.

There are a number of factors to consider in the ROI equation:

• Costs: hardware, software, training, bandwidth

• Business Payoffs: end-user productivity gain, participation in dynamic business, better and cheaper customer service, collaborative business activities

• IT Payoffs: software-development automation, streamlining of middleware, use of standards-based integration, reusability of codeA sample ROI model for Web services is: ROI= (Business Benefits + IT Benefits - Costs) / (Costs + quantifiable risks) * 100

Quantifiable risks are nebulous. One oft-used example is the fact that Web services standards have not been finalized and continue to evolve; the cost of potential redevelopment should be factored in as a quantifiable risk. Let's take a hypothetical situation: You want to use Web services for supply-chain management, specifically to order the parts you need to make your widgets based on availability and lowest per-part cost. Assuming your hardware and bandwidth are sufficient to handle Web services, you still need software. A reasonable estimate is $20,000 for the platform and developer seats and $30,000 for training.

If you've determined that Web services will increase developer productivity by 10 percent, and for each 1 percent productivity increase you save $25,000, the total benefit is $250,000.

You may be asking, "Why is bandwidth in that equation? I get the rest, but bandwidth?" The move to Web services means an increase in both the payload being exchanged and, most likely, the number of exchanges on a daily basis. A SOAP request and response is considerably larger than its HTML-form-based cousin (see "Fatter Payloads, Bigger Bulge" at right). You may need to increase your current bandwidth capacity to ensure timely receipt and delivery of Web services traffic.

If diving in isn't an option, you can phase in Web services. Start with isolated implementations, then move to developing the core services used throughout the organization, then slowly migrate critical applications to a Web services architecture that takes advantage of existing services. The best way to achieve a high ROI on these implementations is to do up-front work on common services across the organization and then build those services one by one until you can reimplement existing applications based on Web services.

The Endpoint

If you do take the plunge, do so cautiously, paying close attention to security and standards. The benefits, both short and long term, are tangible, and eventually you'll be forced to get on and ride whether you want to or not. Most software vendors, especially in the enterprise application market, are moving toward Web services and eventually will remove the ability of your developers to interface with these critical applications in any way other than Web services. Indeed, many software vendors are moving rapidly in that direction, having grasped the benefits of a service-oriented architecture that decreases the cost of their products in terms of support, both from an API and a customer viewpoint. But do not underestimate the dangers: Make sure your infrastructure is capable of supporting the bandwidth and security needs of Web services. Start with something noncritical and work through all the bugs before moving forward.

Ultimately, business process management/workflow standards such as WS-Choreography and WSFL (Web Services Flow Language) will help you turn your enterprise into a lean, mean automated business machine, capable of turning on a dime and turning that dime into a dollar.

For further product updates, ongoing insights and more information on Web services, please visit our ongoing Project Weblog at blog.networkcomputing.com/webserv.html. Our review of six Web services platforms can be found here.

Lori Macvittie, a Network Computing technology editor, has been a software developer, network administrator and member of the technical architecture team for a global transportation and logistics organization. Write to her at [email protected].Post a comment or question on this story.

The hype: Web services will revolutionize the way applications are built and deployed, both internally and externally, and will make customer and partner interactions seamless.

The reality: Web services hold much promise, and if you're not already on board, you will be eventually. But security fears are valid and must be addressed from the get-go. Competing standards implementations are also a concern.

In "Be Nimble, But Be Safe," we examine the key drivers of Web services adoption and tell you how to deal with standards and security worries. Easier application integration and smoother customer and partner interactions are strong incentives, but the ultimate reward is that SOAP can make your business processes as flexible as an Olympic gymnast.

In "Serving Up SOAP," we tested application servers and platforms from BEA Systems, Cape Clear Software, Iona Technologies, Novell, Sun Microsystems and Systinet that support enterprise, SOAP-based Web services. We looked for price, performance, standards--especially security standards--and interoperability (we tested each Web service against a .Net client, a Java client and a generic SOAP client using WSDL to access the service). Novell's Extend earned our Editor's Choice, thanks to its strong feature set and golden IDE. We also liked BEA's WebLogic, but its price and lack of support for security standards kept it in the silver-medal spot.In The Hitchhiker's Guide to the Galaxy, Douglas Adams says: "The Babel Fish is small, yellow, and simultaneously translates from one spoken language to another. When inserted into the ear, its nutrition processes convert sound waves into brain waves, neatly crossing the language divide between any species you should happen to meet whilst traveling in space."

Like the Babel Fish, Web services bridge the gap between development languages and disparate species ... er, platforms. Insert Web services into the "ear" of your application infrastructure, between the consumer of the service and the back-end system--the brain, if you will--that will ultimately process the request, in its own language of course, and you're in business.The evolution of the Babel Fish--and Web services--are no accident. The past two decades have seen many attempts to provide a mechanism through which business and applications can talk to one another without regard to platform or language, and without the distasteful side effect of requiring modifications to existing business processes.

CORBA and COM arose out of a need to provide enterprises with a way to exchange data between systems and with business partners that did not require a massive investment. EDI standards have been the traditional, and somewhat successful, mechanism through which businesses have exchanged data for everything from purchase orders to scheduling shipments to invoices.

And yet EDI isn't the solution we had hoped for. Standard formats across industries were a start, but the data formats weren't flexible enough to support every business, which resulted in additional code to translate from EDI to an internal representation and then back to EDI. And the expense of using value-added networks to transport and ensure message delivery pushed the price of entry too high for many small and midsize enterprises.

XML and the Internet were big evolutionary jumps. A self-defining format with an accepted, standard description language exchanged over an easily accessible, standardized network suddenly offered a better way to integrate businesses and applications. But even as XML became the de facto standard for exchanging data, the manner in which that data was sent and received varied greatly from business to business. Distribution channels could not count on being able to send an order to Business A in the same manner as Business B. As a result, the time and cost to implement such connectivity remained high.

Enter SOAP. Taking advantage of the flexibility and widespread acceptance of XML, SOAP provides a standardized transport mechanism for messages, and when combined with WSDL (Web Services Definition Language), offers a standard method of describing supported business services. (For more on how all this works, see "SOAPing Up Web Services".)SOAP requests (and responses) comprise much bigger payloads, primarily because they are XML. They contain not only the data, but a plethora of additional information, all necessary for the Web service receiving the request to process that request.

As you can see, even in this simple scenario, the payload for a SOAP request is much fatter than more conventional means of data submission. It isn't just the addition of the SOAP headers; it's the wrapper around each piece of data being submitted that makes the payload larger. For each parameter included in the submission, the payload grows. The size gets even larger if you specify the type of each parameter (for example, 2). At a minimum, you'll need to double the number of bytes being sent to account for the parameter wrapping. If an HTML form submission is 1 KB, you'll have at least 2 KB with SOAP, because every parameter name shows up twice--wrapping the actual data being submitted.Network administrators need to be aware that live requests and responses will likely be much larger and consume more resources.

top