Java: A platform for platforms
Sun's reorg may seem promising to shareholders but it's also a scramble for position. The question now is whether Sun can, or wants to, maintain its hold on Java technology. Especially with enterprise leaders like SpringSource and RedHat investing heavily in Java's future as a platform for platforms

Also see:

Discuss: Java: A platform for platforms?

Featured Whitepapers
Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

Connect the enterprise with the JCA, Part 1

A look at the J2EE Connector Architecture

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
The EAI (enterprise application integration) product category has grown significantly over the last 10 years. EAI eases the integration of disparate enterprise information systems (EIS). Although products such as Tibco and Vitria targeting the EAI market have succeeded, they have yet to achieve widespread adoption. As one of its missions, the new JCA (J2EE Connector Architecture) strives to bring EAI into mainstream use.

Read the whole series on the JCA:



The emerging JCA standard provides a mechanism to store and retrieve enterprise data in J2EE (Java 2 Platform, Enterprise Edition). The latest versions of many application servers, including BEA's WebLogic and IBM's WebSphere, support JCA adapters for enterprise connectivity. Using JCA to access an EIS is akin to using JDBC (Java Database Connectivity) to access a database.

Before JCA, each EAI vendor created a proprietary resource adapter interface for its own EAI product, requiring a resource adapter to be developed for each EAI vendor and EIS combination (for instance you'd need a SAP resource adapter for Vitria and a SAP resource adapter for Tibco). To solve that problem, as one of its main thrusts, JCA attempts to standardize the resource adapter interfaces.

In this article, I first deliver a high-level introduction into the JCA. Then I discuss how JCA fits into an integration strategy. After that I compare JCA to EAI vendors' products. Finally, I discuss the limitations of the current JCA platform, followed by what the future may hold.

How JCA and J2EE compare to EAI products

With that background in mind, let's consider how the current version of the JCA specification -- as well as J2EE in general -- measure up to some of the features found in EAI vendors' products.

Many EAI vendors, Vitria and Tibco for example, have either announced JCA support, or are in the process of releasing products that incorporate JCA-based adapters. Because the JCA 1.0 specification was finalized in July 2001, don't expect JCA in its initial release to match feature for feature to an EAI vendor's product, nor is that the aim. (Many features of the J2EE platform also compare to features in many EAI products.)

In light of this, and before we can discuss how JCA fits into the EAI picture, it's important to first understand some basic EAI features:

  • Resource adapters
  • Data mapping
  • Messaging brokers
  • Workflow


Let's look at each.

Resource adapters

Most EAI vendors include proprietary adapters built to work with their products. Most proprietary adapters allow for synchronous and asynchronous communication to an EIS. JCA adapters closely resemble those adapters, except JCA adapters include only a synchronous communication channel. Resource adapters represent the EAI feature JCA most directly matches, although most EAI vendors' adapters offer a larger feature set (for instance asynchronous capability) than JCA adapters.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources
  • Dirk Reinshagen's "XML Messaging" series (JavaWorld):