Apache Camel - 0.5 - SOA与ESB
SOA
Apache Camel相关代码已经上传GitHub，需要的自取：GitHub - Apache Camel 完整Demo
如果觉得还行，麻烦点个Star
SOA是一种架构思想，主要围绕多个"服务"如何进行集成以达到某种目的。
SOA中服务的定义是什么呢？
在业务系统中被发布出来供用户使用，能完成一个完整业务过程的功能，就是服务。
服务着眼于完整的业务
从上面对于"服务"的定义就可以看出，服务定义的对象是：业务系统中完整的业务功能。
例如：
电商系统中的"确认订单"这个功能就是一个服务、计费系统中的"当月费用结算"功能也是一个服务。
但在操作这两个功能之前的"用户登录"动作就不是服务了..它是为了操作"确认订单、当月费用结算"功能的鉴权步骤
服务的粒度虽然相对粗放，但却可控，目标是重用
“用户登录”这个功能在某些情况下也可以满足“服务”的定义：当用户中心系统为其他所有业务系统统一提供的“登录”服务被公布出来时。
服务粒度的拆分完全依据业务系统中业务过程进行定义和分析，所以服务的粒度都相对粗放。
就像上一段文字中所举例的“费用结算”服务那样，可能完成“费用结算”功能，在计费系统内部需要完成：用户身份确认->上月费用查询->套餐清单查询->费用明细生成 这几个过程。
但是这些每一个过程都不会有任何其它业务系统进行单独使用，也就是说是否单独公布这些处理过程对于其他业务系统来说没有任何意义。
如果在后续的业务变更/业务重编时，业务设计人员发现某一个业务系统需要单独使用计费系统的“上月费用查询”功能，这时就需要计费系统将这个功能作为一个独立的服务向第三方业务系统公布出来。这时，这个功能就满足了“服务”的定义。
集成的目的是形成一个新的服务
对企业内部的业务进行集成，被集成的业务服务称之为原子服务，集成的目的是重用这些原子服务形成一个新服务。
这样保证技术团队/业务团队能以最小的代价，最高的效率使用既有服务。
SOA需保证屏蔽细节
使用SOA架构思想构建多个业务系统的集成关系，需要保证每个业务系统屏蔽细节。
这些细节包括技术细节和业务细节。
从技术细节看，不论业务系统使用哪种语言开发，哪种对外传输协议，哪种消息格式都可以使用SOA进行集成。并且内部完成不同协议转换和不同消息格式转换。
从业务细节看，SOA需要屏蔽业务系统的功能步骤细节，也就是说，第三方只需要知道调用某一个服务就可以达到业务目的，至于提供服务的业务系统如何实现业务过程无需关心。
SOA让各业务系统保持松散
SOA架构模型为多个业务系统进行松散集成提供了一个良好的思路：
通过屏蔽各业务系统技术细节和业务细节，兼容各业务系统的不同传输协议和不同消息格式，可以让通过SOA进行业务集成的各个业务系统保持低耦合状态。
这是因为所有协议和消息格式都处于开放状态，业务集成时各业务系统不需要单独进行额外的转换工作，甚至不需要为基于SOA的业务集成进行任何额外工作，也无须知道对方系统的存在。
ESB
ESB全名：企业服务总线，是SOA架构思想的一种实现思路。
举一个栗子：
企业的信息化建设一般经历很长时间的发展，少则5、6年多则10几年。
所以我们看到某大型企业的信息系统最可能的情况是：存在着多个业务系统，甚至各业务系统负责的功能职责还存在重叠。
这些系统采用不同时代的编程语言、编程框架、通讯协议、消息格式和存储方案。
例如：
计费系统可能采用C++ 进行编写，对外调用功能采用CORBA；
年久的CRM系统采用Delphi进行编写，同样使用CORBA发布调用功能，并且最近两年该企业刚对CRM系统使用C#语言进行了一次升级，
但是由于数据存储层的设计原因，并没有将老系统的所有数据割接到新系统，所以目前两套CRM系统都在使用；
最新开发的财务联动系统，采用Java语言开发，并且不再采用应用程序窗口，改为使用浏览器进行页面展示和用户操作。
这个财务联动系统多数对外的服务采用HTTP协议对外公布；
还有一部分服务采用Thrift RPC对外公布……
由此可见，由于各种可见的和不可见的原因，企业信息化系统的建设历史和现实存在往往纷繁复杂。
如果这些系统需要进行服务集成，但是又没有一个成熟稳定、兼容易用的中间层进行协调，
那么要达到以上的调用要求基本上不可能的（即使实现也相当难以维护和扩展）。
那么为了满足SOA架构思想的设计要点，达到既定的工作目标，ESB总线技术至少需要帮助这些业务系统完成以下工作：
多种调用协议支撑和转换
无论业务系统向外部公布的服务使用哪种调用协议，都可以通过ESB技术进行兼容和转换。
例如：
A业务系统的服务只接受WebService形式的调用；
B业务系统却使用Thrift RPC进行调用；
在基于ESB服务的中间层帮助实现两种协议的转换。
多种消息格式支撑和转换
无论调用协议携带哪一种消息描述格式，通过ESB中间层也可以实现互相转换。
例如：
ESB中间层应该支持将JSON格式的信息转换为目标业务系统能识别的XML格式，或者将XML格式转换为纯文本格式....等等。
服务监控管理(注册、安全、版本、优先级)
既然ESB要对原子服务进行集成，考虑的问题就比较多了。
首先业务提供提供的服务可能会周期性的变化(迭代、升级)...等复杂情况。
那么ESB的实现软件中应该有一套功能，能够保证再这样的情况下集成服务依然能够工作。
还要有一套完整的功能保证服务集成的安全性和权限。
作为被集成的业务系统，ESB中如何集成它提供的原子服务，前者是不需要关心的。
服务集成和编排
为了将多个服务通过ESB技术进行集成，形成一个新的服务，ESB技术必须能够进行服务编排。
服务编排的作用就是明确原子服务执行的先后顺序、判断原子服务执行的条件、确保集成后的新服务能够按照业务设计者的要求正常工作。
举个栗子，下图示例了新服务“工单派发”通过多个业务系统提供的原子服务，按照设置的执行条件在ESB总线上进行工作的过程：
上面讲了很多关于SOA 和 SEB 的理论内容，但其实，要我们自己开发一个ESB系统，难度是非常大的。
之所以要写上面的内容，为了要引出Apache Camel，因为Camel 是一个需要二次开发的框架，为我们提供了很多的功能组件，利用它，可以较为便利的实现一个ESB(很多功能还是需要我们自己手动实现的...)
即便我们不需要使用它来完成一个ESB，我们也可以使用它的相关组件，来简化我们平时的开发代码。
下一篇，我们就用一个小栗子，来看看Apache Camel的使用。