【IT168 SOA文档】    最近好久没更新blog了，是因为最近都在忙着思考SOA相关的东西，确实是需要好好整理的时候了。
    SOA涉及面很广，以至于感觉到新名词目接不暇呀，今天主要从最简单的Web service规范讲起吧。
    Web service与SOA的关系，这个议题觉得过大，因为要一下讲清楚并不是那么容易的，还得从第一代Web service规范来讲起。第一代Web service规范的关注点主要是关注于基本SOA，这个其实很容易想到，既然是面向服务架构，必定有service、service之间的关系、当然还有管理service注册的注册中心。
    用于描述service的规范是WSDL规范，其主要部分包括两部分：1、抽象部分 2、具体部分，抽象部分包括服务提供的接口（portType），该接口内就有操作和消息，相当于普通Java接口的函数以及函数参数，具体部分就包括具体的binding协议类型、服务地址等信息，让服务请求者可以通过服务地址信息找到某个服务，并用相应的协议与之通讯，调用的接口信息则已经在抽象部分给出。
    用于描述service与service关联的消息（也就是服务间的关系），一般就有SOAP协议消息框架来完成，SOAP消息由evenlop包装，包装了消息头和消息体，其中消息头可以包含丰富的控制信息，以便让服务可以尽量保证无状态，而消息体则是具体的信息负载部分，也就是具体的数据部分了。
    用于管理服务注册的UDDI规范，该规范一般在服务比较多的情况下，为所有的服务提供一个注册的场所，让服务请求者可以到这里来寻找需要的服务，其实就是一个简单的server locator模式了。 如下图:

    该图简洁明了，给出了第一代Web service关注点，其实读此书（《SOA概念、技术与设计》）的感觉收获最大的是理清楚了以下几个概念：
    1、面向服务架构是什么？在面向服务架构中，至少有某些服务具有可复用性，其实也就是可以SCA中的递归装配来组装出新的构件，但如果颗粒度把握不当，难以根据后续需求变化复用上任意一个服务，那么我的理解那也就不是面向服务架构，而充其量只是披着Web service外表的传统分布式架构而已。我们在设计中，应该全局把握所有的需求，以面向服务的思维来分析需求，找出可以复用的不可再分服务，封装之，但颗粒度方面又不能太小，这便是考验设计师的功底的时候。
    2、 Web service一系列规范给出了实现SOA所必须的一些基础设施，但并不是唯一，第一代Web service只是给出了服务的描述（可以用WSDL），以及服务通讯的消息规范SOAP，从某中程度上来说，实现了SOA所要求的服务自治，消息智能，但这些完全不够，因为我们知道正如拿Java还是可以用static方法来做面向过程的编码一样，这里面主要是人的因素，人的思维模式的改变，用面向对象的视角来看世界，自然世界中的万物皆对象，每个对象有自己的状态和行为，每个功能是各个对象相互合作，相互作用的结果。而用面向服务的视角来看世界，自然世间万物皆服务，这样是不是就可以连同C语言也可以提供服务，因为不一定提供服务的就是对象，确实已经有了C的SCA客户程序与实现规范。从个人到公司到政府，从小到大，从动物到静物，从具体到抽象，他们都扮演着对外提供服务或消费服务的角色，当然具体角色要根据不同的上下文来判断。
    3、为某个企业或政府规划SOA架构，并不能先上一部分，再上一部分。不做全局考虑，不统一相应的业务规范，形成规范的XML交换文档并统一输理整个全局业务流中的元数据是很难真正做到完全面向服务架构的，因为这样的话，可能会出现只考虑到特定业务属性，结果数据不兼容，连数据都无法共享，更别说复用服务功能了，所以在分析服务契约（其由WSDL、XSD schema、策略组成）时，我们必须保持全局观来分析业务。
    4、面向服务架构的另一重要面——互操作性，这个是很容易忽略的，如果没有互操作性的保障，其也不过是披上了Web service的外壳，而比手工做两子系统之间的接口没什么两样，当然他可以实时导数据了。没有充分发挥出通过复用服务而快速开发解决方案的优势。
    5、从某种意义上来说，服务可以与面向对象UML中的用例类比，他可以分为业务服务、工具服务，业务服务其实就是主要提供功能的业务逻辑。工具服务是被用来完成特定功能的服务，比如负载均衡服务，服务请求可以先发给负载均衡服务，然后由他来计算后端目标服务的负载状况，然后转发请求。是否可以将SOA中被复用的服务类比为在面向对象中变化会相对比较剧烈的用例呢？组合已有的服务，通过WS-BPEL来编排现有服务，从而形成新的服务，该规范就其实包含了基本流程以及结构化流程，从某种程度上可以与编程语言类比，包含了顺序、条件、循环三大结构化程序语言的特性。
    6、最后一点，就是由于服务是自治的、相对独立松散耦合的，那么又可以通过组合服务将其组合成新的大的服务，就必然会遇到编程中的事务性边界问题，这个由WS-协调规范（WS-*扩展规范）解决之，可以与SCA中的事务相结合来看。
    7、涉及到多个服务的交互，除了事务性外，其实还有服务间的同步并发问题需要考虑，比如有的服务可以并行执行，而有的服务必须等到其依赖结果的前置服务执行完后才能执行，这个又类似于进程间的通讯机制，既然同步又要并行，是矛盾而又共存的统一体。
    总之，有了面向服务理念，还要加上人的努力，毕竟科技以人为本！
    以上是本人的愚见，学习中，不知道思考得对不对，希望大家多发意见，共同探讨！