企業運算環境的歷史

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

這個XML標準可以允許企業根據自身的需求來定義自己專屬的標記語言，如電子商務、供需整合、資料管理以及資料出版等等。也就因為有著這樣的彈性，使得XML快速地成為企業資料的管理工具。XML中所定義的標記，可以以開放且跨平台的形式來呈現資料及概念，而用XML標記所描述的資料，則會擁有更大的重複使用可能。也就是因為如此，XML便成為許多特定產業中制定特殊用途標記語言的標準，而這些產業的投身參與，也共同造就了資訊快速共享與交換的運作環境。

如上所述，XML在企業中佔有著重要的地位，也影響了企業應用開發的內涵。在早期，企業中使用電腦來處理資料的模式，基本上是以部門為單位來構成，而相對地，在系統的開發上，也就會以部門為單位來進行開發。這樣演變的結果，形成了各個系統都是以甚為狹窄的資料處理為目標，所做到的只是將企業部門中特定的商業處理流程自動化而已，完全缺乏對外的溝通操作能力，也鮮少需要和其他部門的系統做整合。這樣的安排造就了所謂垂直整合(Stovepipe)系統，也就是說，在系統的開發上，完全是以特定使用者以及特定目標來進行，很少會見到所謂的水平整合需求。這樣的企業運算環境，就如同海中的孤島一般，如(圖一)所示。

《圖一　如海上孤島般的運算模式》

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

促進企業運算環境改變的力量

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

1.在企業中，隨著跨部門與跨功能商業應用需求的出現，使得整合目前各部門系統的腳步開始加快。

2.越來越多人意識到客戶資料不能被封閉在單一的孤島之中，而應該被視為企業的主體。

3.希望能夠整合廠商與客戶的系統需求日漸增加。

簡而言之，這些需求所引發的企業內部整合，會建立出一個新的運算模型，如(圖二)所示：

《圖二　企業整合後新的運算模型》

資料交換的議題

在以前系統的處理方法上，開發者鮮少會去想到所謂的資料交換議題。而這樣的結果，導致了所開發出來的資料介面，會隨著系統的不同而有所差異，且無法進行溝通。而在目前可以作為系統之間資料交換的模型，如RMI、RPC、 CORBA 以及COM等等，都是以所謂的共同介面方法來達到交換區塊資料的目的。但基本上，這些區塊資料本身並沒有描述自身的能力，也就是說，這些所謂的區塊資料本身並沒有描述自己的能力。這些所謂的區塊資料所代表的只有資料的開始與結束，以及資料欄位的格式而已，我們仍需要去使用額外的程式碼來解釋以及驗證這些資料的正確性。以(表一)為例，一個典型的訂購記錄定義了各欄位的位置、順序、以及內容資料的型態與大小。

《表一　一個典型的訂購記錄格式定義》

而(表二)則說明了一筆真實訂購記錄的內容。

《表二　一筆真實的訂購記錄內容》

以下處理訂購記錄的Java程式碼中，會將這類訂購資料讀入並加以處理：

import java.io.InputStream;
import java.io.OutputStream;
import java.io.IOException;
import java.util.Enumeration;

public class Class2
{
 public static void read(InputStream inputstream, Struct2 struct2)
 throws IOException
 {
  long nl1, nl2, nl3, nl4;
  int n1, n2, n3, n4;

  // nlOrderID, 記錄流水號
  nl1 = inputstream.read();
  nl2 = inputstream.read();
  nl3 = inputstream.read();
  nl4 = inputstream.read();
  struct2.nlOrderID = (nl1 ＜＜ 24) | (nl2 ＜＜ 16) | (nl3 ＜＜ 8) | nl4;

  // rgcCustomerID, 客戶代碼
  for (int i = 0; i ＜ 
      struct2.rgcCustomerID.length; i++)
  {
   struct2.rgcCustomerID[i] = (char)inputstream.read();
  }

  // rgcProductID, 產品編號
  for (int i = 0; i ＜
     struct2.rgcProductID.length; i++)
  {
   struct2.rgcProductID[i] = (char)inputstream.read();
  }

  // nQuantity, 產品數量
  n1 = inputstream.read();
  n2 = inputstream.read();
  struct2.nQuantity = (n1 ＜＜ 8) | n2;

  // options..., 其他選項
  while (true)
  {
   int nType = inputstream.read();
   if (nType ＜ 0) break;

   switch (nType)
   {
    case 1:
     Option1 option1 = new Option1();
     // nField1A, 欄位1A
     n1 = inputstream.read();
     n2 = inputstream.read();
     n3 = inputstream.read();
     n4 = inputstream.read();
     option1.nField1A = (n1 ＜＜ 24) | (n2 ＜＜ 16) | (n3 ＜＜ 8) | n4;
     struct2.vectorOptions.addElement(option1);
     break;

    case 2:
     Option2 option2 = new Option2();
     // nField2A, 欄位2A
     n1 = inputstream.read();
     n2 = inputstream.read();
     option2.nField2A = (n1 ＜＜ 8) | n2;
     // nField2B, 欄位2B
     for (int i = 
       0; i ＜ option2.rgcField2B.length; i++)
     {
      option2.rgcField2B[i] = (
                       char)inputstream.read();
     }
     struct2.vectorOptions.addElement(option2);
    break;

    default:
     Option3 option3 = new Option3();
     struct2.vectorOptions.addElement(option3);
     break;
   }
  }
 }

 public static void write(OutputStream outputstream, Struct2 struct2)
 throws IOException
 {
  // nlOrderID, 記錄流水號
  outputstream.write((int)(struct2.nlOrderID ＞＞＞ 24) & 0xFF);
  outputstream.write((int)(struct2.nlOrderID ＞＞＞ 16) & 0xFF);
  outputstream.write((int)(struct2.nlOrderID ＞＞＞ 8) & 0xFF);
  outputstream.write((int)struct2.nlOrderID & 0xFF);

  // rgcCustomerID, 客戶代碼
  for (int i = 0; i ＜ struct2.rgcCustomerID.length; i++)
  {
   outputstream.write(struct2.rgcCustomerID[i]);
  }

  // rgcProductID, 產品編號
  for (int i = 0; i ＜ struct2.rgcProductID.length; i++)
  {
   outputstream.write(struct2.rgcProductID[i]);
  }

  // nQuantity, 產品數量
  outputstream.write((struct2.nQuantity ＞＞＞ 8) & 0xFF);
  outputstream.write(struct2.nQuantity & 0xFF);
  Enumeration enumeration = struct2.vectorOptions.elements();
  while (enumeration.hasMoreElements())
  {
   Object object = enumeration.nextElement();
   if (object instanceof Option1)
   {
    Option1 option1 = (Option1)object;
    outputstream.write(1);
    // nField1A, 欄位1A
    outputstream.write((option1.nField1A ＞＞＞ 24) & 0xFF);
    outputstream.write((option1.nField1A ＞＞＞ 16) & 0xFF);
    outputstream.write((option1.nField1A ＞＞＞ 8) & 0xFF);
    outputstream.write(option1.nField1A & 0xFF);
   }
   else if (object instanceof Option2)
   {
    Option2 option2 = (Option2)object;
    outputstream.write(2);
    // nField2A, 欄位2A
    outputstream.write((option2.nField2A ＞＞＞ 8) & 0xFF);
    outputstream.write(option2.nField2A & 0xFF);

    // nField2B, 欄位2B
    for (int i = 0; i ＜ option2.rgcField2B.length; i++)
    {
     outputstream.write(option2.rgcField2B[i]);
    }
   }
   else
   {
    outputstream.write(3);
   }
  }
 }
}

在這裡，你將會發現，這樣的程式碼並不能為這樣的資料型態帶來任何的好處，同時這其中的程式大都是具有其專屬性，且不容易達到重複使用的目的。除此之外，在處理有彈性的資料(option)部份也需要在程式碼中加入一些商業應用的規則。總而言之，這樣的做法勢將系統開發在一個象牙塔之中，也就是因為如此，系統整合的工作將會變成大多是在做所謂的資料轉換工作以及程式除錯上。而對企業來說，開發資料轉換的工作往往是整個系統整合工作中最為困難的部份。

那XML之於資料交換呢？

接下來，我們來構思如何使用XML來描述一筆訂購資料。如下例所示， 一個XML記錄是由兩大部分所組成，首先是所謂的DTD(Document Type Definition)部份，DTD定義了文件中標記之間的架構關係，而這樣的定義可以讓分析器分析並確認文件的正確性。第二個部份則是訂購記錄本身，由XML標記所標示構成。你將會發現，在閱讀以及了解XML資料上有多麼的容易，而且即使沒有DTD的存在，XML分析器仍然可以決定這個文件是否是所謂的well-formed文件。因此，我們可以將使用XML的優點分述於後：

1.使用XML可以減少針對不資料做開發的成本。也就是說，我們可以使用一個XML分析器來根據DTD自動檢驗文件的結構與語法，同時也加強了商業運算的規則。而對應用程式本身來說，只需要驗證標記之間所包含的資料即可。

2.XML文件具有自身描述的特性。由於XML標記本身為文字敘述，同時又擁有一個定義完善的DTD，使得在開發資料轉換工具上，大大的減少了猜測的需要與負擔。

3.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＞

Java的加入

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

那，Java呢？

Java本身的跨平台運算能力在合作運算環境中早已獲得肯定。例如，XML-Dev討論群就利用Java技術開發出所謂的SAX(Simple API for XML)介面。SAX是一個以Java技術為基礎的程式介面，它允許應用程式將任何的XML分析器，整合進應用程式之中，以支援分析文件的特色。當我們一起使用XML以及Java技術之後，對企業內外的各項整合上，就會更具有相互運作的能力。以下我們簡單的介紹一下企業中各種型態的工作，在XML以及Java的支援下，如何簡化並增進這些工作的效率。

1.電子資料交換(Electronic Data Exchange)與電子商務方面

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

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

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

此外，內容與格式驗證的工作可以在處理的應用程式之外執行，甚至可以在不同的機器上來進行。這種方法的影響層面有二：首先，它可以降低處理機器的資源耗費，加速應用程式的處理效率。其次，這種方法提供了企業先對資料予以驗證，以決定接受或是拒絕資料，而不必再真正處理資料的當時才來對付資料本身所會發生的例外狀況。

當XML標記和Java技術結合之後，便可更輕易的電子資料交換的應用。理由很簡單：首先，Java平台是以網際網路為基礎，可以順利簡便的使用TCP/IP為交換資料兩端的通訊協定。因此，網際網路便可以順理成章的成為電子資料交換的平台。此外，XML與Java均以Unicode支援為基礎，可以提供企業在這方面的開發支援，以利建立國際性的應用程式。而使用了Unicode之後，應用程式便可以使用多國語言來呈現資料內容。因此，透過XML的資料交換格式，以及Java技術所開發的國際化應用程式，XML文件便可以在全球流通與交換。

2.電子資料交換EDI(Electronic Data Interchange)方面

EDI是一個特殊的資料交換環境，且大多是使用加值型網路(VAN, Value-Added Network)為傳輸媒介，並仰賴X12或是EDIFACT標準來交換所需要的資料。到目前為止，EDI仍是一個相當昂貴的運作環境，它需要各個資料交換單位自行設定及安裝。也就因如此，目前有不少企業以及單位正慎重的考慮採用XML語言，討論XML是否可以成為X12以及EDIFACT文件的標準格式，但目前仍未有任何決定性的進展。但是無論如何，眼前XML可以在這個領域中發揮的用途，是為EDI文件建立語彙以及格式的定義。這對於使用以X12以及EDIFACT文件為基礎的交換單位來說，特別有幫助，因為這些單位可以用XML來和EDI文件的結構綱要(schema)做溝通。而就長遠的目標來說，這樣的資訊可以成為自動交換處理程序的一部份，也可以藉此減少開發上所需要的成本。

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

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

《圖三　銷售系統與會計系統整合的範例》

一個企業可以使用幾種不同的方式來完成EAI的工作，其中有些方式便會使用XML來支援。舉例來說，當我們在應用程式中使用訊息傳遞時，通訊應用程式便需要能夠了解訊息的格式。因此，對兩端的應用程式來說，就必須要能夠了解特定的結構化資料，而XML正可以在EAI中輕易地達到結構化資料呈現的目的。而另一種形式的整合，則是使用共同的資料媒介，如資料庫或是記憶體。企業中的商業資料是由多個不同的資料來源匯集而成，而以一個結構化的文件方式來呈現給其他的應用程式。在會計與銷售系統的整合範例中，這些匯集的資料包含了所有需要呈現銷售交易的訊息，而這些資料所形成的文件則存放在共同的資料媒介上，而由銷售系統或是會計系統來存取。

由於Java平台支援各種中介服務的連結，如資料庫、交易處理監控程式、非同步訊息傳系統、以及物件需求媒介，使得Java成為開發EAI最有利的工具之一。而在Java企業應用程式開發介面上，包括了Enterprise JavaBeans架構、Java IDL、JDBC、JMS(Java Messaging Service)、JNDI(Java Naming and Directory Interface)、JTS(Java Transaction Service) API。這些介面共同提供開發者和許多非Java環境之間的溝通工具。而XML便可以用來在Java環境與非Java環境之間扮演呈現Java物件資料的重要角色。

資料出版方面

XML語言，承襲了許多SGML原有的特色，也很適合用在出版事業上。事實上，在W3C所制定XML標準的本意來說，本來就大多是為了出版的目的來訂定。XML可以提供出版業許多組織文件的方法，以達到最大的重複使用性。例如，它可以用來在車主使用手冊中呈現類似以及和汽車相關的段落。這樣一來，便可以提供最大的內容重複利用性，而除了能夠簡化內容的組織之外，XML技術也可以用在簡化不同格式輸出的需求。舉例來說，XSL(Extensible Stylesheet Language)是一種用來描述如何轉換文件的XML應用，它可以用來對單一個XML文件產生針對不同媒體的格式輸出，如印表機、繪圖機、以及印刷廠等等。

除了支援傳統的出版目的之外，XML技術也可以用在新的電子出版事業上，也就是說，XML可以用來標記圖形、視訊資料、聲音資料、以及其他非文字性的資料物件。這樣一來便可以在應用程式中提供這些媒體索引、搜尋、以及操作等等的功能。

雖然有了以上的功能，但是出版業絕對不只是包括組織內容及重製工作而已。在工作流程以及儲存問題上，是一個好的出版環境中最重要的兩個環節，需要特別的商業運算邏輯來處理。這也就是Java技術得以發揮的地方。由於Java平台有著對網路及儲存方面良好的處理能力，使得它對出版環境來說，是個相當適用的運作平台。運用Java環境，便可以建立良好的出版共享環境，包括處理創作、文件處理、文件流通、工作流程、以及延件儲存。

軟體開發方面

在軟體開發方面，XML主要的影響層面有三：一是軟體架構的共享，一是建立陳述性的環境，一是提供描述的功能。以下將探討這三個層面。

在1999年2月，OMG(Object Management Group)公開宣佈將採用XMI(XML Metadata Interchange)標準，XMI是以XML為基礎所定義的語彙集合，描述了使用UML所設計的應用程式架構。UML是一組標準的規則，可以用來描述系統單元以及單元之間的關係。一旦採用了XMI，我們便可以在一個大規模的開發團隊中共想一個單一的UML模型，繼而增進開發團隊的生產效率。此外，由於整個模型是由XML所描述，因此就可以做到集中式的管理，從而便利版本控制(version control)方面的問題。

XMI顯示了如何利用XML來簡化軟體開發的過程，但是它也可以簡化整體系統的設計。因為XML是將內容植入在文件之中，所以以XML技術為基礎的應用便是一種陳述性的應用程式。一個陳述性的應用程式可以決定一個文件對自身的定義，而傳統的應用程式則會針對文件做一些假設，因此便需要使用預先定義好的邏輯來進行處理。一個陳述性的環境則會先分析檔案並檢視其正確性，接著決定檔案的型態，最後才會根據檔案的型態來採取一系列的動作。

陳述性的環境的概念目前已經相當的流行，特別是在商業規則的處理方面。這些應用允許開發者先宣告一組規則，然後將這些規則交給一個規則處理引擎，該引擎則會根據其中檢視的資料來進行動作與規則的配對。XML技術也可以提供開發者定義及處理自己的描述語言，因此，XML是定位為一種詮釋性的語言(meta-language)，可以用來建立其他任何的語言，包括描述語言。這方面正是除了XML強大的功能之外，業界也正在探索中的XML能力之一。

後記

本文介紹了XML的特性，以及XML與Java的配合如何在企業應用上發揮其影響力。可以想見的，由於XML本身所具有的彈性，以及Java本身所具有的跨平台及網路的優勢，在兩者的合作之下，可以發揮出來的影響不容忽視。下一期我們將會針對Java與XML的配合上，更進一步的探討如何應用這兩大資訊技術來加速企業的發展。