浅谈web系统的服务化(一)

对于系统的架构，特别是web前端（不包括js，css本身的框架）的架构，作为java工程师，每个人都有自己的意见，而且总是众说纷纭。从另外一个方面来讲，世界上没有真正的银弹，基于此，很难有一个全体程序员都接受的框架，只有在一定阶段适用的框架。

[b]系统框架中的服务[/b]
服务的概念很久之前都产生，记得当初研究生导师给出了一句话，其实在编程语言的角度来将，真正的革命性的理念就是 面向对象的设计理念的推出，这些所谓的服务概念只不过是扩展而已。我认同这个观点，但是我同时认为服务的提出，虽然不够革命性，但是它在拓展人的编程思想有很大的推进作用。

[i][size=large]1.关于什么是服务[/size][/i]
很难讲，众说纷纭，我也给不了定义。但是个人认为的服务一定要体现内聚性，这样与外界的沟通要小。另外，对于提供出去的服务根据用户的需求，提供必要的再加工和扩展的能力。
看看维基的解释：http://en.wikipedia.org/wiki/Service_(systems_architecture)。可以看出来基本有两个概念：重用 & 协议。（这有点像个定义，我给出的还是偏向于实现）

[i][size=large]2.服务的具体实现[/size][/i]
服务也需要一个服务框架的支撑，基于维基和平时的感受，协议是构成服务最重要的基础：服务的接口定义，服务的结果返回格式，以及服务的传输方式等。我的伪定义上继续来讲，中间主要给出三个概念：少沟通，再加工，扩展。基本上来，这三个概念中，少沟通，与扩展，都是对于服务的接口，而再加工都是服务返回的结果。

[i][size=medium]2.1 网络的传输协议[/size][/i]
说到这里，我想起来了中间件,衔接两个系统之间，支撑两个系统的沟通方式，这样的工具总能够很好的填补这里的空白。而网络传输的方式，有很多种，比如ISO的七层，TCP/IP的5层(有地方成为4层）等等，每层都可以作为支撑，或者基于这些传输再进行概念包装，RPC,RMI,dubbo等。然后基于这些概念，需要给出服务传输时候的接口以及返回结果的描述，如 wdsl，xdr 等等。
-----------------------后面需要实例补充-------------------------------------

[i][size=medium]2.2 服务的接口定义[/size][/i]
接口定义个人觉得很重要。这个直接关系到服务抽象的粒度和好坏问题，一般来讲，越少的参数个数，意味着越少的外界沟通。服务就更加内聚。但是这里对参数也是有一个抽象，比如

    public void add1(long a, String b, int c);
    public void add2(A a);
    class A{
       private long a;
       private String b;
       private int c;
    }

这里 add1 和add2 的接口参数是一样吗，然后他们与外界的联系少吗？在我看来，很难下结论，需要对业务的理解才能知道，单从编程的角度来看，add2只是变相的达到"方法调用参数要尽量少"这条准则，而没有解决实质原因。
接下来看这两个：

     public void addStudent(long id, String name, int age);
     public void addStudent(Student student);
     class Student{
          private long id;
          private String name;
          private int age;
     }

     /**
      ** addend : 被加数
      ** added : 加数
      ** times : 被加的次数
      **/
     public void addition(long addend, long added, int times); 
     public void addition(Quantity  quntity);
     class Quantity{
          private long addend;
          private long added;
          private int times;
     }

第二个例子就抽象的不太好，合并在一起成为一个类，有些牵强，将 addend 和 added 合并起来形成一个概念似乎还行，但是把times也加上就有些奇怪。反过来，其实也在考虑这个 addition方法是否抽象的合适。
类似于以上的情况，如果我们采用Map来参数接口，其实不太合适的。Map是一个弱对象结构，没有太多的抽象意义。所以我认为，接口的定义还是需要要有概念的抽象，而且尽量少用弱的对象结构。因为有些场景为了扩展，也会用到弱对象类型。
而如果系统中原本的模型抽象做的比较好，这些接口定义也就是顺理成章的事情。也就是好的系统中业务的概念模型都会抽象的很好。 比如 电信业务中的三户模型（用户，账户，客户）。

[i][size=medium]2.3 返回的结构格式[/size][/i]
对于返回的格式，原本以为是不重要的，我给你数据，你使用就好了。根据这几年的使用情况，发现返回的数据是需要再加工的。这样返回的数据结构就变成很重要了。一般情况下，返回的数据格式都不会太复杂，比如使用json，xml，结构化对象。而根据服务提供的不同的场景或者层面，其数据要求又不相同。(List, Map...)

但是目前希望服务的层面似乎越来越高，能够直接生成HTML页面使用。个人认为可以实现，但是还是需要去思考的,还是要回到上面概念抽象的角度上，甚至更多。比如服务需要重用，而页面的样式可以重用吗，需要从需求设计的时候去思考，包括数据部分+页面的展示部分。

[i][size=large]2.服务的维护和升级[/size][/i]
后面再加上..