面向服务的框架

  Service-Oriented Framework

1       框架

在这里，框架是指特定领域应用框架。

在历史上，创建的很多框架，会造成一种强约束，太多需要去遵循的条条框框。而我认为，一个可用的框架，对于框架的使用者而言，应该减少遵循的法则，极少数的限制应该是符合最佳实践或者是设计模式。

框架应该是一个松散的结构，这个结构定义了一个抽象的运行时状态。它表示一组资源的操作契约。

由于这个框架是特定领域的应用框架，因此，它的结构中存在必要的基础设施，就好像一个房子它如果是住宅，那必然要有厨房基础设施，比如燃气管道，排烟通道，上下水，等等。

我在这里希望讨论的特定领域是企业信息系统。

然而，框架仅提供基础设施接口，而非实现，就好比燃气管道可以输送液化气，也可以输送天然气，水管可以输送纯净水，自来水，冷热水。这并不重要。

框架对于应用开发者而言，仅需要关注业务领域知识，然而几乎所有的新技术，新标准，新框架，新平台出来时都是如此承诺的，但是这几乎很难兑现。这是个两难问题，既不能太具体，也不能太抽象。

因此，我接着会谈到服务分层。

一个框架并不能兑现所有承诺，那就使用子领域框架来完成。子领域框架更加贴近某类应用，比如CRM，或者是Blog。而具体的项目，则基于子领域框架构建，架构师负责将领域概念转为软件模型，我倾向于这是一个对象模型，因为在描述业务领域方面，其使得从业务概念到软件模型的转换更自然（可以在讨论DDD时再详说）。

其实，我使用过一些复杂的应用框架，比如Oracle Application Framework，它对于企业信息系统抽象的很好，可惜的是由于历史原因，技术比较落后，使得其非常的笨拙，但是很多方面是值得借鉴的。

抛开技术本身，一个能够为大家所用的框架，也应该有丰富的文档，已经解决典型问题的丰富的案例库。

2       服务分层与服务分类

服务按照在应用中所处的不同位置和面对的不同方面应该分出不同层次，可以包括：

1 基础设施服务层，例如分布式缓存，安全，并发，UI，命名服务，事务，日志（审计）

2 应用服务层，例如邮件，工作流，搜索引擎，目录，BI展现引擎，消息

3 领域（业务）服务层，例如会议室，部门列表，地址名录，员工档案

从服务的分类来看，存在一种传统意义上的Web Service服务，和另外一种传统意义上的Mashup服务，或者是现在流行的App。

关于UI服务，我是受到了Google的Code PlayGround，Adobe Flex Samples库，以及Dojo可以通过放在AOL上的链接进行调用的启发，何必每个项目都要去选择控件呢。另外我也受到Oracle Application Framework的启示，图片之类的资源也可以公用。此时可能有人会想到面向资源的架构。

再来谈谈并发服务，我是希望能够像安全，事务一样，利用AOP来透明的实现并发，这或许比较其他方面更难，多线程甚至是多进程的处理和协作模型虽然看起来是清晰的，但是通过配置来使得开发者受益需要进一步思考，我最近阅读了很多相关资料，包括特定领域应用框架：行业的框架体验，Java编程思想里的线程一章，Effective Java的线程部分，以及IBM上的一些文章，还有一些学术论文，JBoss的手册，这是个不近不远的目标。

然后说说搜索引擎，我认为对于具体项目而言，搜索就像使用Google做站内搜索一样简单，建库也只是简单几个URL搞定的事儿。

最后说说员工档案，这样的服务应该提供有价值的统一服务，这个概念可能那些做数据库的会想到主数据库MDB。

3       分离服务与服务组件

3.1     服务只是一种契约

服务仅仅是一种契约，我提供什么资源，你给我提供什么服务，我会得到什么，当发生意外，会怎么样。

一般服务都会有个名字服务来进行注册，比如JNDI，UDDI之类的，也就是告诉我服务在哪。

一定要将服务和服务组件分离开，服务组件是用来提供服务的。

周末家里的抽水马桶堵了，于是打电话给12580说明情况，她帮我转接了一个家政服务的电话，然后我说明了我的情况，对方就说派一个人来修。

其实我并不关心服务来自于哪，由谁来提供。

我会遇到问题时就给12580打电话，比如最近的银行，去某个地方怎么走之类的，我只需要记得这个号码就可以了，然后表明我需要什么服务。

3.2     只依赖真正的标准

如果上一节我还说得不够清楚的话，那么我再明确的表述一下我的意思，就是提出服务时，不要谈及SOAP Web Service，还是Message Service，或是RESTful Web Service，或者是Corba。

我看了Corba的承诺，SOAP Web Service的设想，后来又出来RESTful web service，之后ROA有了两个意思，一个是Resource-Oriented Architecture和RESTful SOA。我还开发过SCA（Service Component Architecture）的程序，使用过Active MQ，Spring HTTPInvoke。

经历了这些觉得除了HTTP协议，XML（现在可以提及JSON了）之外的神马都是浮云。

3.3     不同的外套

在浏览视频网站进行分享时我受到一个启示，就是点击分享时，它会生成三种格式供你分享之用，分别是用于IM分享的本页的链接，一种是HTML代码<embed src=，一种是Flash链接。

其实服务也可以这样，同一个服务，可以生成不同的接口，比如用于Spring程序直接调用的Spring HTTPInvoke服务，或者是SOAP Web Service，或者是RMI，这些都需要生成一些桩代码。或者是用于JS调用的Javascript片段，或者是一般的RESTful Web Service。就像视频分享网站一样，你只需点击一个按钮即可。

服务就像披上了不同的外套一样，可以出席各种场合了。

3.4     微引擎

这需要实现一个微引擎来做这件，其实这个结构非常简单，而且可以有扩展性。可以很简单的利用字节码生成（对于Spring HTTPInvoke，或RMI），或者是XML生成（SOAP，或用于RESTful）。

服务组件本身可以一个jar包，然后微引擎将其转为web service，或者是通过URLConnection远程加载jar包（或者是用一个框架辅助这件事，比如OSGI）。一个服务组件本来可能就是一个Web服务（这里稍微在概念上不太严谨，服务组件在这里应该称为服务契约的实现或具体提供者），那么引擎会将其转为需要的接口服务。

生成的代码可以缓存起来，就像JSP的机制一样。

3.5     服务中心

建立服务中心很重要，它可以发布，管理，搜索，转换（换外套）服务。并且还可以预览和测试服务。

服务中心的意义在于使得其能够成为稳固的IT资产。

4       分布式服务，而非分布式对象

Martin Fowler的分布式对象第一法则提到不要分布你的对象。但是其支持分布式服务。

因此千万不要在这里搞神马分布式对象。

5       面向服务的框架

在过去的开发经历中，我比较熟悉并自然的划分为多个层次，比如展现层，领域层，数据访问层等。在开发大型项目时，不同子系统的调用还有专门的Import和Export的Façade层。这使得系统会被竖着切若干刀。

后来在项目中使用了AOP，来进一步分离关注点，于是横着又对系统切了若干刀，所谓横切面。

这时系统变成了一个网格。

5.1     敏捷开发框架

我之前写过一篇帖子谈论利用CoC来快速构建应用的框架，我现在的想法更近了一步，就是加入分层次的Service，在线的UI组件库，利用内容管理工具整合RESTful web service（其表现为JS App）或者是Mashup。

结合持续集成，自动构建工具，就可以创造一个随需应变的面向服务的框架了。

5.2     企业服务总线

受到计算机硬件的启示，企业服务总线由若干标准的接口（比如PCI，内存）和消息路由器组成。

5.3     服务组合

服务是可以组合起来形成更大的服务的。SCA标准支持SOAP Web Service，EJB的集成，我之前写了一篇论文Research on e-Commerce Application Architecture Based on the Integration of Workflow and Agile Service，介绍了RESTful Web Service和Workflow的结合，并且介绍了RESTful的服务组合。这类似于将SCA，BPEL的工作转移到REST上。

6       架构师团队

[一个小组]是一些拥有各种技术的人的集合，他们之间有共同需要完成的目标，并且之间相互负责任。

架构师团队的成员应该是类似于一个类继承体系，基类是对系统架构的共同的技能，能够为一个产品定义架构。然后每个子类代表一个或几个方面专长或对其负责的架构师。

在这个团队中，所有的成员一起为构建系统的架构做出决策，尤其是那些最重要的系统。而每个人会负责产品涉及的某一个领域，比如RIA，工作流，分布式，并发，远程访问等。

在系统设计方面，架构师主要负责针对领域问题设计出软件模型。因此需要对领域具有深刻的理解，同时精通于领域模型和软件结构的设计。

领域这个词的概念很宽广，可以指具体的业务领域，比如招聘，培训，财务，也可以指技术领域，比如缓存，分布式等。

本文提及的框架由架构师团队设计并完成核心模块，而具体服务由分管架构师负责。

另外为特定业务领域创建构建模式，并利用之前提到的以服务形式提供的工具集，由一个架构师总领整个设计并对业务总体建模（保持概念完整性），分管架构师解决对应技术领域问题。

7       结束语

本文立足于服务计算的历史和自己的相关经验，意在总结与拓展。

基于某个致力于统一服务计算的规范来实现系统集成，服务应用都是没有生命力的，即使SOAP Web Service这种基于HTTP协议（虽然可以用于FTP等协议，但是实际应用不多见）和XML的服务协议，依然在使用时让大家感觉很难受。因此才有了Big Web Service这样戏谑的名称。

写到最后感觉怎么跟学术论文是的。