|
|
|
|
|
|
Concepts
This section describes some of the more important concepts with which you should familiarize yourself 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:
Runtime vs. Designtime
Adapter activity falls within one of two conceptual entities: runtime and designtime. Runtime refers to functionality that occurs when adapters execute their processes. Designtime refers to the adapter user's implementation of an application view; in essence, designtime is the act of creating, deploying, and testing an application view.
Runtime and designtime 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. Runtime and designtime are discussed in greater detail below.
Note: In this document, the spelling of "designtime" and "runtime" will vary depending upon usage. They are alternately spelled "designtime" or "runtime" (noun) and "design-time" or "run-time" (adjective).
Run-time Framework
The runtime framework is the set of tools you will use to develop event and service adapters. To support event adapter development, the runtime framework provides a basic, extensible event generator. For service adapter development, the runtime framework provides a complete J2EE-compliant adapter.
The classes supplied by the runtime framework provide the following benefits:
In addition, the runtime 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.
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 the BEA WebLogic Application Integration Product Overview.
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 ADK's 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 internationalized 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. For the Application Integration product, the log toolkit is provided in the logtoolkit.jar file.
For information on using the logging toolkit, see The ADK 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 runtime.
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:
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|