售后服务EAI和W服务.docx

1、售后服务EAI和W服务（售后服务）EAI和W服务EAI和Web服务-轻松进行企业应用集成内容：什么是企业应用集成?EAI类型用户界面集成(界面重组)数据集成商务流程集成函数或方法集成Web服务EAI和Web服务传统EAI解决方案和Web服务之间的显著的不同用Web服务的EAI示例从哪里开始结论参考资料作者简介关联内容：什么是Web服务?柴晓路(fenniveluddi-china.org)ChiefSystemArchitect2001年10月30日通过壹个被Web标准支持的方法而不是壹个有私有知识产权的系统，Web服务提供壹个中立的平台来集成应用程序，从而被用于集成不同的应用系统。依靠Web

2、服务，企业能够实时地访问不同部门、不同应用、不同平台和不同系统的信息，这已是Web服务被接受的最重要和最有力的因素之壹。于企业冒险于B2B中使用Web服务实施应用集成之前，企业应当首先于他们内部的非面向事务的壹般商业流程集成中使用Web服务。本文所引用的资源主要包括俩类，壹类是Web服务的技术资源网站，包含了大量Web服务的技术信息，另壹类是Web服务“stack系列技术规范，他们是壹个整体的技术体系，包括UDDI、SOAP、WSDL、XML等。本文的最后给出了这些资源的链接，有兴趣的读者能够通过这些资源链接找到所需的内容。我们知道，大多数企业均有由过去遗留下来的异构的系统、应用、商务流程以及

3、数据源构成的应用环境。应用环境的通信情况是混乱的，只有很少的接口文档，且且维护代价也非常的昂贵。而数字时代市场的合且又提出了壹些附加的问题，即公司的联合和兼且能够指数级的增加系统综合的复杂性。当企业向B2B电子商务协作方向迁移时，他们首先要做的是审视他们内部的系统、应用以及商务流程。壹些商务流程会横跨多个内部应用，于企业能够有效的和外部网络连接之前，这些应用必须能够实时动态的进行通讯。Figure1.点对点的B2B应用互联随着诸如企业资源规划(ERP)、客户关系管理(CRM)、供应链管理(SCM)以及企业门户(EnterprisePortal)等多种商业应用的引入，激增了企业信息系统的应用分割

4、。早期这些系统被设计成自包含的黒盒系统，只有很少或者更本没有方法来访问它内部的数据和商务流程。虽然当下许多这些应用均提供了更好的访问他们的内部数据和商业逻辑的方法，可是把这些系统和企业里其他系统集成仍是壹个巨大的挑战。Figure1的每壹个节点均包含它自己的数据，而这些数据可能会于节点之间共享。共享这些数据代表性的方法是通过数据传输方法，包括壹批数据处理以及数据输入输出服务来完成。之所以采用这种方法是因为壹个节点的数据对其他节点来说不是实时存于的，而后者也不能于处理时分析和做决定。什么是企业应用集成?不断增长的客户和商业伙伴对实时信息的期望的持续增加，为了满足这种期望的需要，企业被迫连接他们的

5、那些异构的系统来增加产出、提高效率以及，最终的，使顾客满意。为使壹个组织内部IT系统互相通信，导致了企业应用集成(EAI)的发展。EAI通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等。EAI解决方案的起源能够追溯到那些提供双向的解决方案以完成于企业内部的ERP、CRM、SCM、数据库、数据仓库以及其他重要的内部系统之间无缝地共享和交换数据的需要。Figure2.B2B企业应用集成EAI不是壹个能彻底解决最终问题的方案，他更能够说是正于建立壹个灵活的、标准化的企业应用底层架构，能够允许新的基于IT的应用和商业处理能够更容易和更有效的被部署。新的底层架构允许企业中的应用能够实时的，

6、无缝的互相通信。EAI的类型EAI解决方案能够呈现许多种形式且以多种级别出现。EAI合适的级别依赖于许多因素，包括公司的大小、公司的行业类别、公司应用的集成度或是项目的复杂度以及预算等等。这里列出了EAI的中间件解决方案的4个类型： 用户界面集成 数据集成 商务流程集成 函数/方法集成当我们见到这些解决方案的类型，要注意的是我们于讨论解决方案的样式而不是具体实现。用户界面集成(界面重组)界面重组是壹个面向用户的整合，他将原先系统的终端窗口和PC的图形界面使用壹个标准的界面(有代表性的例子是使用浏览器)来替换。壹般的，应用程序终端窗口的功能能够壹对壹地映射到壹个基于浏览器的图形用户界面。新的表示

7、层需要和现存的遗留系统的商业逻辑或者壹些封装的应用如ERP、CRM以及SCM等进行集成。企业门户应用(EnterprisePortal)也能够被见成是壹个复杂的界面重组的解决方案。壹个企业门户合且了多个企业应用，同时表现为壹个可定制的基于浏览器的界面。于这个类型的EAI中，企业门户框架和中间件解决方案是壹样的。数据集成数据集成发生于企业内的数据库和数据源级别。通过从壹个数据源将数据移植到另外壹个数据源来完成数据集成。数据集成是现有EAI解决方案中最普遍的壹个形式。然而，数据集成的壹个最大的问题是商业逻辑常常只存于于主系统中，无法于数据库层次去响应商业流程的处理，因此这限制了实时处理的能力。此外

8、仍有壹些数据复制和中间件工具来推动于数据源之间的数据传输，壹些是以实时方式工作的，壹些是以批处理方式工作的。下面列出了壹些数据集成的方法：1. 批传输2. 数据合且3. 数据复制4. 析取、转换、装载解决方案(ETLSolution)Figure3.ETLSolutionETL解决方案(如上图所示)，是基于ETL引擎的，从不同的应用程序析取、转换、过滤和装载数据到数据仓库和(或)数据市集。当下ETL已经是企业实现数据集成的壹个非常有效的途径。商务流程集成虽然数据集成已经证明是EAI的壹个流行的形式，然而，从安全性、数据完整性、商务流程角度来见，数据集成仍然存于着很多问题。组织内大量的数据是被商

9、业逻辑所访问和维持的。商业逻辑应用且加强了必须的商业规则、商务流程和安全性，而这些对于下层数据均是必需的。商务流程集成产生于跨越了多个应用的商务流程层。通常通过使用壹些高层的中间件来表现商务流程集成的特征。这类中间件产品的代表是消息中介，消息中介使用壹个总线模式或者是HUB模式来对消息处理标准化且控制信息流。下面的图示于壹个较高的层次说明了壹个开放的商务流程的组成：Figure4.基于开放式商务流程的集成函数/方法集成函数和方法集成包括直接的和严格的，于网络环境中的跨平台应用程序之间的应用到应用(A2A)的集成。它涵盖了普通的代码(COBOL,C+,Java)撰写、应用程序接口(APIs)、远

10、端过程调用(RPCs)、分布式中间件如TP监控、分布式对象、公共对象访问中介(CORBA)、Java远端方法调用(RMI)、面向消息的中间件以及Web服务等等各种软件技术。Figure5.函数/方法的集成面向函数和方法的集成壹般来说是处于同步模式的，即基于客户(请求程序)和服务器(响应程序)之间的请求响应交互机制。Web服务Web服务提供了壹个分布式的计算技术，用于于Internet或者intranet上通过使用标准的XML协议和信息格式来展现商业应用服务。使用标准的XML协议使得Web服务平台、语言和发布者能够互相独立，这是EAI解决方案的壹个理想的候选者。通过开放的Internet标准：W

11、eb服务描述语言(WSDL，用于服务描述)，统壹描述、发现和集成规范(UDDI，用于服务的发布和集成)，简单对象访问协议(SOAP，用于服务调用)和Web服务流语言(WSFL，用来定义工作流，这尚不是壹个W3C标准)，Web服务消除了现存解决方案(如CORBA和DCOM)中的互用性问题。EAI和Web服务Web服务不是EAI或者是EAI的壹部分，更甚者，Web服务是另外壹个技术，Web服务能够使EAI成为真正可能的、便捷实施的，同时又引人注目的解决方案。Web服务能彻底地改变传统的EAI中点对点的集成处理方式。使用Web服务，通过松散的应用集成，壹个企业能够仅仅实现EAI的壹个子集，即能取得实

12、效。和之相反，EAI要实现壹个全盘的方案，来紧密的集成和联系支持公司业务的所有的系统和应用。于公司内部不同的业务系统和技术单体中可能需要花费数年的持续的努力，高投资以及为之配备的充实的资源。Web服务，以这样壹种松散的服务捆绑集合形式(也能够说是壹个特别得解决方案)，能够快速、低代价地开发、发布、发现和动态绑定应用。就当代Web服务的技术发展水平来见，Web服务能够实现应用程序之间的函数或方法级的集成。他们不是自然的基于事务的，同时仅提供了基本的请求/响应功能。然而，于下壹代的Web服务中，于功能上和技术上均会更先进，将会提供用户接口封装和安全性，他们将能够包装壹个应用程序且且把他嵌入到其他的

13、应用程序中去。现有的主要关注于应用集成的EAI解决方案将不得不因此而改变。于将来，包装好的应用程序将使用如XML、SOAP、WSDL和UDDI技术来把他们的函数或方法作为Web服务的界面来显示。因此，EAI解决方案将不得不提供壹个对服务集成的广泛的支持，而不仅仅是应用集成。传统EAI解决方案和Web服务之间的显著的不同下面是传统的EAI解决方案和Web服务之间的壹些基本的不同点：(注意：有壹些不同点所描述的Web服务的特点可能且非是Web服务目前有的特性，而是考虑了Web服务被提议的未来的改进) 简单性：毫无疑问，相比于典型的EAI解决方案(也许包括分布式技术如DCOM和CORBA)，Web服

14、务更便于设计、开发、维护和使用。既然开发和使用Web服务的平台框架已经准备好了，创建跨越多个应用程序的商务流程处理将变得相对简单。 开放标准：不像有所有权的EAI解决方案，Web服务是基于开放标准诸如UDDI、SOAP、HTTP的。这个可能是导致Web服务被广泛接受的最重要的因素。事实上基于现存的开放标准消除了企业潜于地为了支持新出现的Web技术的投资的需要。 灵活性：既然EAI解决方案需要点对点集成，壹端的改变必须告知另外壹端，这自然使集成变得非常的生硬，同时也是浪费开发人员的时间的。基于Web服务的集成是非常灵活的，因为他是建立于发布服务的应用程序和使用服务的应用程序之间的松散耦合。 便宜

15、：EAI解决方案，诸如消息中介，其实施是非常昂贵的。而Web服务的实施则会变得便宜而快速。 范围：EAI解决方案，诸如消息中介，把应用程序作为壹个单个的实体来集成。然而Web服务允许企业把大的应用划分为小的独立的逻辑实体且且包装他们。举例来说，企业能够为壹个ERP应用的不同的商业组件进行包装。如订单管理、接受购买订单、订单情况、订单确认、帐户接受、帐户支付等等。 高效性：已于前面几点提到的，Web服务允许应用程序划分为壹些小的逻辑组件，因为于小粒度基础上集成应用程序，集成将变得更容易。这也使Web服务的EAI解决方案比传统的EAI解决方案更有效率。 动态：Web服务通过提供动态的服务接口来实施

16、壹个动态的集成。然而传统的EAI解决方案均是静态处理的。用Web服务的EAI示例下面的Figure6显示了于壹个于企业内使用Web服务的例子。于这个例子中，于应用服务器中运行的企业门户从多个内部应用集成信息，且提供壹个跨越这些应用的业务处理的入口点。企业门户应用通过内部应用程序使用私有UDDI注册中心(PrivateUDDIRegistry)来获得可提供的Web服务的技术信息，且且于企业内部Intranet上调用这些服务。壹些经常被调用的Web服务的绑定信息将被企业门户应用缓存，这样得以避免花费于动态绑定上的资源和时间。于这个例子里面，Web服务把企业门户和CRM、ERP应用程序松散的集成于壹

17、起。Figure6.使用Web服务进行WAI的示例流程步骤如下：1. 于登录企业门户之后，用户发出请求信息；2. 支持企业门户框架的应用程序通过浏览私有UDDI注册中心获得关于CRM和ERP应用的Web服务的技术；3. Web服务的位置和WSDL绑定信息被穿送给应用服务器；4. 应用程序调用CRM应用发布的Web服务得到个人的信息，如名字、身份证号码、地址以及用户的Email。这个通讯过程是基于SOAP交互的；5. 应用程序调用ERP应用发布的Web服务获得银行帐号信息，诸如银行帐号号码，结余和用户交易历史记录。这个通讯过程也是基于SOAP交互的；6. 信息被格式化后，被发给起初的调用用户。从

18、哪里开始企业于内部应用程序中使用Web服务来实施应用集成的项目，应当从函数、应用程序接口(API)，或者远端过程调用(RPC)级别开始这壹进程。这个将使企业内使用和实施Web服务的IT技术人员熟悉Web服务技术，当企业将来使用Web服务进行外部集成(B2B集成)项目时，将会有助于项目的有效进行。于Intranet内控制、管理、寻找、执行和维护Web服务相对来说也比通过企业防火墙于Internet上使用Web服务更为容易。进壹步来说，它将帮助企业来比较和鉴别，使用标准化和相对便宜的Web服务解决方案相对于昂贵的传统的EAI解决方案到底是不是对提高企业的产出率更有帮助。然而，要求企业抛弃现存的EA

19、I底层架构且且盲目的转向开发基于Web服务的解决方案来替代它是不太现实的。企业不会停止使用提供完整事务服务的EAI中间件框架。于使用Web服务的场所，不是替代(当下仍不是)，而是应该使用Web服务来支撑现存的下层结构。经过壹段时间，Web服务将逐渐的由壹个EAI解决方案进化为壹个B2Bi(B2BIntergration)解决方案。结论通过壹个被Web标准支持的方法而不是壹个有私有知识产权的系统，Web服务提供壹个中立的平台来集成应用程序，从而被用于集成不同的应用系统。依靠Web服务，企业能够实时地访问不同部门、不同应用、不同平台和不同系统的信息，这已是Web服务被接受的最重要和最有力的因素之壹

20、。于企业冒险于B2B中使用Web服务实施应用集成之前，企业应当首先于他们内部的非面向事务的壹般商业流程集成中使用Web服务。参考资料 WebService技术/评论网站o UDDI-China.ORG,以UDDI为主的Web服务技术网站。o WebServices.ORG,Web服务的综合类技术网站。o IBMdeveloperWorks/WebServiceZone,IBM的Web服务技术资源中心o MSDNOnlineWebServicesDeveloperResources,Microsoft的Web服务的开发者资源网站 解决B2B电子商务应用交互和集成的InterOPStack系列技术

21、标准规范o UDDI执行白皮书,UDDI-China.org,UDDI.orgo UDDI技术白皮书,UDDI-China.org,UDDI.orgo UDDI程序员API规范v2.0,UDDI-China.org,UDDI.orgo UDDI数据结构参考v2.0,UDDI-China.org,UDDI.orgo UDDI程序员API规范v1.0,UDDI-China.org,UDDI.orgo UDDI数据结构参考v1.0,UDDI-China.org,UDDI.orgo MicrosoftUDDIResourceCenter&UDDIOperator,MicrosoftCooperatio

22、no WebServiceandUDDI,IBMo SOAPVersion1.2中文版,W3CWorkingDraft9July2001/UDDI-ChinaTranslation作者简介柴晓路:上海得易电子商务技术XX公司(DealEasy)首席系统架构师、XML技术顾问。UDDI-China.org蓝色火焰工作室(BlueBlazeStudio)成员。UDDIAdvisorGroup成员，WSUIWorkingGroup成员。2000年获复旦大学计算机科学硕士学位，曾于国际计算机科学学术会议(ICSC)、亚太区XML技术研讨会(XMLAsia/Pacific99)、中国XML技术研讨会(北京)、计算机科学期刊等各类国际、国内重要会议和期刊上发表论文多篇。专长于基于XML的系统集成和数据交换的技术研究，同时对数据库、面向对象技术及CSCW等技术比较擅长。