 | Level: Introductory Michael Beisiegel, Senior Technical Staff Member, IBM Toronto Lab
Gary Bist, Technical Writer, IBM Toronto Lab
Piotr Przybylski, Advisory Staff Member, IBM Toronto Lab
18 Jan 2002 Tools make the difference when you want to apply architecture to application development. Tools turn architecture into products. In this article, you'll see the practical aspects of J2EE Connector Architecture (JCA) by using JCA-based tools from IBM to build, test, deploy, and run a J2EE EJB application.
© 2001 International Business Machines Corporation. All rights reserved. Introduction 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
information (res_ref, res_type,
and 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.
Reap time
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.
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.
Connection timeout
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 connections
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 connections
Minimum number of managed connections that should be maintained. If this
number is reached, the garbage collector will not discard any managed connections.
Pool name
Name used by the pool manager to group managed connections created by different
managed connection factories.
Subpool name
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
name (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
server.
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.
Future directions 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.
Conclusion 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.
Acknowledgments We would like to thank Mike Andrea, Sandy Minocha, Kevin Sutter,
and Leigh Davidson for their help with this article. Top of page
Resources - 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.
About the authors | | | Michael Beisiegel is a Senior Technical Staff Member
working for the architecture team of IBM's Application and Integration Middleware
(AIM) Division in Somers NY. He is responsible for IBM's connector/adapter run
time and tools architecture. He is IBM's expert on the J2EE Connector Architecture
effort. He joined IBM in 1989 and began working for the 390 software development
organization at the IBM Lab in Boeblingen, Germany. Later, he took an assignment
(1998-2000) to lead the development effort of the VisualAge for Java Enterprise
Access Builder (EAB) and the Common Connector Framework (CCF) at the IBM Toronto
Lab. He received his M.S. (1989) in Electrical Engineering from University of
Kaiserslautern, Germany. You can reach Michael
at mbgl@us.ibm.com. |
| | | Gary Bist is a technical writer at the IBM Toronto
Lab. You can reach Gary at bist@ca.ibm.com. |
| | | Piotr Przybylski is an Advisory Staff Member at the
IBM Toronto Lab working on connector architecture and tools. He joined IBM in
1996, working on tools and libraries to access enterprise applications from
Java. He has contributed to several releases of the VisualAge for Java Enterprise
Access Builder (EAB) and Common Connector Framework (CCF). He received his B.S.
in Computer Science from Concordia University in Montreal in 1994 and his M.S.
in Computer Science from University of Waterloo in 1996. You can reach Piotr
at piotrp@ca.ibm.com. |
Rate this page
| |
