本文是Web Service Case Study系列文章的第二篇。在这篇文章中,我将围绕一个认证考试申请系统展开设计和讨论,这个应用与本文的系统不同,主要是面向B2C模式的应用,着眼点在于如何将这个系统的客户端插入到尽可能多的公共平台、桌面系统中去,同时借助这个Case Study,我将着重讲解在Web服务设计的时候,如何有效地使用XML Schema设计系统中使用的XML数据模式。
本文中针对的应用实例是一个认证考试系统,应用背景如下:(以下陈述纯属虚构)
UDDI-China.org是中国的Web Services技术组织,提供Web服务系列技术的技术认证服务,具体负责这个技术认证服务的是UDDI-China.org下的WSTA机构。任何技术人员都可以向WSTA机构提出申请,要求进行某一项Web服务技术(比如XML Schema、SOAP、WSDL、UDDI等)的技术认证,一般流程是要经过申请、修读相应课程、考试这三个主要步骤。WSTA认证考试系统就是为了管理和加速这个流程而开发的一套系统。
在介绍具体的系统流程之前,我们先来看看这个系统的实体关系图:
Figure 1. 认证考试系统实体关系图
结合图1中,我们的系统中,基本上可以有这样三个主要的流程:
注册:申请人需要填写申请表,经过申请审核其资格,通过后准许进入课程修读以及考试流程;
课程修读:通过了申请之后,系统将为这个申请人自动安排一个课程的修读日程,并安排指定授课老师;
考试:当申请人经过课程的修读(当然也可以不读书直接考试),可以申请参加考试,系统将自动为其安排一个考试日程,当申请人完成考试后,将得到相应的成绩单以及认证证书(当然要是通过的)。
设计人员希望这个系统的使用者不但能够通过UDDI-China.org的Web Page来使用认证考试系统,同时设计人员还希望能让各种桌面工具能够直接与UDDI-China.org的认证考试系统集成,比如用户在使用个人事务计划软件时,就能够将申请、听课和考试等事务纳入系统的安排,涉及的事务安排可以通过个人事务计划软件与UDDI-China.org的认证考试系统的交互来自动完成。交互的界面被设计为使用Web服务调用接口,而Web服务接口中输入/输出的数据应当是XML格式的,抛开Web服务调用接口先不谈,我们先来看看系统接口中需要使用的XML数据模型。
经过系统分析,设计人员认为以下实体是需要使用XML来描述的:
Application,在这个XML描述实体中,将涉及图1中的Applicant和Application;
CourseSession,在这个XML描述实体中,将涉及图1中的Applicant、Employee、CourseSession和Course;
ExamSession,在这个XML描述实体中,将涉及图1中的Applicant、ExamSession、Exam和Test。
下面,我们分别给出这三个XML实例文档的模式。
XML Schema建模
Application
首先,我们给出Application文档的XML Schema定义及其模式图示,随后我们再一一详细解释模式的细节。
elementFormDefault="qualified" attributeFormDefault="unqualified">
Application的模式定义
Application类型定义
个人信息类型定义
联系方法类型定义
上面的代码给出了Application的XML Schema文档,其中定义了一个Application元素,这个元素是Application数据文档的根元素。Application元素使用了applicationType这个复合类型作为它的类型定义。而applicationType类型定义引用了personType这个类型定义作为个人信息的描述,personType类型定义中使用了contactType类型定义来描述个人的联系方式,而contactType类型定义还使用了mailAddress这个组定义,以支持choice的定义方式。
在详细介绍这个层次结构之前,我们可以先来看一看图2的模式图示。
Figure 2. Application模式图示
applicationType复合类型用于描述一个申请表,applicationType复合类型定义包含了6个子元素:person、company、experience、reference、certificationID、applicationDate,分别表示个人信息、所属公司、工作经验、参考技能认证、认证考试ID、申请日期。其中person的类型是复合类型personType,而其他5个元素都是简单类型。company、experience、reference的类型都是字符串xs:string,certificationID的类型是xs:long,而applicationDate的类型是xs:date。其中除reference的出现次数可以是0到3次以外,其他的元素都是出现且仅出现1次。
person子元素应用了personType复合类型,personType复合类型定义包含了3个子元素:personID、name和contact,分别表示个人ID、姓名和联系方法。personID是一个简单类型元素,类型为xs:long。name是一个复合结构,包含了两个子元素surname和givenName,共同描述了人的姓名。
而contact子元素则是应用了contactType复合类型定义,contactType是一个选择类型,应用contactType类型的元素可以选择是包含一个email子元素、或是包含一个phone子元素,或是包含一个mailAddress子元素,mailAddress使用了在后面定义的元素组定义mailAddress。
为了使得对contact元素的定义理解地更为具体一些,我们下面给出一些contact元素的实例表示的例子,具体的,包含在person元素内。
20302290
Joe
Huang
[email protected]
[email protected]
No.2000, Huangxing Road, Shanghai
200433
上面的代码给出了一个person的实例文档,其中这个个人信息包含了三个联络方式,两个是email地址,一个是寄信地址,此人没有留下联系电话。
最后,我们给出Application模式的一个完整的实例文档。
20302290
Joe
Huang
[email protected]
[email protected]
No.2000, Huangxing Ro