|
|
|
|
|
|
Concepts
This section describes some of the more important concepts with which you should become familiar before attempting to develop an adapter or design-time GUI. You will see additional discussion of all of the following concepts at some point in the adapter/GUI development procedures.
This section provides information on the following subjects:
Run Time Versus Design Time
Adapter activity falls within one of two conceptual entities: run time and design time. Run time refers to functionality that occurs when adapters execute their processes. Design time refers to the adapter user's implementation of an application view; in essence, design time is the act of creating, deploying, and testing an application view.
Run time and design time are characterized in the ADK by the run-time and design-time frameworks. The run-time framework is comprised of the tools used when developing adapters while the design-time framework refers to the tools you will use to design Web-based user interfaces. Run time and design time are discussed in greater detail below.
Run-Time Framework
The run-time framework is the set of tools you will use to develop event and service adapters. To support event adapter development, the run-time framework provides a basic, extensible event generator. For service adapter development, the run-time framework provides a complete J2EE-compliant adapter.
The classes supplied by the run-time framework provide the following benefits:
In addition, the run-time framework provides abstract base classes to help you implement an event generator to leverage the event support provided by the ADK environment.
A key component of the run-time framework is the run-time engine, which hosts the adapter component responsible for handling service invocations and manages:
all in compliance with the J2EE Connector Architecture standard. These features are provided by WebLogic Server.
Design-Time Framework
The design-time framework provides the tools you will use to build the Web-based GUI that adapter users need to define, deploy, and test their application views. Although each adapter has EIS-specific functionality, all adapters require a GUI for deploying application views. This framework minimizes the effort required to create and deploy this GUI, primarily by using these two components:
The design-time interface for each adapter is a J2EE Web application that is bundled as a .war file. A Web application is a bundle of .jsp, .html, image files, and so on. The Web application descriptor is web.xml. The descriptor instructs the J2EE Web container how to deploy and initialize the Web application.
Every Web application has a context. The context is specified during deployment and identifies resources associated with the Web application under the Web container's doc root.
Events and Services
The ADK is used to create two types of adapters: event adapters and service adapters. Within the ADK architecture, services and events are defined as a self-describing objects (that is, the name indicates the business function) that use XML schema to define their input and output.
Events
An event is an XML document published by an application view when an event of interest occurs within an EIS. Clients that want to be notified of events register their interest with an application view. The application view then acts as a broker between the target application and the client. When a client has subscribed to events published by an application view, the application view notifies the client whenever an event of interest occurs within the target application. When an event subscriber is notified that an event of interest has occurred, it is passed an XML document that describes the event. Application views that publish events can also provide clients with the XML schema for the publishable events.
Note: The application view represents a business-level interface to the specific functionality in an application. For more information on this feature, please refer to Introducing Application Integration.
Services
A service is a business operation within an application that is exposed by the application view. It exists as a request/response mechanism; that is, when an application receives a request to invoke a business service, the application view invokes that functionality within its target application and then returns (or, responds with) an XML document that describes the results.
To define a service, you will need to determine and define the input requirements, output expectations, and the content of the interaction specification. A request is submitted in two parts:
Logging
Logging is an essential feature of an adapter component. Most adapters are used to integrate different applications and do not interact with end users while processing data. Unlike the behavior of a front-end component, when an adapter encounters an error or warning condition, it cannot stop processing and wait for an end-user to respond.
Moreover, the applications that adapters connect to are typically mission-critical business applications. For example, an adapter might be required to keep an audit report of every transaction with an EIS. Consequently, adapter components should provide both accurate logging and auditing information. The ADKs logging framework is designed to handle the needs of both logging and auditing.
The Logging Toolkit
The ADK provides the logging toolkit, which allows you to log localized messages to multiple output destinations. The logging toolkit leverages the work of the open source project, Apache Log4j.
The logging toolkit wraps the critical classes within Log4j to provide added functionality when you are building J2EE-compliant adapters and is provided in the logtoolkit.jar file.
For information on using the logging toolkit, see Using the Logging Toolkit.
The Logging Framework
With the ADK, logging of adapter activity is accomplished by implementing the logging framework. This framework gives you the ability to log internationalized and localized messages to multiple output destinations. It provides a range of configuration parameters you can use to tailor message category, priority, format, and destination.
The logging framework uses a categorical hierarchy to allow inheritance of logging configuration by all packages and classes within an adapter. The framework allows parameters to be easily modified during run time.
Internationalization and Localization
The logging framework allows you to internationalize log messages. Internationalized applications are easy to tailor to the idioms and languages of end users around the world without re-factoring the code. Localization is the process of adapting software for a specific region or language by adding locale-specific components and text. The logging framework uses the internationalization and localization facilities provided by the Java platform.
Adapter Logical Name
Each adapter created must have an adapter logical name; that is, a unique identifier that represents an individual adapter and serves as the organizing principle for all adapters. As such, the adapter logical name is how an individual adapter is identified and is also used to name the following:
The adapter logical name is a combination of the vendor name, the type of EIS connected to the adapter, and the version number of the EIS. By convention, this information is expressed as vendor_EIS-type_EIS version; for example, BEA_WLS_SAMPLE_ADK, where:
Where the Adapter Logical Name is Used
The adapter logical name is used with adapters in the following ways:
In Adapter Deployment
The Name attribute of the <ConnectorComponent> element must be the adapter logical name. This is the key application integration uses to associate application views to a deployed resource adapter, as shown for the sample adapter in Listing 2-1.
Listing 2-1 Name Attribute of the ConnectorComponent Element
<ConnectorComponent
Name="BEA_WLS_SAMPLE_ADK"
Targets="myserver"
URI="BEA_WLS_SAMPLE_ADK.rar"/>
Note: The adapter logical name is used as the name of the .rar file as a convention, but is not required in the URI attribute.
When an application view is deployed, it has an associated J2EE Connector Architecture CCI connection factory deployment. For example, if a user deploys the abc.xyz application view, WebLogic Integration deploys a new ConnectionFactory and binds it to the JNDI location com.bea.wlai.connectionFactories.abc.xyz. connectionFactoryInstance. For efficiency sake, the new connection factory deployment uses the <ra-link-ref> setting in the weblogic-ra.xml deployment descriptor.
The <ra-link-ref> element allows for the logical association of multiple deployed connection factories with a single deployed adapter. The specification of the optional <ra-link-ref> element with a value identifying a separately deployed connection factory will result in this newly deployed connection factory sharing the adapter which had been deployed with the referenced connection factory. In addition, any values defined in the referred connection factory's deployment will be inherited by this newly deployed connection factory unless specified. The adapter logical name is used as the value for the <ra-link-ref> element.
As an Organizing Principle
Table 2-1 lists the areas that use the adapter logical name as an organizing principle.
As the Return Value for getAdapterLogicalName() Lastly, the adapter logical name is used as the return value to the abstract method getAdapterLogicalName() on the com.bea.adapter.web. AbstractDesignTimeRequestHandler. This return value is used during the deployment of application views as the value for the RootLogContext for a connection factory.
Enterprise Archive (.ear) Files
The ADK uses Enterprise Archive files—.ear files—for deploying adapters. A single .ear file contains the .war and .rar files and the Event Router Web application files necessary to deploy an adapter. An example of an .ear file is shown in Listing 2-2.
Listing 2-2 .ear File Structure
adapter.ear
application.xml
sharedJar.jar
adapter.jar
adapter.rar
META-INF
ra.xml
weblogic-ra.xml
MANIFEST.MF
designtime.war
WEB-INF
web.xml
META-INF
MANIFEST.MF
eventrouter.war
WEB-INF
web.xml
META-INF
MANIFEST.MF
The .ear file for the sample adapter is shown in Listing 2-3.
Listing 2-3 Sample Adapter .ear File
sample.ear
application.xml
adk.jar (shared .jar between .war and .rar)
bea.jar (shared .jar between .war and .rar)
BEA_WLS_SAMPLE_ADK.jar (shared .jar between .war and .rar)
BEA_WLS_SAMPLE_ADK.war (Web application with
META-INF/MANIFEST.MF entry Class-Path:
BEA_WLS_SAMPLE_ADK.jar adk.jar bea.jar log4j.jar
logtoolkit.jar xcci.jar xmltoolkit.jar)
BEA_WLS_SAMPLE_ADK.rar (Resource Adapter
with META-INF/MANIFEST.MF entry Class-Path:
BEA_WLS_SAMPLE_ADK.jar adk.jar bea.jar log4j.jar
logtoolkit.jar xcci.jar xmltoolkit.jar)
log4j.jar (shared .jar between .war and .rar)
logtoolkit.jar (shared .jar between .war and .rar)
xcci.jar (shared .jar between .war and .rar)
xmltoolkit.jar (shared .jar between .war and .rar)
Notice that neither the .rar nor .war files include any shared .jar files inside of them; rather, they both refer to the shared .jar files off the root of the .ear.
For more information on using .ear files to deploy adapters, see Deploying Adapters.
|
|
|
|
|
|
Copyright © 2002 BEA Systems, Inc. All rights reserved.
|