Web服务动态组装机制

Web服务动态组装机制 题 目 Web服务动态组装机制 设计和实现 学生姓名 指导老师 学 院 专业班级 完成时间 2010年6月 摘 要 近年来，软件开发技术、XML等技术取得了长足进步，Web服务技术也得到了广泛的应用。Web服务是一种想把全世界的Internet/Intranet变成一个虚拟计算机环境的观念和技术，它是一种可以通过URL地址来访问网络资源，可以将应用程序转换为网络应用程序，可以被其他应用程序使用的技术。 如果在客户端运行的时候，用户能够自由选择不同的Web服务并且可以选择别的服务来替换已经改变的服务，这样将会使调用服务更加方便快捷，本文讨论的Web服务动态组装机制正实现了自由选择服务和动态调用服务的功能。 本文从课题任务出发，首先介绍了Web服务动态组装机制的开发背景和Web服务相关知识，然后描述了该机制的需求分析和总体设计。随后，本文详细讲述了为实现Web服务动态组装机制而设计的Web服务注册查询子系统和Web服务动态组装子系统的具体内容。为了能够动态自由地选择Web服务，这里设计的Web服务注册查询系统能够让发布者发布服务、调用者查询服务，从而使调用者能够在调用服务的时候自由选择查询得到的服务。在Web服务注册查询系统的基础上，Web服务动态组装系统通过采用动态创建Web服务代理类的方法，能够实现在运行时让用户自由选择调用服务的功能。同时，为了测试Web服务的动态调用，本文简述了本次设计的两大Web服务组件:学生成绩管理系统组件、好友信息管理组件。最后本文给出了两大子系统的运行实例并对工作做出了总结。 关键词 UDDI，发布服务，查询服务，动态调用 I ABSTRACT In recent years, software development technology, XML and other technologies have made great progress and Web Services technology has also been used widely. Web Services is a kind of concept and technology which aims to change the Internet/Intranet all over the world into a virtual computing environment. To be simple, Web Services is a technology that is access to network resources through URL address, and can convert application programs into net application programs which could be used by other application programs. It will make calling services more convenient and efficient if users can choose different Web Services freely and choose other services to replace the changed services when on the run of client applications.In fact, Web Services Dynamic Assembly Mechanism which is discussed in the paper is to achieve the freedom choice of Web Services and dynamical calling of Web Services. According to the assignment, the paper firstly introduces the development background of the mechanism and related knowledge about Web Services, then describes requirements analysis and the overall design of Web Services Dynamic Mechanism, and later dwells on the details of the two child systems: Web Services Registry and Query System and Web Services Dynamically Assembly System, which are designed for realizing the mechanism. In order to call Web Services dynamically and freely, we have designed Web Services’Registry and Query System, where providing services to publish for publishers and services to query for callers so that it can achieve the free choice of services access to query for callers when calling services. Based on the Web Services Registry and Query System, Web Services Dynamic Assembly System can allow users to freely choose services for calling when the system is running by using the method of dynamically creating Web Services Proxy Class. At the same time, in order to test Web Services’ dynamical calling , the paper describes two Web Serivces components:Student Score Management System services component and Good Friend Information Query System services Component. At last, it gives running instances of the two child systems and summarizes the work. KEY WORDS uddi, publishing services, quering services, dynamic calling II 目 录 摘 要 ............................................................................................................... I ABSTRACT ...................................................................................................... II 第一章 绪 论 ............................................................................................... 1 1.1应用背景 ............................................................................................. 1 1.2Web服务技术 ...................................................................................... 2 1.3课题任务及目标 .................................................................................. 3 1.4组织结构 ..................................................................................... 4 第二章 相关知识 ........................................................................................... 5 2.1 Web服务模型 ..................................................................................... 5 2.2 Web服务协议栈 ................................................................................. 6 2.2.1 SOAP ........................................................................................ 7 2.2.2 WSDL ....................................................................................... 7 2.2.1 UDDI ........................................................................................ 8 2.3 本章小结 .......................................................................................... 10 第三章 需求分析与总体设计 ....................................................................... 11 3.1 问题分析 ........................................................................................... 11 3.2 功能需求 ........................................................................................... 11 3.2.1 Web服务注册查询系统 ......................................................... 12 3.2.2 Web服务动态组装系统 ......................................................... 13 3.2.3 Web服务组件 ......................................................................... 13 3.3机制的主要组成 ................................................................................ 14 3.4 总体设计 .......................................................................................... 15 3.4.1系统架构图 ............................................................................. 15 3.4.2功能结构图 ............................................................................. 16 3.4.3 Web服务注册查询子系统的功能模块简介 ........................... 16 3.4.4 Web服务动态组装子系统的功能模块简介 ........................... 17 3.5系统运行环境与开发平台 ................................................................ 17 3.6本章小结 ........................................................................................... 18 第四章 详细设计与实现 .............................................................................. 19 4.1 数据库详细设计 ............................................................................... 20 4.1.1数据库表的组成及表关系 ...................................................... 21 III 4.1.2表结构设计 ............................................................................. 25 4.1.3 视图和存储过程设计 ............................................................ 29 4.2 Web服务注册查询系统功能详细设计与实现 ................................. 30 4.2.1Web服务注册查询子系统详细功能划分 ............................... 31 4.2.2用户注册和登录模块 ............................................................. 32 4.2.3服务注册模块 ......................................................................... 32 4.2.4服务查询模块 ......................................................................... 38 4.2.5授权模块 ................................................................................. 39 4.2.6外部UDDI注册接口和查询接口模块 .................................. 40 4.3 Web服务动态组装系统功能详细设计与实现 ................................. 40 4.3.1添加服务模块 ......................................................................... 41 4.3.3调用方法模块详细设计与实现 .............................................. 43 4.4本章小结 ........................................................................................... 44 第五章 运行实例 ......................................................................................... 45 5.1Web服务注册查询系统运行测试 ..................................................... 45 5.1.1服务注册运行测试 ................................................................. 45 5.1.2服务查询运行测试 ................................................................. 47 5.1.3服务授权运行测试 ................................................................. 50 5.2Web服务动态组装系统 ..................................................................... 51 5.2.1添加服务运行测试 ................................................................. 51 5.2.2调用方法运行测试 ................................................................. 53 5.3本章小结 ........................................................................................... 54 第六章 与展望 .............................................................................. 55 6.1 工作总结 .......................................................................................... 55 6.2 展望 .................................................................................................. 56 致谢 ................................................................................................................ 57 参考文献 ......................................................................................................... 58 IV Web服务动态组装机制设计和实现 第一章 绪论 第一章 绪 论 随着电子商务的迅速崛起，Web应用从局部化发展到全球化，从B2C(business-to-customer)发展到B2B(business-to-business)，从集中式发展到分布式。Web服务作为一种崭新的分布式计算模型，它使企业应用集成和动态协作成为真正可能的、同时便于实施的解决。目前，虽然Web服务技术得到了广泛的应用，但是在现今这个个体间交互合作越来越频繁的社会，Web服务还有很多问题有待解决，具有广阔的研究空间，同时也存在很多挑战。 我们知道，互联网正在发生很多变化，它已经成了Web服务的推动器，而不仅仅是一个信息仓库。很多组织都将他们的核心业务以Web服务的形式放到互联网上，并在互联网上找其他所需要的Web服务，从而构建出新的增值服务。因此，我们需要一个Web服务的发布查询系统，发布者可以将Web服务信息发布到互联网上，用户可以通过查询获得Web服务的具体信息，从而用户可以自由地选择所需要的服务组合在一起来满足自己的需求。鉴于发布、查询、调用Web服务，尤其是动态组装Web服务在生活中的广泛应用，所以，Web服务动态组装机制的研究将显得尤为重要。 1.1应用背景 Web服务源于它蕴含的商业价值及可能带来的巨大商业利益，它同时也代表着Internet技术的重大发展。我们知道，Internet已经给大量企业带来巨大利益，而Web服务技术将会使这种商业价值和商业利益更大化。现在很多组织都将它们的核心业务以Web服务的形式放到互联网上，并在互联网上找到其他所需Web服务，并及时执行，从而可以测试发现服务的可用性、可靠性和正确性，为实现 [4]整合提供了支持并保障了整合的有效性。 Web 服务有以下几个方面的优势: ? Web服务使企业内部和企业间的人、信息和流程之间的整合更加容易，从而缩短了业务流程周期，提高企业反应速度。同时，它能够为更多的应用和用户实时地提供关键数据，从而使企业更具敏捷性和灵活性。 ? Web服务简化了客户的自助服务体系，让企业内部各个职能部门可以通过一个“窗口”了解客户，也可以让客户通过一个“窗口”接触整个企业，接触到企业的新产品和新服务，这些都有助于企业建立持久的、忠诚的客户关系。 ? Web服务有助于提高企业效率。就目前来说，只有Web服务才能够将分散在各种系统、信息孤岛中的数据进行整合，并让管理者们能够实时地访问这些 1 Web服务动态组装机制设计和实现 第一章 绪论 分散的数据，同时也可以让合作伙伴和供应商直接访问该企业相关的信息和服务。 从另一方面看，当Java在1995年刚刚出现时，我们希望它能解决软件业中碰到的所有难题，虽然结果并不尽如人意。在随后的几年中，XML出现并以惊人的速度发展，它与Java一样也获得巨大的成功。如果我们将XML与Java结合，因特网数据的集成程度将远远超过单独使用Java时的集成程度。Web服务是近年来人们谈论的另一个新的研究热点，它的出现将更加有助于实现企业内和企业之间的应用集成，提高应用程序的互操作性。因此，Java、XML和Web服务是实现强大开放且可移植的平台的三要素，它们互为补充，缺一不可，为电子商务的发展和成功奠定了坚实的基础。 从电子商务的发展看来，目前它还只处于发展的初期，其主要任务是将企业现有的业务和应用移植到因特网上来供相关客户访问，因此在很大程度上可以说是用户驱动型的电子商务。另外，企业实施电子商务从根本上说是为商业服务的。实现技术和模式是否先进是次要的。当前相对成熟并极富价值的电子商务应用包括:企业门户、网上连锁商店、集团内联网与知识库，供应链管理、客户服务和分销管理、ASP服务等，企业要实施以上的这些电子商务应用，一般有两种途径: ? 由企业自己的IT部门来进行实施。 ? 外包给软件公司或解决方案提供商来实施。 然而，无论是自身的IT部门还是外包的解决法案提供商，其拟定的实施都是在应用正式运营前给出的。一旦应用被部署之后，就需要修订、更新这些商务应用，以符合新的电子商务流程的需要。例如，可能会经常增加新的电子商务应用，更改电子商务的流程，也可能需要根据用户的需求而进行更改，为每个客户、每个合作伙伴或每个企业员工都定制其首选的电子商务应用等。毫无疑问，当企业直接面对这一问题的挑战时，如何提升企业的响应能力，削减响应开支是解决问题的关键。对于以上问题的解决，Web服务技术是一种很好的解决方案。Web服务的出现将会改变目前的开发模式并减少企业商务应用的部署费用，它一次部署到Internet中，然后就可以任意调用，所有应用只要能够连入Internet，就可以使用和集成这些Web服务了。 1.2Web服务技术 Web服务具有广泛的适应性和应用背景,而且Web服务的很多相关问题仍处于研究过程中,学术界从不同的侧面对Web服务有不同的描述。 从功能的角度描述Web服务,Web服务是基于TCP/IP,HTTP,XML等规范而定义,具备如下功能:Web上链接文档的浏览、事物的自动调用、服务的动态发现 2 Web服务动态组装机制设计和实现 第一章 绪论 和发布。从组成框架及实现目标的角度描述了Web服务,认为Web服务作为一种网络操作,能够利用的Web协议及接口进行应用间的交互。从语义的角度,描述了基于语义Web的服务,认为Web服务是语义Web的一种应用,由于考虑了语义信息的描述及表示,Web服务能够更准确地被执行,服务组合(service composition)能够按照所期望的目标进行。从网格计算(grid computing)的角度指出Web服务能用于Web上的资源发现、数据管理及网络计算平台上异构系统的协同设计,提出了网络服务的新概念。从信息检索的角度提出了在包含了分布 [17]。 策略和路由信息的电子文档之上进行分布式文档检索的Web服务 从另一方面看,针对不同的应用背景,Web服务的应用对象也不同,目前被广泛应用的Web服务可分为如下四类:面向企业应用(business-oriented)的服务、面向消费者(consumer-oriented)的服务、面向设备(device-oriented)的服务。尽管对Web服务进行描述的出发点或应用类型不同,但是它们均具有如下共同特征:(1)应用的分布式。为适应网络应用中分布式的数据源和服务提供者,分布式的服务响应、松散耦合是Web服务必须具备的特征。在应用中,服务请求者不必关心服务提供者的数据源格式是什么,某一服务请求需调用哪些服务,服务请求在Web上怎样被执行等,即Web服务对用户具有分布透明性。(2)应用到应用的交互。在分布式的环境中,若采用集中控制方式,服务器有较大的负荷,并且系统不具有健壮性。因此应用到应用的交互,使得Web服务更具有可伸缩性。(3)平台无关性。Web服务的界面、跨Web服务的事务、工作流、消息认证、安全机制均采用规范的协议和约定;由于Web服务采用简单、易理解的标准Web协议作为组件接口和协同描述的规范,完全屏蔽了不同软件平台的差异,因此更具有可集成能力。 1.3课题任务及目标 本次课题任务为:设计一个Web服务动态组装机制,该机制能将接口一致的Web服务进行组装以实现服务的动态组装。用户在注册中心注册好新的组件后在工作流中能够把该新组件替换原有的组件,实现动态更新,不重新编译系统就可以直接运行新的流程。 根据课题任务,构建了一个Web服务注册查询系统以及一个Web服务动态组装(调用)系统。Web服务注册查询系统可以方便服务发布者注册服务,同时普通用户可以根据服务名称等查询相关服务。如果发布者在注册服务后,由于工作需要或者其它原因更改了Web服务组件的内容,只要他提供给注册中心的信息和地址仍然正确,其它用户仍然能够正常使用该服务组件,不需要重新编译系统。Web服务动态组装系统采用了在运行时动态创建代理类的方法，可以方便用户根 3 Web服务动态组装机制设计和实现 第一章 绪论 据在Web服务注册查询系统查得的服务地址来调用服务,用户不必事先在该系统中静态添加Web服务引用,而可以在运行的时候,根据查得的地址来动态生成Web服务组件,实现Web服务的动态组装。 那么,为了实现以上两个系统,必须设计一些Web服务组件来供测试使用。由于Web服务技术的使用是为了方便企业与企业间,或者企业与个人间等等的交互合作,因此这里设计了两个Web服务组件,一个是普通高校发布的学生成绩管理系统组件,一个是学校某班级某学生发布的好友信息查询系统组件。 1.4论文组织结构 论文共分为六章。 第一章 绪论。简单介绍了课题的应用背景和Web的定义及特征，同时陈述了本课题的任务和目标。 第二章 相关知识介绍。主要介绍了Web服务模型、Web服务协议栈和一些与Web服务相关的知识,如SOAP、WSDL、UDDI。 第三章 需求分析与总体设计。根据本次设计的任务要求，具体分析了课题，得出了具体的功能需求。并且概括了要实现本次设计的各个组成部分。同时对Web服务动态组装机制的各个系统进行了概要设计，详述了各个系统的相互关系，也简述了运行环境和开发平台。 第四章 详细设计与实现。这一章首先对与Web服务动态组装机制的各个子系统交互的数据库进行了详细设计，然后对各个子系统的各功能模块的设计与实现进行了详细的讲述。 第五章 运行实例。这一章给出了各个子系统的主要模块的运行实例，并对运行结果进行了分析。 第六章 工作总结与展望。这一章总结了本次设计的学习所得、进行本次设计的过程以及存在的问题。并且对Web服务和Web服务动态组装机制的应用前景进行了展望。 4 Web服务动态组装机制设计和实现 第二章 相关知识 第二章 相关知识 2.1 Web服务模型 Web服务体系结构是面向对象分析和设计(OOAD)的一种必然的发展结果,同时也是电子商务解决方案中面向体系结构、设计、实现与部署而采用的组件化模式的必然结果。 Web服务体系结构基于三种角色(即服务提供者、服务注册中心和服务请求者)之间的交互。交互涉及发布、查找和绑定操作,这些角色和操作一起作用于Web服务组件,即Web服务软件模块及其描述。在典型情况下,服务提供者托管可通过网络访问的软件模块,定义Web服务的服务描述并把它发布到服务注册中心;服务请求者使用查找操作来从服务注册中心检索服务描述,然后使用服务描述与服务提供者进行绑定并调用Web服务实现与它交互。那么Web服务的体系结构即上面提到的面向服务的体系结构(SOA)，如图2.1所示。 图2.1 面向服务体系结构SOA 从图2.1可以看出,SOA结构中共有三种角色: 服务提供者:发布自己的服务,并且对服务请求进行响应。 ? ? UDDI服务注册中心:注册已经发布的Web服务,对其进行分类,并提供搜 索服务。 ? 服务请求者:利用服务注册中心查找所需的服务,然后使用该服务。 SOA体系结构中的组件必须具有上述一种或多种角色,这些角色之间使用三种操作: ? 发布操作:使服务提供者可以向服务注册中心注册自己的访问接口。 ? 查找操作:使服务请求者可以通过服务注册中心查找特定种类的服务。 ? 绑定操作:使服务请求者能够真正使用服务提供者提供的服务。 为支持结构中的三种操作,SOA需要对服务进行一定的描述,这种服务描述 5 Web服务动态组装机制设计和实现 第二章 相关知识 应具有下面几个重要特点: ?首先,它要声明服务提供者提供的Web服务的特征。服务注册中心根据某些特征将服务提供者进行分类,以帮助查找具体服务。服务请求者根据特征来匹配那些满足要求的服务提供者。 ?其次,服务描述应该声明接口特征,以访问特定的服务。 ?最后,服务描述还应该声明各种非功能特征,如安全要求、事务要求、使用服务的费用等。接口特征和非功能特征也可以用来帮助服务请求者来查找服务 其中的服务描述和服务实现是分离的,这使得服务请求者可以在服务提供者的一个具体实现正处于开发阶段、部署阶段或完成阶段时,对具体实现进行绑定。另外,SOA中的组件之间必须能够进行交互,才能进行上述三种操作。所以Web服务体系结构的另一个基本原则就是使用标准的技术,包括服务描述、通信协议以及数据格式等,这样以来,开发者就可以开发出平台独立、编程语言独立的Web服务了。 最后,SOA体系结构没有对Web服务的粒度进行限制,因此一个Web服务既可以是一个组件(小粒度),也可以是一个应用程序(大粒度)。 2.2 Web服务协议栈 要以一种互操作的方式执行发布、发现和绑定三个操作,必须有一个包含每层标准的Web服务协议栈。图2.2展示了一个概念性Web服务协议栈。上面的几层建立在下面几层提供的功能之上,垂直的条表示在协议栈的每层中必须满足的需求,左边的文本表示协议栈的那一层所应用的标准技术。 图2.2 Web服务的概念性协议栈 Web服务协议栈的基础是网络层，Web服务要被服务请求者调用，就必须通过网络访问。因特网上可供访问的Web服务必须使用普遍部署的网络协议，而HTTP凭借其普遍性，成为因特网可用的Web服务真正的标准网络协议。Web 6 Web服务动态组装机制设计和实现 第二章 相关知识 服务还可以支持其他因特网协议，如FTP、SMTP、MQ(消息队列)、IIOP(因特网ORB间协议)上的远程方法调用、Email等，应使用哪种网络协议和应用 [4]。 程序的具体需求有关 2.2.1 SOAP Web服务体系结构的基础是XML消息传递,当前XML消息传递的行业标准是SOAP(Simple Object Access Protocol )。SOAP简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议,是一个基于XML的协议,它包括四个部分: ? SOAP封装(envelop),封装定义了一个描述消息中的内容是什么,是谁发送的,谁应当接受并处理它以及如何处理它的框架。 ? SOAP编码规则(encoding rules),表示应用程序需要使用的数据类型实例。 ? SOAP RPC表示(RPC representation),表示远程过程调用和应答的协定。 ? SOAP绑定(binding),使用底层协议交换信息。 虽然这四个部分都作为SOAP的一部分,作为一个整体定义的,但他们在功能上是相交的、彼此独立的。特别的,信封和编码规则是被定义在不同的XML命名 [12]空间(namespace)中,这样使得定义更加简单。 2.2.2 WSDL WSDL(Web Service Description Language)Web服务器描述语言是用XML文档来描述Web服务的标准,是Web服务的接口定义语言,由Ariba、Intel、IBM、MS等共同提出,它用来定义Web服务并描述如何访问它们。 WSDL文档把Web服务定义为一组处理消息的网络端点或端口(port)。在WSDL中,端点和消息的定义都是抽象的,必须把它们绑定到具体的网络协议和消 [5]息格式上才能定义一个具体的端点。 W3C对WSDL的定义是:WSDL完全基于XML,它把网络服务描述为一组在包含面向文档或者面向过程信息的消息上执行操作的端点(endpoint)。其中操作(operation)和消息(message)采用抽象方式进行描述,然后把它们绑定到一个具体的网络协议和消息格式上来定义一个端口(port)。多个相关的具体端点结合在一起就构成了服务(service)。WSDL是可扩充的,它允许采用一种与消息格式或网络协议无关的方式来描述端点和它们的消息。 通过WSDL,可描述Web服务的三个基本属性: ? 服务做些什么——服务所提供的操作(方法)。 ? 如何访问服务——和服务交互的数据格式以及必要协议。 ? 服务位于何处——协议相关的地址,如URL。 7 Web服务动态组装机制设计和实现 第二章 相关知识 WSDL文档中主要包含以下6个元素: ? definitions:definitions元素是WSDL文档的根元素,它主要用来定义Web服务的名称、声明一些命名空间并包含下面的几个元素。 ? types:types元素包含一些WSDL文档中使用的数据类型定义。如果WSDL文档中只有使用XML架构中的内建简单类型,则可以省略types元素。 ? message:message元素是对被交换数据的抽象描述。它描述了一个单向的消息,即它可以是一个单一的请求消息,也可以是一个单一的响应消息。message元素定义了消息的名称并包含0个或多个part元素,它们表示消息的参数或消息的返回值。 ? portType:portType元素表示端点支持的一组抽象操作(operation)。portType可以把多个message元素结合在一起来构成一个完整的单向或双向操作。 ? binding:binding元素为一个特定的端口类型制定具体的协议和数据格式。 ? service:service元素是一组相关端口(使用port元素表示)的集合,其中每 一个端口都表示一个端口,包含具体的绑定和网络地址。 其文档结构如图2.3所示。 图2.3 WSDL 文档的结构 2.2.1 UDDI Universal Description Discovery and Integration即统一描述、发现和集成协议。 UDDI 始于2000年,由 Ariba , IBM, Microsoft 和其他33家公司创立。UDDI registries 提供了一个机制,以一种有效的方式来浏览,发现Web服务以及它们之 8 Web服务动态组装机制设计和实现 第二章 相关知识 间的相互作用。 UDDI计划是一个广泛的,开放的行业计划,它使得商业实体能够: ? 彼此发现。 ? 定义他们在因特网上互相作用,并在一个全球注册体系架构中共享信息。 UDDI是这样一种基础的系统构筑模块,它使商业实体能够快速,方便地使用他们自身的企业应用软件来发现合适的商业对等实体,并与其实施电子化的商业贸易。UDDI同时也是Web服务集成的一个体系框架。它包含了服务描述与发现的标准规范。UDDI规范利用了W3C和Internet工程任务组织(IETF)的很多标准作为其实现基础,比如扩展标注语言(XML),HTTP和域名服务(DNS)这些协议。另外,在跨平台的设计特性中,UDDI主要采用了已经被提议给W3C的SOAP(Simple Object Access Protocol,简单对象访问协议)规范的早期版本。 简单地说,UDDI的工作方式和邮局公开发行的电话黄页类似,它可以把特定的企业信息和Web服务在Internet上广而告之,并且提供具体的联系地址和方式。其工作原理如图2.4所示。 图2.4 UDDI工作原理 从图2.4中可以看出UDDI的主要用途以及参与UDDI协议的不同机构。 UDDI实际上是一种供用户发现服务的协议，UDDI注册中心保存了许多服务的详细信息，这些信息UDDI规范确定。UDDI商业注册的信息包括6种数据结构类型。这种根据信息类型的划分为快速定位和理解构成商业注册的不同信息提供了一种简单的划分方法。这些信息类型是技术人员在需要使用合作伙伴所提供的Web服务时必须了解的技术信息。六种主要信息类型如图2.5所示。 9 Web服务动态组装机制设计和实现 第二章 相关知识 图2.5 UDDI信息模型结构图 其中，商业实体(businessEntity)发布服务信息的商业实体的详细信息，包括企业名称、关键性标识、可选分类信息和联络方法等。 服务信息(businessService)一组特定的技术服务的描述信息。它是商业实体的子结构。 绑定模板(bindingTemplate)关于Web服务的入口点和相关技术规范的描述信息。 技术规范(tModel，又名技术指纹)Web服务或分类法的规范描述信息，也就是关于调用规范的元数据，包括Web服务名称、注册Web服务的企业信息和指 [2]向这些规范本身的URL指针等。 2.3 本章小结 本章介绍了Web服务的工作原理和Web服务的协议栈的基本组成，并对组成Web服务协议栈的相关知识如SOAP、WSDL、UDDI等做了简单介绍。 10 Web服务动态组装机制设计和实现 第三章 需求分析与总体设计 第三章 需求分析与总体设计 3.1 问题分析 本次课题任务为:设计一个Web服务动态组装机制,该机制能将接口一致的Web服务进行组装以实现服务的动态组装。用户在注册中心注册好新的组件后在工作流中能够把该新组件替换原有的组件,实现动态更新,不重新编译系统就可以直接运行新的流程。 根据对前面Web服务的初步了解和任务要求，从面向服务体系结构SOA中可以知道在Web服务的动态调用过程中需要三个角色参与:服务提供者、服务注册中心UDDI、服务请求者。其中服务提供者发布自己的服务，即在创建好自己的Web服务组件后向UDDI注册中心注册服务信息;然后服务请求者便可以通过查询UDDI注册中心获得所需的Web服务信息(最重要的就是获得Web服务的URL)，服务请求者在获得了URL后，便可以调用Web服务组件了。 那么所谓的实现Web服务动态组装机制的一个重要前提就是要实现一个UDDI服务注册中心，因为只有这样，用户(服务请求者)才可以随时根据需要来查阅Web服务的信息，如果Web服务发生了变化，服务发布者可以在UDDI中更新信息，而服务请求者也可以随时获得最新的服务信息，同时用户能在运行的时候动态选择要调用的服务，只要在UDDI注册中心的服务信息正确，用户不需要重新编译系统，便可以直接获得正确的调用。 其次，要实现动态组装，即运行时自由选择要调用的服务，那么需要实现的是不需要事先将Web服务组件添加到系统里，而是在运行的时候，通过输入某个值(比如一个URL地址)，便可以产生Web服务组件(即产生组件的各个功能方法)。因此，需要选择一种动态添加Web服务的方法。 同时，为了测试Web服务的动态组装，需要设计Web服务组件。而Web服务组件主要用于测试，其具体功能是什么可随意设计。 3.2 功能需求 通过问题分析，显然该机制的设计与实现依赖于三大部分的设计和实现: Web服务注册查询系统，Web服务动态组装系统，Web服务组件。 其中Web服务注册查询系统用于服务发布者注册服务和服务请求者查询服务。Web服务动态组装系统，用于用户动态调用Web服务。Web服务组件则是服务于前面两大系统的，用于前两大系统的测试。 11 Web服务动态组装机制设计和实现 第三章 需求分析与总体设计 3.2.1 Web服务注册查询系统 我们都知道IT业界对UDDI做了大量的研究工作,许多企业都有自己的UDDI服务器(如微软,IBM等公司),他们都有自己的UDDI数据库后台。然而，不同的企业、不同的用户有不同的需求，为了使该机制的实现变得简单明了，在这里需要创建私有的UDDI注册中心,该注册中心可以供合作伙伴或内部人员注册服务和内部人员或合作企业进行Web服务的查询工作。为了方便用户能获得更多的Web服务信息(比如外部企业发布在其他UDDI服务器中的服务),还需要有一个对外部企业UDDI服务器的注册查询接口。根据以上分析,需要一个外部UDDI的注册查询接口,和一个内部私有的UDDI服务器。 1.对外的注册查询接口 由UDDI信息模型的结构图3.1,可以知道它定义了6种主要的信息类型,同时,现有的UDDI注册中心都提供了UDDI注册API和UDDI查询API,那么可以利用这些API来实现注册查询工作。对于外部完整的UDDI服务器,要注册一个完整的服务,必须具备上述UDDI信息模型中的6种或5种类型,并需对这几种类型的信息进行注册。为了简化查询,需要提供两种方式的查询工作:按businessEntity 的名称查询和按tmomel的名称查询。通过这些查询可以获得服务的WSDL文档的地址。 2.内置私有的UDDI服务器 本次设计可以依据UDDI信息模型来设计私有的UDDI服务器。由于UDDI是私有的,为了研究和实现本次设计,因此可以适当简化UDDI服务器。但是businessEntity,businessService,bindingTemplate和tmodel是必不可少的,需要提供对这些类型的注册和查询服务。同时,我们知道在企业或个人之间的交互合作中,为了确保企业的信息不被非授权用户非法访问,这里需要采用一定的安全措施,确保企业信息和服务信息只能被合法的用户访问。 注册部分需要包括: ? 注册businessEnity信息 ? 注册businessService信息 ? 注册bindingTemplate信息 ? 注册tmodel信息 查询部分需要包括: ? 按照businessEnity的名称查询 ? 按照businessService的名称查询 ? 按照tmodel的名称查询 12 Web服务动态组装机制设计和实现 第三章 需求分析与总体设计 安全措施方面: ? 只有注册用户才可以登陆该系统。 ? 有对查询工作的授权机制,只能是权限高的用户对权限低的授权。同时只允许授予的权限低于授权者本身权限。 ? 只有获得授权的用户才可以获得WSDL文档的地址。 3.2.2 Web服务动态组装系统 我们知道部署Web服务有三种方式:Dynamic Invocation Interface(DII)、Stubs方式、Dynamic Proxy方式。在这里选择Dynamic Proxy方式来调用Web服务。 而在Dynamic Proxy方式中,可以通过Web服务的URL地址或WSDL文档地址来动态生成Web服务的代理类,从而获得相应的方法。 在Web服务注册查询系统里面,可以通过查询得到所需要的Web服务的URL或WSDL服务文档地址。那么在这个系统中需要实现两大功能: ? 添加Web服务组件(即动态生成代理类) ? 调用Web服务组件的方法(方法由用户自己选择) 需要说明的是,由于Web服务的方法参数有类型和个数的差异,在调用方法之前,用户并不能清楚地知道方法参数的类型和个数,因此在调用方法模块中,需要让用户清楚的知道Web服务方法的参数的名称、类型、个数。因为只有这样,才能保证用户正确地调用方法。 3.2.3 Web服务组件 为了实现Web服务的动态组装,需要设计Web服务组件,这里可以设计两个Web服务组件来进行调用。它们是:学生成绩管理系统组件和好友查询系统组件。这些组件的功能如下: 1. 学生成绩管理系统 ? 增加学生信息 ? 查询指定学生的总分 ? 查询指定学生的加权平均分 ? 查询相关课程的任课教师 ? 查询指定教师姓名的详细信息 ? 查询指定学生指定科目的分数 2. 好友信息查询系统 ? 重置好友信息系统的登陆密码 ? 查询好友的电话号码 13 Web服务动态组装机制设计和实现 第三章 需求分析与总体设计 ? 查询好友目前的信息 ? 查询好友的过往情况 ? 查询好友的生日 在前面我们已经知道Web服务的重要意义之一是方便了企业间、企业与人之间等等的交互合作,以上两个服务组件的设计实际上是一种企业或组织提供服务给特定用户的一个表示。当然也可以设计其他的一些Web服务组件,但是由于本次设计的目的是在于动态调用Web服务,所以服务组件具体是什么并不重要。 3.3机制的主要组成 由上面的需求分析得知,该Web服务动态组装机制主要由三大部分组成，其组成关系如图3.1所示。 1.Web服务注册查询系统 ?利用外部企业提供的UDDI服务器实现的注册和查询模块 ?自己建立的私有内部UDDI服务器实现的注册和查询模块 这两个模块主要是为了方便发布者发布服务、请求者查询服务所用。 2.Web服务动态组装系统 ?动态添加服务模块 ?自由选择调用服务模块 这两个模块是为服务请求者自由添加服务，动态调用服务方法所用。 3. Web服务组件 ?学生成绩管理系统组件 ?好友信息查询系统组件 这两个组件是为测试Web服务动态调用所建，表示不同企业发布的服务组件，可由客户端用户自由选择不同企业的服务来组装。 图3.1 组成关系图 14 Web服务动态组装机制设计和实现 第三章 需求分析与总体设计 从图3.2可以知道，这三大组成成分之间的关系是:Web服务组件发布者在创建Web服务组件之后,将其发布,然后利用Web服务注册查询系统来注册相关信息(如商业实体信息,服务信息,技术指纹信息等)。其他用户可以通过Web服务注册查询模块来查询权限范围内(例如合作伙伴的Web服务)的Web服务,在查得URL或者WSDL文档地址后,用户可以利用Web服务动态组装系统来调用Web服务组件。 3.4 总体设计 根据需求分析,可以知道该机制需要实现三大部分:Web服务注册查询系统、Web服务动态组装系统、Web服务组件。为了提高该机制的安全性，本次设计采用了两层安全机制，一层用于系统本身安全即用户登录系统验证，第二层用于服务敏感信息安全即UDDI用户验证和授权。 由于微软的Windows2003服务器版本的操作系统中有微软开发的UDDI服务器组件,因此可以选windows2003作为开发平台。同时可以利用微软提供的UDDI.dll中封装了API的类来实现对微软提供的UDDI服务器和Windows2003内置UDDI服务器进行对外部UDDI服务器的注册和查询服务操作。在实现私有UDDI服务器的时候,可以利用IIS服务器来发布Web服务组件和发布开发的Web服务注册查询系统。服务调用模块,可以设计一个客户端小软件来实现Web服务的动态组装调用。这里的Web服务注册查询系统采用的是B/S模式,而Web服务动态组装调用系统则是一个C/S模式的客户端小软件。 3.4.1系统架构图 图3.2 系统架构图 15 Web服务动态组装机制设计和实现 第三章 需求分析与总体设计 图3.2表示了该机制的各个部分的组成及各部分之间的关系。图中有两个参与者:发布者和请求者。发布者创建Web服务组件，同时发布者可通过Web服务注册系统将服务信息发布到UDDI服务器。请求者通过Web服务注册查询系统向UDDI服务器来查询服务，同时可以根据查得的结果在Web服务动态组装系统中调用服务。 3.4.2功能结构图 Web服务动态组装机制的功能结构如图3.3所示。 Web服务动态组装机制 Web服务注册查询系统Web服务动态组装系统Web服务组件 外部企业内部私有学生好友添调用成绩信息UDDI服UDDI服加服务管理查询务器注册务器注册登录服系统系统查询服务查询服务方法务组件组件接口接口 注册查询服务授用户用户服务服务权登录注册 图3.3 功能结构图 3.4.3 Web服务注册查询子系统的功能模块简介 1.用户登录模块 为了保证系统的安全，只有合法用户才能享有该系统提供的服务。该模块用于验证合法用户。 2.用户注册模块 要想通过用户登录模块的验证，必须要有一个用户名和密码。那么这个模块就是用于注册合法用户。 3.注册服务模块 要注册一个可用的完整的Web服务信息，需要注册商业实体信息、服务信息、绑定模块信息、技术指纹信息等。因此该模块提供对这些信息的注册。同时 16 Web服务动态组装机制设计和实现 第三章 需求分析与总体设计 为了加强安全，该注册模块中还有对注册该服务信息的用户的注册子模块。以便用于服务授权和查询敏感信息的安全控制。 4.查询服务模块 该模块用于服务请求者查询服务，以获得要调用的服务信息。由于一个完整的服务包含商业实体信息、服务信息、绑定模块信息、技术指纹信息等，因此查询模块有对这些信息进行查询的子模块。服务请求者可以通过授权来查询Web服务的URL信息或WSDL文档地址信息。 5.服务授权模块 该模块是第二层安全机制的体现。在这个模块中。权限高的UDDI用户可以授权权限低的用户低于自己权限的权限。这样如果某用户想获得某个服务的敏感信息，可以先与拥有该服务较高权限的用户取得联系，让此用户授予他权限。 3.4.4 Web服务动态组装子系统的功能模块简介 1.用户登录模块 为了保证系统的安全，只有合法用户才能享有该系统提供的服务。该模块用于验证合法用户。 2.添加服务模块 该模块主要用于动态生成Web服务组件。用户只需要输入Web服务的WSDL文档的地址，便可以生成代理类来获得服务和相关方法。 3.调用服务方法模块 该模块通过添加服务模块获得方法后，可以动态产生服务组件的方法的参数，从而通过对参数的输入来获得调用结果。 3.5系统运行环境与开发平台 1.操作系统平台 根据需求分析,我确定以Windows2003企业版作为开发系统的平台。Windows 2003(全称Windows Server 2003)才是微软朝.NET战略进发而迈出的真正的第一步。它大量继承了Windows XP的友好操作性和Windows 2000 sever的网络特性,是一个同时适合个人用户和服务器使用的操作系统。 2.数据库平台 根据需求分析,我确定以SQL Server2005作为系统的数据库平台。SQL Server 2005是微软公司SQL Server生产线上的最受期待的产品。在成千上万的电子邮件、成百上千的规格说明以及大量的编译的基础上,SQL Server 2005确保了自己是Windows平台上数据库应用程序中最具戏剧性的新型数据库平台。 17 Web服务动态组装机制设计和实现 第三章 需求分析与总体设计 3.软件开发平台 综合考虑平台选择的3个要素,我确定的软件开发平台为Microsoft.NET,它完全能满足项目的技术需求,属于目前最先进的开发平台之一。 4.开发语言 我选择C#作为系统开发语言。C#语言是微软公司针对.Net平台才推出来的一门新语言,作为.Net平台的第一语言,它几乎集中了所有关于软件开发和软件工程研究的最新成果。 其中，Web服务注册查询子系统采用.Net平台的ASP.Net 2.0开发，以一个B/S模式的网站来实现,开发语言为C#。Web服务动态组装子系统将采用C/S模式以一个客户端小软件来实现。 3.6本章小结 本章首先根据课题任务，对课题任务进行了分析得出了详细的需求。然后根据需求对整个机制的各个系统进行了总体的描述和设计。同时也对系统间的相互关系以及开发环境进行了介绍。 18 Web服务动态组装机制设计和实现 第四章 详细设计与实现 第四章 详细设计与实现 从需求分析和总体设计可以知道，Web服务动态组装机制主要由Web服务注册查询系统、Web服务动态组装系统和Web服务组件组成。Web服务注册查询系统实现服务发布者(即Web服务组件创建者)发布服务信息和服务请求者(即用户)查询服务信息的功能，即使在服务信息改变的情况下，只要服务发布者在该系统更新了服务信息，那么服务请求者就能依据最新的正确的服务信息来调用服务，而不需重新编译系统。Web服务动态组装系统采用了动态创建Web服务代理类的方法，只要获得正确的Web服务的URL地址，服务调用者(即用户)便可以在运行的时候，自由选择服务并获得正确的结果。其体系结构如图4.1所示。 其中，两大子系统的设计与实现是完成该机制功能的关键部分，而Web服务组件只是为了测试调用服务而设计的，其具体功能的设计与实现并不重要，因此在本章将不做详细介绍。 为了保证系统安全以及敏感信息安全，本次设计采用了两层安全机制，第一层用于系统本身安全即系统用户登录验证，第二层用于服务敏感信息安全即UDDI用户验证和授权。这两层安全机制的使用将会在本章的部分小节介绍。 4.1 体系结构图 根据图4.1，本章将对数据存储层的数据库设计、Web服务注册查询子系统详细设计与实现和Web服务动态组装子系统详细设计与实现等三个部分予以介绍。 19 Web服务动态组装机制设计和实现 第四章 详细设计与实现 4.1 数据库详细设计 Web服务动态组装机制由Web服务注册查询系统、Web服务动态组装系统和Web服务组件三大部分组成，其中每个部分都与数据库有交互，并且为了提高该机制的安全性，采用了两层安全机制，其中第一层用于保证系统安全，第二层用于保证发布服务的敏感信息安全。这两层安全机制的实现与数据库的设计密不可分。因此数据库在该机制中起着很重要的作用。 用于两个子系统和Web服务组件的数据库有:自己设计的4个私有数据库和一个UDDI架构通用的UDDI注册中心数据库(关于UDDI架构可以查询W3C官方网站)。私有数据库分别是:UDDIDB、WebService、StudentManager、GoodFriend。数据库组成如图4.2所示。 数据库 Web服务注册查询Web服务组件后台数据库Web服务注册查询系统和Web服务 系统后台数据库动态组装系统用户管理数据库 StudentManagGoodFriendUDDIDB数据库WebService数据库er数据库数据库 图4.2 数据库组成 UDDIDB数据库是与Web服务注册查询系统交互的数据库，该数据库用于保存注册的商业实体、服务、绑定、技术指纹等等信息。Web服务注册查询系统通过注册操作将数据保存到该数据库，并通过查询操作来访问数据库。为了保证敏感信息的安全，该数据库设计了专门为第二层安全机制服务的表。 为了确保两大子系统只能被合法用户使用，设计了WebService数据库来实现第一次安全机制，该数据库虽然只有一张用户表users，但是为了供Web服务注册查询系统和Web服务动态组装系统的用户登录验证使用，其功能单一，因此做了一个单独的数据库。 StudentManager数据库和GoodFriend数据库是用于测试的Web服务组件的数据库。前者与学生成绩管理组件交互，用于管理学生、教师、课程、分数等等信息。后者与好友信息管理组件交互，用于管理好友信息管理组件的用户、好友分类、好友信息、好友不同阶段信息等等。 本节将对每个数据库的表组成、表的用途、表间关系、表的结构、视图和存储过程设计等等方面进行介绍。 20 Web服务动态组装机制设计和实现 第四章 详细设计与实现 4.1.1数据库表的组成及表关系 1.UDDIDB数据库 UDDIDB数据库的所有表组成如图4.3所示。 UDDIDB数据库 tModel表users表 BusinessService表BusinesstModelType表userRights表BusinessEntity表 BindingTemplate表BusinessEntityType表BusinessServiceType表 图4.3 UDDIDB数据库的表组成 UDDIDB数据库总共包含9张表。这9张表分别是:用户表users，管理注册查询服务的UDDI用户信息，用于第二层安全;用户权限表userRights，管理服务敏感信息的权限，用于第二层安全;商业实体表BusinessEntity，管理商业实体信息(即开发Web服务的企业或组织信息);服务表BusinessService，管理服务信息;绑定模板表BindingTemplate，管理绑定信息;技术指纹表tModel，管理技术指纹信息;商业实体类型表BusinessEntityType，服务类型表BusinessServiceType，技术指纹类型表BusinesstModelType分别管理商业实体、服务、技术指纹的类型信息。这9张表之间的关系如图4.4，图4.5，图4.6所示。 图4.4 商业实体关系图 UDDIDB数据库表与表之间通过外键相互关联。图4.4表示表BusinessEntity 与表BusinessEntityType、BusinessService、users之间的关系。其中表 21 Web服务动态组装机制设计和实现 第四章 详细设计与实现 BusinessEntityType的主键Id在表BusinessEntity中做外键，对应字段为businessTypeId，表示属于同一商业实体类型的商业实体可以有多个。其中表BusinessEntity的主键businessId在表BusinessService中做外键，表示一个商业实体可以有多个服务。其中users表中的主键在表BusinessEntity中做外键，表示一个uddi用户可以注册多个商业实体信息。 图4.5 服务信息关系图 图4.5表示服务信息表BusinessService与表BusinessServiceType、表BusinessEntity、表BindingTemplate、表Tmodel之间的关系。其中表BusinessServiceType的主键Id在表BusinessService中做外键，对应字段为serviceTypeId，表示属于同一服务类型的服务可以有多个。其中表BusinessService 中的主键serviceId在表BindingTemplate中做外键，表示一个服务可以有多个绑定。其中表BusinessService中的主键serviceId在表Tmodel中的外键，表示一个服务可以对应多个技术指纹信息。 图4.6 技术指纹与权限关系图 22 Web服务动态组装机制设计和实现 第四章 详细设计与实现 图4.6表示技术指纹信息表Tmodel与表TmodelType、表userRights、，表users与表userRights之间的关系。其中表TmodelType中的主键Id在表Tmodel中做外键，对应字段为tmodelTypeId，表示同一类型的技术指纹可以有多个。其中表Tmodel的主键和表users的主键在userRights中做外键，表示某个uddi用户对某个技术指纹的读取权限。 2.WebService数据库 WebService数据库只包含一张用户表webUsers。该表通过Web服务注册查询系统的用户注册模块对其进行插入操作，通过Web服务注册查询系统和Web服务动态组装系统的用户登陆模块对其进行查询验证，用于第一层安全。 3.StudentManager数据库 StudentManager数据库的表组成如图4.7所示。 StudentManager数据库 classTeacher表 stuInfo表 course表score表 class表 teacher表 图4.7 StudentManager数据库的表组成 Web服务组件数据库StudentManager共包括6张表，分别是:学生基本信息表stuInfo，管理学生基本信息;班级表class，管理班级信息;课程表course，管理课程相关信息;成绩表score，管理学生不同科目成绩信息;教师表teacher，管理教师基本信息;班级授课教师表classTeacher，管理班级授课课程教师信息。 下图4.9中表示了该数据库的两大主要关系。一为表score、表course和表stuInfo三者之间的关系，其中表stuInfo中的主键stuId和表course中的主键courseId均是表score中的外键，并且二者组成score表中的联合主键，表示一个学生有多门课程的成绩。二为表teacher、表class和表course三者之间的关系，其中表teacher和表class中的主键均为表classTeacher的外键，表示每个班级的每个课程都有相应的老师。 23 Web服务动态组装机制设计和实现 第四章 详细设计与实现 图4.8 StudentManager数据库表关系图 4.GoodFriend数据库 GoodFriend数据库的表组成如图4.9所示。 GoodFriend数据库 currentInfo表user表 friendInfo表friendType表 图4.9 GoodFriend数据库的表组成 另一个Web服务组件数据库GoodFriend共包含4张表，分别是:用户表user，管理用户名和用户密码;好友信息表friendInfo，管理好友基本信息;好友类别表friendType，管理好友类型信息;好友目前信息表currentInfo，管理好友不同时期的基本信息。该数据库表与表之间的关系如图4.10所示。 下图4.10表示表users、表friendType、表friendInfo、表currentInfo四者之间的关系。其中表users中的主键userId在表friendInfo中做外键，表示一个用户可以拥有多个好友。表friendType中的主键typeId在表friendInfo中做外键，表示每个好友属于不同的好友类型即同一类型的好友有多个。表friendInfo的主键在表currentInfo中做外键，表示每个用户的每个好友可以有多个不同时期的信息。 24 Web服务动态组装机制设计和实现 第四章 详细设计与实现 图4.10 GoodFriend数据库表关系图 4.1.2表结构设计 1.UDDIDB数据库 系统用户表users的结构如表4.1所示。 表4.1 users表结构 序号 列名 数据类型 长度 允许为空 备注 1 userId int 4 主键，自动增长 2 userName varchar 30 用户名 3 userPwd varchar 10 密码 表4.1中字段userName表示uddi用户的名称，字段userPwd表示uddi用户的密码，uddi用户验证时需要和这张表的用户名和密码进行匹配认证。同时WebService数据库中唯一的一张表webUsers与该表的结构完全一样，所以后面不再做介绍。 权限管理表usersRights的结构如表4.2所示。 表4.2 userRights表结构 序号 列名 数据类型 长度 允许为空 备注 1 userId int 4 联合主键，外键 2 tModelId int 4 联合主键，外键 3 rightRank int 4 权限值 表4.2主要用于Web服务注册查询系统的敏感信息访问控制。 25 Web服务动态组装机制设计和实现 第四章 详细设计与实现 商业实体类型表BusinessEntityType的结构如表4.3所示。 表4.3 BusinessEntityType表结构 序号 列名 数据类型 长度 允许为空 备注 1 Id int 4 主键，自动增长 2 typeName varchar 100 名称 3 details varchar 300 ? 描述 表4.3中的字段typeName表示类型名称，字段detail表示类型描述。同时，表BusinessServiceType、表BusinesstModelType与此表结构完全一样。 商业实体表BusinessEntity的结构如表4.4所示。 表4.4 BusinessEntity表结构 序号 列名 数据类型 长度 允许为空 备注 1 businessId int 4 主键，自动增长 2 businessName varchar 100 名称 3 businessTypeId int 4 外键 4 userId int 4 外键 5 details varchar 300 ? 描述 表4.4中的字段businessName表示商业实体的名称，字段businessTypeId指向BusinessEntityType中的Id，字段userId指向users中的userId，字段details表示商业实体描述信息。 服务信息BusinessService的结构如表4.5所示。 表4.5 BusinessService表结构 序号 列名 数据类型 长度 允许为空 备注 1 serviceId int 4 主键，自动增长 2 serviceName varchar 100 名称 3 businessId int 4 外键 4 serviceTypeId int 4 外键 5 details varchar 300 ? 描述 表4.5中的字段serviceName表示服务称，字段businessId指向表BusinessEntity的主键，字段serviceType指向表BusinessServiceType中的Id，字段details表示服务描述信息。 服务绑定信息表BindingTemplate的结构如表4.6所示。 表4.6 BindingTemplate表结构 序号 列名 数据类型 长度 允许为空 备注 1 bindingId int 4 主键，自动增长 2 serviceId int 4 外键 3 accessPoint varchar 100 4 details varchar 300 ? 描述 表4.6中的字段serviceId指向BusinessService中的主键，accessPoint表示服务绑定的地址，details表示绑定描述信息。 26 Web服务动态组装机制设计和实现 第四章 详细设计与实现 技术指纹信息表如表4.7所示。 表4.7 Tmodel表结构 序号 列名 数据类型 长度 允许为空 备注 1 tmodelId int 4 主键，自动增长 2 serviceId int 100 外键 3 tModelName varchar 100 名称 4 wsdlUrl varchar 100 wsdl地址 5 tModelType int 4 外键 6 details varchar 300 ? 描述 表4.7中的字段tModelName表示技术指纹名称，wsdlUrl表示服务文档的地址，details表示技术指纹的描述信息。 2.StudentManager数据库 学生信息基本表stuInfo，班级信息表class，课程信息表course，学生成绩表score的结构分别如表4.8，4.9，4.10，4.11所示。 表4.8 stuInfo表结构 序号 列名 数据类型 长度 允许为空 备注 1 stuId int 4 主键，自动增长 2 stuName varchar 20 名称 3 stuSex char 2 性别 4 cardId char 20 省份识别号 5 stuAddress varchar 60 ? 地址 6 birthday datetime ? 生日 表4.8中的字段stuName表示学生姓名，stuSex表示性别，cardId表示身份证号码，stuAddress表示住址，birthday表示出生年月。 表4.9 class表结构 序号 列名 数据类型 长度 允许为空 备注 1 classId int 4 主键，自动增长 2 className varchar 20 名称 表4.9中的字段className表示班级名称。 表4.10 course表结构 序号 列名 数据类型 长度 允许为空 备注 1 courseId int 4 主键，自动增长 2 courseName varchar 20 名称 3 courseScore int 4 学分 表4.10中的字段courseName表示课程名称，courseScore表示课程学分。 表4.11 score表结构 序号 列名 数据类型 长度 允许为空 备注 1 stuId int 4 联合主键，外键 2 courseId int 20 联合主键，外键 3 score int 4 学分 27 Web服务动态组装机制设计和实现 第四章 详细设计与实现 表4.11中的字段stuId和courseId均为外键，分别指向stuInfo中的主键stuId和course表中的courseId。字段score表示某学生某课程的分数。 教师表teacher和班级授课教师表classTeacher的结构分别如表4.12和4.13所示。 表4.12 teacher表结构设计 序号 列名 数据类型 长度 允许为空 备注 1 teacherId int 4 主键，自动增长 2 teacherName varchar 20 名称 3 sex char 2 性别 4 phone varchar 13 ? 电话号码 5 birthday datetime ? 生日 其中字段teacherName表示教师姓名，sex表示教师性别，phone表示联系电话，birthday表示出生日期。 表4.13 classTeacher表结构设计 序号 列名 数据类型 长度 允许为空 备注 1 classId int 4 联合主键，外键 2 teacherId int 4 联合主键，外键 3 courseId int 4 联合主键，外键 其中字段classId、teacherId，courseId均为外键，分别指向class表中的classId、teacher表中的teacherId和course表中的courseId。 3.GoodFriend数据库 好友基本信息表、好友类型表和不同时期好友信息表的结构分别如表4.14、4.15、4.16所示。 表4.14 friendInfo表结构 序号 列名 数据类型 长度 允许为空 备注 1 friendId int 4 主键,自动增长 2 friendName varchar 20 名称 3 sex char 2 性别 4 birthday datetime ? 生日 5 address varchar 50 ? 地址 6 phone varchar 13 ? 电话 7 typeId int 4 外键 8 useId int 4 外键 表4.14中字段typeId和userId分别指向好友类型信息表和好友信息管理组件的用户信息表。 表4.15 friendType表结构 序号 列名 数据类型 长度 允许为空 备注 1 typeId int 4 主键 2 typeName varchar 20 名称 28 Web服务动态组装机制设计和实现 第四章 详细设计与实现 表4.15中的typeName表示好友类型名称。 表4.16 currentInfo表结构 序号 列名 数据类型 长度 允许为空 备注 1 friendId int 4 联合主键，外键 2 startTime datetime 联合主键，起始时间 3 endTime datetime 联合主键，结束时间 4 phone varchar 13 ? 电话 5 jobName varchar 30 职位 6 comanpy varchar 50 ? 公司名字 7 address varchar 50 ? 现居地址 8 email varchar 30 ? Email 表4.16中的字段startTime和endTime表示一段时间的起始点和终止点，二 者与friendId唯一标识该表的项，表示某段时期的某个好友的信息。字段jobName表示职位名称，company表示就职单位名称，address表示该阶段的住址。 4.1.3 视图和存储过程设计 本次数据库设计最重要的数据库也是较为复杂的数据库是UDDIDB数据 库，由于该数据库是用于保存和查询服务注册等信息的，所以该数据库设计了一 些视图和存储过程，以方便服务注册、服务查询、授权处理等应用。 这个小节将对UDDIDB数据库的视图和存储过程做简单介绍。 1.主要视图介绍 下面几个视图主要服务于web服务的查询和权限管理:视图 v_tmodelname_tid，视图v_tmodel_user，视图v_tmodel_right，视图 v_tmodel_user_name。其中前三个视图均用于技术指纹信息查询与注册，而第四 个视图主要用于授权模块。 v_tmodel_user_name视图的sql语句如下所示: select x.tmodelId, x.tmodelName, x.userId, dbo.users.userName from (select b.userId, a.tmodelId, a.tmodelName from (select s.businessId, t.tmodelId, t.tmodelName from dbo.Tmodel as t inner join dbo.BusinessService as s on t.serviceId = s.serviceId) as a inner join dbo.BusinessEntity as b ON a.businessId = b.businessId) as x inner join dbo.users on x.userId = dbo.users.userId 2.存储过程设计 表4.18简单介绍了该数据库的存储过程及其用途。 29 Web服务动态组装机制设计和实现 第四章 详细设计与实现 表4.18 UDDI数据的存储过程简介表 序号 名称 用途 1 pro_nameExist 用于判断用户名是否存在 2 pro_register 用于注册用户 3 pro_business_type_register 用于注册商业实体类别信息 4 pro_service_type_register 用于注册服务类别信息 5 pro_tmodel_type_register 用于注册技术指纹类型信息 6 pro_binding_register 用于注册绑定信息 7 pro_business_register 用于注册商业实体信息 8 pro_service_register 用于注册服务信息 9 pro_tmodel_register 用于注册技术指纹信息 10 pro_right_register 用于修改权限 为了在编写代码的时候更加简单方便，我在数据库后台设计了上面的存储过程，主要用于UDDI用户的注册、验证，商业实体、服务、技术指纹等信息的注册以及服务授权等功能的实现。 4.2 Web服务注册查询系统功能详细设计与实现 从前面的需求分析和总体设计章节可以知道该系统总共包括7个功能模块:用户注册模块，用户登录模块，服务注册模块，服务查询模块，服务授权模块，外部UDDI注册模块，外部UDDI查询模块。由于这个系统采用了两层安全机制，只有已经登录的合法用户才能使用注册、查询和授权功能。整个系统，首先由普通用户注册为该系统合法用户后，然后通过用户登录模块登录系统，然后才可以执行注册或查询或授权操作。程序的实现也是基本按照该流程描述的步骤逐步实施的，每个功能作为程序的一个模块，系统的功能流程描述如下: ?用户通过用户登录模块登录系统，如果没有用户名，用户可以先进入注册模块注册为该系统的合法用户。 ?用户登录后可以自由选择进入系统不同页面。 如果用户选择进入服务注册页面，用户需先注册一个UDDI用户，如果已? 经注册了UDDI用户，此UDDI用户注册模块也可以充当验证功能，它将返回该UDDI用户的userId。在获得userId后，用户可以注册商业实体模块，从而获得商业实体的businessId，根据获得的businessId接着继续注册服务模块，从而获得服务的businesssId，根据获得serviceId最后注册技术指纹tmodel模块。 ?如果用户选择进入服务查询模块，用户可以自由选择不同的查询模块，如查询商业实体信息等。没有顺序限制。 ?如果用户进入授权模块(该模块页面只有登录的用户才可以看到，其他模块非登录用户也可以看到，但是不能使用功能)，合法用户需登录自己的UDDI 30 Web服务动态组装机制设计和实现 第四章 详细设计与实现 用户账号，可以在该UDDI用户权限范围内进行授权。 4.2.1Web服务注册查询子系统详细功能划分 Web服务注册查询子系统主要由内置私有的UDDI注册查询中心和外部UDDI注册查询接口组成。 其中私有UDDI注册查询中心包括的功能模块为用户注册登录和注册模块、服务授权模块、服务注册和查询模块，其中服务注册模块包括的功能有注册UDDI用户、注册商业实体信息、注册服务信息、注册技术指纹信息，服务查询模块包括的功能有按照服务名查询、按照商业实体名查询、按照技术指纹名查询。 由于外部UDDI注册接口模块与私有UDDI注册查询中心的服务注册模块的功能完全一样，只是注册的UDDI服务器地址不一样，所以在本章只介绍私有的UDDI注册查询中心的服务注册模块。而外部UDDI查询接口模块只提供了按商业实体名查询和按技术指纹名查询，这里用到了微软提供的Uddi.dll库文件，实际上该模块的查询原理与私有UDDI注册查询中心的服务查询模块基本一样，因此也不作详细介绍。Web服务注册查询系统详细功能划分如图4.11所示。 图4.11 Web服务注册查询系统详细功能图 31 Web服务动态组装机制设计和实现 第四章 详细设计与实现 4.2.2用户注册和登录模块 只有在用户登录模块通过验证后，用户才能享有注册、查询、授权等功能。而此登录模块比较简单，只要输入合法的用户名和密码便可登录成功，与其他系统登录功能基本一样，所以其详细设计与实现不做介绍。用户登录和注册模块主要通过使用User类的属性与方法来实现，其类图如图4.12所示。 图4.12 User类图 其中属性name为用户名，属性pwd为密码，类型均为字符串string。构造函数有两个参数，这两个参数分别对两个属性赋值。成员函数userTestName用于检查用户名是否存在，如果存在则返回false否则返回true。成员函数userRegister用于注册用户，注册成功将返回true，否则返回false。成员函数userLogin用于验证用户是否为合法用户，如果返回值是非0值则证明是，否则不是。该类的所有方法的访问属性都为public。 4.2.3服务注册模块 此模块主要包括四大子模块:UDDI用户注册(也有验证功能)，商业实体注册，服务注册，技术指纹注册。 针对此模块，将分别从程序描述、数据流程、程序流程、类设计等四部分予以介绍。 1.程序描述 商业实体注册包括商业实体类型信息注册和商业实体信息注册，商业实体注册部分的注册成功是以UDDI用户成功注册为前提的。同时商业实体注册的两个部分存在顺序问题，只有注册商业实体类型信息成功后，才能成功注册商业实体信息。 服务注册部分包括服务类型信息注册、服务信息注册，服务信息注册部分同时也注册了绑定信息，服务注册部分的成功注册是以商业实体的成功注册为前提 32 Web服务动态组装机制设计和实现 第四章 详细设计与实现 的。同时服务注册的两个部分也存在顺序问题，只有注册服务类型信息成功后，才能成功注册服务信息和绑定信息。 技术指纹注册部分包括技术指纹类型信息注册和技术指纹信息注册，技术指纹注册部分的成功注册是以服务信息的成功注册为前提的。同时技术指纹注册的两个部分也存在顺序问题，只有注册技术指纹类型信息成功后，才能成功注册技术指纹信息。 2.数据流程 图4.13 服务注册数据流程图 从数据流程图可以看出，每个模块的注册都依赖于前面模块的成功注册。数据流动的过程有以下几步: ?用户注册UDDI用户账号等信息获得一个userId。 ?只有同时获得userId和在注册商业实体类型成功后返回的类型Id，才可注册商业实体信息，因为每个商业实体信息都归一个UDDI用户所有并且属于一种 类型，注册成功后返回商业实体businessId。 ?只有同时获得businessId和在注册服务类型成功后返回的类型Id，才可以注册服务信息和绑定信息，注册成功后返回服务serviceId。 ?只有同时获得serviceId和在注册技术指纹类型成功后返回的类型Id，才可以注册技术指纹信息，注册成功后将直接将该技术指纹的创建者权限写入权限表，最后结束整个注册过程。 3.程序流程 下图4.14和下图4.15显示了注册模块的主要流程。 33 Web服务动态组装机制设计和实现 第四章 详细设计与实现 开始 进入服务注册页面 输入用户名和密码 是 该用户名是否存在验证密码否 否 注册到数据库密码是否正确否是 注册是否成功 是图4.14 UDDI用户注册流程图 图4.14显示了UDDI用户注册的过程。只有在这个过程中注册成功后，才获得UDDI用户Id结束 能获得UDDI用户的Id，这样才能进行后面的注册。 开始 进入商业实体注册模块 输入商业实体类别信息 否类型和UDDI用户 注册成功, 是 输入商业实体信息 注册商业实体信息 否 图4.15 商业实体注册流程图 商业实体信息是否注册成功 图4.15显示了商业实体注册的过程，只有当商业实体注册成功并获得商业 是 34 保存商业实体的Id结束 Web服务动态组装机制设计和实现 第四章 详细设计与实现 实体的Id，才能进行服务信息的注册。而服务注册流程、技术指纹注册流程和商业实体注册流程基本相近，区别在于服务模块注册的时候需要在商业实体注册成功后(即获得商业实体的Id)后才能成功注册，同时注册服务成功后将保存服务Id，技术指纹注册模块需要在服务模块注册成功后(即获得服务Id)才能成功注册。 4.类设计 uddiUser类主要用于第二层安全机制，在注册服务模块和授权模块将会用到，与之交互的数据库表是UDDIDB数据库的user表。类结构如图4.16所示。 图4.16 User类的类图 该类的成员函数userTestName用于检查用户名是否存在，如果存在则返回false否则返回true。成员函数userRegister用于注册用户，注册成功将返回true，否则返回false。成员函数getUserId用于获取该用户在数据库UDDIDB的表users中的userId，如果返回值大于0则将返回对应的userId，否则表示数据库中没有该用户。成员函数gettmodelId通过传入tmodel的名字获得在数据库UDDIDB表Tmodel中的tmodelId值，如果返回值大于0则返回对应的userId，否则表示数据库中不存在这样的tmodel项。成员函数getRightbyTmodelId通过传入tmodelId值可以获得对应用户对应tmodel的权限值，如果返回值大于0表示返回权限值，否则表示不存在该用户该tmodel的项。该类的所有成员函数的访问属性都为public。 Type类主要用于服务注册模块和服务查询模块的商业实体类型、服务类型、技术指纹类型的注册和查询。与之交互的是UDDIDB数据库的BusinessEnityType 表，BusinessServiceType表和tmodelType表。类结构如图4.17所示。 35 Web服务动态组装机制设计和实现 第四章 详细设计与实现 图4.17 Type类图 该类的成员函数ServiceTypeRegister用于注册服务类型信息，如果返回值大于0将返回注册成功的服务类型的Id，否则注册失败。成员函数BusinessTypeRegister用于注册商业实体类型信息，如果返回值大于0将返回注册成功的商业实体类型的Id，否则注册失败。成员函数TmodelTypeRegister用于注册技术指纹类型信息，如果返回值大于0将返回注册成功的技术指纹类型的Id，否则注册失败。该类的所有成员函数的访问属性都为public。 BusinessEntity类主要用于注册商业实体模块，与之交互的数据库表是UDDIDB数据库的BusinessEntity表。其类结构如图4.18所示 图4.18 BusinessEntity类图 该类的成员函数SavebusinessEntity用于注册商业实体信息，如果返回值大于0将返回商业实体的Id号，否则注册失败。所有成员函数的访问属性都为public。 BusinessService类主要用于注册服务和服务绑定信息，与之交互的数据库表是UDDIDB数据库的BusinessService和BindingTemolate表。类结构如图4.19所示。 36 Web服务动态组装机制设计和实现 第四章 详细设计与实现 图4.19 BusinessService类图 该类的成员函数SaveService用于注册服务信息，如果返回值大于0将返回服务的Id号，否则注册失败。成员函数SaveBinding用于注册绑定模块信息，如果返回值大于0将返回绑定的Id号，否则注册失败。所有成员函数的访问属性都为public。 Tmodel类主要用于技术指纹信息的注册。与之交互的数据库表是UDDIDB数据库的Tmodel表。类结构如图4.21所示。 图4.20 Tmodel类图 该类的成员函数getUserId用于在注册tmodel权限时，获取拥有tmodel权限的用户Id，如果返回值大于0表示该tmodel的创建用户在数据库中存在，否则失败。成员函数SaveTmodel用于注册技术指纹信息，如果返回值大于0将返回技术指纹的Id号，否则注册失败。成员方法save_manager_rights用于技术指纹的创建者权限写入，如果返回值大于0表示写入成功，否则失败。所有成员函数的访问属性都为public。 37 Web服务动态组装机制设计和实现 第四章 详细设计与实现 4.2.4服务查询模块 该模块分为按商业实体名查询，按服务名查询和按技术指纹名查询三大子模块。其功能结构如图4.21所示。 针对此模块，将从程序描述和类设计两个方面予以介绍。 1.程序描述 查询模块的所有查询都是按名字查询，并且名字的匹配都采用了模糊匹配，不需要输入非常精确的查询字符。 在按商业实体名字查询子模块中，用户首先需要输入商业实体名称，然后才可以选择查询商业实体信息、服务信息、技术指纹信息中的任一种，点击查询按钮后，将会在结果显示控件中显示结果集合。 在按服务名字查询子模块中，用户首先也需要输入服务名称，然后才可以选择查询服务信息或技术指纹信息，点击查询按钮后，将会在结果显示控件中显示结果集合。 在按技术指纹查询子模块中包括两个不同权限级别的查询。一个是直接按照技术指纹名称查询技术指纹的非敏感信息(即除服务文档地址之外的信息)。另一个是需要进行UDDI用户登录认证，只有当登录的UDDI用户拥有对该服务文档地址信息读取权限的时候，才会显示对应技术指纹服务文档的地址。在登录之后，继续输入前面查询得到的技术指纹名字和服务名字组合，点击查询按钮，将会在对应结果显示控件中显示结果集合。 图4.21 查询模块功能结构图 2.类设计 服务查询模块的查询实现主要依赖于search类的使用。此类只有一个数据库连接字符串的成员变量，因此不给出类图了。 其中成员函数getResult(string sql,string name)用于根据名称查询，返回结果为一个字符串。 成员函数gettModelResult(string sname,string tname)用于根据服务名称和技 38 Web服务动态组装机制设计和实现 第四章 详细设计与实现 术指纹名称查询敏感信息wsdl，其返回结果为一个字符串。 成员函数getRight(string userName, string tname, string sname)用于查询权限，其返回值类型为整型int。 所有成员函数的访问属性都为public。 4.2.5授权模块 为了保证企业之间的敏感信息安全，需要采取一些安全措施。在这里所谓的敏感信息就是指服务文档的地址，因此为了保证该敏感信息只能被拥有该信息访问权限的用户获取，这里设计了授权模块用于对与企业取得联系并得到授权许可的用户进行授权。同时拥有高于访问权限(也叫读取权限)的用户可以授权给较低权限用户低于授权者本身权限的权限。 为了要授权，授权者必须进行UDDI用户的登录验证，验证通过后将获得授权者的UDDI用户Id，然后通过给出的技术指纹名称获得授权者UDDI用户对该技术指纹的权限，通过该权限来判断授权者是否能够对指定用户授予指定权限(只能是高权限给低权限者授权，并且授予的权限小于授权者本身权限)。授权的成功与否将在界面上做出提示。该模块的流程如图4.22所示。 开始 进入服务授权页面 输入UDDI用户名和 密码否 验证是否通过 是 输入被授权用户名 称 输入被授权的技术 指纹名称 获得此UDDI用户对 该技术指纹的权限 图4.22 授权流程图 输入权限等级 39 获得的权限是否否高于输入的权限 是 授权失败 授权成功 结束 Web服务动态组装机制设计和实现 第四章 详细设计与实现 4.2.6外部UDDI注册接口和查询接口模块 外部UDDI注册接口模块主要是为了方便用户将自己的Web服务组件发布到其他的UDDI服务器，这里我采用了微软开发的UDDI服务器，同时用到了微软提供的Microsoft Uddi.dll 文件，该文件中封装了UDDI注册API和查询API。 要将服务发布到其他的UDDI服务器，必须知道该注册服务器的URL，因此用户需要输入UDDI注册中心的URL。同时我们已经知道要注册一个完整的Web服务信息，需要注册商业实体信息、服务信息、绑定信息、技术指纹信息，由于这些注册部分与前面的私有UDDI各部分注册基本差不多，因此不再累述。 外部UDDI查询接口模块主要是为了方便用户能够查询注册到外部UDDI服务器的服务信息。此模块的查询设计比较简单，只有按照商业实体名称查询和按照技术指纹名称查询两种方式。由于是查询外部UDDI服务器，因此需要输入外部UDDI查询服务器的地址，在输入了外部UDDI服务器地址之后，用户便可以在按商业实体名称查询和按技术指纹名称查询这两种查询方式中择其一进行查询。这里的查询其实与前面的查询模块没多大区别。不同的是这里采用了Microsoft Uddi.dll中对查询API封装的类。因此在此不再累述。 4.3 Web服务动态组装系统功能详细设计与实现 在开发Web服务客户程序的过程中，要使用“添加Web引用”来添加Web服务引用并生成代理类代码。本系统实际上是一个客户端程序，为了实现动态化，该系统将这个生成代理类代码的过程自动化(即动态化)。这样，只要用户给出WSDL文档来动态生成代理类代码，并创建相应的代理类对象实例，那么就可以在运行时通过代理类对象来调用服务方法。代理类DynamicWebServiceProxy将在本章添加服务模块的类设计中详述。 该系统包括三大功能模块:登录、添加服务、调用方法，其中登录模块与Web服务注册查询系统的用户登录模块作用和设计实现完全一样，因此不再讲述。Web服务动态组装子系统的功能划分如图4.23所示。 图4.23 Web服务动态组装系统详细功能图 40 Web服务动态组装机制设计和实现 第四章 详细设计与实现 4.3.1添加服务模块 用户首先需要输入WSDL文档的URL地址(该URl地址的可以通过在Web服务查询系统中查询得到)，如果输入的URL地址真实存在，便可动态添加该URl地址的Web服务组件，在添加服务后系统会动态添加该服务组件的所有方法，随后用户就可以选择需要的服务组件方法来调用了。由于不同的方法可能会有不同的参数个数和参数类型，因此系统在调用方法后会动态产生方法的所有参数并且显示各个参数的类型，这样用户就可以根据类型来对参数赋值，从而可以获得正确的结果。 针对此模块，将从程序描述、程序流程、类设计、关键代码等四个方面予以详细介绍。 1.程序描述 该模块的主要功能是根据给定的服务文档(WSDL)的地址,动态创建代理类DynamicWebServiceProxy的对象，然后创建该代理类实例(即Web服务)的所有Web服务方法。因此需要用户输入服务文档地址，同时该系统需要有提供和显示Web服务方法的功能。 2.程序流程 此模块的流程图如图4.24所示。 图4.24 添加服务模块流程图 41 Web服务动态组装机制设计和实现 第四章 详细设计与实现 从图4.24可以得知该模块的执行流程大致上可以分为以下几步: (1) 用户输入WSDL文档的地址 (2) 根据用户输入的WSDL文档的地址获取WSDL文档的内容 (3) 使用相应的类从WSDL文档生成C#源代码 (4) 对生成的源代码进行相应的修改，以使之符合要求 (5) 使用相应的类编码源代码，并把它保存在一个临时的程序文件中 (6) 从临时的程序文件加载程序集并生成代理类对象 (7) 从代理类对象中获取成员方法等各种信息 (8) 用户输入相应方法的参数 (9) 使用用户输入的参数调用相应的方法并显示返回结果。 3.类设计 该系统只有一个非常重要的类即Web服务代理类DynamicWebServiceProxy，该类用于在客户端创建Web服务代理对象，也就是说用于动态添加服务。其类图如图4.25。 图4.25 DynamicWebServiceProxy类图 其中属性protocolName为协议名称，用户可以使用3种协议:Soap、HttpGet和HttpPost，默认值为Soap。属性assfileName为动态创建的程序集的名称。属性proxySource用于保存根据WSDL文档自动生成的代理类源代码。 其中构造函数 public DynamicWebServiceProxy(string wsdlSourceName)，具有一个参数，用户可以通过这个参数来传递WSDL文档的URL地址或保存WSDL文件的文件名，用户还可以通过直接传递包含WSDL文档内容的字符串。 成员函数 private string GetWsdl(string source)用于获取WSDL文档的内容。 成员函数private string GetWsdlFromUri(string uri)用于使用指定的URL获取WSDL文档。 42 Web服务动态组装机制设计和实现 第四章 详细设计与实现 成员函数private string GetWsdlFromFile(string fileFullPathName)用于从本地文件中读取WSDL文档。 成员函数 private void BuildAssemblyFromWsdl(string strWsdl)用于根据知道的WSDL文档生成程序集。 成员函数public object CreateInstance()用于创建代理类对象实例。 成员函数private void ApplyLogExtension()用于读取SOAP扩展源代码。 4.关键代码 //通过给出的wsdl文档的url地址，创建代理类对象 dynProxy = new DynamicWebServiceProxy(TxtWsdlUrl.Text); //创建代理类实例 objProxy = dynProxy.CreateInstance(); LblProxy.Text = objProxy.ToString(); //获取代理类中的方法 Type proxyType = objProxy.GetType(); //指定获取公共的实例方法 MethodInfo[]mis=proxyType.GetMethods(BindingFlags.ExactBinding|BindingFlags.Public| BindingFlags.Instance); 4.3.3调用方法模块详细设计与实现 每个Web服务组件都是由不同功能的方法组成，而每个方法都有不同的参数列表，这些参数列表因个数和类型的不同而不同。要正确调用方法，必须传入正确类型的参数。因此在调用方法模块中，系统需要让用户选择方法，在选择方法后产生所选择方法的参数列表，然后用户根据参数类型提示依次对各个参数进行赋值，赋值后调用方法便可获得正确的结果。 程序流程描述如下: (1) 选择要调用的方法 (2) 点击调用方法按钮，产生该方法的参数列表。 (3) 如果参数个数不为0，依次对该方法的参数进行赋值，否则不需赋值。 (4) 待该方法的所有参数赋值后，点击确定按钮。 (5) 显示结果。 该模块调用方法和对参数赋值的关键代码如下所示。 43 Web服务动态组装机制设计和实现 第四章 详细设计与实现 //将选择的列表项转换为MethodInfo对象 MethodInfo mi = (MethodInfo)(LbxMethods.SelectedItem); ParameterInfo[] pis = mi.GetParameters(); object[] theParams = null; if(pis.GetLength(0) > 0)//用户输入方法的参数 {FormInputParams formInput=new FormInputParams(); formInput.pis = pis; if(DialogResult.OK == formInput.ShowDialog(this)) {theParams=new object[formInput.lbxValues.Items.Count]; for(int i = 0; i < formInput.lbxValues.Items.Count; i++) {if (formInput.lbxValues.Items[i].ToString() == "未赋值") theParams[i]=null; else {TypeConverter tc=new TypeConverter(); Type t = pis[i].ParameterType; theParams[i]=TypeDescriptor.GetConverter(t).ConvertFromString( formInput.lbxValues.Items[i].ToString());} }} else return;}//如果用户取消输入参数，则直接返回 object obj = mi.Invoke(objProxy, theParams);//调用方法 4.4本章小结 本章针对组成该机制的两大子系统:Web服务注册查询系统和Web服务动态 组装系统，首先介绍了与系统交互的数据库后台设计，然后从程序描述、程序流 程、类设计和关键代码等方面详述了每个系统的各个功能模块。 44 Web服务动态组装机制设计和实现 第五章 运行实例 第五章 运行实例 Web服务动态组装机制主要由Web服务注册查询子系统和Web服务动态组装子系统组成。其中Web服务注册查询子系统是一个B/S模式的网站，而Web服务动态组装子系统是一个C/S模式的客户端软件。下面将给出这两个子系统的部分运行实例，并对其结果进行分析。 5.1Web服务注册查询系统运行测试 该系统最重要的三大功能模块为服务注册、服务查询和服务授权。用户若想进行服务注册、服务查询和服务授权这三大操作，必须先进入用户登录模块进行系统用户的登录验证，只有通过验证的用户，才能有此操作权利，如果没有该系统的用户账号，可以通过用户注册模块先获取，由于用户登录和用户注册模块与一般系统的用户登录与注册类似，功能实现简单，所以针对该系统，将主要详述服务注册、服务查询和服务授权这三大功能模块的运行实例。 5.1.1服务注册运行测试 1.测试实例 功能描述:用户进入服务注册页面之后，首先需要注册一个UDDI用户，因为后面的所以注册信息均归属于该UDDI用户，如果系统用户已经拥有了一个UDDI用户账号，UDDI注册操作也有认证功能。如果UDDI用户注册成功，系统用户将可以进行商业实体信息、服务信息、技术指纹信息等的注册，其中这三大信息注册前后依赖，只有前一种信息注册完后，才能成功注册后一种信息，三大信息都注册成功才能表示一个完整的服务注册成功。如果UDDI用户注册失败，系统将提示出错信息，后面的注册功能将不可用。 测试用例: 1)UDDI用户注册没有成功。 2)成功UDDI用户，不注册服务信息，直接注册技术指纹失败。 3)成功注册一个完整的服务。 测试步骤: 1)输入两个不同的UDDI注册密码。 2)注册一个新的UDDI用户名和商业实体信息，不注册服务信息，直接注 册技术指纹信息。 3)正确的UDDI用户注册，正确的注册顺序。 45 Web服务动态组装机制设计和实现 第五章 运行实例 2.测试结果 1)对于“输入两个不同的UDDI注册密码”，提示“两次输入的密码不同，请重新输入”。 2)对于“注册一个新的UDDI用户名和商业实体信息，不注册服务信息，直接注册技术指纹信息”，提示“请确保服务注册成功和类型注册成功”，如图5.1所示。 图5.1 服务注册运行界面分解图 3)对于“正确的已经存在的用户名和密码，正确的注册顺序”，所有的注册均成功，最后技术指纹信息注册成功，如图5.2所示。 图5.2 服务注册运行界面分解图 46 Web服务动态组装机制设计和实现 第五章 运行实例 3.测试结果分析 在进行UDDI用户注册时，如果两次输入的用户名密码不一样，那么UDDI用户注册失败，将不会产生一个UDDI用户Id，这样后面的服务等信息将不能指定为谁所有，因此就不能注册后面的信息了。 商业实体信息、服务信息、技术指纹信息的注册是依次进行的，如果UDDI注册成功后，那么就能成功注册商业实体信息，而如果服务信息没有注册，那么技术指纹信息也就不能注册了。只有所有信息的注册按顺序进行，没有遗漏，一个完整的服务才会注册成功。 5.1.2服务查询运行测试 1.测试实例 功能描述:进入查询页面后，可选择三种查询方式:按照商业实体名称查询、按照服务名称查询、按照技术指纹名称查询。这三种查询均为模糊查询。只要输入对应的名称，点击不同的查询按钮，将会返回不同的信息。其中按技术指纹名称查询时，若想查询服务文档地址这一敏感信息，需要先进行UDDI用户权限验证，验证成功后才能获得所需信息。 测试用例: 1)查询商业实体信息。 2)查询商业实体的服务信息。 3)查询技术指纹信息。 4)查询技术指纹敏感信息，没有成功。 5)查询技术指纹敏感信息成功。 测试步骤: 1)在按商业实体名称查询中输入商业实体名称，查询商业实体信息。 2)在按商业实体名称查询中输入商业实体名称，查询商业实体的服务信息。 3)在按服务名称查询中输入服务名称，查询技术指纹信息。 4)在按技术指纹名称查询中输入技术指纹名称，输入没有权限访问指定技 术指纹敏感信息的UDDI用户名和密码，查询敏感信息。 5)在按技术指纹名称查询中输入技术指纹名称，输入指定技术指纹创建者 的用户名和密码，查询敏感信息。 2.测试结果 1)对于“在按商业实体名称查询中输入商业实体名称，查询商业实体信息”， 显示查询得到的商业实体信息，如图5.3所示。 47 Web服务动态组装机制设计和实现 第五章 运行实例 图5.3 商业实体信息查询界面 2)对于“在按商业实体名称查询中输入商业实体名称，查询商业实体的服务信息”，查询得到的服务信息项与图5.4的结果显示一样。 图5.4服务信息查询界面 3)对于“在按服务名称查询中输入服务名称，查询技术指纹信息”，显示查询得到的技术指纹信息，查询得到的技术指纹信息项与图5.5的结果显示一样。 4)对于“在按技术指纹名称查询中输入技术指纹名称，输入没有权限访问指定技术指纹敏感信息的UDDI用户名和密码，查询敏感信息”，提示“权限不够，不可获取”，如图5.6所示 5)对于“在按技术指纹名称查询中输入技术指纹名称，输入指定技术指纹创 48 Web服务动态组装机制设计和实现 第五章 运行实例 建者的用户名和密码，查询敏感信息”，显示查得的服务文档地址这一敏感信息，如图5.5所示。 图5.5 技术指纹信息查询界面 图5.6 无权查询敏感信息界面 3.测试结果分析 所有的查询，只要数据库中有记录，均能返回正确的查询结果。在查询敏感 49 Web服务动态组装机制设计和实现 第五章 运行实例 信息时，只有对指定服务的指定技术指纹有访问权限的UDDI用户才能有权查看，如技术指纹创建者对他创建的技术指纹的访问权限为3，表示有读改授的权限，因此创建者可以获得指定的敏感信息。 5.1.3服务授权运行测试 1.测试实例 功能描述:进入授权页面后，若要对某一用户授予对某一技术指纹的权限，首先需要进行UDDI用户验证。如果验证通过，并且该UDDI用户对指定的技术指纹的权限高于输入的权限值，那么将会授权成功。否则，将失败。 测试用例: 1)授权失败 2)授权成功 测试步骤: 1)输入正确的UDDI用户名和密码，验证通过后，输入一个此UDDI用户 没有权限访问的技术指纹名称，进行授权。 2)输入正确的UDDI用户名和密码，验证通过后，输入一个由此UDDI用 户创建的技术指纹的名称，进行授权。 2.测试结果 1)对于“输入正确的UDDI用户名和密码，验证通过后，输入一个此UDDI 用户没有权限访问的技术指纹名称，进行授权”，提示“授权失败”，如 图5.7所示。 图5.7 授权失败界面 50 Web服务动态组装机制设计和实现 第五章 运行实例 2)对于“输入正确的UDDI用户名和密码，输入一个由此UDDI用户创建 的技术指纹的名称，进行授权”，提示“授权成功”，如图5.8所示。 图5.8 授权成功界面 3.测试结果分析 如果需要对一个用户授予一个技术指纹的敏感信息的读权限，那么需对该用户授予1以上的权限。而一个对技术指纹敏感信息没有访问权限的UDDI用户，其权限值为0，0小于1，因此这个UDDI用户不能授权。而技术指纹创建者对他创建的技术指纹敏感信息有读改授的权限，值为3大于1，所以他能授权成功。 5.2Web服务动态组装系统 该系统由用户登录模块、添加服务模块、调用方法模块组成。其中登录模块与Web服务动态组装系统的用户登录模块基本一样，唯一区别在于这里是一个C/S模式的客户端程序登录模块，因此也不给出用户登录验证的运行实例。针对该系统，将主要介绍添加服务、调用方法这两大功能模块的测试实例。 5.2.1添加服务运行测试 1.测试实例 功能描述:在通过了用户登录验证后，进入添加服务窗体，如要添加某个服务，需要在服务文档地址输入栏中输入要添加的服务文档地址。如果输入的服务文档地址正确，将创建Web服务代理类实例并添加该服务组件的所有方法，否 51 Web服务动态组装机制设计和实现 第五章 运行实例 则添加服务失败，产生错误提示信息。 测试用例: 1)给出错误的服务文档地址，添加服务失败 2)给出正确的服务文档地址，添加服务成功。 测试步骤: 1)输入一个错误的Web服务文档地址，点击添加服务按钮。 2)输入一个正确的Web服务文档地址，点击添加服务按钮。 3)再次输入另一个正确的Web服务文档地址，点击添加服务按钮。 2.测试结果 )对于“在服务文档地址栏中输入一个错误的Web服务文档地址”，弹出1 出错窗口，如图5.9所示。 图5.9 添加服务失败界面 2)对于“在服务文档地址栏中输入一个正确的Web服务文档地址”，显示创建的代理对象名称和服务的所有方法，如图5.10所示。 图5.10 添加服务和结果显示界面 52 Web服务动态组装机制设计和实现 第五章 运行实例 3)对于“在服务文档地址栏中再次输入另一个正确的Web服务文档地址”， 继续添加另一个服务的所有方法，如图5.11所示。 3.测试结果分析 Web动态组装机制是通过动态创建Web服务代理类的方法来添加服务的，在创建过程中需要根据服务文档的具体内容来创建服务的各个方法，所以必须输入正确的服务文档地址。 5.2.2调用方法运行测试 1.测试实例 功能描述:选择一个已经添加的Web服务的方法，调用方法，需要对方法的参数进行赋值，不同方法的参数个数与类型可能不一样，所以用户需要根据参数类型对方法的所有参数依次赋值，只有正确赋值后，才能获得正确的调用结果。 测试用例: 1)错误赋值，调用不成功。 2)正确赋值，返回正确结果。 测试步骤: 1)选择所添加的服务中某个方法，给其中某个参数赋予错误的值。 2)选择所添加的服务中某个方法，给所有参数赋予正确的值。 2.测试结果 1)对于“给其中某个参数赋予错误的值”，弹出出错窗体，如图5.11所示。 2)对于“给所有参数赋予正确的值”，返回正确结果，如图5.12所示。 图5.11 参数输入出错界面 53 Web服务动态组装机制设计和实现 第五章 运行实例 图5.12 参数输入正确界面 3.测试结果分析 要想成功调用服务的方法，必须对所调用方法的所有参数进行正确的赋值。否则调用将会出错。 5.3本章小结 本章针对每个子系统的主要功能模块进行了运行测试，并对结果进行了分析。其中Web服务注册查询系统的服务注册运行测试，说明了注册一个完整的服务，需要成功注册UDDI用户、商业实体、服务等等信息，为了保证服务敏感信息安全，在此系统的查询模块和授权模块进行了安全控制。要测试Web服务动态组装系统是否能动态使用服务，需要测试该系统是否能够正确使用Web服务的方法并返回结果。从测试结果可以看到，该机制需要实现的功能都已通过两个子系统实现。 54 Web服务动态组装机制设计和实现 第六章 工作总结与展望 第六章 工作总结与展望 6.1 工作总结 本次毕业设计是对Web服务动态组装机制的研究。为了设计和实现这个机制，在学习和探索过程中让我学到了不少东西。 在搜索资料的学习过程中，我了解了许多与Web服务相关的知识。从不了解Web服务到熟悉它，我大约花了3到4周的时间。但是这几周的时间，让我感受到了Web服务技术出现的重大意义，并了解了Web服务的研究背景、发展过程、工作原理，同时对相关对象服务技术如DCOM技术等也有了部分了解，通过对Web服务技术和其他对象服务技术的比较，让我认识到了Web服务的优势以及它之所以被广泛研究和应用的原因。同时为了深入研究Web服务，我深入学习了XML、SOAP、WSDL、UDDI等等技术，而这些技术的研究和应用正是Web服务技术迅速发展的根本原因。由于以前对网页制作和面向对象编程语言如Java、c#等不太熟悉，所以这次毕业设计使我学习了HTML语言、c#语言等相关知识。 在设计之前，由于没有这方面的开发经验，所以走了不少弯路。首先在开发环境选择上浪费了不少时间。由于我和另一同学研究的方向基本一致，因此我们在这个过程中经常互相学习，当时我们打算使用Sun公司开发的Tmocat做服务器，并使用该公司开发的JUDDI来进行Web服务的发布和查询，用.Net平台开发Web服务。但是在我们花了较长时间进行环境搭建、连接JUDDI、用UDDI4j工具包发布和查询时，遇到了不知如何调用.Net平台开发的Web服务的问题，因此没继续研究，就半途而废了。后来在觉得选用Windows2003做操作系统平台后，由于在IIS和Windows2003内置UDDI服务器的配置上出现了一些问题，我也浪费了不少时间。总之从这个过程中，我发现了自己解决问题能力的不足，今后我将在加强实践操作，提高解决问题的能力。 设计和实现的过程基本上还是一个不断学习不断修改的过程，这个过程让我复习了数据库和面向对象编程的一些知识，并且也让我学习了别人的一些编程技巧，如微软 Uddi.dll或 Uddi SDK.dll对UDDI API的封装技巧。总之这个过程锻炼了我的动手能力也巩固了以前学的知识。 这次设计虽然基本完成，但是不足之处仍然还有很多。如在数据库的设计方面，没有认真考虑数据库安全等技术，在界面设计方面不太美观，两个系统没有很好地合为一个系统等等，所以，在接下来的时间里，我会继续学习和研究这方面的内容。 55 Web服务动态组装机制设计和实现 第六章 工作总结与展望 6.2 展望 通过本文前面章节的介绍与学习，可以总结出:Web服务使企业应用集成和动态协作成为真正可能的、同时便于实施的解决方案;使用Web服务,通过松散的应用集成,将各个企业间的应用以Web服务的方式有效组织起来,实现跨企业的信息共享与业务协同,并通过跨企业工作流系统实现业务流程的自动化。 然而，随着企业应用系统的日益复杂,以及Internet环境所特有的复杂性与多变性,当前跨企业Web服务的业务集成系统依然存在的主要问题有: 1) Web服务的开发与部署没有完全分离,缺乏一定的灵活性,限制了各自的发展;Web服务与服务器往往是静态绑定,不能支持分布式环境下Web服务的动态部署,无法将Web服务动态绑定在可用服务器上运行; 2) 在跨企业Web服务的组合过程中,对于企业Web服务的发现缺乏有效的机制保证在运行时能够动态发现具有较高性价比的服务; 3) 跨企业Web服务的组合过程缺乏动态的描述,无法对动态变化的业务环境做出及时的应对,从而无法进行有效的控制与协调; 4) Web服务与所需资源的静态绑定,限制了跨企业资源的共享,无法提供安全有效的机制,根据Web服务的实际运行环境,实现跨企业的资源共享。 从这些问题中可以看出，目前对Web服务的研究仍然存在着许多不足，要完全实现Web服务的动态化，还需要我们做很多的研究和努力。同时，这些问题也正反映出了Web服务的研究前景非常可观。在未来的一段时间，世界将继续掀起Web服务的研究热潮。我们有理由相信，Web服务的应用将越来越广，在不久的将来，Web服务技术将给人们带来巨大的利益。 56 Web服务动态组装机制设计和实现 致谢 致谢 在此论文最终完成之际，谨向所有关心和帮助我的老师、同学、朋友和亲人们表示深深感谢～ 衷心感谢指导老师A～感谢他在我的研究过程中悉心的指导以及孜孜不倦的教诲。他的严谨的工作态度、科学严密的逻辑思维和宽广的学术知识面使我深受启发和鼓舞，而且对我以后的生活都有深远影响。也感谢 B老师对我的教导，感谢她在毕业设计中期检查给我的指导意见。 感谢那些不知名的论文审稿人～他们中肯的意见使我认识到了研究中存在的不足与缺陷，使我有机会进一步完善自己的工作。 感谢家人对我学业的支持以及生活上的巨大帮助～ 衷心感谢所有关心和帮助过我的人～。 57 Web服务动态组装机制设计和实现 参考文献 参考文献 [1]张明鸣. 基于赋权多段图的服务动态选取机制[J]. 计算机应用与软件, 2007, 24(8). [2]李春梅, 蒋运承. 基于服务提供方与请求方的语义服务选取研究[J]. 计算机应 用研究, 2007, 24(9). [3]喻坚, 韩燕波. 面向服务的计算:原理和应用[M]. 北京: 清华大学出版社～ 2006.20~200. [4]顾宁, 刘家茂, 柴晓路等. Web Services 原理与研发实践[M]. 北京: 机械工业 出版社, 2006.1~151. [5]孙永强. Web服务深入编程[M]. 北京: 清华大学出版社, 2002. [6]丁士峰. 完全手册VisualC#2005 SQLServer2005数据与网络开发[M]. 北京: 电子工业出版社, 2008. [7]李继武. Visual C#.NET项目开发实践从入门到精通[M]. 北京: 清华大学出版 社, 2006. [8]单云. 服务动态选优机制及其应用研究[D]: 硕士学位论文. 西北大学, 2007. [9]江岭, 崔光佐. 一种支持条件分支的语义服务组装方式及执行[J]. 计算机应用, 2007, 27(7). [10]张秋余, 潘强, 贾志龙.基于服务的构件组装结构的研究与设计[J]. 微计算机 信息, 2006, (24). [11]张帆, 杨文军, 李娟子, 郑国勤. 服务组装语言的研究[J]. 计算机工程与应用, 2006, 42(18). [12]武海峰, 蔡勇. 基于语义的动态服务组合的改进[J]. 计算机工程与设计, 2007, 28(4). [13]辜希武, 卢正鼎. 类型化的服务组合形式化模型[J]. 计算机科学, 2008, 35(1). [14]岳昆, 王晓玲, 周傲英. Web服务核心支持技术: 研究综述[J]. 软件学报, 2004, 3(3). [15]M.Little, J.Webber, and S.Parastatidis. Stateful interactions in Web Services: a cimparison of WS-Context and WS-Resource Framework[J]. Web Services Journal, 2004, 5. 58