Development Methodologies and Supporting Tools

At the time of writing this book, Web services–related technologies are still growing. It is predictable that several related specifications will be added to the existing specifications. For example, Microsoft is working on some of these supporting Web services–related specifications. These specifications will extend the Web services environment by including infrastructure services that will define operational management functions such as ability to route messages among many servers and dynamic configuration of servers. These services are specified in the WS-Routing specification and the WS-Referral specification. More information about these specifications is available at http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-routing.asp and http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-referral.asp.

Dealing with protocol-specific constructs and programming models makes it difficult to develop Web services. Fortunately numerous vendors offer Web service development tools; companies like CapeClear, Polarlake, BEA, IBM, IONA, and others provide visual tools for editing XML, and automatic creation of Web service interface from existing legacy components like Java classes, EJBs, CORBA, and .NET components. Most of these tools allow development, deployment, and maintenance of Web services–based applications.

Web services are good candidates for widely used legacy systems. Message-oriented middleware (MOM) and transaction managers like IBM MQSeries, Microsoft MSMQ, Tibco Rendezvous, BEA MessageQ, and BEA Tuxedo offer out-of-the-box Web services interfaces, ready for plugging into a larger business solutions.

Web services can

• Create new business opportunities and value-add for customers, by exposing services over the Internet.

• Revitalize and/or reuse existing applications with new, powerful, and integrated business solutions.

• Increase developer productivity by simplifying the task of distributed systems development.

• Provide a standards-based solution, which in turn provides a portable and extensible solution, therefore "future proofing" the investment in integration technologies.

Although it is outside the scope of this book to discuss specific development paradigms for Web services, we briefly discuss a development methodology recommended by Object Management Group (OMG). OMG proposes a model-driven architecture (MDA), which tries to simplify the challenging problem of dealing with multiple industry standards and competing middleware architectures and information models/vocabularies. MDA tries to simplify this problem by unifying these diverse technologies using information models/designs and mapping these models to one or more implementation technologies (middleware, databases, languages, and so on). MDA also raises the level of abstraction at which these applications and integration scenarios can be designed and implemented, which is a key requirement to managing software integration complexity. MDA defines a software architecture that complements existing middleware, and modeling tools, and allows integration and interoperability to be addressed across the application life cycle and not just between individual objects or components. MDA provides an open, vendor-neutral approach to the challenge of interoperability, building upon and leveraging the UML, Meta-Object Facility (MOF), and Common Warehouse Meta-Model (CWM) standards. MDA allows a developer to design a model of an application or a component only once, and automatically map this model to several technologies. Additional information about MDA is available at http://www.omg.org/mda.

Other methodologies may be used by some mainstream tool vendors. For example, Polarlake's "Transactional XML." Transactional XML suggests a programming model where XML is at the center of the architecture. Transactional XML has the following modes:

• Web services Exposing existing IT assets, and providing mechanisms for discovering and interacting with those assets. Typically, a Web service exposes the assets as a series of remote procedure calls. These services fit into the larger eCommerce context using XML integrations.

• XML services Similar to Web services, without the notion of request-response model implicit in Web services.

• XML integrations Creating process flows from combinations of Web services and XML services.

• XML applications Creating new applications from a combination of XML integrations and services.

This methodology is useful in composing coarse-grained solutions by aggregating fine-grained solutions. It promotes modularity and reuse. Further information is available at http://www.polarlake.com.

From an application and component architecture perspective, Web service adds a new way of integrating the existing legacy applications, components, and systems into larger solutions. Note that applications and components themselves will still be designed, developed, and deployed using their respective mainstream object models, specifically J2EE, .NET, and CORBA. For example, one may use a tool to generate Web service interface from an exiting CORBA application, or one can implement a new Web service, by first implementing its business logic using any mainstream object model and then generating the required WSDL.

The Web services standard can be broken into three parts:

• SOAP The communication protocol

• WSDL The service description

• UDDI A directory through which one can query for an existing Web service

The following sections visit WSDL and SOAP standards. The method used to describe these standards is broken into two steps. The first step introduces the standard using its formal definition. In this step we provide an abstract summary of the formal specification developed by W3C. In the second step, we provide an example of how the standard applies to a real-world problem.