/**
*作者：张荣华(ahuaxuan)
*2007-9-20
*转载请注明出处及作者
*/
[size=11]首先来一段名词解释吧：
名词解释：
B2B，business to business。（非电子商务中的b2b）
A2A， Application to Application。（可以翻译为应用到应用）
第二个概念好像不是很常见，我暂且用来表示企业内部的应用。B2B用来表示不同企业的应用。
Message Endpoint: 消息端点，接受消息的端点（我们把企业应用之间传输的数据可以称之为消息，那么接受消息的端点就是Message Endpoint）
Adapter: 这是一个非常重要的概念，这里的Adaptor可能是应该应用，或者是组件，为了消除不同系统之间的差异性而产生的。
看了几个基础概念之后，对消息比较熟悉的人大概都知道我在说什么了，没错，还是SOA，但是今天主要不是谈概念，而是架构。
我们知道随着社会的发展，企业内部和企业之间的交互变的越来越频繁，尤其是企业内部的系统。一个大型企业会用到大小不一的多个系统，他们可能是用不同的语言写的，运行在不同的机器上，有不同的系统平台，但是随着企业的发展，他们之间开始需要有信息交互。那么他们就需要被集成起来。
除了企业内部的系统集成，还有一种就是企业之间系统的集成，他们需要共享信息，或者他们通过系统来做生意，这些都是企业之间的系统集成。
下面我们来设定一个具体的场景：某企业内部有多个独立的系统，但是这多个系统需要有信息的交互，而且这多个系统之间的某一个系统还需要和其他企业的系统进行交互。看上去问题域非常明确，就是信息交换。我用visio画了一幅图来表示这种场景。
见图1
[img]http://www.iteye.com/topics/download/ee7f1440-4b68-44e4-b10d-c667af651dd8[/img]
从图上看来，有四家公司有着业务上的联系，他们分别是A,B,C,D四家公司。A公司分别和B,C,D三家公司有业务往来。A公司内部有多个系统进行交互，我们就叫它A2A。显然A公司和B,C,D三家公司之间存在着不可避免的差异性，但是这不是我们要关注的重点，重点是A和BCD是属于哪种情况，很显然是B2B。那么在上面这张图中同时出现了A2A和B2B两种情况，这两种情况可以说是SOA中常见的场景了。
在这里我也不打算提供企业应用集成(EAI)服务器和企业服务总线方面的讨论，因为我也没有研究或使用过哪个EAI和ESB框架（但将来可能会使用，“将来的事将来再说“）。
我们可以把A公司的app称之为endpoint，其他应用的接入点称之为adapter（内容应用之间也有可能存在adapter，其他企业接入点绝大多数都需要adapter了）。如图中所示，这样我们就可以明确整个图的概况了。A的整个应用体系由endpoint和adapter构成。
我们可以看到在A2A的情况下有一个JMS server，还有轻量级远程调用，我也知道，很多公司在A2A的情况下使用了webservice，但是我认为这是不恰当的，太重量级了，不合适企业内部应用之间的调用（特殊情况例外，比如两个应用使用不同语言开发等等，有时候这种特殊情况是很多的，呵呵）。那么A2A的情况下用什么比较好，个人觉得如果都是构建于java语言，那么使用jms+httpinvoke或者jms+Hessian比较好。为什么，简单。两个都是java的应用使用xml作为通信的结构会带来不必要的复杂，而且会浪费大量的带宽，而且是大师推荐（该点仅作为参考）。
而在B2B的情况下，好像选择也不是很多，一般就是基于xml+http，还有就是webservice.(虽然还是xml+http)，这种情况应该很常见，实际上我们可以看作是通过文件来作为消息传递，但是这个文件的格式被统一化，规范化了，就是xml。
在我看来图中所描述的业务模型就是A2A+B2B的结合体，当然我们也要区分他们，区别对待，因为不同的场景都技术的需求是不一样的，比如B2B的场景中我们可能需要security（我们可以现在ws-security），而A2A的场景中绝大多数不需要security支持（这也是jms规范中为什么没有定义security相关内容的原因）当然授权和验证不能属于security，授权和验证大多数remote invoke技术都是支持的。这里讲的security是指”对称加密”，”非对称加密”，”数字签名”，”双重签名”的支持等。
当然这所有的一切都是基于都业务和系统的了解，如果对业务不了解就不要谈架构了。说到这里我想批评一下自己，原来一直不重视业务，为了技术而技术，后来慢慢发现业务的重要性，可以这样说，如果对业务不熟悉就不能给整个系统作一个合理的架构，如果对业务不熟悉也不能写出好的代码来，因为代码就是对业务的抽象，不熟悉业务怎么可能写出好代码（当然并不是说熟悉了业务就一定能写出好代码，这还得看程序员得水平了）。
至于具体的技术的特性（如，jms，webservice，hessian等等）不在这篇文章的讨论之列，本文假设大家对这些技术都比较了解。
欢迎大家对技术的选择提出不同的看法。而且我觉得这篇文章是比较high level的，如果大家比较感兴趣，我会接下去和大家一起学习讨论具体的技术。[/size] :arrow:
*作者：张荣华(ahuaxuan)
*2007-9-20
*转载请注明出处及作者
*/
[size=11]首先来一段名词解释吧：
名词解释：
B2B，business to business。（非电子商务中的b2b）
A2A， Application to Application。（可以翻译为应用到应用）
第二个概念好像不是很常见，我暂且用来表示企业内部的应用。B2B用来表示不同企业的应用。
Message Endpoint: 消息端点，接受消息的端点（我们把企业应用之间传输的数据可以称之为消息，那么接受消息的端点就是Message Endpoint）
Adapter: 这是一个非常重要的概念，这里的Adaptor可能是应该应用，或者是组件，为了消除不同系统之间的差异性而产生的。
看了几个基础概念之后，对消息比较熟悉的人大概都知道我在说什么了，没错，还是SOA，但是今天主要不是谈概念，而是架构。
我们知道随着社会的发展，企业内部和企业之间的交互变的越来越频繁，尤其是企业内部的系统。一个大型企业会用到大小不一的多个系统，他们可能是用不同的语言写的，运行在不同的机器上，有不同的系统平台，但是随着企业的发展，他们之间开始需要有信息交互。那么他们就需要被集成起来。
除了企业内部的系统集成，还有一种就是企业之间系统的集成，他们需要共享信息，或者他们通过系统来做生意，这些都是企业之间的系统集成。
下面我们来设定一个具体的场景：某企业内部有多个独立的系统，但是这多个系统需要有信息的交互，而且这多个系统之间的某一个系统还需要和其他企业的系统进行交互。看上去问题域非常明确，就是信息交换。我用visio画了一幅图来表示这种场景。
见图1
[img]http://www.iteye.com/topics/download/ee7f1440-4b68-44e4-b10d-c667af651dd8[/img]
从图上看来，有四家公司有着业务上的联系，他们分别是A,B,C,D四家公司。A公司分别和B,C,D三家公司有业务往来。A公司内部有多个系统进行交互，我们就叫它A2A。显然A公司和B,C,D三家公司之间存在着不可避免的差异性，但是这不是我们要关注的重点，重点是A和BCD是属于哪种情况，很显然是B2B。那么在上面这张图中同时出现了A2A和B2B两种情况，这两种情况可以说是SOA中常见的场景了。
在这里我也不打算提供企业应用集成(EAI)服务器和企业服务总线方面的讨论，因为我也没有研究或使用过哪个EAI和ESB框架（但将来可能会使用，“将来的事将来再说“）。
我们可以把A公司的app称之为endpoint，其他应用的接入点称之为adapter（内容应用之间也有可能存在adapter，其他企业接入点绝大多数都需要adapter了）。如图中所示，这样我们就可以明确整个图的概况了。A的整个应用体系由endpoint和adapter构成。
我们可以看到在A2A的情况下有一个JMS server，还有轻量级远程调用，我也知道，很多公司在A2A的情况下使用了webservice，但是我认为这是不恰当的，太重量级了，不合适企业内部应用之间的调用（特殊情况例外，比如两个应用使用不同语言开发等等，有时候这种特殊情况是很多的，呵呵）。那么A2A的情况下用什么比较好，个人觉得如果都是构建于java语言，那么使用jms+httpinvoke或者jms+Hessian比较好。为什么，简单。两个都是java的应用使用xml作为通信的结构会带来不必要的复杂，而且会浪费大量的带宽，而且是大师推荐（该点仅作为参考）。
而在B2B的情况下，好像选择也不是很多，一般就是基于xml+http，还有就是webservice.(虽然还是xml+http)，这种情况应该很常见，实际上我们可以看作是通过文件来作为消息传递，但是这个文件的格式被统一化，规范化了，就是xml。
在我看来图中所描述的业务模型就是A2A+B2B的结合体，当然我们也要区分他们，区别对待，因为不同的场景都技术的需求是不一样的，比如B2B的场景中我们可能需要security（我们可以现在ws-security），而A2A的场景中绝大多数不需要security支持（这也是jms规范中为什么没有定义security相关内容的原因）当然授权和验证不能属于security，授权和验证大多数remote invoke技术都是支持的。这里讲的security是指”对称加密”，”非对称加密”，”数字签名”，”双重签名”的支持等。
当然这所有的一切都是基于都业务和系统的了解，如果对业务不了解就不要谈架构了。说到这里我想批评一下自己，原来一直不重视业务，为了技术而技术，后来慢慢发现业务的重要性，可以这样说，如果对业务不熟悉就不能给整个系统作一个合理的架构，如果对业务不熟悉也不能写出好的代码来，因为代码就是对业务的抽象，不熟悉业务怎么可能写出好代码（当然并不是说熟悉了业务就一定能写出好代码，这还得看程序员得水平了）。
至于具体的技术的特性（如，jms，webservice，hessian等等）不在这篇文章的讨论之列，本文假设大家对这些技术都比较了解。
欢迎大家对技术的选择提出不同的看法。而且我觉得这篇文章是比较high level的，如果大家比较感兴趣，我会接下去和大家一起学习讨论具体的技术。[/size] :arrow:
2801
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
