为了使得一个公司的网络应用达到最高的效率,存在它自己和它的合作伙伴,供应商以及客户之间的Webservice,应该能够实现无缝的交互。如果在众多的Webservice之间不能轻松的实现交互,那么该应用的效率将大打折扣。但是,在现实中这种情况是极有可能出现的。由于各个公司对业务的理解各不相同,就是理解相同的情况下,对于相同的概念也可能用不同的形式加以表现,具体而言就是对于同一数据可能采取不同的xml表示。由于以上的原因,对于协同性的问题应该在设计应用架构时就加以考虑,而不是留待以后去改变。
Webservice 主要由以下几块技术所构成,SOAP (Simple Object Access Protocol), WSDL (Web service Description Language), 以及UDDI (Universal Description, Discovery and Integration)。
在这里我们不会去详细研究这些技术,而是揭示他们的一些重要特性,这些特性需要在Webservice的设计时详加考虑。
WSDL是实现协同能力的关键,它提供了一份契约用于与新老的应用之间交互。这项技术使得各个组织可以将标准的制定集中在Service的外部接口,而不用考虑各组织的具体实现。简而言之,它实现了Webservice的接口与实现的分离。从而使得标准的制定,更加容易。并且,基于这份接口描述,很多工具可以从中自动生成客户端代码,减少了开发者的工作量,并使得大部分开发者摆脱了编写SOAP消息传递代码过程。
SOAP是实现在各个Webservice组件之间传递消息的传输层。因此,SOAP应该是一项透明的协同技术。但是,由于很多的SOAP实现方法却与标准背道而驰,要么添加了新的扩展功能要么删减了一些标准功能。由于对SOAP标准的支持程度不同,使得Webservice的协同能力大打折扣,实现协同的困难加大了。基于这种情况,当开发者需要Webservice运行在不同平台上时,就要对具体情况加以了解并相应的编码以解决这种不一致性。如果所有的SOAP实现组织都能够遵循标准的话,那么Webservice的开发者就不需要考虑使用该Webservice的底层平台了。
尽管如此,不同SOAP实现的协同还是相当困难,因为协同标准的制定存在大量的分歧,目前一些组织正致力于标准的制定,比如
SOAP Builders 和
WS-I。然而,现在Webservice开发者只有针对不同平台,给予不同的实现,使得开发的成本和负担加大了。
l 理解传输模型
SOAP并不是完全透明的解决方案,它把一些复杂的实现细节隐藏起来。Webservice的开发者必须深入的了解SOAP,了解底层的传输机制以及模型,从而知道SOAP是如何实现的。在一些简单的应用中,某些工具可以帮助Webservice的开发者生成SOAP消息传递的代码,但是这只在最简单的应用中有效。真正的情况不可能那么简单,可能在某些方面你需要有特殊的处理(这种情况在实际开发中是很常见的),这个时候,你就需要直接操纵SOAP的消息传递代码,以及一些底层的XML内容。因此,Webservice的开发者需要深入了解SOAP和XML层的内容。
在开发Webservice的接口的时候,不要以为使用XML技术,协作性的问题就迎刃而解了,XML并不是解决集成问题的灵丹妙药。这里同样需要标准的制定,需要一个在业界公认的词汇表。仅仅在你的设计框架中引入XML技术并不能保证系统具有协同性,XML仅仅是用来描述数据的语言,XML自己并不提供语义去理解数据。就如同英语和德语都使用拉丁字母,但是他们的语义却并不相同。
即使你使用相同的语言,也不能保证具有良好的协作性。比如你的公司可能使用Order描述一个订单,但你的合作伙伴可能使用Purchase_Order,而另一个伙伴可能又不相同。你不可能强迫你所有的合作伙伴都采用和你相同的词汇。因此需要有一项技术可以在众多的描述之间充当翻译的角色。XSLT就是这么一种技术,它用于不同语言的转换。和XSLT的配合使用XML才能解决协同性的问题。
l DOM vs. SAX
许多的Webservice开发环境,将开发者从底层的XML文档的解析和处理中解放出来,他们提供了自动化或者很方便的工具,使得这一过程变得很简单。但是对于一些有特殊要求的Webservice应用,比如需要更好的柔性或者对速度要求特别高的应用,就需要手工处理XML文档。这时候两种XML解析的模型-DOM 和SAX的选择,将成为重要的问题。
DOM使用树状图的方式解析XML文档,而SAX则更多的采用事件驱动的模型。
DOM先将XML文档映射成一颗树,然后通过采用一系列与树相关的操作去处理这份文档。这种方法有很多的好处,首先开发者很容易理解,使用一颗树这对于开发者来说是最常见不过的了。DOM最常用于XML在Service中需要频繁修改的场合。当然DOM也有它的缺点,在处理XML文档的时候,它需要载入整个文档,而不管你需要修改的是否只是其中的一小部分。因此它的运行效率以及对内存的使用显然是不能接受的,尤其是面对很大的XML文档。
SAX使用事件驱动的模型来处理XML文档。通过一系列事件的触发,来完成对XML的解析,你可以只关心你所要处理的事件,当这些事件发生时,会调用到相应的回调函数来通知到你。采用这种方式就可以在很大程度上提高XML文档解析的效率。但是它的缺点在于难于使用,以及对同一文档的多次处理会存在一些问题。
总而言之,DOM更适合处理那种文档型的XML文件,而SAX则适于那种想直接将XML结构映射成在你系统中的一个对象的操作。(比如将一个XML结构直接映射成JAVA中的一个Class)或者那种针对XML文件中特殊Tag的操作。
l 文档交换vs. RPC模型
这两种交互方式应该在应用架构的设计初始就应该详加考虑,因为它将在很大程度上决定系统的耦合程度。
RPC(Remote Procedure Call)本质上就是远程方法的调用。尽管Webservice是基于XML的但是你仍然可以使用远程方法调用这种模式来进行Webservice的实现,尤其是在那种简单的请求相应的模型中。在这个过程中,传输中的XML文件所描述的更多是有关远程方法的信息,比如方法名,方法参数等等。
而文档交换方式,与RPC相比较在XML文件中不是做远程方法的映射,而是一份完整的自包含的业务文档,当Service端收到这份文档后,先进行预处理(比如词汇的翻译和映射),然后再构造出返回消息。这个构造返回消息的过程中,往往不再是简简单单的一个方法调用,而是多个对象协同完成一个事务的处理,再将结果返回。
这两种方式的区别,类似与打电话和发邮件的不同处理方法。在目前,对于第一种方法提供了很多自动化的工具使得远程方法的调用能够很容易的完成,而后一种方法缺少一系列工具的支持,需要开发者手工完成。
尽管如此,在此还是推荐使用文档交换的方式。由于它在以下方面具有RPC所不具备的优点。
使用文档方式,你可以充分利用XML文件的功能去描述和验证一份业务文档,而在RPC模型中XML仅仅被用于描述方法的信息。
使用文档方式,在客户的Service的提供者之间不再需要紧密的约定,而RPC模型需要客户和Service的提供者紧密相连,一旦方法发生变化,客户端就需要做相应的改动。这不符合低耦合系统的要求,而在文档交换方式中则灵活的多。
由于业务数据是自包含的,显然文档模型更利于采用异步处理。
l 利用设计模式
设计模式在设计Webservice的时候显然可以起到相当大的作用。设计模式的主要目的就是为解决某些在类似环境下的相像问题提供已有的较为成熟的设计方案。在这里,只简单的提及一些很常用的模式,让我们了解到模式在Webservice中可以起到的作用。
Adapter :为内部系统提供一个不同的接口
Façade: 封装复杂的内部实现,提供一系列简单的接口
Proxy: 作为其他对象的代理,代替它提供服务
Adapter模式用于将一个组件的接口转化成客户所需要的样子,这里的客户就是Webservice。一个常见的情况就是将原有的老的系统包装成一个Webservice。比如现在使用的是J2EE的平台,而原来有一个C++的系统实现了某些功能,现在需要将它发布成Webservice,那么就需要利用JNI技术做一个Adapter,为原来的C++组件提供一个Java的接口,然后再转化为Webservice。
Façade模式用于构建粗粒度的服务,它包装了细粒度的服务,从而为复杂的系统提供了一个简单的接口。在J2EE中,Session Bean就象是一个Façade,而Entity Bean则是细粒度的服务。在Webservice中也一样,使用Façade模式可以将已有的组件的功能发挥殆尽。
Proxy 模式用于充当其他对象的代理,类似于中间人的作用,将处理工作从一个对象传递到另一个对象。在Webservice中,它主要用于隐藏Soap消息构造的过程。也可以用于模拟对象(Mock Object)的创建。
以上仅仅是一些可以用于Webservice开发的模式,如果你熟练的将这些模式应用于Webservice开发,你将会发现开发Webservice应用,将好像做一种特殊的面向对象设计。
l 安全
Webservice为作为方便的服务被用广大领域使用的同时,也成为了黑客们的美食。在这里,本文将就目前对Webservice安全所能做的改进做简单介绍。
在Webservice中的安全主要分为以下三个方面。
传输 SSL/HTTPS 对连接加密,而不是传输数据
消息 数据加密(XML Encryption) 数字签名(XML-DSIG)
底层架构 利用应用服务安全机制
传输时的安全是最容易被加入到你的Webservice应用中的,利用现有的SSL 和HTTPS协议,就可以很容易的获得连接过程中的安全。
然而这种安全实现方法有两个弱点。一是它只能保证数据传输的安全,而不是数据本身的安全,数据一旦到达某地,那么就可以被任何人所查看。而在Webservice中,一份数据可能到达多个地方,而这份数据却不该被所有的接受者所查看。二是它提供的是要么全有要么全无的保护,你不能选择哪部分数据要被保护,而这种可选择性也是在Webservice中所常要用到的。
第二层的保护是对于消息本身的保护。你可以使用已有的XML安全扩展标准,实现数字签名的功能,从而保证你的消息是来自特定方并没有被修改过。XML文件的加密技术从更大程度上加强了Webservice的安全,它能够定制数据传输到后,能否被接受者所查看,进一步完善了传输后的安全,业界也在不断的制定Webservice的安全标准,比如SAML 和 WS-Security。
最后一层保护就是依靠底层架构的安全,这更多的来自于操作系统和某些中间件的保护。比如在J2EE中,主持Webservice的应用服务器。目前很多的J2EE应用服务器都支持Java Authentication and Authorization Service (JAAS),这是最近被加入到J2SE 1.4当中的。利用主持Webservice的服务器,实现一些安全机制这是很自然的做法。另一种利用底层架构的安全方法就是,做一个独立的负责安全的服务器,Webservice的使用者和创建者都需要与之取得安全信任。
相关推荐
### WebService的运行模式和UDDI信息发布 #### WebService体系结构 WebService作为一种分布式计算模型,在互联网上提供了标准的方法来让不同的应用系统相互通信。本文档从WebService的基础架构出发,深入探讨了...
例如,可以采用以下设计模式: - **Document Processor**:处理文档或消息的服务,将复杂的业务逻辑封装在处理过程中,确保服务接口简洁。 - **Idempotent Message**:幂等消息模式,确保即使同一消息多次发送,...
本文档将详细介绍Webservice安全性的关键概念、应用场景、设计模式及实现指南,主要针对Web Services Enhancements (WSE) 3.0版本。 #### 二、常见场景 在讨论具体的实现细节之前,我们先来看一些常见的Webservice...
在WinForm应用程序中调用WebService是一项常见的任务,它允许客户端应用程序与远程服务器上的服务进行交互,从而实现...这种设计模式使得WinForm应用能够灵活地利用Web服务提供的各种功能,而无需关心底层实现细节。
本课程设计旨在通过C#与ASP.NET技术,实现一个基于Web Service模式的天气预报查询系统。系统的主要功能包括允许用户选择想要查询天气预报的城市,并返回相应的天气信息。此设计不仅涉及到Web Service的基本原理与...
这种设计模式使得应用程序可以脱离具体的后端实现,只关注于用户界面和业务逻辑,而后端服务则负责处理数据存储、计算等任务。这样既提高了代码的复用性,也降低了维护成本。 首先,我们需要理解WebService的基本...
Java电子书集合涵盖了一系列核心的IT技术主题,包括XPath、Web服务、DOM4J库、SQL和设计模式。这些主题都是软件开发中的基础且至关重要的部分,尤其在Java编程环境中。 1. XPath(XML Path Language):XPath是用于...
WebService是一种基于开放标准的互联网通信协议,它允许不同的系统和服务之间进行交互,无论它们使用何种操作系统或编程语言。这种技术的核心在于它提供了API(应用程序接口),使得应用程序能够通过Web调用远程服务...
"可進行後期改動滿足自己想要功能"这部分表示,虽然这个工具类已经实现了基本的WebService调用功能,但其设计是灵活的,允许开发者根据实际需求进行扩展和修改。这表明,源代码可能包含了一些可配置的参数或者预留了...
这种设计模式的关键在于其服务之间的交互是基于中立的标准或协议进行的,这意味着服务接口的设计应当独立于具体的硬件平台、操作系统和编程语言。SOA的主要目的是提高系统的灵活性和复用性。 #### WebService作为...
除了SOAP,还有另一种常见的API设计模式——RESTful。REST(Representational State Transfer)强调资源的表述和状态转换,通常使用HTTP协议,更加简洁和易于理解和使用。虽然RESTful API在某些场景下更受欢迎,但...
* XSD(XML Schema Definition):是一种基于XML的模式语言,用于描述XML文档的结构和约束。 * SOAP(Simple Object Access Protocol):是一种基于XML的协议,用于实现远程过程调用和消息传递。 * UDDI(Universal ...
SOAP Web服务和RESTful Web服务是两种常见的Web服务交互方式,它们在设计理念、协议复杂度、数据格式和操作方式等方面存在显著的区别。 首先,SOAP(简单对象访问协议)是一种基于XML的协议,它允许不同系统之间的...
本资源提供的"完整的webservice架构源代码"是一个可以直接运行的Web服务示例,对于理解Web服务的工作原理以及开发实践具有很高的参考价值。 在Web服务中,SOAP(Simple Object Access Protocol)是主要的消息协议,...
在文件列表中提到的"WebService"可能包含了关于这些技术的具体文档,比如SOAP和WSDL的教程、RESTful API设计指南、具体的WebService框架(如Apache CXF、Java JAX-WS、.NET WCF)的使用手册,以及可能的示例项目代码...
### 基于SVG和WebService的WebGIS系统设计 #### 摘要 本文深入探讨了基于SVG(可缩放矢量图形)和WebService技术构建WebGIS(Web地理信息系统)系统的方法。该系统的设计理念源自Google Maps的成功模式,并在此...
MVC是一种设计模式,它将应用程序分为三个主要部分:模型(Model)、视图(View)和控制器(Controller)。模型负责业务逻辑,视图呈现数据,而控制器处理用户交互并协调模型和视图。 2. **JavaScript在MVC中的...
通过阅读源码,可以深入理解.NET中WebService的工作原理和设计模式。 8. **客户端调用** - .NET提供了许多类库用于调用WebService,如System.Web.Services.Protocols.SoapHttpClientProtocol,或者更现代的...