Will Web services jump-start the software slump?

Web services are software applications that allow their programs to run over the Internet — taking advantage of new technology standards and creating workable and efficient e-commerce transaction-processing systems, among other applications. These software components network with other Web services dynamically, and use existing Internet technologies to create links between systems without massive re-engineering. A Web service is a compilation of responsibilities summarized into a stand-alone object, which users can access from the network. In a nutshell, Web services link, locate, and speak to other entities outside your own Web services system by spanning every linked Internet application.

New technologies driving the paradigm

To drive this new Web model forward, Java developers must familiarize themselves with the new technology standards derived from XML:

• Simple Object Access Protocol (SOAP), known as XML Protocol messaging specifications, is a standard for reliably transferring application triggers between Internet applications.
• Universal Description Discovery and Integration (UDDI) enables applications to broadcast specifications on how they want to manage information exchange with other applications. Those applications also hunt for information-trading partners to provide goods and services they need by querying UDDI registries (an open framework for relating and integrating application services, plus an operational registry).
• Web Services Description Language (WSDL) is an XML format for connecting network services as endpoint sets operating on messages that are either procedure- or document information-oriented. WSDL describes which programs are accessible via communication query by any network with message formats and protocols. WSDL is valuable because it provides for a programming standard and enables Web services to describe their capabilities, permitting easier interoperability among Web services and development tools.

These standards allow for core application assembly, taking the place of Enterprise JavaBeans (EJB) and other major vendors’ competing standards. Chief industry players, including Hewlett-Packard, IBM, Microsoft, and Sun, are currently working to strengthen Web services technology and standards like SOAP and WSDL. Vendor toolkits allow pre-existing JavaBeans to easily adapt to Web services. The Java 2 Platform, Enterprise Edition (J2EE) lets you write the fundamental parts of business applications (for example, connections to databases, transaction handling, and so forth) that will run across different computing systems. Web services for servers will be included in a future J2EE release.

Web service example

To better understand how Web services work, imagine the sort of Web service the real estate industry might offer. A consumer employs a Broker service, which searches a UDDI directory to identify several lenders. Those lenders all correspond to a unique dialect of XML schema (XML schema is a diagram or template that provides a road map to access data from linked systems). The Broker service’s business logic then corresponds with preferential lenders, allowing the business service program logic to assess mortgage proposals from multiple lenders and provide advice to the client, based on the XML returned to the Broker. The Broker could also arrange other supporting services such as Escrow, Inspection, Insurance, and an Appraisal service, given that this data conforms to a consistent schema.

In a highly competitive environment, you could provide multiple services to the client based on Web service business logic. That not only gives customers an effective way to acquire an advantageous loan, but it also provides them a one-stop process where they can access all services related to their needs. The Broker can also receive further commissions based on value-added services.

The goal of Web services is to combine components dynamically to accomplish specific business or user needs. The technical details of that combination are transparent to the user, who only encounters the result. The promise of Web services is that systems can market business functions that other systems can use.

Fueling the economy

Wherever there is a need for business collaboration or application integration along the enterprise, you’ll see businesses piloting Web services. The application server, portal, and Web application server markets will be most affected by Web services, since they will profit handsomely by ensuring that this technology gains early acceptance. “Many types of Web services will exchange data, but the most likely candidates for early adoption are services within industries where the nature of the conversations can be rapidly identified and standardized,” says Anne Thomas Manes, director of market innovation at Sun Microsystems. “The result will be XML schemas that serve as guidelines for developers in particular industries. XML enables the transfer of data between Web services, but specific conversations require that both sides understand both the meaning and the ordering of the data as it flows over the Web — information that is defined by schemas,” she adds.

“The first area where we see people using Web services will be in business-to-business integration. We expect to see it used in finance, travel, manufacturing, and other industries,” continues Manes.

Establishing the currently embryonic Web services market will prove challenging. According to GartnerGroup, 75 percent of corporations with revenues over 00 million will interface regularly with Web services by the middle of 2002 (GartnerGroup, June 11, 2001). AMR Research stated that the B2B-commerce platform will see almost a 50 percent annual growth between now and 2005, reaching .3 billion by 2005 from .9 billion this year (AMR Research, May 2001).

Jack Walicki, general manager of HP’s Web services operation, expects to see businesses profit from Web services in several ways. “Some will enjoy new revenue streams by turning business processes into services. Some companies will make money by acting as the anchor of a Web service exchange and potentially taking a cut of the transaction or charging a registration fee. Service providers will profit by offering their services in these exchanges. Some companies will reduce costs and increase revenues by using Web services to develop better-integrated supply chains.”

Web services also significantly lower the entry level for small businesses to profit from the Internet’s effectiveness at reaching new markets. Other technologies, such as Electronic Data Interchange, are reserved for sizeable businesses with the infrastructure and means to sustain them. In contrast, all businesses can use Web services to leverage their readily available infrastructure to execute and exchange with other Internet services.

With a growing market, developers will remain busy customizing in-house applications for the next few years. According to IBM’s Donald O’Toole, director of strategic software technology marketing, “It’s still very early, so it’s difficult to accurately quantify the opportunity that Web services represent. The opportunity for software and services to integrate e-business applications is enormous. When we look at that amount of spending, we find a majority of that spending represents custom programming or custom integration expenses. This spending is a good proxy for the Web services opportunity because Web services provide a faster, easier, and more flexible way for businesses to integrate applications.”

Loosely coupled versus tightly coupled programming models

Web services give developers a new freestanding programming model that moves away from the straitjacketed approach of legacy programming. The new paradigm doesn’t bog down in devices or protocols. By assembling business rules and logic within your application and accessing previously excluded data, an entire Internet-accessing architecture is exploited from within the programming model, unleashing the power to do many things previously difficult or impossible to do.

“Prior to Web services,” says Manes, “developers employed what is generally characterized as a tightly coupled programming model to develop new applications. That model assumes that the application works in a highly structured computing environment, where all the inputs and outputs are specified in great detail. A good example would be a graphical interface designed to query a database over a local area network. The behaviors of the interface, the network, and the database are all well known, and the programmer writes within the constraints of those behaviors.

“However,” adds Manes, “the tightly coupled model permits a constrained range of application services. Web services, on the other hand, employ a loosely coupled programming model, which opens a vast new range of application possibilities. This model opens up the computing environment to exploit large numbers of services executing on remote Internet systems. A single application might draw upon several such services, and use its internal business logic to assemble them into the preferred result. This loosely coupled model uses standards such as XML and SOAP to create a universally understood communications structure.”

A Web service allows an application to be assembled and wrapped without respect to the underlying fundamental technology. With Web services, the torment of translating among DCOM (Distributed Component Object Model), CORBA, and other protocols will be a thing of the past.

Michael Smith, principal evangelist for BEA Systems, sees a new wave of Web services application development emerging. “Virtually any component that interacts with another could be used as a Web service. This could be anything from a simple integration of application functionality, to syndication of a service, to cross-platform application integration. Web services will likely make a larger impact in business-to-business by loosely coupling applications that may range from simple informational applications to long-lasting, transaction-oriented applications in supply chain management, such as request for quote and order fulfillment.”

BEA’s efforts in business Web services involves connecting a supply chain with partners both upstream and downstream without the need for long integration cycles, using Business Transaction Protocol (BTP) and ebXML.

What you need to know beyond Java

Web services will essentially replace technologies like CORBA, COM, and EJB over time. Those objects may underlay Web services, but the most public and most used interfaces will be Web services’ XML-based interfaces.

The fastest way to come up to speed on Web services is to learn XML, SOAP, UDDI, and WSDL. Currently, vendors working with the JCP (Java Community Process) are extending Java with natively supported Web services.

A number of Java specification requests are currently in progress to create a new set of APIs collectively called the JAX APIs (Java APIs for XML). These APIs will add support for SOAP, UDDI, WSDL, ebXML, and other Web services technologies. Sun has also recently introduced the Open Net Environment (ONE), which it says extends the Java platform to cover all aspects of Web services. For further enhancement, Sun and the JCP are working on the Java API for XML (JAXP), the Java API for XML Messaging (JAXM), the Java API for XML-based RPC (JAX FLASH RPC), the Java APIs for XML Registry (JAXR), and the Java API for WSDL (JAXWSDL).

But Web services are not just about Java, according to IBM’s O’Toole. “Web services are language independent. Although we see Java being a preferred implementation vehicle, one could certainly use COBOL or other languages to deliver Web services, which are widely deployed. What Java offers developers is the virtual environment it creates regardless of the platform it is running on. A developer doesn’t need to change his or her program for it to be converted into a Web service.”

(IBM announced its e-business strategy in May 2001, enabling its entire software portfolio for Web services. It has implemented Web services support in WebSphere, DB2, Tivoli Management Software, and Lotus.)

Finally, Java programmers especially need to monitor the new Web services standards. They need to look for standards that have industry acceptance, well-established schema, and a backing organization that will bring it to market. In addition to maturing specifications and standards, Java developers will need to be aware of maturing application frameworks for XML-based or Web services-based applications. These frameworks should address how to send an XML document, how to receive it, how to break it apart and understand what it is, and how to run business logic on it. Developers must be aware that the industry is still changing and must ensure that they adapt to those changes.

Legacy applications will talk to Web services

Web services essentially permit legacy applications to communicate over the Web. The goal of chief vendors is to create “wraps” that let you access a high-level tool that turns your Java or any other program into a Web service. Legacy applications, such as Enterprise Resource Planning (ERP), and Web services can talk to each other by using high-level tools — such as HP’s E-Speak toolsets; IBM’s Dynamic e-business (infrastructure and software); and Sun’s ONE (Forte technology and iPlanet’s ECXpert) — which all assist data flow and communications between vastly diverse applications.

“The question really should be, ‘When will Web services speak to legacy applications?’ Web services are essentially a new interface to the legacy application, allowing it to converse over the Web,” says Manes.

ERP essentially provides for integrated, multicomponent application software performing multiple business functions. ERP involves the use of packaged software instead of client-written custom software. Web services simplify integration so users can easily access data through ERP.

ERP vendors are finding ways for different enterprises involved in the same supply chain to integrate their systems with the marketplace. This process ensures that enterprises name APIs for each other, decide on ways to find applications on the network, and come to agreement on how data is bartered between applications. Web services provide a standards-based architecture for these applications to describe, find, and bind functions through WSDL, UDDI, and SOAP.

The enterprise may still require an ERP for its internal systems to function efficiently together. Web services allow the enterprise to acquire the information needed to respond effectively, even in situations where tightly coupled application design isn’t necessary.

By developing an integrated Internet information solution, ERP systems companies make public information that was never before accessible from the enterprise. In this way efficient markets are created, permitting companies to concentrate their efforts on customer service and profits. As this new technology gains business-wide support, you will see more vendors announcing new products to support these Web services.

Security, transactions, and scalability issues

Authenticating user data in a virtual environment creates constant security concerns. Of greater consequence is the need to guard corporate data from rivals, data pirates, and an information-hungry public. The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols for Java were designed to help protect the privacy and integrity of data transferred across a network. The Java Secure Socket Extension (JSSE) 1.0.2 enables secure Internet communications. It provides a framework and a reference implementation for a Java version of the SSL and TLS protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication. Using JSSE, developers can provide for the secure passage of data between a client and a server running any application protocol (e.g., HTTP, Telnet, FTP) over TCP/IP.

In its current version (1.2, released in June 2001), SOAP doesn’t speak to the end-to-end security questions. A SOAP message can intersect multiple intermediate Web services before being delivered, yet has no ordinary means to implement end-to-end security. Some suggestions have been made based on XML-DSIG and Encryption UDDI technologies to resolve this, but since Web service interactions usually starts with a discovery phase using private registries or UDDI global, they become the Achilles heel for attack. UDDI needs to recognize enhanced security procedures for secure services data publication, identity management and access. A service should be able to verify that it is performing an operation on behalf of a valid associate rather than an impostor.

Web services will gain faster acceptance only when users can feel secure and confident through agreements on standards. To build user trust, consumer data and privacy policies should be defined, controlled, and managed through an open, vendor-neutral organization. The past decade has shown that taking an industry-wide approach is the proven and best way to ensure both users’ privacy and identity. The large-scale adoption and proliferation of Web services will be the major indicator that users trust and feel secure using Web services.

Getting past the hype

The grandiose projections of consulting firms and others about the magnitude of the Web service business will be put to the test. Web services-oriented architecture makes sense on paper, but how it will work in a market-driven economy remains to be seen. Many questions linger: Will Web services be any different than object-oriented development, RAD, and all of the other fads that have not lived up to their promises? What will make users use Web services? Will this way of supplying services be productive or will it be bogged down with complicated hoops and hurdles just to get simple apps to run? In short, how will Web services deliver a bulletproof service, with ease of maintenance, ease of use, at a reasonable price, with an uncomplicated interface that’s flexible enough to grow and evolve with the industry it serves?

Some of the roadblocks to acceptance could come from the inability to agree on standards, with each vendor building its own incompatible kludge of criteria. Although predictions are rosy, we know that market acceptance could be a long way off. Until winning applications are running over the Net, it could be some time before Internet-savvy corporations adapt this new technology.

The universal question

In the future, data and services will be shared in private and public exchanges. These interactions will originate in numerous market segments, such as wireless commerce, insurance and financial services, and manufacturing. The universal question has been: How will standards take shape and how can the computer industry agree to implement standards and schemas? Business pressures are driving this change. Given present market conditions, technology vendors must offer businesses a quick way to respond to changing market conditions and customer preferences. So the question really should be: When will Web services deliver industry-wide standards?