星期五, 03月 6th, 2009
Mule技术架构（摘译）
更多明细，请阅读原文 《 Mule 1.x Architecture Guide 》，2.0版本缺少相应的文章，但技术架构没有发生更本的变化。
一.需求
- 简化不同数据源之间的数据交互
- 简化不同应用之间的服务交互
- 可扩展、轻量级、可嵌入、可定制、简单易用
二.架构风格选择
Mule使用的是基于消息的架构风格(如上图所示)，消息具有程序语言无关系、组件无关性、数据格式灵活性、消息无状态等特征，基于消息的服务也同样具有无状态的特征，此外，消息风格有非常成熟的应用模式，能够满足当前遇到的大部分数据应用需求以及SOA的需要。因而能够很好的满足需求中的前2个和第三个的可扩展、可定制的需求。
- Application：可以是程序段、外部系统。
- Channel：连接任何2个应用点（计算点），通过消息进行沟通，可参考《EIP - Message Channel (60)》
。
- Message Receiver：用来从应用节点中读取、写入消息。
- Inbound Router：进入计算组件（component）之前的控制和处理，例如：过滤、聚合、排序等。
- Connector：在Channel上建立链路层，Message Receiver绑定在connector上监听数据、派发数据。
- Transformers：转换消息格式。
- Endpoint：把channel抽象为服务的一种配置组件，这些被配置的元素有connector, endpoint URI, transformers, filters and transactional。
- Outbound Router：消息从计算组件（component）流出后的控制和处理，例如：过滤、Pub/Sub、拆分、路由等。
三. 技术框架和领域对象介绍
- The Model：提供框架的运行时环境，管理配置、组件实例，提供运行模式；用户甚至可以定制自己的运行模式（很强大）。Model模型包含如下内容 Descriptors、UMO components、 An endpoint resolver、A lifecycle-adapter factory、A component resolver、A pool factory、An exception strategy。
- Entry Point Resolver：与应用组件（POJO等）的交互。
- Lifecycle Adapter：将MULE实例的生命周期映射到应用组件，间接接管应用组件。
- Component Pool Factory：应用组件管理，提供pool能力。
- Transport Providers：使Mule组件发送和接收消息的部件。
- Connectors：对Connector的实现。
- Endpoints Address：资源标识的一种方法。例如，pop3://user:password@mail.mycompany.com ，file:///tmp/data/in，vm://MyUMO，axis:http://mycompany.com/mule/services/MyUMO等
- Endpoint Resolution：对附加在Endpoint的配置进行解析，例如，jms://topic:myTopic?durable=true。
- Message Receivers：消息接收者或监听者，不同类型的协议实现方式不同。例如TCP协议，只需要监听端口即可，File协议，需要定制一个线程去扫描文件系统，VM协议，可以不做任何事。
- Message Adapters：负责消息的转换。
- Transactions：提供事务支持。（没敢用，实际中，都是通过其它方式实现事务）
- Container Contexts：嵌入式的时候使用，能够把Mule容器和外部容器打通。与Spring整合的已经非常完美。
- UMO Components：mule的核心抽象之一，主要用来包装应用组件（POJO等）。
- Component Lifecycle：组件的生命周期。
- Events：Mule框架采用事件（SEDA,强烈推荐阅读Using SEDA to Ensure Service Availability ）架构来实现。
- Inbound Routers、Outbound Routers：对应于消息架构中的2个部件。
- Event Processing：Mule提供三种事件处理方式，（1）Asynchronously，（2）Synchronously ，（3）Request-Response相当于用异步实现的同步。 （具体使用模式，请参考原文）
- Interceptors：Mule框架提供拦截器模式，以方便用户扩展组件整体行为。
- Exception Management：提供异常管理的机制，默认的异常粗略很糟糕，最好自己定制。
- Agents：为运维人员提供的管理接口。
- Thread Pool：线程池管理，Mule的线程池和池策略需要仔细配置，否则很容易出现错误。Mule提供共用线程池和独立线程池模式，建议使用共用线程池模式。
星期五, 02月 27th, 2009
Mule是啥玩意
Mule基于Java平台，是一个轻量级的消息框架，可让您快速，轻松地连接您的应用程序（外部系统、内部组件、甚至一段脚本），使他们能够交换数据。
Mule的架构风格是 Enterprise Service Bus (ESB) 架构，它也属于ESB产品一组，就如下图所示，具有如下品质特征：
- 互联互通。
- 低的耦合性。
- 高扩展性。
- 高可重用性。
- 易维护性。
Mule框架的一些说明：
- Mule框架具有高可扩展性，用户可以自己定制连接器（说实在的，Mule提供的一些东西，只能算是参考品，例如TCP连接器质量一般，必须定制Mina、Grizzly等强壮点的通信框架，自己实现一个连接器；老的那个XFire连接器，也很不好用，换成Jetty也得Fix一些BUG。要不是看它的框架还算巧妙，早丢弃了），拦截器，转换器等连接组件，同时能够把自己业务领域的计算组件或领域组件部署在Mule容器中；
- Mule框架支持面向服务的架构（ SOA ），能够通过JMS ， Web服务，数据库， HTTP等等连接器，无缝地整合应用系统；
- Mule框架可以独立部署，也可以嵌入；
- Mule已经与Spring实现了无缝整合；
- Mule框架有企业版和社区版，社区版是免费的，BUG多一些；其中企业版需要付出点费用；
- Mule有一个很长的授权文件，可惜E文不是很好，没有完全看明白，倒是记得了一句：“The Original Code is MuleSource Mule The Initial Developer of the Original Code is MuleSource Inc. All portions of the code are Copyright (c) 2003-2007 MuleSource Inc. All Rights Reserved。”，所以上市公司，请再仔细读读该文件。
- Mule不是对JBI的实现，但提供了JBI扩展。Mule使用起来比JBI要简单，也不像JBI强制要求SOAP堆栈，协议比较灵活，在分布式计算领域，性能也还是可以接受的。
星期五, 02月 27th, 2009
ESB产品Mule+Spring实现最简领域驱动框架
更多内容在：
架构专栏
先发一个消息，开源ESB产品Mule又发布了新的LDAP组件，很是让人佩服，首先赞一个先。
架构风格的基本组成体：计算组件、连接组件、信息、数据、配置。下图中，又抽象了一个领域组件，这也是为了让这个风格表示法能够同样适用于业务层面。
MULE+Spring完全支撑上图所示的架构风格，我们可以很容易的用它们实现最简领域驱动框架，以支持领域驱动设计。MULE大量提供连接组件（通信，协调，仲裁等）和信息链路拦截机制（可使用格式转换，加密，压缩之类的），也提供一些通用的计算组件，但更多的通用计算组件还是依赖自己开发；Spring提供了配置能力，把组件之间的关系记录下来；唯独留下新引入的领域组件（领域组件的计算能力可以很容易通过连接组件实现与其它组件的交互），需要我们自己来开发。
在《领域驱动设计在SOA架构中的实践》一文中提到技术架构师解决如下问题：“解决缓存、事务管理（包括分布式事务）、分布式接口规范、通信机制、共性系统服务的注入和应用契约、领域驱动设计风格与编程模式的确定、测试方案的确定、工具的提供、搭建可运行的环境、跨环境（分布式环境）的服务依赖策略、模型转换策略和工具的提供、集成策略”。下面用Mule+Spring的组合来对应一下：
- 缓存：是一个计算组件，需要单独开发。
- 事务管理：是一个计算组件，利用Spring事务，分布式事务需要单独定制一个计算组件。
- 分布式接口规范：需要单独定义。
- 通信机制：MULE提供。
- 共性系统服务的注入和应用契约：Spring提供。
- 领域驱动设计风格与编程模式的确定：见实践一文。
- 测试方案的确定：Spring提供单元测试，Mule提供分布式测试，可以定制一些测试辅助组件，例如：数据生成组件，该组件配合MULE的定时组件，很容易实现简单的自动测试。
- 工具的提供：MULE，Spring都提供了工具，DAO生成组件依据存储框架的不同寻找合适的。
- 搭建可运行的环境：再搞一个JBOSS，整个环境OK。
- 跨环境（分布式环境）的服务依赖策略：见实践一文，Spring + Mule提供技术支持。
- 模型转换策略和工具的提供：用Dozer 解决Bean-Bean，JAXB解决Bean-XML，或者Hessian解决Bean-Hessian；开发这些计算工具，配置在Mule的链路中，即可使用。
- 集成策略：Mule提供了各种连接组件，轻易集成外部系统或服务。
- 额外的：Mule提供了分布式计算环境，可以作为SOA技术平台来使用。
- 额外的：Mule提供了服务模型，可以作为服务平台来用。
- 额外的：Mule提供了Galaxy，解决服务治理。
通过上面的匹配，就会发现，以MULE+Spring为基础，实现一个更强大的领域驱动框架将会非常容易。
星期四, 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）。
Mule技术架构（摘译）
更多明细，请阅读原文 《 Mule 1.x Architecture Guide 》，2.0版本缺少相应的文章，但技术架构没有发生更本的变化。
一.需求
- 简化不同数据源之间的数据交互
- 简化不同应用之间的服务交互
- 可扩展、轻量级、可嵌入、可定制、简单易用
二.架构风格选择
Mule使用的是基于消息的架构风格(如上图所示)，消息具有程序语言无关系、组件无关性、数据格式灵活性、消息无状态等特征，基于消息的服务也同样具有无状态的特征，此外，消息风格有非常成熟的应用模式，能够满足当前遇到的大部分数据应用需求以及SOA的需要。因而能够很好的满足需求中的前2个和第三个的可扩展、可定制的需求。
- Application：可以是程序段、外部系统。
- Channel：连接任何2个应用点（计算点），通过消息进行沟通，可参考《EIP - Message Channel (60)》
- Message Receiver：用来从应用节点中读取、写入消息。
- Inbound Router：进入计算组件（component）之前的控制和处理，例如：过滤、聚合、排序等。
- Connector：在Channel上建立链路层，Message Receiver绑定在connector上监听数据、派发数据。
- Transformers：转换消息格式。
- Endpoint：把channel抽象为服务的一种配置组件，这些被配置的元素有connector, endpoint URI, transformers, filters and transactional。
- Outbound Router：消息从计算组件（component）流出后的控制和处理，例如：过滤、Pub/Sub、拆分、路由等。
。
三. 技术框架和领域对象介绍
- The Model：提供框架的运行时环境，管理配置、组件实例，提供运行模式；用户甚至可以定制自己的运行模式（很强大）。Model模型包含如下内容 Descriptors、UMO components、 An endpoint resolver、A lifecycle-adapter factory、A component resolver、A pool factory、An exception strategy。
- Entry Point Resolver：与应用组件（POJO等）的交互。
- Lifecycle Adapter：将MULE实例的生命周期映射到应用组件，间接接管应用组件。
- Component Pool Factory：应用组件管理，提供pool能力。
- Transport Providers：使Mule组件发送和接收消息的部件。
- Connectors：对Connector的实现。
- Endpoints Address：资源标识的一种方法。例如，pop3://user:password@mail.mycompany.com ，file:///tmp/data/in，vm://MyUMO，axis:http://mycompany.com/mule/services/MyUMO等
- Endpoint Resolution：对附加在Endpoint的配置进行解析，例如，jms://topic:myTopic?durable=true。
- Message Receivers：消息接收者或监听者，不同类型的协议实现方式不同。例如TCP协议，只需要监听端口即可，File协议，需要定制一个线程去扫描文件系统，VM协议，可以不做任何事。
- Message Adapters：负责消息的转换。
- Transactions：提供事务支持。（没敢用，实际中，都是通过其它方式实现事务）
- Container Contexts：嵌入式的时候使用，能够把Mule容器和外部容器打通。与Spring整合的已经非常完美。
- UMO Components：mule的核心抽象之一，主要用来包装应用组件（POJO等）。
- Component Lifecycle：组件的生命周期。
- Events：Mule框架采用事件（SEDA,强烈推荐阅读Using SEDA to Ensure Service Availability ）架构来实现。
- Inbound Routers、Outbound Routers：对应于消息架构中的2个部件。
- Event Processing：Mule提供三种事件处理方式，（1）Asynchronously，（2）Synchronously ，（3）Request-Response相当于用异步实现的同步。 （具体使用模式，请参考原文）
- Interceptors：Mule框架提供拦截器模式，以方便用户扩展组件整体行为。
- Exception Management：提供异常管理的机制，默认的异常粗略很糟糕，最好自己定制。
- Agents：为运维人员提供的管理接口。
- Thread Pool：线程池管理，Mule的线程池和池策略需要仔细配置，否则很容易出现错误。Mule提供共用线程池和独立线程池模式，建议使用共用线程池模式。
Mule是啥玩意
Mule基于Java平台，是一个轻量级的消息框架，可让您快速，轻松地连接您的应用程序（外部系统、内部组件、甚至一段脚本），使他们能够交换数据。
Mule的架构风格是 Enterprise Service Bus (ESB) 架构，它也属于ESB产品一组，就如下图所示，具有如下品质特征：
- 互联互通。
- 低的耦合性。
- 高扩展性。
- 高可重用性。
- 易维护性。
Mule框架的一些说明：
- Mule框架具有高可扩展性，用户可以自己定制连接器（说实在的，Mule提供的一些东西，只能算是参考品，例如TCP连接器质量一般，必须定制Mina、Grizzly等强壮点的通信框架，自己实现一个连接器；老的那个XFire连接器，也很不好用，换成Jetty也得Fix一些BUG。要不是看它的框架还算巧妙，早丢弃了），拦截器，转换器等连接组件，同时能够把自己业务领域的计算组件或领域组件部署在Mule容器中；
- Mule框架支持面向服务的架构（ SOA ），能够通过JMS ， Web服务，数据库， HTTP等等连接器，无缝地整合应用系统；
- Mule框架可以独立部署，也可以嵌入；
- Mule已经与Spring实现了无缝整合；
- Mule框架有企业版和社区版，社区版是免费的，BUG多一些；其中企业版需要付出点费用；
- Mule有一个很长的授权文件，可惜E文不是很好，没有完全看明白，倒是记得了一句：“The Original Code is MuleSource Mule The Initial Developer of the Original Code is MuleSource Inc. All portions of the code are Copyright (c) 2003-2007 MuleSource Inc. All Rights Reserved。”，所以上市公司，请再仔细读读该文件。
- Mule不是对JBI的实现，但提供了JBI扩展。Mule使用起来比JBI要简单，也不像JBI强制要求SOAP堆栈，协议比较灵活，在分布式计算领域，性能也还是可以接受的。
ESB产品Mule+Spring实现最简领域驱动框架
| 更多内容在： |
架构专栏 |
先发一个消息，开源ESB产品Mule又发布了新的LDAP组件，很是让人佩服，首先赞一个先。
架构风格的基本组成体：计算组件、连接组件、信息、数据、配置。下图中，又抽象了一个领域组件，这也是为了让这个风格表示法能够同样适用于业务层面。
MULE+Spring完全支撑上图所示的架构风格，我们可以很容易的用它们实现最简领域驱动框架，以支持领域驱动设计。MULE大量提供连接组件（通信，协调，仲裁等）和信息链路拦截机制（可使用格式转换，加密，压缩之类的），也提供一些通用的计算组件，但更多的通用计算组件还是依赖自己开发；Spring提供了配置能力，把组件之间的关系记录下来；唯独留下新引入的领域组件（领域组件的计算能力可以很容易通过连接组件实现与其它组件的交互），需要我们自己来开发。
在《领域驱动设计在SOA架构中的实践》一文中提到技术架构师解决如下问题：“解决缓存、事务管理（包括分布式事务）、分布式接口规范、通信机制、共性系统服务的注入和应用契约、领域驱动设计风格与编程模式的确定、测试方案的确定、工具的提供、搭建可运行的环境、跨环境（分布式环境）的服务依赖策略、模型转换策略和工具的提供、集成策略”。下面用Mule+Spring的组合来对应一下：
- 缓存：是一个计算组件，需要单独开发。
- 事务管理：是一个计算组件，利用Spring事务，分布式事务需要单独定制一个计算组件。
- 分布式接口规范：需要单独定义。
- 通信机制：MULE提供。
- 共性系统服务的注入和应用契约：Spring提供。
- 领域驱动设计风格与编程模式的确定：见实践一文。
- 测试方案的确定：Spring提供单元测试，Mule提供分布式测试，可以定制一些测试辅助组件，例如：数据生成组件，该组件配合MULE的定时组件，很容易实现简单的自动测试。
- 工具的提供：MULE，Spring都提供了工具，DAO生成组件依据存储框架的不同寻找合适的。
- 搭建可运行的环境：再搞一个JBOSS，整个环境OK。
- 跨环境（分布式环境）的服务依赖策略：见实践一文，Spring + Mule提供技术支持。
- 模型转换策略和工具的提供：用Dozer 解决Bean-Bean，JAXB解决Bean-XML，或者Hessian解决Bean-Hessian；开发这些计算工具，配置在Mule的链路中，即可使用。
- 集成策略：Mule提供了各种连接组件，轻易集成外部系统或服务。
- 额外的：Mule提供了分布式计算环境，可以作为SOA技术平台来使用。
- 额外的：Mule提供了服务模型，可以作为服务平台来用。
- 额外的：Mule提供了Galaxy，解决服务治理。
通过上面的匹配，就会发现，以MULE+Spring为基础，实现一个更强大的领域驱动框架将会非常容易。
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）。
