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