Web services are the latest in a series of industry-wide initiatives to connect and integrate extended enterprise applications. Despite having few deployments to date, Web services have generated a wave of excitement and bring the promise of delivering systems interoperability. Much has been written about creating new applications within a Web services framework and how Web services work. The reality, however, is that most of today’s IT systems still run on legacy platforms and simply aren’t architected to take advantage of new technologies. These systems, built at a high cost over many years, often have the knowledge of the business locked within them. There’s no simple way to replace them. No extended enterprise solution is complete without a viable approach to embracing the legacy platform.
Web Services and the Extended Enterprise
Over the last decade, we’ve seen numerous application integration technologies:
- Proprietary Electronic Data Interchange (EDI) solutions
- Message-based middleware products such as IBM’s WebSphere MQ (formerly MQSeries) and TIBCO’s TIB/ Rendezvous
- Object Request Broker (ORB)-based technologies such as Common Object Request Broker (CORBA) from the Object Management Group (OMG)
- Enterprise JavaBeans (EJBs) based on the Java 2 Enterprise Edition (J2EE) specification from Sun Microsystems
- Distributed Common Object Model (DCOM ) from Microsoft
- eXtensible Markup Language (XML).
These technologies were aimed to reduce the coupling between participating system components. In their quest for loosely coupled architectures, these technologies introduce such key milestones as:
- Replacing synchronous transfer of control with asynchronous message-based communications
- Relaxing rigid information exchange requirements via self-defining data formats
- Support for negotiated distributed transactional models.
Web services build on these technologies and leverage widely accepted Internet protocols such as HyperText Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), HyperText Markup Language (HTML), and XML. Both the transactional and security models for Web services are yet to evolve. However, both the Microsoft .NET strategy and Java communities have endorsed Web services. This gives Web services a high likelihood of industrywide acceptance even though the Microsoft and the Java camps’ approaches to Web services architecture are implemented in fundamentally different ways. Microsoft’s approach is platform dependent (Windows) and language independent (.NET family of languages); the Java camp’s approach is platform independent and language dependent (Java). The good news is that although developers must choose which approach to use, both implementations will interoperate due to their adherence to industry standards.
At the heart of Web services are three emerging industry protocols:
- Simple Object Access Protocol (SOAP) is the XML-based message format used for invoking Web services. SOAP is used to call Web services-based application functions over the Internet, regardless of their target operating system, hardware platform, or implementation language.
- Web Services Description Language (WSDL) is an XML-based metadata description of Web services. WSDL defines what the individual Web services do and the data and invocation binding properties of how to access them. WSDL started as a negotiated compromise between IBM and Microsoft to consolidate their numerous proprietary initiatives; it quickly evolved into a full-fledged standard.
- Universal Description, Discovery, and Integration (UDDI), referred to as the Yellow Pages of Web services, is the repository containing descriptions of available Web services. UDDI is where the publishing party goes to record the existence of Web services and where users go to look for Web services. UDDI incorporates company contact information, standard taxonomies such as geographic index, industry codes, etc., and technical information such as data binding, invocation properties, etc. IBM, Microsoft, and Ariba introduced UDDI in late 2000; now more than 250 companies support it.
Though these standards are new, they’re being complemented by even newer sets of standards — such as Web Services User Interface (WSUI) and Web Services Flow Language (WSFL) — and more standards are likely to emerge.
The three primary actors in the Web services collaboration model (see Figure 1) are Web services provider, broker, and consumer. The three primary activities that define the Web services collaboration model are publish, request, and bind. The Web services provider initiates the collaboration processes by developing the specific Web service, describing it using WSDL, and publishing its existence in the predefined UDDI. In this case, UDDI acts as the broker for this Web service. After the Web service is published in UDDI, it’s made available for use. A Web services consumer can interrogate the broker (UDDI) to request the information for the available service. After UDDI returns information about a specific Web service, the consumer can bind its application to this Web service and begin to use it.