企业运算环境的历史

在以往数位资料与数位文件的交换问题上，常常会受限于特定且定义松散的文件格式，但随着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();
  struts2.nl OrderID = (nl1 

  // rgc Customer ID, 客户代码
  for (int i = 0; i ＜ 
      struct2.rgcCustomerID.length; i++)
  {
   struct2.rgcCustomerID[i] = (char)inputstream.read();
  }

  // rgc ProductID, 产品编号
  for (int i = 0; i ＜
     struct2.rgcProductID.length; i++)
  {
   struct2.rgcProductID[i] = (char)inputstream.read();
  }

  // Quantity, 产品数量
  n1 = inputstream.read();
  n2 = inputstream.read();
  struts2.Quantity = (n1 

  // options..., 其他选项
  while (true)
  {
   int nType = inputstream.read();
   if (Type 

   switch (nType)
   {
    case 1:
     Option1 option1 = new Option1();
     // nField 1A, 栏位1A
     n1 = inputstream.read();
     n2 = inputstream.read();
     n3 = inputstream.read();
     n4 = inputstream.read();
     option1.nField 1 = (n1 
     struct2.vectorOptions.addElement(option1);
     break;

    case 2:
     Option2 option2 = new Option2();
     // nField 2A, 栏位2A
     n1 = inputstream.read();
     n2 = inputstream.read();
     option2.nField 2A = (n1 
     // nField 2B, 栏位2B
     for (int i = 
       0; 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, 记录流水号
  24) & 0xFF);"outputstream.write((int)(struts2.nl OrderID  24) & 0xFF);
  16) & 0xFF);"outputstream.write((int)(struts2.nl OrderID  16) & 0xFF);
  8) & 0xFF);"outputstream.write((int)(struts2.nl OrderID  8) & 0xFF);
  outputstream.write((int)struct2.nlOrderID & 0xFF);

  // rgc Customer ID, 客户代码
  for (int i = 0; i 
  {
   outputstream.write(struct2.rgcCustomerID[i]);
  }

  // rgc ProductID, 产品编号
  for (int i = 0; i 
  {
   outputstream.write(struct2.rgcProductID[i]);
  }

  // Quantity, 产品数量
  8) & 0xFF);"outputstream.write((struts2.Quantity  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);
    // nField 1A, 栏位1A
    24) & 0xFF);"outputstream.write((option1.nField 1  24) & 0xFF);
    16) & 0xFF);"outputstream.write((option 1.Field 1  16) & 0xFF);
    8) & 0xFF);"outputstream.write((option 1.Field 1  8) & 0xFF);
    outputstream.write(option1.nField1A & 0xFF);
   }
   else if (object instanceof Option2)
   {
    Option2 option2 = (Option2)object;
    outputstream.write(2);
    // nField 2A, 栏位2A
    8) & 0xFF);"outputstream.write((option 2.Field 2  8) & 0xFF);
    outputstream.write(option2.nField2A & 0xFF);

    // nField 2B, 栏位2B
    for (int i = 0; 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 CustomerID (#PCDATA)＞
  ＜!ELEMENT ProductID (#PCDATA)＞
  ＜!ELEMENT Quantity (#PCDATA)＞
  ＜!ELEMENT Options (
   "Option1 | Option2 | Option 3)+ 
  "
  "
  "
  "
  "
  "
]＞

＜Order＞
 ＜OrderID＞15＜/OrderID＞
 RULES"RULES
 ＜ProductID＞DC123_44＜/ProductID＞
 ＜Quantity＞5＜/Quantity＞
 ＜Options＞
  "
  ＜Option2＞
   3"3
   ＜Field2B＞black＜/Field2B＞
  ＜/Option2＞
  ＜Option2＞
   2"2
   whiteField 2B"whiteField 2B
  ＜/Option2＞
 ＜/Options＞
＜/Order＞

Java的加入

在上例中，我们知道，有了XML的支援，我们可以建立具结构化的资料描述。首先，它提供了资料封装的特性，清楚的表示了资料的起始与结束，​​以单一的单元来看待结构化的资料。其次，XML语言提供了资料内容的结构关连，可以告知我们其中资料在该单元中的关系。最后，XML语言提供了所谓的诠释资讯(meta-information)。这些特色，共同造就了跨平台的资料描述特色。

那,Jar呢?

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的配合上，更进一步的探讨如何应用这两大资讯技术来加速企业的发展。