|
SOA
Web服务作为炙手可热的技术，如何应用到企业的IT系统和商业流程之中、并给企业带来直接的经济效益，一直备受国内外企业管理者的高度关注和推崇。而在近两年，出现了一种技术架构被誉为下一代Web服务的基础架构，它就是SOA（Service-oriented architecture，面向服务架构）。1996年，Gartner最早提出SOA。2002年12月，Gartner提出SOA是"现代应用开发领域最重要的课题"，还预计到2008年，SOA将成为占有绝对优势的软件工程实践方法，主流企业现在就应该在理解和应用SOA开发技能方面进行投资。 更好支持商业流程 SOA并不是一个新事物，IT组织已经成功建立并实施SOA应用软件很多年了，BEA、IBM、等厂商看到了它的价值，纷纷跟进。SOA的目标在于让IT变得更有弹性，以更快地响应业务单位的需求，实现实时企业（Real-Time Enterprise，这是Gartner为SOA描述的愿景目标）。而BEA的CIO Rhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA，并且从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户化和人员技能的投入等方面取得了不错的成绩。 SOA是在计算环境下设计、开发、应用、管理分散的逻辑（服务）单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA鼓励使用可替代的技术和方法（例如消息机制），通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。 SOA也不仅仅是一种开发的方法论--它还包含管理。例如，应用SOA后，管理者可以方便的管理这些搭建在服务平台上的企业应用，而不是管理单一的应用模块。其原理是，通过分析服务之间的相互调用，SOA使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。 SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序是无法包容业务用户的（各种）需求的，即使是一个大型的ERP解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口，对市场快速做出反应，商业用户只能通过不断开发新应用、扩展现有应用程序来艰难的支撑其现有的业务需求。通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是，基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的--这是从上向下看的。这种角度同一般的从可用技术所驱动的商业视角是相反的。服务的优势很清楚：它们会同业务流程结合在一起，因此能够更加精确地表示业务模型、更好地支持业务流程。相反我们可以看到以应用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。 企业流程（enterprise process）是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方法。例如，会计可能是企业服务系统的一个组件--但是将发票寄给客户却是一个业务流程。服务被定义用来支持业务流程，因而贯穿整个流程始终的是：各种服务组件在流程和逻辑实现过程中的装配操作。理解业务流程是定制服务的关键所在。 有利于企业业务的集成 传统的应用集成方法（点对点集成、企业消息总线或中间件的集成（EAI）、基于业务流程的集成）都很复杂、昂贵，并且不灵活。这些集成方法难于快速适应基于企业现代业务变化不断产生的需求。基于面向服务架构 (SOA) 的应用开发和集成可以很好的解决其中的许多问题。 SOA 描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。 不同于传统的应用集成方法，在 SOA 中，围绕服务的所有模式都是以基于标准的技术实现的。大部分的通信中间件系统，如 RPC、CORBA、DCOM、EJB 和 RMI，也同样如此。可是它们的实现都不是很完美的，在权衡交互性以及标准定制的可接受性方面总是存在问题。SOA 试图排除这些缺陷。因为几乎所有的通信中间件系统都有固定的处理模式，如RPC 的功能、CORBA 的对象等等。然而，服务既可以定义为功能，又可同时对外定义为对象、应用等等。这使得 SOA 可适应于任何现有系统，并使得系统在集成时不必刻意遵循任何特殊定制。 SOA 帮助企业信息系统迁移到"leave-and-layer"架构之上，这意味着在不用对现有的企业系统做修改的前提下，系统可对外提供 Web 服务接口，这是因为它们已经被可以提供 Web 服务接口的应用层做了一层封装，所以在不用修改现有系统架构的情况下，SOA 可以将系统和应用迅速转换为服务。SOA 不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等 IT 架构中的功能和数据。因为基于 SOA 的应用能很容易地从这些基础服务架构中添加功能，所以基于SOA的应用能更快地应对市场变化，为使企业业务部门设计开发出新的功能应用。 下图提供了使用基于服务集成的企业应用的高级视图。与传统的企业应用集成架构的主要区别在于该系统使用基于标准的服务，并包括过程/数据服务、编排和组合。基于标准的服务成了应用间的集成点。服务的编排和组合增加了服务的灵活性、重用性和集成性。  图示：使用基于服务集成的企业应用 SOA服务粒度 可以按基于服务的功能及发送和接收的数据数量来定义服务，如细粒度服务、粗粒度服务或组合服务。 在 SOA 中服务粒度有两种相关的意思：服务是如何实现的，服务使用和返回了多少数据或多少消息。细粒度服务执行了最小的功能，发送和接收少量的数据。粗粒度服务执行了较大的业务功能，并交换了更多的数据。 细粒度服务是供粗粒度服务或组合服务使用的，而不是由终端应用直接使用的。如果应用是使用细粒度服务建立的，则应用将不得不调用网络上多个服务，并且发生在每个服务上的数据量较少，因而会对对系统整体性带来影响。所以粗粒度服务的用户不能直接调用他所使用的细粒度服务。然而，由于粗粒度服务可能使用多个细粒度服务，因此它们不能提供粒度级的安全和访问控制。 组合服务可以使用粗粒度服务和细粒度服务进行组装。数据数量数量不是粗粒度服务和组合服务之间的区别。粗粒度服务例子，如创建新客户，在这一过程的操作是：需要通过一些外部服务验证对客户进行验证，并在 CRM 应用系统中创建客户记录。组合服务例子可以是提供一个新的DSL线，这需要一个服务调用来验证定单、创建或验证客户，确认产品库存及为数据线分配资源。 下图描述了服务粒度的不同级别及它们之间的关系。  图示：服务粒度 通过一组有效设计和组合的粗粒度服务，业务专家就能够有效地组合出新的业务流程和应用程序了。 SOA与Web服务 SOA不是一定需要 Web 服务来实现，并且一个基于Web 服务开发出来的应用也不代表就是一个基于 SOA 构架应用。Web 服务只是服务实现的一个典型，是实现企业 SOA的一个组件（非必需组件）。SOA 为基于服务的分布式系统提供了概念上的设计模式。Web 服务则是基于标准的、可经济实惠地实现 SOA的一项技术。 SOA将IT资源透过服务这样一个在业务上有重要涵义的概念来提供、共享，把IT与业务的距离更加拉近了一步。服务在涉及的层次上要比组件、函数、流程等更高，而且往往在业务上可以找到与之直接对应的概念或实体，例如报价、订单。服务打破了IT系统间的藩篱，就像一家公司的各个部门，平常各自扮演特定对内或对外服务的角色，但彼此间如果能有效地通过共通的语言及文字，进行良好的沟通，便能协力达成更大、更高的目标。 随着SOA和Web服务的潮流，带来了组合式应用（composite application）的开发方式和观念，开始逐渐被大量应用在Portal（门户）和Integration（集成）上。组合式Portal的做法，就是通过Portal界面所提供的应用，往往不是真的在Portal服务器上执行，而是将Web服务即时抓过来，再加以呈现，同时汇总给Portal的使用者。在整合方面也是采用组合式的方式。通过高级工具来设定，使系统得以灵活地配合任务的调整，对各项以Web服务方式提供的服务进行不同形式的串联和协作，同时快速地加以部署。2004年3月，BEA发布了一个企业门户合理化（enterprise portal rationalization，EPR）战略，这个战略用来平衡BEA WebLogic Platform的SOA能力，凭借最好的行业实践和行业专家，帮助客户解决多年来形成的散乱的portal和Web应用程序开发。 如果说Web服务等技术是SOA的血肉，那么正确的服务设计理念及系统运行平台则是SOA的灵魂。SOA试图让IT能更快和业务同步，在规划上以提供弹性的业务服务为目标。从CIO到负责规划的系统分析人员，需要和业务单位、策略伙伴间有充分的沟通。CIO必须认识到，SOA的建立将是一个为期数年的承诺，基础建设需要按部就班地进行，资助的模式也必须在IT和各个业务部门间建立，来陆续支援基础建设及各项业务服务的开发。 在中间件领域，SOA架构日益成为中间件软件供应商争 |