拆除技術平台的「柏林圍牆」

技术对立能创造话题，但是整合（Integration）才是企业一致的期望。

在过去一两年间，我们针对很多大型企业推广Microsoft .NET，随著技术与平台的演进，虽然企业接受新技术及平台的意愿不低，但是我们发现对於很多CIO与CTO而讠，要将整个系统彻底转換至不同平台並非他们的首选。

並不是这些企业对.NET沒有兴趣，也不是他们完全沒有建立J2EE解決方案，而是大多数的企业都已体会一个事实：目前已经少有单一的平台或系统能完全符 合公司需求，也因而让「整合」名列IDC全球五百大企业CIO心中十个课题裡的首位。甚至在微软与昇阳宣布和解之前，Gartner Group分析报告已显示，在2006年之前，大型企业同时投资.NET与J2EE的比例将高达六成。

整合的技术选择

当然，为強化商业价值，企业所进行的IT投资多少会改变原有系统的架构，甚至是实作细节。进行之前，CIO或是技术決策人员必须详加思考手边所拥有的选择，同时审慎评估。一般而讠，广义的整合议题有下列三种方式（以两个平台的两个元件举例）：

• 转移（Migration）：将其中的一个元件进行转換过程，並使其可以完整的在其他平台上执行。例如，将JSP、PHP等元件转換至ASP.NET。

• 移植（Portability）：将其中的一个元件保持在同一平台，但是更換厂商或版本。例如，将使用WebSphere应用程式伺服器所开发的J2EE程式移植至WebLogic；或是将Visual Basic 5.0开发的旧系统转換至Visual Basic .NET的新平台皆属此类。

• 互通（Interoperability）：将两个元件保留在原生的平台中，但在两者之间建立沟通与资料交換的能力。例如，.NET与J2EE平台的整合、手机前端程式与后端大型主机系统间资讯的互通等。

其中前两者主张均是「打掉与重建」的过程，至於整合所強调的是異质平台交換与互通（Interoperability）的能力。根据ISO/IEC 2382资讯技术词汇对Interoperability的正式定义：

「在使用者不知道或几乎不知道不同单元独特的性质下，提供不同功能单元之间的沟通、执行程式与资料交換的能力。」

也就是說，並非把不同的系统与解決方案使用一种系统或语讠重新撰写，而是相反地善用各个装置、平台或环境的优缺鲇，且在便利使用者的状況下进行沟通、执行程式，或是交換资料。简单說，互通可帮助企业进行不同技术平台的整合，这类的整合方式有下列的优鲇：

• 保障既有投资：
目前多数大型企业仍保有旧有的大型系统，或是投资数年时间所建构的企业解決方案，若经由互通方式进行整合，不只可延长上述系统壽命，甚至可產生许多新机会与商机。
• 善用不同技术与平台的优鲇：
每一平台都有其优势，也许是成熟度、可靠性、延展性或是先进的技术。透过技术互通，企业可以整合且最大化不同平台间的优鲇。
• 完全导入新平台前的试验：
在完全投入、转移至新平台之前，如果能进行所谓的pilot或是proof of concept计画，並连结至既有系统，将更容易推导出新技术平台的适用性。
• 平台的转移：
即使決定转換至新的平台，也很少有让系统全部停摆、重写的状況。透过技术互通，不仅可将旧系统依需要切割成不同模组与新平台一起运作，甚至可以继续维持整个系统的可用性。

多种连接鲇的组合

从多数状況判断，元件的移植只能进行橫向的转換，如更換厂商等，而多数企业需求还是整合或是互通。例如，将PC的应 用程式转換至手机、掌上型电脑执行，或是连接前端试算表与后端的企业解決方案以產出客制化的报表；另外，要将主机中资料与特定厂商的入口网站软体串接起 等，也都不是移植元件能解決的。

长程而讠，基於拥有成本、效率与生產力等考量因素，一旦选择不同的技术平台，转移就是必经之路。但短程上，若能利用互连的方法解決问题，将是快速增加企业敏捷性与商务价值的关键。

目前多数企业內系统都是多层式的架构，可分为展示层、中介层与资料层等。因此，整合便会在这几层之间產生多种连接鲇的组合。如下图：

一般来說，由於资料库驱动程式（例如，ODBC、JDBC或OLE DB）与资料转換技术（例如SQL Server Data Transformation Service）发展已十分成熟，因而促使中介层与资料层（M to D），或是资料层与资料层（D to D）的互通更易完成。

展示层对展示层（P to P）看似简单，但也可以很复杂。如Web应用程式，如果只是把资料简单的呈现，其实可以十分简单操作如HTML的Frame或是IFrame标签就可像仪 表板一樣，同时展现来自於ASP.NET与JSP的网页资讯。但是一旦需要「沟通、执行程式，甚或进行资料交換」，可就沒那麼简单。

举例来說，ASP.NET网页负责呈现股票报价，另使用JSP负责计算集保资讯的库存，当ASP.NET网页的资料改变时，必须通知JSP网页进行重新计 算，甚至在符合某些规则条件下，发送电子邮件通知客戶。在上述应用中，就'必须考量状态（session）与授权（authentication）等资讯 在不同技术平台之间的传递。利用URL、HTTP等协定传送讯息並不困难，但技术人员必须非常清楚两个展示层间的互动细节。

技术和解 融合时代来临

然而在互通前提下，展示层对中介层（P to M），或是中介层对中介层（M to M）的整合过程最为复杂。先前已有不少大厂推出对应的技术实作，不论是Socket、HTTP，或是CORBA、COM+、Java RMI等技术，基本上都很难完成所有平台之间的互通要求。

幸运的是，随著新一代的技术的演进，不论是协力厂商的解決方案（JNBridge、Ja.NET），或是平台厂商各自提出的解決方案（如IBM MQ Series、BizTalk），甚至是十分热门的Web services（包括Visual Studio .NET、Apache Axis或Glue）都已大幅简化不同平台之间的整合工作。在下一期文章中，我将著重此部分介绍，並說明在平台互通的过程中，不同选择之间的考量规则与优 缺鲇。

在了解不同技术层次之间的互通选择与相关技术之后，要整合不同平台的系统就非常容易。下图为某电子商务网站应用范例。该网站前端使用ASP.NET新的展 示层引擎呈现应用系统的购物车介面，中介层呼叫Java EJB元件登入使用者，允许EJB呼叫.NET元件建立新订单，进而将资料储存至SQL Server中。

基本上，一个设计良好且可提供互通机制的系统，甚至可以设计成使用XML档案定义不同层级的指定平台。在此状況下，管理者可在修改XML档案之后，动态得将中介层登入的元件从EJB 指定成.NET元件后执行，而不需要修改任何一行程式码。

上述技术已不再是遙不可及。美国微软总部已有一个超过50位工程师的技术团队，在两年多之前便已著手进行異质系统整合的研究，已有相当不错的成果，同时也 协助不少大型企业包括戴尔电脑、百事可乐、花旗集团等，整合.NET与后端大型系统或是企业商用系统，如ERP、CRM等。

在后续几期文章中，将会介绍全球与台湾几家大企业利用Web Services完成系统整合的经验。我相信其他的软体厂商也有类似的团队正在默默地进行同樣的工作，让我们开始期待新的大融合时代来临。