《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、涉及到多个服务的交互，除了事务性外，其实还有服务间的同步并发问题需要考虑，比如有的服务可以并行执行，而有的服务必须等到其依赖结果的前置服务执行完后才能执行，这个又类似于进程间的通讯机制，既然同步又要并行，是矛盾而又共存的统一体。
        总之，有了面向服务理念，还要加上人的努力，毕竟科技以人为本！
        以上是本人的愚见，学习中，不知道思考得对不对，希望大家多发意见，共同探讨！