深蓝海域KMPRO

架构Web Service: 为什么需要Web服务?

2017-04-11 17:05

本文是架构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种)当前最有价值进行实施的电子商务应用，它们是：

为了实施这些电子商务应用，不外乎几种手段：由自己的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服务的发展状况做了预测：

同时我们看到各大技术提供商都按照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服务架构一定非常有兴趣，我将在本文章系列的后续部分中逐一描述并提供答案。

 

参考资料

 

相关推荐