Developing With Web ServicesDeveloping With Web Services

Investment banker Robertson Stephens Inc. has a classic problem. Various departments want to share data, but as in many large companies, each unit has its own IT staff, computer systems, and data formats. That makes sharing difficult and time-consuming. Typically, databases have to be replicated or custom hooks written to link applications. Not all departments use the same development tools or programming languages, which can complicate things when developing new programmatic interfaces.

Web-services technology, a set of emerging protocols and standards, offers a different approach to enterprise integration and development. Developers can build standard interfaces to existing and new systems using the Simple Object Access Protocol and describe how to access the data using the Web Services Description Language (WSDL). These let each department access data in other departmental databases without custom programming on an application-by-application basis. The re-use of Web services functionality cuts development time.

A developer only has to identify the departmental data to access and link to the corresponding WSDL interface, using existing development tools, says Dirck Hecking, a technical architect for E-commerce at Robertson Stephens. "This keeps services where they should be: in each department," he adds.

Web services are still quite new, and analysts expect that it will take at least another year before the standards and developer tools mature. Developers and IT architects creating Web services are faced with an incomplete set of standards, performance constraints, and an assortment of nascent developer tools. Still, the lure of a flexible system architecture based on de facto standards has many companies working on Web-services designs.

Today, developers have four core standards for Web services: Soap, WSDL, XML, and the Universal Discovery, Description, and Integration protocol. These comprise the basic capabilities necessary to build the discrete elements of a services-oriented architecture. Of the four, UDDI, a set of protocols and APIs used to discover where Web services are located, has been the slowest to evolve. Most sites developing Web services are working on internal systems in which UDDI's discovery role isn't critical. Some businesses are developing private UDDI registries that also can be used by their trusted partners, but UDDI will be most valuable on the public Internet.

When there are thousands of Web services available on the Internet, the ability to search for Web services on a global scale will become meaningful. Version 2 of the UDDI spec, released four months ago, added support for multiple languages, improved searching capabilities, and support for more complex hierarchal business organization descriptions.

For system architects working on internal systems, Web services offer design flexibility not possible before this. Architects have long advocated a services-oriented architecture in which applications are designed with modular, loosely coupled interfaces that hide the complexity of the underlying systems. The Web-services standards finally offer a way to design systems with modularity, flexibility, and platform independence.

The primary components in a services-oriented architecture are all services. A service is a collection of business or application logic that can be accessed via a messaging protocol such as Soap, which provides a standard way to decouple software components-useful when system changes or upgrades are needed. Soap also lets services collaborate with each other over a network.

Database access can become a Web service rather than a piece of program logic hard-coded into each database application because it can be accessed via Soap. The database client application needs to know only how to send and receive Soap messages and parse the XML-encoded data within each message. XML, a language for encoding data, plays multiple roles for Web services. It's used to define protocols such as Soap and WSDL, and to encode the data stream that applications use to communicate.

Because the database client developer needs to decode only the XML data stream and deal with Soap messages, all other aspects of the database deployment are hidden. The same database client can be modified to connect to other departmental databases by modifying the XML data stream and Soap message handlers. When all departments have deployed Web services front ends using Soap and WSDL, such modifications become relatively easy, compared with the old methods of developing application-specific interfaces for each department.

Further, this loosely coupled services architecture is resilient in the face of system changes. A department could switch from a Microsoft SQL Server database running on Windows 2000 Advanced Server to an Oracle database on Sun Microsystems' Solaris, and the database client would require few changes. From the database client's perspective, access to the database service would be an exchange of Soap messages.

It's been possible to build similar services-oriented architectures for some time, but because no universally agreed-upon standards have existed, accessing services required the involvement of many programmers. Microsoft's Distributed Component Object Model, the Java Remote Method Invocation, or even custom message-passing interfaces running over HTTP, have been used to decouple business logic, but none of these approaches offers a platform-independent, standardized method of accessing services.

TapX Ltd., a British developer of virtual banking technology, sees the private commerce between companies as a lucrative niche for Web services. The TapX application, due in the first quarter of next year, will be a hosted Web service that processes financial settlements between companies. It will handle invoicing and payments between companies, typically buyers and suppliers of goods. TapX's deployment of Web-services standards will let them quickly connect buyers and sellers who can build a compatible Soap client interface.

"Web services provide a common implementation, as opposed to possibly hundreds of custom-interface implementations that may have been necessary in the past," says John Magee, TapX's chief technology officer.

The benefits to TapX's customers will be faster payment processing and, possibly, more attractive payment terms. "TapX lets the buyer maintain or extend the payment terms of their contracts," Magee says. TapX uses IBM's WebSphere development platform with Sun's Java 2 Enterprise Edition programming model extensions and IBM's Message Queue Series Integrator. MQSI manages the flow of transaction data between participants using the virtual bank technology.

TapX is an example of a Web service residing outside the enterprise that developers can connect with to satisfy larger application needs, in the same way that some Web apps connect to third-party credit-card processing systems. TapX uses MQSI to handle transactions because Web services aren't yet suitable for handling the fault-tolerant needs of high-speed transactions. Future Web-services standards may address the needs of transaction systems.

Soap, UDDI, WSDL, and XML are the core standards needed to develop Web services. But development of a multitier, enterprise-class services architecture requires a programming language platform that includes a component object model, application-server technology, portability across various platforms, and well-defined APIs for things such as database access. Realistically, this means building services on top of either Sun's Java 2 Enterprise Edition or Microsoft's .Net object models.

Soap, UDDI, WSDL, and XML are platform-neutral standards, and thus Web services aren't tied to any specific aspects of either Java 2 Enterprise Edition or .Net. For the many companies that use both Java 2 Enterprise Edition and .Net in various departments, Web services will be able to tie these departments together without regard to the development platform they've chosen.

While both Java 2 Enterprise Edition, which is supported by many vendors, and .Net, a Microsoft-only approach, can be used as the basis for developing Web services, Microsoft has an early lead in the quality of developer tools offered for building Web services. Though analysts say that .Net isn't expected to mature for at least a year, developers are excited about the simplicity with which Web services can be created using Microsoft's latest beta of the Visual Studio .Net tools.

Visual Studio .Net makes it easy to wrap Web services around program logic, automatically generate corresponding WSDL, and map XML to the data stream. "It definitely makes development very simple, and that's the most important thing when you're introducing a new technology," says Graham Glass, chief architect at the Mind Electric, a Web-services infrastructure vendor. Mind Electric's latest product, Glue, which was released in August, is a Java framework for quickly developing Web services. Glass' goal was to bring the same simplicity that he sees in .Net to Java developers.

Products such as Glue can act as hubs for Web services, exposing Soap interfaces within the enterprise as well as outward to the public Internet. "We're calling it a Web-services platform," says Annrai O'Toole, chairman of Cape Clear Software, whose Cape Connect software is used by companies such as BT and Primordial Inc., a systems integrator in New York.

Interoperability among Web services is a critical measure of the concept's success. However, not all the standards necessary for serious deployment of Web services have been defined yet. Standards for authentication and connection management are still in the works. Both proprietary and standard methods exist for authentication and connection management, but to integrate into Web services in a platform-neutral manner, such standards should be XML-based.

If Sun and Microsoft don't deploy these new standards as they're defined or choose to deploy their own technology in their place, Web services built using Java 2 Enterprise Edition and .Net might not be able to interoperate.

Microsoft, in particular, has been leaning toward using its proprietary Passport authentication system for its .Net program. Meanwhile, the Oasis standards group is readying Security Assertion Markup Language, an XML-based standard that will likely become the Web services' authentication mechanism when it's ready, which is expected by year's end. Microsoft's acceptance of the standard will likely be one of many benchmarks that will reveal how much it's committed to deploying interoperable Web services. "I would fault Microsoft for not adopting SAML," says Randy Heffner, an analyst at Giga Information Group.

Performance also will be an issue as Web services are widely deployed. XML parsing typically is used to decode the flow of data to a Web service, but XML parsing can be slow when large amounts of data are involved. "We're advising people to be cautious," Giga's Heffner says. Developers need to be judicious when deploying Web services if their application requires fast and predictable response times, Heffner says. The XML parsing required by Web services can slow down the speed of data delivery. Hosted services such as those offered by Atesto Technologies Inc. and products such as Empirix Inc.'s FirstAct are some of the new tools available to test the performance and scalability of Web services.

Enterprise architects have tough choices to make and a lot of work ahead to get Web services into their system designs. While the vision of thousands of available services on the public Internet is compelling, businesses developing Web services today are more concerned with their internal systems and trusted partners. Future standards for Web services will make public Internet access a more- viable option for Web services as well.