随笔-55  评论-208  文章-0  trackbacks-0

面向服务的8个原则
服务可复用 不管是否存在即时复用的机会,服务被设计为支持潜在可复用。
服务共享一个正式契约 为了与服务交互,只需要共享描述每个服务信息交换术语定义的正式契约。
服务是松散耦合的 服务被设计为无需紧密的、跨服务的依赖而交互。
服务是底层逻辑的抽象 只有经由服务契约所暴露的部分服务对于外部世界是可见的。契约之外所表达的底层逻辑是不可见的,且与服务请求者无关。
服务是可组合的 服务可能组合其他服务。这允许表示不同粒度的逻辑,并促进复用及抽象层的创建。
服务是自治的 逻辑由服务所控制,并位于一个清晰的边界内。服务已经在这个边界内被控制,并且不依赖于执行其控制的其他服务。
服务是无状态的 服务应当不需要管理状态信息,因此能够其维持松耦合性。服务应当尽可能设计成无状态的,即便这意味着要将状态管理移至别处。
服务是可发现的 服务应当允许其描述被发现,并被人工和可能会利用其逻辑的服务请求者所理解。
这个8个面向服务的原则乍看很像我们熟悉的OOP啊,不过如果你把一个服务抽象成一个对象来看的话也就不难理解了。
下面介绍一下依据这8个原则构建的SOA的各个服务层:
1、连通性服务层
所谓的连通性是指对于原有系统的数据连通,由于原有系统不能提供一个具有通用性的数据服务,所以在连通性服务层的主要任务就是负责把原来已有的JDBC的,EJB的,webService的各种数据服务,封装成具有统一标准的java pojo控件,然后其它的就可以方便,简单的实现对数据服务的调用。
连通性服务层:
服务对象:需要获得数据的对象         如业务层、表示层等
提供服务:可以操作原有系统的数据层   如对一个sap服务器进行操作、对一个DB服务器进行操作邓
调用资源:原有系统的数据服务接口     如EJB、Hibernate,JDBC等
图1:
在这里值得一提的是bea在使用workshop对于连通性服务层创建,非常简单,完全图形化的方式,只需简单的鼠标拖曳,就可以实现服务控件的建立。
2、业务流程服务层
我们知道一般的业务系统都会有一些自由的业务流程的,那么如何让这些原有的业务流程来提供给SOA系统使用呢?
在bea专家给我们演示的demo中,我看到bea的做法是把每一个流程节点封装成了服务,这样,这些流程节点每个都可以成为一个向外提供服务的服务者了。
业务流程服务层:
服务对象:需要流程控制的对象         如其他业务层,表示层等
提供服务:业务流程控制               如从a入口进入后是应该去b节点还是应该去c节点
调用资源:通常是连通性服务层的服务  
图2:
在bea演示的时候对于业务流程服务层的构建依然采用的是图形化的方式,这里值得称道的是在使用图形化的过程中,bea的工具还可以支持对于服务的格式转换
3、服务中介层  
上面已经介绍了两种服务层了,在soa中这两层的调用不是简单的上下层关系。在实际项目中,也许有的需求是需要流程控制的,但是也许有些需求是直接要求展示数据的,那么如何处理这两种的需求呢。这里就是在soa中最重要的一个层了,服务中介层。很多人应该听过soa中service bus这个概念。我之前一直理解为服务总线仅仅是为客户端提供服务的,其实是不对的,实际上服务总线是一个用了穿起来各个服务层的,就好比是一个糖葫芦,服务中介层就是中间的那根棍子。
图3:
做为服务中介层来说,主要有两种服务,一种是应用服务;另外一个是代理服务,用来对应用服务进行代理封装的,是服务总线中向外暴露的服务。
4、表示层服务层
表示层服务主要和不同的客户端有关,bea在这里的讲述中由于时间紧张所以比较简单。重点还是在演示他们可视化得页面编辑。但是这里有点给我洗脑得就是,对于不同的客户端所提供的服务是直接可以使用的,比如判断一个用户名是否合法,表示层服务不是返回的true,false,而是直接返回,“该用户名可用”,“该用户名已被占用”这样的字符串。
关于表示层我就不再画图了,最后是一个整体的soa层次结构图:


 

posted on 2008-05-22 22:52 rocket 阅读(1565) 评论(0)  编辑  收藏 所属分类: 构架设计

只有注册用户登录后才能发表评论。


网站导航: