课设实验报告之web服务描述文档-服务建模研究-组成部分-问题描述-难点-解决方案

实验报告

一、课题内容和要求
1、自动生成多个web服务描述文档，用wsdl描述，服务类型尽可能多。
2、启动多个WEB服务目录服务器进程，进程数目可设置。
3、将自动生成的WEB服务发布到目录服务器中。

两份报告：研究报告，实验报告
研究报告包含内容：
（1）概述
（2）问题描述
（3）技术难点
（4）关键技术
（5）解决方案
（6）为什么采用这种方案
（7）优缺点分析、性能分析
实验报告包含内容：
（1）课题内容和要求
（2）需求分析
（3）概要设计
（4）代码
（5）测试
（6）总结

二、需求分析
　向别人介绍你的Webservice有什么功能，以及每个函数调用时的参数的时候，可能会自己写一套文档，甚至可能会口头上告诉需要使用你的Webservice的人。然而，这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Webservice的时候，他们的工具(如VisualStudio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Webservice。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Webservice描述语言(WSDL)就是这样一个基于XML的语言，用于描述Webservice及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的Webservice生成WSDL文档，又能导入WSDL文档，生成调用相应Webservice的代码。
　
三、概要设计
从客户端的观点来看，这两个服务实现构成了一个”虚拟的”服务。如果承担设计新解决方案的任务，则首先想到的可能是为新服务创建一个全新的服务协定(WSDL文件)，以便导人为GetWeather服务定义的架构。遗憾的是，使用该技术将意味着当前的NET工具会将这两个WebnE务视为完全不同的实体。当使VisualStudio。NET或WSDL。exe来为这两个web服务创建代理时。每个代理都将具有它自己的针对”Current Weather”消息的对象表示。这些类将完全相同，并且将被序列化和反序列化为完全相同的XML结构。实际上。可以使用XmlSerializer将一个类的实例序列化为文档，然后成功地将同一文档反序列化为另一个类的实例。但是，从运行库的角度来看，这两个类是不同的命名空间中恰好具有相同名称的不同托管类。既然如此，那么从对Get Weather代理对象的方法的调用中返回的对象实例就不能传递给CalculateChanceOfRain代理的方法。它们在托管世界中是不同的类，就像SystemWindowsForms。Buton和SystemWebUIWebControlsButon是不同的类一样。这意味着只能在不同类的实例之间复制值，或者手动编辑由工具生成的代理代码。如果消息不是非常巨大的话，那么在字段之间复制数据可能不会造成多么大的性能差异。但这一定是可以避免的一项额外的维护任务。如果决定手动更改代理，则必须移除两个表示常见XML消息的类之一，并且对那个被移除表示的代理重新进行编码，以使用另一个代理的类。也就是说，每当创建对服务的新Web引用时。都必须重新实现这些更改。在我看来，这些解决方案都不是特别理想。因为它们使客户端开发人员必须在服务之间实施消息的概念性共享，从而增加了他们的负担。
通过创建带有针对每个实现服务的binding的单个接口，可以获得某种级别的封装。以显式定义两个服务实现之间至今存在的隐式关系。与只是具有一个GetWeather服务和一个caIcuIatechanceOfRain服务不同，可以公开一个包含这两组行为的虚拟weatherseces服务。还可以让使用的WebfiE务工具创建这两个服务共有的数据类型的单个类表示。让我们考察一下如何创建包含这两个服务的binding的服务说明。
创建WeatherServicesWSDL创建新服务说明的第一步是确定将要传递给新的caIcuIatechanceOfRain服务的消息。正如我先前已经讨论过的那样，作为输入传递给新Web服务的消息将是由Yasser的GetWeather服务返回的相同CurentWeather元素。
在CurrentWeather元素包含一些子元素。定义了消息之后，可以创建新的服务接口。与从头创建新的WSDL文件不同，只需要修改由负责GetWeather服务的团队创建的WSDL文件。
要创建新的服务接口，需要将WeatherlnterfaceWSdI的内容复制到一个新的文件中。然后，需要将新的RainServiceMesages架构的命名空间添加到新WSDL文件中的定义元素中。接下来，添加一个使用CurrentWeather元素作为其数据部件的请求消息，以及一个使用新的CalculateChanceOfRainResponse元素的响应消息。还需要为新的服务向WSDL文件中添加一个port和一个binding。

3.1 创建服务实现

现在，需要创建服务实现。
第一个步骤是创建一个新的Web服务项目。该类应用WebServiceAttribute。以便设置将由该服务使用的命名空间。这并非严格需要。因为基础结构将默认使用tempuriorg命名空间。向该类应用了WebServiceBindingAttribute类。以指示该Web服务的binding在先前创建的服务说明中定义。该属性至关重要:它指定该服务将使用WSDL文件中定义的CalculateChanceOfRainlnterfacebinding。

3.2 实现GetWeather服务

   由于的情况是虚构的。因此需要创建GetWeather服务的示例实现，以便测试的解决方案。相关步骤几乎与在实现上一个Web服务时所遵循的步骤完全相同。因此我不再对它们详加讨论。唯一需要说明的是，将再次使用WSDL。EXE工具生成web服务存根。然后创建一个新的类文件以保持服务实现。该服务返回一个填充了随机值的CurentWeather实例。由于cafcuIatechanceOfRain服务无论如何都会忽略发送给它的消息，因此这一点并不重要。

3.3 WeatherSerVices客户端应用程序

到目前为止。已经准备好测试新的Web服务。
为此，创建一个简单的名为WeatherClient的Windows窗体应用程序，该应用程序将充当Web服务的客户端。
首先，需要向主窗体中添加一些控件，使用户可以与该应用程序交互。向主窗体中添加一个文本框。并将其命名为“Zipcode“。然后，向该窗体中添加一个按钮。并且将其命名为”Submit Button”。最后。添加一个标签以显示计算结果。并将其命名为“DisplayLabel“。接下来。使用VisualStudio。NET添加一个对服务说明的引用。应该将该引用添加到所创建的静态WSDL文件。而不是ASMX件的动态创建的WSDL。服务说明不包含用于指定服务实现的终结点的service元素。因此在调用Webfie务之前必须手动设置代理实例的URL属性。
像很多NETXMLWeb服务开发人员一样。在添加web引用之后完成的第一件事情是将web引用的URLBehavior属性设置为Dynamic。在设置该属性以后。代理类通过分析应用程序配置文件中的设置来确定Web服务终结点的URL。因此不需要将该URL硬编码到类本身中。遗憾的是。对于已经创建的多重绑定文件，该方法不起作用。因此必须手动创建配置项。并且设置代理实例的URL属性。
现在。已经做好了向应用程序中添加客户端代码的准备。

3.4 进程设置

元素在 WSDL 中相当于 Java 中的接口。它将对 元素的引用分组成逻辑操作，一个进程可以对另一个进程执行这些操作，并将它们绑定到一个名称。 可以包含 、 和 元素。对于所有这三个元素，message 属性引用 WSDL 文件中所定义的 元素。 元素声明客户机向 Web 服务请求传输的需求。 声明 Web 服务响应的内容。 元素描述当 Web 服务设法响应客户机的请求时所发生的任何消息级异常。
在 RPC 样式的消息传递情况下，两个进程之间发生请求-响应类型的通信是很常见的。也就是说，客户机进程调用服务器进程上的一个过程，将该过程所需的所有参数传递给它，服务器进程将它拥有的所有返回值发送回客户机进程。该过程的名称、参数以及返回类型都在 SOAP 元素中以 XML 进行描述。

3.4 将WEB服务发布到目录服务器

在完成之后，需要立即将WSDL文件移动到客户端可以访问的位置。当告诉客户端开发人员有关WeblE务的信息时，或者当使用像UDDI这样的服务发布该服务时，可以将用户引导到该静态WSDL文件的位置。而不是使用在查询字符串中用”?WSDL”访问ASMXURL而创建的动态生成文件。当然，就像所有经验丰富的Web服务开发人员一样，一旦进入实际工作环境，总是将该动态文件保存为静态文件。如果使用反射来动态生成它，则它就不是协定。还可以使用BuiIding XML Web Services Using Industry Standardized WSDLs中描述的机制，让动态生成的WSDL指向静态的WSDL。
确定对外提供服务的url地址 ，这里的url的第一级目录和二级目录会影响我们的配置；
一级目录影响的是：web.xml中监听器的匹配规则
二级目录影响的是：注册webservice服务的时候指定的名称
1)将要部署的WEB应用放在webapps以外的路径, 并在server.xml相应的context中的docBase指定。
2)删除webapps中的所有文件夹, 以及conf/catalina/localhost下所有xml文件。
注: webapps是server.xml中的Host元素的appBase属性的值。
实现二:

1. 修改server.xml中Host元素的属性, 添加或修改: deployXML=“false”
   deployOnStartup=“false” autoDeploy=“false”
2. 含义:
   deployXML=“false”: 不部署conf/catalina/localhost下的xml相应的WEB应用
   deployOnStartup=“false” : tomcat启动时, 不部署webapps下的所有web应用
   autoDeploy=“false”: 避免tomcat在扫描改动时, 再次把webapps下的web应用给部署进来。

四、代码
五、测试

如果正在测试。NETFramework2。0Beta1。则可能会注意到。在开发环境中当前未公开该新功能。请尽管放心。在以后的测试版中。将从VisualStudio2005开始提供同一功能。
如果正在考虑使用带有多个binding的WSDL文件。并且的服务也使用SoapHeaders，则需要小心。在这一特定方案中。客户端代理生成存在一个已知的问题。即只有第一个binding的s0apHeaderAttr。bute参数才是正确的。
通过检查服务器日志文件中是否有错误以及通过使用 appserver appstatus 命令，来验证服务已得到部署。appserver appstatus 命令列出 WebSphere Application Server 中已安装的企业应用程序，以及它们的运行 status (running | stopped)。如下调用 appserver appstatus：appserver appstatus
在已安装企业应用程序的列表中查找 complexWSDL 应用程序的名称。

六、总结

这里完成的封装不够严密。客户端应用程序非常清楚存在两个不同的binding。因为存在两个不同的代理类。两个服务在不同的位置活动。因为客户端负责配置用来访问这些服务的终结点的URL。同时。也没有必要告诉客户端应用程序这两个服务是由不同团队在不同时间单独实现的。还可以在客户端代码中共享这两个Web服务之间的类型。从而避免了很多将一个结构中的数据复制到不同命名空间中另一个完全相同结构的工作。
由于使用NETFramework中提供的工具来创建和使用XMLWeb服务相当容易。因此很多开发人员和设计师从来没有花费时间来熟悉Web服务栈的基础协议。但是。对基础协议以及工具使用这些协议的方式进行一定的了解。可以扩充在设计解决方案时的可用选择。

一、概述
1.1 WSDL概述

WSDL(WebServices Description Language，Web服务描述语言)是一种XML Appifcafion，用来描述web服务及web服务通信过程的XML语言。Web服务相当于一组服务访问点，通过这些服务访问点，客户端可以直接访问调用那些面向文档信息或面向过程调用的服务。WSDL首先对访问时的具体操作和访问时使用的请求/响应消息信息进行抽象描述，然后将此绑定到具体的传输协议和消息格式上，用来定义具体部署的服务访问点。相关的具体部署的服务访问点进行组合成为抽象的整体Web服务。
WSDL是用来精确描述Web服务的文档，WSDL文档一般遵循WSDLXML模式的XML文档，将Web服务定义为服务访问点或端口的集合。在WSDL中，由于巳从具体的服务部署或数据格式绑定中分离出服务访问点和消息的抽象定义，因此可以再次应用抽象定义。交换数据的抽象描述即为消息；而端口类型指的是操作的抽象集合。

1.2 服务建模研究

随着Web服务相关技术的发展，Internet上可供调用的Web服务数量快速增加，它是基于网络化的、分布式的、自封闭性的、功能模块化的组件。Web服务组合提供一种面向Internet应用的统一服务发现、调用和集成增值机制，得到学术界和产业界的广泛关注。服务组合一般基于消息域和服务过程建立模型。以往研究建模研究概括为以下3类:
(1)语义Web模型的服务组合研究，基于DAML—S模型实现服务集成_4和基于Colombo模型提出一种稳定高效的服务组合算法pJ，但在工业界缺少该理论模型的具体实现；
(2)消息驱动模型的服务组合研究，利用更通用的工具模型解决了消息驱动的服务组合问，如多数此类组合研究是基于中间件(middle-ware)理论模型。
(3)功能性服务组合研究，如Roman模型验证服务功能可组合性

1.3 WSDL 文档的组成部分

（1）组成部分
　　：web service 执行的操作
　　：web service 使用的消息
　　：web service 使用的数据类型
　　：web service 使用的通信协议
（2）WSDL元素介绍
WSDL规范为了不会产生歧义，定义了特有名词来表述功能与服务。
　　 ：元素是最重要的 WSDL 元素。 它可描述一个 Web Service、可被执行的操作，以及相关的消息。 可以把 元素比作传统编程语言中的一个函数库（或一个模块、或一个类）。
　　：是对服务中所支持的操作的抽象描述，一般单个Operation描述了一个访问入口的请求/响应消息对。
　　： 元素定义一个操作的数据元素。 每个消息均由一个或多个部件组成。可以把这些部件比作传统编程语言中一个函数调用的参数。 通信消息的数据结构的抽象类型化定义。使用Types所定义的类型来定义整个消息的数据结构。
　　： 元素定义WebService 使用的数据类型。为了最大程度的平台中立性，WSDL 使用 XML Schema 语法来定义数据类型。
　　： 元素为每个端口定义消息格式和协议细节。

二、问题描述

应用程序必须运行完所有的前台线程才可以退出；而对于后台线程，应用程序则可以不考虑其是否已经运行完毕而直接退出，所有的后台线程在应用程序退出时都会自动结束。一般后台线程用于处理时间较短的任务，如在一个Web服务器中可以利用后台线程来处理客户端发过来的请求信息。而前台线程一般用于处理需要长时间等待的任务，如在Web服务器中的监听客户端请求的程序。
线程是寄托在进程上的，进程都结束了，线程也就不复存在了！
只要有一个前台线程未退出，进程就不会终止！即说的就是程序不会关闭！（即在资源管理器中可以看到进程未结束。）
作为程序的入口main()函数所在的线程即为主线程，通过Thread类来创建子线程，Thread类有 ThreadStart 和 ParameterizedThreadStart类型的委托参数，我们也可以直接写方法的名字。线程执行的方法可以传递参数（可选），参数的类型为object，写在Start()里。
本实验将提供一个解决方案，以便实现Web服务进程创建。同时提供一个分析Web服务描述语言(WSDL Web Services Description Language)及其与我们了解并喜欢的Web服务工具之间的交互的机会。

三、技术难点

当我第一次尝试创建两个Web服务描述文档时。该技术使每次在开发过程中更改服务协定时，无需重新创建对代理类进行的更改XML类型。我遭遇到一个令我不太愉快的意外。在我的客户端应用程序中创建的每个代理，都在不同的C#命名空间中具有常见消息的不同对象表示。我必须将每个属性从一个类的实例手动复制到另一个类的实例。而这似乎是这些工具当前实现的一项不必要的结果。

四、关键技术

WSDL的设计理念完全继承了以XML为基础的当代Web技术标准的一贯设计理念：开放。WSDL允许通过扩展使用其他的类型定义语言(不光是XML Schema)，允许使用多种网络传输协议和消息格式(不光是在规范中定义的这些：SOAP/HTTP，HTTP-GET/POST以及MIME等)。同时WSDL也应用了当代软件工程中的复用理念，分离了抽象定义层和具体部署层，使得抽象定义层的复用性大大增加。比如我们可以先使用抽象定义层为一类Web服务进行抽象定义(比如UDDI Registry，抽象定义肯定是完全一致的遵循了UDDI规范)，而不同的运营公司可以采用不同的具体部署层的描述结合抽象定义完成其自身的Web服务的描述。
一个web services要被其它应用调用，就必须告诉其它应用如何去调用web services中的webmethod，比如这个web services中包含哪些可以调用的方法，每个方法的方法签名是怎样的，方法是用的输入输出参数的类型又是什么等等，这些都是通过web services的WSDL来进行描述的。

五、解决方案

通过创建带有多个绑定的WSDL文件封装了多个Web服务终结点。这就显式地定义了服务之间的关系，而且还具有代理的优势。这些代理可以共享表示常见消息的托管类。在完成上述工作之后，可以通过手动编辑工具生成的代理，在相同命名空间中共享由多个协定定义的类型。但是，通过将Web服务绑定组合到单个WSDL文件中。
首先定义了将用其服务交换的XML消息。然后，使用该XML结构定义了一个XML架构，并且定义了一个抽象服务说明。该抽象服务说明用来创建该服务的实现。

六、为什么采取这种方案？

通过使用突出消息的协定优先设计。Web服务设计者可以定义将在网络中传送的消息的确切结构，而不是设计和实现对象表示并且让工具来决定网络级表示。

七、优缺点分析、性能分析

服务描述文件(WSDL)缺乏对服务行为的表述，使得以上的组合方法在工业界的应用有一定的局限性。通过验证DPDL逻辑表达式的可满足性来检验服务的可组合性。Roman系列均要求用有限状态自动机暴露服务行为，而WSDL文件缺乏对服务行为的描述，使得Roman系列无法直接获取服务资源库中的服务进行自动组合。例如，从全球资源服务库Seekda中获取Hotel服务和Bank服务的服务描述文件，但其并没有暴露服务行为，无法直接应用Roman系列进行服务组合。本文设计和扩展WSDL标签，基于自定义的标签在WSDL上添加服务行为(自动机)，从而为一类服务组合方法(如Roman系列)提供技术支撑。
可能存在很多已经开发的web服务——它们的设计师从未考虑过他们的服务的消息在网络中呈现的状况，这通常是因为这些服务是在单个平台上实现和测试的，并且只通过代理使用。如果强迫这些开发人员深入到其开发工具所提供的抽象之下来解决难解的问题，或者如果他们需要利用XML开发人员可以使用的强大工具，则他们可能会突然感到非常吃惊，因为他们面对的是其消息不够理想的XML表示。
其实也是有优势的，使服务之间的类型共享变得更为简单。通过向该工具提供多个WSDLURL以及向参数中添加gsharetypes标志。用户可以告诉该工具，希望在生成的代理之间共享任何公共类型。公共类型是指在同一架构文件中定义的具有相同本地名称和命名空间的元素。所创建的文件将包含与每个Web服务的binding相对应的类。以及与在服务之间共享的每个类型相对应的单个类。实际上。所创建的文件几乎与使用。在添加对WSDL文件的引用时所创建的文件完全相同。