不要误解和小看SOA的架构思路

好久没有到板桥大哥这里作客了。今天晚上有空就过来这里做一下客。
今天想和大家聊一下SOA。因为我和很多人聊过什么是SOA。SOA 到底是什么似乎很多人都没有很准确的了解SOA 的真谛。于是我今天从代码以外的一个角度就是开关角度(设计角度)来看一下SOA.

第一个例子：记得我上司在我面前质疑过SOA的作用,他觉得SOA的作用到底有什么重要的性,给我们带来什么更大的飞跃.他似乎不太满意外面鼓吹的SOA架构的作用-----我觉得他是在当今效果来评估SOA的作用来看SOA的实施的可行性；第二例子是我们一个研发人员看SOA（webservice）他是J2EE(JavaEE 5)应用软件人员他认为:soa 就是使用xml的描述语言来描述接口的技术，没有什么神秘和难以捉摸的技术体系----他是从代码技术角度来看SOA的实现载体。

的确他们他们的看法都有一定的代表性，第一个例子的看法他是从应用的高度来看，但是他的看法并不是SOA的错，却是现在的行业技术实现的事例（毕竟SOA的架构体系处于初级阶段,人们对他的理解还不是很高,特别是国内的技术人员理解得不够）造成的.第二例子完全就是从技术实现的片面的恶角度看SOA,这样的理解只是处于一种很低的层次看SOA,这样的看法是很不够也不可能设计出好的基于SOA的架构体系的.

那好,现在我就说说一下我的看法(看法也未必是正确,希望大家自己评估,如果大家觉得有什么错误或更好的理解请不要吝啬指出,谢谢大家乐);我认为SOA架构体系正是软件工程发展一个有标志性里程碑也是开关原则的必然出现的架构.SOA其实体现的是:分离关注点他和J2EE(JavaEE5)的JDBC/JDNI思路是一样的，而WebService只是他的一种行业标准化的结果而已，而并不是SOA就是SOAP（只是SOAP只是SOA的一种体现）。为什么我这样认为呢，这么说吧，换个角度看吧：如果我使用servlet/jsp来访问结构，jsp/servlet都返回一个XML的字符串（或是byte流,而且byte流里面有一个节点存放序列化的对象，和流程控制信息） 得到这个结果后对xml字符串后进行相应的解析进行相关的操作一样可以实现所谓的webservice的效果（只是不符合标准而已）以前我也曾这样做过web系统(只是不知道这就SOA的思想的实现)。

那么在现阶段较好使用 SOA是是什么呢，我个人觉得SOA根本体现分离关注点包含三个方面：一个是代码技术角度，一个是设计架构角度，一个应用业务功能角度。代码技术：反应的从对象/接口的关系静态（体现代码）-->描述的动态的转变；设计架构体系：从根本上可以把架构的技术关系从静态耦合关系-->代码没有耦合，耦合关系发生在runtime动态关系转变（这必然促使架构中组件关系的）；应用角度：这是他思路最强和更高层次看问题，从业务和技术功能的从静态耦合到静态分离(runtime耦合)转变----这是多么强大的功能能也是IT行业追求的效果.

所以说SOA是体现高度的开关原则的体现。所以我自己个人提倡不要以为SOA的体系没有太大的作用，其实如果能理解好SOA的思路，应用高层次可以帮助我们解决业务和技术功能的分离，在底的层次可以在系统内部的关系处理好分离关注点（系统/组件/类/对象的分离）功能；而WebService只是SOA的一种行业标准的实现而已。


SOA是一个大的抽象目标，相关概念还有：
为了变得更加有竞争力，企业必须创建一个面向业务(business-oriented)的，可靠的面向服务架构(SOA)，用来替代过去分散的、专用的应用平台，
相关组织正在建立一个全盘整体架构，这种架构横跨所有应用但是将这些应用中的服务暴露出来，网络应用平台（NAP：Network Application Platform ）指引了这样一条架构性质的帮助企业采用SOA方向性途径。

基本上，NAP提供了一个虚拟的用于创建SOA基础的应用平台，它由三个概念组成：服务总线(service bus)，基础服务模型（ISM:infrastructure services model）和服务设计实现（SDP:service design practices）

服务总线是一个产品 语言 平台等中立性的、可管理的通讯联系基础结构，服务总线提供了很多种联系通讯风格，包括one-way messages（消息系统采用的）, request/response(web最常采用的), brokered delivery（中转传送JMS）, hub and spoke(类似群发), orchestrated workflow

基础服务模型（ISM:infrastructure services model）是使得服务总线不只是一个基础通讯管道，它提供一群高附加值的服务，这些服务主要用于环境管理，这些管理功能包括：查找发现（类似JNDI）, 安全（security）, 可靠性（reliability）, 事务机制（transactions）, 转换性transformation, orchestration, 持久性persistence, 等等其他适合应用通讯的功能，主要是用来管理协调服务总线中的服务.

服务设计实现（SDP:service design practices）包含设计原理和符合松散性的实践代码接口，开发这应当遵循这些代码接口实现他们的应用服务，这些代码接口确保了架构设计的灵活性，平台中立性和跨平台协调性。

从上述文字意译看，SOA应该是对过去Web服务概念的抽象扩展，Web服务属于服务总线更下面的基础结构，太底层了。

SOA概念提出，实际是把EJB再搞大，大到跨平台，所以，Java EE现在是两个方向发展，大者更大，这是工业界以SOA为标志特色；最近EJB3推出则是向小者细化，这方面开源领域推动的比较多。

Java在企业市场已经衡强，桌面系统就靠SUN推广了，最近SUN和Google在桌面软件上联手，以及Java在Game大型游戏市场开源软件包推出，这些表明，Java从手机嵌入式到桌面系统到企业服务器到大型网络游戏到跨平台企业联合服务无处不在。

Gartner预测SOA将成为软件工程实践领域的主流，终结40年的单块软件架构统治。

SOA目标是整合业务过程，假设一个大型国企单位，有不同分部门，不同部门找一两个程序员编写部门用程序，应用挺好，就保持下来，后来这个单位开始整体上Java系统了，如何整合这些小部门之间、呈碎块状态的系统呢？

早期我们提出使用JMS，如果是不同语言系统，那么使用Web 服务，但是不同系统之间如何保证一个事务的完整性，特别是跨部门的审批，不同部门都有自己的数据库/应用服务器。

SOA设计目标必须具备下面要求：

1.异构性Heterogeneity，　横跨现有应用系统。（这类似Corba）
2.可伸缩性Scalability, 根据环境变化非常容易地能够提升系统性能。（这类似EJB）
3.适用性Availability，　将应用错误和通讯错误隔离开来，不至于因为一点失败导致全局混乱。
4.分布式Distribution，　跨部门跨地域交互操作
5.机动性Flexibility, 允许各个部门以最小的代价很容易更改与应用相关的设计和实现，也就是各个部门系统相互独立，没有耦合性。
6.可见性，　可以对各种处理和服务Service运行情况进行管理监视。

服务总线（ESB：ENTERPRISE SERVICE BUS）的提出能够帮助SOA实现上述目标，ESB提供了各种接口，以容纳各种通讯风格，有：
Web services
Application, Database, and Protocol adapters
HTTP
JCA, J2EE Appservers, .NET, C++, C#
RosettaNet, ebXML
JMS, WebSphereMQ, TIBCO
SMTP, FTP

服务总线实际也是一个容器，服务总线容器基于EJB教训，除了提出并行处理负载平衡，还提出本地透明　轻量的服务容器，这算是应用最新的组件设计理念了。

建立服务总线如同在各个村之间修通了公路，那么要达到各个村通过公路互相交换数据，还需要对公路上跑的“内容”进行一些定义，JSR 208―Java Business　Integration Services (JBI)是标准的组件模型整合，是一种松耦合，事件驱动方式的整合。

JBI促进帮助了和ESB的整合，这非常类似上个世纪的EJB标准规定（现在走向另外一个方向：简化），EJB标准对业务逻辑和应用服务器都进行了规定和说明。怪不得在EJB3专家组看不到工业界主力部队，原来都开赴到新一代标准JBI专家组里去了。

JBI有下面几个特征：
1.可插拔的整合组件
2.协议独立　支持HTTP, SOAP JMS EDI, ASN.1
3.松耦合　基于SOA的整合模型，　容器管理性质的模型，这点类似Web容器　EJB容器，Jdon微容器等等。
4.基于标准的接口：WSDL　，　不能使用Java的接口了，喜欢纯java的人就觉得在设计上不爽了
5.是SPI而不是API，允许各个应用提供专有的“黑盒子”服务，这样，提供服务就可以收费，实现商业赢利了，比如我提供给你一个搜索功能或Email功能，你付费给我。
6.第三方生态系统：可以扩展传统的J2EE/Java EE系统所能够达到的范围，J2EE相当于地球范围，JBI是航空技术，神六升空表示扩展我们的能力范围，这就是前面说的大者恒大。
7.规格化的消息路由：基于XML　可用WSDL，　JMS中消息格式没有特别规定，可以自由定义，但是只适合Java系统，
8.可部署，可打包，可通过JMX管理，这些类似对EJB服务器的规定了，JBI也会有一个容器载体。

最后，目前感觉ESB如同主板的总线，JBI类似可插入的显示卡等各种板卡，JBI中包装着各个应用系统的服务，将JBI插入ESB，各个应用系统的服务就可以握手对话了，某个应用系统如果提供一个搜索服务，而且可以收费方式提供。现在我们的服务整合是很低级的，例如我们使用银联的网上支付功能，只要到时将网页网址跳转到银联支付网址即可以，但是万一在支付过程中失败或重复怎么办？我这里的系统一点都不知道，所以Jdon的VIP会员网上支付有很多需要手工处理，这种弱智不安全的支付目前都是这样。

期待SOA吧。


看看IBM的说法

IBM这个地址不能访问，大概他们以为遭受黑客攻击，突然有很多访问量。

> IBM这个地址不能访问，大概他们以为遭受黑客攻击，突然有?> 多访问量。

用IBM开发者网络的帐号登陆就可啊

　我是个java初学者，我试着运行书上的实例，可以总出现
Ｅxception in thread "main" java.lang.NoSuchMethodError:main
这可能是我那方面的错呢？请速回，谢谢！
　　　　　　　　　　　　　　　　　　　　初学者
　　　　　　　　　　　　　　　　　　　2005.10.18
　　　　　　　　　　　

soa在java领域发展的不是很完善，基本停留在初级阶段，在可预见的将来一段时间里，可能也不会有太大的飞跃，主要原因是缺少操作系统级的支持。而微软在几方面作的工作比较多，从将要发布的长角操作系统的介绍来看，体现了一个soa最高理想：软件即服务。如果将来的操作系统都是为soa架构而设计的，soa才会深入人心。

看来大家都对SOA的有自己的见解，其实从SOA的在设计层面的看法其实也也体现解耦的一种思路，用冰云一种说法就是“去对象化吧”---至少有那么一点意思吧。作为IT系统来架设描述业务需求，用开发语言来描述业务---必然有主谓宾的关系了，soa的一个思路就是描述的一种解耦。

>主要原因是缺少操作系统级的支持
Java力图成为Internet世界的操作系统，编程人员通过简单脚本就可以完成他们的系统开发和衔接。ESB这些都是属于操作系统级别的技术

微软试图从桌面操作系统延伸为Internet操作系统，但是总是利用其威名让人翘首以待，Java的Weblogic 9已经有很强大的SOA功能。

个人觉得在这场未来操作系统中Java胜出概率要大，Java就是应网络而生，安全是网络系统的最基本通行证。

说句笑话，如果微软赢了，我也不会再搞软件了。已经没有意思了，让他一个人玩去吧。

哈哈，看来板桥大哥还是比较愤青哦，我个人觉得SOA不管谁做得好也没有问题，反正SOA本来就是套用别人的服务嘛，大可以，把MS好的东西拿过来自己用啊。大家都遵从SOA协议标准，那么我们就大可以英雄不问出处，只要好用就行,来个各民族大团结。

recher言之有理，这是一个大同目标，但是很担心各个厂商因为各自利益，在这个大同目标下做些只符合自己利益的事情，害怕这是厂商合谋再次要求用户掏腰包的一个幌子。

所以现在态度是冷眼观之。

板桥大哥大可不必为微软与java的竞争而偏袒谁，真到了soa大行其道的一天，我们的眼里只有标准，那里还有微软与java，他们都是通过标准为我们提供服务的一堆软件，至于我们的机器上安装了什么软件，我们根本不知道，也无需知道，谁还分得清微软与java。

下页