![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
There has been a long history of attempts to integrate systems based on older technologies with more modern architectures. To increase interoperability across heterogeneous environments, different software vendors and a variety of technologies, organizations needed a means of integration based on open-standards, rather than vendor-proprietary technologies. Java™ 2 Enterprise Edition (J2EE) Connector Architecture (JCA, or J2C) was compiled to specify a mechanism for accessing Enterprise Information Systems (EIS) from J2EE components. Subsequently, other specifications were published to extend the features provided by JCA. For instance, Enterprise Metadata Discovery (EMD) provides dynamic discovery features. In order to take EIS to the SOA world, Service-Component Architecture (SCA), when implemented by JCA resource adapters, provides a unified access mechanism to EIS through JCA resource adapters.
This article provides an overview of the technologies used in a J2EE environment to access EIS, and how these technologies can be extended to fit in a Service-Oriented Architecture. We'll start with a walkthrough of the technologies, and then discuss the tooling and runtime that enable implementations based on those technologies. A listing of possible tasks for implementing such an access to EIS using these technologies, tooling and runtime is included.
J2EE Connector Architecture (JCA) defines the standard to enable J2EE components to access EIS in a secure and scalable manner with support for transactions. JCA resource adapters -- the connectors defined by JCA specifications -- can implement an optional Common Client Interface (CCI) to provide unified API access for J2EE clients to EIS. JCA resource adapters are hosted by application servers that control their life cycle through a set of Service Provider Interfaces (SPI) defined by JCA specifications as System Contracts.
JCA resource adapters support two-way communication between the J2EE components and EIS:
- An outbound communication is initiated by a J2EE component, which acts as a client to access EIS.
- An inbound communication is initiated by EIS to notify a J2EE component, also known as an Endpoint Application, subscribed for events from that EIS. Inbound communications are performed asynchronously using the messaging infrastructure provided by the hosting application server as Message Providers.
The following diagram shows the two possible communication scenarios and the use of CCI and system contracts. J2EE components that use the resource adapter may co-reside with the adapter on the same application server or operate remotely.
Figure 1. JCA outbound and inbound scenarios
JCA specifications define more contracts for Quality of Service aspects, such as security, workload management, and connection management.
Enterprise Metadata Discovery (EMD) is a specification that defines a metadata discovery and import model to extend the functionality of JCA resource adapters. This model provides an Enterprise Application Integration (EAI) framework for tooling and runtime:
- Tooling: With EMD, EAI tooling enables JCA resource adapter developers to gather information about the data and functions of an EIS using metadata discovery facilities. These discovered EIS data and functions become available for developers (who want to consume a JCA resource adapter) to define service interfaces -- for selected EIS data and functions -- using metadata import facilities defined by the specification and provided by the tooling.
- Runtime: On the other hand, EAI runtime enables J2EE components to use generated service interfaces to EIS data and functions through the CCI exposed by the JCA resource adapter that complies with the EMD specification.
Obviously, EMD reduces the time required to consume a resource adapter by providing a means for exploring data and functions of an EIS. It also generates the code required to invoke CCI. If this functionality was not present, then adapter consumers would be needed to write such a code.
IBM WebSphere Adapters implement JCA, as well as EMD. Moreover, they extend both the programming and the runtime models to utilize the extended Quality of Service features provided by the WebSphere platform.
Figure 2. WebSphere Adapters are based on open standards
For common integrations, IBM has introduced two sets of adapters:
- Applications adapters provide connectivity to specific software packages, such as PeopleSoft Enterprise, SAP Software and Siebel Business Applications.
- Technology adapters provide connectivity to systems using specific technologies or protocols, such as JDBC, EJB and JMS.
Each set includes a list of adapters that can be acquired, deployed and configured independently on the WebSphere platform.
Both application adapters and technology adapters utilize a programming framework for developing WebSphere Adapters. ISVs and developers can use this framework to write their own custom adapters that solve specific integration cases not provided by off-the-shelf application and technology adapters. This can save much development effort, as it provides implementations to generic JCA interfaces and lets resource adapter developers focus on EIS-specific integration code. From a tooling perspective, WebSphere Adapter Toolkit can be used to simplify the development of custom resource adapters based on WebSphere Adapters technology.
Throughout the rest of this article, whatever applies to JCA resource adapters holds true for WebSphere Adapters, as they are JCA implementations.
WebSphere Adapters versus WebSphere Business Integration Adapters
WebSphere Adapters and WebSphere Business Integration Adapters are two different types of adapters that can be deployed on WebSphere platform to provide access to EIS. Process integrators, system assemblers, and adapter developers are encouraged to use and develop WebSphere Adapters which are fully compliant with JCA 1.5. The WebSphere Business Integration Adapters are not JCA-compliant, and they run outside the J2EE containers of an application server. See the Resources section for more information on the differences between the two types of adapters.
Invoking WebSphere Adapters from J2EE components
WebSphere Adapters are JCA resource adapters that can be deployed on a J2EE application server that supports JCA version 1.5. J2EE components such as Web modules and EJB modules, and can use WebSphere Adapters through CCI APIs as any other JCA resource adapters. When a JCA resource adapter complies with EMD specifications, the generated service interface, mentioned in the Enterprise Metadata Discovery section, uses CCI to connect to EIS. Furthermore, WebSphere Adapters -- like all JCA resource adapters -- may expose additional APIs to J2EE components, as needed.
Enterprise Information Systems and Service-Oriented Architecture
To a SOA, EIS is yet another system that provides functionality to other Enterprise Service Bus (ESB) members. Hence, Bus members should be able to use a unified mechanism to invoke functions provided by EIS and exchange data with EIS. Using a unified mechanism to access EIS and exchange data in an implementation-independent way enables interoperability among services from different vendors regardless of the implementation technology or transport.
As discussed above, JCA and EMD provide a solid mechanism to access the data and functions of EIS, while providing more Quality of Service capabilities from the J2EE platform. However, since JCA is part of the J2EE specification, this invocation mechanism addresses J2EE components, meaning technology-specific, even if this technology is an open standard.
Service Component Architecture
The Service Component Architecture (SCA) specification was developed to provide a unified way to invoke the services available on ESB by abstracting them as service components that can be used by other service components through interfaces:
- Component providers define interfaces that list the functions provided by their components and the data types used to invoke these functions.
- Component consumers define references to target the functions they need to invoke without specifying target components, implementation technology or the protocol used to access them.
- Application Assemblers wire references to interfaces takes place at the assembly time.
This loose coupling among interfaces, references, and wires allow components and their implementations to evolve independently without affecting other dependent components. Components can access non-SCA system external services using imports. An import defines the access mechanism used for communication with external service; that is binding. Imports define an interface for references from other components to wire to. A consuming component does not have to know whether its reference is wired to another similar component or to an external service through an import, as long as the interface provided by either of them is the same: the one that satisfies the reference.
Similarly, components can be invoked through exports. An export defines a set of functions that can be provided, without specifying the component that is going to provide them. When such an export is wired to a matching interface of a component, that component serves any invocations through that export. Again, exports can be bound to, or invoked by, SCA components or external services.
WebSphere Adapters as Service Components in Service-Oriented Architecture
A common definition of resource adapters is that they are system-level drivers to EIS. When defined as SCA components, resource adapters make EIS as accessible as any other component. According to SCA, consuming SCA components are not expected to use resource adapters in a J2EE way. Alternatively, SCA components should access EIS as external services through EIS imports and EIS exports, as discussed in the Service Component Architecture section. EIS imports realize the outbound scenario of resource adapters where SCA components invoke functions on EIS. EIS exports realize the inbound scenario where EIS-initiated actions notify and invoke SCA components. These two scenarios were mentioned earlier in the J2EE Connector Architecture section.
Figure 3. Key players for accessing EIS in Service Component Architecture
To make it easier for consumers, EIS imports and EIS exports can be generated by EAI tooling from resource adapters that conform to EMD specifications with EIS binding (also known as JCA binding). Generated import and export implementations can be edited as needed. Other binding options may be used, such as binding an import to a stateless session EJB that accesses EIS using a resource adapter in a pure J2EE manner, such as through CCI APIs. EJB binding should be used in that case. A Web service can replace the session EJB mentioned, and the Web service binding can be used. Again, consuming SCA components will not be affected by using any of the binding types, as long as the interface is the same.
Tooling and Runtime walkthrough
WebSphere Adapter Toolkit: for developing custom WebSphere Adapters
The IBM WebSphere Adapter Toolkit provides tooling, libraries and sample code to enable resource adapter developers to create JCA resource adapters based on WebSphere Adapters technology. Using the WebSphere Adapter Toolkit, developers can create both base JCA 1.5 adapters and WebSphere Adapters that extend JCA 1.5. The toolkit is installed on top of Rational® Application Developer and WebSphere Integration Developer. WebSphere Adapter Toolkit requires both Rational Application Developer and WebSphere Integration Developer to be installed on the same machine before the Toolkit can be installed.
WebSphere Integration Developer: for Enterprise Application Integration and Business Integration
WebSphere Integration Developer is a tool for creating business process flows, state machines and business rules. It also has support for the Service Component Architecture - including an assembly editor for assembling service components, for importing service interface definitions, and for setting binding policies. WebSphere Adapters can be assembled in WebSphere Integration Developer from the imported resource adapter archive (RAR) files -- possibly developed using WebSphere Adapter Toolkit or purchased separately -- and then exported as an enterprise archive (EAR) file and deployed on WebSphere platform. For binding SCA imports and exports, the assembly editor in WebSphere Integration Developer creates and configures them easily. For resource adapters that are compliant with the EMD specification, the enterprise service discovery wizard creates EIS import and export components, and the enterprise data discovery wizard creates business objects from data structures.
Target Runtimes: Application Servers
WebSphere Application Server constitutes the foundation for other application servers in the WebSphere family of products. As well as its role as a J2EE application server (including J2EE Connector Architecture support), it contains the Service Integration Bus (SIB) which is a basic implementation of the Enterprise Service Bus (ESB) architectural pattern. WebSphere Adapters can be deployed on WebSphere Application Server at the node level. WebSphere Enterprise Service Bus extends WebSphere Application Server by providing more mediation capabilities to the ESB implementation, such as service requests transformation, content-based routing and side-logging for auditing. From the SCA standpoint, mediation modules are SCA modules that have interfaces and bindings, as discussed in the Service Component Architecture section. WebSphere Process Server extends WebSphere ESB by providing business integration capabilities. WebSphere Adapters can be deployed on WebSphere ESB and WebSphere Process Server as part of an enterprise application (also known as embedded deployment) rather than being installed independently (standalone) at node level. Standalone deployment of WebSphere Adapters is only supported on WebSphere Application Server. WebSphere Adapters can be also assembled as SCA components in an enterprise application to be deployed on WebSphere ESB or WebSphere Process Server .
The development and assembly tasks needed to access an Enterprise Information System differ based on what software can be acquired versus developed; this is the same for the type of consumers that will access the EIS. These tasks can be summarized as follows:
- Develop/acquire: This is the process of developing and acquiring a resource adapter that accesses the EIS. WebSphere Adapter Toolkit facilitates the development of resource adapters. The resource adapter can be deployed in a stand alone fashion on WebSphere Application Server and used by J2EE components.
- Assemble (componentize): This allows for the assemply of a SCA component out of a resource adapter. The resource adapter used may be purchased or developed. This task is performed only if the EIS needs to be accessible from SCA components and business processes. WebSphere Integration Developer can be used for component assembly. The assembled SCA module can be packaged in an enterprise application and deployed on WebSphere Enterprise Service Bus or WebSphere Process Server.
- Compose: Once the components are defined, they can be used to compose higher granular services that map directly to business. This step is needed only if the SCA components are not significant enough to business so that they can be choreographed. To compose services, WebSphere Integration Developer can be used. The outcome is an enterprise application that can be deployed on WebSphere Enterprise Service Bus or WebSphere Process Server.
- Choreograph: Composed business services can be choreographed in a business process using WebSphere Integration Developer. The resulting enterprise application can be deployed on WebSphere Process Server.
The following table shows the inputs and outputs of each task of the above along with tools needed, target runtime and possible consumers.
Table 1. Access to EIS in SOA: inputs, outputs, tools, runtime and consumers
| Task | Input | Output | Tool | Runime | Possible Consumers |
|---|---|---|---|---|---|
| Develop/Acquire | None | Custom Resource Adapter (as RAR) | WebSphere Adapter Toolkit | WebSphere Application Server | J2EE components |
| Assemble (Componentize) | Resource Adapter | EIS Import SCA module (as EAR) | WebSphere Integration Developer | WebSphere Enterprise Service Bus or WebSphere Process Server | SCA external services/non-SCA components via standalone reference |
| Compose | SCA Import + (other SCA components) | Composite component SCA modules (as EAR) | WebSphere Integration Developer | WebSphere Enterprise Service Bus or WebSphere Process Server | SCA components/non-SCA components via standalone reference |
| Choreograph | SCA module(s) | Business process (as EAR) | WebSphere Integration Developer | WebSphere Process Server | Business process consumers |
As shown, the output of each task can be used on its own depending on the type of consumers. Proceeding with the rest of the tasks should be performed only as needed by the type consumers.
The WebSphere platform provides the tooling and runtime to integrate EIS into a SOA based on open standard specifications and technologies. Implementation tasks -- using these tools and runtime -- are tailored to the target consumers, giving the flexibility to accelerate implementations by acquiring off-the-shelf WebSphere Adapters.
Learn
- Introduction to the J2EE Connector Architecture
- About WebSphere Adapters
- Technical Overview of WebSphere Process Server and WebSphere Integration Developer
- Differences between WebSphere Adapters and WebSphere Business Integration Adapters
- About Enterprise Metadata Discovery
- What is Service Oriented Architecture?
- Service-Oriented Architecture expands the vision of Web services, Part 1
- Service-Oriented Architecture expands the vision of Web services, Part 2
- Managing Information Access to an Enterprise Information System Using J2EE and Services Oriented Architecture
- Toward a pattern language for Service-Oriented Architecture and Integration, Part 1
- Service-oriented modeling and architecture
- IBM SOA Foundation: An architectural introduction and overview
- About Service Component Architecture
- Architecting on demand solutions, Part 15
- Building SOA solutions with the Service Component Architecture - Part 1
- Building SOA solutions with the Service Component Architecture - Part 2
Get products and technologies
- Download
J2EE Connector Architecture version 1.5 specification
- Download
IBM WebSphere Adapter Toolkit
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
