In-Depth

Answering the critical Web services questions

• By Peter Fischer
• July 1, 2002

The IT industry is currently swept up in the latest buzzword -- Web services. The hoopla accompanying the emergence of this new technology darling has vendors scrambling to bring supporting products to market.

But it is time to move past the hype and uncover the truth about Web services. My goal is to set the record straight and answer three critical questions about Web services: What are Web services? Why are they important? And how can they help solve IT problems?

Armed with these answers you will be prepared to go into battle with Web services as a part of your IT solutions toolkit. And you will understand how Web services are enabling two important trends: enterprise portals and app integration.

Web services are evolutionary; they represent a progression of existing distributed computing models. And they are revolutionary; they will fundamentally change the way we build and deploy applications over a global network.

Web services' capabilities and features are not new. The idea of providing distributed software services has been around for more than a decade. Technologies like RPC, DCOM and CORBA were built from a client/server foundation focused on creating a standard technology platform on which to accomplish ''true'' app-to-app communication by providing access to remote methods. Messaging then came along and freed us from the shackles of synchronous communication, enabling point-to-point and Publish/Subscribe communication models utilizing messages as the ''exchange currency.''

Web services build on these technologies and simplify the development and deployment of distributed app systems. They do this by combining a standards-based approach to distributed computing with the availability and accessibility of the Internet. HTML and HTTP were two catalysts of the first Web revolution, providing standard technologies for creating webs of human-accessible content. But while HTML and HTTP opened up a web of related information, they did not simplify access to business systems and services. The missing ingredient was the ability to share processes and data across a global network: the Internet.

A Web services platform provides the foundation for the next generation of distributed computing, enabling the creation of a web of collaborative services that are machine-accessible and peer-to-peer in nature. Web services' value is that it enables pervasive machine-to-machine computing over the Internet. It is this platform of technologies that will enable us to achieve the true benefits of distributed computing that have historically eluded us.

The ticket to Web services' success is that it is based on fundamental standard technologies that everyone agrees on, including companies like IBM, BEA Systems and Microsoft. Using these standards, Web services provide ''between-the-boxes'' communication capability by specifying the semantics of information via standard message exchange technology protocols, as well as the format of these messages.

Web services will change the way we architect, build and deploy the next generation of distributed apps. This new breed of ''aggregate apps'' is built from a set of loosely coupled components with Web services providing the foundation ''glue,'' and loosely coupled connections to make these components interoperable.

The technologies that work together to provide this ubiquitous standard connectivity are XML, SOAP, WSDL and UDDI. These technologies work together to provide a Web services model with important functionality: a loosely coupled model for exchanging information; a standard format for packaging and sending data over the wire; the ability to make interface definitions available; the ability to locate and register interest in a service; and the ability to describe the capabilities of a service and information about how to access a service.

The Web services technology stack is penetrated through the use and leverage of XML. XML provides the lingua franca of Web services; every other Web services technology eats and breathes XML. I use the term ''informational middleware'' to describe XML's power, applicability and potential. Web services finally realize XML's promise by providing the standard format for specifying both application interfaces and application messages.

SOAP defines an XML-based message protocol that provides a standard way of passing XML-encoded data and remotely accessing services and objects in a platform-independent way. SOAP messages are packaged into HTTP messages, enabling message and method invocation over the Internet using existing communication technologies. And SOAP is firewall-friendly; it does not require changes to existing corporate Internet firewalls.

A SOAP message is wrapped within an HTTP message and consists of a mandatory SOAP envelope, an optional SOAP header and a mandatory SOAP body defined as an XML document. The HTTP header contains the traditional HTTP request and response information and wraps the SOAP machinery. It specifies the action of the SOAP message with the SOAPAction parameter, which typically indicates the target destination address as a URL for the message.

The technical end of the SOAP message is the SOAP envelope, which defines the framework for describing the contents and processing of the message. It can specify a set of encoding rules for serializing app-defined data over the wire. Both the provider and requester must agree on this ''language,'' usually by referring to the same schema that defines them. The envelope and the encoding rules are defined using different XML namespaces.

The optional SOAP header contains service- and request-specific information, and is the ''extensibility'' point for the SOAP message. It provides the mechanism for extending SOAP in place to include additional capabilities such as security, transactions and quality-of-service features for the request.

The business end of the SOAP message is the SOAP body, which contains the app-defined data being exchanged. The data is specified using XML and can be expressed as a single self-describing structure or as an RPC-style interface that includes method name and typed parameters. The latter is remote method invocation that uses XML to describe the complete request.

The SOAP communication model exchanges messages between a requester and a provider. To invoke a remote method, the requester sends a SOAP request message to the provider indicating the action to be performed and passing the required parameters in the SOAP body. The provider replies by sending a response message with the requested data in the SOAP body. If an error occurs, a detailed error message is sent back to the requester describing the fault.

SOAP's power is its simplicity. The specification is aimed at specifying a basic mechanism for routing a request to its target by providing the required information to enable the invocation. Those who criticize SOAP as slow and see it as a performance bottleneck in app-to-app communication are missing the point, and are overlooking SOAP's value and merit.

One cannot deny that CORBA and DCOM have better performance by the numbers. After all, DCOM and IIOP provide ''on-the-wire'' interoperability and perform better because they are not required to propagate any meta-information between partners. This comes from their connection-oriented nature; components participating in an exchange have a persistent and transactional connection between them.

The connectionless nature of the Internet and its supporting technologies do not provide this capability. To enable effective communication over the Internet, SOAP provides an ''over-the-wire'' protocol that specifies a standard way to package requests based on XML that can be sent wrapped in HTML over commodity connectivity technologies like HTTP.

SOAP provides leverage in helping us overcome the challenges of component model and platform integration. The IT industry has been playing the component and platform integration game for a while, and my article, ''Renew, don't rewrite, legacy systems'' in ADT's December 2001 issue detailed some recent advances in the field. However, these solutions still fall short and it is still not easy to get CORBA objects to interoperate effectively with DCOM objects. SOAP provides the answer to this dilemma with its ability to express methods and parameters as XML -- SOAP provides the basis for component model integration without bridges.

SOAP ''cleans up'' the interoperability issues and challenges that have plagued business-to-business and app-to-app initiatives by providing the universal messaging currency. In the case of Web services, when you think of SOAP, think of pervasive and large-scale interoperability and not performance. After all, when you use the Internet as a communication medium, all bets are off on predicting performance. SOAP also provides the messaging to support the other two key Web services technologies, WSDL and UDDI.

WSDL provides the ''datasheet'' for Web services, but instead of rendering the information in .pdf, it renders it in XML. WSDL provides the complete interface for a Web service and is the IDL for a Web service. The XML grammar for WSDL is rich and provides everything a service requester needs to know to bind to a Web service and utilize its methods, including:

* A definition of the message format the Web service accepts and sends using the and elements, as well as appropriate schema definitions;

* The methods of the service using ;

* The semantics of the service that define how the methods of a service are called, such as synchronous request/reply, asynchronous and so on;

* The end point and transport of the service using the element; and

* The specific protocol used to bind to the service, including HTTP, HTTPS and JMS. WSDL provides both static and dynamic binding. Static binding uses a development tool to generate code to invoke the methods on a Web service. Dynamic binding is provided via the automatic creation of the appropriate access code at runtime. This 'tooling' makes it easier to write code that accesses Web services. WSDL must be located in a public repository to allow service requesters to look up binding information for Web service providers.

UDDI provides a standard interface to WSDL repositories and defines several lookup services that allow requesters to locate and retrieve the WSDL for Web service providers. A UDDI repository is a broker of information about the Web services that have been registered with it, and is similar to a CORBA interface repository.

UDDI provides three ways to look up a Web service: white pages, which locates a Web service by name; yellow pages, which locates a Web service by type of offering or topic; and green pages, which locates a Web service by its characteristics.

Adopting and applying Web services to real solutions
Web services can revolutionize the way we build and deploy B2B and B2C functionality. Pulling these technologies together provides the foundation for an extensible and flexible computing platform that provides access to small granular services and opens the door for large-scale services access and app integration.

We are currently in the early adopter phase, and many firms are trying to fight the hype and use Web services to deploy simple service-based functionality over the Internet. Much of this hype is about deploying simple Web services front ends over isolated code and functionality, making it available to the ''masses.'' Some examples are the credit card authorization, shipment tracking, currency conversion and simple calculation Web services that can be invoked from ''Web services sites.'' While providing functionality such as credit card authorization via a Web service is valuable, this adoption of Web services ''in the small'' only offers an incremental benefit over existing mechanisms.

Web services' true value will emerge when business functions and services are wrapped and made available on demand to a larger audience, including business partners and corporate users. The second generation of Web services implementations will be focused on wrapping business assets to provide the foundation for the adoption of Web services ''in the large.''

Web-based access to integrated information has been the focus of app portals. Current portal solutions provide simple, customizable content integration within HTML, offering single-point access to key and related information both within an enterprise and between an organization and its customers. However valuable these portals are for providing one-stop shopping for information content, the true value of a portal as a ''view'' into an organization's business environment will not be realized until it is integrated with business IT assets, including corporate business functions, services and processes. The next generation of portals, the Enterprise Information Portal (EIP), will be a full-featured environment that provides true portals into the business of the enterprise.

Enterprise portals will require integration of enterprise apps that execute across a heterogeneous set of apps. Web services provides the ''plugs'' that connect the source back-end systems to user interface components, called portlets, that provide a focused view into a business service. A portal can provide a dashboard of services to the user, in our case a customer service representative who needs access to legacy processing systems and databases. This dashboard is easily built by deploying the appropriate portlets into the enterprise portal.

With Web services-based components, firms can begin to architect and deploy this new generation of portals that are aggregate apps whose constituent services can execute anywhere on the 'Net. These portals provide access to the business IT infrastructure of a company, allowing customers, employees and business partners to be ''integrated'' with the business.

A snapshot of the Web services industry shows that a large contingent of early adopters are firms seeking both cost- and time-effective approaches and technologies for implementing their demand-chain and supply-chain solutions. A few years ago, some of these same companies were looking to EAI to create these solutions. Many experts expected EAI would be an integral part of the standardization of interfaces and messages that would enable these firms to communicate with their partners more effectively.

But recently, firms have shied away from EAI implementations that require significant up-front investment of resources and financial commitment with no measurable short- or medium-term ROI. The business case for creating these integration points still exists; but with shrinking IT budgets and the market demand for rapid deployment of solutions, the model has shifted to building app integration solutions in an incremental way using more ''commodity'' technologies.

From a technical perspective, Web services fills in what EAI lacked -- a standard, on-the-wire format to enable app components to exchange messages in an implementation-independent way. Web services, through SOAP and XML, provides this format and ''XML-itizes'' app integration. Combining its loosely coupled nature with standard-driven technologies that are ''toolable,'' Web services is a good approach to app integration in the small.

The sweet spot for Web services is sharing business logic in a non-intrusive way. Existing interfaces can be ''e-nabled'' for integration within the enterprise and between partners and customers. Web services provide an ''inside out'' approach to app integration where existing interfaces are wrapped as components with interfaces specified in XML in WSDL files.

To move from packaging and making functionality available via Web services to using Web services effectively, we must create an architecture that enables large-scale and pervasive use of Web services assets. Web services' benefits do not come from the mechanisms of the technologies that support it, but from the architecture and implementation that uses the technologies to expose useful, discrete components of the corporate IT infrastructure in a secure, reliable and scalable way.

Combining Web service app integration points with a service-oriented architecture provides the foundation for a Web service-oriented app integration platform, which enables integration solutions to be deployed in an incremental way. The Service Information Bus provides the universal circuit board for collaborative distributed computing by extending the Web service communication model from simple point-to-point message exchange to more complex many-to-many exchanges where multiple providers and requesters participate transparently.

Web services provides the plugs for connecting service requesters and providers to the bus, while the bus provides the intelligence for routing service requests to the target providers. The bus provides the information current and the ability to harmonize information and services across the enterprise, creating logical circuits between requesters and providers. This leads to the creation of a true web of services that supports the ability to create aggregate apps.

This architecture integrates heterogeneous information sources and consumers over a scalable and extensible infrastructure. The information current can be extended to partners and other business units. Using Web services, B2B Information Plugs are created that enable the bus to extend logical circuits to partners, trading exchanges and marketplaces. EAI plugs extend the information current to other business units, enabling standard cross-division integration points. If these all speak Web services, it is plug and play.

The good news is that building this architecture does not require a significant amount of effort and cost up front. For example, if your organization uses the J2EE platform for app development, the solutions you are building and deploying are easy to extend to Web services if they are architected and designed properly. J2EE-based service providers and requesters can be plugged into the service bus by creating adapters that ''Web servicize'' existing J2EE components. These adapters, which wrap the methods on the remote interfaces of Session or Entity beans, can be created using either the Java Web Services Development Kit or commercially available products. For the Service Information Bus, combining a UDDI-based repository with a Java Messaging Service Provider is all you need to get started. If your organization already has investments in EAI technology, those products can be used as the foundation for implementing the bus.

In my December 2001 article, I discussed how to integrate legacy assets into an architected component-based framework. This approach is based on the well-known Model-View-Controller pattern. It uses J2EE technology to enable legacy assets to be re-factored into reusable components called eaiComponents.

Existing legacy data assets are re-faced as Entity Bean model components that can be used in multiple transactions and business processes using controller eaiComponents deployed as Session Beans. Session Bean view eaiComponents wrap this functionality as a set of related business service methods, making it simple to invoke an operation such as AddCustomer. Under the covers, the framework of model and controller beans executes the supporting processes to support the business service request.

This model's power is its simple extensibility to Web services. Wrapping the View eaiComponents with Web services is straightforward, requiring the creation of a simple adaptation layer. The Customer Management eaiComponent's three service methods are provided as Web services to the bus via a Web service adapter. Now the functionality represented by these three business services is available to all requesters connected to the bus. Enterprise portals can also be plugged into the bus, allowing the rich array of business services and functions to be readily available to portal users. Web services become basically 'in-place' solutions, extending existing models with new and expanded connectivity.

I envision Web services adoption occurring in four phases. We are currently moving from a simple wrapped Web services model to the first generation of app integration solutions. These second-generation solutions will evolve from providing efficient access to services, to providing effective use of business services within the enterprise and with partners and customers. The third generation requires a service-oriented infrastructure that provides pervasive service access. This universal availability of information, functionality and services provides the foundation for fourth-generation solutions -- business process integration.

Web services gives us a cornerstone for B2B process integration by allowing new and existing functionality to be plugged into the information circuit of the service information bus, creating integrated business process circuits that execute within the enterprise and to ''connected'' partners. Programming complex business processes that span the enterprise and partner networks creates a ''process network'' enabling services to be integrated and new business processes to be created using existing assets to ''connect the dots.''

A work in progress
Firms should not delay in adopting Web services as an integral component of their IT toolkits. Despite the fact that interfaces like UDDI are still maturing, and security is still a work in progress, the foundation technologies of XML, SOAP and WSDL are mature and well formed.

For firms looking for a way to take services and offerings to market quickly, Web services is a great place to start because it can define and enable standard access. For enterprises still confronted with an app integration problem and paralyzed by the cost and fear of adopting ''heavy'' EAI platform solutions, Web services provides a fast path by wrapping existing processing assets using standard technologies. This will allow the infrastructure to grow on demand while meeting the short-term business needs of the company. The attraction for Web services is enabling organizations to make the transition from efficiency gains in providing Web-based access to simple functionality, to business effectiveness that enables organizations to create new business value through the unique combination of their existing IT infrastructure and business processes.

While Web services cannot end world hunger, I believe they provide the answer to app integration's Holy Grail -- a non-intrusive integration solution that uses standard and commodity technologies. The cost model, rapid time to market and standards-based nature of the platform is a hard-to-beat combination.

Web services have promise and a bright future. Stay tuned -- we have only begun this wild yet rewarding ride.