SOA之路1
版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://ziapple.blog.51cto.com/271886/57601 |
SOA之路
引言 首先，我想写一篇彻底透彻Web服务的文章，包括各种工具的使用，最后还要包括应用，我一直想系统的介绍一下Web服务这个东西，因为在学习过程中几乎是摸索前进的，这曾经令我非常苦恼，虽然网上很多Web服务的介绍，但真正具体应用的却很少，国内这方面还处于一个学习过程。这是项巨大的工程，大的我都不知道如何说起，而且我是个菜鸟，我只想按照我的理解来还原Web服务一个真是面目，可能读者已经发现了我一会说SOA一会说Web服务，容易造成误解，概念界定的东西我就不说了，当我说SOA的时候，是从企业级架构考虑的，当我说Web服务的时候，则是从技术角度考虑的。
如果要我用简答的几个词概括SOA，同时也是我对SOA最深的理解，将是：
1. SOA是个重量级的企业架构，如果你的项目不是必须的就别做，做做研究可以。
2. 对企业而言，它就像当初ERP一样，不上是等死，上是找死。
3. SOA不是企业架构的终结，但至少会持续很长时间。
话不多说，进入正题。
文章结构1. 为什么要Web服务？我将从企业应用集成及分布式系统架构到Web服务的发展来回答这一问题，目前为止，还没有哪种技术可以取代Web服务，可以和Web服务的诸多特点媲美，最后得出结论，这是网络发展的趋势。
2. 一定要用Web服务吗？这是个很困难的命题，我看到很多人企业，很多个人在做应用集成整合，但很多情况下我看到他们并没有用Web服务，而是用相对简单的多的方法，Web服务的发展并没有像人们预想的那样快，在Web服务炒的最火的时候，IBM、微软和Sap各大公司都提供在线的商务注册（即UDDI），如今这几家全部关闭了。现在要我做企业集成，我更乐意推荐他们用一些相对简单的办法来实现。
3. SOAP 、WSDL、AXIS其实题目应该叫Web服务实现方式的，但这几个词实在是太重要了，作为搞技术的我不得不这么做，这是本文的核心之一。
4. UDDI发现Web服务前三章基本对Web服务有个整体把握了，如果你的项目只涉及到简单的层面，但就足以应付了。之所以把UDDI单独列一个章节，是因为它跟第三章的差别比较大，放进第三章有点牵强。本章将以一个注册服务为实例详细介绍UDDI相关细节，这是本文的核心之二。
5. SOA来了前面的都是技术层面的东西，离真正的企业SOA还差的很远，就像你知道拉面是一条条拉出来的一样，而真正让你自己动手却又不会，这是本文的核心之三，本章以智能交通信息服务集成为例详细介绍一下，也是作者根据自己的理解做的一个模型，真正企业是如何实施的我也不太清楚。
6. 未来方向本体一直作者研究的对象，断断续续有些时间了，但遗憾的是这方面一直没有实质性的进展，只是跟大家分享一下我的理解，如果要做研究的话这是个不错的方向，因为Web服务的东西已经被别人研究滥了。
第一章 为什么要Web服务动力是软件革新的一个非常重要方面。问题大机遇也大。机遇能够带来巨大效益，也就产生了解决问题的动力，从而推动了整个业界的发展。许多行业的主要革新都是这么反战的。电子商务应用集成的挑战是巨大的，以至于业界的主要公司都在关注它的发展。客户需要、市场压力和希望成为技术前沿精英的念头，促使许多公司投身于Web服务。摘自《用Java构建Web服务》steve graham。
对于软件业界的老手来说，有时发展势头就等于大肆渲染。那么是不是说：Web服务的成功也将取决于天花乱坠的广告宣传呢？绝对不是！Web服务的发展势头是实在的，并且不同于迄今为止我们在其他分布式计算潮流所体验到的。根本区别在于：众多的从业者都能够并行地参与补充标准化工作。我们来看一下分布式服务的发展史就知道标准化操作的有多大的意义。
历史上，分布式计算的重点问题是如何在若干个共同处理某个问题的系统间分配计算。在分布式计算中，最常用的抽象概念是RPC。RPC使得对远程函数的调用就如同对本地函数的调用一样。分布式面向对象系统要求基于对象的PRC（ORPC）。ORPC需要增加一些上下文才能调用特定对象实例的方法。RPC式的分布式计算和分布式对象的历史相当复杂。上面列举上些关键事件的时间表：
1987年
l Sun Microsystem开发了开放式网络计算（ONC）PRC系统，作为它的网络文件系统（NFS）的基本通信机制。
l Apollo Computer为其域操作系统开发了网络计算系统（NCS）的PRC系统。
1989年
l 开发式软件基础（OSF，即现在的开放组）为RPC系统发布了技术请求（RFT）。OSF收到了两个主要提案：一个来自HP/DEC,它是基于NCS(HP已收购了Apollo)的；另一个提案来自Sun，它基于ONC。OSF选择NCS作为其分布式计算环境（DCE）的PRC机制。
l 对象管理组（OMG）成立并发布分布式计算规范，它对语言的平台是中性的（OMG现在至少有650个成员）。OMG最初开发规范的就是“通用对象请求代理体系结构（CORBA）”，这是一个分布式的对象平台。
1990年
l Microsoft基于DCE/RPC的修订版开发了自己的PRC机制。
1991年
l OSF颁布了DCE1.0
l CORBA1.0上市，它提供了由C语言映射而来的单一语言。术语“对象请求代理（ORB）”开始流行，它指能作出分布式对象的基础结构软件。
1996
l Microsoft的分布式构件对象模型（DCOM）上市，DCOM与Microsoft以前的构件产品，如对象链接与嵌入（OLE）、非分布式的COM（OLE2的后继）和ActiveX(Web应用的轻量级构件)等紧密地联系在一起。核心DCOM的功能是基于Microsoft的PRC技术。DCOM是一ORPC协议。
l CORBA2.0上市，主要增强了核心分布式计算模型和能用分布式对象作较高层次的服务。互联网交互-ORB协议（IIOP）是其规范的一部分。IIOP允许多个ORB以销售商不知情的方式交互操作。IIOP是一个ORPC协议。
1997年
l Sun的JDK1.1上市，它包括了远程方法调用（RMI）。RMI为使用Java对象的分布式计算定义了一个模型。RMI类似于CORBA和DCOM，但只能以Java对象工作。RMI有一个称为Java过程方法协议(JRMP)的ORPC协议。
l Microsoft宣布COM+的第一次复出，它是DCOM的后继。COM+的能力更接近于分布式计算的CORBA模型。
1999年
l Sun的J2EE(Java2平台企业版)上市。Java2平台将RMI与IIOP相集成，使得Java和CORBA系统这间的交互操作更容易。
l 简单对象访问协议（SOAP）首次出现，代表着Web服务时代的来临。
虽然RPC和分布式对象都是建立分布式系统的传统方法，但并不是唯一方法。另一种非常重要的方法是面向数据或发文档为中心的消息传递。消息传递采取了不同方法，它不强调依靠调用专用的远程代码来实现分布式计算。应用程序可运行自己的独立计算，并通过消息传递来通信，纯数据包含在消息中。
当前，CORBA、DCOM、RMI等RPC中间件技术已广泛应用于各个领域。但是面对规模和复杂度都越来越高的分布式系统，这些技术也显示出其局限性：（1）同步通信：客户发出调用后，必须等待服务对象完成处理并返回结果后才能继续执行；（2）客户和服务对象的生命周期紧密耦合：客户进程和服务对象进程都必须正常运行；如果由于服务对象崩溃或者网络故障导致客户的请求不可达，客户会接收到异常；（3）点对点通信：客户的一次调用只发送给某个单独的目标对象。
面向消息的中间件（Message Oriented Middleware，MOM）较好的解决了以上问题。发送者将消息发送给消息服务器，消息服务器将消息存放在若干队列中，在合适的时候再将消息转发给接收者。这种模式下，发送和接收是异步的，发送者无需等待；二者的生命周期未必相同：发送消息的时候接收者不一定运行，接收消息的时候发送者也不一定运行；一对多通信：对于一个消息可以有多个接收者。
已有的MOM系统包括IBM的MQSeries、Microsoft的MSMQ和BEA的MessageQ等。由于没有一个通用的标准，这些系统很难实现互操作和无缝连接。Java Message Service（JMS）是SUN提出的旨在统一各种MOM系统接口的规范，它包含点对点（Point to Point，PTP）和发布/订阅（Publish/Subscribe，pub/sub）两种消息模型，提供可靠消息传输、事务和消息过滤等机制。
第二章 一定要用Web服务吗对于软件业界的老手来说，有时发展势头就等于大肆渲染。那么是不是说：Web服务的成功也将取决于天花乱坠的广告宣传呢？绝对不是！Web服务的发展势头是实在的，并且不同于迄今为止我们在其他分布式计算潮流所体验到的。根本区别在于：众多的从业者都能够并行地参与补充标准化工作。
接下来我们看看企业实施SOA时会遇到哪些困难，记得IBM两个特牛的人最近出了一篇文章专门介绍SOA团队开发的，里面讲到两点：一个是进度压力、另一个是重用压力。
有空接着写…
第三章 SOAP 、WSDL、AXIS这里面要讲的东西实在是太多了，但实际怎么用还是比较简单的，要学习的话网上有很多的例子，在我的博客里有也相关的介绍，这里我就不多说了，要学习web服务这三个法宝是一样都不能少的，只有正真理解这三样法宝才能理解什么是SOA。下面给出我的链接。
第四章 UDDI发现Web服务1. UDDI介绍在网上没有搜到很好的UDDI的详细介绍，主要Steven Graham著的《Bulding Web Service With Java》。
UDDI(统一描述、发现和集成) 是未来电子商务的基石，它使得商业实体能够使用他们首选的应用软件，快速、方便、迅捷地发现现存的或潜在的商业伙伴，并与之进行交易。所有的这一切全部由自动化的应用程序来完成，因此应用程序如何与UDDI注册中心进行交互就显得异常重要。
如图4.1所示，这是一个UDDI应用框架图，中间大圆圈表示internet网络，从上到下分为三个层次：服务提供者、UDDI和服务请求者。右边表示各个层次需要用到的工具。当然你也可以不使用这些工具，这只是作者在实际运用中的工具而已。
 本文出自 “邹润茨” 博客，请务必保留此出处http://ziapple.blog.51cto.com/271886/57601 本文出自 51CTO.COM技术博客 |
ziapple
博客统计信息
热门文章
最新评论
友情链接