Let us explore the steps to develop adapters before looking into the details of a socket adapter.
For each adapter to be used in your enterprise, you must provide an interface to the services and events that it provides. You can create such an interface in either of two ways: by defining application views or by writing custom code.
The various application integration components participate in the following high-level lifecycle:
1. Define the overall integration solution.
This includes defining what EIS and adapters are used and what services and events are implemented.
2. Install and deploy the required adapters.
3. Create a WebLogic Workshop application that implements the required business processes for the integration solution.
4. Define an application view that addresses a specific business purpose. This step includes defining the required services and events and testing the application view.
5. Publish the application view to the WebLogic Workshop application.
6. Define an Application View control that provides access to application view services.
7. Integrate the Application View control into your business process.
8. Deploy your integration solution.
9. Manage your integration solution using the WebLogic Integration Administration Console.
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).
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:
The request arrives at the adapter in the form of an XML document. The adapter uses the request schema associated with the service (as defined in the application view) to translate the request to the format that the EIS expects. Similarly, when the adapter receives the response back from the EIS, it uses the response schema associated with the service to translate the response to an XML document that the requesting application handles.
When you define an application view, you must configure communication parameters for it, and then add services and/or events to it. The application view’s services and events expose specific functions of the application. The communication parameters of the application view govern how the application view connects to the target EIS.
Defining an application view involves the following steps:
o Step 1: Log On to the Application Integration Design Console
o Step 2: Define the Application Context for an Application View
o Step 3: Add Folders
o Step 4: Define Application View
o Step 5: Create New or Select Existing Connection
o Step 6: Add Services and Events to the Application View
o Step 7: Perform Final Configuration
o Step 8: Test Services and Events
o Step 9: Publish Application View
While defining the application view, the UI used to define connection parameters and other adapter specific information needs to be developed as per framework defined in the BEA Adapter Development Kid (ADK). This uses custom taglibs and framework related classes.
Once you define an application view in your WebLogic Integration environment, you can deploy it on WebLogic Server and use it to implement your enterprise’s business processes. The most common way to use an application view in your enterprise’s business is by designing a business process in WebLogic Workshop. A graphical user interface (GUI) is used for designing business processes. These business processes can include application view services and events accessed through the Application View control and the Message Broker Subscription control.
A socket adapter uses Sockets (TCP) to communicate with the EIS. Our socket adapter will be modeled as a service adapter.
To start with, we use the GenerateAdapterTemplate, a command-line utility you can use to create a new adapter development tree by cloning the sample tree.
Open a command line from the WLI_HOME/adapters/utils directory and execute GenerateAdapterTemplate.cmd. Enter all the required info and this will create a plethora of files and directories along with the required ant build scripts. Execute these scripts and build the adapter.
To implement the Socket sample adapter Server Provider Interface (SPI) and meet the J2EE-compliant SPI requirements, the classes in the ADK were extended to create the following concrete classes:
Concrete class (Extends this ADK class)
The first step in implementing an SPI for the Socket sample adapter was to implement the ManagedConnectionFactory interface. A ManagedConnectionFactory supports connection pooling by providing methods for matching and creating a ManagedConnection instance. Actual sockets objects are created here in the createManagedConnection() method.
A ManagedConnection instance represents a physical connection to the underlying EIS in a managed environment. ManagedConnection objects are pooled by the application server. This class also handles house keeping operations like destroyPhysicalConnection().
The ManagedConnectionMetaData interface provides information about the underlying EIS instance associated with a ManagedConnection instance. An application server uses this information to get run-time information about a connected EIS instance.
To implement the Socket sample adapter Common Client Interface (CCI) and meet the J2EE-compliant CCI requirements, several classes in the ADK were extended to create the following concrete classes.
Concrete class (Extends this ADK class)
A Connection represents an application-level handle that is used by a client to access an underlying physical connection. The actual physical connection associated with a Connection instance is represented by a ManagedConnection instance.
The Interaction instance enables a component to execute EIS functions. An interaction instance is created from a connection and is required to maintain its association with the Connection instance. This is the class where we will make the actual call to the EIS on the socket. This class uses the getPhysicalConnection() method to get a handle to the socket that was created in the ManagedConnectionFactoryImpl class.
An InteractionSpecImpl holds properties for driving an interaction with an EIS instance. An InteractionSpec is used by an interaction to execute the specified function on an underlying EIS.
The process of creating an adapter is a long drawn one. But following these guidelines should help.