|
Oracle® Application Server Adapter Concepts
10g Release 2 (10.1.2) Part No. B14058-01 |
|
|
Oracle® Application Server Adapter Concepts
10g Release 2 (10.1.2) Part No. B14058-01 |
|
Copyright © 2004, Oracle. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.
Concepts
10g Release 2 (10.1.2)
Part No. B14058-01
November 2004
The purpose of this document is to discuss the general methodology used by Oracle to implement adapters as part of the Oracle Application Server in an enterprise that offers multiple applications deployed over multiple platforms. It is not meant to be a comprehensive and detailed discussion of all situations the user is likely to encounter when using adapters, but rather a brief introduction to the concepts and a roadmap to other more in-depth documents that address system-specific requirements.
Contents
This document contains the following topics:
|
See Also: The following books provide details on Oracle Application Server Adapter installation and use:
|
When enterprises implement an enterprise information system (EIS) by integrating diverse applications that run on different platforms, they rely on a set of adapters to ensure interoperability.
The various applications that enterprises use in their daily operations may include database, mainframe and Web interface applications, all of which run on different operating systems and are developed by different vendors. Oracle provides a suite of adapters that implement bidirectional connectivity between applications and various back-end systems and enable faster, flexible, efficient, and cost effective integration.
The benefits of using Oracle Application Server Adapters (OracleAS Adapters) include the following:
OracleAS Adapters are Java-based, and integrate with EIS-native APIs.
OracleAS Adapters perform translation between Oracle data, usually in XML format, and native EIS data formats.
GUI-based design-time tools available with OracleAS Adapters provide a standard methodology for browsing, downloading, configuring and storing the schemas that represent the EIS business objects and operations in standard formats, such as XSD and WSDL. These tools facilitate rapid change without additional coding effort.
Through its use of standards like Web Services, J2EE Connector Architecture (J2CA) and J2EE server technology, OracleAS Adapters deliver high availability and scalability to the enterprise. An OracleAS Adapter can be deployed as either a J2CA 1.0 adapter (OracleAS Adapter J2CA) or as a Web Services servlet within the OC4J container of the Oracle Application Server (OracleAS Adapter Business Services Engine).
OracleAS Adapters can be deployed in Oracle Application Server clusters.
By supporting bidirectional connectivity, OracleAS Adapters enable request-response services to EIS applications and broker event notifications.
OracleAS Adapters integrate the Oracle Application Server with EIS applications (ERP and CRM), with databases, and with messaging systems.
OracleAS Adapters integrate with Oracle Application Server Containers for J2EE (OC4J) and OracleAS Integration InterConnect (an integration broker).
Using OracleAS Adapters to connect Oracle Application Server and other systems and applications ensures that this distributed system has the advantage of inheriting many Oracle features, such as system security, scalability, persistence, guaranteed delivery, transaction support, connection pooling when using OC4J, portability, NLS support, security differentiation, and pathname persistence. See the "Certification Matrix" in the Oracle Application Server Adapters Installation Guide.
Oracle Application Server ships with these adapter types:
Oracle technology adapters are available with every Oracle Application Server installation; they provide connectivity with data stores, messaging middleware, various transport protocols and Oracle Applications such as Oracle Financials and other components of the Oracle E-Business Suite. These adapters are for HTTP, FTP, Advanced Queuing, databases, and Files.
Oracle application adapters integrate with packaged applications such as SAP, Siebel, PeopleSoft and J.D. Edwards.
This document will focus on application adapters.
OracleAS Adapter offers three primary services: request-response service, event notification service, and metadata extraction.
The OracleAS Adapter supports the synchronous request-response communication paradigm, also known as an outbound interaction in J2CA terminology. It receives requests from adapter clients, translates these requests into the data format native to the EIS, and invokes the appropriate method on the EIS application. The OracleAS Adapter also returns the EIS response to the client application, after performing reverse translation. See Figure 1 for an illustration of the request-response service.
The request-response service can be used to create, delete, update and query EIS data, and also to invoke EIS workflows and transactions. For example, OC4J application clients can use the OracleAS Adapter to create a new customer within PeopleSoft's HRMS Warehouse system.
The OracleAS Adapter also supports event-notification, an asynchronous communication paradigm, known as an inbound interaction in J2CA terminology. Figure 2 illustrates the event notification service.
Event notification has two forms:
When listening for events, the OracleAS Adapter registers as a listener for the EIS application that is configured to push events.
Alternatively, the adapter polls the EIS, usually through an interface or a staging database table, for events of interest to the client application.
These events might be generated within the EIS application when a transaction completes successfully, or they may be nontransactional events initiated by the EIS application. Where supported by the EIS application, the OracleAS Adapter offers guaranteed event delivery. OC4J is currently based on J2CA 1.0, which does not support event notification.
The OracleAS Adapter metadata definition consists of the information on the EIS connection and the schemas for the EIS business objects and business services. The OracleAS Adapter has a design-time component for browsing and storing the metadata, and a runtime component for executing its services.
The OracleAS Adapter repository stores the metadata and makes it available at runtime. The metadata is expressed in XSD for the OracleAS Adapter J2CA, and as WSDL and DTDs for OracleAS Adapter Business Services Engine.
The OracleAS Adapter consists of OracleAS Adapter Application Explorer, a repository, EIS-specific libraries, channel and port. Figure 3 illustrates this structure.
OracleAS Adapter Application Explorer is a Swing-based design-time tool for configuring the OracleAS Adapter. Configuration consists of defining the EIS connection, browsing the EIS schemas, and exposing these schemas as adapter services. The OracleAS Adapter Application Explorer is bundled with plug-ins for browsing EIS-specific metadata.
You can use the OracleAS Adapter Application Explorer to create repository projects for either the OracleAS Adapter J2CA or OracleAS Adapter Business Services Engine. Each repository project may consist of multiple EIS connections. The schemas are represented as either XSD for the OracleAS Adapter J2CA interface, or as a WSDL with SOAP binding and DTDs for the OracleAS Adapter Business Services Engine interface. The OracleAS Adapter repository stores these configurations using the client API.
The OracleAS Adapter stores configuration information either in a file or in a database repository.
The file repository is local for the adapter installation home of the OracleAS Adapter deployed as a J2CA 1.0 Resource Adapter.
The file repository is local for the J2EE-OC4J Servlet deployment home when the OracleAS Adapter is deployed as an OracleAS Web Services servlet, which must be running during both design-time and runtime.
The EIS-specific adapter libraries interface with the various EIS applications and implement the APIs native to the EIS. For example, the SAP adapter library implements the RFC API to talk to the SAP R/3 application, while the Siebel adapter library implements the Siebel Java Data Bean interface to talk to the Siebel application.
The Channel is the OracleAS Adapter component that receives events in real time from the EIS application. The channel component can be a File Reader, an HTTP listener, a TCP/IP listener, or an FTP listener, and it is always EIS-specific. For example:
The Channel component is an HTTP listener for Siebel. The user implements a Siebel workflow to push a Siebel event through the Siebel HTTP adapter to an HTTP listener. The adapter for Siebel must be registered as an HTTP listener using Siebel Tools in order to receive notifications for this event.
The Channel component is an RFC Server for SAP R/3. The user must register the adapter for SAP R/3 as an RFC server using the SAP GUI.
The OracleAS Adapter supports multiple channels for a particular EIS. For example, the OracleAS Adapter for Siebel supports File listener and MQSeries listener channel components as well as the HTTP listener channel component for receiving events in real time. This allows the user to choose the channel component based on deployment needs.
OracleAS Integration products, such as OracleAS Integration InterConnect, use OracleAS Adapters to communicate with EIS environments. This is illustrated in Figure 4, "OracleAS Adapter Integration". This section describes the components necessary for this type of integration, and centers on the OC4J Container and OracleAS Integration InterConnect.
Oracle Application Server Containers for J2EE, OC4J, is the core J2EE runtime component of Oracle Application Server. All application clients run within the OC4J environment. The OracleAS Adapters for packaged applications are deployed as a J2CA 1.0 Resource Adapter (RA) within the OC4J container. The adapters run in managed mode within the OC4J container under the request-response paradigm. The contract between the OC4J client application and the Resource Adapter is defined by the Common Client Interface, CCI. The contract between the OC4J container and the Resource Adapter is defined by the Service Provider Interface, SPI. The SPI API addresses connection, transaction and security management. The system handles these contracts automatically, and they are hidden from the application developer.
Connection management enables application components to connect to an EIS, and leverages the rich connection pooling support of the OC4J container. Connection management provides scalability to an EIS that supports a large number of simultaneous component connections.
Transaction management enables an application server to manage transactions across multiple resource managers. The majority of adapters support only single-phase commit local transactions, not two-phase commit XA transactions.
Security management provides authentication, authorization, and secure communication between the J2EE server and the EIS. OC4J supports container-managed and component-managed sign-on protocols. In the former, the Oracle Application Server forwards security credentials to the EIS application; in the latter, this is managed by the J2CA adapter.
|
See Also: Chapter 8, "J2EE Connector Architecture" in Oracle Application Server Containers for J2EE Services Guide for further information on transaction, connection and security management services provided by the OC4J container. |
OracleAS Integration InterConnect
OracleAS Integration InterConnect integrates Oracle applications with third-party applications or third-party messaging middleware. This integration can be deployed within an enterprise, or across enterprise boundaries through the Internet. OracleAS Integration InterConnect is designed as a hub and spoke system, where the spokes function as OracleAS Integration InterConnect adapters that access other applications and systems, and the hub is the OracleAS Integration InterConnect repository server, a standalone Java application. The OracleAS Integration InterConnect repository is a database that stores the design-time metadata definition.
|
See Also: "Unique Integration Methodology" section in Chapter 1, "Getting Started with OracleAS Integration InterConnect" of Oracle Application Server Integration InterConnect User's Guide. |
The OracleAS Adapter Business Services Engine integrates with OracleAS Integration InterConnect products and enables access to packaged applications. It helps businesses to integrate heterogeneous information systems faster, more cost effectively, and more uniformly by implementing standards that provide simple and consistent connections between these systems over the Internet. Business functions and data can be exposed as a Web Service, and tools on other platforms can use these services with minimal effort. The OracleAS Adapter Business Services Engine supports the following standards:
A Simple Object Access Protocol (SOAP) request makes a Web Service perform a task.
Web Services Definition Language (WSDL) describes all of the SOAP calls that can be used for a set of services.
A Universal Description, Discovery, and Integration (UDDI) server acts as a directory of relevant Web Services and the WSDL that describes them.
No programming knowledge is necessary to generate these services, which reuse functionality from ERP or CRM systems, legacy applications, and diverse data sources.
The OracleAS Adapter Business Services Engine is deployed as a servlet within the OC4J container of the Oracle Application Server, and it depends on the OC4J container for scalability and high availability. The Swing-based design-time tool, OracleAS Adapter Application Explorer, is used for browsing the EIS metadata that it passes to the OracleAS Adapter Business Services Engine. The OracleAS Adapter creates the WSDLs for the various adapter services, and stores the WSDL schemas in an XML-based file repository or an Oracle Database repository. The OracleAS Adapter Business Services Engine must be running during both design and at runtime.
The OracleAS Integration InterConnect EIS Adapter Plugin integrates the OracleAS Web Services adapter with OracleAS Integration InterConnect by translating XML payloads between XSD and DTD formats, respectively.
The OracleAS Integration InterConnect product supports four messaging paradigms: implemented procedures (request-response service), subscribe (one-way request service), publish (event service), and invoked procedure (OracleAS Integration InterConnect is the server in this case and EIS is the client making the request).
The OracleAS Integration InterConnect EIS Adapter Plugin supports only the first three messaging paradigms. It uses SOAP for implemented procedure and subscription and RMI for the request-response and event notification services.
The following components are used in integrating with OracleAS Integration InterConnect:
OracleAS Adapter Business Services Engine, the OracleAS Adapter deployed as a Web Services servlet within OC4J
OracleAS Integration InterConnect EIS Adapter Plugin to talk to the OracleAS Adapter Business Services Engine
OracleAS Integration InterConnect deployment
Oracle iStudio
OracleAS Adapter Application Explorer
During design time, the OracleAS Adapter Application Explorer configures the OracleAS Web Services adapter. In addition to the standard WSDL schemas, the OracleAS Web Services adapter generates DTD schemas and stores them locally in a file system specified by the user. The OracleAS Integration InterConnect iStudio tool includes a DTD browser plugin, and can be used to convert DTD schemas to the native OracleAS Integration InterConnect schema and store these in the OracleAS Integration InterConnect repository. Figure 5 illustrates the architecture of OracleAS Integration InterConnect integration at design time. More specifically, the following steps complete configuration for Request-Response and Event Notification scenarios at design time.
Request-Response; Implemented Procedures and Subscribe
Configure the OracleAS Adapter Business Services Engine for request-response service using the Oracle Application Explorer. The WSDL schemas are stored in the OracleAS Adapter repository and the DTD schemas are saved to a local file system.
Use OracleAS Integration InterConnect iStudio DTD browser to consume the DTD schemas generated in the previous step and store the configuration information in the OracleAS Integration InterConnect repository.
Event Notification; Publish
Configure the OracleAS Adapter Business Services Engine for event services, including the RMI port definition, using the Oracle Application Explorer. The WSDL schemas are stored in the Oracle Adapter repository and the DTD schemas are saved to a local file system.
Use OracleAS Integration InterConnect iStudio DTD browser to consume the DTD schemas generated in the previous step and store the configuration information in the OracleAS Integration InterConnect repository.
Figure 5 OracleAS Integration InterConnect at Design Time
The OracleAS Integration InterConnect EIS Adapter Plugin loads the metadata from the OracleAS Integration InterConnect repository using its own API. The OracleAS Integration InterConnect EIS Adapter Plugin interfaces with the EIS application and translates the data between EIS native format and the Application View, a format recognized by OracleAS Integration InterConnect. This interaction is illustrated in Figure 6. More specifically, the following steps describe runtime behavior for Request-Response and Event Notification scenarios.
Request-Response; Implemented Procedures and Subscribe
The OracleAS Integration InterConnect hub hands the request to the OracleAS Integration InterConnect EIS Adapter Plugin, which creates a SOAP client request and makes a call to the OracleAS Adapter Business Services Engine. The adapter invokes the EIS and forwards the EIS response as a SOAP response back to the OracleAS Integration InterConnect EIS Adapter Plugin, which in its turn translates the SOAP response to appropriate OracleAS Integration InterConnect format and forwards it on to the OracleAS Integration InterConnect hub.
Event Notification; Publish
The OracleAS Adapter Business Services Engine receives an EIS event notification through the Channel component. It then forwards this event as an RMI request to the OracleAS Integration InterConnect EIS Adapter Plugin, which acts as an RMI server and consumes this event, translates it to the appropriate OracleAS Integration InterConnect format and forwards it to the OracleAS Integration InterConnect hub.
The OracleAS Adapter J2CA supports only synchronous outbound interactions, such as the request-response service, not event notification. At runtime, an EJB, a servlet or a Java application client communicates with the OracleAS Adapter J2CA through the CCI API. The OracleAS Adapter J2CA is deployed within OC4J as a standard J2CA 1.0 Resource Adapter, and runs in managed mode within the OC4J container. Like the OracleAS Adapter Business Services Engine, it is configured using the OracleAS Adapter Application Explorer. The OracleAS Adapter J2CA is in practice a J2CA wrapper around the adapter SDK, as previously illustrated in Figure 3.
An OracleAS Adapter J2CA is universal; its repository project can contain more than one EIS connection and it can talk to more than one EIS type. The repository project can be in a file or database repository; its ra.xml file contains the repository connection parameters and the repository project name. Multiple managed connection factories can be specified in the oc4j-ra.xml file generated by OC4J, each pointing to a different repository project and JNDI name. To connect to a particular EIS, the J2CA CCI ConnectionSpec class is used to specify the EIS type and the EIS connection name.
The basic outline for using CCI with the OracleAS Adapter J2CA consists of the following steps:
Look up a ConnectionFactory for the OracleAS Adapter J2CA.
Create a ConnectionSpec object that uses the EIS type and EIS connection name.
Create a Connection to the EIS using the ConnectionFactory and ConnectionSpec objects.
Create an Interaction based on the request and response XSD schemas.
Call the execute() method on the Interaction.
After the required interactions have been processed, close the Interaction and Connection objects.
The OC4J provides connection pooling for the OracleAS Adapter J2CA. The OracleAS Adapter J2CA connection represents the underlying network connection to the EIS. This allows the reuse of connections to the resource adapter between multiple J2EE components, such as EJBs and servlets. The pool parameters are defined by the oc4j-ra.xml file that contains the following details:
The minConnection parameter specifies the minimum number of connections that can be created for a particular ManagedConnectionFactory class during start up. This parameter is not used by the OracleAS Adapter J2CA.
The maxConnections value specifies the maximum number of EIS concurrent connections that can be pooled for a particular ManagedConnectionFactory class.
The OC4J container can be configured either for dynamic, fixed, or fixed-wait connection. The OracleAS Adapter J2CA throws a CCI ResourceException if a connection fails. Where applicable and supported, the EIS-specific error message is embedded in the ResourceException.
|
See Also: Chapter 8, "J2EE Connector Architecture" in Oracle Application Server Containers for J2EE Services Guide for further information on quality of service contracts. |
The OracleAS Adapter J2CA supports local transactions with one-phase commit protocols, but has no support for extended transactions with two-phase commit. Nevertheless, it can participate in OC4J last-resource commit optimization, provided it is the only non-XA resource. The OC4J transaction coordinator throws an exception when the user attempts to use the OracleAS Adapter J2CA as an XA resource in two-phase commit transactions.
The OracleAS Adapter J2CA supports both component-managed and container-managed sign-on.
In the component managed sign-on, the J2CA client (EJB, servlet, or application client) authenticates with the EIS without relying on the OC4J container. The res-auth parameter in the deployment descriptor of the J2CA client should be set to Application. The security credentials, such as user name and password, are specified in the ConnectionSpec when creating the EIS Connection object.
In the container-managed sign-on, these security credentials do not need to be passed in the ConnectionSpec object when creating the EIS Connection object.
Our goal is to make Oracle products, services, and supporting documentation accessible, with good usability, to the disabled community. To that end, our documentation includes features that make information available to users of assistive technology. This documentation is available in HTML format, and contains markup to facilitate access by the disabled community. Standards will continue to evolve over time, and Oracle is actively engaged with other market-leading technology vendors to address technical obstacles so that our documentation can be accessible to all of our customers. For additional information, visit the Oracle Accessibility Program Web site at
http://www.oracle.com/accessibility/
Accessibility of Links to External Web Sites in Documentation
This documentation may contain links to Web sites of other companies or organizations that Oracle does not own or control. Oracle neither evaluates nor makes any representations regarding the accessibility of these Web sites.
