一、jCOM簡介

據Gartner的研究分析，在名列全球前1000名的企業中，大約90%都混合應用了java和Windows技術。然而，Java技術和微軟技術分別提供了豐富但卻迥然不同的解決方案，或至少說這兩種方案之間的差異是巨大的。

為了解決這一矛盾，Sun率先提出了JNI解決方案。JNI，即Java本機接口，是編寫Java本機方法和把Java虛擬機嵌入到本機應用程序中的標準編程接口。Java本機接口的主要目的就是保證本機方法庫在不同平臺上的Java虛擬機中的二進制兼容性。使用JNI編寫程序，就可以很方便地做到程序的跨平臺可移植。盡管如此，Sun提供的JNI解決方案只是底層的API包裝，在實際開發中用到大量Java/COM互操作時，直接從JNI級進行開發顯然效率并不高。

為此，大大小小的公司甚至個人都試圖提供全部或局部的Java/COM互操作解決方案。例如，WebLogic提供的jCOM技術，bridge2java（IBM提供的基于Java本機接口和COM技術，答應把ActiveX對象輕易地集成到Java環境中），jacoZoom（是一個java類庫—它答應你在java程序中使用ActiveX控件和ActiveX服務器，基于Java本機接口和COM技術，答應使用于Windows平臺上的任何java環境中），J-Integra for COM（http://j-integra.intrinsyc.com/），還有一個小型的JCom橋接庫（http://sourceforge.net/PRojects/jcom/，它也支持從Java中調用COM對象，例如Excel工作簿，VB的COM對象等）。其中，WebLogic提供的jCOM技術為微軟的COM對象和Java對象提供一個穩定、無縫的機制，讓這兩種對象可以協同工作。

jCOM，即Java／COM橋，它是一種用軟件實現的橋接機制，可以幫助Java應用程序快速訪問微軟的COM／DCOM組件。而且，微軟的COM應用程序也可以通過這個機制訪問基于Java的對象。jCOM不僅具有實現相對簡單的特點，而且其最吸人的部分在于它的透明性。對Java程序員來說，COM對象看起來與其他Java對象沒有什么不同。而對COM開發人員來說，遠程Java對象看起來就象是本機COM組件。在這些對象中可以找到jCOM運行時刻引擎進行動態類型映射，因此從表面上屏蔽了數據類型間的差異。遠程對象的數據類型被動態地轉換成調用程序所使用的基元類型。對Java開發人員來說，COM數據類型表現得就象Java基元類型；而對COM開發人員來說，Java數據類型看起來就象是COM數據類型。

本文將重點討論BEA的Java/COM解決方案。

二、jCOM工作原理

jCOM聲稱以雙向方式工作，實際只是答應在Java和COM組件之間，在任意一個方向上通信—Java對象可以調用COM組件，COM組件又可以調用Java對象。當然，在這兩種不同的分布式組件框架之間，有著兩種截然不同的底層體系結構負責線路級通信。在運行時，jCOM內部設置了一個雙協議棧環境，實現對底層兩個彼此獨立的基礎結構的支持(參考圖1）。對于COM組件，有一個在DCE遠程過程調用之上的COM／DCOM實現。對于Java對象，有一個在Java遠程方法IIOP（Internet Inter-ORB）之上的遠程方法調用（RMI）實現。調用要通過這些協議棧，并通過內部的協議轉換進行處理，內部的協議轉換能夠有效地屏蔽掉低一級的協議。對于EJB來說，來自COM客戶的調用看起來就似乎是來自Java客戶的調用。對于COM組件來說，來自Java客戶的調用看起來就好象是來自一個普通的COM客戶。

jCOM提供了能夠自動生成更高級別COM／DCOM代理以及RMI存根的工具。客戶程序用COM／DCOM代理以及RMI存根在這兩個不同的基礎結構間封裝并傳送調用。jCOM可以設置成本機模式，這樣就可以利用本機操作系統的動態鏈接庫，從而減輕DCOM的網絡負荷，并極大地提高系統性能。

下面看一下Java對象如何調用COM對象：

import com.jCOMSample.account.*;

clsaccount account=new clsaccount();

double accountbalance=getaccountbalance("Xiao Wang");

圖1演示了當Java對象訪問COM組件的時候事件產生的標準流程。首先，jCOM為要訪問的COM組件生成—個代理對象，Java對象開始調用這個代理對象。然后，代理對象與jCOM運行時引擎通信，jCOM運行時引擎又把代理對象的消息封裝成遠程過程調用的COM／DCOM形式，通過TCP／ip發送到Windows環境里的COM組件。在最低的一層上，jCOM使用服務器上的標準Java網絡類進行調用。