Use Web services to integrate Web applications with EISs
Web services: A team player in the enterprise-information-system integration game
Enterprise application integration; enterprise systems integration; legacy data access: thoughts that make most of us cringe. Until now, these terms have meant long hours of frustration, sleepless nights, and hair loss. Fear no more: help has arrived, or at least that is what we are being told in the development community. Web services technology has promised to solve your enterprise integration problems and then some. At this point, it’s hard to tell whether Web services are just a fad, but Sun Microsystems, Microsoft, and many others seem to be staking their reputations on the future of Web services. Let’s take a look at how the Java community and Microsoft are trying to make this promise more than just hype.
Introducing Web services
Web services is the term currently used to describe the concepts and technologies that integrate business processes and services over the Web using standard network protocols. Web services, as a technology, is a mechanism for delivering services and business content to any Web-enabled client or device.
Web services are URL-addressable resources that share a common protocol, allowing applications and services to connect to them over the Internet. Web services are based on XML and are communicated over existing HTTP infrastructures. The Web services model lets you combine unrelated applications and services dynamically in a loosely coupled manner over a networked environment.
Until recently, the Internet has mainly focused on interaction between Web browsers and data stores. Any integration with a middle-tier or legacy business system involved a lot of expensive, proprietary coding from several different teams of integration engineers. The Web services model promises to solve this problem by providing the following:
- A standard, uniform way to represent and transfer data
- A common, extensible message-processing format
- A common service description language
- A way to locate services
The current language used to describe Web services is the Web Services Description Language (WSDL). Web services are published in a registry using Universal Description, Discovery, and Integration (UDDI), and invoked over HTTP using the Simple Object Access Protocol (SOAP). A WSDL file is an XML document that defines a Web service and acts as a programming contract by separating a service’s interface from its implementation. A WSDL file provides abstract and concrete definitions for a Web service’s requests and responses, as well as the schemas needed to create the request documents and response documents.
XML is ubiquitous throughout the Web services architecture. Even though you can implement Web services in any programming language and deploy them on any network-accessible platform, you must use XML as the data transfer mechanism.
XML is quickly becoming the standard for information transfer and business interchange. According to many experts, XML should also replace EDI (electronic data interchange) systems as the main means of communication and data transfer between businesses. This ubiquitous XML support makes Web services the primary player in the enterprise information system (EIS) integration game.
The Java Web application domain
EIS integration usually begins with some kind of user instigation. The current preferred user environment for Web interactions is a Web browser. A user typically uses a browser to start a Web application session. This often starts a series of events that lead to one or more transactions on the middle tier and EIS integration tier. Typical Web applications need the following basic features:
- HTTP request handling
- Access control and authentication
- Session management
- HTTP request-parameter validation
- A way to read and write data to and from a persistent store
- Transaction-supportable connectivity to other systems
Sun Microsystems’ Java 2 Platform, Enterprise Edition (J2EE) supports these and other features that sophisticated Web applications need. For example, J2EE provides servlets and JavaServer Pages (JSP) to handle HTTP requests and session management. Servlets also control request-parameter validation. The Enterprise JavaBeans (EJB) architecture handles automatic persistence, transactions, connection pooling, and other typical middleware tasks. EJB and Java Database Connectivity (JDBC) provide database connectivity and access.
Sun Microsystems has recently released the Java Web Services Developer Pack (Java WSDP), a set of development technologies aimed at simplifying the Web services development process using the J2EE platform. The technologies include APIs for handling XML transfers between Web services, processing XML messages, interacting with XML-based registries, making remote procedure calls (RPCs), and using XML with the SOAP protocol. The pack also includes a standard tag library for JSPs and the Tomcat servlet and JSP container.
Web services and MVC in the presentation tier
Initially designed for fat-client application development, the Model-View-Controller (MVC) pattern has proven to work admirably for Web application development. MVC separates application development into roles that fit current business models; for example, page designers build elegant and effective Webpages, Java developers build business logic, domain experts manage application flow, and system integrators focus on backend integration. The benefits derived from this role support include:
- Reliability: The presentation and business logic layers are cleanly separated, which allows changes to an application’s look and feel that do not affect the rest of the system.
- High reuse and versatility: Applications can use multiple view types, all accessing the same business logic code from various client devices, such as Web browsers and wireless devices.
- Lower development costs: Higher-level programmers can develop and maintain the UI. Developers aren’t forced into domains in which they are uncomfortable.
- Rapid time to market: Development time is reduced significantly. Concurrent development is enforced, allowing Java programmers to focus on business logic, domain experts to concentrate on application flow, and Webpage designers to focus on presentation.
The MVC architecture lets you integrate Web services at several useful points in your Web application development. First, you must understand the components of an MVC implementation.
MVC components
Components involved with the MVC pattern in a Java Web application consist of a controller servlet to handle and dispatch client requests, multiple task objects to extend the controller to specific domains, JavaBeans to transfer data, platform service adapters for encapsulating model/business logic, and template pages for building the desired views.
The controller uses the Front Controller pattern to centralize client-request management in an object known as the Controller. The controller detects the client device, dispatches client requests to tasks, and loads and caches HTML pages and templates. It also aggregates pages and templates to complete the response ultimately returned to the client.
Task components are based on the Command pattern and extend the controller to handle specific domain requests. You implement these simple components using common interfaces and base classes.
JavaBeans manage data transfer duties for the application model. Tasks instantiate the necessary beans that represent the model for a particular application component; initialize any required input properties on the beans; pass the beans to the desired service; and then deliver the beans to the controller to form the response from the beans’ output properties.
Service adapters are Java components, such as JavaBeans and/or Enterprise JavaBeans (EJBs), that encapsulate the business logic for a specific service within a particular industry domain. Service adapters perform complex operations on backend systems; interface with middleware platform services, such as rules engines and job-scheduling engines; integrate data from disparate EISs; and handle transaction responsibilities.
HTML-style template pages form the application view. Application clients specify the desired template page. The controller looks for the template page in its cache. If the page is not in the controller’s cache, the controller loads the page and stores the page in its cache. Once the template page is found, the controller calls any tasks specified within the page, and then uses the results from each task, and any static data the template page specifies, to form the response later passed back to the client.
For MVC-based Web services integration, Web services, acting as clients, can drive service adapters using a thin translation layer between the Web service method call and the service adapter. This service adapter layer can notify Web services asynchronously using message-oriented middleware (MOM). Also, existing systems can wrap their CGI responses with this translation layer to provide an easy migration to a new system or architecture.
Web services and business services in the middle tier
Business services are currently implemented using middleware technologies such as EJB, CORBA, COM, and MOM. Most of these service technologies have been used for several years as integration technologies to access EISs. When business services can be discovered and invoked over the Internet, they are transformed into Web services.
Description languages, such as WSDL, describe business services as Web services. Discovery mechanisms providing standard registries, such as UDDI, are critical components for transforming business services into Web services. UDDI will likely become a primary Web service registry for enabling businesses to access content and data using the Internet. This description mechanism allows EISs to publish their Web services for interested business services to locate and use.
Web services and J2EE Connector in the enterprise tier
As more businesses gravitate towards a Web services strategy, integration with existing legacy systems grows increasingly important. Businesses need to extend their legacy systems to support business-to-business (B2B) transactions.
The J2EE Connector Architecture (JCA) provides a standard architecture for integrating heterogeneous EISs. Most architectures used to connect between B2B systems and EISs are nonstandard and vendor-specific. Using the JCA, EIS vendors don’t need to tailor their products to each B2B vendor’s needs. B2B vendors who adhere to the architecture guidelines don’t need to implement custom, proprietary code to connect to a new EIS.
The JCA advises each EIS vendor to provide a standard resource adapter for its EIS. The resource adapter plugs into systems that support the Connector architecture, providing connectivity between the EIS and enterprise applications using the systems. If a Web application framework vendor extends its system to support the Connector architecture, that vendor is assured of seamless connectivity to multiple EISs. An EIS vendor needs to provide just one resource adapter that supports the JCA. Examples of resource adapters are a JDBC driver to connect to a relational database, a connector to an enterprise resource planning (ERP) system, or a connector to a transaction-processing system.
The JCA specifies that a middleware system and an EIS collaborate to keep all system-level mechanisms, such as transactions, security, and connection management, transparent to the system’s business and presentation logic. The JCA defines the following set of system-level contracts between a middleware system and an EIS:
- A Connection Management contract that allows for pooling connections to an underlying EIS
- A Transaction Management contract between a transaction manager and an EIS that supports transactional access to EIS resource managers
- A Security contract that enables secure access to an EIS
The architecture also defines the Common Client Interface (CCI), a standard client API for EIS access. Using the API, application components and Enterprise Application Integration (EAI) frameworks can interact across disparate EISs.
The JCA supports access to EISs from Java applications and services. Web services implemented in a platform or framework that supports the JCA can easily access multiple, heterogeneous information systems using a common interface.
Web services, Java, and .Net
Microsoft is delivering a new platform, based on its .Net architecture, designed to facilitate interoperable Web application development. The .Net platform and technologies introduce a host of new products that rely on XML use, placing great emphasis on the SOAP protocol.
.Net applications will no longer execute in native machine code. All programs will compile to an intermediate binary code called the Microsoft Intermediate Language (MSIL). This portable binary code then executes in a sort of virtual machine called the Common Language Runtime (CLR).
With the .Net platform, Microsoft will provide several languages and associated compilers, such as C++, JScript, VB.Net (Visual Basic.Net), and C#. .Net can integrate with Java through the use of SOAP, XML, and other Web services technologies.
.Net’s business services architecture resembles the n-tier application architecture defined by Microsoft’s existing DNA (Distributed Internet Architecture) platform. In the .Net framework, a Web service listener is equivalent to the presentation layer of a Windows DNA application. An evolving business service system can access .Net by implementing a Web service listener. To implement a Web service listener, a system needs to understand SOAP messages and generate SOAP responses, provide WSDL contracts for its services, and advertise its services using a registry, such as UDDI.
With the Web services tools that J2EE and .Net provide, integration between the two platforms is easily realized in a cleanly separated architecture. XML is the language common to both environments. WSDL, SOAP, and UDDI allow developers to apply this XML glue to the enterprise application environment, thus integrating J2EE and .Net with EISs.
Revolutionize the way you do business
Web services promise to revolutionize not only the way we develop software systems, but also how we do business. WSDL, SOAP, UDDI, XML, Sun Microsystems’ J2EE, and Microsoft’s .Net certainly provide the technologies and tools needed to make this happen. By using these tools to implement well-designed systems that clearly determine the roles and responsibilities associated with distributed application development, we can fulfill that promise.
