基于SOA架构与云计算技术的ERP系统设计方案

目录1前言 41.1企业ERP系统的需求描述 41.2ERP技术及应用的开展趋势 51.2.1B/S架构的ERP已经盛行 51.2.2SOA架构的引入，使ERP全面升级 5平台化——ERP的柔性大大增强 5与其它信息系统的集成 6整合业务流程的监测与评估 72传统ERP产品技术架构 82.1传统C/S架构的ERP系统 82.2B/S架构的ERP系统 82.3C/S架构和B/S架构的优缺点分析 92.3.1C/S系统优缺点 92.3.2B/S系统优缺点 9结论 103国内外最新ERP产品技术架构 103.1主流ERP产品简要介绍 103.1.1OracleEBusinessSuite 103.1.2SAPNetWeaver 12用友U9 123.2ERP系统架构设计的共同特点 13基于互联网的三层体系架构 14面向效劳架构〔SOA〕 14模块化和组件化的体系架构 144基于SOA架构的ERP系统 154.1SOA技术简介 154.1.1SOA概念及简介 15基于SOA技术的体系结构 164.1.3SOA的实现方式-WebService 194.2基于SOA的ERP系统架构设计 224.2.1SOA架构根底技术 224.2.2SOA架构设计方案 254.2.3SOA架构实现 264.2.4SOA架构的效劳管理组件：ESB 274.3ERP系统架构技术的时间线 305系统实现的关键技术 325.1关键技术框架及工具 32三层分布式架构 32基于WEB的B/S架构开发技术 34统一认证技术 34构件开发技术 36工作流系统 40权限管理系统 45表单生成技术 49插件化开发框架 515.2系统性能优化技术 52分布式技术应用 525.2.2AJAX局部更新 54预加载技术 55数据库查询优化 55数据库读写别离 565.3系统运营部署设计 56效劳器集群技术 56虚拟化数据中心技术 576应用云计算技术的ERP系统 616.1云计算技术简介 616.1.1IaaS根底设施即效劳 626.1.2PaaS平台及效劳 656.1.3SaaS软件即效劳 65云计算产生背景分析 696.2应用云计算技术的ERP系统 706.2.1SaaS模式的ERP与传统ERP的比拟 706.2.2SaaS模式的ERP系统架构设计 706.2.3SaaS模式的ERP系统的应用前景 726.3云计算平安设计 73云端数据存储加密 73网络数据传输加密 74数据平安管理标准 74云端加密的利与弊 766.4应用物联网技术的ERP系统 76物联网技术 76物联网应用案例—服装行业 796.4.3RFID,无线移动数据的收集技术 806.5应用移动技术的ERP系统 81移动ERP系统介绍 81移动ERP系统结构图 827总结 848参考文献 85前言企业ERP系统的需求描述

ERP实施的主体――企业的需求永远是ERP技术开展的主动力，由于全球一体化进程的加剧，使得企业所面临的竞争环境发生了巨大的变化，对ERP提出了新的需求，具体表现在[50]：

1)全球化市场的开展与产业链之间合作经营生产方式的出现，使得ERP能支持异地企业运营、异种语言操作和异种货币交易；

2)企业过程重组及协作方式的变化使得ERP能支持基于全球范围的可重构过程的供给链及供给网络结构；

3)企业需要应对新生产与经营方式的灵活性与敏捷性使得ERP也越来越灵活的适应多种生产制造方式的管理模式；

4)由于行业特性越来越明显，因此ERP的行业化开展趋势越来越明显；

5)企业的快速开展使得ERP的柔性越来越高以适应企业的动态变化；

6)企业的低本钱策略使得ERP可以按需配置、大大缩短实施周期。

IT技术的开展是推动ERP开展的另一驱动力，毕竟ERP应用是以“技术导向〞为推动的应用技术，具体表现在，计算机新技术的不断出现将会为ERP提供越来越灵活与强大功能的软硬件平台，多层分布式结构、面向对象技术、中间件技术与Internet的开展会使ERP的功能与性能迅速提高。图1.1企业ERP系统结构图ERP技术及应用的开展趋势B/S架构的ERP已经盛行

B/S模式是一种全新的软件系统构造技术。随着Windows98/Windows2000将浏览器技术捆绑植入操作系统内部，这种结构更成为当今应用软件的首选体系结构。显然B/S结构应用程序相对于传统的C/S结构应用程序将是巨大的进步。网络应用系统的开展正在改变着ERP系统的开发及其实施方法,传统ERP体系结构逐渐被由客户、应用效劳器、数据库效劳器组成的三层B/S结构所替代,并有了统一的通讯协议TCP/IP和统一的基于Web浏览器的用户界面。B/SERP把传统的依赖于邮件、、人盯人的管理方式变革为目标导向、流程驱动、智能的电子商务流程。并且该B/S架构的ERP可以把企业内部流程与企业外部流程连接起来，与客户、合作伙伴、供给商协同完成供给链业务操作[52]。SOA架构的引入，使ERP全面升级SOA〔Service-OrientedArchitecture面向效劳架构〕的概念是由Gartner公司给出的，Gartner对SOA的定义为“客户端/效劳器的软件设计方法，一项应用由软件效劳和软件效劳使用者组成……SOA与大多数通用的客户端/效劳器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。其核心是：

1〕SOA是一种软件架构思想，并不是一种产品。

2〕SOA的重点是面向效劳，此效劳包括企业的内部与外部的每一个业务细节，比方企业中财务应收发票的处理就是一个效劳。SOA的思想是把这些效劳从复杂的环境中独立出来——组件化封装，然后通过标准的接口使不同的效劳之间相互调用。

3〕SOA是一种软件架构思想，通过使企业中一个个细化的效劳标准化，来到达企业的IT系统跟随企业的动态变化的目的。平台化——ERP的柔性大大增强在ERP应用实施的过程中，用户的满意度一直不高。主要原因是产品更新周期加快、市场响应要求提高，对ERP的个性化要求越来越高，这是导致ERP实施成功率不高的重要原因之一。经过多年的积累，人们已经总结出了ERP系统中业务的核心，其架构、业务模型、标准化高的业务处理均是可封装的，如果我们把这局部封装起来，再开发出辅助这个平台的客户化工具，就可以形成业务化平台。同样如此，如果对ERP进行分析、研究，将ERP的相关局部封装起来，再加上工具包，就可以形成平台化的ERP。平台级企业信息解决方案提供了一个软件平台，内置多种管理软件组件和快捷的二次开发工具，其组件可以通过多种语言来开发，开发出一个个的小模块，然后把每一个小模块独立起来建成一个组件，最后把这些组件组装起来形成最终的成品。那么对这些组件进行调用，管理和删减、添加及修改，甚至重新构架都可以，而这样对某一局部的改动根本不会影响到其它功能。这就是平台带来的灵活性，易操作性，使它在进行小的改动时可以直接通过系统上的某些功能来实现，而不必要通过改源代码的方式来处理，可以降低企业信息化软件的开发难度，提高开发效率，提高系统的柔性和可扩展性。一方面管理信息化厂商通过平台提供的组件能很方便地满足用户个性化的需求，以及用户在开展过程中各种各样变化的需求。另一方面将应用软件的业务逻辑和开发技术相对分开，使得应用软件的开发者可以仅关注应用的业务任务，而不必关注其技术的实现。这使管理与业务人员参与应用软件的开发成为可能。平台化软件的根本特性如下：

1〕软件架构灵活；

2〕核心业务标准化；

3〕接口标准化，具有很好的兼容性；

4〕提供客户化工具包。与其它信息系统的集成1〕ERP与客户关系管理的进一步整合ERP将更加面向市场和面向顾客，通过基于知识的市场预测、订单处理与生产调度、基于约束调度功能等进一步提高企业在全球化市场环境下更强的优化能力；并进一步与客户关系管理CRM结合，实现市场、销售、效劳的一体化，使CRM的前台客户效劳与ERP后台处理过程集成，提供客户个性化效劳，使企业具有更好的顾客满意度。2〕ERP与电子商务、供给链SCM、协同商务的进一步整合ERP将面向协同商务〔CollaborativeCommerce〕，支持企业与贸易共同体的业务伙伴、客户之间的协作，支持数字化的业务交互过程；ERP供给链管理功能将进一步加强，并通过电子商务进行企业供需协作，如汽车行业要求ERP的销售和采购模块支持用电子商务或EDI实现客户或供给商之间的电子订货和销售开单过程；ERP将支持企业面向全球化市场环境，建立供给商、制造商与分销商间基于价值链共享的新伙伴关系，并使企业在协同商务中做到过程优化、方案准确、管理协调。3〕ERP与产品数据管理的整合产品数据管理PDM(ProductDataManagement)将企业中的产品设计和制造全过程的各种信息、产品不同设计阶段的数据和文档组织在统一的环境中。近年来ERP软件商纷纷在ERP系统中纳入了产品数据管理PDM功能或实现与PDM系统的集成，增加了对设计数据、过程、文档的应用和管理，减少了ERP庞大的数据管理和数据准备工作量，并进一步加强了企业管理系统与CAD、CAM系统的集成，进一步提高了企业的系统集成度和整体效率。4〕ERP与制造执行系统的整合为了加强ERP对于生产过程的控制能力，改变ERP"重方案，轻控制"的弱点，将进一步加强"事前方案、事中控制、事后审核"的功能，ERP将与制造执行系统MES(ManufacturingexecutiveSystem)、车间层操作控制系统SFC更紧密的结合，形成实时化的ERP/MES/SFC系统。该趋势在流程工业企业的管控一体化系统中表达得最为明显。5〕ERP与工作流管理系统的进一步整合全面的工作流规那么保证与时间相关的业务信息能够自动地在正确时间传送到指定的地点。ERP的工作流管理功能将进一步增强，通过工作流实现企业的人员、财务、制造与分销间的集成，并能支持企业经营过程的重组，也使ERP的功能可以扩展到办公自动化和业务流程控制方面。6〕ERP与企业知识门户进一步整合企业知识门户〔EnterpriseKnowledgePortal，EKP〕所关注的是企业内部员工和信息内容，它的核心是知识管理〔KM〕，通过与ERP系统的集成，使得企业内任何员工都可以实时地与工作团队中的其他成员取得联系、寻找到能够提供帮助的专家或者快速连接到相关的知识，它的建立和使用可以大大提高企业范围内的知识共享，并由此提高企业员工的工作效率。整合业务流程的监测与评估“用于测量成功的业务应用解决方案是连续改良的关键：财务表现的共享,SC效力，知识资本的价值以及顾客的满意度都是新的评测方法。〞――Gartner。传统ERP产品技术架构传统C/S架构的ERP系统信息系统架构示意图：

1)一层架构：客户端、应用效劳器和数据库效劳器都在同一台机器上部署；

2)两层架构：数据库效劳和应用效劳在同一台效劳器上部署，客户端访问效劳器上的资源或数据；

3)

三层架构：应用效劳和数据库效劳别离，分别部署在不同的效劳器上，应用效劳采取集群部署，到达性能上的需求。图2.1不同分级层次的系统架构图从企业信息系统架构设计看，三层分布式架构是一种典型应用；甚至可以过渡到多层分布式架构，如扩展出缓存效劳、负载均衡效劳等；这些都是用户对系统快速响应和系统可靠性的需求。B/S架构的ERP系统B/S架构的ERP系统的出现使得传统的ERP系统成为互联网应用，用户借助网络的方便快捷，可以随时随地办公，处理业务数据。现代企业普通存在多区域分支机构，或者业务人员需要差旅或在家办公，传统的C/S架构日益不能满足移动办公的需要，B/S架构的ERP系统刚好可以解决这一需要。图2.2B/S架构的ERP系统部署图C/S架构和B/S架构的优缺点分析C/S系统优缺点C/S模式的优点[1]：1)由于客户端实现与效劳器的直接相连，没有中间环节，因此响应速度快。〔当数据少时，C/S在局域网内响应快；当数据超过十万时，C/S软件变慢，B/S软件能维持稳定速度〕2)操作界面交互性强、控件组件形式多样，可以充分满足客户快速操作的要求。3)C/S结构的管理信息系统能实现的复杂的数据处理操作，不用过多考虑网络的不稳定性。C/S模式的缺点：1)需要专门的客户端安装程序，分布功能弱，针对点多面广且不具备网络条件的用户群体，不能够实现快速部署安装和配置。2)兼容性差，对于不同的开发工具，具有较大的局限性。假设采用不同工具，需要重新改写程序，跨平台难度大，无法轻易实现Windows、Linux、iOS系统的同时开发和部署。3)开发本钱较高，需要具有一定专业水准的技术人员才能完成。〔就开发小型企业管理软件，针对内部使用的系统而言，C/S开发人员比B/S开发人员的本钱低了许多〕。B/S系统优缺点B/S结构的优点：1)是互联网应用，具有分布性特点，可以随时随地进行查询、浏览等业务处理。2)业务扩展简单方便，通过增加网页即可增加效劳器功能。3)维护简单方便，只需要改变网页，即可实现所有用户的同步更新。4)开发简单，共享性强。B/S结构的缺点：1)操作是以鼠标为最根本的操作方式，无法满足快速操作的要求，尤其是在大量数据录入操作、复杂交互的情况下，需要提升交互设计能力。2)页面加载刷新时，响应速度受网络连接的稳定性影响。结论目前，从架构设计来看，ERP系统采用B/S架构和C/S架构是并存存在的，B/S的架构的系统更有开展前景，从长远来看，由于互联网开展，网络带宽提升，HTML5技术出现的等因素，B/S的架构的系统是将来的开展趋势。国内外最新ERP产品技术架构主流ERP产品简要介绍OracleEBusinessSuiteOracleEBS产品介绍

OracleEBS是OracleE-BusinessSuite的缩写，是Oracle公司的ERP产品，全球销量仅次于SAP〔另一款ERP产品〕。OracleEBS是一整套企业级应用软件，包括：采购管理、库存管理、销售管理、车间管理、物料清单及工艺管理、生产方案、本钱管理、应付账款管理、应收账款管理、现金管理、总帐管理、工程会计、工程制造、客户关系管理、供给商门户等模块。纯互联网技术架构Oracle电子商务套件采用标准的100％基于互联网的三层体系架构；无论是数据库层、应用层以及最前端的最终用户操作界面都100％支持基于JAVA的先进互联网技术[37]。Oracle电子商务套件的技术架构特点，提供了软件系统基于数据中心运行的集中管理根底。使所有关于软件系统的推广、升级和日常维护工作可以基于数据中心进行，从而到达最大限度地降低客户端软硬件和维护本钱，降低效劳器端的软件维护工作内容。图3.1Oracle应用软件技术架构模块化开放架构Oracle电子商务套件应用产品采用模块化和组件化的先进软件技术体系架构，应用软件产品可以细化成为许多细粒度的模块，不同的客户应用可以选择不同的组件或模块组合形成适合于企业需求的软件平台方案；基于同一共享数据库和统一数据模型的数据层面的高度集成架构，保证各应用模块之间的紧密无缝集成和平滑的业务流转[37]。图3.2Oracle电子商务套件的模块化开放架构SAPNetWeaverSAPNetWeaver产品介绍

SAPNetWeaver是SAP的集成技术平台和自从SAPBusinessSuite以来的所有SAP应用的技术根底。SAPNetWeaver是一个面向效劳的应用和集成平台。SAPNetWeaver为SAP的应用提供开发和运行环境，也可以用来和其它应用和系统进行自定义的开发和集成。SAPNetWeaver是使用开放标准和事实上的工业标准进行开发的，可以用icrosoft?NET，Sun燡avaEE，和IBM燱ebSphere等这些技术平台进行扩展和互操作[44]。SAPNetWeaver技术架构

SAP企业系统架构是以SOA架构技术作为根底框架进行开发的。ERP,CRM,SCM,SAPBusinessSuite,SRM,PLM系统都是独立的子系统，这些系统之间的交互都是通过SOA效劳进行。图3.3SAP企业系统架构用友U9用友U9产品介绍用友U9完全基于SOA架构的世界级企业管理软件，用友U9面向快速开展与成长的中大型制造企业复杂应用，以“实时企业、全球商务〞为核心理念，完全适应多组织供给链协同、多工厂制造协同、产业链协同、产品事业部和业务中心的管理模式，更能支持多生产模式的混合生产与规划、多经营模式的混合管理、精益生产、全面本钱、跨国财务等深度应用，具有高度灵活的产品架构，帮助企业快速响应变化，支持经营、业务与管理模式的创新。用友U9技术架构

UFIDAU9完全采用面向效劳架构〔SOA〕，实现了全程模型驱动开发〔MDD〕模式，到达降低集成和开发本钱的目的。UAP使企业管理软件具有多项新技术应用特点：企业信息资源变得可重用、透明化，并且系统具有高可扩展性，让业务处理更加高效、简洁、平安。UAP还提供了统一的集成开发环境〔IDE〕，用户可以使用包括企业建模、领域建模、效劳设计、UI设计、报表设计、规那么设计、数据库设计等全方位的设计器，并通过可视化的界面和友好的交互操作，自动生成用户所需要的各种效劳部件。UAP完全支持企业级的集成与应用协同，如Office集成、移动商务、企业搜索、智能客户端等多项领域[35]。图3.4用友U9技术架构ERP系统架构设计的共同特点通过国内外最新ERP产品的功能及技术架构比拟，得出：基于SOA架构的技术框架是共同采用的，而且更加强调了多设备的支持，完全基于互联网模式的系统。产品名称是否B/S是否SOA架构是否模块化构建是否支持移动设备是否分布式部署OracleEBusinessSuite是是是支持是SAPNetWeaver是是是支持是用友U9是是是支持是金蝶EAS是是是支持是OpenERP(开源)是下一版本支持完全模块化支持是表3.1各主流ERP产品系统架构比拟基于互联网的三层体系架构采用标准的100％基于互联网的三层体系架构,无论是数据库层、应用层以及最前端的最终用户操作界面都100％支持WEB的互联网技术，特别是应用层，直接采用互联网先进技术，不需要任何中间转换过程，在表达先进互联网技术的同时，最大限度的减少了中间环节，保证了系统处理的高性能和高稳定性。面向效劳架构〔SOA〕完全采用面向效劳架构〔SOA〕，实现了全程模型驱动开发〔MDD〕模式，到达降低更加强调系统的根底，采用松耦合，降低系统的耦合度。SOA的实现方式都是采用了基于Http协议的WebService的技术，数据交换格式采用XML，SOAP。模块化和组件化的体系架构模块化和组件化的先进软件技术体系架构，应用软件产品可以细化成为许多细粒度的模块，不同的客户应用可以选择不同的组件或模块组合形成适合于企业需求的软件平台方案；基于同一共享数据库和统一数据模型的数据层面的高度集成架构，保证各应用模块之间的紧密无缝集成和平滑的业务流转。基于SOA架构的ERP系统SOA技术简介SOA概念及简介SOA的根本概念面向效劳的体系结构〔Service-OrientedArchitecture，SOA〕是一个组件模型，它将应用程序的不同功能单元〔称为效劳〕通过这些效劳之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现效劳的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的效劳可以使用一种统一和通用的方式进行交互[26]。简介SOA(Service-OrientedArchitecture)，面向效劳架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。效劳层是SOA的根底，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。SOA是一种粗粒度、松耦合效劳架构，效劳之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML/WebService技术之后的自然延伸。SOA技术的优势通过SOA思想的引入，使得ERP软件可以做到[50]：1)支持异构集成所谓异构环境，包括四个层次，硬件平台、操作系统、数据库、应用软件。如果一套硬件、一套操作系统、一套数据库、一套应用软件能够面面俱到的解决集团企业的所有管理问题，那是再好不过了。但现实中是不可能的，更普遍的是，不同的应用往往选择不同的平台和应用系统，以便充分发挥各个厂商的特长。支持SOA的ERP系统为集团企业的信息化提供了伸缩空间，企业可以根据需要选择最适宜的解决方案。2)降低企业的IT本钱以往多数企业在建设企业的ERP系统时是从工程的角度出发的，比方ERP工程、CRM工程等，事后当企业的IT系统越来越多的时候，才会考虑系统的集成问题，但这时候往往集成的难度就很大了。而SOA要求企业在建设IT系统之初就要考虑这些问题，也就是要考虑效劳之间的接口问题。这样就会使企业的IT本钱大大降低。同时，SOA将改变以往的软件购置模式。目前，多数企业在购置软件时往往是成熟性软件，需一个模块或一个系统的购置，企业在购置时往往无法将那些企业不需要的功能剔除出去，这样，企业就不得不为此多付出资金、培训本钱等许多不必要的本钱。而支持SOA的集团财务软件那么可以帮助企业实现真正的按需购置，企业需要什么功能就购置相应的效劳，帮助企业防止不必要的支出。3)实现企业的动态变革支持SOA的集团财务系统使企业的IT人员不必太多的关心企业IT系统的底层技术，而更多的去考虑集团财务的业务处理以及财务业务与IT的接合。同时，以往企业在开发集团财务系统时，在重复功能上浪费了大量的人力与财力，同时系统在开发完成后，如果企业业务变化，系统将很难更改或者更改的本钱很高。而SOA面对的是一个个独立的效劳，效劳之间可以通过标准接口来相互调用，这样企业在重复功能上就可以直接通过接口调用，而不必去重新开发。企业的业务发生变化时，只需要修改相对应的效劳即可，降低了修改的难度与复杂度，保证了企业的IT系统的动态变化。基于SOA技术的体系结构SOA是松耦合的系统这种具有中立的接口定义〔没有强制绑定到特定的实现上〕的特征称为效劳之间的松耦合。松耦合系统的好处有两点：1)是它的灵活性，当组成整个应用程序的每个效劳的内部结构和实现逐渐地发生改变时，它能够继续存在。2)而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对局部或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比方经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需〔Ondemand〕业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。SOA系统原型的一个典型例子是通用对象请求代理体系结构〔CommonObjectRequestBrokerArchitecture，CORBA〕，它已经出现很长时间了，其定义的概念与SOA相似。然而，现在的SOA已经有所不同了，通过使用基于XML的语言〔称为Web效劳描述语言〔WebServicesDefinitionLanguage，WSDL〕〕来描述接口，效劳已经转到更加动态且更灵活的接口系统中，非以前CORBA中的接口描述语言〔InterfaceDefinitionLanguage，IDL〕可比了。SOA体系结构作用传统企业〔数据库〕应用软件产品，如MRP、ERP、OA系统等，在设计或架构上都是紧偶合、封闭式、自成体系，属于一次性投入一次性完结的产品。这样的产品很难适应或快速响应市场或客户灵活多变的需求，以及后续的扩展。在这样的市场、及客户需求下，从而催生了软件产品一种新的设计或架构的理念：面向效劳架构〔SOA架构〕。对SOA的需要来源于需要使业务IT系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。SOA是一场革命。一个应用程序的业务逻辑〔businesslogic〕或某些单独的功能被模块化并作为效劳呈现给消费者或客户端。这些效劳的关键是他们的松耦合特性。例如，效劳的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个效劳来构建应用，而无须理解效劳的底层实现。举例来说，一个效劳可以用.NET或J2EE来实现，而使用该效劳的应用程序可以在不同的平台之上，使用的语言也可以不同。让SOA系统适应改变的能力是最重要的局部，对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对SOA模型大的改变。这种分工，就是让开发人员集中精力于创立作为效劳定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言〔UniversalModelingLanguage，UML〕，并且描述成模型驱动的体系结构〔Model-DrivenArchitecture，MDA〕。SOA架构的定义或特性

SOA架构，是一种粗粒度、开放式、松耦合的效劳结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。通过这种分层设计或架构体系可以使软件产品变得更加弹性和灵活，且尽可能的与第三方软件产品互补兼容，以到达快速扩展，满足或响应市场或客户需求的多样化、多变性。一个典型的SOA架构示意如下：图4.1SOA架构的系统图示基于SOA技术架构的价值未来企业的应变之道持续增长的客户需求、瞬息万变的市场和日趋剧烈的全球化竞争，使得企业必须不断提升自身IT及企业管理系统的敏捷性和适应性。现在，每个企业都需要把握业务流程开展的变革，预测业务环境的变化，以便对竞争者做出快速响应，确保企业的生存、开展和快速成长[27]。面向效劳架构技术〔Service-OrientedArchitecture，SOA〕的出现，标志着设计、开发、部署新的企业应用系统，并将其与原有应用系统、业务流程进行集成的方式出现了根本性变化。采用SOA架构，可以带来显著的商业和技术利益：1〕提升商业决策能力，通过将商业效劳和信息进行聚合成为一系列动态的、组合的商业应用，企业决策者可以更便捷地获得更准确、更全面、更深入的信息，可以更敏捷地对各种变化做出反响。2〕获得更高的员工生产率，SOA可以改良商业流程，使得员工更加关注关键性、增值业务流程，基于效劳更好地进行协作，通过各种方式访问和操作业务数据和信息，大大提升生产率。3〕建立与供给商和顾客的更强的联系，SOA增强了端到端的应用模式，跨越企业组织边界，更好地集成现有的信息系统，通过效劳的编排和聚合，使其更好地融合在业务流程里。4〕可以更快、更节省地搭建IT和业务应用系统，基于SOA和标准化效劳组件，可以根据业务流程需要，更快地搭建业务系统；同时，也可以更好地利用原有的IT和业务系统的投资，并保证其符合业务流程的需要。5〕可以增强IT和业务系统的可管理性和平安性，通过平安效劳的部署和SOA治理，可以实现更强的平安性管理和监控，确保了整个架构置于统筹和管理之下。完全SOA架构所带来的价值1〕确保总体架构的合理规划，全面整合信息，彻底消除应用孤岛，全面实现过程、人员和信息的实质集成、高度协调，实现更高的互操作性与协同、更敏捷的业务流程、更全面的信息可见性；2〕企业的IT及应用系统架构将更具伸缩性，IT价值将得到充分的发挥，全面提升未来企业的竞争优势；3〕降低集成本钱和风险，降低维护本钱：随着企业业务的开展，非SOA应用在IT和应用系统中相互集成的本钱和风险日益增大，系统运行将变得繁冗和低效；相应地，为维护应用孤岛及更多的流程接口，甚至是重复、重叠的业务功能系统，企业IT及应用系统维护本钱将不可防止地日益增大。4〕基于SOA架构的IT及应用系统可以增量部署到位，但毫无疑问，选择完全SOA架构是正确、长远和明智的决策。SOA的实现方式-WebServiceWebService的概念WebService是一种构建应用程序的普遍模型,可以在任何支持网络通信的操作系统中实施运行;它是一种新的web应用程序分支，是自包含、自描述、模块化的应用，可以发布、定位、通过web调用。WebService是一个应用组件,它逻辑性的为其他应用程序提供数据与效劳.各应用程序通过网络协议和规定的一些标准数据格式〔Http，XML，Soap)来访问WebService,通过WebService内部执行得到所需结果.WebService可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他WebService应用程序可以发现并调用它部署的效劳[28]。WebService的关键技术和规那么技术和规那么在构建和使用WebService时,主要用到以下几个关键的技术和规那么:1)XML:描述数据的标准方法.2)SOAP:简单对象访问协议.3)WSDL:Web效劳描述语言.4)UDDI(UniversalDescription,DiscoveryandIntegration):通用描述、发现与集成，它是一种独立于平台的，基于XML语言的用于在互联网上描述商务的协议。相关实际上，WebService的主要目标是跨平台的可互操作性。为了到达这一目标，WebService完全基于XML〔可扩展标记语言〕、XSD〔XMLSchema〕等独立于平台、独立于软件供给商的标准，是创立可互操作的、分布式应用程序的新平台。由此可以看出，在以下三种情况下，使用WebService会带来极大的好处。具体如下：1)跨防火墙的通信如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和效劳器之间的通信将是一个棘手的问题。因为客户端和效劳器之间通常会有防火墙或者代理效劳器。在这种情况下，使用DCOM就不是那么简单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是，选择用浏览器作为客户端，写下一大堆ASP页面，把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大，程序很难维护。2)应用程序集成企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。应用程序经常需要从运行在IBM主机上的程序中获取数据；或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。通过WebService，应用程序可以用标准的方法把功能和数据“暴露〞出来，供其它应用程序使用。3)B2B的集成用WebService集成应用程序，可以使公司内部的商务处理更加自动化。但当交易跨越供给商和客户、突破公司的界限时会怎么样呢？跨公司的商务交易集成通常叫做B2B集成。WebService是B2B集成成功的关键。通过WebService，公司可以把关键的商务应用“暴露〞给指定的供给商和客户。例如，把电子下单系统和电子发票系统“暴露〞出来，客户就可以以电子的方式发送订单，供给商那么可以以电子的方式发送原料采购发票。当然，这并不是一个新的概念，EDI(电子文档交换)早就是这样了。但是，WebService的实现要比EDI简单得多，而且WebService运行在Internet上，在世界任何地方都可轻易实现，其运行本钱就相对较低。不过，WebService并不像EDI那样，是文档交换或B2B集成的完整解决方案。WebService只是B2B集成的一个关键局部，还需要许多其它的局部才能实现集成。用WebService来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把商务逻辑“暴露〞出来，成为WebService，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。这样就大大减少了花在B2B集成上的时间和本钱，让许多原本无法承受EDI的中小企业也能实现B2B集成。4)软件和数据重用软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。最根本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。WebService在允许重用代码的同时，可以重用代码背后的数据。使用WebService，再也不必像以前那样，要先从第三方购置、安装软件组件，再从应用程序中调用这些组件；只需要直接调用远端的WebService就可以了。举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接发送给相应的WebService，这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址是否在相应的邮政编码区域。WebService的提供商可以按时间或使用次数来对这项效劳进行收费。这样的效劳要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。另一种软件重用的情况是，把好几个应用程序的功能集成起来。例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购置电影票。现在Web上有很多应用程序供给商，都在其应用中实现了这些功能。一旦他们把这些功能都通过WebService“暴露〞出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。将来，许多应用程序都会利用WebService，把当前基于组件的应用程序结构扩展为组件/WebService的混合结构，可以在应用程序中使用第三方的WebService提供的功能，也可以把自己的应用程序功能通过WebService提供给别人。两种情况下，都可以重用代码和代码背后的数据。SOA的WebService实现SOA是一种软件架构，而不是局限于某个技术的组合，它超越了技术范围。SOA的关键是“效劳〞。W3C将效劳定义为：“效劳提供者完成一组工作，为效劳使用者交付所需的最终结果。最终结果通常是使用者的状态发生变化，但也可能是提供者的状态改变，或者双方都产生变化〞。效劳是网络中可用的软件资源。效劳提供者通过标准机制提供效劳，使用者通过网络有方案地使用效劳。效劳储藏库发布效劳所在位置，并在使用者请求效劳时定位效劳。效劳使用者和提供者的角色不是惟一的，效劳提供者也可以是使用者，反之亦然。SOA具体的实现有很多，包括WebService，Ses-sionBean，JINI等，但随着WebService技术被越来越重视，其己经成为构建SOA的主要技术。图4.2标准WebService技术和SOA架构系统比照从上图比拟得出，SOA自治的WebService实现架构中，增加了对效劳的管理，包括：业务对象管理、业务流程管理，效劳策略，效劳平安等的考虑。基于SOA的Application为什么选择SOA？不同种类的操作系统，应用软件，系统软件和应用根底结构〔applicationinfrastructure〕相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程〔businessprocesses〕，因此从头建立一个新的根底环境是不可能的。企业应该能对业务的变化做出快速的反响，利用对现有的应用程序和应用根底结构〔applicationinfrastructure〕的投资来解决新的业务需求，为客户，商业伙伴以及供给商提供新的互动渠道，并呈现一个可以支持有机业务〔organicbusiness〕的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新效劳或更新现有效劳，以解决新的业务需要，提供选择从而可以通过不同的渠道提供效劳，并可以把企业现有的或已有的应用作为效劳，从而保护了现有的IT根底建设投资。图4.3采用SOA架构的应用例如基于SOA的ERP系统架构设计SOA架构根底技术SOA效劳架构为了实现SOA，企业需要一个效劳架构,效劳消费者〔serviceconsumer〕可以通过发送消息来调用效劳。这些消息由一个效劳总线〔servicebus〕转换后发送给适当的效劳实现。这种效劳架构可以提供一个业务规那么引擎〔businessrulesengine〕，该引擎容许业务规那么被合并在一个效劳里或多个效劳里。这种架构也提供了一个效劳管理根底〔servicemanagementinfrastructure〕，用来管理效劳，类似审核，列表〔billing〕，日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求〔regulatoryrequirement〕，例如SarbanesOxley〔SOX〕，并且可以在不影响其他效劳的情况下更改某项效劳[29]。图4.4SOA效劳架构SOA根底结构要运行，管理SOA应用程序，企业需要SOA根底，这是SOA平台的一个局部。SOA根底必须支持所有的相关标准，和需要的运行时容器[29]。图4.5SOA根底架构SOAP，WSDL，UDDIWSDL，UDDI和SOAP是SOA根底的根底部件。WSDL用来描述效劳；UDDI用来注册和查找效劳；而SOAP，作为传输层，用来在消费者和效劳提供者之间传送消息。SOAP是Web效劳的默认机制，其他的技术为可以效劳实现其他类型的绑定。一个消费者可以在UDDI注册表〔registry〕查找效劳，取得效劳的WSDL描述，然后通过SOAP来调用效劳。WS-IBasicProfileWS-IBasicProfile，由Web效劳互用性组织〔WebServicesInteroperabilityOrganization〕提供，是SOA效劳测试与互用性所需要的核心构件。效劳提供者可以使用BasicProfile测试程序来测试效劳在不同平台和技术上的互用性。J2EE和.Net尽管J2EE和。NET平台是开发SOA应用程序常用的平台，但SOA不仅限于此。像J2EE这类平台，不仅为开发者自然而然地参与到SOA中来提供了一个平台，还通过他们内在的特性，将可扩展性，可靠性，可用性以及性能引入了SOA世界。新的标准，例如JAXB〔JavaAPIforXMLBinding〕，用于将XML文档定位到Java类；JAXR〔JavaAPIforXMLRegistry〕用来标准对UDDI注册表〔registry〕的操作；XML-RPC〔JavaAPIforXML-basedRemoteProcedureCall〕在J2EE1.4中用来调用远程效劳，这使得开发和部署可移植于标准J2EE容器的Web效劳变得容易，与此同时，实现了跨平台〔如。NET〕的效劳互用。效劳品质在企业中，关键任务系统〔mission-criticalsystem，译注：关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的，那么该系统就是该企业的关键任务系统。比方，系统对于一个促销企业来说就是关键任务系统，而文字处理系统就不那么关键了。〕用来解决高级需求，例如平安性，可靠性，事物。当一个企业开始采用效劳架构作为工具来进行开发和部署应用的时候，根本的Web效劳标准，像WSDL，SOAP，以及UDDI就不能满足这些高级需求。正如前面所提到的，这些需求也称作效劳品质〔QoS，qualityofservices〕。与QoS相关的众多标准已经由一些标准化组织〔standardsbodies〕提出，像W3C〔WorldWideWebConsortium〕和OASIS〔theOrganizationfortheAdvancementofStructuredInformationStandards〕。下面的局部将会讨论一些QoS效劳和相关标准。平安Web效劳平安标准用来保证消息的平安性。该标准主要包括认证交换，消息完整性和消息保密。该标准吸引人的地方在于它借助现有的平安标准，例如，SAML〔asSecurityAssertionMarkupLanguage〕来实现web效劳消息的平安。OASIS正致力于Web效劳平安标准的制定。可靠在典型的SOA环境中，效劳消费者和效劳提供者之间会有几种不同的文档在进行交换。具有诸如“仅且仅仅传送一次〞〔once-and-only-oncedelivery〕，“最多传送一次〞〔at-most-oncedelivery〕，“重复消息过滤〞〔duplicatemessageelimination〕，“保证消息传送〞〔guaranteedmessagedelivery〕等特性消息的发送和确认，在关键任务系统〔mission-criticalsystems〕中变得十分重要。WS-Reliability和WS-ReliableMessaging是两个用来解决此类问题的标准。这些标准现在都由OASIS负责。策略效劳提供者有时候会要求效劳消费者与某种策略通信。比方，效劳提供商可能会要求消费者提供Kerberos平安标示，才能取得某项效劳。这些要求被定义为策略断言〔policyassertions〕。一项策略可能会包含多个断言。WS-Policy用来标准化效劳消费者和效劳提供者之间的策略通信。控制当企业着手于效劳架构时，效劳可以用来整合数据仓库〔silosofdata〕，应用程序，以及组件。整合应用意味着例如异步通信，并行处理，数据转换，以及校正等进程请求必须被标准化。在SOA中，进程是使用一组离散的效劳创立的。BPEL4WS或者WSBPEL〔WebServiceBusinessProcessExecutionLanguage〕是用来控制这些效劳的语言。WSBPEL目前也由OASIS负责。管理随着企业效劳的增长，所使用的效劳和业务进程的数量也随之增加，一个用来让系统管理员管理所有运行在多相环境下的效劳的管理系统就显得尤为重要。WSDM〔WebServicesforDistributedManagement〕规定了任何根据WSDM实现的效劳都可以由一个WSDM适应〔WSDM-compliant〕的管理方案来管理。其它的qos特性，比方合作方之間的溝通和通訊，多個服務之間的事務處理，都在WS-Coordination和WS-Transaction標準中描述，這些都是OASIS的工作。SOA架构设计方案系统采用面向效劳架构来设计其体系结构，每一层的具体功能如下：图4.6基于SOA架构的ERP系统架构设计

1〕应用表示层采用Portal技术建立企业信息门户，通过标准接口与效劳提供方和效劳注册中心通讯，到达查询和绑定效劳的目的。功能设计中将利用效劳层和业务流程编排层提供的效劳和业务应用流程，以及引入的其他外部WebService，利用了最新的Web2.0技术，包括Ajax、RSS、WebGIS等等来增强用户体验。

2〕业务流程编排层集成了各种业务规那么和逻辑规那么，将效劳层提供的效劳编排成业务应用流程，满足了灵活重组企业内部流程的要求。

3〕效劳层由各种粒度的效劳组成，主要分为粗粒度效劳和细粒度效劳，并按功能的不同将它们分成四类提供给不同的用户使用。这四类包括：技术功能、业务功能、业务事务和业务流程。其中技术功能主要是由运行根底提供的各种效劳，业务功能那么是由组件层发布上来的细粒度效劳。业务事务那么是粒度稍大的效劳。粒度最大的是业务流程效劳。在该层通过业务效劳总线〔BSB〕完成细粒度效劳到粗粒度效劳的整合，从而实现ERP系统的整体功能。本层的主要功能在于分类组织组件层发布上来的各种效劳、SOA运行根底提供的功能效劳以及从外部引入的各种效劳。

4〕组件层主要向上提供涉及到各种企业应用的接入组件，以实现系统中不同的功能模块，并通过WebService接口被包装成WebService发布到在组件层之上的效劳层，同时组件层预留其他类型接口供系统调用。

5〕系统层，主要是提供满足ERP系统的根底架构，如企业ERP系统中通常需要集成的各个应用系统和数据库管理系统。通常各个应用系统之间是相互独立的，他们将通过系统架构中的组件层接入整个SOA企业信息系统中并受BusinessIntelligence控制。在系统层，通过面向对象技术完成组件层与数据库的交互。SOA架构实现为了实现构建大型，分布的多层企业应用技术，使系统具有语言无关、再开发、可移植性和高性能等优点，我们选择.NET平台作为基于SOA的Web效劳开发实现平台。结合WebServices，采用xfire发布框架完成SOA架构的实现。

1)应用表示层的技术实现通过AMVC3.0框架对web效劳的良好的支持完成Web层的开发，以到达表达给用户一个直观而且简单易于使用的用户界面。在表示层中同时采用与AJAX技术相结合，让系统页面在性能上具有比一般Web页面更快的响应速度。

2)业务流程编排层的技术实现由于系统的业务流程比拟灵活，本文采用基于标准的可扩展的WSDL和BPEL〔Web效劳业务流程执行语言〕来定义和描述流程。在BPEL中通过使用结构化活动来定义这些活动之间的相互关系从而创立出复杂的流程，这有利于系统的开放性和通用性。在此根底上采用Web效劳完成流程到前台应用系统的接口，Web效劳向内通过各种控件完成流程的操作与管理，向外为前台的开发提供了一个结构松散、异步操作和具有分布式支撑能力的统一接口。

3)Webservice发布框架WebService〔Web效劳〕技术那么是一种主要的实现方法。Webservice发布主要由xfire实现，xfire是一个免费的开源SOAP框架，在它的代码中有一个轻量级的信息处理模块通过STAX来与SOAP信息相结合。它不仅可以极大方便地实现这样一个环境，并且可以提供许多WebServices标准中高级特征，这些特征在多数的商业或者开源工具都没有提供。SOA架构的效劳管理组件：ESB企业效劳总线ESB简介企业效劳总线介绍ESB全称为EnterpriseServiceBus，即企业效劳总线。它是传统中间件技术与XML、Web效劳等技术结合的产物。ESB提供了网络中最根本的连接中枢，是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用效劳器协调运作，实现了不同效劳之间的通信和整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口[30]。2.企业效劳总线功能1)总线根底效劳框架：提供系统一致性、平安性、可靠性，以及性能何扩展能力保障的根底技术手段。2)集成效劳：提供根底的集成效劳与用户定制的应用效劳；支持多种集成效劳模式；支持效劳的封装、重用、效劳组合、效劳调度。3)公用效劳：提供内置的各种公用效劳。例如，渠道认证效劳，日志效劳等公用效劳。4)效劳管理和效劳标准：提供效劳配置管理的前台工具集合，并提供行业的效劳规约标准。5)系统监控：提供多角度的系统实时监控与交易报表，提供用户定制的告警。6)平安体系：提供多种平安机制并支持和第三方平安系统的有效集成，提供有效的平安监控机制。传统的EAI解决方案企业应用集成经历了从最初的点到点连接到基于消息的中间件再到基于SOA和ESB的开展历程[31]。EAI点对点集成结构存在着严重的隐患，即随着应用系统个数的增加。接口的数目将快速增长，其总数为n(n-1)个接口(n为应用系统个数)。应用系统之间存在着高度的耦合性。这为系统的维护带来巨大的复杂性，任何一个系统的升级和改动都将影响到其他与之相关的应用系统的修改。随着控制技术和信息技术的开展，企业信息化涉及到的子系统越来越多，点对点的集成方式已无法满足需求。图4.7点对点的EAI技术传统的EAI技术试图通过Hub-Spoke结构解决企业内部的整合问题。在SOA架构中的各效劳之间设置一个类似Hub的中间件，由它充当整个SOA架构的中央管理器的作用。这样，效劳的请求者和提供者之间有了一个智能的中转站，效劳的请求者不再需要了解效劳提供者的细节。图4.8Hub-Spoke结构的EAI技术SOA的应用场景是复杂的企业级架构，如果采用Hub的模式来构建SOA根底架构，从纯粹逻辑的角度，可能会出现以下问题：首先，如果每个效劳的请求都经过中央Hub的中转，那么Hub的负担会很重。速度会随着参与者的增多而愈来愈慢；其次，这样的系统会很脆弱，一旦Hub出错，整个SOA架构都会瘫痪；最后，这样的架构会破坏SOA的开放性原那么，参与者运行在一个相对封闭的环境中，扩展起来十分麻烦。企业效劳总线解决方案概念ESB的概念是从SOA开展而来的。SOA描述了一种IT根底设施的应用集成模型，其中的软构件集是以一种定义清晰的层次化结构相互耦合，其中，一个ESB是一个预先封装的SOA实现，它包含了实现SOA分层目标所必需的根底功能部件。ESB是一种是松散耦合的效劳和应用之间标准的集成方式，它可以作用于[31]：1)面向效劳的架构：分布式的应用由可重用的效劳组成。2)面向消息的架构：应用之间通过ESB发送和接受消息。3)事件驱动的架构：应用之间异步的产生和接收消息。图4.9ESB企业效劳总线如上图所示，ESB比EAI结构灵活的多：首先，它比单一Hub的形式更开放，总线结构有无限扩展的可能；其次，真正表达了SOA的理念，一切皆为效劳，效劳在总线中处于平等的地位。即使我们需要一些Hub，那么它们也是以某种效劳的形式部署在总线上。因此，ESB可作为SOA架构中实现效劳间智能化集成与管理的中介。优势ESB是一个完全面向企业级的中间件解决方案，可以架构在企业现有的网络框架、软硬件系统之上，构筑出一个企业级的信息系统解决方案。在ESB中，效劳器犹如一个个汽车站，可以自由地连接和脱离ESB中间件，所有的信息系统都可以通过其发送或接受任务、指令，它适用于所有的现有的或未来的信息应用平台。对企业而言，采用ESB中间件系统作为企业级信息系统融合方案中的中枢技术，几乎可以无须添加任何软硬件设备，就可把过去、现有和未来的IT系统整合在企业级的信息应用框架下，并且能为企业提供实时、大容量的信息通信和实时控制、管理和分配消息传递的能力。它能大大提高整个网络和信息系统的使用效率，还能为企业节省可观的整合费用。ESB在SOA系统中的实施阶段尽管ESB作为SOA架构系统中的关键组件，但是并不是作为根底组件，在开始阶段就去开发。Accenture首席技术官DonRippert认为激活SOA的全部潜力需要通过四个阶段，而ESB那么处于第三个阶段。他同时指出当前大多数的企业还只是处于第一个阶段，因此ESB实际上对于他们来说并不是迫切需要的[32]。而他所说的四个阶段如下所示：1)使用XML，以更标准的方式使用应用程序接口。2)捕获一些业务过程，并将它们转化成为Web效劳。3)引入并全面使用企业效劳总线。4)产生业务过程执行语言(BusinessProcessExecutionLanguage，BPEL)，它可由业务过程建模工具完成。BPEL可以改变应用程序的行为，而无需修改软件。另外，在IBM定义的实施SOA的五个切入点中——人员、流程、信息、连接性、重用，只有连接性和ESB相关。Bobby在他的文章中也说道，仅仅建造一个总线的工程是不可取的。IT部门认为只要建造了一个总线，人们就会围绕着总线来构造SOA的应用了。但是问题在于，当人们开始构造SOA应用时，他们会发现那些已经建造好的ESB已经不能满足当前的需求了。ERP系统架构技术的时间线通过ERP系统架构演变开展的资料分析，特意绘制了架构技术的时间线，如下列图所示：图4.10架构技术的演化时间线基于SOA架构的ERP系统是分解掉传统ERP的紧耦合特性，将ERP系统的内部功能以效劳的方式呈现出来，通过API调用的方式和其它系统交互；借助互联网B/S架构的先进性，可以在线随时访问ERP系统，免安装和部署，为企业能够节省IT运营本钱，提升ERP系统在企业内部的重要性。系统实现的关键技术关键技术框架及工具三层分布式架构三层架构介绍三层架构是[23]：1〕界面层界面层提供给用户一个视觉上的界面，通过界面层，用户输入数据、获取数据。界面层同时也提供一定的平安性，确保用户不用看到不必要的机密信息。2〕逻辑层逻辑层是界面层和数据层的桥梁，它响应界面层的用户请求，执行任务并从数据层抓取数据，并将必要的数据传送给界面层。3〕数据层数据层定义、维护数据的完整性、平安性，它响应逻辑层的请求，访问数据。这一层通常由大型的数据库效劳器实现，如Oracle、Sybase、MSSQlServer等。从开发角度和应用角度来看，三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发，每人可以有不同的分工，协同工作使效率倍增。开发双层或单层应用时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用时，那么可以结合多方面的人才，只需少数人对系统全面了解，从一定程度工降低了开发的难度。三层架构属于瘦客户的模式，用户端只需一个较小的硬盘、较小的内存、较慢的CPU就可以获得不错的性能。相比之下，单层或胖客户对面器的要求太高。三层架构的另一个优点在于可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行，充分利用网络的计算功能。分布式计算的潜力巨大，远比升级CPU有效。三层架构的最大优点是它的平安性。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。另外三层架构还可以支持如下功能：1〕RemoteAccess(远程访问资料)，例如可透过Internet存取远程数据库；2〕HighPerformance(提升运算效率)解决集中式运算(Centralize)及主从式架构(Client-Server)中，数据库主机的运算负担，降低数据库主机的ConnectionLoad，并可藉由增加AppServer处理众多的数据处理要求；3〕Client端发出Request(工作要求)后，便可离线，交由AppServer和DataBaseServer共同把工作完成，减少Client端的等待时间。分布式系统是充分利用效劳器资源，性能优势将系统的表现层、逻辑层和数据层部署到不同的效劳器上，这样做的好处是获取系统的可靠性和健壮性。一个典型的三层分布式的系统架构如下列图所示：图5.1典型三层分布式系统架构分布式系统介绍分布式系统有如下特点[24]：

1〕协作与互联分布式系统的重要作用之一就是能够整合大量地理上分散于各地的信息和效劳，如地图、电子商务网站、多媒体、大百科全书等。互联网上即时通讯系统和聊天室的流行凸显了分布式系统的另一个重要作用：与家庭、朋友、同事乃至客户保持联系。

2〕经济性包括PDA、笔记本、台式机和效劳器在内的计算机网络通常比集中式的大型机具有更高的性价比。例如，它们支持非集中式的、模块化的应用，这使得共享像大容量的文件效劳器、高清晰度的打印机等昂贵的外设成为可能。相应地，我们可以将选定的应用组件和效劳分配到具有特殊处理属性的计算机节点上执行，如具有高性能磁盘控制器、大容量内存或增强的浮点运算能力的节点，而那些简易的程序就可以运行在相对廉价的硬件上。

3〕性能与可伸缩性成功的软件通常会随着时间推移而拥有更多的用户和需求，因此分布式系统的性能能否扩展以处理不断增加的负荷至关重要。可以将已联网计算节点的处理能力组合起来以获得性能的极大提升，此外，至少理论上来说，多处理器和网络更容易扩展。例如，多个计算和通信处理任务可以并行运行在数据中心的不同节点上，或运行在同一效劳器的不同虚拟机上。

4〕容错性分布式系统的关键目标之一是允许系统发生局部故障。例如，尽管网络中的所有节点都运转正常，但网络本身可能会出现故障。类似地，网络中的某个终端系统，或多处理器系统中的某个中央处理器可能崩溃。这些故障应当能被很好地处理而不影响其他不相关的局部或整个系统。一种常见的容错实现方式是在多个节点或网络上提供重复的效劳。冗余性有助于将单节点失败的影响控制在最小范围内，它可以显著提高系统在出现局部故障时的可靠性。

5〕内在的分布性某些应用天生就是分布式的，如电信管理网络〔TMN〕系统、跨区域部门的企业级业务系统、对等网络〔P2P〕的内容共享系统、企业之间〔B2B〕的供给链管理系统等。分布式在这些系统中已经不再是一个可选项，而是满足客户需求至关重要的局部。基于WEB的B/S架构开发技术完全采用100%WEB，也就是B/S架构的应用软件才能以云计算模式给客户提供效劳。因为因为这种模式才能做到跨平台，兼容各种设备；其架构应该是基于互联网的架构，核心的业务逻辑是在后台效劳器上部署实现，客户端始终完成数据展现和交互操作。早期的那些基于单机、局域网的C/S结构软件是无法支持云计算的，虽然有某些软件公司为了急于搭上云计算这趟车，试图利用SOA、虚拟化等技术将20甚至30年前的C/S软件改造成为支持云计算模式，实践证明这是徒劳的。也是对客户不负责的。这绝对不是云计算，实际上是一种Multi-Tenant模式，这种模式无法解决高性能、个性化、跨平台等关键问题[2]。统一认证技术SSO简介SSO英文全称SingleSignOn，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比拟流行的企业业务整合的解决方案之一[34]。SSO技术实现机制当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行校验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了[34]。要实现SSO，需要以下主要的功能：

1)所有应用系统共享一个身份认证系统统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比拟，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志〔ticket〕，返还给用户。另外，认证系统还应该对ticket进行校验，判断其有效性。

2)所有应用系统能够识别和提取ticket信息要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。另外：1)单一的用户信息数据库并不是必须的，有许多系统不能将所有的用户信息都集中存储，应该允许用户信息放置在不同的存储中，事实上，只要统一认证系统，统一ticket的产生和校验，无论用户信息存储在什么地方，都能实现单点登录。2)统一的认证系统并不是说只有单个的认证效劳器认证效劳器之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别的单点登录。如：当用户在访问应用系统1时，由第一个认证效劳器进行认证后，得到由此效劳器产生的ticket。当他访问应用系统2的时候，认证效劳器2能够识别此ticket是由第一个效劳器产生的，通过认证效劳器之间标准的通讯协议〔例如SAML〕来交换认证信息，仍然能够完成SSO的功能。图5.2SSO系统架构示意图WEB-SSO的实现用户在访问页面1的时候进行了登录，但是客户端的每个请求都是单独的连接，当客户再次访问页面2的时候，如何才能告诉Web效劳器，客户刚刚已经登录过了呢？浏览器和效劳器之间有约定：通过使用cookie技术来维护应用的状态。Cookie是可以被Web效劳器设置的字符串，并且可以保存在浏览器中。当浏览器访问了页面1时，web效劳器设置了一个cookie，并将这个cookie和页面1一起返回给浏览器，浏览器接到cookie之后，就会保存起来，在它访问页面2的时候会把这个cookie也带上，Web效劳器接到请求时也能读出cookie的值，根据cookie值的内容就可以判断和恢复一些用户的信息状态。Web-SSO完全可以利用Cookie技术来完成用户登录信息的保存，将浏览器中的Cookie和上文中的Ticket结合起来，完成SSO的功能。为了完成一个简单的SSO的功能，需要两个局部的合作：1)统一的身份认证效劳。2)修改Web应用，使得每个应用都通过这个统一的认证效劳来进行身份校验。构件开发技术早在2000年，GartnerGroup①就预测到2003年至少70%的新应用将主要建立在软件构件之上。随着WebServices等技术的开展，将会进一步地推动构件技术的开展，而基于构件的软件开发方式也成为软件开发的主流技术[15]。什么是软件构件？工业化革命的伟大创新在于，功能再复杂的产品也可以由大量标准的零部件组装而成，分工越细、专业生产程度越高，总体生产效率就越高。构件技术就是一种类似于“零部件组装〞的集成组装式软件生产方式，它把零件、生产线和装配运行的概念运用在软件产业中，彻底打破了手工作坊式的软件开发模式。构件是软件的构成元素，具有一定的功能和结构，并符合一定的标准，可以完成一个或多个特定的效劳。构件隐藏了具体的实现，通过接口对外提供效劳。一般而言，构件是软件系统中具有相对独立功能、可以明确辨识、接口由契约指定、和语境有明显依赖关系、可独立部署、可组装的软件实体。广义上讲，构件可以是数据，也可以是被封装的对象类、软件构架、文档、测试用例等。软件生产方式的变革构件技术的出现是对传统软件开发过程的一次变革。构筑在“构件组装〞模式之上的构件技术，使软件技术人员摆脱了“一行行写代码〞的低效编程方式，直接进入“集成组装构件〞的更高阶段。图5.3软件构件开发技术基于构件的软件开发，不仅使软件产品在客户需求吻合度、上市时间、软件质量上领先于同类产品，提高了工程的成功率，而且对软件的开发和维护变得简单易行，用户可以随时随地应应对商业环境变化和IT技术变化，实现“敏捷定制〞。从最终用户的角度来看，采用基于构件技术开发的系统，在遇到业务流程变化或系统升级等问题时，不再需要对系统进行大规模改造或推倒重来，只要通过增加新的构件或改造原来的构件来实现。据已采用构件技术进行软件开发的我国某著名软件企业的相关统计显示，构件技术可以使软件的投放市场时间减少为原来的1/2到1/5，使软件的缺陷密度降低为原来的1/5到1/10，使软件的维护本钱降低为原来的1/5到1/10，使整体软件的开发本钱降低大约15%，长期工程可降低高达75%的本钱。构件化开发根本概念构件化，是指软件体系结构可重组以及软件组件可重用的系统开发方法。这种方法的根本内涵是：应用需求领域化，软件结构框架化，软件元素构件化，应用原型实例化。构件，是具有一定的功能和结构，并符合一定的标准，可以完成一个或多个特定的效劳的软件