面向构件SOA架构设计 解决软件灵活性问题

　　目前，关于SOA(面向服务的架构)的研究和讨论已经成为IT业界的新热点。尽管各方研究者和专家对SOA架构的认识和理解不尽相同，各IT厂商提供的SOA解决方案也不一而足，SOA相关标准仍在不断发展和完善之中，但大家却都有一个共同的认识，那就是SOA代表着今后一段时期软件技术的发展方向，并已经开始从研究阶段进入实施和推广阶段。本文试图从面向构件的角度，介绍一些SOA架构设计的基本思想和方法论。首先简单介绍一些构件设计和实现的基础知识，然后重点介绍面向服务设计的基本原则和方法。

　　构件的组成要素

　　构件是软件开发、复用和软件组装的实体单元，包括以下要素：构件类型(componenttype)、构件实现(componentimplement)、提供接口(provides-interfaces)和依赖接口(requires-interface)。

　　构件类型(componenttype)：构件类型表明构件是处理什么问题和提供哪些接口功能，它包含了构件类型的名称。

　　构件实现(componentimplement)：对构件类型的具体实现称为构件实现，一个构件类型可能有多个构件实现。

　　提供接口(provides-interfaces)：提供接口指构件提供给外部程序使用的接口。

　　依赖接口(requires-interface)：依赖接口指构件运行时所必须依赖的外部程序接口。

　　构件的基本特征

　　复用：复用是构件最基本的性质，构件的设计必须满足未来能在新的应用、项目中使用。

　　封装：构件封装对外界隐藏构件的设计和实现细节，仅通过接口与外界交互。这可以保证构件功能复用的完整性和构件开发及交付的独立性。

　　组装：构件可以通过组装形成新的构件或系统，组装是构件复用的手段，同时具备可插拔，便于替换，系统可以由不同的开发商开发的构件组装而成。

　　粒度：构件是有大小的，越是跟领域相关的构件粒度越大，小粒度的构件可以方便的组装成较大粒度的构件。

　　层次：构件可以按层次进行划分，企业级应系统的复杂逻辑可以通过层次来解决，不同的层次需要不同层次的构件。按照MVC的体系架构，可以把构件划分为：展现层、控制层、业务层、运算层及数据层等。

　　构件的实现

　　目前软件市面上有三个代表性的构件技术标准分别是：COM/DCOM、CORBA和EJB。

　　COM/DCOM：COM(Conponent Object Model)是由Microsoft公司推出的构件接口标准，DCOM是指可以分布式布的COM。

　　CORBA：CORBA(Common Object Request Broker Architecture)是由对象管理组织(OMG)提出的构件技术标准。

　　EJB：EJB是由SUN公司提出的构件技术标准。

　　以上三种构件标准实现的构件互相依赖的方式仍然是基于对象接口式的，当系统复杂度到一定规模时，整个系统会因依赖关系混乱而陷入失控。

　　比较理想的构件模型是构件之间是数据耦合的，每个构件只单独与数据总线发生联系。当需求发生变化时，可以对各个单独的构件进行添加、减少或者修改而不影响整体的架构和性能。基于数据耦合的构件，据有很高的独立性，对需求变化有较强的适应能力。

　　构件技术与构件化

　　构件技术与构件化的区别在于，构件化的关注点不在于构件本身的技术实现，而在于如何把应用系统分解成稳定、灵活、可重用的构件，在于如何利用已有的构件库组装出随需应变的应用软件，从一个面向构件的环境中去分析应用，如何做出灵活、重用的构件来思考。但是，构件技术是构件化的基础，它为构件的工厂化生产提供技术保障。传统的软件方法学是从面向机器、面向数据、面向过程、面向功能、面向数据流等反映问题的本质;而构件技术关注的是在构件已经可用的情况下，在更高层次上的组装和复用。面向构件的软件设计方法把装配和制造分离，构件运行时负责提供标准接口和框架，负责软件装配，而构件负责软件的制造，使软件开发变成构件的组装。

　　接下来，我们将开始介绍面向服务(SOA)的设计。

　　面向服务设计

　　服务代表一段完整的业务单元，并且可以根据特定用户的需求组织成为更大和新的服务。服务可以由一个或多个构件组合而成。服务开发者必须考虑构件的粒度，以及构件的流程和组装，这样他们在改变服务的实现时，可以尽可能少的影响其它构件、应用和服务。而服务的设计者则更关心选择合适的服务，并将它们以可管理的方式组织，并最终将它们组装为完整的业务流程。

　　“面向服务”表示一种分离系统关注面的方法，其实质是将一个比较大的问题分解成一系列较小的、互相关联的子问题，从而降低问题的复杂度，使得我们能够较从容地分析、解决和管理它。传统的面向对象的设计方法其实也是一种分离系统关注面的方法，只不过它是在对象层面来分离关注面，相对业务逻辑较远，而面向服务则是在服务层面来分离关注面，直接关注的是业务逻辑，从而使面向服务能够(至少在理论上)更好地满足业务需求。