Whether you’re an IT manager or a J2EE architect, if you’re interested
in EIS connectivity you’ll be excited about the promises of JCA. What is
JCA? What are its most appealing features? What are its shortcomings? Who
are the vendors that support it? Are there any other choices so I can do
some comparison shopping? What path should I take from here? This article
sheds some light on these questions.
First I provide an overview of JCA and its features, then I discuss
the type of support provided by the application servers in the market. The
rest of this article focuses on the state of the market for JCA adapters.
Finally I offer some guidelines to help you determine if JCA is the right
solution for you.
Before JCA became available, connectivity to EIS presented a set of
common issues and needs. First, each EIS application had its own programming
interface. Talking to a different EIS application required programming against
a different set of APIs. A common set of client interfaces was needed to
simplify the programming effort. Second, the traffic to a back-end EIS application
would likely be heavy. You needed connection pooling to cut down connection-related
overhead and enhance performance. Third, the connectivity to an EIS application
was often transaction-oriented. You needed built-in transaction support to
guarantee data integrity with the least amount of programming effort. Last
but not least, security integration across EIS applications and EIS clients
was highly desirable.
If you think about these issues, they’re similar to the ones regarding
connectivity to very early databases. These problems are now resolved due
to widely adopted technologies like JDBC. As a programmer, you don’t need
to talk directly to a database but you can through the JDBC API, which is
the same across all popular databases. You can use connection pooling to
a database but you don’t need to implement it. You can use transaction support
and security integration easily since support for these features is built-in.
Wouldn’t it be great to have a similar technology for EIS applications as
well? If your answer is yes, JCA is the answer:
JCA resolves these issues by providing the following features:
• Connection pooling: An EIS connection is usually expensive
and time-consuming to create. Connection pooling enables application servers
to create and share connections to EIS applications so that expensive connection
resources can be used efficiently. JCA adapters and J2EE application servers
implement this service.
• Transaction management: This enables an EIS application
to be enlisted in the transaction context provided by an application server
so that this server can manage the transaction of the EAI system as one unit.
JCA adapters and J2EE application servers also implement this ser-
• Security: Security interface implementation allows application
servers to manage overall security without compromising an EIS-specific security
mechanism. Authentication, authorization, and secure association are the
areas covered by this interface. This is a built-in service for JCA adapters
and J2EE application servers.
• Common Client Interface: JCA also defines a user-level
programming interface referred to as the common client interface (CCI). This
interface set is optional in JCA 1.0 and allows developers of an EIS client
to connect, interact (execute a command), and get a result set from the targeted
EIS in a standard way.
JCA Support of Application Servers
JCA receives support from two places: a JCA supporting application server
and a JCA supporting adapter to an EIS application. JCA 1.0 is part of the
J2EE 1.3 specification and a J2EE 1.3–compliant application server must provide
the environment to support the required JCA features such as pooling, transaction,
and integrated security. Table 1 provides a list of commonly used application
servers and their JCA support status.
BEA’s WebLogic Server is one of the early supporters of JCA. JCA beta
support was built into WebLogic 6.0 in the beginning of 2001 when the JCA
1.0 specification was in its final draft. With about one year to mature,
the award-winning WebLogic Server is one of the best application servers
with JCA support. IBM WebSphere Application Server is another popular and
award-winning J2EE app server. Its JCA support became available around mid
2001. JBoss is another one that’s worth a special mention. If you’re under
a tight budget, you may want to look into this product. It supports JCA and
you can’t beat its price – free!
You also need a JCA-compliant adapter to connect to your back-end EIS
application. Many integration vendors have built JCA-compliant adapters.
Table 2 provides a compiled list of the vendors and the JCA adapters.
In this table, many vendors have JCA adapters for the same EIS application.
However, a JCA adapter from one vendor may support a different set of features
from the others even if it’s for the same EIS application. This is caused
by two factors. (1) Some specifications such as the CCI in JCA 1.0 is optional;
it’s up to an adapter vendor to decide whether they want to include this
feature in the current release. (2) Some of the important features for EIS
integration are not included in the current JCA specification. Adapter vendors
may decide to add additional features to enhance an adapter’s functionality.
The missing features will be discussed in more detail later.
Since these missing features from the JCA specification can be important
ones, most of the vendors surveyed here took a more practical approach and
stayed ahead of the curve. One or more additional features were added to
their adapters to provide extra functionality even though their implementations
Insevo has JCA adapters for many EIS applications including SAP, PeopleSoft,
JD Edwards, and Siebal. These adapters support an XML-based interface in
addition to the JCA-defined CCI. They support both synchronous and asynchronous
communications between a client and EIS applications. They also support bidirectional
communication instead of JCA-defined single direction communication. These
additional features make Insevo’s adapters not only suitable for application
integration but also for process integration. These additional features are
already being considered as part of the JCA 2.0 specification. So in some
sense, Insevo’s adapters are one version ahead of the JCA specification.
The additional features are not JCA compliant, but if you really need the
features can you get anything better?
RAi connectors by Resource Adapters are another set of JCA adapters
that took the same approach. They incorporate some of JCA 2.0’s anticipated
features. RAi supports both inbound and outbound connectivity as well as
synchronous and asynchronous communication modes. In addition to CCI, RAi
connectors support XML-based APIs and XML metadata and provide a logging
and monitoring utility, which can be a big plus in real life.
In addition, Attunity and Insevo also provide numerous data source and
legacy adapters. These adapters usually need only a single direction and
a synchronous type of communication. Some of the data sources and legacy
systems don’t support JCA features such as transactions. As a result, not
all JCA features are fully supported.
Comparison with Other Kinds of Adapters
Other types of adapters are developed for different requirements. One
new and important type is a Web services adapter that’s rapidly gaining popularity
as well. Web services is an HTTP/SOAP-based integration interface and an
XML-based protocol. And a lot of proprietary adapters were developed prior
to the introduction of JCA, so these adapters had a longer time to mature.
Web Services Adapter
Nowadays, an enterprise uses all types of platforms some of which are
Java-based. Companies invest a large number of resources to develop their
systems and usually are not in a position to abandon them. The question is
how to integrate these heterogeneous systems so they all work together without
an additional investment. Fortunately two very popular technologies make
it possible. One is HTTP protocol and the other is XML. They’re the technologies
that every platform uses and are a great fit for heterogeneous system integration.
Web services is a specification that is built on these two simple yet critical
technologies. While the full discussion of Web services is beyond the scope
of this article, here’s a short list of Web services features.
• XML interface: Web services is XML based. It uses the
Web Services Description Language (WSDL) to describe the service format of
the end-point service provider
• HTTP/HTTPS protocol: The de facto protocol for Web services
• SOAP: The binding protocol between WSDL-based Web services
and HTTP/HTTPS communication protocol
Web services doesn’t provide any QoS yet and is a synchronous protocol.
It’s a good fit for loosely coupled heterogeneous system integration.
The features provided by Web services and JCA complement each other.
It won’t be surprising if these two technologies eventually merge their features.
In fact, a few vendors have already moved in that direction. For example,
vendors like Attunity and Sirvisetti have already built Web services support
into their JCA adapters.
Prior to the introduction of JCA, integration adapters from independent
vendors like webMethods and TIBCO have been available for years. These adapters
will likely have proprietary APIs that are sometimes nondetachable from their
integration packages. However, these adapters have also been tested for years
and have much wider EIS coverage than JCA adapters. In particular, the webMethods
Enterprise Adapter and B2B adapters have the most coverage by far. webMethods
has more than 60 adapters. These adapters don’t support JCA yet, even though
webMethods is rapidly moving to support it. Table 3 provides a list of some
of these adapters.
Short Term Solution/Long Term Strategy Pros and Cons
The advantages of JCA are obvious. It provides EIS vendors with a way
to expose an EIS interface in an open-industry standard. By using the common
callable interface and inheriting the QoS provided by JCA, a programmer can
simplify the EIS integration effort without sacrificing performance and system
The limitations of JCA are less obvious but can be important. Like any
new technology the immaturity of the initial implementation is often the
most frustrating problem to deal with. One specific issue is that JCA adapters
should be portable across application servers. However, at this point, this
statement may not be true for your application server. The adapter’s support
for an application server is tested and released by the adapter vendor on
a case-by-case basis.
In addition, there are a few known limitations, some of which will be
addressed in the future version of the JCA standard.
• Asynchronous message delivery: JCA 1.0 tackles a synchronous
call to EIS applications. It doesn’t handle asynchronous message delivery
to and from EIS applications. If asynchronous delivery is a requirement for
your company, you may want to use JCA in combination with the Java Message
Service (JMS) or another queuing service. The other choice is to use JCA
adapters with proprietary asynchronous communication support built in.
• Long-running transaction: This is the type of transaction
that may run for days or even months. It doesn’t achieve data integrity by
locking resources but by long-term coordination of resources to guarantee
the successful execution of a workflow. Long-term transactions are of increasing
importance due to the growing need for B2B integration, and that the time
span of a process often can’t be controlled by a single trading partner.
JCA 1.0 supports DTC-type short-term transactions but it doesn’t support
any long-running transactions. If you’re thinking of using JCA to integrate
with your trading partner directly, it may not be the best fit. You’re better
off using it inside an enterprise and inserting a workflow engine between
you and your trading partners for long-running transactions.
• No XML-based interface: There’s no XML-based interface
to provide interoperability with non Java–based heterogeneous systems. The
result set returned from the CCI is row- and column-based. It’s similar to
the result set from a JDBC call to a database. The data returned from the
rows and columns are in their native data format. Additional XML-based interfaces
can be a big plus for interoperability and data validation.
• Single direction interface: JCA 1.0 only defines a single
direction call from a client to an EIS application. It doesn’t define how
an EIS application calls the client back. This makes it difficult to use
JCA 1.0 as a specification for process-level integration where bidirection
communication is often required.
• No adapter metadata: JCA 1.0 doesn’t have a standard
way to query an adapter’s metadata.
Is JCA the Right Solution for You?
To answer this question, you need to consider several factors:
• Architecture: Needless to say, JCA has been widely adopted
as an open-industry standard and will flourish in the future. It is architecture
neutral, and cheaper and easier to implement than most proprietary solutions.
It’s simply a better architecture than its competitors.
• Availability: At this point, JCA adapters are in their
early releases for a limited number of EIS applications. If there’s a solution
for your application server and EIS application and if it’s robust enough
for your application, you may want to give it a try. Otherwise, webMethods’
EIS integration solution has been around for several years and is a safer
bet. In addition, JCA adapters from different vendors may have different
non-JCA features, such as bidirectional communication, asynchronous message
delivery, and an XML-based interface, that can be critical factors in your
• Application arena: As I discussed earlier, JCA is currently
performance-optimized for synchronous connectivity and designed to benefit
from the QoS provided by the J2EE application server. It’s a great fit for
an EAI application, but not for B2B integration.
Whether the JCA is for you should be decided on a case-by-case basis.
It’s important to keep in mind what the strength and weakness of JCA adapters
and their counterparts are and apply your solution accordingly. Whether you
choose to use JCA or not, you can learn something from the spirit of JCA
architecture. Isolate the callable interface and QoS so that you always have
room to migrate to JCA in the future.
The Java Connector Architecture completes the story for building enterprise
applications for J2EE. Before J2EE CA was available, J2EE application servers
enabled development of all the pieces of the jigsaw puzzle except the piece
that connected to the legacy systems the data was extracted from. To integrate
with these EIS systems, companies provided custom development for each system.
With J2EE CA, a layer of abstraction is provided by the
application server vendors for connecting Java platform components to back-end
systems. This also fits into the natural evolution of the J2EE application
server market. Because of the popularity of J2EE, EIS vendors had to follow
suit and offer resource adapters to connect to J2EE components.
At some point the adapter framework and the corresponding
adapters should become a commodity offering from J2EE app server vendors.
Visualize a design studio, similar to the one offered by BizTalk, where basic
connectivity to ERP systems is available in a graphical environment. Of course,
customization will still be required, depending on the needs of specific
clients. However, getting a prototype up and running shouldn’t be as difficult
as it is today.
David Li is the president of VertFuture Inc (www.vertfuture.com), a consulting
firm specializing in B2B and EAI development and integration. He holds a
PhD in chemical physics from the University of Pennsylvania.