星期四, 06月 12th, 2008
ESB产品升级准备：SOA、ESB、JBI、SCA、OSGI概念再学习、再理解
这几日看了许多SOA，ESB，JBI，SCA，OSGI相关的书籍、BLOG、文章、JavaOne上的一些资料，希望在ESB产品升级之前，能对这些概念再次进行学习、理解。明确术语，确定关系。
SOA
SOA是一种业务建模思想，是一种架构风格；它以服务为核心，构建系统；通过进化控制节奏;【摘录】支持对业务进行整合，使其成为一种能够相互联系、可重用的业务任务或者服务。
【注：此处的架构仅指技术相关的架构。】
- 一种业务建模思想
SOA是一种业务建模思想，而不是一种技术体系。它来自业务敏捷的需求，植根于业务，致力于提升业务的敏捷性。
最低层面：使用SOA的思想分析、重构业务，用服务的概念定义业务单元。实现层甚至使用现有技术体系，选择几种结构型模式：Façade模式，Proxy模式，Composite模式配合，从而达到原始的SOA层面。SOA并不强制我们必须分布，必须采用一些支持SOA的技术或产品，只要业务敏捷了，且当前技术架构也能够满足生产发展的需要，就是合适的。
- 一种架构风格
SOA也是一种架构模式，特别是一种分布式架构模式。
实践观点：第二个层面以第一个层面为基础，没有第二个层面，只有第一个层面，我们还可以说这个系统是SOA化的；没有第一个层面，只有第二个层面，这个系统是否SOA化，值得商议。(IBM提出的SOA切入点中，包含有以技术为中心的切入点【连通性】，从我们实践、公开案例的实践、专家有关SOA实践的书籍来看，以业务为切入点是最合适的，也是最容易成功的，获得组织支持的概率也大；单一的基于技术切入SOA架构，案例较少)
它的一些特征：
以服务为基本单元，可以把服务视为构件。
服务质量可度量，且可以提升。
基于开放标准。
该架构同时是一种分层架构。
具有分布的能力。
与技术无关性。
鼓励扩展。
支撑业务敏捷的要求。
架构层面主张组合。
- 服务设计的原则
松散耦合
服务契约
自治
抽象
复用性
组合性
无状态性
可发现性
互操作性
IBM的SOA架构框架：
该图从技术层面描绘了SOA的架构模型，以及OA技术架构所包含的主要概念。
ESB
ESB是一类中间件产品的通称；是一种分布式的技术架构，以中介为核心概念；是一种支持SOA实施的技术选择；来源于集成的需要，实现服务、系统之间的互联、整合；ESB产品通常提供一种容器，方便插入各类通用服务（编排服务、消息服务等）、提供服务虚拟化的能力（协议和模式、接口、身份等）、提供面向方向的连接（安全性、管理、日志记录和审核等）；支持业务逻辑和实现的技术逻辑的分离。
最常用到的特性:
-
它使用XML（可扩展标识语言）作为标准通信语言。
它支持Web服务标准。
它支持消息传递（同步、异步、点对点、发布-订阅）
它包含对服务编制（orchestration）和编排（choreography）的支持。
它包含智能、基于内容的路由服务（itenerary路由）。
它包含转换服务（通常是使用XSLT），在发送应用和接收应用之间转换格式，简化数据格式和值的转换。
它可以条件路由，或基于非集中策略的消息转换，即不需要集中规则引擎。
它提供对服务监控、治理相关的内容。
-
参考资料：
http://www.ibm.com/developerworks/cn/architecture/ar-esbpat2/index.html
http://www.ibm.com/developerworks/cn/architecture/ar-esbpat1/index.html
http://www-128.ibm.com/developerworks/cn/webservices/ws-esbscen/index.html
http://www.infoq.com/cn/articles/ESB-Roundup-Part1-Defining-ESB
http://www.ddj.com/java/201200303;jsessionid=DP5D5J5VEP4XKQSNDLPSKHSCJUNN2JVN?_requestid=459785
JBI
【摘录】是基于面向服务体系提倡的方法和原则，为了解决 EAI 和 B2B 若干问题的 Java 标准。JBI 定义了基于插件方式的架构，以便服务能融入“ JBI 运行时”环境。 JBI 提供了详细的接口，使服务能与“ JBI 运行时”环境交互。
- 资料：
http://soaneu.blog.com.cn/index.shtml
http://www.jcp.org/en/jsr/detail?id=208
http://www.infoq.com/jbi
服务引擎、组件绑定图：
本图强调了服务引擎，组件的绑定方式，更倾向与产品的扩展。对业务级别的服务模型支撑比较弱，业务通过API来实现与JBI产品的交互。
SCA
服务组件体系结构 (SCA) 是一个规范；是一种架构模式；是一种通用的面向业务服务的组件模型；定义了部署模型；提供了实现提供服务和使用其他服务的组件、组装组件，以通过服务引用其他服务的方式来构建业务应用程序–与SOA组合的原则一致；SCA是平台无关的；SCA是一种编程模型；支持业务逻辑和实现的技术逻辑的分离；是一种支持SOA实施的技术选择；SCA支持组件的分布。
【摘录】is a set of specifications which describe a model for building applications and systems using a Service Oriented Architecture. SCA models solutions as sets of service components offering services and making references to services supplied by others, which are combined together by composites which wire references to services and which declaratively apply bindings for communication methods and also apply policies for aspects such as security and transactions. SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.
- 资料：
http://dev.yesky.com/topic/308/7667308.shtml
http://www-128.ibm.com/developerworks/cn/webservices/ws-theme/ws-soa.html#sca
http://www.davidchappell.com/articles/Introducing_SCA.pdf
http://www.osoa.org/display/Main/Service+Component+Architecture+Home
http://www.infoq.com/sca
http://www.infoq.com/articles/setting-out-for-sca
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-41500&yr=2007&track=3
核心概念图：
本图强调了组件模型，服务组件之间的组合模式，把业务级别和系统级别的组件，同等对待。提供了业务组件接入容器的方式。完全符合SOA的概念。
OSGI
【摘录】一个开放并且提供统一接口标准的体系框架，基于这个体系框架，服务提供商，程序开发人员，软件提供商，服务网管运营商，设备提供商能够协调地联合起来开发，部署以及管理向用户提供的各种服务。
【摘录】provides a service-oriented, component-based environment for developers, primarily on the
Java platform. It provides a dependency resolution mechanism, with version support and also offers standardized ways to manage the software lifecycle. OSGi is a particular boon when using different components that use different versions of some shared package. These capabilities greatly increase the value of a wide range of computers and devices that use the Java™ platform.
- 资料：
http://www.riawork.org/
http://www.infoq.com/osgi
http://www.osoa.org/download/attachments/250/Power_Combination_SCA_Spring_OSGi.pdf?version=3
http://xml.coverpages.org/OSGi-ServicePlatformOverview2004.pdf
http://www.blogjava.net/BlueDavy/archive/2007/10/14/152820.html
http://www.blogjava.net/hx9111/archive/2006/11/10/OSGi-SCA.html
http://www.blogjava.net/zhaobin/archive/2007/11/06/158485.html
相互之间的关系
- SOA – ESB
ESB是一种支持SOA实施的技术选择。
- SOA – JBI
JBI是Java领域一种支持SOA实施的技术选择。
- SOA – SCA
SCA是一种支持SOA实施的技术选择。
- SOA – OSGI
没有直接关系,目的不一致。
- ESB—JBI
JBI和ESB是互补的。JBI提供一个模型和将集成组件作为服务的标准接口。JBI可以宿主在一个应用程序服务器环境或者在一个ESB容器中。ESB提供了一套基础架构包括了事件驱动的SOA，高度分布的路由目的地命名，企业消息能力和分布管理能力。
- JBI – SCA
【摘录】SCA has a strong model for defining composite applications、Services can be implemented in multiple languages、Can bind interfaces and references to different technologies。
JBI:Defines a standard, loosely coupled, ESB architecture、SE / BC are exchangeable between JBI implementations、Provides standard abstraction for all JBI components。
融合性：When combining JBI and SCA, all JBI service engines can be used in SCA components, SCA components can be called from JBI, SCA applications can be deployed as service units in a JBI container.
- SCA-OSGI
相同点：都是一种规范；都是一种架构；一种编程模式；都定义了模块，服务概念。
不同点：OSGI强调模块的动态性；SCA强调服务的分布性；OSGI来源与单个JVM产品架构的需求；SCA来业务SOA化的技术需求；OSGI更适合产品架构；SCA更适合业务系统架构。
融合性：SCA可以作为Bundle部署到OSGI环境，以增强OSGI环境的业务架构解决能力；OSGI可以作为一个模块部署到SCA环境中，从而利用OSGI环境下的基础通用服务。
- SCA-ESB
相同点：都是SOA的一个可选的技术方案；都基于服务的概念；都是可分布的；都提供插件特性等。
不同点：SCA是一个标准，ESB是一个概念；SCA有模块的概念，ESB没有这个概念；SCA是一个组装车间，ESB是一个中介机构；SCA简单而清晰，ESB复杂而模糊，不同产品特性千差万别。
星期三, 06月 11th, 2008
ESB分布式的基础–传输层、远程通讯
ESB作为SOA的基础产品，它的第一个目标就是服务的分布化。提到服务分布，那么必然会想到传输、远程通讯、TCP/IP、SOAP等等概念。
不久前看到朋友的一篇文章Java远程通讯可选技术及原理, 读完之后，感觉有些概念定义的还不是很清楚。再者最近又准备升级ESB产品，因此就一些想法写出来，和朋友们交流。
归类正名
古人有黑马和白马的逻辑辩论，其目的就是正名。只有把概念定义清楚了，外延画定了，我们在讨论问题的时候，才能避免大象和犀牛一起比较的情况。下面我就平时遇到的一些东西进行简单了归类和定义。
- 四层协议：网络通讯的一种模型。参考TCP/IP协议分析-协议分层一文。
- 传输协议：四层模型中的第三层–传输层，主要指TCP、UDP。
- 应用协议：四层模型中的第四层–应用层，基于TCP/UDP，面向应用开发的高层协议。例如：HTTP、FTP等。
- ESB的传输层：它是一个逻辑概念，相对于ESB体系结构来说，解决服务（或系统）交互的一层。可以直接利用第四层协议，例如：SMTP协议，FTP协议等；或者基于第三层、第四层协议定制的解决服务交互的协议，把一个系统的数据+指令传输到另一个系统（可以获取回执，也可以不获取回执），例如：SOAP+HTTP协议，RMI协议，Hessian协议，REST（HTTP + XML方式）的协议，XML+JMS协议；甚至与传输无关的一些交互方式，例如：File协议，内存协议等。
- 通讯框架：基于TCP、UDP等开发的面向应用协议的框架。这类框架往往为使用者提供了一套通讯解决方案，允许使用者，定制需要的业务协议。例如：MINA，Netty2 ，Cindy，Grizzly等。其它可参考：Java开源 网络服务器端组件一文。
- POJO服务框架：这类框架提供了一种通用调用模式，简化POJO类的服务化问题，它们也提供了很强的扩展机制，允许使用通讯框架、ESB传输层来进行扩展。例如：Spring Remote，JBoss Remote，EJB等。
四层协议的共性
通过分析，可以看到四层协议具有如下特点：
- 每一层的职责清晰，专著于本层的关键问题。例如：网络层，它处理路由选择等分组在网络中的活动，而不会关心：与传输媒介的物理接口细节等。
- 上层协议利用下层协议来处理更低级的数据传输问题。
- 都有连接相关的定义。
- 都有数据打包的定义。
- 都有marshallers/unmarshallers 上层数据的定义。
- 都提供了上层如何使用的方案，发送方，接收方（提供方）。
由此扩展到应用协议，我们会发现它们要解决的根本问题也都包含这几个方面。因此：通讯层的模式是相对稳定的。
ESB分布式层、JMS、POJO服务框架等分布式产品的一些共性
- 明确定义服务标示的概念。例如：ESB产品Mule对服务的定义：vm://hello.service,xfire:http://localhost:8888/hello.service。JBOSS Remote中服务的定义：rmi://localhost:8797/hello.service。
- 插件化的传输协议。例如：JBOSS Remote提供了，Socket ，RMI，HTTP等。
- 插件化的数据编码和解码。该层与传输相关，而与应用无关。例如：Http协议，有文本型编码，Multipart编码。
- 插件化的序列化解决体系，例如：Java对象可以用Hessian方式序列化，可以用XML方式序列化，可以用SOAP方式序列化，可以用Java二进制方式序列化，以Jason方式序列化，甚至自定义的方式序列化。这一层通常解决高级应用层的数据（可能包括指令）的序列化方案。
- 有选择的提供数据压缩，数据加密，数据签名等常用方案。
- 为POJO层（或者定义为：业务层）提供同步、异步等多种业务交互模式。
- 错误处理机制。
- 提供专有API，或者与IOC容器、EJB容器整合的解决方案。
- 服务定位机制，寻址机制。
ESB分布式层的一种选型
在我们的ESB产品中，分布式层解决了如下问题：
- 包含了“ESB分布式层、JMS、POJO服务框架等分布式产品的一些共性“一节中描述的特性。
- 一个服务，通过一个端口支持多种协议。例如：通过5200端口，我们提供Hessian协议，WS协议，REST协议，HTTP+XML业务协议的方式。而且可以依据需要进一步定制。
- 传输质量的解决，例如：数据重发，超时。
- 批量传输数据。
- 长连接提升性能。
- 软负载。
- 大数据传输。
- 可靠传输。
- 流量监控。
- 在通讯框架上，我们选择了MINA。原因：A：文档齐全 B：扩展性好 C：协议层定制方便 D：基于事件模型 E：有HTTP的扩展（AsyncWeb） F：稳定性也不错 H：公司内已经有使用先例 G：Apache在不断升级
【说明：】群集，远程类装载（JINI特性），服务器组等一些高级特性，由于在我们的SOA化过程中，并没有业务上的需求，因此没有考虑这方面的内容。此外，我们发现，可以通过其它一些简单的技术（软件 + 硬件 + 发布 + OSGI等）来简单获得这些复杂技术提供的基本特性，以满足我们业务的需求。
对于开发一款通用ESB产品和符合自己企业需要的ESB产品，其出发点是不同的，由此在分布式特性的选择上也必然不会相同，每种产品的特性选择，只要满足了自己的目标和需求即可。不过，有些共性的特性点，无论如何也跑不了的（当然，可以简化方案，例如传输层，可以只有RMI，或者JMS）。
ESB产品升级准备：SOA、ESB、JBI、SCA、OSGI概念再学习、再理解
这几日看了许多SOA，ESB，JBI，SCA，OSGI相关的书籍、BLOG、文章、JavaOne上的一些资料，希望在ESB产品升级之前，能对这些概念再次进行学习、理解。明确术语，确定关系。
SOA
-
SOA是一种业务建模思想，是一种架构风格；它以服务为核心，构建系统；通过进化控制节奏;【摘录】支持对业务进行整合，使其成为一种能够相互联系、可重用的业务任务或者服务。
- 一种业务建模思想
SOA是一种业务建模思想，而不是一种技术体系。它来自业务敏捷的需求，植根于业务，致力于提升业务的敏捷性。
最低层面：使用SOA的思想分析、重构业务，用服务的概念定义业务单元。实现层甚至使用现有技术体系，选择几种结构型模式：Façade模式，Proxy模式，Composite模式配合，从而达到原始的SOA层面。SOA并不强制我们必须分布，必须采用一些支持SOA的技术或产品，只要业务敏捷了，且当前技术架构也能够满足生产发展的需要，就是合适的。 - 一种架构风格
SOA也是一种架构模式，特别是一种分布式架构模式。
实践观点：第二个层面以第一个层面为基础，没有第二个层面，只有第一个层面，我们还可以说这个系统是SOA化的；没有第一个层面，只有第二个层面，这个系统是否SOA化，值得商议。(IBM提出的SOA切入点中，包含有以技术为中心的切入点【连通性】，从我们实践、公开案例的实践、专家有关SOA实践的书籍来看，以业务为切入点是最合适的，也是最容易成功的，获得组织支持的概率也大；单一的基于技术切入SOA架构，案例较少)
它的一些特征：
以服务为基本单元，可以把服务视为构件。
服务质量可度量，且可以提升。
基于开放标准。
该架构同时是一种分层架构。
具有分布的能力。
与技术无关性。
鼓励扩展。
支撑业务敏捷的要求。
架构层面主张组合。 - 服务设计的原则
松散耦合
服务契约
自治
抽象
复用性
组合性
无状态性
可发现性
互操作性
【注：此处的架构仅指技术相关的架构。】
IBM的SOA架构框架：
该图从技术层面描绘了SOA的架构模型，以及OA技术架构所包含的主要概念。
ESB
-
ESB是一类中间件产品的通称；是一种分布式的技术架构，以中介为核心概念；是一种支持SOA实施的技术选择；来源于集成的需要，实现服务、系统之间的互联、整合；ESB产品通常提供一种容器，方便插入各类通用服务（编排服务、消息服务等）、提供服务虚拟化的能力（协议和模式、接口、身份等）、提供面向方向的连接（安全性、管理、日志记录和审核等）；支持业务逻辑和实现的技术逻辑的分离。
-
它使用XML（可扩展标识语言）作为标准通信语言。
它支持Web服务标准。
它支持消息传递（同步、异步、点对点、发布-订阅）
它包含对服务编制（orchestration）和编排（choreography）的支持。
它包含智能、基于内容的路由服务（itenerary路由）。
它包含转换服务（通常是使用XSLT），在发送应用和接收应用之间转换格式，简化数据格式和值的转换。
它可以条件路由，或基于非集中策略的消息转换，即不需要集中规则引擎。
它提供对服务监控、治理相关的内容。 -
参考资料：
http://www.ibm.com/developerworks/cn/architecture/ar-esbpat2/index.html
http://www.ibm.com/developerworks/cn/architecture/ar-esbpat1/index.html
http://www-128.ibm.com/developerworks/cn/webservices/ws-esbscen/index.html
http://www.infoq.com/cn/articles/ESB-Roundup-Part1-Defining-ESB
http://www.ddj.com/java/201200303;jsessionid=DP5D5J5VEP4XKQSNDLPSKHSCJUNN2JVN?_requestid=459785
最常用到的特性:
JBI
-
【摘录】是基于面向服务体系提倡的方法和原则，为了解决 EAI 和 B2B 若干问题的 Java 标准。JBI 定义了基于插件方式的架构，以便服务能融入“ JBI 运行时”环境。 JBI 提供了详细的接口，使服务能与“ JBI 运行时”环境交互。
- 资料：
http://soaneu.blog.com.cn/index.shtml
http://www.jcp.org/en/jsr/detail?id=208
http://www.infoq.com/jbi
服务引擎、组件绑定图：
本图强调了服务引擎，组件的绑定方式，更倾向与产品的扩展。对业务级别的服务模型支撑比较弱，业务通过API来实现与JBI产品的交互。
SCA
-
服务组件体系结构 (SCA) 是一个规范；是一种架构模式；是一种通用的面向业务服务的组件模型；定义了部署模型；提供了实现提供服务和使用其他服务的组件、组装组件，以通过服务引用其他服务的方式来构建业务应用程序–与SOA组合的原则一致；SCA是平台无关的；SCA是一种编程模型；支持业务逻辑和实现的技术逻辑的分离；是一种支持SOA实施的技术选择；SCA支持组件的分布。
- 资料：
http://dev.yesky.com/topic/308/7667308.shtml
http://www-128.ibm.com/developerworks/cn/webservices/ws-theme/ws-soa.html#sca
http://www.davidchappell.com/articles/Introducing_SCA.pdf
http://www.osoa.org/display/Main/Service+Component+Architecture+Home
http://www.infoq.com/sca
http://www.infoq.com/articles/setting-out-for-sca
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-41500&yr=2007&track=3
【摘录】is a set of specifications which describe a model for building applications and systems using a Service Oriented Architecture. SCA models solutions as sets of service components offering services and making references to services supplied by others, which are combined together by composites which wire references to services and which declaratively apply bindings for communication methods and also apply policies for aspects such as security and transactions. SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.
核心概念图：
本图强调了组件模型，服务组件之间的组合模式，把业务级别和系统级别的组件，同等对待。提供了业务组件接入容器的方式。完全符合SOA的概念。
OSGI
-
【摘录】一个开放并且提供统一接口标准的体系框架，基于这个体系框架，服务提供商，程序开发人员，软件提供商，服务网管运营商，设备提供商能够协调地联合起来开发，部署以及管理向用户提供的各种服务。
- 资料：
http://www.riawork.org/
http://www.infoq.com/osgi
http://www.osoa.org/download/attachments/250/Power_Combination_SCA_Spring_OSGi.pdf?version=3
http://xml.coverpages.org/OSGi-ServicePlatformOverview2004.pdf
http://www.blogjava.net/BlueDavy/archive/2007/10/14/152820.html
http://www.blogjava.net/hx9111/archive/2006/11/10/OSGi-SCA.html
http://www.blogjava.net/zhaobin/archive/2007/11/06/158485.html
【摘录】provides a service-oriented, component-based environment for developers, primarily on the
Java platform. It provides a dependency resolution mechanism, with version support and also offers standardized ways to manage the software lifecycle. OSGi is a particular boon when using different components that use different versions of some shared package. These capabilities greatly increase the value of a wide range of computers and devices that use the Java™ platform.
相互之间的关系
- SOA – ESB
ESB是一种支持SOA实施的技术选择。 - SOA – JBI
JBI是Java领域一种支持SOA实施的技术选择。 - SOA – SCA
SCA是一种支持SOA实施的技术选择。 - SOA – OSGI
没有直接关系,目的不一致。 - ESB—JBI
JBI和ESB是互补的。JBI提供一个模型和将集成组件作为服务的标准接口。JBI可以宿主在一个应用程序服务器环境或者在一个ESB容器中。ESB提供了一套基础架构包括了事件驱动的SOA，高度分布的路由目的地命名，企业消息能力和分布管理能力。 - JBI – SCA
【摘录】SCA has a strong model for defining composite applications、Services can be implemented in multiple languages、Can bind interfaces and references to different technologies。
JBI:Defines a standard, loosely coupled, ESB architecture、SE / BC are exchangeable between JBI implementations、Provides standard abstraction for all JBI components。
融合性：When combining JBI and SCA, all JBI service engines can be used in SCA components, SCA components can be called from JBI, SCA applications can be deployed as service units in a JBI container. - SCA-OSGI
相同点：都是一种规范；都是一种架构；一种编程模式；都定义了模块，服务概念。
不同点：OSGI强调模块的动态性；SCA强调服务的分布性；OSGI来源与单个JVM产品架构的需求；SCA来业务SOA化的技术需求；OSGI更适合产品架构；SCA更适合业务系统架构。
融合性：SCA可以作为Bundle部署到OSGI环境，以增强OSGI环境的业务架构解决能力；OSGI可以作为一个模块部署到SCA环境中，从而利用OSGI环境下的基础通用服务。 - SCA-ESB
相同点：都是SOA的一个可选的技术方案；都基于服务的概念；都是可分布的；都提供插件特性等。
不同点：SCA是一个标准，ESB是一个概念；SCA有模块的概念，ESB没有这个概念；SCA是一个组装车间，ESB是一个中介机构；SCA简单而清晰，ESB复杂而模糊，不同产品特性千差万别。
ESB分布式的基础–传输层、远程通讯
ESB作为SOA的基础产品，它的第一个目标就是服务的分布化。提到服务分布，那么必然会想到传输、远程通讯、TCP/IP、SOAP等等概念。
不久前看到朋友的一篇文章Java远程通讯可选技术及原理, 读完之后，感觉有些概念定义的还不是很清楚。再者最近又准备升级ESB产品，因此就一些想法写出来，和朋友们交流。
归类正名
古人有黑马和白马的逻辑辩论，其目的就是正名。只有把概念定义清楚了，外延画定了，我们在讨论问题的时候，才能避免大象和犀牛一起比较的情况。下面我就平时遇到的一些东西进行简单了归类和定义。
- 四层协议：网络通讯的一种模型。参考TCP/IP协议分析-协议分层一文。
- 传输协议：四层模型中的第三层–传输层，主要指TCP、UDP。
- 应用协议：四层模型中的第四层–应用层，基于TCP/UDP，面向应用开发的高层协议。例如：HTTP、FTP等。
- ESB的传输层：它是一个逻辑概念，相对于ESB体系结构来说，解决服务（或系统）交互的一层。可以直接利用第四层协议，例如：SMTP协议，FTP协议等；或者基于第三层、第四层协议定制的解决服务交互的协议，把一个系统的数据+指令传输到另一个系统（可以获取回执，也可以不获取回执），例如：SOAP+HTTP协议，RMI协议，Hessian协议，REST（HTTP + XML方式）的协议，XML+JMS协议；甚至与传输无关的一些交互方式，例如：File协议，内存协议等。
- 通讯框架：基于TCP、UDP等开发的面向应用协议的框架。这类框架往往为使用者提供了一套通讯解决方案，允许使用者，定制需要的业务协议。例如：MINA，Netty2 ，Cindy，Grizzly等。其它可参考：Java开源 网络服务器端组件一文。
- POJO服务框架：这类框架提供了一种通用调用模式，简化POJO类的服务化问题，它们也提供了很强的扩展机制，允许使用通讯框架、ESB传输层来进行扩展。例如：Spring Remote，JBoss Remote，EJB等。
四层协议的共性
通过分析，可以看到四层协议具有如下特点：
- 每一层的职责清晰，专著于本层的关键问题。例如：网络层，它处理路由选择等分组在网络中的活动，而不会关心：与传输媒介的物理接口细节等。
- 上层协议利用下层协议来处理更低级的数据传输问题。
- 都有连接相关的定义。
- 都有数据打包的定义。
- 都有marshallers/unmarshallers 上层数据的定义。
- 都提供了上层如何使用的方案，发送方，接收方（提供方）。
由此扩展到应用协议，我们会发现它们要解决的根本问题也都包含这几个方面。因此：通讯层的模式是相对稳定的。
ESB分布式层、JMS、POJO服务框架等分布式产品的一些共性
- 明确定义服务标示的概念。例如：ESB产品Mule对服务的定义：vm://hello.service,xfire:http://localhost:8888/hello.service。JBOSS Remote中服务的定义：rmi://localhost:8797/hello.service。
- 插件化的传输协议。例如：JBOSS Remote提供了，Socket ，RMI，HTTP等。
- 插件化的数据编码和解码。该层与传输相关，而与应用无关。例如：Http协议，有文本型编码，Multipart编码。
- 插件化的序列化解决体系，例如：Java对象可以用Hessian方式序列化，可以用XML方式序列化，可以用SOAP方式序列化，可以用Java二进制方式序列化，以Jason方式序列化，甚至自定义的方式序列化。这一层通常解决高级应用层的数据（可能包括指令）的序列化方案。
- 有选择的提供数据压缩，数据加密，数据签名等常用方案。
- 为POJO层（或者定义为：业务层）提供同步、异步等多种业务交互模式。
- 错误处理机制。
- 提供专有API，或者与IOC容器、EJB容器整合的解决方案。
- 服务定位机制，寻址机制。
ESB分布式层的一种选型
在我们的ESB产品中，分布式层解决了如下问题：
- 包含了“ESB分布式层、JMS、POJO服务框架等分布式产品的一些共性“一节中描述的特性。
- 一个服务，通过一个端口支持多种协议。例如：通过5200端口，我们提供Hessian协议，WS协议，REST协议，HTTP+XML业务协议的方式。而且可以依据需要进一步定制。
- 传输质量的解决，例如：数据重发，超时。
- 批量传输数据。
- 长连接提升性能。
- 软负载。
- 大数据传输。
- 可靠传输。
- 流量监控。
- 在通讯框架上，我们选择了MINA。原因：A：文档齐全 B：扩展性好 C：协议层定制方便 D：基于事件模型 E：有HTTP的扩展（AsyncWeb） F：稳定性也不错 H：公司内已经有使用先例 G：Apache在不断升级
【说明：】群集，远程类装载（JINI特性），服务器组等一些高级特性，由于在我们的SOA化过程中，并没有业务上的需求，因此没有考虑这方面的内容。此外，我们发现，可以通过其它一些简单的技术（软件 + 硬件 + 发布 + OSGI等）来简单获得这些复杂技术提供的基本特性，以满足我们业务的需求。
对于开发一款通用ESB产品和符合自己企业需要的ESB产品，其出发点是不同的，由此在分布式特性的选择上也必然不会相同，每种产品的特性选择，只要满足了自己的目标和需求即可。不过，有些共性的特性点，无论如何也跑不了的（当然，可以简化方案，例如传输层，可以只有RMI，或者JMS）。
