《专栏声音》Web Services ,在困惑中突围

类别:.NET开发 点击:0 评论:0 推荐:

《专栏声音》Web Services ,在困惑中突围

 


小气的神  2001-12-12

 

    What is a Web Service?”,这是一个不错的问题,但也是我无法回答的问题,而且这篇文章不会对此有任何结论,开始不会有结尾也不会有,答案将是一个仁者见仁,智者见智的归结。回答它需要有足够的智慧和许多人的相同或相似的认识,而目前只能是雾里看花,能看多少看多少,能看多远看多远。不过得承认我拣了一个让你注意的话题。

 

    如果你和我一样是一个开发人员,从认识或知道它的那一天起,我想你会喜欢它,或是对它产生兴趣。有人说这是软件工业的又一个黎明,也有人说它是SunMicrosoft之间裂缝的桥梁。无论是什么,它出现了,而且还夹带了XML,SOAP,UDDI,WSDL时髦名词和新技术,一时之间大家如此的亲和,消除了所有的分歧,欣然而体面的接受了它。众心所向的事物很容易获得滋长的环境和养料,况且Web Service也没有辜负众望,如果不是碰上美国经济衰退和去年网络泡沫的刺痕犹在,商业机器也许会再次催化它。当然,还好没有。

 

    不知你是否注意到:Web Service目前大多流传在开发人员之间,商业上的市场目前只是预热,不大不小但不容忽视。国外的软件业已经确实的开始研究和拓展整个Web Service框架和评估它对软件工业的调整程度;国内许多软件公司内部的BBS也都开始针对Web Service结合自己现有的软件体系开始讨论和实践,而民间的网站早就沸沸扬扬,热闹非凡。仿佛有产生了一种这样的景象:目前绝大部分的应用和程序都可以直接或间接的转化成Web Services的形式,而未来几乎所有的应用都将是Web Services形式的。加上Microsoft dotNET以及其他软件公司新产品的刻意侧重,开发人员是否会再次用技术的眼光和信心来诠释Web Services商业的发展,而导致又一次的失落?那么我想有必要现在泼点冷水:Web Services 真的这么好吗?(第二个不错的问题)

 

    首先声明我是一个Web Services的拥护和爱好者,泼冷水只是让我更理性的思考和看待Web Services,不会影响我对它的继续喜爱、研究和学习。Web Services似乎完全符合我对组件的理解:是一个自包含的 "功能生命体" ,它可以完成一个单独的任务。本身可以自描述,告诉别人自己的输入和输出,其它组件可以判断它能做什么,如何和它交互而获得它的功能。和其他组件通讯的方式简单、广阔和直接。我会很容易的把以前对COM的喜爱转移到Web Services上。针对松散耦合、可重用、开放程度、面向组件的特性要求下,它会被理解成目前最好的技术模型。但是对于我们喜欢的技术,除了学习、研究和应用外,我们是否对它未来的发展一定要加入自己独特的坚持,得到一个好或不好,是或不是的答案呢?(第三个不错的问题)

 

    好吧,先让我们看一些其他的东西,看看Web Services的生存环境,这里我只从各个软件开发商的情况,任何一项IT新技术都需要硬件开发商、软件开发商、开发人员和它的市场价值体现。软件、硬件开发商以及开发人员的支持对一项技术是先决的,而Web Services是我目前见到支持最多的一个,每个软件开发商都有自己的开发平台,问题不是支持,而是支持多少,如何吸引开发人员到自己平台的问题。那么面对众多的平台和选择,每个开发人员在Web Services可能成功的未来,你将如何选择一个合适而成功的平台进行开发呢?(第四个不错的问题)

 

HP

HP Application server 8.0

HP Total-e-server 7.3 developer edition

HP Web services platform developer edition

HP Internet server

HP core services framework

HP Total-e-server localization (L10N) pack

HP Total-e-transactions 2.1.1

HP Total-e-mobile 1.1.1 evaluation

HP Total-e-server 7.3/process manager 5.0 adapter

IBM

IBM WebSphere Application Server, version 4.0

IBM WebSphere Studio

IBM WebSphere Business Integrator

(MQSeries to deliver SOAP messages )

IBM DB2 Version 7.2

IBM Tivoli Web Services Manager

IBM Lotus' software

Microsoft

Hailstorm

Microsoft.NET ( dotNET )

Microsoft Windows.NET

Microsoft Windows 2000 Server

Microsoft Visual Studio.NET

Microsoft Sharepoint Portal

Microsoft Content Manager

Microsoft Biztalk

Microsoft ISA Server

Microsoft Mobile Information Server

Microsoft SQL Server

Microsoft Passport

Oralce

Oracle9i Database

Oracle9i Application Server

Oracle9i Developer Suite

Oracle9iAS Portal

Oracle Internet File System

Oracle9iAS Integration

Oracle9iAS Business Intelligence

Oracle9iAS Cache

Oracle9iAS Wireless 

BEA

BEA WebLogic Server 6.1,

BEA WebLogic Integration 2.1

BEA WebLogic Personalization Server

BEA WebLogic Portal 4.0

BEA eLink

BEA WebLogic Enterprise

BEA Tuxedo

 

Sun

SunONE

Forte for Java  Enterprise Edition 3.0

Sun JDK & J2EE

 

上述的列表(数据来源于上述各公司网站)都是从Database ,Application Server  ,Development Tool, Middle-Tier Components , Portal, Content Management, Integration, Business Intelligence, Mobile这几个方面来列举,这些产品并非只指Web Services,各家公司都更愿意提供一个开发平台和WebService解决方案。从上面看,除了Sun交了一份让人有些感到不可思议的答卷外,其他的表明了一种积极的支持,从这个方面看,Web Services是乐观的。

 

    然后从我们可见的实际应用上Web Services又如何呢?记得我曾在很久以前的一篇《另类资源》的文章中提起过salcentral.com salcentral.comXMethods是目前比较有名的两个Web Services的发布和搜寻引擎,刚好不久前有人对salcentral.com做了一个研究和统计报告,也让我们看看目前大多数发布和可使用的Web Services的情况:

 

Web Services & UUID

 

 

错误原因统计

URL Available

Description

Total

%

Yes

Correct format and confirmed to be available

818

52%

No

Value was blank

296

19%

No

The format of the URI could not be determined

211

13%

No

Connect Failure

165

10%

No

Protocol Error such as 401 Access Denied

91

6%

 

片和统计表格(数据来源Mike Clark:《UDDI - The Weather Report》EMail:[email protected] )最直观,左边是对Web Services链接的利用情况,右边是UDDI登记的情况,表格则是对1581个UDDI访问错误原因的分类统计。结果让人有些失望和担忧。67%的Web Services不能够使用或访问;UDDI注册中也有近一半48%的不能使用。如果这就是Web Services的使用现状,那么显然,Web Services并不容乐观。调查的作者认为:照这样的比例推算,未来几年,如果UDDI的登记记录达到1,000,000 条,那么就有近48,000条是无用的。一方面这个问题需要引起重视,加强管理。另一方面对Web Services本身也将有伤害的。其一,目前真正可以使用的Web Services并不多,排除实验性和日常功能的Web Services,真正可以商用的几乎是粒粒可数,如果说未来Web Services是组成应用的主体或一个部分,那么你如何相信这样质量的Web Services不会对你应用的质量和稳定产生影响。

 

纵向的仔细看Web Services ,每个开发人员也许有不同的疑虑,事实上这些疑虑没有统一或是获得一个清晰的认识,那么Web Services还只能是一种概念和争论。我们有那些疑虑呢?

 

观念的认识

     Web Services实现“软件作为一种服务”体现,最终让人联想到软件最后可以成为一种真正意义上的价值体,而且可以在网络上实现价值的体现,转移和流动。透过可以兑换金钱的蓝图之外,我们还不能看到一种有效的方式用Web Services作为载体或主体来实现。“Web Services能够产生新的业务模型,但本质上是一种技术解决方案。”,那么有如何来产生这个新的业务模型,从解决方案到具体实现这种业务模型又要经过如何的转变?现实中现在还没有这样的典范和成功案例,可以让人振奋的是目前所有有关向Web Services的转变都是从企业内部和现有应用上的扩展上,Web Services目前最为直接的好处是有利于整合内部部署,与其丢掉旧系统或对其进行重写,不如用最快的方式将它暴露为Web Services。

 

一些演示业务已经出现了: Xmothods.NET网站为FedEx提供包裹跟踪、货币兑换和加州公路路况查询;集成工具厂商Cape Clear Software提供机场天气状况信息;Continental Airlines公司提供航班情况信息;ActiveState公司提供股票行情数据。微软和休斯顿的Compaq公司正在从事的一个导航项目。使用灯塔Web站点,农场主就可以检查天气报告和将来的价格,对他们的土地做出地图,有效地管理供水。Emerald已经创建了一个名为网络索引服务器(Web Index Server)的产品,此产品从多个地区罪犯信息系统中收集数据。 网络索引服务器使联邦机构能够利用从本地、县、地区和州罪犯信息系统收集到的数据去查找可能的嫌疑犯。

 

Web Services并没有发明新的东东出来,所有的许多都是从原来的系统上扩展而来。如果我们头脑足够的清醒,Web Services需要脱下全能的光环,走下救世的神坛。

 

安全、认证和性能

 

有关安全和认证,W3C现有XKMS (XML Key Management Specification)和SAML (Security Assertion Markup Language) 两个都是进程中的规范但也是现成的。不过自己实现这些标准将是一件卓越和痛苦的事,现在Grand Central 和Flamenco Networks 都提供有关Web Services的安全服务。另一个是Microsoft's Passport,MS现在已经谨慎的将其定位在.NET My Services中,使用起来相对方便和经济并且Passport支持Kerberos 5.0 标准,但是目前Passport只提供用户的单一Authentication,如果需要不同等级的不同用户Authentication ,那么你还需要选择其他的方案和办法。号称具有工业标准的The Liberty Project 则是另一种力量,不过目前看不到有任何实质的东西可以使用,传说它是因为惧怕Microsoft而出现,现在看来Microsoft已经感到足够的威胁和骚扰,应变的办法如俄罗斯抵抗北约东扩一样,成则力举Passport,不成则转成一个成员。因为Web Services已经被Microsoft盘剥成两种:.NET My Services和XML Web Services。对于安全和认证,也还没有一种很明显和让开发人员清晰的方案,争执还将继续,较量才刚刚开始。

 

至于性能,一个分布式应用性能很容易被平均响应时间和每秒完成事务数两个指标左右客户的眼球和大脑。几乎能够全兼容以前应用又可以轻易穿过防火墙的Web Services是否也能够带来比以前架构更好的性能?如果是,那么Web Services真是太好了;如果不是,那么需要做些什么来让它做到。Web Services绝对是一个有生命力和高性能的技术,但有关真实和具体的表现,目前还看不到,或者说还没有提到我们该讨论它的议事日程上。好吧,我们也再等等。

 

 

商业要求的事务

     Web Services基于一个开放的,以Internet为中心的基础构架。Web Services所表达的模型中,电子商务流程内的离散任务被广泛分布于一个增值网中。Web Services元素可以被其它公司重新组合,来满足他们自己软件和业务流程的需求。所有的商业应用都要求不同颗粒的严格事务来保证每一笔交易的成功或失败。单个或较短的交易链我们不需要考虑这些。不过实际的商业从来不是简单的,当多个交易发生并且象供应链一样交织纵横,那么从链首到链尾的事务处理可能需要很长的时间处理,而且情况会很复杂。包括SAML(Secure Assertion Markup Language), 商业事务协议, 和IBM公司的可靠HTTP,都试图在某种程度上解决这些问题,无论是标准委员会的同意还是实际的应用都是一个谨慎和需要时间的过程。不过如果商业对此表示出明显的厌恶和不满,那么Web Services的发展将会面临一个显而易见和巨大的障碍。

 

 

复杂的组件环境

 

     组件的动人之处在于多个组件的依附和相互存活,一个复杂的组件环境足以模拟一个真实的现实,一个完整的商业应用。但许多个商业应用都要使用一个Web Services时,那么这个Web Services的存活可以想像成一根链条中一环,这个Web Services的升级、维护、成长和任何的变化都需要严格的定义和监控,它必须有足够的智力能将它的情况通告给整个应用让其他组件发生相应的变动,它必须保证多赢而不是链断。如果足够的大和复杂,而且分布的足够的广,那么就会有更多的Web Services是存在于你不能控制的环境中,而且它们的存活环境也将各自不同和多样。网络技术再次证明了它的互联魅力,不过现在网络上的每个节点比以前要更复杂、更多样和不可预知。

 

 

开发人员的黑洞

 

     Web Services在展示其所有的优美表现的同时,自然的也会开出绝佳的价格: 服务组件必须为更通用的方向去开发, 程序员必须预先估计出许多应用都可能要用的功能,留下许多未来可以预知的接口来扩展,重用,耦合。而PM绝对不会因为要获得以后才能实现的代码重用的好处而使项目拖下去;没有设计经验的初手将再次展现他们的经验不足,束手无策的放任他们的疏忽;设计者也会不小心或是保守的依照原来的设计经验,将应用在组件化的过程中分的尽量独立和小,从而使整个应用中的组件关系更加分散和复杂。维护人员需要比以前更多的技能和耐心才能了解系统,同时也注定会有一段时间将如同在脱缰野马上一般摇动不安。剩下的还有大量的足够清晰的文档需要生成,实际的开发人员需要掌握更多的技术和隐晦难懂的编程技巧,才能在新的令人赞赏的体系结构中开始自己新的编程之旅;程序应用间消息传播的方式和架构方式更加不固定,重新编程将被利用已有的Web Service的念头诱惑;每一个程序开发人员的判断能力将和他的编程能力同样重要,而且他还必须自如的穿越在现存的各种不同组件体系结构中。

 

“由于对Web Services所需的时间和工作量有了更现实的估计--以及对Web Services的限制的更清晰的理解--也许这种很有前途的技术不会象许多其它的技术那样遭受过高的期待。”Web Services象香港电影一样还没有一个明确的概念,还在不断的摸索和自由生长,不过有一点不容置疑:这种建立在商业和积累价值基础上的新技术,支持商业的递增,同时本身的清楚、漂亮、低成本、可互操作也将是商业需要的。(担忧的是软件技术对商业越来越强的依赖感可能是对软件本身自由精神的一种伤害)而Web Serivces身处在一个经济低迷衰颓,时势战略转型的十字路口,前途充满了不确定性。在高潮来临之前,它必须在“传统IT浅滩之外的地方积聚力量”,在过去和未来交织的迷惑中突围。

 


 

特别说明:

此文非CSDN官方专栏文章,所以文中观点只是作者本人有感而发,不代表和反映其他人观点。

本文署名原创,CSDN首发,如非经过作者授权其他人请勿用于新闻或商业用途。

如有其它疏漏不再一一注明

本文地址:http://com.8s8s.com/it/it46187.htm