面向服务架构的一些思考

　　在谈面向服务架构之前，首先来看看什么是服务。常谈的业务组件，业务方法或操作是否都是服务？真正的服务必须满足两个条件，一个服务本身是能力供给，必须有外界的需求；一个是服务本身是可复用或重用。一般来讲服务应该是可重用的任务，这种任务可以是业务方面的操作组合，也可以是一种技术能力。

　　面向服务的重点就是一切以服务为中心，从服务识别，服务分析，服务设计，服务开发和服务上线使用一切都是以服务为中心。但是要注意到面向服务本身不是在面向结构或面向对象基础上的一个新方法，而是对面向对象和组件化思想的提升。

　　面向服务架构很容易被理解为一种技术架构，而SOA本身更多的是一种架构风格，这种架构风格和传统软件开发最大的不同是更加体现了业务和流程驱动IT的思想，体现了IT系统组件化和服务化构建思想，体现了由于服务本身可以重用，可以通过服务的组合和编排来满足业务的实现。SOA作为一种架构风格，使需求方和供给方有了共同的语言和价值约定；SOA作为一种架构风格，使服务不在单纯的是一种技术能力，而更多的是一种业务能力和IT智慧资产。

　　看看维基百科上SOA的完整定义：

A service-oriented architecture (SOA) is an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network. The principles of service-orientation are independent of any vendor, product or technology.[1]

A service is a self-contained unit of functionality, such as retrieving an online bank statement.[2] By that definition, a service is a discretely invokable operation. However, in the Web Services Definition Language (WSDL), a service is an interface definition that may list several discrete services/operations. And elsewhere, the term service is used for a component that is encapsulated behind an interface. This widespread ambiguity is reflected in what follows.

Services can be combined to provide the functionality of a large software application.[3] SOA makes it easier for software components on computers connected over a network to cooperate. Every computer can run any number of services, and each service is built in a way that ensures that the service can exchange information with any other service in the network without human interaction and without the need to make changes to the underlying program itself.

　　一般说SOA是一种架构方法，将单片式应用打破，分解为离散的、自治的业务服务，利用标准提升他们的互操作性，从而可以更好地共享、重用和组装，快速构建复合的应用从而满足业务需求的变化。在这里面有两个重点，一个是要找到可重用的服务，同时这些服务满足离散，自治和无状态等基本条件；其次是服务本身可以组合和编排，以满足流程整合的需要。

　　第一步找服务的过程，是系统分析和建模从顶向下得过程，要充分体现流程驱动IT的实现，通过流程的分解，业务建模和数据建模，识别业务组件和业务能力，通过跨系统或组件的流程交互识别可重用的服务。最终形成可重用的服务智慧资产库。第二步服务的组装和编排则更多是从底向下得过程，对于原子服务我们可以组合为组合服务，对于业务服务我们可以通过组合和编排形成流程子服务和流程服务；最终使可重用的服务满足流程交互的需要。

　　在跨系统的流程集成和SOA应用集成过程中，高端建模重点则是EA企业架构或TOGAF方法论，从业务架构，数据架构和应用架构入手，逐层分解和展开分析来得出总体的跨业务系统流程交互和集成架构。而对于系统内的SOA应用，则重点仍然是业务组件识别，通过组件间交互得到的服务组件和服务识别，可重用的服务组件单元的提取。

　　那么对于应用系统本身基于SOA架构又如何理解？如果说一个应用系统基于SOA架构，我们至少需要看到该应用系统有明确的业务组件和服务组件定义，而且组件之间满足高内聚松耦合的要求；其次对于组件间的交互都通过服务的方式进行，或者至少预留了服务接口；其次内部这些服务可以灵活的重用或组合。至于是否有内部的ESB总线反而不是重点，但是我们看到如.NET开发内部的IOC机制基本也基于内部的软总线思路，实现良好的互操作性和位置透明。

　　SOA另外一个核心是实现两个层面的解耦，一个是业务和技术的解耦，业务实现不再依赖于某种特定的技术或语言，只要满足业务标准都可以来实现SOA和服务，正是因为业务和技术松耦合，技术的变化对业务影响越小。另外一个方面则是操作方法和业务数据实体的解耦，对于操作方法我们后续可以通过WSDL文件定义，而传输的数据实体又可以通过XSD定义，对于RUP开发方法中，类似于控制类和实体类的分离。

SOA有一些基本特性，在这里再做一下简单解释：

粗粒度：仅仅暴露需要暴露的东西，方法和传输都简单，但是实现方法的内部过程则很复杂，业务规则或逻辑全部隐含在业务组件内部，不需要暴露。

无状态：每次服务调用完成即完成，不会存储任何全局状态信息，这也是WebService的特性。

互操作：包括位置透明，通过ESB和UDDI，只需要关心服务目录，而不需要关心具体提供服务的源系统。

标准化：有精确的服务契约和服务接口，这也是在SOA方法论中在服务识别和服务分析阶段重要输出。

　　如果说要举个简单的例子来说明SOA，可以直接拿我们生活中的汉语来说明：生活中的的3000-4000个常用字即是最基础的原子服务，有了这些原子服务很容易通过这些字去组织表达想表达的东西。说话的内容有调整通过调整这些汉字的顺序，即原子服务的顺序来完成表达新的东西。但是如果全是单个汉字组合表达意思说起话来嘴都累，所以再向上就会出现词组或常用短句、成语等，这些即是组合服务，这样说话速度可以增加，说话量减少，别人也听的懂。从这里可以看到词组或短语的可重用程度相较单个汉字的降低了。所以越到组合服务或流程服务，复用越困难，但是要是能够复用却能大大提升效率。