Web Service 的基本概念

  •      WebSevice 让一个程序可以透明地调用互联网程序,不用管具体的实现细节。只要WebService公开了服务接口,远程客户端就可以调用服务。WebService是基于Http协议的组件服务,WebService是分散式应用程序的发展趋势。 WebService更多是一种标准,而不是一种具体的技术。不同的平台,不同的语言大都提供WebService的开发实现。在Java领域WebService常见的框架 Axis、XFire、CXF......。其中成熟实现的是AXIS。
  • webservice就是调用远程的java方法的技术。
    WebService是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求,轻量级的独立的
    通讯技术。它是:通过SOAP在Web上提供的软件服务,使用WSDL文件进行说明,并通过UDDI进行注册。
    Web Service是建立可互操作的分布式应用程序的技术平台,开发者可以使用自己喜欢的编程语言,在各
    种不同的操作系统平台上编写Web Service应用。

    Web Service的特点
    Web Service的主要目标是跨平台的可互操作性。为了实现这一目标,Web Service 完全基于XML、XSD(
    XML Schema)等独立于平台,是创建可互操作的、分布式应用程序的新平台。

    例如java的RMI也能进行远程通信调用,但是RMI能在java程序机制通讯,调用。而webservice则可以在任何语言的程序上通讯。
    SOAP、WSDL和UUID是Web Service的“三剑客”。
    Web Services 框架的核心技术包括SOAP(Simple Object Access Protocol,简单对象访问协议) ,WSDL(Web Services Description Lanuage,Web服务描述语言) 和UDDI(Universal Description,Discovery and Integration,通用描述,发现,集成) ,它们都是以标准的XML 文档的形式表述的。

    目前:
    XFire迅速成为Web Service开发框架中的闪亮新星,相比于其他Web Service框架(如Axis、GLUE等)

    xfire 的升级版本 cxf 现在是2.1 官网上例子很多。

    到了java6时代,在jdk中已经包含了wsgen和wsimport等命令,很容易发布和访问 webservice,无需依赖任何框架或者库了。

    什么是web service
        Web service是通过HTTP协议交流的客户和服务器。根据W3C的描述,web service提供了运行在不同的平台和框架上的软件之间的互操作的标准的方式。Web service的特点包括高度的互操作性和可扩展性,以及使用XML带来的可机器处理的描述。Web service可以以松散耦合的方式组合起来完成复杂的操作。提供简单的服务的程序和和其他的程序互动来提供复杂的有附加值的服务。

    Web Service的类型
        在概念上,一个服务就是一个由可以通过网络访问的端点提供的软件组件。服务的消费者和提供者使用消息来交换调用请求和自包含格式文档响应信息而很少考虑接收方技术上的能力。
        在技术上,web service可以以不同的方式实现。在本教程中讨论的两种方式可以称为“大”web service和“RESTful”web service。
    “大” Web Service
        在Java EE 6中,JAX-WS提供了“大”web service的功能,这种类型的web service在第12章“使用JAX-WS构建web service”中介绍。这种web service使用遵循SOAP(Simple Object Access Protocol)标准的XML消息。这样的系统通常包含一个机器可读的service提供的操作的描述,这个描述以Web Service Description Language(WSDL)写成。WSDL是定义结合和语法的XML语言。
        SOAP消息格式和WSDL接口定义语言是被广泛接受的。许多开发工具,如NetBeans IDE,能够减少开发web service应用程序的复杂性。
        一个基于SOAP的设计必须包含以下元素:
    • 必须建立一个正式的约定来描述web service提供的接口。WSDL能够用来描述约定的细节,包括消息、操作、绑定和web service的定位。在JAX-WS的service中也可以不发布WSDL而处理SOAP消息。
    • 架构必须能够满足复杂的非功能性的需求。很多web service的规范明确了这样的需求并且创建了通用的词汇,例如事务、安全性、寻址、信任、协调等。
    • 架构需要处理异步处理和调用。这种情况下,可以直接使用由标准(如Web Service Reliable Messaging,WSRM)和API(如JAX-WS)提供的基础设施以及它们对客户端的异步调用的支持。
    RESTful Web Services
        在Java EE 6中,JAX-RS提供了RESTful web service的功能。REST很适合基本的、特别集成的情况。RESTful web service通常比基于SOAP的service和HTTP集成的更好。RESTful的web service不需要XML message或WSDL的服务API定义。工程Jersey是JAX-RS规范的参考实现。Jersey实现支持JAX-RS规范定义的组件,使得开发人员能够容易的使用Java和JVM构建RESTful web service。
        因为RESTful web service使用了已经存在的广为人知的W3C和IETF(Internet Engineering Task Force)标准(HTTP,XML,URI,MIME)并且有轻量的基础设施允许使用很少的工具来构建service,开发RESTful web service是很代价很低的,因此接受的门槛很低。可以使用开发工具如NetBeans IDE来进一步减少开发RESTful web service的复杂性。
    当符合以下条件的时候一个RESTful的设计才是合适的:
    web service是完全无状态的。一个好的测试是考虑这个互动能否在服务器重启的时候存活。
    • 能够使用缓存来提高性能。如果web service返回的数据布署动态生成的并且能够被缓存,就可以使用web服务器或其他的中间件提供的缓存功能来提高性能。但是,开发人员应该小心,因为在大多数服务器上这样的缓存只对HTTP GET有效。
    • 服务的提供者和服务的消费者对传递的上下文和内容有共同的理解。因为没有正式的方式来描述service的接口,所以两方都必须就描述交换的数据的schema和处理这些数据的方式达成一致。在现实世界中,很多提供RESTful实现的service的商业应用程序也发布增值工具包,其中用流行的编程语言向开发人员描述了service的接口。
    • 带宽是特别重要的并且需要限制的。REST对配置有限的设备很有用,如PDA和手机。对这些设备,XML有效载荷之外的SOAP元素的headers和附加层必须要被限制。
        使用RESTful类型可以很容易的提交或聚合web service到已经存在的web站点。开发人员可以使用如JAX-RS和AJAX等技术及DWR(Direct Web Remoting)工具来在web应用程序中使用service。不需要从头开始,service可以提供XML,HTML页面可以直接使用而不需要对已经存在的web站点的架构做大的重构。开发人员的生产率会提高,因为他们可以使用已经熟悉的技术来添加新的东西而不是使用新的技术从头开始。
        RESTful web service会在第13章“使用JAX-RS构建RESTful web service”中讨论。该章中包括使用NetBeans IDE和Maven项目管理工具来生成RESTful web service骨架的信息。

    决定要使用哪种类型的Web Service
        基本上,在基于web的集成的情况下会使用RESTful web service,在有更高的服务质量要求的企业应用程序集成的情况下会使用“大”web service。
        JAX-WS:适合于更高的服务质量要求的情况,通常发生在企业计算中。和JAX-RS相比,JAX-WS使得支持WS-*系列的协议更加容易,这些协议提供了安全性、可靠性以及和其他的WS-*兼容的客户和服务器互操作等的标准。
        JAX-RS:可以更容易的编写应用了部分或全部的REST风格的限制来引入希望的特性的web应用程序。这些特性包括松散耦合(可以很容易的进化服务端而不影响已经存在的客户端),可扩展性和架构简化(使用现成的组件,例如代理或HTTP路由器)。在web应用程序中应该选择JAX-RS,因为RESTful web service易于被多种类型的客户消费,同时使得服务器端能够进化和扩展。客户端可以选择使用部分或全部的service并将其和其他的基于web的service一起使用。

猜你喜欢

转载自wanghaopk.iteye.com/blog/1123445