Enterprise applications have really made significant strides over the past 10 years (especially in the past 4) to improve their ability to integrate into a larger corporate scheme. There was a time when the letters SAP invoked uncertainty on the part of non-SAP consultants as to what these systems did. Back then, most integration was done primarily through the underlying data model and information on the platform was scarce, especially on the SAP Web site.

The integration with SAP that wasn't handled through customization of the data model occurred mainly through extracted documents known as IDOCs - structured documents based on internally defined structure and loosely defined codes. This made IDOCs useful for integration internally among developers within the same organization. As things progressed, SAP customers demanded a better interface for real-time integration of Enterprise Resource Planning (ERP) capabilities with existing manufacturing systems. Thus, Business Application Programming Interfaces (BAPI), offering an Object Request Broker (ORB) architecture against which programmers could communicate with ERP objects was born. With BAPI, it became possible to develop applications that could synchronize the data in the ERP system with other existing enterprise applications, such as Electronic Data Interchange (EDI).

BAPIs worked well for a time, until the ERP information had to be shared with external entities, such as the supply chain. Many companies didn't like the idea of allowing their trading partners and customers to directly impact their mission-critical systems, and IDOCs offered little assistance in this area, given the lack of structural information that accompanied the documents. Since this need emerged in parallel with the development of the eXtensible Markup Language (XML), the requirement and specification were in complete synergy to become the natural solution.

With the advent of Web services - a model for developing application components designed for sharing with other applications in a loosely coupled manner-the question to be answered is, "What problem does this solve for enterprises today?" As we've seen thus far, each of the advances in technology was incorporated into the enterprise application platform based on consumer needs. Initially, the need was customization, then communication of data with other internal systems, and finally, the need for real-time access for synchronization.

Web Services in An Enterprise World
Business-to-business (B2B) and enterprise application integration (EAI) are both about the development of new or modified processes for the purposes of bettering the organization. These enhancements might lead to faster production, lower cost of development, or increased communication with customers and partners. The crux of these enhancements can be readily seen in Customer Relationship Management (CRM), ERP, Supplier Relationship Management (SRM), and Supply-Chain Management (SCM) applications.

B2B and EAI are also about providing access to data that has been typically developed in stove-pipe applications locked away from each other by artificial boundaries. These new processes require that information be provided on demand and be up-to-date with the latest changes. It's no longer acceptable to have a two-day lag on inventory information in a shop that relies on Just-In-Time manufacturing. Large manufacturers, such as General Motors, rely on completed parts assemblies arriving at the shipping dock the day they are to be assembled into a vehicle.

To answer the question posed at the end of the last section, we need to look at the Web services offering from different perspectives. The first perspective is the traditional view of Web services that many programmers are being introduced to today through tools such as BEA's WebLogic Workshop and Microsoft's Visual Studio .NET. This perspective leverages the Simple Object Access Protocol (SOAP) and Web Service Definition Language (WSDL) as a means to wrap a functional interface with an XML request-and-response document. From this perspective, the functions being wrapped have well-defined method signatures and use known data typing, such as strings and integers. The XML documents encode the parameters and return values to these functions using SOAP encoding (see Figure 1).

This methodology extends the Remote Procedure Call (RPC) functionality provided by popular ORBs, such as CORBA, DCOM, and Java RMI. However, it extends the RPC capabilities to operate over more traditional, and often firewall-friendly, interfaces such as SMTP and HTTP. On the other hand, merely extending an existing methodology does little to demonstrate the role that Web services could play in an EAI or B2B solution. For this we need to look at Web services from another perspective.

In the introductory paragraphs we discussed how systems like SAP used a document metaphor for data exchange with other systems-the IDOC. The weakness in the IDOC approach was the lack of communication of the structure to systems that weren't privy to the underlying data model. This is where the real opportunity for Web services exists.

When we reviewed the traditional approach to Web services, we saw that they operate through the use of XML-based request-and-response documents. XML was chosen as the format for SOAP encoding because it was able to incorporate metadata about the data encoded as well as carry the data itself. But SOAP is also a general enveloping facility that can carry non-XML documents between applications and can use alternate encoding schemes for the data it is carrying. Therefore, it's possible to use the multitude of existing document formats as input to and output from Web services processing.

Viewed from this perspective, it would be possible to use existing spreadsheet models and IDOC-like documents as input into a server-side process, thus providing significant reuse of existing systems architectures for interoperability and integration. Moreover, the SOAP architecture provides ample support to notify the sender that the document type is understood and has been properly processed by the receiver.

You might ask, "Why go through all the trouble of implementing a new encoding scheme instead of just transforming the data into XML?" That's an excellent question, which can only be answered by pointing to a possible real-world scenario. Before XML existed, there was a multitude of data formats, such as comma-separated values, tab-delimited, and even column-specific formats. To facilitate integration with existing applications, these formats were generated by many legacy systems; systems that today are costly to pull out of production or to rewrite to support XML.

Developing a new B2B or EAI process to communicate with systems might require that the data be formatted for the time being in something other than XML. Web services enables us to take advantage of these systems as components of a much larger process without having to first rewrite them - a very powerful and often overlooked capability of Web services. Remember, the goal of Web services is to componentize our legacy systems so they can participate in newly designed processes, which means that they will take some input and provide some output that will be used in downstream steps.

Next Steps for Web Services EAI
In contrast to past supporting changes made to enterprise applications for the purposes of integration, Web services is clearly being driven by the hype surrounding XML and the support for Web services by leading companies, such as Microsoft, IBM, BEA, Oracle, and others. The widespread support for Web services by these companies - for example, Microsoft betting the company on a Web services strategy - has led vendors such as Siebel, SAP, JD Edwards, and others to develop Web services or SOAP interfaces to their products. It's still questionable how soon enterprises will adopt these interfaces for use in new application integration solutions.

Standardization will be a key contributor to this adoption, if and when it occurs. In addition to SOAP, organizations created to ensure the interoperability of Web services implementations (WS-I) and emerging standards, such as Web Service Flow Language (WSFL), will assist with tying together these components in a consistent manner. These will help increase the chances of success.

Note: while there are many contrasts between efforts, the Object Management Group (OMG) has followed a very similar history in the CORBA arena, with only a modest level of adoption. And, while there are many differences between CORBA and Web services that don't allow for prediction based on past experience - for example widespread support by Microsoft - there's certainly a large degree of consistency in the approaches that indicates that Web services will have a much steeper learning curve than most of the early XML-based standards.