XML大行其道

XML大行其道  

随着企业数据逐渐以XML格式应用在多种软件程序之际，有一通用的XML框架正逐渐成形，以支持协同功能的发展。

以往，协同功能祇是一独立的应用程序，但近期已有多家厂商利用该功能将遍布于IT基本架构中的XML数据排列于应用程序间，以利其运作。

Aberdeen Group研究主任Dana Gardner表示，目前XML已深入各类企业应用程序中。而运用XML框架的企业数据，不但可优化生产力，也将建立更丰富和个人化的应用程序。

为顺应XML潮流，一家位于加州Mountain View的新兴公司－Vayusphere也于日前推出一结合企业IM（实时传讯）与应用整合闸门的软件平台，以连结使用者与后端应用程序。

该公司推出的IRiS（Instant Response Server）2.0在企业应用程序和IM网络间，使用XML和其它如SOAP（Simple Object Access Protocol）及WSDL（Web Services Description Language）的网站服务协议，以在员工和应用程序间建立对话。

Vayusphere行销副总Malcolm Lewis表示，一改以往在每一应用程序内使用特定技术，IRiS可当成单一存取点以达成与行动工作整合的目的。

无独有偶的是，包括Inktomi、Verity及Fast Search&Transfer等企业搜寻厂商也相继使用XML萃取结构化和未结构化数据中的数据。

为萃取应用程序内容，Inktomi Search Toolkit及Fast Data Search 3.0运用XML并配合Xquery标准，将关键词搜寻与结构化查询作结合，并从数据库和XML输入中进行参数式搜寻。而Verity推出的K2 Developer则具备搜寻及取得XML文件、XML metatag的功能。

另外，整合厂商Tibco Software和Enosys也积极地运用XML以存取多个资料来源。

Tibco日前推出的BPM 2.0（Business Process Management）可管理分散的网站服务组件，以及支持网站服务所需的XML超数据（metadata）。而Enosys Software之数据整合软件则可裨益使用者透过XML及Xquery引擎于防火墙内、外部存取不同的资料来源。

同时，传统的协同应用供货商（如IBM的Lotus Software）也正密切注意XML在应用程序间所扮演的协同角色。Lotus产品管理资深经理Heidi Votaw则指出，XML是目前Lotus推展协同功能至Notes客户端间的技术之一。

Votaw表示，XML为IBM开启了一扇整合的大门。传统上，该公司被局限在Notes间的整合关系中，由于XML和HTML的支持让IBM得以将触角延伸，并和传统Lotus产品外的使用者合作。同时，其也认为：「大多企业如对XML均持欢迎的态度，将裨益IBM旗下之技术与厂商之应用程序整合地更好。」

未来， XML将是Lotus和IBM网站服务策略中的另一垫脚石。目前，Lotus正计划将其整合技术内嵌至多种IBM应用程序和软件系统中。

而就在XML逐渐成为应用程序间交换数据的标准之时，基本架构厂商（如Nortel Networks）也开始建立具备协同功能的平台。

Nortel推出的IMS（Interactive Media Server）通讯服务器可裨益企业透过VOIP（voice over IP）进行视讯会议与实时传讯。

Appmail整合一切

无仔细研究人们的工作模式为目前许多整合方案不具人性化的原因。对大多分散的公司而言，使用方便且无所不在的电子邮件已成为企业之首选工具。尽管如此，透过电子邮件进行整合不仅易使讨论议点偏离，也极易忽略真正的参与者而让不相关的人士参与讨论。

相较于一些借用Weblog概念以捕捉讨论串的新颖工具，测试者认为，Zaplet Appmail 2.0所提供之Appmail功能较实际。多数人应同意其是被收到的电子邮件牵着鼻子走的：透过email收件匣，人们得以了解公司的政策，并用以排列工作的顺序。Appmail不仅可裨益企业继续使用熟悉的电子邮件工具，也可以一中央化的方式解决系统间差异问题。

尽管测试者Appmail 2.0的价格并非所有小型公司都能负担，但测试者认为该款产品值得企业添购。相较于部分产品将多个讨论串和讯息复本储存在负担过重的邮件服务器上，该产品将使用者导向Appmail服务器，以维持企业程序的一贯观点。

同时，Appmail可配合多种电子邮件客户端使用，包括Eudora、IBM/Lotus Notes、Microsoft Outlook及Outlook Express、Netscape Messenger，或是任何支持HTML的邮件程序，不过安全预设可能需要稍作调整方能使用。而后端要求则包括BEA WebLogic应用程序服务器及Oracle8i数据库。尽管该家厂商并未承诺，但测试者仍期盼Appmail能于日后纳入对其它应用程序和数据库服务器平台的支持，如此该产品才能获得广大的接受度。

Appmail主要是由预先定义及自订之可重复使用程序代码的「建构区块」所组成。而这些组件包括两个主要部分：以Java class或EJB（Enterprise JavaBean）形态呈现的业务逻辑，具有定义区块的作用；以一组JSP（Java Server Pages）所呈现的逻辑，则可定义使用者界面。

建构区块和相关的Appmail容器配合，而容器从中所扮演的角色就如同组件在应用程序中所处之控制器阶段；协助Appmail容器作存取动作的servlet，其功能就如控制器，不仅须因应HTTP的要求，并将该请求转变成萃取对象的要求。而转换后的要求将被传送至适当的建构区块进行处理并呈现逻辑，以成为一HTML响应的数据对象。为提供最后输出给使用者，呈现控制器需先结合来自各建构区块的HTML响应，之后规则引擎和其它的平台服务将可完成整个包装（Package）。

目前Appmail建构区块的同步／异步联机能力仅支持J2EE（Java 2 Enterprise Edition）Connector Architecture和JMS（Java Message Service）等Java语言。只需透过Appmail SDK的网站服务，包裹将可藉由HTTP或JMS传送的XML讯息以因应SOAP（Simple Object Access Protocol）的要求，进而提升与现有协力厂商系统的协调能力。

无需仰赖Java发展人员，一般用户即可自行建立简单的Appmail应用程序，同时Appmail提供之SDK不但能便利企业进行内部设定，其亦可与旧系统沟通。而该产品内附约二十种预先定义的区块，可提供诸如日历功能、项目流程等功能。

现阶段由于Zaplet建议由企业内部的工程师或是系统整合商来执行设定动作，因此Appmail的安装程序相当简易，日后厂商将推出客户可自行安装的版本。尽管Zaplet再三保证该目标已不远矣，然测试者仍认为该梦想近期内将难以实现。假设Oracle和WebLogic已预备完成，用户可能要花费半小时的时间以安装及设定Appmail。

当企业训练预算不断下降时，Appmail之简易性及统一性为该产品最大的优势。由于Appmail整合了整个过程流程，因此其提供观看整个讨论的功能，而无须强迫使用者手动组织一连串的电子邮件讯息，或屈于一组过度自动化、却无法涵盖所有状况的响应。尽管Zaplet Appmail 2.0并非十全十美，测试者仍认为，任何期盼填补运作间隙的公司都应考虑该产品。

本文原载于环球咨询网站