DEV2DEV TECHDAYS SOA 体会二

rocket — Thu, 22 May 2008 14:52:00 GMT

面向服务的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层次结构图：

rocket 2008-05-22 22:52 发表评论

DEV2DEV TECHDAYS SOA 体会一

rocket — Wed, 14 May 2008 10:09:00 GMT

首先先说一些闲话：这次bea的dev2dev techDays依然是在讲现在bea公司的主攻领域soa，估计这也是oracle之所以收购bea的一个原因吧。
会议的地点依然是每次雷打不动的圣庭苑酒店，会议的主办方也组织的很好，为了能让参与者对bea的相关技术和产品感兴趣，bea也是准备了丰富的奖品，有笔，有T恤，还有5个workshop的licence，最引人注目就是最后抽奖的一个iphone，做为一个免费会议来说，这些东西却是很丰富了，但是要是考虑到bea主要是为了推它的SOA产品Workshop 10.2这个售价高达1000多美元的怪物来说，也就不觉得贵了：）。
1、SOA起源
这些年为了提高办公效率，企业和政府都在努力追求着一个看似很甜的棒棒糖：信息化。但是由于信息化的方式多种多样，这样就造成了在一个企业内部有多套信息化的系统。财务是买来的财务软件，行政使用免费的行政软件，销售是请人来研发的销售系统。然后各个部门发现，原来自己虽然信息化了，但是实际上只是一个信息孤井，自己的信息系统没有办法接受别的部门的信息，而自己的信息也没有办法传递到其他部门去。这样公司的领导就不高兴了，你们都要信息化，无纸办公，结果现在信息化的比优质办公还麻烦，都给我统统统一起来。开始的时候有人想到重做一套整体的信息系统，把所有部门都包含进去不就可以了，但是这方案代价太高了。于是呢就有人提出了这样的想法，其实每个系统都是为每个部门或者其他部门提供服务的，那么我们就把这些服务给抽象出来进行统一管理吧，然后让所有的部门都只面对这些抽取的服务，而不是单一的系统，这样soa的概念就渐渐浮出水面了。
2、服务的概念，以及SOA基本架构
SOA中最核心的就是服务了，所以我们首先应该明确一下服务这个概念。用毛主席最经典的一句话：为人民服务。这里我们可以看出，抽象的服务概念有两个基本的要素：1是服务对象，2是可以提供什么。超市收银员的服务对象是顾客，可以提供的是算钱收钱；公安局的服务对象是市民，可以提供的是解决你解决不了的难题。；你的心脏的服务对象是血液，可以提供的是给血液加养分；等等。所以来说任何一个对象都是一个服务提供者（当然任何一个对象也将是一个服务接受者，对于服务接受这里不再详细讨论）。
根据一个信息系统本身固有的几个层次为了让各个层次的职责更加清晰，而且也是为了在调用服务的时候更加统一SOA的一个基本架构是这样的：
      原有系统架构                                      SOA系统架构
企业原有业务系统的存储层   --〉    [把这层封装成SOA的连通服务层]

企业原有业务系统的业务层   --〉    [把这层封装成SOA的业务流程服务层]

企业原有业务系统的应用层 --〉 [根据上层抽象出来的统一服务进行调用并在各种应用前台]

然后专门隔离出来一个服务中介层，也就是一条服务总线来把所有的服务进行统一管理

rocket 2008-05-14 18:09 发表评论

BlogJava-rocket-随笔分类-构架设计

DEV2DEV TECHDAYS SOA 体会二

DEV2DEV TECHDAYS SOA 体会一