JCA 综述
什么是JCA？它最吸引人的特点是什么？它有什么不足之处？有哪些厂商支持JCA？是否还存在替代JCA的产品，以便选购时货比三家？本文将帮助你解答所有这些问题。
JCA及其特点
JCA即Java Connector Architecture，或Java连接器体系，它完善了用J2EE构造企业应用的技术体系。在JCA出现之前，基于J2EE应用服务器的开发体系为企业应用各个部分提供了相应的开发工具，但是，与传统系统连接的部分仍未得到很好的解决。为了与这些EIS系统集成，各个公司为每一种系统提供了定制的开发工具。有了JCA，应用服务器厂商就能够为Java平台组件与后端系统的连接提供一层抽象。应该说，JCA完全符合J2EE应用服务器市场的自然发展历程。
在JCA出现之前，人们在连接EIS时面临着一系列类似的问题。
首先，每一个EIS应用有自己的编程接口，与一个异种的EIS应用交互意味着要针对一组特定的API编程。因此，人们需要一组公共的客户端接口，以便简化客户端编程。
其次，与后端EIS系统的交互通常总是很繁忙。为了降低连接开销、提高性能，人们需要连接池。
第三，与EIS应用的连接往往是面向事务的。为了保证数据完整性，人们需要内建的事务支持，以便把编程工作量降低到最少限度。
最后一点（但并非最不重要的一点）是人们迫切需要提高EIS应用和EIS客户程序集成的安全性。
仔细分析上述问题，可以发现，它们与人们以前连接数据库时面临的问题相似。对于数据库连接，由于JDBC API之类的技术被广泛采用，问题已经得到解决：作为一个程序员，你现在再也不必直接与数据库交互，而是可以通过JDBC与数据库交互，JDBC接口对于所有流行的数据库系统来说都是一样的；你可以方便地使用数据库连接池，却不必自己动手实现它；你可以方便地使用事务支持和安全集成能力，因为这些功能都是内建的。要是对于EIS应用也有类似JDBC的技术，它一定能够为你带来不少方便吧？如果你的回答是肯定的，答案就是JCA。
为了解决连接EIS时面临的各种问题，JCA提供以下功能：
▲ 连接缓冲池：EIS连接通常属于昂贵的资源，创建EIS连接需要大量的时间开销。连接池使得应用服务器能够创建和共享EIS应用的连接，使得应用能够更高效地使用昂贵的连接资源。
▲ 事务管理：事务管理能力使得EIS应用能够获取应用服务器提供的事务环境的支持，使得服务器能够把EIS系统的事务作为一个单元管理。
▲ 安全：安全接口的实现允许应用服务器在不影响EIS特有安全机制的情况下，对整体安全性进行有效的管理。验证、授权和安全关联都属于该接口包含的范围，它们都属于为JCA适配器和J2EE应用服务器内建的服务。
▲ 公共的客户端接口：JCA还定义了用户级的编程接口，称为公共客户端接口（CCI，Common Client Interface）。这个接口集在JCA 1.0中是可选的，允许EIS客户程序的开发者按照一种标准的方式，连接目标EIS系统，或与目标EIS交互（执行命令并获取结果）。
应用服务器的JCA支持
对JCA的支持来自两个方面：支持JCA的应用服务器，支持JCA的EIS应用适配器。JCA 1.0是J2EE 1.3规范的一部分，遵从J2EE 1.3规范的应用服务器必须提供合适的环境支持必要的JCA功能，包括缓冲池、事务和集成的安全机制。表一列出了常见的应用服务器以及它们的JCA支持情况。
表一：JCA支持现状
BEA的WebLogic Server是最早支持JCA的应用服务器之一。从2001年开始，WebLogic 6.0就内建了对JCA Beta的支持，当时的JCA 1.0规范正处于最终草案状态。经过一年的发展之后，多次获奖的WebLogic Server已经是支持JCA的最佳应用服务器之一。IBM的WebSphere应用服务器是另一个广受欢迎并获奖的J2EE应用服务器，2001年中期左右，它开始支持JCA。JBoss也是值得特别指出的应用服务器，如果预算比较紧张，你就应该注意一下这个应用服务器。JBoss也支持JCA，而且它具有无可比拟的价格优势--它是免费的！
适配器厂商和产品
连接后端EIS应用时要用到JCA适配器。目前已经有许多集成商开发了JCA适配器，如表二所示。
表二：JCA厂商与适配器
从表二可以看出，有许多厂商为同样的EIS应用提供了JCA适配器。然而，即使对于同一个EIS应用，来自不同厂商的JCA适配器可能支持不同的功能集。这是由于两个因素造成的。首先，一些规范，例如JCA 1.0中的CCI，是可选的；是否在当前发行版中包含某个功能，完全由适配器厂商决定。其次，一些重要的EIS集成功能并未包含在当前的JCA规范中；为了增强适配器，适配器厂商可能决定增加一些额外的功能。这些在规范中没有定义的功能将在稍后详细讨论。
由于这些在JCA规范中没有定义的功能可能是很重要的，许多厂商在这个问题上采取了更实在的策略，走到了规范之前；即使面临着非标准化的风险，为了提供额外的功能，它们也会为适配器加上一些辅助特性。
Insevo为许多EIS应用提供了JCA适配器，包括SAP、PeopleSoft、Edwards和Siebal。这些适配器除了支持JCA定义的CCI之外，还支持一种基于XML的接口。它们既支持客户程序和EIS应用之间的同步通信，也支持异步通信。另外，它们还支持双向通信，而不是JCA定义的单向通信。这些额外的功能使得Insevo的适配器不仅适用于应用集成，而且适用于过程集成（Process Integration）；另外，这些附加的功能已经被作为JCA 2.0规范的一部分考虑。因此，从某种意义上来说，Insevo的适配器是一个超前JCA规范的版本。尽管额外增加的功能不遵从当前的JCA规范，但如果你确实需要它们，还有比这更好的事情吗？
Resource Adapters的RAi连接器是另一组采取此种策略的JCA适配器，也包含了一些预期将在JCA 2.0规范中定义的功能。RAi支持输入（Inbound）连接和输出（Outbound）连接，支持同步和异步通信模式。RAi连接器除了支持CCI之外，还支持一组基于XML的API和XML元数据，并提供了日志和监视工具，为实际工作带来了巨大的方便。
除此之外，Attunity和Insevo还提供了许多数据源适配器和传统适配器，这些适配器往往只需单向的同步通信。一些数据源和传统适配器不支持事务之类的JCA功能，因此，它们并不提供对JCA的完整支持。
与其他类型的适配器比较
除了JCA适配器，还有其他一些根据不同需求而开发的适配器类型，其中之一是Web服务适配器，它是一种重要的新适配器类型，正在迅速地获得人们的认可。另外，在JCA出现之前就有许多非标准的适配器被开发出来，因此这些适配器拥有更长的发展和成熟时间。
Web服务适配器
当前，企业应用的平台有各种各样的类型，当然有一部分是以Java为基础的。在开发各类系统的过程中，企业投入了大量的资源，当然不肯轻言放弃。问题在于，如何才能在不增加额外投资的情况下，让这些异种的系统能够协作运行？两种流行的技术使这一切成为可能：第一是HTTP，第二是XML。这两者是每一种平台上都使用的技术，非常适合于异种平台的集成。Web服务规范就建立在这两种简单但关键的技术的基础上。尽管详细讨论Web服务已经超出了本文的范围，但从下面的简要说明可以看出Web服务的主要特点：
▲ XML接口：Web服务以XML为基础，它利用Web服务描述语言（WSDL）描述终端服务者的服务形式。
▲ HTTP/HTTPS协议：Web服务事实上的通信协议。
▲ SOAP：基于WSDL的Web服务和HTTP/HTTPS通信协议之间的绑定协议。
Web服务仍未提供任何QoS机制，因此是一种异步协议。对于异种系统的宽松结合来说，它是一种很合适的协议。
Web服务和JCA提供的功能互相完善了对方。如果这两种技术最终把它们的特点合并了起来，我们不应该感到奇怪。实际上，一些厂商已经向这个方向发展。例如，Attunity和Sirvisetti等厂商已经在它们的JCA适配器中提供了对Web服务的支持。
非标准化的适配器
在JCA出现之前，一些中立的厂商，例如webMethods和TIBCO等，推出集成适配器已有数年。这些适配器一般具有非标准化的API，有时它们不能从集成软件包分开。尽管如此，这些适配器已经经过多年实践的检验，比JCA适配器涵盖范围更广泛的EIS。特别地，webMethods Enterprise Adapter和B2B适配器拥有迄今为止最广泛的覆盖面。webMethods拥有的适配器多达60个以上，这些适配器还不支持JCA，但webMthods正在快速地向支持JCA的方向发展。
JCA的优点和不足
JCA的优点很明显。它为EIS厂商提供了一种按照开放的产业标准定义EIS接口的途径。通过使用公共的可调用接口以及继承JCA提供的QoS机制，程序员能够在不牺牲性能和系统完整性的前提下，简化EIS的集成工作。
JCA的局限不是显而易见，但不容忽视。和所有其他新技术一样，JCA第一个版本的不成熟性往往成为最令人担心的问题。另外，JCA适配器应该是可在应用服务器之间移植的；然而，就目前的情况来看，对于你正在使用的应用服务器来说这一判断未必正确，因为适配器对某种应用服务器的支持情况由适配器厂商根据个案进行测试和发布。此外，JCA还有其他一些已知的局限，其中有些局限有望在JCA标准的下一个版本中得到解决，其中包括：
▲ 异步消息传输：调用EIS应用时，JCA 1.0采取同步消息传输方式；它不能处理来自EIS应用的异步消息或向EIS应用传递异步消息。如果要异步传递消息，就要在使用JCA时结合JMS（Java Message Service）或其他队列服务，或者选择使用JCA适配器中内建的非标准化异步消息支持。
▲ 长时间运行的事务：这是一种运行时间可能达到数天甚至
转自 http://www.bitscn.com/pdb/java/200605/24119.html
JCA及其特点
JCA即Java Connector Architecture，或Java连接器体系，它完善了用J2EE构造企业应用的技术体系。在JCA出现之前，基于J2EE应用服务器的开发体系为企业应用各个部分提供了相应的开发工具，但是，与传统系统连接的部分仍未得到很好的解决。为了与这些EIS系统集成，各个公司为每一种系统提供了定制的开发工具。有了JCA，应用服务器厂商就能够为Java平台组件与后端系统的连接提供一层抽象。应该说，JCA完全符合J2EE应用服务器市场的自然发展历程。
在JCA出现之前，人们在连接EIS时面临着一系列类似的问题。
首先，每一个EIS应用有自己的编程接口，与一个异种的EIS应用交互意味着要针对一组特定的API编程。因此，人们需要一组公共的客户端接口，以便简化客户端编程。
其次，与后端EIS系统的交互通常总是很繁忙。为了降低连接开销、提高性能，人们需要连接池。
第三，与EIS应用的连接往往是面向事务的。为了保证数据完整性，人们需要内建的事务支持，以便把编程工作量降低到最少限度。
最后一点（但并非最不重要的一点）是人们迫切需要提高EIS应用和EIS客户程序集成的安全性。
仔细分析上述问题，可以发现，它们与人们以前连接数据库时面临的问题相似。对于数据库连接，由于JDBC API之类的技术被广泛采用，问题已经得到解决：作为一个程序员，你现在再也不必直接与数据库交互，而是可以通过JDBC与数据库交互，JDBC接口对于所有流行的数据库系统来说都是一样的；你可以方便地使用数据库连接池，却不必自己动手实现它；你可以方便地使用事务支持和安全集成能力，因为这些功能都是内建的。要是对于EIS应用也有类似JDBC的技术，它一定能够为你带来不少方便吧？如果你的回答是肯定的，答案就是JCA。
为了解决连接EIS时面临的各种问题，JCA提供以下功能：
▲ 连接缓冲池：EIS连接通常属于昂贵的资源，创建EIS连接需要大量的时间开销。连接池使得应用服务器能够创建和共享EIS应用的连接，使得应用能够更高效地使用昂贵的连接资源。
▲ 事务管理：事务管理能力使得EIS应用能够获取应用服务器提供的事务环境的支持，使得服务器能够把EIS系统的事务作为一个单元管理。
▲ 安全：安全接口的实现允许应用服务器在不影响EIS特有安全机制的情况下，对整体安全性进行有效的管理。验证、授权和安全关联都属于该接口包含的范围，它们都属于为JCA适配器和J2EE应用服务器内建的服务。
▲ 公共的客户端接口：JCA还定义了用户级的编程接口，称为公共客户端接口（CCI，Common Client Interface）。这个接口集在JCA 1.0中是可选的，允许EIS客户程序的开发者按照一种标准的方式，连接目标EIS系统，或与目标EIS交互（执行命令并获取结果）。
应用服务器的JCA支持
对JCA的支持来自两个方面：支持JCA的应用服务器，支持JCA的EIS应用适配器。JCA 1.0是J2EE 1.3规范的一部分，遵从J2EE 1.3规范的应用服务器必须提供合适的环境支持必要的JCA功能，包括缓冲池、事务和集成的安全机制。表一列出了常见的应用服务器以及它们的JCA支持情况。
表一：JCA支持现状
BEA的WebLogic Server是最早支持JCA的应用服务器之一。从2001年开始，WebLogic 6.0就内建了对JCA Beta的支持，当时的JCA 1.0规范正处于最终草案状态。经过一年的发展之后，多次获奖的WebLogic Server已经是支持JCA的最佳应用服务器之一。IBM的WebSphere应用服务器是另一个广受欢迎并获奖的J2EE应用服务器，2001年中期左右，它开始支持JCA。JBoss也是值得特别指出的应用服务器，如果预算比较紧张，你就应该注意一下这个应用服务器。JBoss也支持JCA，而且它具有无可比拟的价格优势--它是免费的！
适配器厂商和产品
连接后端EIS应用时要用到JCA适配器。目前已经有许多集成商开发了JCA适配器，如表二所示。
表二：JCA厂商与适配器
从表二可以看出，有许多厂商为同样的EIS应用提供了JCA适配器。然而，即使对于同一个EIS应用，来自不同厂商的JCA适配器可能支持不同的功能集。这是由于两个因素造成的。首先，一些规范，例如JCA 1.0中的CCI，是可选的；是否在当前发行版中包含某个功能，完全由适配器厂商决定。其次，一些重要的EIS集成功能并未包含在当前的JCA规范中；为了增强适配器，适配器厂商可能决定增加一些额外的功能。这些在规范中没有定义的功能将在稍后详细讨论。
由于这些在JCA规范中没有定义的功能可能是很重要的，许多厂商在这个问题上采取了更实在的策略，走到了规范之前；即使面临着非标准化的风险，为了提供额外的功能，它们也会为适配器加上一些辅助特性。
Insevo为许多EIS应用提供了JCA适配器，包括SAP、PeopleSoft、Edwards和Siebal。这些适配器除了支持JCA定义的CCI之外，还支持一种基于XML的接口。它们既支持客户程序和EIS应用之间的同步通信，也支持异步通信。另外，它们还支持双向通信，而不是JCA定义的单向通信。这些额外的功能使得Insevo的适配器不仅适用于应用集成，而且适用于过程集成（Process Integration）；另外，这些附加的功能已经被作为JCA 2.0规范的一部分考虑。因此，从某种意义上来说，Insevo的适配器是一个超前JCA规范的版本。尽管额外增加的功能不遵从当前的JCA规范，但如果你确实需要它们，还有比这更好的事情吗？
Resource Adapters的RAi连接器是另一组采取此种策略的JCA适配器，也包含了一些预期将在JCA 2.0规范中定义的功能。RAi支持输入（Inbound）连接和输出（Outbound）连接，支持同步和异步通信模式。RAi连接器除了支持CCI之外，还支持一组基于XML的API和XML元数据，并提供了日志和监视工具，为实际工作带来了巨大的方便。
除此之外，Attunity和Insevo还提供了许多数据源适配器和传统适配器，这些适配器往往只需单向的同步通信。一些数据源和传统适配器不支持事务之类的JCA功能，因此，它们并不提供对JCA的完整支持。
与其他类型的适配器比较
除了JCA适配器，还有其他一些根据不同需求而开发的适配器类型，其中之一是Web服务适配器，它是一种重要的新适配器类型，正在迅速地获得人们的认可。另外，在JCA出现之前就有许多非标准的适配器被开发出来，因此这些适配器拥有更长的发展和成熟时间。
Web服务适配器
当前，企业应用的平台有各种各样的类型，当然有一部分是以Java为基础的。在开发各类系统的过程中，企业投入了大量的资源，当然不肯轻言放弃。问题在于，如何才能在不增加额外投资的情况下，让这些异种的系统能够协作运行？两种流行的技术使这一切成为可能：第一是HTTP，第二是XML。这两者是每一种平台上都使用的技术，非常适合于异种平台的集成。Web服务规范就建立在这两种简单但关键的技术的基础上。尽管详细讨论Web服务已经超出了本文的范围，但从下面的简要说明可以看出Web服务的主要特点：
▲ XML接口：Web服务以XML为基础，它利用Web服务描述语言（WSDL）描述终端服务者的服务形式。
▲ HTTP/HTTPS协议：Web服务事实上的通信协议。
▲ SOAP：基于WSDL的Web服务和HTTP/HTTPS通信协议之间的绑定协议。
Web服务仍未提供任何QoS机制，因此是一种异步协议。对于异种系统的宽松结合来说，它是一种很合适的协议。
Web服务和JCA提供的功能互相完善了对方。如果这两种技术最终把它们的特点合并了起来，我们不应该感到奇怪。实际上，一些厂商已经向这个方向发展。例如，Attunity和Sirvisetti等厂商已经在它们的JCA适配器中提供了对Web服务的支持。
非标准化的适配器
在JCA出现之前，一些中立的厂商，例如webMethods和TIBCO等，推出集成适配器已有数年。这些适配器一般具有非标准化的API，有时它们不能从集成软件包分开。尽管如此，这些适配器已经经过多年实践的检验，比JCA适配器涵盖范围更广泛的EIS。特别地，webMethods Enterprise Adapter和B2B适配器拥有迄今为止最广泛的覆盖面。webMethods拥有的适配器多达60个以上，这些适配器还不支持JCA，但webMthods正在快速地向支持JCA的方向发展。
JCA的优点和不足
JCA的优点很明显。它为EIS厂商提供了一种按照开放的产业标准定义EIS接口的途径。通过使用公共的可调用接口以及继承JCA提供的QoS机制，程序员能够在不牺牲性能和系统完整性的前提下，简化EIS的集成工作。
JCA的局限不是显而易见，但不容忽视。和所有其他新技术一样，JCA第一个版本的不成熟性往往成为最令人担心的问题。另外，JCA适配器应该是可在应用服务器之间移植的；然而，就目前的情况来看，对于你正在使用的应用服务器来说这一判断未必正确，因为适配器对某种应用服务器的支持情况由适配器厂商根据个案进行测试和发布。此外，JCA还有其他一些已知的局限，其中有些局限有望在JCA标准的下一个版本中得到解决，其中包括：
▲ 异步消息传输：调用EIS应用时，JCA 1.0采取同步消息传输方式；它不能处理来自EIS应用的异步消息或向EIS应用传递异步消息。如果要异步传递消息，就要在使用JCA时结合JMS（Java Message Service）或其他队列服务，或者选择使用JCA适配器中内建的非标准化异步消息支持。
▲ 长时间运行的事务：这是一种运行时间可能达到数天甚至
转自 http://www.bitscn.com/pdb/java/200605/24119.html