本文是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定义及其模式图示，随后我们再一一详细解释模式的细节。
上面的代码给出了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元素内。
上面的代码给出了一个person的实例文档，其中这个个人信息包含了三个联络方式，两个是email地址，一个是寄信地址，此人没有留下联系电话。
最后，我们给出application模式的一个完整的实例文档。
闽公网安备 35060202000074号