WebService架构 - 为什么需要Web服务?
WebService架构 - 为什么需要Web服务?
本文是架构Web服务的系列文章的首篇，从Web服务的商业需求开始，来探讨为什么要使用Web服务。首先，作者分析了目前电子商务应用所面临的挑战: 务实和追求经济利益是当今电子商务的需求。然而目前广泛应用的电子商务应用的体系架构使得这一商业需求很难实现，复杂的应用连接和程序代码造成了应用的高维护代价和更新代价。而作为现有技术的革新(而不是革命)的Web服务却正好能解决这一问题，成为目前应用环境中最为合理的解决方案。
Web服务似乎是一个崭新的名词，现在去浏览各大主流技术论坛，无一不在关注Web服务的发展。但是到底是么是Web服务呢？很多技术人员初次接触Web服务，会有一个错觉，认为这是一个新的系统架构，新的编程环境。是的，Web服务是一个新的概念，但他的系统架构，他的实现技术却是完完全全继承已有技术的，绝对不会使现有的应用推倒重来，而是现有应用的面向Internet的一个延伸。
在本系列中，作者将从什么是Web服务，为什么需要Web服务开始，就Web服务的构建模式，结合一个实例，详细阐述了Web服务的架构过程。
本文所引用的资源主要包括两类，一类是Web服务的技术资源网站，包含了大量Web服务的技术信息，另一类是Web服务“stack"系列技术规范，他们是一个整体的技术体系，包括UDDI、SOAP、WSDL、XML等。本文的最后给出了这些资源的链接，有兴趣的读者可以通过这些资源链接找到所需的内容。
面临的挑战
我们知道，过去十年的对IT产业/COM的"疯狂投资"的时代已经过去了，那是一个实验的年代。而现在，整个业界跨入了务实的阶段，当今电子商务发展的重心已经完全从过去的.COM的模式转向到传统企业的电子商务化的进程中来。既然是企业的电子商务化，模式是否崭新是次要的，而是否能为企业带来经济利益则是主要的。在规划企业的电子商务应用的时候，企业管理人员和系统架构师更多的关注该电子商务应用是否能为企业带来直接的经济收益、是否有利于削减掉某方面的开支成本、是否能够优化资源使用，这些完完全全是由企业的商业利益驱动的，在这一轮的电子商务发展中，技术完全是为商业服务的，任何脱离商业需求的"新"技术则必然是毫无用武之地。
在IT投资锐减的日子里，系统架构师们小心翼翼、广泛考证，在对企业自身运作机制的务实的仔细调研中，总结出了一些(比较少量的，只有7种)当前最有价值进行实施的电子商务应用，它们是：
企业门户(Portal)：企业门户与一般信息门户有本质的区别，企业门户主要是为企业的重要客户、合作伙伴和自身的员工服务的。它应当具有个性化(这里的个性化并不仅仅是页面)，应当提供一系列的在线服务，使得客户、合作伙伴和员工们得以使用企业门户获得必要的知识/信息，得以通过企业门户与企业应用进行交互及事务处理。
网上连锁商店(Storefront)：为了拓展产品和服务的市场，拓广销售渠道以及增加销售额，企业应当建立具有自身品牌标识的网上连锁商店。这里需要注意的是，所谓网上连锁商店并不是说使用各种语言在各个国家分别建立网上商店，这只是其中的一个形式，更多的方式应当是将企业的网上商店能够加入到各种各样的网上实体中，比如门户网站、行业交易市场(e-Marketplace)、都市引擎等，使企业的销售渠道遍布整个Web空间。
集团内联网(Intranet)与知识库(Knowledge Base)：集团的全球内联网能够使企业的雇员可以在全球范围内进行有效的交流和协作，充分利用企业的全球资源，以提升整体的生产力。集团的知识库能够为员工的协作提供丰富有效的工作中所需要的知识，以最大可能地提高员工的单位产出。
供应链(Supply Chain)管理：为提升企业的整体竞争力，企业往往需要保持并提升自身与其供应商的关系，采取流水线形式的采购方式并尽量减少运作成本，而要做到这一点，则必须要创建私有的交易通道和供应链关系的电子商务应用才能达到这一目标。
客户服务(Customer Service)：通过建立这样的面向客户的服务门户或自助式销售网站能够实现跨区销售，提升客户的亲近程度和满意程度，并减少服务成本。
分销(Distribution)管理：建立分销管理应用能够使企业迅速地拓展分销渠道并挖掘新的市场机会。同时，企业还能裁减培训成本、服务成本和产品分销成本，并减少仓储费用。
提供ASP(Application Service Provider)服务：通过在Web上部署ASP服务，企业能够获得新的额外的收入。而提供的ASP中的A(Application)应当是企业核心竞争力的数字化表现，一般情况下，其范围可能就包含了前面提到的6种电子商务应用中的5种：企业门户、网上连锁商店、供应链管理、客户服务以及分销管理。
为了实施这些电子商务应用，不外乎几种手段：由自己的IT部门具体计划并实施，外包给软件公司或解决方案提供商计划并实施，当然解决方案或实施计划中可能会包含平台软件或专用软件模块的采购。然而，无论自身的IT部门还是外包的解决方案提供商，其给出的实施计划都是应用正式运营前的。一旦应用被部署之后，由于商务环境和商务需求的不断改进和不断变化，这些电子商务应用不可避免地需要被修订、需要被更新，以符合新的电子商务流程。而到最后，企业的管理人员甚至会想为企业的员工、客户以及合作伙伴分别定制具体应用以获得最大的商业利益并保持竞争力。
在这些应用更新的可能中，下面三个可能是最主要的也是最常发生的：
经常会增加新的电子商务应用，这常常会每几个星期或每几个月发生一次；
经常会对电子商务的流程进行更改，这常常每周或每几天发生一次；
经常应用户的需求而进行更改，这甚至每个小时都会发生，尤其是当需要为每个客户、每个合作伙伴或每个企业员工都定制其首选的电子商务应用的时候。
毫无疑问，e化的企业必须直面这一问题的挑战，经常的应用更新是当今电子商务应用部署所面临的最大问题，如何提升企业的响应能力，削减响应开支，提升企业的竞争力，是所有的e化企业必须面对的问题。
错误的解决方案: 复杂系统对接的解决方案
为了达到这一保持企业核心竞争力的目的，大部分企业都在努力奋斗着，毫无疑问他们在IT上投入了极多的资金和资源，那么他们的选择是否正确呢？在商务上，无疑是正确的，"没有电子商务将等于无商可务"，可是方法呢？他们采取了正确的方法了么？
让我们首先来看一看目前大多数企业是如何操作的？
目前，在构建前面我提到的那些电子商务应用的时候，程序员们一般都是采用"独立解决方案"来实施的。也就是说，对于每个应用，他们都是为每个需要的企业资源或外部资源编写连接代码，以使得应用得以运行。这些资源包括：传统系统(legacy systems)和数据库、Web应用及Web资源，以及正在不断涌现的Web服务。
程序员还需要编写更多的代码以使得大量的用户能够访问每个应用，例如通过公司的Web站点，例如使用公司内部的桌面应用程序等等。由于这些应用都是"辛苦"编程的产物，几乎很难再定制。当需要融入新的电子商务流程，需要为额外的用户群提供访问界面，需要继承不同的电子商务应用以为用户提供更完整的增值服务，所有的这一切不得不从最初的系统设计开始做起。为什么会这样？因为所有的应用都是从一次性开发的角度实施的，应用的没一个更改都需要由特定的程序员来完成。这样，通过跨应用集成的方式实现电子商务应用的重用变得异常地困难。
由于每个应用都有其自己特有的基础架构，这些应用在部署、更改和维护上的代价都异常高昂。企业不得不会每套应用配置特有的专业技术人员，并保持与不同技术供应商或解决方案供应商的密切联系。同时这些应用即不能被方便地继承，也不能随着企业商务的规模扩展而方便地实现应用的规模扩展。
我们很清楚地认识到，即使是只有一个电子商务应用，其创建、维护和定制的代价及复杂度就已经是如此惊人了。何况要涉及多个这样的应用，其代价之高是可象而知的。
让我们来考察当企业部署若干个这样的电子商务应用的情形：
第一个应用，企业的为之付出的总的费用应该是该应用的开发和部署费用、以及运营时态的维护和更新费用。
第二个应用，应用的开发和部署费用是一样的，但是企业需要为之花费额外的集成费用，同时由于整个企业应用环境变得更加复杂，其运营时态的维护和更新费用可能呈指数形式增加。
同样，当第三个、第四个应用被部署后，企业所支出的费用可能是高得惊人。
这样的电子商务应用的实际运营状况非但无法令企业商务规模迅速增长，甚至会造成相反的影响作用，因为此时，IT部门不得不雇佣更多的员工并花费更多的资金来管理这些复杂而纷乱的应用，并维护多种承载应用的基础架构。
早先出现的电子商务技术，比如EDI、web EDI (也许是基于XML的)、内容服务器、应用服务器、EAI(Enterprise Application Integration)，以及那些为创建企业门户以及其他单个电子商务应用(上面提到的7种应用)而设计的独立解决方案都无法解决这个问题。它们之所以无能为力，是因为它们不无例外地都是基于复杂应用连接的、不具备良好集成能力的应用开发模式，它们都是通过程序代码实现复杂应用连接以连接用户、电子商务应用以及其他信息系统的。这样的实现方式即无法有效地解决经常发生的电子商务流程的更改而触发的大额费用，也无法有效地解决各类用户的定制需求。
正确的解决方案: Web服务和商业Web
在本节中，我将描述一个能解决以上所有问题的解决办法。
电子商务需要摆脱独立解决方案的实现模式，需要舍弃复杂系统连接的实现方法。一个有效的电子商务应用绝对不应该是仅仅基于程序员以及那些复杂的代码的。对于电子商务而言，传统的由程序员主导的由里向外的开发模式应当被由用户主导的由外向里的开发模式取代。冗长的串行的开发循环应当被即时的，快速的应用装配所取代。同时这样的应用应当天生就具备高可定制性。如果探究其商业本质，这是来自经过时间考验的商业技术概念："即时制造"以及"规模可伸缩"等概念，我们需要做的就是将传统的商业概念延伸到电子商务中去。
看了上一段的描述，大家可能会认为这需要一个技术上的更本性变革，其实，不然。
基于XML技术的Web服务正是解决这一问题的最佳手段。Web服务的使用将改变目前的开发模式和应用部署的费用规模。各种Web服务分表实现了一定的电子商务功能，通过将各种电子商务的Web服务进行组合和集成以创建动态电子商务应用。Web服务能够统一地封装信息、行为、数据表现以及商务流程，而无需考虑应用所在的环境是使用何种系统和设备。
通过使用Web服务，企业能够以前所不可能的方式通过抽象和混合将自身的电子商务组件化。当一个企业的核心竞争力被组件化之后，那么这些核心竞争力就能够很方便地在不同的企业之间共享，同时架构跨企业的电子商务应用，形成商务Web。
在商务Web中，将不需要为使用一个电子商务应用而购买这个电子商务应用所承载的应用软件。Web服务是一种无需购买并部署的组件，这种组件是被一次部署到Internet中，然后到处可用的一种新型组件，所有应用只需要能够连入Internet，就可以使用和集成Web服务。通过采用Web服务，开发的代价显著降低了，程序员无需与多种平台进行交互，他只需要与一种组件进行交互，即Web服务，同时Web服务的调用界面完全采用标准的XML及相关技术，在代码实现上代价也有显著下降。通过采用Web服务，部署和集成的费用大大降低，流程的更改也无需更改大量代码，甚至通过工具的支持，更本无需更改程序代码。同时随着新的Web服务技术，如WSDL/UDDI/WSFL的大量使用，Web服务在运行时态进行动态装配将成为现实，同时每个用户甚至可以应用户的需要而实时装配。
Web服务是未来？
全球权威IT行业研究评论机构Gartner Group对未来5年的Web服务的发展状况做了预测：
2001年，Web服务的架构开发工具将被各大开放商开发完毕。开发人员能够购买到这些面向服务的开发工具。同时他们将会开始构建实际使用的Web服务。
2002年，商业Web服务将大量出现，大量的面向消费者的B2C Web服务将被使用。
2003年，UDDI注册中心应Web服务的发展，变得越来也重要，其中的商业数据也越来越丰富。私有的UDDI注册中心将被投入使用以支持内部的服务信息的交换。而政府的Web服务(e-Government)应用也将会不断出现。
2004年，各类企业将会普遍接受基于Web服务的商务应用模式，而服务集中的计算模式将会进入青年期。私有的UDDI注册中心仍然在各类应用中处与优势地位。新的收入模式和商业渠道将到处可见。40％的金融财务服务事务将使用Web服务模式。而35%的在线政府服务将以Web服务的形式提供。
2005年，公共的UDDI注册中心作为公共商务信息的交换机制而获得大量的使用。动态服务同样将大量投入使用。
同时我们看到各大技术提供商都按照Gartner Group的预测陆续地推出Web服务的构建工具：Microsoft的Visual Studio .NET，IBM的Web Service Toolkit，SUN的Sun ONE等等。基于Web Service的公共技术标准SOAP/WSDL/UDDI/WSFL或是已经成为事实行业标准，或是正在制订的进程中，各大技术提供商和传统商业企业都投入到了标准的制定和应用的架构中去。作为Web服务的体系架构的领导者IBM和Microsoft也开始在全球推广Web服务技术。我们有理由相信Web服务将成为将来动态商务Web的主流技术。
什么是Web服务?
我们已经从商业需求的角度和技术实现的可行性上讨论了Web服务的可行性和必要性。由于大部分的读者是技术人员，所以我相信大家对Web服务的各种实现技术会非常有兴趣，对Web服务的架构过程也一定更有兴趣，对如何在某个具体的Case中使用Web服务架构一定非常有兴趣，我将在本文章系列的后续部分中逐一描述并提供答案。
作者简介
柴晓路: 上海得易电子商务技术有限公司(DealEasy)首席系统架构师、XML技术顾问。UDDI-China.org主要核心成员。2000年获复旦大学计算机科学硕士学位，曾在国际计算机科学学术会议(ICSC)、亚太区XML技术研讨会(XML Asia/Pacific'99)、中国XML技术研讨会(北京)、计算机科学期刊等各类国际、国内重要会议与期刊上发表论文多篇。专长于基于XML的系统集成和数据交换的技术研究，同时对数据库、面向对象技术及CSCW等技术比较擅长。2001年加入UDDI Advisor Group，参与了UDDI Specification V2的开发。
扫一扫加微信
