實際專案導入

這個章節會藉由真實案例，說明企業目前確實有面臨如此的技術瓶頸以 及如何導入本論文中的架構來解決問題，用來加強佐證本篇論文的動機及價 值。

第五章、結論與建議

本研究的最後章節，將對整篇文章作最後總結並且提出個具體的方法供 許多企業參考使用。最後則是點出本篇論文未來可能遇到的情況與未來後續 研究的建議。

第二章 文獻探討

2.1 JCOM 架 構 及 相 關 技 術

2.1.1 何謂JCOM Bridge

JCOM (Java for COM)，簡單來說就是一種中介軟體，藉由這個軟體架 構，可以讓 Java 程式能使用 COM+、ActiveX 控制項、DLL 以及 EXE 等 Microsoft 元件，也可以讓 VB、VC++、ASP 程式能執行任何 Java objects 及 EJB。換句話解釋，就是無障礙的軟體開發架構。

 COM-to-Java : 對於 COM 開發者而言，可以透過 JCOM 直接使用 JAVA object 的元件，享受件導向的方便性［43］。

 Java-to-COM : 對於 Java 開發者而言，也可以透過 JCOM 直接使用 COM 元件［43］。

2.1.2 JCOM Bridge的運作架構

如下圖所示，JCOM 是一種建構在 JVM(Java Visual Machine)平台上的 一個軟體。JCOM 主要功用在於兩種類型的訊息傳遞之間轉換(COM/DCOM vs.

Java RMI)。

圖 1 JCOM 最基本架構圖

它會自動建立每一端通過上述協議進行通信所必需的 COM/DCOM 代理 和 RMI 存取控制元件的對應關連。當 COM 元件要使用 JAVA 物件時，會透 過 COM/DCOM 對 JCOM 發出 Request，JCOM 在接收到 Request 後,會將其 Request 轉換成通過 Java 遠程方法協議/Internet Inter-ORB Protocol 分

散式組件基礎結構實現遠程方法（Remote Method Invocation，簡稱 RMI）

的方式，然後再將 Request 發送到 Enterprise Java Bean (EJB)，如此一 來就像請求來自一般 EJB 客戶端一樣。 Binding 的技術時，必須借由 Weblogic 提供的工具，先將 JAVA 物 件 先 轉 換 IDL(Interface Description Language) 後 ， 再 由 Microsoft MIDL 工具將 IDL 文件轉換成 COM 支援的 TLB 檔。如此 一來就是在程式在 Compile 階段就知道程式是否正確。反之 Late Binding 則不是不需要進行任何物件 Interface 的轉換，Compile 階段不會檢查物件的正確性，而是在執行時才和 JCOM-Bridge 確認 是否無誤。一般而言，Early Binding 的執行效率會比 Late Binding 來的好。

 In Process vs. Out Process: 這是用來設定 JCOM JVM 的執行是 否獨立於 COM Process 中。Weblogic 為了改善透過 DCOM 執行效能 的問題，提出了另外兩種方式來改善效能。以下這兩種做法有一個 移至客戶端機器上執行 JCOM Bridge，但 Weblogic 提供了 JVM.dll 的 library，讓 COM+程式執行時能一同將 JVM Bridge 載入。

圖 2 Out Process 架構 資料來源：Web Logic 官方網站

圖 3 In Process 架構 資料來源：Web Logic 官方網站 以下是我們歸納出幾種 JCOM 比較具代表性的架構 :

1. Zero Client、DCOM 模式架構

2. Native Mode + Out Process + 後期綁定(Late Binding) 3. Native Mode + In Process + 前期綁定(Early Binding) 2.1.3 Zero Client、DCOM模式架構

Zero Client ， 就 是 在 客 戶 端 不 需 要 任 何 額 外 的 設 定 或 載 入 JCOM 程式就 可 以 使 用 JCOM 的 架 構 。 JCOM Zero Client 的部署很容易 實現，也是企業內最普遍使用的方法之一。這種架構使用物件引用標記 (objref)。Objref 字串是由 Weblogic Server 的 IP 及 Port 進行編碼產 生的。Client 端程式只要取得這一字串，便可和 Server 產生連結物件 (Objref)，當取得連線後，Objref 物件就如同在 COM Client 端產生對應 java 的 interface 一樣，COM+程式可以直接對 objref 執行 Java 的 Methods。

DCOM 模式和 Zero Client 模式類似，差別在於 Objref 的取得方式是由

在 Client 端必須註記 Server 的 IP 及 Port。

圖 4 Zero Client Mode 資料來源：Web Logic 官方網站

圖 5 DCOM Mode

資料來源：WebLogic 官方網站

這種架構的好處在於客戶端無需任何額外的軟體或設定，開發人員可以 很直覺式的使用 Objref 就好像在使用 java object 一般。 但缺點是不適 合在用大量資料交換，因為每當 com 對 Objref 讀取一次資料時，就如同透 過 DCOM 連結遠端 JCOM ，再經由 JCOM 透過 RMI 的方式取得 JAVA 值後，再 回傳給 COM Client 端。如下圖 6 所示 :

圖 6 Client 每次存取 Object 物件，都必須往返 Server

可以想像，當程式大量使用 JCOM，需花費大量時間及資源在 Java & Com+

物件之間的轉換，導致 Server 的 Loading 急速增加，必然會造成 Client、

網路流量、Server 端相當大的 loading。

2.1.4 Native Mode + Out Process + Late Binding 架構

所謂的 Later Binding 指的是 COM+元件在 Compile 時不檢查有關所訪 問 Object 的是否有效；而是在運行時對所訪問對象進行即時確認。這意味 著，直到執行程式時才能確定所訪問的方法和屬性是否確實存在。和 Early Binding 比較起來，因為必須才能透過 JCOM 確認 Interface 是否正確，所 以執行性能上不如 Early Binding 好。

所謂的 Native Mode(本地模式)指的就是 Client 模式，也就是將 Weblogic library 複製一份到 client 端，並且在 Client 端架設 JCOM Bridge。一般企業比較少使用本地模式。

由圖 7 中得知，本地模式和 DCOM 模式最大的差異性在 JCOM 所在位置由 Server 端改成本機(Client)端，而且是透過 COM 來進行資料交換。 由下圖 中，我們可以很明顯看出差異性。簡單來說本地模式是為減少網路流量及 Server loading 而生的架構。

圖 7 Native Mode + Late Binding 資料來源：Web Logic 官方網站

2.1.5 Native Mode + In Process + Early Binding 架構

就官方的說法，這個架構是 Weblogic JCOM 中最有效率，但也是最難實 做、最複雜的架構。其採用的是 Early Binding 的方式，產生本地模式使 用專為本機操作系統和 CPU 編譯並優化的本機端的 DLL，配合上本地模式 的應用，可提高性能。不僅如此，在本地模式下運行的 COM-to-WLS 應用 程式使用 WebLogic 的 T3 / Internet InterORB (IIOP) 協議在 COM 客 戶端和 WebLogic Server 之間進行通信。因此可提供以下優點

 可減少網絡調用次數，所以與使用 DCOM 調用相比可提高性能。例 如，假設您的 VB 應用程式存取 java vector 物件時，必須讀取 1000 個通過使用 WebLogic Server 返回值的次數。在 DCOM 模式 下，該過程需要對服務器進行 100 次往返網路使用。在本地模式

下，則僅需要一次往返調用。［43］

 採用 In Process 的方法，能直接使用 JVM 的物件，更能增加執行 速度。［43］

 可使用 WebLogic Server 的故障轉移和平衡 loading 的功能。

以下是 Early Binding(前期綁定)的步驟 :

1. 先將 JAVA(EJB)的程式，透過 Weblogic 提供的 java2com 的工具，

轉成 IDL 檔，

無論是 Zero Client/DCOM 模式或是 Native and Early Binding 模式，

其最大共同的優點就是對系統開發人員而言，無論是 COM-to-WLS 或是 WLS-to-COM，都可以用直覺式的方法調用對方的元件。

但就執行的效能來說，Zero Client/DCOM 模式，但只適用在 Remote Procedure Call 的應用上，不適用在大量資料交換上的應用。而 Native and Early Binding 模式，雖然比 Zero Client/DCOM 來的有效率，但仍然有一 先天上的缺點及瓶頸 :

1. JCOM 程式必須建置在 Client 端

2. 必須先將 Java Interface 轉換成 Windows Library，而且在所有 COM 客戶端計算機上安裝 WebLogic Server Library 才能順利執 行。

3. 在 Native Mode 中，雖然可以直接透過 COM/DCOM 和 JCOM 在本機上 溝通，但在大量資料轉換過程中，仍浪費許多時間處理資料轉換的 問題。

因此我們嘗試用其他的方法 來克服以上問題。其中的方法就是用 Object Orient Web Service 來替代 JCOM。

2.2 Web Services 架 構 及 相 關 技 術

 UDDI (Universal Description Discovery and Integration) : 提供註冊與搜尋 Web Service 資訊的一個標準。主要是定義 Web services 位置的 pointer。［46］

 WSDL (Web Service Description Language):

是一項以 XML 為基礎的技術，它描述一個 Web Services 的網 路服務介面、資料和訊息型態、以及指示用戶端與它可能的互 動方式和轉換協定。［46］

 SOAP (Simple Object Access Protocol):

是一項以 XML 為基礎的技術，主要用於定義路服務通訊的 envelope，能夠對應到 HTTP 或是其他傳輸協定，並且提供 XML 文件在網路上的傳輸，一個連續化的格式，和 RPC 互動的協 定。［46］

2.2.1 UDDI

UDDI (Universal Description Discovery and Integration)起初是由 微軟、IBM 和 Ariba..等幾家大型企業所共同參與推動的! 它的概念有點類

圖 9 藉由 UDDI，Client 可以找提供服務的 Server 資料來源 : 深探網路服務 黃義焜譯

上圖顯示一個企業如何利用 UDDI 的註冊機制來註冊 Web Services 的 WSDL 資料。(1)企業首先產生 WSDL 檔案及描述 SOAP 支援的 Functions (2) 接著利用 UDDI Server 提供的 API 向 Server 註冊 WSDL 及功能 (3)其它企 業客戶端應用程式可透過 SOAP 向 UDDI 主機進行查詢功能 (4)UDDI 主機會 依照查詢的結果，產生 WSDL schema (5)並回傳給 Client 應用程式 (6)最 後，當 Client 端程式取得相對的 WSDL 文件及主機位置，就可以透過 SOAP 向遠端的 Web Services Server 發出 Request 了。

2.2.2 WSDL

WSDL 其實是一種 XML Schema 的格式，差別在於 WSDL 格式是經過許多 大型廠商支援的標準格式。WSDL 內容如下圖所示，主要可分為以下二類定 義(六個子元素): 如下圖所示 :

圖 10 WSDL 主要元素分類表 資料來源 : 深探網路服務 黃義焜譯

 介面描述(Interface Description)

［45］

:

XML schema 來定義，例如 int、float、long、short、byte、

string、boolean、date...等，而且可以包含複雜的型態，像 是結構和陣列，也包含這些為 SOAP 定義的部份。

範例 :

<wsdl:types>

<xsd:schema….>

<xsd:element name="division">

<xsd:complexType>

<xsd:sequence>

<xsd:element maxOccurs="1" minOccurs="1" name="in0"

type="xsd:int"/>

<xsd:element maxOccurs="1" minOccurs="1" name="in1"

type="xsd:int"/>

</xsd:sequence>

</xsd:complexType>

…

<wsdl:part name="parameters"

element="tns:substractResponse"> 文件的起點。其依據 input/output message 組合不同，可區 分四個主要的傳輸方式(Solicit-Response、Notification 尚 未支援)，如圖下所示 :

圖 11 WSDL Port Type 型式 範例 :

<wsdl:portType name="AdvancedMathPortType">

<wsdl:operation name="division">

<wsdl:input name="divisionRequest"

message="tns:divisionRequest">

</wsdl:input>

<wsdl:output name="divisionResponse"

message="tns:divisionResponse"> Port-Type 及 Message 所提到的資料元素部份。簡單來說，就 是 用 來 定 義 服 務 傳 輸 協 定 、 相 關 資 料 型 態 及 提 供 之 Operations。Binding 因為使用的協定而有三種不同的方式 (SOAP Binding、HTTP Get/Port Binding、MIME Binding)。

下章節會介紹什麼是 SOAP..

範例 :

<wsdl:binding name="AdvancedMathHttpBinding" …>

<wsdlsoap:binding style="document" …/>

<wsdl:operation name="division">

<wsdlsoap:operation soapAction=""/>

<wsdl:input name="divisionRequest">

<wsdlsoap:body use="literal"/> </wsdl:input>

<wsdl:output name="divisionResponse">

<wsdlsoap:body use="literal"/> </wsdl:output>

</wsdl:operation>

</wsdl:binding>

 執行描述(Implementation Description)［45］:

<wsdl:port name="AdvancedMathHttpPort"

binding="tns:AdvancedMathHttpBinding">

<wsdlsoap:address

location="http://localhost:7001/WebServicesToEJBApp/Advanced Math"/>

</wsdl:port>

</wsdl:service>

2.2.3 SOAP(Simple Object Access Protocol)

簡單物件取存協定(SOAP)，簡單來說就是在網際網路環境之下將溝通方 式標準化的通訊規範。它是一個獨立的訊息，可以獨自運作在不同的作業 系統與網路上面，例如在微軟的 Windows 或 Linux 的建構下運作，並可以 使用各種不同的通訊方式來傳輸，例如 SMTP、MIME，或是 HTTP 等。但大部 份是以 HTTP 傳輸協定來傳遞 XML 文件格式的內容。只要 Client 端能夠製

SOAP 的 XML Schema 架構可分為 Envelope、Header、Body 三個部份；

其組織架構是與 XML 的語法相結合應用。以下範例分別是 Web Services 借 由 SOAP 發出的 Request 及 Response XML 格式內容 :

其組織架構是與 XML 的語法相結合應用。以下範例分別是 Web Services 借 由 SOAP 發出的 Request 及 Response XML 格式內容 :

在文檔中 Object-Oriented Web Services 應用 - 解決JCOM在大量資料交換效能不佳的問題 (頁 13-54)