| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Platform > WebLogic Integration > AI Topics > Introducing AI > Understanding the Integration Framework |
|
Introducing AI
|
Understanding the Integration Framework
The integration framework provided by WebLogic Integration offers a standards-based architecture for hosting application views: business-oriented interfaces to enterprise applications.
This section includes the following topics:
Understanding Adapters
Application integration uses an integration framework that is based on adapters and application views to help you integrate applications in your enterprise. Instead of hardwiring your enterprise systems together, you can use the integration framework to build adapters: software components that 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.
What Are Application Views?
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.
Understanding Application Views
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.
Figure 2-1 How Application Views Work
Main Features of Application Views Because WebLogic Integration uses the application view as its primary user interface for adapters, it offers several features not commonly found in competing EAI technologies:
The remainder of this section provides descriptions of these functions.
Use of XML as a Common Language Among Applications
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.
In the WebLogic Integration environment, virtually all messages are sent as XML documents:
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.
Use of Service and Event Definitions to Expose Application Capabilities
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.
Use of XML Schemas to Define the Data for Services and Events
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.
Support of Bidirectional Communication in Adapters
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 event adapters.
Who Uses Adapters and Application Views?
In your enterprise, several people may share the responsibilities of maintaining adapters, application views, and the services and events for those application views. In most enterprises, these people belong to one of three groups:
System Administrators
If you are responsible for installing the WebLogic Integration Adapter Development Kit (ADK), then you are the system administrator mentioned in this document and in Using Application Integration.
Adapter Developers
If you are a software developer or a high-level technician in your enterprise, you are probably an adapter developer. Adapter developers commonly use the ADK to develop new adapters for EIS systems and design the accompanying Common Client Interface (CCI) for the adapter. The CCI is an interface that the adapter user interacts with to design application views representing functionality associated with a resource adapter. For more information, see Developing Adapters.
Adapter Users
If you are a business analyst, EIS specialist, or technical analyst in your enterprise, you are probably an adapter user. Adapter users do not usually create adapters, but they may provide specifications to adapter developers. Once an adapter is created, application views for it are often defined and managed by its users.
How Responsibilities Are Distributed Among Users
Table 2-1 shows how tasks and responsibilities are typically divided among users.
What Are Design-Time GUIs?
The integration framework provided by WebLogic Integration provides 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.
Creating Application Views Using a Design GUI
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 Application Integration.
Managing Application Views with the Console
The Application View Console helps you access, organize, and edit all application views in your enterprise. You can use the Application View 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 View Console in Using Application Integration.
When to Define Application Views and When to Write Custom Code
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.
When to Define Application Views
Most EIS applications can be integrated into your system easily by defining application views. You may want to define application views in the following situations:
When to Write Custom Code Instead of Defining Application Views
In general, you should write a custom interface to an adapter only in the following situations:
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
