connect the enterprise with the jca, part 1.htm

本人收集的关于Java Connector Architecture的资料

  A look at the J2EE Connector Architecture</A> (November 2001) 
  <LI><A 
  href="http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-jca2.html">Part 2. 
  Build your own J2EE Connector Architecture adapter</A> (February 2002) 
</LI></UL>
<P>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. 
<P>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. 
<P>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. 
<P><FONT size=+1><STRONG>How JCA and J2EE compare to EAI products 
</STRONG></FONT><BR>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. 
<P>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.) 
<P>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: 
<UL>
  <LI>Resource adapters 
  <LI>Data mapping 
  <LI>Messaging brokers 
  <LI>Workflow </LI></UL>
<P>Let's look at each. 
<P><STRONG>Resource adapters </STRONG><BR>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. 
<P><STRONG>Data mapping </STRONG><BR>With the next EAI feature -- data mapping 
-- data acquired in one format (for instance in the EIS's native format) by the 
resource adapter must be transformed into the format required for the business 
object. Mapping data from one system to another often proves the most time 
consuming aspect of system integration because you must map each business object 
in both systems. In response, most EAI vendors provide visual tools to enable a 
developer to set up such mapping. 
<P>While JCA does not offer an equivalent data-mapping facility, EJB's 
(Enterprise Java Beans) Container Managed Persistence (CMP) facility provides a 
similar functionality. However, currently not all EJB containers can use EJB CMP 
with JCA (using JCA as a data resource in place of JDBC). Presumably this will 
change as JCA becomes more widely adopted. 
<P><STRONG>Message broker </STRONG><BR>Messaging brokers, another feature common 
to many EAI products, usually enable both point-to-point and publish/subscribe 
messaging. EAI products often employ messaging as the connectivity layer to tie 
together disparate systems. 
<P>Currently JCA does not address connectivity to an EIS in a message-oriented 
manner. It is possible, however, to implement some of a message broker's feature 
set in an EAI product by using JMS (Java Messaging Service), which is part of 
J2EE. 
<P><STRONG>Workflow </STRONG><BR>Workflow is the management of business 
processes. Think of workflow as a coordinator. In and of itself, workflow lacks 
the capability to do anything, but rather relies on business objects, messages, 
and other external entities to perform functionality (for example creating a 
user object in a database). Workflow coordinates the use of business objects, 
messages, and so on to perform business processes. 
<P>JCA does not address workflow. However, look for something in the J2EE arena 
to address workflow, as it serves as an important component when developing a 
complex system. 
<P>Having discussed how JCA (and J2EE) compare with EAI tools, it's now 
important to look at how JCA fits into an overall integration strategy. 
<P><!-- break -->
<P><FONT size=+1><STRONG>JCA and a general integration strategy 
</STRONG></FONT><BR>These days, many systems must integrate with other systems. 
But, what does that mean? In this section, I describe various integration types 
and where JCA fits into them. 
<P>Integration falls into two main buckets: 
<UL>
  <LI><STRONG>Inbound integration:</STRONG> outside systems initiate data 
  requests to your system 
  <LI><STRONG>Outbound integration:</STRONG> your system initiates data requests 
  to other systems </LI></UL>
<P>All of the following integration types can be applied in both an inbound and 
an outbound manner.
<P><STRONG>User interface integration </STRONG><BR>User interface (UI) 
integration represents the most coarse-grain type of integration. UI-level 
integration implies that the data passed between systems will exist in the form 
of a UI representation. An outbound integration at the UI level entails 
requesting the UI (most likely a Webpage) from a remote system, then possibly 
manipulating it before displaying it as if it were part of your system's UI. An 
inbound integration at the UI level entails allowing an outside system to 
request UI pages on your system for inclusion on a remote system. 
<P>Prefer UI integration over other options when it is unimportant to 
distinguish the data type being retrieved. UI integration often requires the 
least effort to implement. 
<P><STRONG>Message integration </STRONG><BR>Message-level integration, all the 
rage with the advent of Web services, implies that the data passed between 
systems will be in the form of a message (a defined, data-driven text format). 
An outbound message integration involves requesting data from a remote system in 
a message form (most likely a SOAP (Simple Object Access Protocol) message). 
With an inbound integration, your system receives a request for data via a 
message and responds with a message. 
<P>Message-oriented integration lends itself to loose coupling between systems 
because the systems remain unaware of the object types that exist on the remote 
system. That type of loose coupling works well with applications that wish to 
communicate over the Internet. 
<P><STRONG>Object/RPC integration </STRONG><BR>Object/RPC (remote procedure 
call) integration implies integrating systems using distributed objects (that 
is, using EJB calls to integrate). With object-level integration, data passes 
between systems as parameters to method calls. In an outbound object-level 
integration, your system invokes objects on remote systems, while in an inbound 
object-level integration, a remote system calls objects on your system to 
retrieve data. 
<P>One of an object-level integration's main advantages is that you can call 
detailed APIs with full type safety and easily propagate the error codes and 
exceptions between systems. 
<P><STRONG>Data integration </STRONG><BR>Lastly, data-level integration implies 
that the data passed between systems will be in a data/record-oriented manner. 
In an outbound data-level integration, your system requests data in a 
record-oriented fashion from other systems. With an inbound data-level 
integration, a remote system requests data from your system in a record-oriented 
manner. 
<P>The advantage of a data level integration: it lends itself to data mapping 
from one system onto the business objects in another system. JCA falls into the 
data-level integration category and therefore has the strengths and weaknesses 
of this integration type. 
<P>Now that we've covered where JCA fits into the overall integration puzzle, we 
are ready to discuss the JCA's structure. 
<P><FONT size=+1><STRONG>JCA's structure </STRONG></FONT><BR>Let's begin with a 
JCA overview. Its main components include the <EM>resource adapter,</EM> 
<EM>system contracts,</EM> and the <EM>Common Client Interface</EM> (CCI), which 
together give JCA the power to access data in enterprise systems. 
<P><STRONG>Resource adapter </STRONG><BR>In order to use JCA in a J2EE 
container, you first must have a JCA resource adapter, which resembles a JDBC 
driver. A JCA adapter is specific to an EIS (for example SAP or PeopleSoft) and 
is contained in a Resource Adapter Archive (RAR) file composed of the jar files 
and native libraries necessary to deploy the resource adapter on a J2EE 
container. 
<P>A JCA adapter interacts with a J2EE server with <EM>system contracts.</EM> 
They enable the J2EE server to propagate the context in which a JCA adapter is 
being called. You'll find three types of system contracts: 
<UL>
  <LI>Connection management 
  <LI>Transaction management 
  <LI>Security </LI></UL>
<P><STRONG>Connection management contracts </STRONG><BR>The connection 
management contract describes the understanding a J2EE container has with the 
adapter regarding establishing, pooling, and tearing down connections. The 
connection management contract also allows listeners created on a connection to 
respond to events (for instance if the connection becomes lost or experiences an 
error). Also note that the underlying protocol an adapter uses to connect to an 
EIS is outside the scope of the JCA specification. 
<P>All JCA resource adapters must supply two implementations with the adapter. 
First, a <CODE>ConnectionFactor</CODE> provides a vehicle for creating 
connections. Second, the <CODE>Connection</CODE> class represents this 
particular resource adapter's underlying connection. 
<P><STRONG>Transaction management contract </STRONG><BR>The transaction 
management contract controls transactions in two different ways. First, it 
allows distributed transactions, which provide a mechanism to propagate 
transactions that originate from inside an application server to an EIS system. 
For example, in an EJB, a transaction may be created. If this EJB then employs a 
JCA resource adapter, the transaction management contract enables the 
transaction to propagate to the EIS (via the application server invoking the 
resource adapter's X/Open XA interfaces). In that situation, the transaction 
manager on the application server would control multiple resources to conduct 
distributed transaction coordination (i.e., two-phase commit). 
<P>Second, the transaction management contract can control transactions by 
creating <EM>local transactions.</EM> Local transactions are local in the sense 
that they exist only on a particular EIS resource. The transaction contract 
allows these transactions to be controlled, but they are related to any 
transaction that exists on the application server where the JCA resource adapter 
is running. 
<P>Also note that the resource adapter need not implement the the transaction 
management contract. Making this optional allows for resource adapters in 
nontransaction resources. 
<P><STRONG>Security contract </STRONG><BR>The security contract enables the 
application server to connect to an EIS system using security properties. The 
application server authenticates with the EIS system by using security 
properties composed of a principle (a user id) and credentials (a password, a 
certificate, and so on). An application server can employ two methods to 
authenticate to an EIS system (via a resource adapter).
<P>With the first method, container-managed sign-on, the security credentials