© 2001 International Business Machines Corporation. All rights reserved.
The following article is an excerpt from J2EE Connector Architecture and Enterprise Application Integration by Rahul Sharma, Beth Stearns, and Tony Ng. Addison-Wesley, 2001.
Tools make the difference when you want to apply architecture to application development. Tools turn architecture into products. In this section, you will see the practical aspects of the J2EE Connector Architecture (JCA) by using JCA-based tools from IBM to build, test, deploy, and run a J2EE enterprise bean application. Let's begin with a brief overview of the Enterprise Access Builder (EAB) feature in IBM's VisualAge® for JavaTM, Enterprise Edition, Version 4.0. EAB contains the JCA-based tools that we will use to build our application.
Enterprise Access Builder (EAB) 101
To an application developer, a connector is a set of related classes that lets an application access business logic and data in an Enterprise Information System (EIS). A simple analogy is to think of these connector classes collectively as a pipeline that allows you to flow request and response data between your application and the EIS.
In Figure 1 below, the connector classes are between the application classes and the server with the EIS, in this case a CICS® transaction server. In VisualAge for Java, the connector classes are subset into the EAB classes, which interact with your application, and the specific connector classes, in this case the CICS connector classes. When we say EAB classes, we mean the classes generated by using the EAB tools and EAB run-time libraries. Note that an application never directly accesses specific connector classes.
Figure 1. Application, connector, and EIS relationship
This separation means that once you are familiar with the EAB tools, you can develop an application in an identical way for any connector supported by VisualAge for Java, since your application only interacts with the EAB classes. The application that we will develop accesses CICS transactions. But using the same EAB tools we could write an application to access IMSTM transactions, MQSeries® messaging queues, PeopleSoft ERP data, Oracle applications and so on. (For a list of the connectors that come with the product, see Connectors in VisualAge for Java.) Using EAB, then, is a standard way to develop any connector-related application.
JCA application development process
What is the JCA application development process? How does EAB fit into it? Although there are no absolute rules for developing a JCA-based application, Figure 2 below shows a process that many developers using EAB have found effective when creating an application. It begins by developing the application in VisualAge for Java. By developing, we mean using the EAB tools to generate code that can access an EIS through the JCA connector and be called by your application. Once the code is generated, another tool in VisualAge for Java is used to test it. The WebSphere® Test Environment emulates the server, in this case, the WebSphere Application Server.
Testing a JCA-based application before you deploy it is a very good idea. Testing lets you address any problems in your application while still in the development environment. Remember that deployment of an application and setup of that application on a server takes time. You do not want to find errors in your application after you have invested time in deployment because then you must return to the development environment, fix the problems, and redeploy until you get it right. Those who have painfully experienced redeployment will find the WebSphere Test Environment a valuable tool.
Figure 2. JCA application development process
After testing, comes deployment of the application. At this point, you are switching from a development environment to a production environment. How you use your deployed application varies, of course, according to your needs. Any application, however, would need to install the run-time resource adapter at the application server. The run-time resource adapter is packaged in a RAR file. RAR means Resource Adapter Archive file. It contains a deployment descriptor, help files, and the interface, implementation and helper classes of the resource adapter. If you were to develop a Web service from an enterprise bean, as seen in our diagram, the final step would be to access it over the Web.
Overview of the application
Let's walk through how we will build our application. We will follow the standard JCA application development process mentioned previously to develop our application. We will use VisualAge for Java, Enterprise Edition, Version 4.0; WebSphere Application Server, Advanced Edition, Version 4.0; the development version of the CICS ECI connector included in VisualAge for Java; and the CICS ECI connector RAR file included with the CICS Transaction Gateway, Version 4.0. We will develop and run our application on Windows© 2000 Professional. Our application will call a CICS transaction that requires as input a customer number and that will return the name of the customer that matches the customer number. Obviously, it is a simple application, but it will demonstrate the heart of the JCA architecture, which is to interact with EIS systems as if the data on the EIS systems is available in the local application.
We will use the EAB session bean tool to create our enterprise bean. The tool first defines the connection information; that is, the type of connection and configuration. In the next stage, it imports a COBOL file, which defines the input and output data structure for the CICS transaction accessed.
Then records representing COBOL structures are generated in the application; that is, input and output records. The tool handles code generation, data type conversion, "endianess" issues, and optimization. The code generated will, at run time, handle the marshalling and unmarshalling of the different data representation formats used by the application and EIS system. Afterwards, we will use a related editing tool, which can be automatically invoked after record generation, to further specify connection information necessary for the Java Naming and Directory InterfaceTM (JNDI) at run time. With this information, a factory object at run time can generate a connection when needed by the application.
To test our application within VisualAge for Java, that is, before deployment, we will use the WebSphere Test Environment. As its name implies, it emulates an application server within a development environment. Once we know our application works, we will switch to the production environment. We will add the CICS ECI RAR file to the application server. Then we will deploy the application to the application server using another tool. Finally, we will run our application again from the application server.
We will show you all of the above as we step you through our tools. Note that VisualAge for Java comes with similar step-by-step samples that let you try out these JCA-based tools in a safe environment.
Using the EAB session bean tool
Let's begin. Launch the EAB session bean tool from within VisualAge for Java's EJB Development Environment. This environment is an IDE for developing enterprise beans. In the EJB Development Environment, create an EJB group, in order to contain an enterprise bean, and then launch the tool. An initial page gives you the option of migrating a session bean; that is, if you had an existing session bean created in the preceding IBM Common Connector Framework (CCF) architecture, you could migrate it to the JCA architecture at this point. On the first page, shown in Figure 3 below, enter the basic information such as the project, package and the name of the session bean. Also, enter the connection information.
Figure 3. Initial information for the EAB session bean
The connection information is the critical information at
this point. In particular, the choice of a managed connection factory and the
type of managed connection factory affects the subsequent properties that appear
in the tool. The property sheet for connection information, which opens when
you click Edit, is shown in Figure 4 below. You can fill in all the connection
properties immediately or wait until after the code is generated and use the
session bean editor tool. All of the properties are documented in the online
help, if you happen to get lost. The key connection properties are the JNDI-related
res_auth) and the type of managed connection
factory, and its properties specifying the address if the CICS gateway and the
CICS server name.
Figure 4. Connection properties
Eventually you will reach the method page. A method for an EAB session bean is comprised of interaction properties and an input and an output record. Starting with the input record, the session bean tool lets you import an existing COBOL structure to create your input record bean. If you import a COBOL file, it will lead to the page shown in Figure 5 below. In the foreground is the COBOL file.
Figure 5. Importing the COBOL source structure
In the following page, select an option called Generate as
javax.resource.cci.Record interface. This option
means that your input and output record beans will comply with JCA. The other
options shown on that page can impact the performance of your session bean.
The performance implications of these options are discussed in "Connectors in
J2EE" (see Resources). In most cases, the default
options offer the best performance. You are also given the opportunity to change
critical machine-to-machine properties such as code page and endianness.
Completing similar fields generates an output record. The completed input and output record beans, as specified in the method page, are shown in Figure 6 below. The invocation of the getCustomerInfo method would result in the customer number being passed from the application to the input record and then to the EIS. Then customer information would be returned from the EIS in the output record and then to the application. The function called has to be expressed in terms understood by the EIS. In the connector architecture, you do this using an InteractionSpec class. In our application, we specified an ECIInteractionSpec class. The following figure shows how to specify the class.
Figure 6. Method page with interaction to EIS properties
At this point, you generate the session bean. If you had selected to edit the session bean when finished in the first page (see Figure 3 above), you automatically launch the EAB Session Bean editor after generation
Using the session bean editor
Application developers greet visual tools with suspicion. Exactly what is going on under the covers? IBM has tried to strike a balance between those who want a fully automatic code generator and those who want more control over the generated code. Editors are provided so that developers can make modifications to the code after generation. The EAB Session Bean editor, for example, lets you edit the generated session bean. The information is grouped into connection information and methods (input and output records). Review the values you entered when building the session bean, make any changes you wish, and save the session bean. Figure 7 below shows the session bean editor. Now it is time to test, while still in the development stage, that your enterprise bean can in fact get the data expected from the EIS.
Figure 7. EAB session bean editor with connection properties
Testing the application in the WebSphere Test Environment
Once you have built your application with the EAB tools, you need to test it while still in the development environment. As indicated earlier, it's better to verify in the development environment that you can get your data from the EIS than to deploy your application into the production environment and then find out it does not work. IBM created the WebSphere Test Environment for this very reason. As its name implies, it emulates the application server within the VisualAge for Java IDE. Testing does not need to be elaborate, but it should verify that you can get the expected values from the EIS. Also, a test should check for error conditions, such as incorrect input, or failure at the server end, such as failure of a gateway.
Begin in the EJB Development Environment where your previous tool will have created your enterprise bean. Figure 8 below shows the customer enterprise bean we created in the enterprise beans pane. Note that the method, getCustomerInfo, is in the Members pane. Begin to test your enterprise bean by adding that method to the EJB remote interface. Then generate your deployed code, which creates code similar to the code you would actually create if you really had deployed an application to an application server. Then, while still in the EJB Development Environment, generate an access bean for your enterprise bean. The access bean is a simplified client interface to an enterprise bean.
Figure 8. Testing the enterprise bean in the EJB Development Environment
Once everything is ready in the EJB Development Environment, launch the WebSphere Test Environment. This run-time environment emulates the actual application server from within the VisualAge for Java IDE. Figure 9 below shows the console window for the test environment. Your enterprise bean needs the persistent name server to be up and running, as is shown. The persistent name server is necessary to support applications using JNDI. The WebSphere Test Environment has its own database and so it can emulate persistence. Add your enterprise bean to the server configuration, just as you would add an enterprise bean to a regular application server. Optionally, you may wish to set an option that lets you step through code a line at a time. This debugging feature can be extremely helpful when you do experience a failure and need to pinpoint precisely the line that caused it.
Figure 9. WebSphere Test Environment with the Persistent Name Server running
Finally, write some additional simple client code, which creates an input record. In our case, we passed a customer number to the enterprise session bean running in the WebSphere Test Environment. Then, capture the returning output from the CICS server and print the result to the console. A fragment of code for the client bean we created is shown below. The point of the test is to show that your application can access the CICS Transaction Server and return correct values, in this case, the customer's first name.
Context initial = new InitialContext(); Object objref = initial.lookup("MyCustomerBean"); CustomerBeanHome home = (CustomerBeanHome)PortableRemoteObject.narrow(objref, CustomerBeanHome.class); CustomerBean customer = home.create(); // Create an input record CustomerInfoRecord input = new CustomerInfoRecord(); // Pass customer number as input input.setCustomerNumber("12345"); // Get output record CustomerInfoRecord output = customer.getCustomerInfo(input); // Print the first name of the customer System.err.println(output.getFirstName());
Moving your application to the WebSphere Application Server
Once you have developed and tested your application, it is time to move from the development environment to the production environment and put the application onto an application server. Deployment is a two-stage process: first, deploying the RAR file and setting up optimal run-time values at the application server, and second, deploying the application itself.
When deploying the application, you need to export a Java archive file (JAR file) containing the application and the libraries the application accesses. Exporting a JAR file is handled through the EJB Development Environment tools. The JAR file can contain either an individual EAB session bean or a group of session beans. Include in the JAR file all the libraries used by the exported beans that are not provided by the WebSphere Application Server. For example, you will need to include in the archive the generated records representing the COBOL copybooks but not the CICS ECI connector classes.
Deploying the RAR file
A run-time JCA resource adapter is shipped in a Resource Adapter Archive (RAR) file. You need to make that resource adapter accessible to the WebSphere instance running the application. Deployment of the RAR file into WebSphere is done using the WebSphere Administrative Console. From the console menu, select an option to add a J2C resource adapter. Then browse the file system and locate the RAR file. Once the file contents are read, the administrative console displays the properties of the resource adapter as defined by its deployment descriptor. The XML deployment descriptor provides information about the service that the resource adapter is providing, with details such as the properties descriptions and their default values. Figure 10 shows the list of resource adapter properties as described in its XML deployment descriptor.
Figure 10. Resource Adapter properties
You can also view additional information besides the configurable
properties. For example, you can look at version numbers. These numbers tell
you the specification level of the connector architecture and the version of
the EIS necessary for communication. Other information tells you the authentication
mechanism supported. More instructions concerning the libraries used by the
connector are found in the
HowTo.html file contained
in the RAR file.
The next step is to create the instance of the JCA connection factory and configure its properties. The connection factory, as its name implies, provides connections to the EIS. From the menu, select Create J2C Connection Factory and the administrative console tool creates an editable properties set associated with the particular connection factory instance. Specify all the information needed by the resource adapter to connect to the particular instance of the EIS. For the CICS ECI connector, specify at least the ServerName and ConnectionURL properties that determined the CICS server to connect to and the address of the CICS transaction gateway, respectively. These values determine the server and gateway that will be accessed through all the connections created by this instance of the connection factory. The resource adapter documentation provides the details of these two properties and all the other properties.
Next, you can specify the JNDI lookup name, instead of the provided default name, under which the new connection factory instance will be available to the components, as shown in Figure 11 below. The components use the JNDI lookup name to retrieve the instance of the connection factory. The instance is used, in turn, to create a connection to the EIS.
Figure 11. Specifying the JNDI lookup name of the connection factory
Specifying the connection pooling properties
The last step in the deployment of the connection factory instance is to specify the management properties to be used when pooling the physical connections to the EIS. Connection pooling can significantly improve performance, so these values deserve some attention. Typically, a system administrator sets up the values of the properties based on the system requirements, load and availability as shown in Figure 12 below. The properties that can be specified include the following.
Interval, in seconds, between runs of the garbage collector. Garbage collection can be disabled by setting Reap Time or Unused Timeout to the default value of 0. The garbage collector discards all connections that have been unused for the time specified by Unused Timeout.
Interval, in milliseconds, after which the unused connection is discarded. Setting this value to the default value of 0 disables the garbage collector.
Interval, in milliseconds, after which a ResourceAllocationException is thrown if the maximum number of connections has been reached. If Connection Timeout is set to the default value of 0, the pool manager waits indefinitely until a connection can be allocated; that is, until the number of connections falls below the maximum number of connections or a connection becomes available for reuse.
Maximum number of connections that can be created by a particular managed connection factory instance. Once this number is reached, no new connections are created and the requester waits or a ResourceAllocationException is thrown. If Maximum Connections is set to the default of 0, the number of connections can grow indefinitely.
Minimum number of managed connections that should be maintained. If this number is reached, the garbage collector will not discard any managed connections.
Name used by the pool manager to group managed connections created by different managed connection factories.
Name used by the pool manager to further subgroup pools of managed connections within a particular pool.
Figure 12. Connection pooling values
Assembling and deploying the application onto the WebSphere Application Server
The first step in assembling and deploying the application is to create the Enterprise Application Archive (EAR file) from the JAR file exported from the development environment. At this time, you can also add Web components such as JSPsTM or HTML files to your EAR file. Using the WebSphere Application Assembly Tool, provide the name for a new EAR file and the location of the JAR file with the application code. Look at the deployment descriptor for your application. You can also modify the deployment descriptor at this point too. Figure 13 below shows the resource references section of the deployment descriptor that describes the resource adapter used by an application.
Figure 13. Resource reference section of the deployment descriptor
The EAR file created by the Application Assembly Tool can now be deployed into the WebSphere Application Server. Using the Administrative Client tool, the Install Enterprise Application wizard will guide you through the steps necessary to deploy your application. Select the WebSphere server, provide your application name, and, finally, add the location of your EAR file. Next, the wizard will take you through several panels, allowing you to specify deployment options for the application. One option, mapping of the resource references to resources, is particularly helpful.
When you create your application, you specify a resource reference
res_ref_name, see Figure 4 above). It is a name used by the application
to look up the instance of the connection factory in the JNDI context at run
time. When the application is deployed, the value of the res-ref-name retrieved
from the deployment descriptor overrides the value you specified during creation
of your application. This allows the deployer, by modifying the deployment descriptor,
to set the lookup name to the value specific to the server on which the application
is deployed. In WebSphere, this can be achieved even easier. The deployment
tool lets you map the
res_ref_name specified in your application to the resource
name on the server without requiring you to modify the deployment descriptor.
Figure 14 below shows the page that lets you perform the mapping operation between
the resource reference of the application and the resource defined on the particular
Figure 14. Mapping resource references
Using the deployed application
You are finished at this point. After deployment, there are several ways to use a session bean that accesses a CICS server. You can access the session bean directly from a client program. You can also provide access to it from a servlet or use it with other enterprise bean components as a part of a more complex business application.
Accessing session beans as Web services
Setting up a session bean as a Web service is a new way of providing easy access to EIS systems. In this section we will show you how a session bean could be made available as a Web service.
The WebSphere Application Server support for the Simple Object Access Protocol (SOAP) protocol lets you expose a session bean as a Web service. Here's how to take advantage of that support with JCA-based applications today. Begin by creating a SOAP deployment descriptor specifying the particular session bean you would like to expose as Web service. The information to include in the deployment descriptor includes the service URN, the list of exposed methods, and the session bean home interface name as well as other information. The deployment descriptors fragment below shows the SOAP deployment descriptor for the session bean we created before:
<isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment" id="urn: customerinfo-service "> <isd:provider type="com.ibm.soap.providers.WASStatelessEJBProvider" scope="Application" methods="getCustomerInfo"> <isd:java class="eabtools/Customer" /> <isd:option key="FullHomeInterfaceName" value="eabtools.CustomerHome" /> <isd:option key="ContextProviderURL" value="iiop://localhost:900" /> <isd:option key="FullContextFactoryName" value="com.ibm.ejs.ns.jndi.CNInitialContextFactory" /> </isd:provider> <isd:faultListener>org.apache.soap.server.DOMFaultListener </isd:faultListener> <isd:mappings> <isd:map xmlns:x=" urn: customerinfo-service " qname="x:customer" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" javaType="eabtools.CustomerRecord" java2XMLClassName= "org.apache.soap.encoding.soapenc.BeanSerializer" xml2JavaClassName= "org.apache.soap.encoding.soapenc.BeanSerializer"/> </isd:mappings> </isd:service>
Finally, use the WebSphere tool, the SOAPEAREnabler, to add the EAR file containing the session bean to the WebSphere SOAP configuration. After WebSphere SOAP is configured with your deployment descriptor and you deploy the EAR file, the session bean connecting to the EIS can be accessed as a Web service.
To describe this service, you will need to use other IBM tools to create the corresponding Web Services Description Language (WSDL) file. The WSDL file below describes the service offered by the server.
<?xml version="1.0" encoding="UTF-8"?> <definitions name="exportejb_Service-interface" targetNamespace="http://www.exportejbservice.com/exportejb-interface" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://www.exportejbservice.com/exportejb" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <message name="IngetCustomerInfoRequest"> <part name="meth1_inType1" type="xsd:eabtools.CustomerRecord"/> </message> <message name="OutgetCustomerInfoResponse"> <part name="meth1_outType" type="xsd:eabtools.CustomerRecord"/> </message> <portType name="exportejb_Service"> <operation name="getCustomerInfo"> <input message="IngetCustomerInfoRequest"/> <output message="OutgetCustomerInfoResponse"/> </operation> </portType> <binding name="exportejb_ServiceBinding" type="exportejb_Service"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="getCustomerInfo"> <soap:operation soapAction="urn:customerinfo-service"/> <input> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:customerinfo-service" use="encoded"/> </input> <output> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:customerinfo-service" use="encoded"/> </output> </operation> </binding> <types> <xsd:schema targetNamespace="http://www.exportejbservice.com/exportejb" xmlns="http://www.w3.org/1999/XMLSchema/"> </xsd:schema> </types> </definitions>
Once you have the WSDL representation of your service, you can make the service available. Availability is achieved by sharing the WSDL file with the intended users of the service. Depending on your service type, you can either directly send the WSDL file to specific users or, if your service is to be used publicly, you can publish its description through a public registry. For example, you could publish publicly using the Universal Description, Discovery and Integration (UDDI) standard registry.
The J2EE Connector Architecture makes the J2EE platform the preferred platform for enterprise application integration. In particular, this architecture does an excellent job in making connectors a pluggable system component. It also provides a common client programming model for access to EIS resources. A common client programming model simplifies life for both programmers and tool vendors.
It is important to understand that when the connector architecture discusses EIS's, the discussion is not limited to legacy enterprise systems. We will see the JCA architecture evolve into a service connector architecture for inter and intra enterprise service invocation. Besides extending the run-time architecture itself (inbound connectivity, XML support, provider pluggability, and so forth), it is important that the next version of the JCA architecture provide pluggability into tool environments (that is, metadata, import and generation support).
IBM will continue to play a leading role in the evolution and support of the JCA connector architecture.
We have shown you how to get up and running with the JCA architecture today, using tools that are currently available. Although you could hand-code your own application to access EIS systems, the cost in development and maintenance time is enormous. For example, you would have to code your own Quality of Service (QoS) and you would need to access proprietary EIS interfaces. These tools simplify the process by generating most of the code you will need to access many EIS systems and the code generated is nonproprietary. At run time, the code will handle the marshalling and unmarshalling needed to pass data from your application to the EIS system while maintaining data integrity in all environments.
We have also shown you tools to help in the deployment of your application along with the RAR file to the application server, as you move your application from the development to the production environment. And we have shown how JCA-based applications are suited to the move to XML-based ways of exchanging data. With a few changes to some files, an application becomes a Web service, available publicly or privately for clients requesting this kind of service. Lastly, we have indicated how IBM will lead and support future JCA architecture directions.
Our section ends with a list of the current connectors that come with VisualAge for Java and some references you will find helpful. If you wish to follow IBM's commitment to the JCA architecture and to Java in general, you should bookmark IBM's WebSphere Developer Domain. Technical articles on tools and products that will support the JCA architecture are posted at this popular Web site.
Connectors in VisualAge for Java, Enterprise Edition, Version 4.0
Connector support is an ongoing story. The following list is the current set of connectors available in VisualAge for Java. As indicated earlier, you only need to know how to use the EAB tools in general in order to develop an application for any one of the following connectors.
- CICS ECI and CICS EPI Connectors - access CICS transactions.
- Host-on-Demand (HOD) Connector - accesses 3270, 5250, CICS and VT hosts.
- IMS TOC Connector - accesses IMS transactions.
- J.D. Edwards Connector - accesses Enterprise Resource Planning (ERP) data from the JD Edwards OneWorld system.
- MQSeries Connector - accesses MQSeries messaging software.
- Oracle Applications Connector - accesses data from Oracle applications.
- PeopleSoft Connector - accesses ERP data from PeopleSoft systems.
- SAP R/3 Connector - accesses the business object repository in SAP R/3.
We would like to thank Mike Andrea, Sandy Minocha, Kevin Sutter, and Leigh Davidson for their help with this article.
- John Green, Sandy Minocha, and Gary Bist. "Connectors in J2EE," WebSphere Developer Domain Technical Journal, May 2001. This article extends the subjects discussed here with material on managed and non-managed connections, connection pooling, performance recommendations, Quality of Service, JNDI, and other important areas linking connectors with J2EE.
- Richard Monson-Haefel. Enterprise JavaBeansTM. O'Reilly: 1999. Though we have built a session bean with our EAB tool and avoided a discussion on enterprise beans themselves, many developers will want a better understanding of the enterprise bean architecture behind the tool. This book will help.
- Tsutomu Oya, Bob Brown, Martin Smithson, and Tomohiro Taguchi. CCF Connectors and Database Connection Using WebSphere Advanced Edition. IBM Redbooks, 2000. This book looks at other connectors, particularly the IMS and MQSeries connectors. Though based on the previous architecture, Common Connector Framework (CCF), the material is still applicable. Remember that IBM provides migration tools to move CCF applications to J2EE.
- Joaquin Picon, Regis Coqueret, Andreas Hutfless, Gopal Indurkhya, and Martin Weiss. Design and Implement Servlets, JSPs, and EJBs for IBM WebSphere Application Server. IBM Redbooks, 2000. This book looks at enterprise beans and their cousins, servlets and JSPs, from the application server perspective. It covers critical run-time areas such as scalability, caching, and performance tradeoffs.
- Ed Rowan. Mastering Enterprise JavaBeans. John Wiley & Sons: 1999. Another classic book on enterprise bean development with many examples. Look at the new sections on J2EE.
- Irene Seelemann, Cyrus Soleimany, Richard Gregory, and Agnes Lisowska. "Working with the New ERP Connectors Available in VisualAge for Java," VisualAge Developer Domain, September 2001. This article looks at connectors in the Enterprise Resource Planning (ERP) arena. Tools, identical to the ones we have shown, are used to access data in JD Edwards, Oracle applications, and PeopleSoft ERP systems.
The product documentation for VisualAge for Java, Enterprise Edition, Version 4.0, product documentation contains many samples similar to the one shown here. In the online help, look in the Samples section under the Enterprise Access Builder. In the Concepts section, you will find topics about the JCA connector architecture, managed connections, connection pooling, JNDI, and comparisons of JCA with the older Common Connection Framework (CCF) architecture. The Tasks section has topics that show you how to migrate applications coded previously in CCF to JCA, and information on deployment. The online help topics are also available as a compilation in PDF format.