前言

在資訊技術進步的今天，許許多多的企業都受惠於新時代的網路技術，發展出各式各樣足以提昇其競爭力的運作模式以及企業軟體。而這些所謂的企業軟體，就資訊技術的觀點而言，可以分為兩大層面來看：一是所謂的資訊運作架構，一是所謂的資訊呈現與交換。

在資訊運作方面，目前已經由單一應用程式（single application）或是傳統的主從式架構（client/server architecture），逐漸演變成擁有良好擴充性質（scalability）的多層次運作架構（multi-tier service architecture）。而在資訊呈現與運作方面，也由傳統的封閉式自訂規格（private data format specification），逐漸走向開放式的描述標準（public data description standard）。

對使用傳統資訊技術的企業來說，近幾年正受到新式網路技術所帶來的衝擊，以及企業自身發展的瓶頸，亟思應變與生存之道：如何改良以往的集中式服務運作，降低企業伺服端的負載；如何因應開放式的網路資訊交換，將部分的企業資訊轉為符合開放式的標準；同時更因應擴大的企業組織與規模，發展出容易組態以及使用的軟體模組。

整體來說，企業所需要的，是取代傳統「肥胖」運作系統的資訊技術，以及更便利企業間資料交換的資訊「描述」標準。這一切一切的需求，正需要資訊技術進一步的努力與支援。我們今天所要討論的，正是針對上述的需求，為讀者做一個廣泛的探討。本文將會針對幾項重點進行討論：資料與應用程式的整合、行動與分散式計算、以及通用形式的資料交換。

為軟體瘦身：使用適合Internet的Java技術

Java是一種高階的程式設計語言，由於它是在Internet時代中出生的，因此自然而然的擁有許多網路時代應有的特點：

而在使用Java程式語言上，則可以在許多方面輔助程式設計者，如下所述：

1.進入的學習障礙較低：

雖然Java是一種強大的物件導向式語言，但是它仍是一種容易學習的程式語言，特別是對已經熟悉C++的程式設計師來說，更是如此。

2.程式碼較為精簡：

就各項比較標準而言，我們可以很容易的了解到，平均來說，Java程式比起相同功能的C++程式而言，C++程式約是Java程式碼的四倍大。

3.程式碼較為優良：

如果使用Java為程式設計語言，Java本身的特性將會驅使程式設計師趨向較為良好的程式設計習慣，同時Java系統中的記憶體回收系統（garbage collector）也可以避免程式設計所造成的各項記憶體配置問題。此外，Java架構本身所定義的各項可重複使用的元件，可以有效的降低程式設計師的設計負擔，以及更加便利的除錯環境。

4.更有效率地開發程式：

使用Java將可以較C++降低50%的開發時間。

5.與平台架構無關：

如果使用100%的純Java來開發程式，將可以造就具有可移植性的程式碼，而不在需要仰賴其他與平台相關的連結程式庫。

6.可輕易地散佈軟體程式：

由於Java具有程式碼的可移動性（code mobility），利用透過網路傳遞Java程式碼的途徑，我們將可以輕易地達到程式碼升級的目的，而不必重新編譯程式碼，也不必再安裝程式。

由以上的特性，我們可以清楚的知道，使用Java之後，我們將可以在不犧牲軟體規模的情況下，有效地減少程式碼的大小，進而達到軟體瘦身的目的。

讓資訊清晰：使用適合資料交換的XML技術

在以往數位資料與數位文件的交換問題上，常常會受限於特定且定義鬆散的文件格式，但隨著HTML的出現，我們可以透過Web瀏覽器來展示互動性的資料。這提供了企業一個標準的資料交換途徑，用以交換具互動性的視覺化資料。但是HTML仍然有一些潛在的不足，因為HTML並不能夠支援所有企業中所使用的資料型態，所以即使HTML目前算是個定義完善的標記語言，仍然無法適用於所有種類的企業環境之中。

這些潛在的不足，共同促成了後來XML (Extensible Markup Language)的出現。這個XML標準可以允許企業根據自身的需求來定義自己專屬的標記語言，如電子商務、供需整合、資料管理、以及資料出版等等。也就因為有著這樣的彈性，使得XML快速地成為企業資料的管理工具。

XML中所定義的標記，可以以開放且跨平台的形式來呈現資料及概念，而用XML標記所描述的資料，則會擁有更大的重複使用可能。也就是因為如此，XML便成為許多特定產業中制定特殊用途標記語言的標準，而這些產業的投身參與，也共同造就了資訊快速共享與交換的運作環境。

如上所述，XML在企業中佔有著重要的地位，也影響了企業應用開發的內涵。在早期，企業中使用電腦來處理資料的模式，基本上是以部門為單位來構成，而相對地，在系統的開發上，也就會以部門為單位來進行開發。這樣演變的結果，形成了各個系統都是以甚為狹窄的資料處理為目標，所做到的只是將企業部門中特定的商業處理流程自動化而已，完全缺乏對外的溝通操作能力，也鮮少需要和其他部門的系統做整合。

這樣的安排造就了所謂垂直整合(Stovepipe)系統，也就是說，在系統的開發上，完全是以特定使用者以及特定目標來進行，很少會見到所謂的水平整合需求。這樣的企業運算環境，就如同海中的孤島一般。而這樣的模式下，會產生兩個相當嚴重的問題。

首先，系統之沒有相互運作的能力。也就是說，要在系統之間做資料的操作幾乎是沒有可能。其次，重要的商業資料會因此有建立複本的需要。而這些問題的存在，使得企業難以針對客戶建立單一且複雜的資料應用環境。因此，這樣的商業運算模型的確有其改進的必要。

針對上述所謂的「孤島」運算環境，出現了三股主要的力量來推動其變革，如下所述：

簡而言之，這些需求所引發了企業內部整合，便促成並建立出一個新的運算模型。而這個新的模型，正是以XML為資料核心的運作模式。以下以一個訂購範例來呈現XML具有清楚描述資料的特性：

＜?xml version="1.0" ?＞

＜!DOCTYPE Order [
  ＜!ELEMENT Order (OrderID, 
                   CustomerID, 
                   ProductID, 
                   Quantity, 
                   Options*)＞
  ＜!ELEMENT OrderID (#PCDATA)＞
  ＜!ELEMENT CustomerID (#PCDATA)＞
  ＜!ELEMENT ProductID (#PCDATA)＞
  ＜!ELEMENT Quantity (#PCDATA)＞
  ＜!ELEMENT Options (
   Option1 | Option2 | Option3)+ ＞
  ＜!ELEMENT Option1 (Field1A)＞
  ＜!ELEMENT Option2 (Field2A, Field2B)＞
  ＜!ELEMENT Option3 EMPTY ＞
  ＜!ELEMENT Field1A (#PCDATA)＞
  ＜!ELEMENT Field2A (#PCDATA)＞
  ＜!ELEMENT Field2B (#PCDATA)＞
]＞

＜Order＞
 ＜OrderID＞15＜/OrderID＞
 ＜CustomerID＞RULDS＜/CustomerID＞
 ＜ProductID＞DC123_44＜/ProductID＞
 ＜Quantity＞5＜/Quantity＞
 ＜Options＞
  ＜Option3/＞
  ＜Option2＞
   ＜Field2A＞3＜/Field2A＞
   ＜Field2B＞black＜/Field2B＞
  ＜/Option2＞
  ＜Option2＞
   ＜Field2A＞2＜/Field2A＞
   ＜Field2B＞white＜/Field2B＞
  ＜/Option2＞
 ＜/Options＞
＜/Order＞

當XML碰上Java：企業運作優勢的再提昇

我們知道，有了XML的支援，我們可以建立具結構化的資料描述。首先，它提供了資料封裝的特性，清楚的表示了資料的起始與結束，以單一的單元來看待結構化的資料。其次，XML語言提供了資料內容的結構關連，可以告知我們其中資料在該單元中的關係。最後，XML語言提供了所謂的詮釋資訊(meta-information)。這些特色，共同造就了跨平台的資料描述特色。

那Java呢？Java本身的跨平台運算能力在合作運算環境中早已獲得肯定。例如，XML-Dev討論群就利用Java技術開發出所謂的SAX(Simple API for XML)介面。SAX是一個以Java技術為基礎的程式介面，它允許應用程式將任何的XML分析器，整合進應用程式之中，以支援分析文件的特色。

當我們一起使用XML以及Java技術之後，對企業內外的各項整合上，就會更具有相互運作的能力。同時也因為Java的各項特性（如網際網路導向、精簡的程式碼、程式碼具有可移動性、獨立於軟硬體平台之外），使得在Java與XML的結合後，所能呈現出來的影響力，將是重要且無法將其忽略的。以下我們簡單的介紹一下企業中各種型態的工作，在XML以及Java的支援下，如何簡化並增進這些工作的效率。

電子資料交換(Electronic Data Exchange)與電子商務

基本上，要處理其他部門或是其他企業的資料，必須先去了解一些相關的知識，如通訊、網路、資料處理等等，這樣的工作似乎應該是件簡單的工作，但是事實上卻不是那麼的理想。在這種簡單的資料交換工作中，如何確認資料的格式與內容的正確性仍然是最主要的癥結。因此，應用XML來解決以往的問題，的確可以達到快速與簡單的開發目的，理由如下：

1. 非標準格式的電子資料交換需要開發者建立一個專屬的分析器，以應付特定的資料格式。而XML技術可以使用標準的XML分析器來解決這部份的需求。

2. 一個XML分析器可以馬上提供部份內容的檢驗功能，以確保所有必要的欄位都能夠以正確的規則存在，但是這樣的工作需要一個DTD來配合。而其他的內容正確性確認工作則可以開發以W3C DOM(Document Object Model)為基礎的應用程式來予以處理。DOM是一個程式開發介面，用以便利XML文件的檢視。而我們則可以應用欄位驗證規則來驗證文件中的元素內容。

當XML標記和Java技術結合之後，便可更輕易的電子資料交換的應用。理由很簡單：首先，Java平台是以網際網路為基礎，可以順利簡便的使用TCP/IP為交換資料兩端的通訊協定。因此，網際網路便可以順理成章的成為電子資料交換的平台。

此外，XML與Java均以Unicode支援為基礎，可以提供企業在這方面的開發支援，以利建立國際性的應用程式。而使用了Unicode之後，應用程式便可以使用多國語言來呈現資料內容。因此，透過XML的資料交換格式，以及Java技術所開發的國際化應用程式，XML文件便可以在全球流通與交換。

電子資料交換EDI(Electronic Data Interchange)

EDI是一個特殊的資料交換環境，且大多是使用加值型網路(VAN, Value-Added Network)為傳輸媒介，並仰賴X12或是EDIFACT標準來交換所需要的資料。

到目前為止，EDI仍是一個相當昂貴的運作環境，它需要各個資料交換單位自行設定及安裝，也就是因如此，目前有不少企業以及單位正慎重的考慮採用XML語言，討論XML是否可以成為X12以及EDIFACT文件的標準格式，但目前仍未有任何決定性的進展。

但是無論如何，眼前XML可以在這個領域中發揮的用途，是為EDI文件建立語彙以及格式的定義。這對於使用以X12以及EDIFACT文件為基礎的交換單位來說，特別有幫助，因為這些單位可以用XML來和EDI文件的結構綱要(schema)做溝通。而就長遠的目標來說，這樣的資訊可以成為自動交換處理程序的一部份，也可以藉此減少開發上所需要的成本。

企業應用程式整合(EAI, Enterprise Application Integration)方面

企業應用程式整合的定義，就是如何使企業中一個個獨立運作的應用程式，在組合之後能夠成為一個大型的單一應用程式。這是項艱鉅且複雜的工作，因為這需要在正確的時間內將正確的資料做複製或是分散到正確的系統單元中。例如，當會計系統和銷售系統整合起來之後，銷售系統會將訂購資料送給會計系統，從而產生發票資料。此外，會計系統也必須將發票資料送給銷售系統以更新銷售記錄。如果流程正確無誤的完成的話，一個單一的銷售交易可以自動產生一筆銷售記錄與發票，避免了人為資料輸入所可能產生的錯誤。

由於Java平台支援各種中介服務的連結，如資料庫、交易處理監控程式、非同步訊息傳系統、以及物件需求媒介，使得Java成為開發EAI最有利的工具之一。而在Java企業應用程式開發介面上，更以J2EE平台為基礎，發展出各項支援企業運作的標準，包括Enterprise JavaBeans架構、Java IDL(Java遠端物件運作介面定義語言，Java Interface Definition Language)、JDBC(資料庫連結服務，Java Database Connectivity)、JMS(訊息傳遞服務，Java Messaging Service)、JNDI(名稱與目錄查詢介面，Java Naming and Directory Interface)、JTS(交易服務介面，Java Transaction Service) API。

這些介面共同提供開發者和許多非Java環境之間的溝通工具。而XML便可以用來在Java環境與非Java環境之間扮演呈現Java物件資料的重要角色。下圖說明了在J2EE架構下如何將企業應用程式與XML資料交換做一個良好的整合。請參考(圖一)。

《圖一　在J2EE架構下企業應用程式與XML資料交換的整合》

後記

由以上的討論，我們可以清楚的了解到，讓軟體瘦身，特別是企業軟體，是相當重要的。同時，讓企業資料清晰且透明，則是通往開放資料交換目標的不二法門。可以想見的，由於XML本身所具有的彈性，以及Java本身所具有的跨平台及網路的優勢，在兩者的合作之下，可以發揮出來的影響不容忽視。

因此，一個以XML為基礎的伺服架構，配合Java所發展出來的多階層式的企業服務，將能夠有效地達到「軟體瘦身、資訊清晰」的目標，進而達成企業競爭力提昇的最終目的。