Web Services Bring the Real-Time Enterprise Closer

Web services can be the catalyst for the creation of service-oriented architectures. By letting applications access data across different devices, operating systems and locations, Web services bring the real-time enterprise a step nearer.

Many CIOs and other executives are looking at technologies that will enable their enterprises to operate in real time. Web services can be the catalyst for the creation of service-oriented architectures. By letting applications access data across different devices, operating systems and locations, Web services bring the real-time enterprise a step nearer.

An Overview of Web Services

Derived significantly from component technology, Web services originated in the simple use of XML to describe the parameters needed to build a simple loosely coupled remote procedure call construct over HTTP. During the past years, Web services have evolved into a minimal set of what is necessary to do simple distributed computing – adding Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) and the Universal Description, Discovery and Integration (UDDI) registry. But unrealistic perceptions or claims regarding what Web services can immediately deliver have made the technology the subject of some disillusionment.

Much of what Web services are attempting to do is not new – rather, it is largely an attempt to redo it, better and simpler. Like the Web itself, Web services are the simple underpinnings. Web services are about adding basic programmability to the Web. Such a technology needs a common-sense definition. Gartner offers the following:

Web services are software components that employ one or more of the following technologies – SOAP, WSDL and UDDI – to perform distributed computing. They allow applications to access data from one another across different devices, operating systems and locations. Consequently, they play a major role in realizing the real-time enterprise (RTE) concept.

• Use of any of the basic technologies – SOAP, WSDL or UDDI – constitutes a Web service.
• Use of all of them is not required.

IT and business managers taking their enterprises along the rocky road to real-time information sharing and synchronization must select the right technologies. The RTE is a concept, not a set of plug-and-play technologies, but it cannot be achieved without appropriate technology.

Developing a Service-Oriented Architecture Using Web Services

Web services can act as a catalyst for the creation of a service-oriented architecture, in which business functionality is organized as a collection of modules known as services. These improve an enterprise’s reaction time by shortening development schedules and making critical data available to more applications – and so to more users – faster and more reliably. Application developers benefit from the freedom to access a service instead of having to perform tight integration between applications or develop critical functionality on their own. This helps enterprises to shorten the time taken to develop new data-access capabilities and the time it takes for applications to share information.

Web Services in New Projects

If no previous systems exist to deal with, businesses can use Web services as a primary development element. A “green field” project presents an enterprise with the opportunity to develop a services orientation without requiring tools or connectors for legacy applications and architecture. Links between enterprises are easily made. Green-field projects are attractive because no reliance exists on wrapping or incorporating established technologies. The newness of the environment invites novelty in the solution. New products and frameworks can give all users access, regardless of their PC, operating system or location. For example, i-Deal is using Web services to provide a neutral platform for connecting broker/dealers in the financial industry.

For uBid, an online auction powerhouse, the benefits have been dramatic. It now takes only two weeks to add aggregators, or auction “middlemen,” to its system. Buyers, of course, have instant access.

Web Services in Legacy Integration Projects

Enterprises should not earmark strategic or highly visible projects for Web services unless their corporate culture is suited to taking risks with IT. Selecting strategic projects for Web services will almost certainly result in managerial disappointment because of inevitable delays. For most enterprises, tiny steps are the best way to start. But Web services should not be used to fix problems that will not affect the business. This will associate them forever with unremarkable projects.

On a small-scale project, learning to deploy Web services will not delay the project too much. Astute enterprises will use Web services to address problems where a solution will get attention, but isn’t eagerly awaited or business-critical. For example:

A Web services implementation at the Colorado Department of Agriculture led to substantial reductions in some data processing times. Field workers now have immediate access to the latest data instead of having to wait weeks for a report.

A sales data analysis system at Rotech Healthcare makes it possible for Rotech to generate readable charts and graphics from previously incompatible data sources, giving it immediate insights into the effects of potential changes.

When Not to Use Web Services

Web services provide loose integration, without the cost of an extensive integration project. They are very effective at opening windows into previously inaccessible data, but they are not so effective at helping to provide the reliable unification of data repositories.

Web services projects are most successful when the responsibility for data retention and structure remains with the established applications, and Web services only provide a new method for viewing or analyzing the data. SOAP is reliable and relatively mature in providing a data-viewing interface, similar to the way in which other Internet protocols address their specific and circumscribed tasks, such as limited data retrieval with HTTP. Web services will not improve the accuracy of data.

That is why Rotech did not unify disparate data sources in a single, new, modern repository, choosing instead to keep its legacy Virtual Storage Access Method and Structured Query Language repositories. The company could develop new analyses of geographically oriented sales data quickly, without costly integration work.

Enterprises in which a project proves a poor match for Web services may find that the project is better handled through another aspect of service-oriented architecture. SOAP, for example, does not offer easy scalability for high-traffic applications unless properly managed. Enterprises that need such scalability may prefer to completely replace an established legacy database structure because they will avoid problems associated with vendor immaturity and market volatility.

Extending Web Services

Web services-enabled data interfaces will not make the data any more accurate or increase its usefulness. Ways exist around the accuracy problem using search and associated technologies, but they can add dramatically to costs. Access to data that is clean, intelligible, usable and lasts beyond a single project is essential for successful Web services and RTE projects. Data repositories enabled through Web services will be consulted both repeatedly and periodically by multiple applications throughout the enterprise. That brings two benefits:

• Enterprises gain access to valuable data more quickly and reliably on subsequent projects.
• They spend less money and time on development to achieve this.

The Value Web

Web services have significant value as enterprises seek to exploit the benefits of RTE. They save money by making repositories and data logic reusable. Once properly managed, they offer flexibility because of their basis in robust and mature standards. Web services benefit enterprises seeking to improve their real-time credentials and performance because they encourage and enable information to travel between applications. Enterprises should not force Web services onto all RTE-related projects, or even onto all projects with a service orientation. However, the general usefulness of Web services’ and their extensibility make them particularly suited for many aspects of application integration. Failing to use Web services where it is the best solution would be a costly mistake.

Gartner’s Tactical Guidelines

Use Web services for the following:

• New projects with no legacy issues or applications to incorporate.
• Noninvasive integration of legacy systems where projects are tactical but popular and the data is clean, intelligible and can be used in multiple projects.

A Gartner Recommendation to CIOs

A Gartner recommendation to CIOs: Pilot two key RTE technologies in 2003 – Web services and instant messaging (IM). The enterprise that sits on the sidelines while its competitors explore Web services will risk allowing them to open a strategic business lead that will be hard to close. Moving to a service-oriented architecture approach is not simply a matter of spending money on new software – it is a new model requiring significant cultural and philosophical changes for application development and deployment.

CIOs should secure consumer IM technologies in use in their enterprises in 2003, while evaluating steps for implementing an enterprise-class IM solution and promoting its use. Simply ignoring or blocking IM will damage the reputation of the IS organization.

Bottom Line

Until the end of 2005, most enterprises should limit their use of Web services to projects that are not time-critical, but will be received positively. Wider implementation will likely incur significant risks that the risk-averse majority should shun. Wider implementation will likely result in ill-considered failures and internally prominent examples of waste.