Introducing Application Integration
A resource adapter (or simply adapter) is a software component that acts as a connector between an EIS and a J2EE application server (such as BEA WebLogic Server). Each adapter provides bi-directional, request-response integration with a specific application or technology. Resource adapters are implementations of the J2EE Connector Architecture (JCA) version 1.0, from Sun Microsystems, Inc. For more information, see the Sun JCA page at the following URL:
Application integration uses adapters and associated application views to help you integrate applications in your enterprise. Instead of hardwiring your enterprise systems together, you can use adapters to connect enterprise systems to an application server. Once you deploy an adapter for an EIS, other components and applications can use that adapter to access data on the EIS.
At run time, the EIS and the adapter exchange requests, responses, and events as XML documents. The adapter automatically handles the data translation between the EIS format and the XML format via schemas that are defined at design-time.
An application view is a business oriented interface to objects and operations within an EIS. Application views include the information needed to communicate with the EIS as well as configurations for services and events. Application views define:
An application view is typically configured for a single business purpose and contains only the services or events required for that business purpose. An EIS might have multiple application views defined for different business purposes. For example, an EIS containing human resources data might have an HREmployee application view that provides individual employees with read-only access to their personnel information, and an HRDataEntry application view that provides data entry clerks with the ability to add, update, and delete personnel information.
Application views provide a layer of abstraction between an adapter and the EIS functions exposed by that adapter. By using application views, you can simplify the procedure you must perform to access adapters. Instead of accessing an EIS by directly invoking it, you can simply edit the adapter's application views, create new application views, or delete obsolete ones. This layer of abstraction, formed by application views, makes it easy for nonprogrammers to maintain the services and events exposed by the adapter.
Each application view defines a set of business functions on one adapter's EIS. After an adapter is created, you can use its Web-based interface to define your own application views. Such application views allow you to display the application capabilities exposed by an adapter.
If you are a business analyst or technical analyst and you define an application view using an adapter, you can customize the application view for a specific business purpose. The business purpose is defined by the business analyst. For example, if you define a "Customer Management" application view on an adapter for a CRM (Customer Relationship Management) system, then you are likely to add only services and events that are related to customer management. You can, however, create application views that are as inclusive as necessary. Because application views can be customized for a specific business purpose, they work much better than the "one size fits all" approach used by many other EAI systems.
The business-level view of an application's capabilities provides a logical dividing line between the focus of the programmer and that of the technical analyst. For example, with a business-level view, a technical analyst can create records in a database without knowing SQL. Figure 2-1 provides a diagram of an application view at work in an application integration environment.
You create application views using the Application Integration Design Console, which is described in Application Integration Design Console. For detailed information about application views, see Defining an Application View in Using the Application Integration Design Console at the following URL:
You can use application views from a business process (JPD), web service (JWS), or from BEA Liquid Data. You can also write custom code to access an application view. For more information, see Using Application Views by Writing Custom Code in Using the Application Integration Design Console at the following URL:
In an EAI scenario, it is much easier and more efficient to use one common data format to integrate every EIS with WebLogic Server than it is to use a variety of custom, proprietary data formats to integrate each EIS with every other EIS. When a common data format is used, all applications communicate using a standard language. WebLogic Integration uses XML, the increasingly popular data interchange format, as its common data format.
Because an adapter translates an application's data format using XML, business analysts do not need to understand that format themselves. If you are a business analyst and you want to use an adapter, you need to know only how to define and use application views. Best of all, because all adapters use a similar Web-based interface for defining application views, it is easy to learn to use current and future adapters. Thus XML simplifies the use of EAI for developers and business analysts alike.
The application view, via an underlying adapter, supports events and services for a particular business use. Events enable messages generated by an application to be managed following a publish and subscribe model. Services are business functions that may be invoked by a user. Service invocations cause messages to be sent to an application following a request/response model. Events, service requests, and service responses are all passed through the system as XML documents.
Each application view uses an XML schema as metadata: that is, as information about the XML information for events, service requests, and service responses. This metadata helps users understand the data requirements of any application view event or service.
Currently, the J2EE Connector Architecture Specification version 1.0 does not provide guidelines governing how an EIS initiates communication with an application server or client. WebLogic Integration provides this communication capability via events.
Business processes, web services, and portals all access EIS data via the Application View Control, a Workshop control that provides access to an application view and, therefore, to the services defined for the associated EIS. The Application View control allows a business process engineer to browse the hierarchy of application views and to invoke a service as a business process action.
Synchronous services are represented as simple methods with a single parameter and a non-void return value. For an illustration of synchronous services, see Processing Synchronous Service Invocations. Asynchronous services are represented as both a method with a single parameter (the request), and a callback method with a single parameter (the response). For an illustration of asynchronous services, see Processing Asynchronous Service Invocations.
In addition, see Using Applications With Business Processes in Using the Application Integration Design Console at the following URL:
Any Java application that uses the Application View client API (in
Adapters deliver events using the WebLogic Integration Message Broker, which provides business processes with a channels-based publish and subscribe communication mechanism. For an illustration, see Processing Event Notifications at Run Time. The following table describes common consumers of events from an EIS.
Business processes, web services., and portals can subscribe to events published by the Message Broker via the Message Broker Subscription control (or, for business processes only, a static subscription). The Message Broker control listens for application view events. Events can start business processes in which the start node is configured with "Started with a Message Broker Subscription".
In addition, see "Receiving Events" in Using Applications With Business Processes in Using the Application Integration Design Console at the following URL:
Any Java application that uses the Application View client API (in
The design-time capabilities provided by WebLogic Integration provide a means for developers to create the Common Client Interface (CCI) for each adapter. The CCI enables applications components and Enterprise Application integration (EAI) frameworks to drive interactions across heterogeneous EISs using a common client API. An adapter's design-time GUI enables nonprogrammers to rapidly create, deploy, test, and edit application views, which they can customize by adding services and events.
The primary purpose of an adapter's design GUI is to allow you to define, deploy, and test application views. For detailed information about defining application views, see Using the Application Integration Design Console.
The Application Integration Design Console helps you access, organize, and edit all application views in your enterprise. You can use the Application Integration Design Console to create new folders and then add new application views to them. These folders allow you to organize your application views according to your own navigation scheme, regardless of the adapter used by the application view.
For detailed information about managing application views, see Using the Application Integration Design Console in Using the Application Integration Design Console.
Using an adapter's design-time GUI is not the only way to expose the functionality of an EIS, but it is usually the most convenient method. To support service invocations and events, you can define application views, or you can write custom code that accomplishes equivalent functions. At a minimum, you must define application views for each adapter, to expose the functions provided by the adapter's application. However, if your users require a greater than average degree of control, you may also write custom code that allows them to access the resources of an adapter. You must decide whether the needs of your enterprise can best be met by defining application views, writing your own code, or implementing a combination of both methods.
These use cases assume you are using JCA 1.0 adapters directly with WebLogic Server. In these cases, you are coding directly to the JCA CCI. This bypasses the capabilities of application views and WebLogic Integration.
Each EIS uses its own interface to handle service requests and event notifications. For example, SAP provides a BAPI interface that defines the parameters and syntax for BAPI requests and responses. For each EIS, the EIS interface defines the metadata that applications can use to integrate with the EIS. The EIS publishes data and expects requests in the format dictated by its interface rules and metadata.
At run time, the EIS and the adapter exchange service requests, service responses, and events via XML documents. The adapter handles the data translation between XML documents and the EIS format, using schemas that have been defined at design-time to map the data between XML and the EIS format:
At design time, you define a request and a response schema for each service and an event schema for each event that you configure in the application view. For some adapters, such as SAP, you can use the BEA Application Explorer, which is described in BEA Application Explorer. For other adapters, you need to create schemas manually. For instructions on how to define schemas for a particular adapter, see the "Generating Schemas" chapter in the User's Guide for the adapter(s) that you are using.
Once you have created the necessary schemas, you save them in a file-based repository, along with a manifest file that associates the schemas with events and services. When you configure application views in the Application Integration Design Console, you specify the location of the repository so that the application view can find the schemas as needed. For more information, see the "Defining Application Views" chapter in the User's Guide for the adapter(s) that you are using.
The BEA Application Explorer is a design-time tool that you can use to generate schemas for services and events. The BEA Application Explorer incorporates in-depth knowledge of application system environments to query for metadata on specific business objects in the EIS. It uses that metadata to generate the schemas required to build the selected service or event—request and response schemas for services and the event schemas for events. For an introduction to schemas, see EIS Metadata, Schemas, and Repositories.
The Application Integration Design Console is a design-time tool that you use to build application views and configure services and events. For each event or service, the Application Integration Design Console allows you to configure connection settings and other relevant information.
For instructions on how to create application views using the Application Integration Design Console, see the "Defining Application Views" chapter in the User's Guide for the adapter(s) that you are using, as well as "Defining an Application View" in Introduction to Application Integration in Using the Application Integration Design Console at the following URL:
BEA WebLogic Workshop is an integrated development environment for building enterprise-class applications on the BEA WebLogic Platform. WebLogic Workshop is both a design-time tool for building business processes, web services, and portals, and a run-time environment for running business processes.
For detailed information, see Starting Your Business Processes in the BEA WebLogic Workshop Help System at the following URL:
The WebLogic Integration Administration Console allows you to manage deployed application views and adapter instances. For each application view, an administrator can perform management tasks, including the following:
For more information on the console, see Managing WebLogic Integration Solutions. The information is also provided in the WebLogic Integration Administration Console help.
The procedures in this section provide simplified, high-level (non-programmer) descriptions of the process. For sample code, see "Code for Sample Java Class" in Using Application Views by Writing Custom Code in Using the Application Integration Design Console at the following URL:
In these procedures, we use the term adapter instance. An adapter instance defines zero or one event connection and zero or more service connections. Each adapter instance is related to a base adapter which is deployed as a RAR file.
invokeServicemethod), specifying the service name, application name, and the request document.
invokeServicemethod and processes it accordingly.
WLAI_EVENT_TOPICJMS topic). A message-driven bean (the WLI-AI Event Processor) listens on the
WLAI_EVENT_QUEUEdistributed destination and publishes a copy of the event to the
WLAI_EVENT_TOPICis a distributed JMS topic that handles the delivery of events to remote application view clients.
At design-time, event consumers must be configured to listen for the event on either of these destinations. In addition, the EIS must be configured to send event messages to a particular destination so that the adapter can receive it via the EIS-specific communications protocol.
WLAI_EVENT_TOPIC) for delivery to remote or local Application Integration clients who are listening to this topic.