[转载]SOAP--新一轮竞争的三八线?(一)

SOAP--新一轮竞争的三八线?(一)


远程而透明地调用世界任何一个角落的一个服务而不是一个组件似乎成了现在的潮流。Client/Server计算也许应该被称作 Client/Service计算了。在Web Service这一领域,自从Microsoft发布.net计划以来,软件产业的巨头和Internet时代的软件新贵们已经一起开始了新一轮的竞争。

一个无法否认同时短时期内难以改变的事实是:Microsoft确确实实已经早已占领了Desktop这个高地,回想其3年前的MS IE保卫战,Microsoft花费了十数亿美金的战略决策对于它自己来说毫无疑问是正确同时又别无选择的。然而同样从那个时候开始,IBM、SUN、 Oracle、Bea等巨头们透过Linux,Java、Apache系列的开放技术正在迅速占领着主流服务器端计算的市场。

是否可以大胆地认为,在服务器端,Microsoft仍然还在努力地进行高可靠性,大容量(可伸缩)、并行(真正的分布式)和高可靠性(关键级)计算的攻 坚战,守方是IBM、SUN、Oracle、Linux阵营和其它的新兴企业计算或电子商务软件厂商,从优势上看守方占上风。而在客户端形势则刚好反过 来。

商业或者生意永远是可以互相妥协的,本文试图寻找五年之内主流企业计算架构的"三八线"在哪里?客户端是Microsoft的操作系统和开发工具,服务端是Unix族,Java技术?

本文将试着给出一种可行的遵循这种"三八线"的计算架构,同时给出一个应用的例子,这个例子把一个Java对象从服务器的Java环境传送到客户端的非Java环境中,包括客户端和服务端的完整的代码以及部署过程。

SOAP及其计算架构简介

SOAP全称Simple Object Access Protocol,是一种基于XML的不依赖传输协议的表示层协议(还记得ISO 7层参考模型吗?TCP/IP大致相当于传输层和网络层,HTTP相当于会话层),用来在应用程序之间方便地以对象的形式交换数据。

在SOAP的下层,可以是HTTP/HTTPS(现在用得最多),也可以是SMTP/POP3、还可以是为一些应用而专门设计的特殊通信协议。

SOAP 应用系统可以两种模式工作,一种被称为RPC(Remote Procedure Call),另一种叫法不统一,在Microsoft的文档中称作document oriented,而在Apache的文档中,被称为message-oriented,这是一种可以利用XML交换更为复杂的结构数据的应用,而且,潜 在地可用于B2B中长事务处理等领域。在本文中,我们将集中讨论RPC,关于后者,我希望我能够在今后的文章中为大家介绍。关于RPC的计算架构见图1。

fig1-1.gif

从 图1中,我们可以看到,SOAP RPC的工作原理非常类似于WEB的请求/应答方式,无非用的是符合SOAP规范的XML代替HTML,HTTP是个无状态协议,但是今天通过 Session来管理状态已经是一个众所共知的技术了,无状态协议非常适合松偶合系统,而且对于负载平衡等问题都有潜在的优势和贡献。


blue_rule.gif
c.gif
c.gif
u_bold.gif回页首


基于"三八线"的具体架构与配置

这篇文章的题目看上去可能有些哗众取宠,其实用这么一个标题我还有一个深层次的意思想在这里表达,在现在这个软件技术飞速发展的Internet时代,我 们应该以一种更客观或者说更技术的观点来看待各家公司的产品或技术,而不要陷入狭隘的"门派"之争,好的计算架构应该是融百家之长的或者说专业一些是开放 的、兼容的、可平滑对接或可互操作的。这样无论对于最终用户还是对于这个领域的开发商都是有好处的。

作为XML小组的成员,Microsoft很早甚至在业界大肆炒作之前就开始应用XML了,在IE 4.0,Office 2000中都可以见到XML的痕迹。在本文中,我选用了Microsoft最近发布的SOAP Toolkit 2.0来作为客户端基本支持库,试图使用RPC模式与Apache的SOAP服务器端技术对接。这样的结构形成了一个三八线--SOAP,客户端从操作系 统到开发工具全部是Microsoft产品,在服务器端则是多家公司的产品,而且没有一个是Microsoft的。我想这的确应该是一个有趣的实验吧。

为了能够充分地说明问题,我采用两台互相连成IP网络的机器来做这个实验,尽管在一台系统上用localhost试验后面的例子毫无问题,但对于这个领域 的新手来说必须心里非常清楚哪些是Server,哪些是Client,因此可能会混淆一些问题。看一下我们的实验环境吧:
IP: 192.168.0.20 是一台 PIII 550 256M内存的系统,这将用于我们实验中的Client部份,这个系统用于实验的是下列软件: Windows 2000 Professional Edition(含IE 5.0)
Microsoft Visual Basic 6.0
Microsoft SOAP Toolkit 2.0

在这一端,我采用Visual Basic 6.0来作为开发语言,以利用SOAP Toolkit提供的方便的OLE Automation接口,同时尝试串行化(Serialization)后的Java对象传递到非Java环境下的处理,SOAP Toolkit还要调用MSXML Parser 3.0,它已经包含在了IE 5.0中,不需要另外下载。

IP: 192.168.0.10 是一台 PII 366 128M 内存的系统,将用于我们实验中的Server部分,这个系统用于实验的是下列软件:
Red Hat Linux 7.0
IBM JDK 1.2.2 for Linux
IBM XML4J 3.1.1
Apache Tomcat 3.2.1
Apache SOAP 2.1
SUN Java Mail 1.2
SUN JavaBeans Activation Framework 1.0.1

其实从技术上讲,由于Java工具的跨平台特性,用两套Windows的系统一样可以运行我们后面的例子,在服务器一端采用Linux的原因正是基于这篇文章的标题。Apache SOAP 2.1来作为SOAP服务器、Tomcat 3.2.1作为WEB服务器和Servlet容器、IBM的XML4J作为XML Parser,此外,应Apache SOAP 2.1的要求,还需要SUN的 JavaMailJavaBeans Activation Framework,这是两个纯Java的包,在Apache SOAP 2.0时并不需要它们,在Apache SOAP 2.1中由于支持SMTP/POP3的SOAP RPC,而导致需要它们,尽管在原理上我们这里的例子和它们不直接相关,但没有它们服务器无法工作。

基于这篇文章的主题,我不打算在这里讲述如何设置Linux与Windows相连的IP网络,也不介绍如何配置名字解析等问题,如果读者对于配置这个实验系统有困难,请参考有关的技术文章,这样的文章各个网站很多,比如 developerWorkers 的Linux主题区的内容就足够你配置这样的系统:)。我直接用IP来区分两台机器,只要互相能ping通,我们的例子就可以工作了。

在客户机一端,Microsoft的软件安装起来比较简单(我想这是Microsoft能够较快赢得用户的重要原因之一),在这个实验中,我们不需要特殊的设置,安装时一切用默认值就可以了,我相信绝大多数读者不会有障碍。安装的一般问题参考README就可以了。

在服务器这一端,除了操作系统和JDK之外,后面的五个工具全部是纯Java的。纯Java软件包在发布时一般不区分是什么平台的,只有包里面的一些脚本对应不同的平台。

在服务器一端,Linux部分的配置稍微有些复杂。IBM的JDK for Linux 1.2.2安装起来没有什么特殊的要求,但安装完之后请设置JAVA_HOME这个环境变量,为了方便你可以把下面两行加入到你的/etc/profile中(如果以后你需要设置无人值守的系统,就把它放在/etc/rc.local中):

JAVA_HOME = 您安装后的java目录


export JAVA_HOME

检查这个环境变量是否已经正确设置的方法是:
echo $JAVA_HOME

这个环境变量非常重要,很多基于Java的系统都检查这个变量,但只有个别的JDK的RPM包在安装时会自动设置它。

后面的5个包有ZIP格式的,也有.tar.gz的,用哪一个都无所谓,你只需以root的身份进入系统,用合适的解压缩工具把它们分别展开在一个目录中就可以了,一个Unix用户群比较习惯的目录布局是:

/usr/jakarta-tomcat         TOMCAT 3.2.1
/usr/soap2.1 Apache 2.1
/usr/XML4J-3.1.1 IBM XML4J 3.1.1
/usr/javamail JavaMail 1.1
/usr/jaf-1.0.1 JavaBeans Activation Framework 1.0.1



首先同样用设置JAVA_HOME的方法设置TOMCAT_HOME,这也是一个重要的环境变量。然后告诉大家一个带点儿 Geek精神的方法,把下列四个文件直接拷贝到$TOMCAT_HOME/lib下:
/usr/soap2.1/lib/soap.jar   这是Apache SOAP 2.1的全部Java类库。
/usr/XML4J-3.1.1/xerces.jar 这是XML Parser和DOM接口,另外两个jar是例子和SAX在SOAP服务器端不需要。
/usr/javamail-1.2/mail.jar 这是Javamail与SOAP 2.1 Server端有关的java执行码,其它几个jar服务器端不需要。
/usr/jaf-1.0.1/activation.jar 这是JAF里的Jar

如果你不打算在linux上看上边几个软件包的文档的话(我喜欢在Windows上看),上面所列的后三个目录就都可以删掉了,对于第一个只保留 /usr/soap2.1/webapps/soap,这个目录里是SOAP的侦听器(listener,就是后面讲到的rpcrouter)和 Deploy工具,它是一个标准的JSP/Servlet WEB应用程序。

我相信过这个过程可以使我们的读者更清楚地认识这些包里那些东西是真正的核心部件以及它们之间的关系,同时减弱对SOAP服务器端的神秘感。

编辑$TOMCAT_HOME/conf/server.xml,这是一个xml文件,找到一节,在里面加入下面几行表示把SOAP的侦听器应用程序作为一个虚拟目录"挂"到TOMCAT Server上:

docbase="/usr/soap2.1/webapps/soap"
debug="1"
reloadable="true" >



最后一步,编辑$TOMCAT_HOME/bin/tomcat.sh,把我们要用的那些.jar加到CLASSPATH中去,同时准备一个装载我们自己的Java Class的目录,也一并加进去。

在$TOMCAT_HOME/bin/tomcat.sh的第115行,在export CLASSPATH 之前,加入下面几行:

CLASSPATH=$CLASSPATH:/home/tuppin:$CLASSPATH
CLASSPATH=$TOMCAT_HOME/lib/soap.jar:$CLASSPATH
CLASSPATH=$TOMCAT_HOME/lib/mail.jar:$CLASSPATH
CLASSPATH=$TOMCAT_HOME/lib/activation.jar:$CLASSPATH
CLASSPATH=$TOMCAT_HOME/lib/xerces.jar:$CLASSPATH

这样保证了xercer.jar在CLASSPATH的最前面,如果系统原先固有的CLASSPATH 中有其它的Java XML Parser,不会发生因org.w3c.*这个名字空间冲突而导致系统出问题,名字空间在CLASSPATH中是先到先得。这是Apache SOAP 2.1在安装说明中特别提到的。

我在linux上使用tuppin这个用户名,因此我只要在/home/tuppin这个目录下写提供Web Service的Java类就可以了。

好了,该启动了,在root身份下输入: $TOMCAT_HOME/bin/startup.sh

一串提示过后,服务器启动。用客户端的浏览器测试一下服务器端是否工作正确,在浏览器的地址栏输入: http://192.168.0.10:8080/soap

现在两个世界已经分别准备好了,一端是Microsoft世界,另一端是我把她称为明星队世界,它们之间用Internet方式(TCP/IP)有了一个 物理连接,现在它们要使用开放的SOAP来对话与合作了。在本系列的下一篇文章中,我将介绍一个具体的应用例子,这个这个例子把一个Java对象从服务器 的Java环境传送到客户端的非Java环境中,包括客户端和服务端的完整的代码以及部署过程。同时,在下面的参考资料6中,我给出了如何获取上面这些软 件的URL。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/374079/viewspace-130726/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/374079/viewspace-130726/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值