服务描述

服务描述（精选7篇）

服务描述 篇1

Web服务是一种新型的Web应用程序。Web服务基于因特网的协议和XML消息与其他应用程序直接交互。由于Web服务是一个分布式的计算环境，从而扩展了Web体系结构，增强了Web的应用潜力，成为研究的热点问题。实际的应用需求常常是比较复杂的任务，而单个Web服务都比较简单，所以将多个简单的Web服务组合起来，完成用户的应用需求。而这个Web服务的组合过程包括服务的选取和执行，并需要计算机自动来完成。

要实现Web服务的自动组合，计算机需要根据一些Web服务的描述信息来自动地、动态地选取和组合服务。这些必要的信息就是Web服务的语义信息。Web服务的语义信息需要通过一种形式化的方法来描述，形式化方法的表达能力和推理能力直接影响Web服务的自动组合能否正确灵活的进行。

在人工智能中，有很多形式化的方法能够对动作(action)进行描述。一个动作可以通过输入输出参数、前提和结果等描述它的语义，来表明动作执行的前提条件、执行的对象参数和执行结果。而Web服务也具有和动作一样的特性，也有执行前提、执行参数和执行结果。因此可将Web服务看做人工智能中的动作，然后用人工智能的方法对这些动作进行形式化描述，在形式化描述的基础上进行推理来得出的服务的组合序列。情景演算(Situation Calculus)是恰恰是人工智能中的一种形式化的建模方法，有着广泛的应用。本文选择情景演算作为Web服务语义的形式化描述方法，在此基础上就能够展开形式化的推理，对Web服务进行组合。

1 情景演算

情景演算是人工智能中的一种一阶谓词演算语言，用来描述动态变化的世界，它能够将状态、状态下的动作和动作作用于状态的结果进行形式化，并推理动作的序列和结果。世界是处在不断变化的状态中的，而状态的转换是动作的执行结果，所以情景演算把世界的变化看做动作的执行序列。很多时候我们需要达到一个目标状态，但能否从现有的初始状态达到目标状态，若能达到，如何达到?这样的问题不好回答。而情景演算通过将系统目标状态和初始状态以及系统中的动作建模，能够解决这个问题，即是否能构造到达目标状态的一个动作序列。

在情景演算中，状态S定义为一系列原子动作从某个初始状态S0开始执行的动作序列。谓词流(fluents)表示和状态S相关联的函数和关系。常量S0表示初始状态，即流的初值。动作do(a,s)表示在状态S下执行动作a的后续状态。

情景演算通过动作理论D刻画变化的世界，包含动作前件公理(action recondition axiom)、动作后续状态公理(successor state axiom)等，动作理论D为如下形式：

∑：基础公理。

Dso：描述初始状态。

Duna：动作的唯一命名公理。

Dap：动作前提公理。领域中的每一个动作a都有一个对应的动作前提公理，

描述动作可以执行的前提条件。

其中π是a执行的所有前提条件。

Dss：动作后续状态公理。描述原子动作的执行如何影响流和状态的变化。

公式γF+(x,a,s)是正效果公理，描述了动作集合，使得流F的值在a执行后为真;

公式γF+(x,a,s)是负效果公理，描述了动作集合，使得流F的值在a执行后为假。

其中Poss(a,s)表示动作a在状态s下是可执行的;

这样，通过情景演算进行动作序列的计划就是：给出某个领域的动作理论D和一个目标公式Ф(s)，能否找到一组动作的序列a軃，使得：。

2 会议行程安排系统的语义描述

该会议行程安排系统具有如下功能：有某用户，要从M地到N地参加一个会议，会议行程安排系统能够为他自动安排会议行程，包括订好去的交通以及酒店房间。

系统将这个过程定义为一个常规任务。这个常规任务的流程如图1。

在这个流程中包含9个原子Web服务：

(1)InquiryDriveTime(M,N):查询从M到N的行车时间;

(2)InquiryCarInfo(M):查询M到N的长途汽车信息，返回汽车的信息;

(3)bookCar(CNum,Date1,Date2):订车号为CNum的长途汽车票，时间从Date1到Date2;

(4)InquiryHotelInfo(N):查询N地的酒店，返回酒店名称;

(5)InquiryTrainInfo(M,N):查询从M到N的火车车次，返回车次信息;

(6)bookTrain(TNum,Date):订购日期为Date，车次为TNum的火车票;

(7)InquiryFlightInfo(M,N):查询从M到N的航班，返回航班信息;

(8)bookAirline(K,FNum,Date):订购日期为Date,航空公司为K，航班号为FNum的机票;

(9)bookHotel(H,Date1,Date2):预定酒店H的一个房间，时间从Date1到Date2。

该常规任务包含顺序序列和选择两种结构。选择结构中服务((2)(3))、((4)(5))、((6)(7))只需从中选择一个执行即可。而服务(1)、(8)、(9)是顺序序列，都必须执行。用户在选择交通方式上有一定的约束，会影响执行序列，包括：(1)如果两地的行车时间小于等于3小时，则做汽车去;(2)如果两地的行车时间大于3小时，小于8小时，则坐火车去;(3)否则乘飞机去。

要实现常规任务需要对这9个Web服务进行自动的组合，根据用户的需要来选择相应的Web服务，并将不同的Web服务排列成适当的执行序列，来实现用户的会议行程安排。

下面根据情景演算语言的动作理论D，从原始动作、系统谓词流、系统初始状态、动作执行的前提公理、动作的后续状态公理、复杂动作及用户的偏好等七方面对9个Web服务进行语义描述。

1)将这9个Web服务定义为情景演算中的原始动作：

2)定义系统中的谓词流，这些谓词流描述了系统的状态，谓词流的值会随着Web服务的执行而动态改变。为订航线原子Web服务bookAirline定义四个流：

类似的,还需要为表示bookCar,bookTrain和bookHotel的前提和结果的谓词定义相应的流,此略。

3)定义系统的初始状态,系统的初始状态就是谓词流的初始值,为真或为假。

4)将Web服务执行的条件定义为动作前提公理

服务bookAirline的前提条件包括己知航空公司、航班号和出发日期,以及信用卡有效。

条件为true表示动作在任何条件下都能够执行,例如:

其它原子服务类似，此略。

5)将Web服务执行的结果定义为后续状态公理，定义动作的执行对流值的改变情况。例如，InquiryFlightInfo执行后会使得流AirCompany和FlightNo的值变为真:

6)将常规任务定义为由原子动作构成的复杂动作,即过程。

常规任务表示为由9个原子Web服务组成的过程:

7)偏好公理

偏好公理只需给出动作在什么情况下是用户不希望执行的，未给出的就是用户所希望执行的。

以上基于情景演算完成了对会议行程安排系统中原子Web服务的语义描述，在此基础上就可以进一步对Web服务进行自动组合。

3 结论

WWW原来是静态的Web页面集合，而Web服务是模块化的程序，可以部署在Web上被其他程序发现和调用，这使得使得WWW逐渐演化成开放的应用和服务平台。而Web服务要想成为计算机可以理解的程序模块，从而支持服务的自动组合，就需要用语义Web的方法来来描述服务的语义。

情景演算是一种一阶谓词演算语言，用动作的序列表示动态变化的世界，在人工智能中有很广泛的应用，因为Web服务很类似于情景演算中的动作，所以可以通过情景演算可以对Web服务的语义进行描述建模。

本文通过使用情景演算对一个会议行程安排系统的进行了语义描述和建模，清晰的描述了会议行程安排系统中的各个Web服务的语义，在此基础上，能够准确快速的根据需要对Web服务进行组合，完成用户的需要。进一步的工作可以使用GOLOG语言对情景演算建立的模型进行实现，达到计算机程序自动进行Web服务组合的目的。

摘要：Web服务是WWW发展的一个重要的趋势,Web服务的相关问题得到了广泛的研究和应用,Web服务的自动组合是其中一个热点。要实现Web服务的自动组合,必须对Web服务的语义进行形式化的描述。情景演算是一种形式化的建模和规划方法,利用情景演算对Web服务进行描述,能使自动组合结果更加快速和准确。在分析情景演算特点的基础上,使用情景演算对一个基于Web服务的会议行程安排系统进行了Web服务语义描述。

关键词：Web服务自动组合,Web服务语义描述,情景演算

参考文献

[1]邱莉榕,史忠植,林芬,常亮.基于主体的语义Web服务自动组合研究[J].计算机研究与发展,2007,(4).

[2]张佩云,孙亚民.动态Web服务组合研究[J].计算机科学,2007,(5).

[3]王杰生,李舟军,李梦君.语义Web服务的自动化组合方法:研究综述[J].计算机科学,2007,(6).

[4]史忠植,蒋运承,张海俊,董明楷.基于描述逻辑的主体服务匹配[J].计算机学报,2004,(5).

[5]任志宏.Web服务复合的若干关健问题研究[D].中国科学院研究生院(软件研究所),2004.

[6]章陶,黎亮,黄巍,李磊.情景演算及其在工作流引擎中的应用[J].计算机应用研究,,2005,(2).

[7]万海,李磊,白勇.基于情景演算多流程交互软件模型的研究与实现[J].华中科技大学学报(自然科学版),2005,(S1).

服务描述 篇2

再看.NET的ServiceBase类没有添加描述的属性。

public class ProjectInstaller : System.Configuration.Install.Installer中也没有什么属性来添加。从网搜了后才知道要重载ProjectInstaller 的Install和UnInstall虚方法。其实重写这些虚方法就是为了在注册表相应服务中加一个I值”Description“,其值填为相应的描述就可以了。

public override void Install(IDictionary stateServer) { Microsoft.Win32.RegistryKey system, service, config;

try { //Let the project installer do its job base.Install(stateServer); system = Microsoft.Win32.Registry.LocalMachine.OpenSubKey(”System“).OpenSubKey(”CurrentControlSet“).OpenSubKey(”Services“); service = system.OpenSubKey(this.serviceInstaller1.ServiceName, true); service.SetValue(”Description“, ”服务描述“);

//添加额外的I config = service.CreateSubKey(”AdditionalInformation“); } catch(Exception e) {

} } public override void Uninstall(IDictionary stateServer) { Microsoft.Win32.RegistryKey system, currentControlSet, services, service;

try { system = Microsoft.Win32.Registry.LocalMachine.OpenSubKey(”System“); currentControlSet = system.OpenSubKey(”CurrentControlSet“); services = currentControlSet.OpenSubKey(”Services“); service = services.OpenSubKey(this.serviceInstaller1.ServiceName, true); //删除额外的I service.DeleteSubKeyTree(”AdditionalInformation"); //... } catch(Exception e) { } finally { base.Uninstall(stateServer); } }

注意这些代码是在ProjectInstaller 文件中的，

Web服务组合的Pi-演算描述 篇3

近年来随着Internet的技术的应用的迅速发展, Web服务的理论和技术取得了长足的发展, Web服务作为一种崭新的分布式计算模型, 称为Web上数据和信息集成的有效机制。但是有时候单一的服务不能满足服务需求者的要求, 这个时候就需要Web服务的组合。Web服务组合是指:由各个小粒度的Web服务相互之间通信和协作来实现大粒度的服务功能;通过有效的联合各种不同功能的Web服务, 服务开发者可以借此解决较为复杂的问题, 实现增值功能。本文从基于流程的观点出发, 以Pi-演算作为Web服务的建模语言, 表达Web服务的语义并进一步描述Web服务组合。

本篇文章第二章将主要介绍一些Pi-演算的基础知识;第三章先要简单描述下一个实例旅行社代理系统的Web服务组合, 然后将会用Pi-演算建模这个旅行社代理系统所有的Web服务, 最后验证对旅行社代理系统所有的Web服务建模的正确性;第四章进行全文总结和说明下一步的工作。

2 Pi-演算

2.1 Pi-演算简介

Pi-演算起源于1991年, 是由Robin Milner提出的以进程间的移动通信为研究重点的并发理论, 它是一种描述和分析并发系统的计算模型, 用动态演化结构表示过程间的间歇性相互作用, 名称是基本概念、值、变量和管道通过名称引用。图1是Pi-演算的一种图形表示, 其中P, Q表示过程, 表示端口 (一个过程可有若干端口) , b表示动作, →表示管道。在图中过程P通过端口沿管道发送信息, 过程Q通过管道接受消息。

2.2 Pi-演算的语法定义

在Pi-演算里, 基本的计算实体为名字 (变量) 和进程。设N为一个无限的名字集, 在N上的小写字母如a, b, …, z代表所有的通信通道、变量和值;进程标识符用A, B, C等大写字母表示;进程表达式用P, Q, R等大写字母表示, 进程表达式为以下8种之一。

(1) 在Pi-演算里定义了3种前缀动作。

其中第一种表示在端口y上输出名字x, 然后执行P;第二种表示在端口y上输入任意名字z然后执行P{z/x}, 其中z/x表示用z替换x, 名字x限制在正前缀y (x) 中;前缀表示一个进程外部不可见的内部动作 (或称为哑动作) 。互补端口和y的链接称为通道y。

(2) 空进程0表示不执行任何动作。

(3) 和式表示选择执行, I为有限索引集合。例如P1+P2表示选择执行P1或者P2.

(4) .P表示先执行前缀动作, 然后执行进程P。在Pi-演算里, 符号.用来表示顺序执行。

(5) 匹配表达式[x=y]P表示当x和y是同一通道名时, 其行为与P相同, 否则为0进程;匹配表达式[x≠y]P表示当x和y名字不相同的时候, 其行为表现为进程P。

(6) 约束表达式P表示当名字x被局限在进程P内部。P在新通道x上的外部动作被禁止, 但P通过通道x的内部通信是允许的, 它们都成为了动作, 即将x局限在P中, 另外的表示法有 (x) P或new c in P即let c=new channel () in P。

(7) 进程标识符。A (y1, y2, …, yn) 对每个进程标识符来说, 必须有其定义A (x1, x2, …, xn) ::=P, 其中x1, x2, …, xn是P中的自由名。

(8) !P表示P被重复复制无穷多次。

3 旅行社代理系统的建模以及验证

3.1 旅行社代理系统所有Web服务的描述

在科技日益进步的今天, 在网上预先报名要去的旅游景点已经成为了一个现实。本文就是建模这样一种系统, 具体的系统描述服务如下:旅行社接到客户发来的旅游请求, 根据请求的数据, 确定能否满足客户的请求, 当确认能满足后, 向银行发出请求, 如果银行确认用户已经付账, 则预订服务发送预定成功消息给客户。旅行社代理系统的Web服务组合包括银行支付服务、预订服务以及景点数据服务。其逻辑结构图如图2所示。

根据逻辑结构图, 旅行社代理系统的各个信息的表示如下:

Re:客户网上预订旅游景点的请求;

AI:预订服务详细询问客户旅行的请求

PI:客户将自己旅行的详细要求返回给预订服务, 如旅行的住宿要求, 交通工具选择;

Ref:预订服务接收客户提供的信息, 当不能满足要求时候则发送拒绝信息;

Ac:能满足客户的请求, 预订服务接收了预订旅游请求;

GTI:预订服务向景点数据服务了解旅游景点的一些基本信息;

TI:景点数据服务返回预订服务询问的相关数据;

RP:预订服务向银行要求付款;

IP:银行支付服务向客户发出付款请求;

PF:客户付款并确认;

PS:银行服务通知预定服务, 客户已经付款;

Cf:预订服务向客户发出确认信息, 预订成功。

Pi-演算是建模复杂的Web服务组合的有效方式, 根据文献1的描述, 在用Pi-演算建模Web服务组合的时候需要解决两个问题: (1) 如何识别出进程使用的通道有哪些; (2) 如何识别出系统的参与进程。下面给出寻找进程和通道的三条规则。

规则1.逻辑上单独的原子服务作为一个代理, 也就是说Web服务组合中的每个子Web服务作为一个代理出现;当需要对某个复杂的单一服务进行内部逻辑验证和流程分析时, 也可将其分割为几个相对独立的代理。

规则2.当消息在两个代理见以一定顺序出现时, 它们将在某一通道上进行传递;

规则3.需要通信的两个代理间至少存在一条通道。

下面按照上面所描述的3条规则以及各个信息的表示方法, 将图2抽象为一个如图3所表示的流程图。

其中x为客户Client与预订服务Booking之间的通道, y为预订服务Booking与景点数据服务Data之间的通道, z为银行支付服务Bank与预订服务Booking之间的通道, w为客户Client与银行支付服务Bank之间的通道。

3.2 旅行社代理系统的建模

对系统进行建模如下 (用<>表示沿通道发出消息) :

客户沿着通道x输出请求预订旅游的信息 (Re) , 而旅行社收到这个请求后, 向客户询问其旅游的详细信息 (AI) , 相应的客户通过通道x收到了这个询问信息 (AI) 。最后客户通过通道输出详细信息给旅行社 (PI) 。当旅行社收到客户提供的详细信息后, 如果不能满足要求则向客户输出拒绝信息。所以客户通过通道x接收到了 (Ref) 信息;如果能满足客户的要求, 则客户通过通道x接收到了 (Ac) 信息。则此时银行通过通道w向客户发出请求付款信息 (IP) , 当客户付款之后通道w发出了确认付款信息给银行 (PF) 。当这一系列完成之后, 客户通过通道x接收到了旅行社预订成功的信息 (Cf) 。 (x () 表示沿着通道发出信息, x () 表示沿着通道接收到消息) 。对客户的所有Web服务进行建模如下:

设

上面是对客户进行的Pi-演算的建模, 下面相应的对对预订服务、景点数据服务、银行支付服务进行建模, 预订服务、景点数据服务以及银行支付服务的详细描述不再赘述

预订服务。

设

景点数据服务。

设

银行支付服务。

设

整个旅行社代理系统的Web服务组合由预订服务、景点数据服务和银行支付服务组成。对整个代理系统而言预订服务与景点数据服务之间的通道y和预定服务与银行支付服务之间的通道z是整个系统的内部通道, 所以按照前面阐述的定义, 通道y和z应该作为受限名出现。令

整个旅行社代理系统的建模如下:

3.3 验证建模的正确性

到此为止整个旅行社代理系统的建模已经完成了, 下面验证的建模的正确性。和其他强大而成熟的形式化模型一样, Pi-演算有着许多支持自动模型检查和验证的工具。Mobility Workbench (MWB) 就是一个用来分析基于Pi-演算描述的并发系统的工具。利用该工具我们可以对一个基于Pi-演算描述的Web服务组合进行验证以排查出可能存在的错误, 可以跟踪服务的行为以及验证服务的等价性。MWB采用标准化语言 (Standard ML) 开发, 运行在新泽西标准元语言编译器 (New Jersey SML Compiler version 11.0) 环境下。

我们首先利用MWB对Web服务的模型进行语法检查以排除不正确的Pi-演算表达式。然后可以利用deadlocks命令检查组合的Web服务是否存在死锁, 用step命令模拟、跟踪服务的交互行为。经过deadlocks命令的检查, 我们所描述的Client、Booking、Data、Bank以及整个系统TAS|Client都不存在着死锁。

模型检查的另一个重要内容是验证所设计的组合服务是否确实符合客户需求。因为我们需要检查组合的TAS服务与客户进程Client之间能否正确的交互, 即验证组合服务TAS和Client之间行为的匹配性。一种直接的方法是用step命令对闭合系统TAS|Client进行跟踪, 观测每一步可能的交互。但对于复杂的系统这种方法显然不可取。文献[1]介绍了一种反转验证建模正确性的方法。将Web服务的客户进程的所有行为反转 (输出变输入, 输入变输出) , 这样就得到了客户进程Client的镜像进程RevClient。如果Rev-Client进程和TAS服务是弱相似的, 那么TAS和Client就是匹配的。

我们首先将Client进程反转, 得到镜像进程RevClient如下:

其中c={x, w, Re, AI, PI, Ref, Ac, IP, PF, Cf}.

根据TAS的定义, 通道y与z是一个内部通道名, 对外他们都是不可见的的内部动作, 相当于一个τ动作。这样在TAS系统中把τ动作消去后, 可以看到TAS系统的外部可见动作与Rev-Client动作完全相同, 即它们使用相同的通道与外界通信, 同时也说明了本系统建模的正确性。

3.4 Web服务流建模的应用意义

对Web服务形式化建模是为了验证服务的正确性。模型验证可以用在两个方面:一方面在抽象设计阶段模型可以清晰地描述服务的交互行为, 模型验证可以保证在设计阶段对服务交互行为描述的正确性;另一方面, 当服务被具体实现后, 我们可以从服务的具体实现中抽取出抽象模型, 并和设计时模型进行等价性验证, 以检查具体实现的正确性。本文以一个旅行社代理系统的模型为例, 用Pi-演算建模并验证了这个系统。在以后设计Web服务流的系统的时候, 可以使用此模型的建立方法描述并验证系统设计的正确性。Web服务流进行实现的时候可以按照此系统的检查方法, 检查Web服务组合的正确性以及具体服务实现的正确性。

4 总结和将来的工作

一个组合的Web服务由一组子Web服务组成。这些被组合的子Web服务会彼此并发地交互完成客户的请求, 而彼此间的交互是通过通信和交换信息来完成。Web服务组合一个很重要的问题是如何保证组合的正确性。解决这个问题的重要手段就是为Web服务组合提供一个形式化模型以进行模型检查和验证。本文以一个旅行社代理系统来介绍Pi-演算的建模的方法以及如何验证建模的正确性。

下一步的工作包括:如何利用Pi-演算建立Web服务自动组合的模型以及各种Web服务组合描述语言和Pi-演算模型的自动转化等问题。

摘要：Pi-演算是一种适合于Web服务组合的进程代数, 文章介绍了Pi-演算的基本语法, 讨论了Pi-演算与Web服务协议栈的对应关系, 说明了利用Pi-演算建立Web服务组合模型的规则, 指出了如何寻找代理和通道。最后建立一个实际的模型, 并利用形式化工具对建立的组合模型是否正确以及是否满足需求进行了验证。

关键词：Pi-演算,Web服务,进程代数,Web服务组合,协议栈

参考文献

[1]Berardi D, Calvanese D, De Giacomo G, et al.Automatic compositon of e-services that export their behavior[A].In:Proc of ICSOC’03, LNCS[C].Trento, Italy, 2003, 2910:43-58

[2]Salaun G., Bordeaux L., Schaerf M..Describing and reasoning on Web services using process algebra.In:Proceedings of the2nd IEEE International conference on Web services, SanDiego, California, USA, 2004, 43-50

[3]P.Yang, S.Basu, and C.Ramakrishnan.Parameterized verification of Pi-calculus systems.In12th International conference on tools an algorithms for the construction andanalysis of systems, LNCS3920, Springer-Verlag, 2006:42-57

[4]R.Milner.Communication and concurrency.Prentice Hall, New York, 1989

[5]J.Pathak, S.Basu, R.Lutz, and V.Honavar.Parallel Web service composition in MoScoE:A choreography-based approach.In4th IEEE European conference on Web services, pages3-12.IEEE CS Press, 2006

[6]T.Bultan, J.Su, and X.Fu.Analyzing conversations of Web services.IEEE Internet computing, 2006, 10 (1) :18~25

[7]郭小群, 郝克钢.Web服务的Pi-演算描述[J].计算机科学, 2006, 33 (3) :265~266

[8]Lucas Bordeaux, Gwen Salaun, Daniela Berardi, and Massimo Mecella.When are two Web services compatible?TES2004, SpringerVerlag, Berlin Heidelberg, 2005.15-28

[9]X.W.GU, Z.D.LU, A typed formal model for web services composition.Computer Science, Chongqing, China, 2008, 25 (1) :128-134

酒店服务员工作描述 篇4

2.精神状态良好，牢记服务宗旨。文明待客，礼貌用语，优质服务，加强管理。

3.熟悉本楼层客人住宿情况，来客主动问候、引导，工作总结《酒店服务员工作描述》。离所欢迎再来，及时点验客房设施，并通知总台。

4.及时清扫整理房间，(上下午各一次或根据客人要求)补充一次性物品，卧具一客一换，按规定消毒，并做好记录。要求用品齐全，设施完好，地面无灰尘，室内无异味。做好楼梯、洗脸间、厕所及客房内清洁工作。

5.二、四楼服务员负责烧开水，一、三楼服务员负责消毒间，注意节约用汽。

6.根据客人需要。及时开启空调，制冷一般以25·C——27·C为宜，制热一般设定18·C为宜。客人外出活动及时关闭空调。节约水、电。

7.加强管理，提醒客人不卧床吸烟，贵重物品须寄存，不得私自留宿，做好防火、防盗、防事故工作。

8.发现人为损坏客房设备、设施及时报告、处理。

9.好工作日记，向值班人员做好交接-班。

10.下班时钥匙交总服务台。

服务描述 篇5

Web服务

1. Web服务的相关发现

Web服务是客户用某种手段在不同类型Web服务中寻求其需求的服务并执行Web服务的相关请求。Web服务系统框架中的一个重要组成部分就是Web服务发现。

当下主要是跟据四个方面来思考Web服务:

(1) 服务的提供者对其提供的服务进行一定的描述

(2) 服务代理把相关的服务描述进行分类和发布

(3) 由服务的请求者对服务代理提出请求其中能提供所需功能的服务

(4) 由服务代理把相关的服务请求与已经存储的服务进行一定的匹配, 之后再把匹配的结果向服务请求者退回。

2.Web服务中遇到的一些问题

当前网络在Web服务中检索和表达中仍然有很多技术缺陷, 这些缺陷制约着Web服务的准确发现。其主要的体现在:

(1) Web服务具有语法性语言表达的特点, 其主要是直接面向直接阅读用户的, 这样就不利于计算机的阅读和相关处理。

(2) 不同的团体之间对统一领域中事物的认知一般不同, 这就使服务请求者和服务提供者关于相同Web服务的相关描述存在着一定的冲突。并在这种关于同一种类的Web服务认知上的种种差异就被称为语义结构。其中, 语义结构的具体表现分为三种:在对不同服务进行描述的时候使用多种形式的术语来表示同一种概念;在对同一个概念进行服务描述的时候表现出不同的含义;对每项服务进行服务秒睡的时候使用结构不同但表示相同的信息。

(3) Web服务检索主要以关键字的匹配放为主要检索方式, 并根据广告服务中所描述的内容中是否包括被请求查询中的关键词来进行结果的返还。

Web服务的相关匹配模型

在使用UDDI支持Web服务匹配的过程中提出了两种可靠方案, 但是其中哪一种方案都需要对其进行规范的服务匹配。服务匹配就是把广告服务SA和其中一个服务请求SR进行比较并计算两者之间的相似度。我们需要知道SWSD主要针对Web服务主要描述了四个方面的内容:

1. Web服务的基本信息

Web服务的基本信息主要包括服务名称、服务描述和服务提供者的信息。

2. Web服务相关功能

服务对信息的相关转变是Web服务功能的主要表现。

3.Web服务质量

展现Web服务操作性强的一个重要标志是Web服务质量。

其他相关属性

对两个方案进行分类匹配的时候一般包括四种情况

(1) 所需的服务和服务实现同属于一个类别。

(2) Web服务实现是所属于所需服务类别中的子孙类别。

(3) 服务实现所属类别是所需服务中所属类别的祖先类别。

(4) 以上两种类别之间没有上述描述中的任何一种情况。

基于语义的制造业Web服务主要探究

1.基于语义的制造业Web服务的相关研究

从众多功能相似的Web服务中从Web服务质量探究出最佳服务的相关问题并从Web服务的特点综合考虑Web服务质量的历史统计信息和较近时间段的信息的基础上提出有效的Web服务质量评价模型。同时为了实现Web服务质量不相同的描述并将其中一个Web服务质量描述的本体进行相应定义。还应该设计一个Web服务质量认证体系中心, 并利用Web服务质量认证体系中心对Web服务质量进行相应的管理, 以便为后续的Web服务研究和Web服务匹配研究提供一定的基础。

2. 对Web服务语义描述的相关研究

对Web服务语义描述的相关研究主要是对其定义和对Web服务进行表示。其服务描述的主要宗旨是对服务的提供者和对相关服务请求人提供较标准的合理方式来进行描述, 这是服务发现的基础。在服务发现请求的基础上对服务的描述语言进行一定的描述并参考Web服务中OWL-S并提出一个服务语义描述本体SWSD。广义来讲, SWSD提供了对Web服务的一些基本信息和服务功能性的相关信息, 其中也有对服务质量和非功能性信息的语言进行描述。在SWSD中, 其不仅引入了相关的语义信息, 同时其通过了服务质量认证ID以及与Qo Ws O相互关联并实现了对比服务质量Qo WS的相关描述。为了能使SWSD服务描述进行有效的发布, 通过对SWSD服务描述和Qo WS服务质量描述, SWSD服务描述和Qo WS服务质量描述是以t Mdoel的形式注册到UDDI中心并实现Sw SD服务描述在u DDI中心使用过程, 以至SWSD服务描述在UDDI中心的相关应用得以实现。

3. Web服务语义匹配研究

从Web服务智能化和高效性的要求上来看, 如何对基于语义描述和本体论广告服务描述中和请求服务的相关描述进行一定的匹配。Web服务中的一个重要问题就是Web服务的匹配。应该把Web服务语义的相似匹配作为重点, 并以Web服务质量为辅进行一定的模型匹配之后对其进行详细的描述。对服务功能的输出和输入进行语义相似匹配, 很大程度上提高了服务检索的查准率和查全率当存在大量功能相似服务时, 通过服务质量筛选, 实现最佳服务的目的。

Web服务的相关改进措施

1.当下还没有对Web服务进行先关的规范, 同时也没有Web服务质量的相关标准, 所以应该对Web服务质量模型进行一定的管理和完善。

2.针对当下Web服务对SWSD语言进行描述封装和质量认证封装, 这就使基于语义的Web服务也同样适合于多种服务。

3.当服务功能的语义相似匹配的检索结果中具有最大相似度小于阀值的时候, 应该充分考虑可替代组合的相关服务。

结束语

但是对于基于语义Web服务发现技术来讲其研究结果相对不成熟, 从某种程度来讲其缺乏客观的评判体系, 应该设计一个Web服务质量认证体系中心, 并利用Web服务质量认证体系中心对Web服务质量进行相应的管理, 以便为后续的Web服务研究和Web服务匹配研究提供一定的基础。从Web服务信息的检索中的查全率及查准率中可以得到一定的借鉴意义。但是在实际的过程中缺乏一定的服务实例成本, 当下对自身数据无法进行具体的分析, 对此我们只能对此作出定性的判断。我们应该根据实际的情况确定出一套具有客观规范的评判标准, 使基于语义的制造业Web服务更加的完善。

服务描述 篇6

C 4ISR系统,我军也称之为军事综合电子信息系统,是涉及到指挥控制、情报侦察、预警探测、通信导航、电子对抗、综合保障以及作战人员等多种军事资源的分布、异构的复杂军事信息系统[1]。体系结构作为C 4ISR系统顶层设计技术的重要组成部分[2],通过作战视图、系统视图、技术视图等多视图的描述方法,对现有系统进行改造,指导新建系统的设计开发,是保证C 4ISR系统综合集成的关键技术之一。

信息化战争条件下的战场瞬息万变,作战双方的战场态势随着战争的进程处于快速变化的动态环境,指挥员需要根据战场态势的变化适时地调整作战任务过程,要求系统视图中描述的各类军事资源需要根据作战视图中作战任务过程的变化适时地调整。现有的C 4ISR体系结构描述框架主要侧重于C 4ISR系统静态结构的分析,系统视图中军事信息资源之间紧密耦合,难以描述为适应作战任务过程的变化各类军事资源之间的动态连接关系。

面向服务思想和面向服务架构为上述问题提供了可能的解决方案,通过将各类军事资源系统以服务的形式封装,服务之间以松耦合的形式互联和互操作完成特定的作战任务需求,同时调整服务间的交互关系可以实现其功能的调整,快速的适应作战任务过程和作战环境的变化。本文结合面向服务的思想对原有的C 4ISR体系结构描述框架进行了扩展,加入服务视图的描述内容,同时对服务视图的产品划分、产品描述内容及底层数据元素模型进行了分析。

1相关研究

目前体系结构主要采用基于多视图的描述方法,为规范体系结构描述语法,IEEE 1471—2000建立了体系结构描述概念模型,提出基于多视图的体系结构描述框架[3]。在C 4ISR体系结构研究领域,以美军的体系结构框架发展最早,影响最大。

美军早在1996年和1997年就颁布了C 4ISR体系结构框架1.0、C 4ISR体系结构框架2.0。上述体系结构框架采用作战视图、系统视图和技术视图三视图结构,分别从作战需求和应用、系统设计以及技术三个视角来描述C 4ISR体系结构。经过多年的推广使用后,美军对C 4ISR体系结构框架2.0进行修改完善,2003年8月美国国防部体系结构框架工作组发布了国防部体系结构框架1.0(DoDArchitec-tureFramework 1.0,简称DoDAF1.0)[4]。DoDAF1.0强调体系结构数据,视图产品建立在一组公共的体系结构数据元素基础之上,保证了体系结构描述的一致性,便于各种体系结构描述之间的集成。

为了描述美军提出的“网络中心战”、“网络化作战概念”[5,6]等新的作战样式和作战理念,2006年10月美国国防部体系结构框架工作组引入了面向服务的思想,将DoDAF1.0中系统视图扩展为系统和服务视图,颁布了DoDAF1.5[4,7,8]。虽然DoDAF1.5加入了面向服务的相关描述,但是系统和服务视图中系统与服务相关的描述内容混淆在一起,并且服务元素与原有的体系结构描述内容之间关系缺乏有效的描述,仅仅给出了部分服务相关的描述模板,难以描述网络化作战过程中要求系统视图中各类军事资源动态连接支持作战视图中作战任务动态变化的问题,DoDAF1.5未来发展预测中提到,这些问题预计将在2010年DoDAF2.0中进行改善[8]。

英国国防部在借鉴美国体系结构框架的基础之上,融入本国的实际和新的思维,提出相应的英国国防部体系结构框架(MoDAF)。在原有6个体系结构视图的基础之上,MoDAF1.2[9]版又新增了一个服务视图,相比于DoDAF1.5,MoDAF1.2服务视图由专门体现面向服务思想的产品组建而成,给出了单独的服务视角描述,但其缺乏对服务视图描述产品之间底层数据元素之间关系的描述,缺乏一致的服务描述规范。

北约组织在DoDAF和MoDAF研究基础上结合北约各国家在未来“网络化使能作战(NetworkEnableOperation)”[6]中的联合作战需求提出了北约体系结构框架(NATOAF),并在NATOAFv3.0[11,12]中加入了服务视图,主要借鉴了MoDAF服务视图的描述方法,由专门体现面向服务思想的产品组成服务视图,并对服务视图产品底层数据元素进行了分析,但其缺乏服务视图与作战视图、系统视图等其它视图产品之间的关系描述。

国内,国防科技大学C 4ISR技术国防科技重点实验室等单位在“十五”、“十一五”期间开展了我军军事电子信息系统体系结构技术的专项研究,已经取得一些研究成果[2]。本文在实验室前期研究工作的基础上,针对现有体系结构框架在描述未来一体化联合作战过程中,缺乏有效的描述方法支持各类军事资源适应作战任务动态变化的问题,结合面向服务的思想对C 4ISR体系结构描述框架进行扩展,并对服务视图描述框架进行了分析。

2 C 4ISR体系结构服务视图描述框架

2.1 C 4ISR体系结构中服务定义

本文借鉴北约体系结构框架(NATOAFv3.0)中扩展的服务定义:通过一系列的工作和程序,服务提供者能够给服务消费者提供功能或完成实际的作战任务[13]。这里的服务不同于WebService等分布式系统中服务的定义,其服务提供者涵盖了C 4ISR系统中涉及到的各类信息资源、武器装备系统以及作战人员等众多的军事资源。

2.2原有的C 4ISR体系结构基本数据元素之间关系

为了保证C 4ISR体系结构内部数据的一致性和不同C 4ISR体系结构之间的可集成性,本文在前期工作中将C 4ISR体系结构所涉及到的底层数据模型作为基本的语法规则,并在此基础之上构建视图分类和定义相关产品。采用表示层模型(视图、产品描述)与底层数据分离的原则,C 4ISR体系结构框架结构分为两层结构:表示层和数据层,见图1。表示层从不同的视角对C 4ISR体系结构相关的内容进行可视化模型描述,建立了作战视图、系统视图和技术视图等相关的视图产品,底层数据层确定C 4ISR体系结构基本数据元素、数据元素之间的关系及属性。

在数据层,C 4ISR体系结构最基本的数据元素及其之间的关系如图2所示,其中数据元素包括:作战节点(OperationalNode)、作战活动(Operational Activity)、作战信息(OperationalInformation)、物理资源(Physicalasset)、组织资源(Organizational Resource)、系统数据(Data)、系统(System)、系统功能(Function)、系统连接(System Connection)以及所涉及的技术(Technology)、所涉及的标准(Standard)等。其中作战节点、作战信息、作战活动及其之间的相互关系构成了作战视图的描述基础;系统、系统功能、物理资源、系统数据及其之间的相互关系构成了系统视图的基本描述;约束系统、系统功的相关技术和相关标准构成了技术视图的基描述。

2.3 加入服务之后C4ISR体系结构基本数据元素之间的关系

为了保证C4ISR体系结构数据的一致性,扩展C4ISR体系结构加入面向服务的描述内容,必须分析服务相关的基本元素,并确定服务元素与其它体系结构基本数据元素之间的关系。引入服务元素之后,服务元素与其它数据元素之间的关系如图3所示。

其中扩展的服务相关元素描述如下:

(1) 服务(Service):对C4ISR系统中涉及到的众多军事资源的封装,能够根据接收到的信息,提供信息分发、信息处理等功能或根据接收的命令完成作战任务。

(2) 服务接口(Service Interface):描述服务消费者访问服务的机制,对服务的接收信息格式、语法进行定义。

(3) 服务之间连接线(Services Needline):描述两个或多个服务之间的连接关系,其上可以加入服务交互的信息描述。

(4) 服务规则(Service Policy):描述服务提供者完成服务的规则约束,对应于作战视图中作战任务过程中的作战规则描述。

(5) 服务属性(Service Attribute):描述服务的相关属性,譬如可用性、服务质量(QoS)等相关属性。

(6) 服务层次(Service Level):服务在整个C4ISR体系结构描述中所有服务分类的层次,便于实现C4ISR系统中涉及到众多服务资源进行层次化分类管理。

(7) 服务行为(Service Behavior):描述服务能够提供的功能或完成的作战任务。

通过分析服务相关元素与C4ISR体系结构基本数据元素之间的关系,可以确定C4ISR体系结构服务视图的描述框架,根据描述关系的不同,分为服务内部描述、服务之间的关系和服务与其它体系结构数据元素之间的关系等三类描述,如图4所示。其中服务与服务之间的关系描述可以从静态逻辑结构和动态交互过程两个视角进行分析;服务与体系结构其它数据元素之间的关系描述可分为:(1) 服务元素与作战活动之间的关系,描述了服务视图与作战视图之间的关系;(2) 服务与系统、军事组织人员及物理资源之间的关系,描述了服务与系统视图中具体军事资源之间的映射关系。为了避免与系统视图产品名称混淆,服务视图命名取Service Oriented View,简称SOV,具体产品划分如下:

(1) SOV—1服务描述,主要描述服务自身的相关内容;

(2) SOV—2服务分类管理,从服务与服务之间的静态逻辑结构关系进行描述,包括服务的层次、组合关系、不同资源的分类等;

(3) SOV—3服务交互描述,主要用于描述服务与服务之间的动态交互过程;

(4) SOV—4服务与作战活动映射,主要描述服务视图与作战视图的逻辑关系;

(5) SOV—5服务与系统资源之间的映射,主要描述服务视图与系统视图的逻辑关系。

3 C4ISR体系结构服务视图产品描述

3.1 SOV—1服务描述

SOV—1服务描述产品,是建立服务视图的基础,服务视图其它产品都依赖于SOV—1的描述内容。从体系结构自顶向下的设计角度分析,SOV—1需要描述能够支持作战任务的服务相关属性,包括服务的接口、功能以及非功能参数能够满足作战任务需求,作为底层系统视图中具体资源的设计需求约束;从C4ISR体系结构集成的角度分析,SOV—1是对系统视图中底层遗留系统的封装,通过分析军事资源所能提供的功能以及非功能参数建立服务的接口、功能等服务描述内容。

SOV—1涉及的体系结构基本数据元素如图5所示。

3.2 SOV—2服务分类管理

SOV—2服务分类管理,主要分类管理C4ISR系统中涉及到的众多服务,从服务与服务之间的静态逻辑结构关系进行描述,包括服务的层次关系、服务的组合关系、服务对不同资源的分类等,便于体系结构设计过程中查找相关的服务。SOV—2涉及的基本数据元素见图6。

3.3 SOV—3服务交互描述

SOV—3服务交互描述,主要用于描述服务与服务之间的交互过程,可以从时序跟踪、状态转移、服务交互规则等多个角度进行分析。服务交互规则描述影响服务与服务之间交互过程的规则约束;服务状态转移描述在事件响应下的服务与服务之间交互过程的状态变化;服务时序跟踪描述了服务与服务之间的时间序列、响应等事件跟踪过程。SOV—3涉及的基本数据元素见图7。

3.4 SOV—4服务与作战活动映射

SOV—4服务与作战活动映射,主要描述服务视图与作战视图的逻辑关系,可以分析服务能够支持作战视图中哪些作战活动,作战视图中的活动可以有哪些服务来完成等相关信息。SOV—4涉及的基本数据元素见图8。

3.5 SOV—5服务与系统资源之间的映射

SOV—5服务与系统资源之间的映射,主要描述服务视图与系统视图的逻辑关系,可以分析服务视图中的服务是由系统视图中哪类军事系统资源的封装,也可以分析服务在系统视图中的部署信息。SOV—5涉及的基本数据元素见图9。

3.6 服务视图与作战视图、系统视图之间的关系

服务视图产品之间的关系,如图10所示,SOV—1服务描述作为服务视图的基础,通过SOV—5完成与各类军事资源的封装,通过SOV—2对体系结构中涉及到的服务进行分类管理。SOV—3服务交互描述作为服务视图的核心,通过对服务之间的数据流转和逻辑转移流程进行抽象描述,可以使得这一层的服务并不与封装具体军事资源的服务实例进行捆绑,而在系统具体运行时自动绑定和执行,使得作战视图中作战任务过程与具体支持作战任务过程的军事资源分离,提高C4ISR体系结构的动态适应性。

4 结束语

本文结合面向服务的思想对C4ISR体系结构框架进行了扩展,在分析原有体系结构基本数据元素之间关系的基础上,加入服务元素,通过分析服务元素之间的关系、服务元素与其它体系结构基本数据元素之间的关系确定了C4ISR体系结构服务视图描述框架,并对服务视图产品的描述内容、数据元素以及产品之间的关系进行了分析。下一步工作将以服务交互过程与作战任务过程为核心,确定服务视图产品的具体描述模型和描述规范。

摘要：针对原有的C4ISR体系结构描述框架中系统视图所描述的军事资源系统之间紧密耦合难以适应作战视图中作战任务动态变化的问题,结合面向服务的思想扩展加入服务视图描述内容。为了保证C4ISR体系结构数据一致性,在底层体系结构数据元素模型分析的基础上加入服务元素,通过分析服务元素之间以及服务元素与原有的体系结构数据元素之间的关系,确定了C4ISR体系结构服务视图描述所涉及的产品,并对视图产品描述内容、数据元素模型及产品之间的关系进行了分析。

关键词：C4ISR体系结构,面向服务,服务视图,体系结构数据元素

参考文献

[1]童志鹏,刘兴.综合电子信息系统.北京:国防工业出版社,2008

[2]罗爱民.基于框架的C4ISR体系结构语法、语义设计与分析方法研究.长沙:国防科学技术大学博士论文,2006

[3] IEEE Architecture Working Group.IEEE Recomm ended Practice forArchitectural Description,IEEE Std 1471,Draft Version 3.0,USA,2002

[4] DoD Architecture Framework Working Group.DoD ArchitectureFramework Version 1.0 Volume II:Product Description.The UnitedStates:Department of Defense,2003

[5] UK Ministry of Defense UK Ministry of Defense Architectural Frame-work(MODAF)v1.1.UK Ministry of Defense,10th April 2007

[6] Ang HW,Dandashi F.Tailoring DoDAF for service-oriented Archi-tectures.The MITRE Corporation,http://www.mitre.org/work/tech_papers/tech_papers_07/06_0818/,April 2007

[7] DoD Architecture Framework Working Group.DoD ArchitectureFramework Version 1.5 Volume II:Product Description.The UnitedStates:Department of Defense,2007

[8] DoD Architecture Framework Working Group.DoD ArchitectureFramework Version1.5 Volume I:Definitions and Guidelines.The U-nited States:Department of Defense,2007

[9] DoD Architecture Framework Working Group.DoD ArchitectureFramework Version 1.5 Volume III:Desk book.The United States:Department of Defense,2007

[10] NATO Consultation,Command and Control Board(NC3B).Transi-tion Guidance NAF v2 to NAF v3.http://www.nato.int.,2008

[11] The NATO C3 Board.The NATO Architecture Framework Version 3.0.North Altlantic Treaty Organization:http://www.nhqc3s.nato.int/Browser.asp?Target=_docs/NAF_v3.November 2007

服务描述 篇7

1 对象与方法

1.1 研究对象

在苏州市农村社区卫生服务中心妇科工作的相关人员。

1.2 研究方法

1.2.1 调查问卷的制定

针对社区卫生服务中心而改良设计骨质疏松症问卷,问卷设计为封闭式,登记被调查者的年龄、职称、学历和工作年限,为尽量保持材料的真实性不要求记录姓名。询问内容包括15道多选题,涵盖骨质疏松发生的病因、预防、诊断和治疗等内容,大多数涉及的相关知识都是较为基础的。对条目答案出现的频度分别进行统计。

1.2.2调查资料的收集和要求为保证资料的客观性和真实性,问卷由社区医师在不受干扰的情况下独立填写,问卷由调查员在填写完毕后收回。调查员和调查对象均不知道问卷的“正确答案”。缺失数据<1%的问卷为合格问卷。对于>1%的不合格问卷,应视为缺失数据的类型予以不同处理:(1)若缺失数据为可以追踪的(如年龄、职称),应对调查对象进行再次调查,追踪原始数据直至问卷合格为止;(2)若缺失数据为无法溯源的资料,则应剔除该问卷。

2 结果

2.1 一般资料

从2010年7月至2010年8月对苏州市相城区6家社区卫生服务中心在妇科工作的相关从业人员进行调查,共发放问卷25份,收回有效问卷21份,应答率84.0%。

有效的21份问卷相关工作人员全部是女性,其中高级职称2位,占9.5%;主治医师6位,占28.6%;住院医师11位,占52.4%;其他职称2位,占9.5%;年龄26～54岁,平均38.2岁;工作年限5～30年,平均11.5年;其中本科学历2位,占9.5%;大专12位,占57.1%;中专6位,占28.6%;其他学历1位,占4.8%。

2.2 骨质疏松症描述性调查结果,见表1。备选的8个骨质疏松症的危险因子分布调查情况见图1、图2。

3 讨论

OP是一个具有明确的病理生理、社会心理和经济后果的健康问题[1]。直接后果之一就是骨折的增加,在这部分人群中,约有30%的女性遭受骨折的痛苦[2]。当骨量和骨强度下降后不能适应运动负荷的要求,正常活动时可出现自发性骨折和骨痛,或者受到低能量的外伤发生胸腰椎骨折。当发生骨折以后明显的增加了患者的病死率[3]。髋部骨折的患者12%～14%在骨折后1年内死于各种并发症,50%的患者终身残疾。OP骨折的高发病率、高致残率以及高病死率不仅严重影响老年人的生存质量(quality of life,QOL)[4],而且带来巨大的经济和社会健康负担。2005年,在美国由OP引起的骨折患者超过200万,其医疗费用高达170亿美元[5]。非脊柱骨折占患者73%,其医疗费用占总费用的94%。预计到2040年,这部分医疗费用将高达2000亿美元。

OP是一种需要终生性、复杂的、昂贵的治疗方式的流行病,严重OP患者遭受疾病本身和治疗方式的双重折磨。在农村地区大多数老年人特别是妇女接受的卫生服务水平较低,并不知道自己的健康情况,或者不知道如何进行健康指导和治疗。对于OP这个特定疾病,大多数患者不会主动就诊,需要社区卫生服务人员教育、动员和进行初筛。社区卫生服务人员特别是妇科医师对骨质疏松症的了解程度显得特别重要。社区卫生主动介入进行健康管理,对OP危险人群进行风险评估,在疾病前期就进行适当的干预,这是降低OP发病率,提高人们QOL的最适宜的并最可能在当前国情下取得实效的措施。社区医师承担着社会医疗保险系统“守门人”的角色。

从本次问卷调查来看,社区妇科医师对OP的认识还存在一些误区和盲点,骨质疏松防治知识有待于进一步普及和提高。只有61.9%的人骨质疏松症是一个“很常见”的疾病。关于OP的原因,“衰老”是一个重要的因素,但只有33.3%认为与有关,还有9.5%的人不知道。高钙饮食一般只能提供400mg的钙元素,必须额外补充600mg左右的钙元素;调查中发现大多数人不知道这一点。经常松的重要措施,但是被调查人群只有57.1%的人表示可以。建立骨库必须从儿童开始,显然大多数人并不知道这一点。OP的发生与遗传、雌激素缺乏、钙调节激素、营养因素、运动与制动、细胞因子的改变及酗酒、嗜烟等生活行为有关[6],从本次调查结果来看不尽如人意。OP本身没有明显的症状,称之为“无声的疾病”,“腰酸”、“手足麻木”和“抽筋”都不是特异性的。OP诊断主要依靠骨密度测定,与血钙水平无相关性,普通摄片只有在严重骨质疏松时才有表现,而且混淆因素较多不能作为诊断依据。钙剂和维生素D3是作为基础营养药物,而双磷酸盐和降钙素是最常见的两个治疗药物,本次调查人群对它们显得认识不足。绝经后妇女服用雌激素对骨质疏松的利弊一直有争论,但是目前的观点是危害大于收益。

问题可以归纳为:(1)对骨质疏松症的重要性认识不够。(2)对OP的认识不统一,对患者的解释和处理也不同,对该病的认识误区多、治疗意识淡薄。(3)严重缺乏相关的防治知识。(4)问题的严重性与目前我国农村OP及其骨折的防治现状形成了巨大的反差[7]。目前普通人群对慢病中的高血压病、糖尿病等有了足够的认识,但是对OP认识却有明显不足[8];在本次调查对象中虽然有57.1%的人选择“专业人员”和47.6%的人选择专业书籍,但是从调查结果来看,社区妇科医师对OP的概念、诊断、预防、治疗等各方面的认识同样远远不够。要重视骨质疏松预防知识推广专业化的骨质疏松教育,识别和处理危险因素[9];首先要在承担社区卫生服务的妇科医师中进行有组织的系统专业知识普及,才能减少骨质疏松症带来的并发症和降低由此带来的致残率和致死率,并减少OP及其骨折带来的沉重经济负担。

参考文献

[1]Wells M,Sturdee DW,Barlow DH,et al.Effect on endometrium oflong term treatment with continuous combined oestrogen-proge-stogen replacement therapy:follow up study[J].BMJ,2002,325(7358):239.

[2]Kado DM,Brower WS,Palermo L,et al.Vertebral fractures andmortality in old women:a prospective studay[J].Arch Intern Med,1999,159(3):487.

[3]Frost HM.Defining osteopenias and osteoporoes;another view(with insight from a new paradigm)[J].Bone,1997,20(5):385-391.

[4]Tidermark J,Bergstrom G,Svensson O,et a1.Responsiveness ofthe EuroQol(EQ 5-D)and the SP-36 in elderly patients withdisplaced femoral neck fractures[J].Qual Life Res,2003,12(8):1069-1079.

[5]Burge R,Dawson-Hughes B,Solomon DH,et a1.Incidence andeconolnic burden of osteopomsis-related fractures in the UnitedStates,2005-2025[J].J Bone Miner Res,2007,22(3):465-475.

[6]胡侦明,劳汉昌.骨质疏松及防治[M].昆明:云南科技出版社,1999:96-123.

[7]程志安,林定坤,许树柴,等.“治未病"与骨质疏松症中医特色健康管理[J].中华健康管理学杂志,2008,2(5):317-318.

[8]沈芸,朱崇昭,申明月,等.骨质疏松知识问卷调查[J].现代预防医学,2006,33(8):1419-1426.