Web Service_legado web service是干嘛的

核心定义

考虑到并没某个独立文档包含一切相关内容，可采用模块化的方式给出对WEB服务的描述，但不能给出一个“绝对全面和准确”的定义。受外部环境和实现技术影响，各方给出的核心定义可能稍有出入，但通常包括：

SOAP

一个基于XML的可扩展消息信封格式，需同时绑定一个传输用协议。这个协议通常是HTTP或HTTPS，但也可能是SMTP或XMPP。

WSDL

一个XML格式文档，用以描述服务端口访问方式和使用协议的细节。通常用来辅助生成服务器和客户端代码及配置信息。

UDDI

一个用来发布和搜索WEB服务的协议，应用程序可借由此协议在设计或运行时找到目标WEB服务。

这些标准由这些组织制订：W3C负责XML、SOAP及WSDL;OASIS负责UDDI。^[1]

协议集合

为提高WEB服务间的互操作能力，WS-I还特别发布了WEB服务协议集(Profile)。协议集包含了一系列特定版本的核心定义(诸如SOAP和WSDL)，以及对其使用上的限制与约束。WS-I还发布了用于部署协议集兼容WEB服务的测试工具及相关用例。

追加定义

Web Service案例架构图为扩展WEB服务能力，一些新的标准已经或正在被开发。这些标准通常被冠以WS字头(Web Service的简称)，以下是一个WS系列追加标准的不完全列表：

WS安全(WS-Security)

定义了如何在SOAP中使用XML加密或XML签名来保护消息传递。可作为HTTPS保护的一种替代或扩充。

WS信赖性(WS-Reliability)

一个来自OASIS的标准协议，用来提供可信赖的WEB服务间消息传递。

WS可信赖消息(WS-ReliableMessaging)

同样是一个提供信赖消息的协议，由Microsoft, BEA 和IBM发布。OASIS正对其实施标准化工作。

WS寻址(WS-Addressing)

定义了在SOAP消息内描述发送/接收方地址的方式。

WS事务(WS-Transaction)

定义事务处理方式。

一直以来，W3C负责制定了不少WS追加定义，但近来此举开始受到怀疑。一些人呼吁W3C作为网络和语义网构建者应当把精力放在核心网络本身，而不是为WEB服务改换版本。特别是2007年2月的企业级WEB服务论坛上，对W3C不再充当WEB服务定义者的诉求开始表面化。 此外，OASIS对WEB服务扩展实施了许多标准化工作。包括WEB服务资源框架以及WSDM。

web广泛用到的技术：

TCP/IP：通用网络协议，被各种设备使用

HTML：通用用户界面，可以使用HTML标签显示数据

Java：写一次可以在任何系统运行的通用编程语言，因为java具有跨平台特性

XML ：通用数据表达语言，在web上传送结构化数据的容易方法

他们的特点是其开放性，跨平台性，开放性正是Web services的基础。

WEB服务实际上是一组工具，并有多种不同的方法调用之。三种最普遍的手段是：远程过程调用(RPC)，面向服务架构(SOA)以及表述性状态转移(REST)。^[2]

远程过程调用

WEB服务提供一个分布式函数或方法接口供用户调用，这是一种比较传统的方式。通常，在WSDL中对RPC接口进行定义(类似于早期的XML-RPC)。

尽管最初的WEB服务广泛采用RPC方式部署，但针对其过于紧密之耦合性的批评声也随之不断。这是因为RPC式WEB服务实质上是利用一个简单的映射，以把用户请求直接转化成为一个特定语言编写的函数或方法。如今，多数服务提供商认定此种方式在未来将难有作为，在他们的推动下，WS-I基本协议集(WS-I Basic Profile)已不再支持远程过程调用。

服务导向架构

现在，业界比较关注的是遵从服务导向架构(Service-oriented architecture，SOA)概念来构筑WEB服务。在服务导向架构中，通讯由消息驱动，而不再是某个动作(方法调用)。这种WEB服务也被称作面向消息的服务。

SOA式WEB服务得到了大部分主要软件供应商以及业界专家的支持和肯定。作为与RPC方式的最大差别，SOA方式更加关注如何去连接服务而不是去特定某个实现的细节。WSDL定义了联络服务的必要内容。

表述性状态转移

表述性状态转移式(Representational state transfer，REST)WEB服务类似于HTTP或其他类似协议，它们把接口限定在一组广为人知的标准动作中(比如HTTP的GET、PUT、DELETE)以供调用。此类WEB服务关注与那些稳定的资源的互动，而不是消息或动作。

此种服务可以通过WSDL来描述SOAP消息内容，通过HTTP限定动作接口;或者完全在SOAP中对动作进行抽象。

Web Service框架图Web Service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web Service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。目前这些协议有：

XML和XSD

可扩展的标记语言XML是Web Service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既与平台无关，又与厂商无关。XML是由万维网协会(W3C)创建，W3C制定的XML SchemaXSD　定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。

Web Service平台是用XSD来作为数据类型系统的。当你用某种语言如VB. NET或C#　来构造一个Web Service时，为了符合Web Service标准，所有你使用的数据类型都必须被转换为XSD类型。如想让它使用在不同平台和不同软件的不同组织间传递，还需要用某种东西将它包装起来。这种东西就是一种协议，如 SOAP。

SOAP

SOAP即简单对象访问协议(Simple Object Access Protocol)，它是用于交换XML编码信息的轻量级协议。它有三个主要方面：XML-envelope为描述信息内容和如何处理内容定义了框架，将程序对象编码成为XML对象的规则，执行远程过程调用(RPC)的约定。SOAP可以运行在任何其他传输协议上。例如，你可以使用 SMTP，即因特网电子邮件协议来传递SOAP消息，这可是很有诱惑力的。在传输层之间的头是不同的，但XML有效负载保持相同。

Web Service 希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用，打破了软件应用、网站和各种设备之间的格格不入的状态，实现“基于Web无缝集成”的目标。

WSDL

Web Service描述语言WSDL　就是用机器能阅读的方式提供的一个正式描述文档而基于XML的语言，用于描述Web Service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的。

UDDI

UDDI 的分层 Web 服务协议栈UDDI 的目的是为电子商务建立标准；UDDI是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web Service注册，以使别的企业能够发现的访问协议的实现标准。

调用RPC与消息传递

Web Service本身其实是在实现应用程序间的通信。现在有两种应用程序通信的方法：RPC远程过程调用　和消息传递。使用RPC的时候，客户端的概念是调用服务器上的远程过程，通常方式为实例化一个远程对象并调用其方法和属性。RPC系统试图达到一种位置上的透明性：服务器暴露出远程对象的接口，而客户端就好像在本地使用的这些对象的接口一样，这样就隐藏了底层的信息，客户端也就根本不需要知道对象是在哪台机器上。^[3]

操作系统离不开丰富的应用软件的支持。同样，Web Service这项技术只有通过日益广泛的应用才能体现出其价值，目前比较流行的实现方法是使用.NET 和 Java两种技术，并且两种实现方法可以互相操作；如今已经可以看到使用微软、Oracle、SUN、Borland等不同厂商的Web Service构建工具建立的Web Service应用。

微软.NET

微软的.NET技术应该算是时下最为流行的Web Service 开发技术。首先因为其公司在以前相应的产品就占有相当大的市场份额，以至使新推出的.NET得以有比较稳定的用户群；其次也是更重要的是 .NET平台不仅延续了微软一贯的编程风格，而且还增加了许多支持Web 服务的关键性技术，使得.NET在操作的简单性和执行的稳定性，高效性上达到了一个非常好的结合。

微软的Visual Studio. NET便是一个便于 Web 服务的开发工具。微软的目标是，将其新编程语言——C#作为Web Service的首选语言。虽然C#看起来与Java类似，但是还有一些Java中没有的独特的功能。.NET技术中用于Web Service 开发的主要工具是ASP. NET。从技术上说，ASP. net　 提供了一些超出ASP以前版本的优点(例如：代码和HTML的分离，与脚本语言相比较，对“真正”的编程语言如 C# 的支持)。

IBM的WebSphere

XML Web服务结构体系IBM公司是业界第一家能够提供全面支持Web服务的电子商务基础设施中间件的公司。通过多年来与W3C(The World Wide Web Consortium)的共同努力，包括DB2、Lotus、Tivoli 和WebSphere在内的所有IBM软件都实现了对SOAP、WSDL、UDDI、Linux、XML、J2EE等开放技术和标准的全面支持。

IBM公司的WebSphere也是比较好的基础架构软件开发平台。WebSphere软件平台及开发工具包括WebSphere Studio Application DeveloperWSAD　 基于J2EE、XML 和Web服务等开放标准，并具备 IBM 在可靠性、扩展性和安全性上的主要优势。WebSphere 是 IBM 在 Web Services策略中的核心平台，它支持所有开发、发布、部署 Web Services应用所必需的开放标准和技术，包括 UDDI，SOAP，J2EE，WSDL，和对 XML 技术集成的增强，这特使得它在全球有很多用户。

Borland的JBuilder

Borland公司在 JBuilder7中，用户可以用其Borland Web Services Kit for Java和Borland JBuilder MobileSet 3进行更快捷地开发Web Service和无线应用。这样将使开发者能够在同一个开发环境中轻松地创建和集成Web Service。新推出的JBuidler8更是针对Web Service开发更提供了方便和高效的方法。

总之，在Web Service开发上，.NET 和Java都是很好的选择，尽管两者现在都有一些需要完善的地方，但是就目前来说，它们还是最好的开发手段和技术。具体选择哪种开发工具，也是仁者见仁，智者见智的问题。从根本上说，这两种方法没有孰优孰劣的问题，只是根据使用者对这两种方法的掌握程度和对具体语言的偏爱程度来决定。

研究一下当前的应用程序开发，你会发现一个绝对的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。

传统的Windows客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的工作，同时也是许多IT工程师的噩梦。事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个DCOM。在我看来，结果就是一个发布容易，但开发难度大而且用户界面极其受限的应用程序。极端的说，就是你花了更多的资金和时间，却开发出从用户看来功能更弱的应用程序。不信？问问你的会计师对新的基于浏览器的会计软件有什么想法：绝大多数商用程序用户希望使用更加友好的Windows用户界面。

关于客户端与服务器的通信问题，一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时，当前许多防火墙也配置为只允许HTTP连接。

许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或.NET语言写的，并且都运行在Windows平台上，那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBOL语言编写的大型机程序访问。而且，目前还有很多商用程序继续在使用C++、Java、Visual Basic和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的"高级程序到程序交流(APPC)"等来完成的。在以前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。只有通过Web Service，客户端和服务器才能够自由的用HTTP进行通信，不论两个程序的平台和编程语言是什么。

什么是Web Service

Web Service工作模型图对这个问题，至少有两种答案。从表面上看，Web service 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。通常把调用这个Web service 的应用程序叫做客户。例如，你想创建一个Web service ，它的作用是返回当前的天气情况。那么你可以建立一个ASP页面，它接受邮政编码作为查询字符串，然后返回一个由逗号隔开的字符串，包含了当前的气温和天气。要调用这个ASP页面，客户端需要发送下面的这个HTTP GET

返回的数据就应该是这样：

21

这个ASP页面就应该可以算作是Web service 了。因为它基于HTTP GET请求，暴露出了一个可以通过Web调用的API。当然，Web service 还有更多的东西。

下面是对Web service 更精确的解释： Web services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术，但是也很容易举出COM并不能满足要求的情况。

Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要可以通过Web service标准对这些服务进行查询和访问。

新平台

Web service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面(interface)的平台提供了一些方法来描述界面、方法和参数（译注：如COM和COBAR中的IDL语言）。同样的，Web service平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。最后，还必须有一种方法来对这个Web service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。

适合使用Web Services的情况

（1）跨越防火墙；

（2）应用程序集成；

（3）B2B集成；

（4）软件重用

不适合使用Web服务的情况

（1）单机应用程序；

（2）局域网上的同构应用程序

j2ee的Web ServiceWeb服务是建立在一些通用协议的基础上，如HTTP，SOAP，XML，WSDL，UDDI等。这些协议在涉及到操作系统、对象模型和编程语言的选择时，没有任何倾向，因此将会有很强的生命力。但具体到Web服务编程时，.NET和J2EE有一些区别。.NET Web服务可用C#，VB，JScript等语言编写，还能利用一些Windows资源;而J2EE Web服务一般使用JAVA语言及J2EE资源，像Bean，EJB，CORBA等。它们在编程环境，语法结构，管理配置等方面也各有自己的特色。iNET Web服务用JAVA语言实现了.NET 类库中提供的Web服务APIs。它能把用户用.NET开发的Web服务移植到与平台无关的JAVA。因是JAVA，故也可利用JAVA的资源。

上述的这些趋势意味着，更加智能的处理，操作和汇总内容变得十分重要。按照Web services角度所预示的四个趋势：

内容更加动态：一个web service必须能合并从多个不同来源的内容，可以包括股票，天气，新闻等，在传统环境中的内容，如存货水平，购物订单或者目录信息等，都从后端系统而来

带宽更加便宜：web services可以分发各种类型的内容(音频，视频流等)

存储更便宜: web services必须能聪明地处理大量数据，意味着要使用数据库，LDAP目录，缓冲，和负载平衡软件等技术保持可扩展能力

普遍式计算更重要：web services不能要求客户使用某一版本的windows的传统浏览器，必须支持各种设备，平台，浏览器类型，各种内容类型。

要达到这样的目标，Web services要使用两种技术：

XML

XML是在web上传送结构化数据的伟大方式，Web services要以一种可靠的自动的方式操作数据，HTML不会满足要求，而XML可以使web services十分方便的处理数据，它的内容与表示的分离十分理想

SOAP

SOAP使用XML消息调用远程方法，这样web services可以通过HTTP协议的post和get方法与远程机器交互，而且，SOAP更加健壮和灵活易用。

其他象UDDI和WSDL技术与XML和SOAP技术紧密结合用于服务发现。

无论是在WEB服务出现以前，还是现在，一直不断有各种同类技术问世。比如，RMI作为这样一种中间件系统就得到了广泛部署。CORBA和DCOM则更加雄心壮志，两者都尝试将作用域波及到分布式对象，这一点也为WEB服务所模仿。

这些类似方式往往借助于XML-RPC和HTTP本身，而不依靠SOAP封装参数。