一种UDDI业务扩展方法及系统

摘要

本申请公开了一种UDDI业务扩展方法及系统，该方法包括：接收操作人员输入的业务请求；判断所述业务请求是否为个性化业务请求；当所述业务请求是个性化业务请求时，通过预先建立的个性业务接口在预先建立的个性业务数据库内进行与所述业务请求相对应的业务操作。使用该方法在UDDI内进行个性业务操作，可以实现业务层的扩展，弥补了在UDDI实现中无法快速扩展的缺憾，并且由于个性业务请求完全遵循了UDDI的实现规范，使得WebService的管理具有规范性。

说明书

技术领域

本申请涉及计算机网络技术领域，特别是涉及一种UDDI业务扩展方法 及系统。

背景技术

UDDI(Universal Description、Discovery and Integration，通用描述、 检索与集成服务)是一种目录服务，它集描述(Universal Description)、检 索(Discovery)与集成(Integration)为一体，其核心是注册机制。企业可以使 用它对基于Web的Web services进行注册、搜索以及其他操作。

在UDDI注册中心存储了关于企业的信息，这些信息包括：企业提供的 服务以及与所提供服务相关的技术信息。UDDI所使用的数据模型和编程API 是基于XML和SOAP的，该数据模型和编程API提供了发布和定位各种服务 的方法。从Web Services协议栈中可以看出，UDDI包含于完整的Web Services 服务协议栈之内，而且是协议栈基础的主要部件之一。UDDI构建于网络传输 层和基于SOAP的XML消息传输层上。

UDDI鼓励Web Services的相互操作和相互采用，允许企业在注册中心中 发布它所提供的服务，利于其它操作方发现企业和服务。但企业需要遵循 UDDI已有的实现规范才可以进行业务注册和查询等操作，这对于企业一些偏 向于业务层的个性化业务注册或查询，现有的UDDI规范常常无法实现，可 扩展性较差。

发明内容

有鉴于此，本申请实施例提供一种UDDI业务扩展方法及系统，该方法 可以在规范性操作的同时可以进行一些个性化的业务处理，以实现UDDI的 业务。

为了实现上述目的，本申请实施例提供的技术方案如下：

一种UDDI业务扩展方法，其特征在于，包括：

接收操作人员输入的业务请求；

判断所述业务请求是否为个性化业务请求；

当所述业务请求是个性化业务请求时，通过预先建立的个性业务接口在 预先建立的个性业务数据库内进行与所述业务请求相对应的业务操作。

优选地，判断所述业务请求是否为个性化业务请求，包括：

从接收到的操作人员输入的业务请求中提取特征关键词；

在UDDI规范内查询是否存在所提取的特征关键词；

当所述UDDI规范内不存在所述关键词时，确定所述业务请求为个性化 业务请求。

优选地，当所述UDDI规范内存在所述特征关键词时，确定所述业务请 求为规范业务请求；

并且通过UDDI规范接口在UDDI数据库内进行与所述业务请求相对应 的业务操作。

优选地，所述业务操作包括：注册、查询和注销。

优选地，所述预先建立的个性业务接口与所述UDDI规范接口相互独立。

优选地，所述预先建立的个性业务数据库为在UDDI规范性表结构的基 础上创建的与个性化业务请求相对应、且存储位置与UDDI数据库的存储位 置相独立的数据库表；并且预先建立的个性业务数据库中内容与和其相关 Web Service服务相绑定。

一种UDDI系统，包括：业务请求接收单元、UDDI规范接口和UDDI 数据库，并且还包括：判断单元、个性业务接口和个性业务数据库，其中：

所述判断单元与所述业务请求接收单元相连接，用于判断所述业务请求 接收单元接收的业务请求是否为个性化业务请求；

所述个性业务接口、所述UDDI规范接口均与所述判断单元相连接，所 述个性业务接口用于当判断单元的判断所述业务请求是个性化业务请求时， 提供与所述业务请求相对应的业务接入；所述UDDI规范接口用于提供规范 性业务请求相对应的业务接入；

所述个性业务数据库与所述个性业务接口相连接，用于当所述个性业务 接口提供业务接入时，根据所述业务请求提供相对应的业务操作；

所述UDDI数据库与所述UDDI规范接口相连接。

优选地，所述判断单元包括：

与所述业务请求接收单元相连接的特征关键词提取单元，用于从所述业 务请求接收单元接收到的操作人员输入的业务请求中提取特征关键词；

与所述特征关键词提取单元相连接的查询单元，用于在UDDI规范内查 询是否存在所提取的特征关键词；

与所述查询单元相连接的确定单元，用于当所述查询单元在所述UDDI 规范内查询不存在所述关键词时，确定所述业务请求为个性化业务请求。

优选地，所述个性业务接口与所述UDDI规范接口相独立。

优选地，所述个性业务数据库为在UDDI规范性表结构的基础上，创建 的与个性化业务请求相对应、并且存储位置与UDDI数据库的存储位置相独 立的数据库表，并且个性业务数据库中的内容与和其相关Web Service服务相 绑定。

由以上技术方案可见，本申请实施例提供的该UDDI扩展方法，首先判 断业务请求是否为个性化业务请求，然后当判断结果为个性化业务请求时， 利用预先建立的个性业务接口，在预先建立的个性业务数据库内进行相应的 业务操作。所以使用该方法在UDDI内进行个性业务操作，可以实现业务层 的扩展，弥补了在UDDI实现中无法快速扩展的缺憾，并且由于个性业务请 求完全遵循了UDDI的实现规范，使得Web Service的管理具有规范性。

另外，该方法没有对UDDI规范性的表结构进行拆分，所以不仅可以进 行个性化业务操作，而且还可以进行规范化业务操作，使得个性化业务操作 可以与规范性的UDDI业务操作进行松散耦合性的分离。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实 施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面 描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员 来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种UDDI业务扩展方法的流程示意图；

图2为本申请实施例提供的判断业务请求是否为个性化业务请求的流程 示意图；

图3为本申请实施例提供的另一种UDDI业务扩展方法的流程示意图；

图4为本申请实施例提供的一种UDDI系统的结构示意图；

图5为本申请实施例提供的判断单元的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合 本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描 述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施 例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前 提下所获得的所有其他实施例，都应当属于本申请保护的范围。

实施例一：

图1为本申请实施例提供的一种UDDI业务扩展方法的流程示意图。

如图1所示，该UDDI业务扩展方法包括以下步骤：

S100：接收操作人员输入的业务请求。

作为服务的提供者，企业可以在UDDI注册中心存储有关企业的一些信 息，这些信息包括：企业提供的服务以及与所提供服务相关的技术信息；作 为服务的使用者，用户可以在UDDI内查询这些企业提供的信息，进而了解 企业所提供的服务。

无论是企业在注册时或者用户在查询时，均需要输入与其预期操作相对 应的业务请求，这里业务请求可以为注册、查询和注销等。

S200：判断所述业务请求是否为个性化业务请求。

根据接收到的业务请求，可以判断其是规范化业务请求，还是个性化业 务请求，在判断时，如图2所示，该步骤具体可以包括：

S201：从接收到的操作人员输入的业务请求中提取特征关键词。

这里特征关键词是作用是对业务请求进行识别，通过特征关键词可以了 解与该业务请求所对应的预期操作。

S202：在UDDI规范内查询是否存在所提取的特征关键词。

由于规范化业务请求均是遵循UDDI的实现规范的，所以在UDDI规范 内可以查找到规范化业务请求中特征关键词，而对于个性化业务请求，由于 其是按照用户设想自己设定的，虽然其也是按照UDDI规范生成，但在UDDI 规范内不存在这些个性化业务请求中的特征关键词。

当该步骤判断得到UDDI规范内不存在关键词时，进行步骤S203。

S203：确定该业务请求为个性化业务请求。

当确定业务请求为个性化业务请求后，进行步骤S300。

S300：通过预先建立的个性业务接口在预先建立的个性业务数据库内进 行与业务请求相对应的业务操作。

个性业务接口是预先建立的、且与UDDI规范接口相互独立的一个接口， 当在上述步骤中判断业务请求为个性业务请求时，需要通过该个性业务接口 进行后续相应的操作。

另外，在UDDI内，预先建立的个性业务数据库为在UDDI规范性表结 构的基础上创建的与个性化业务请求相对应、且存储位置与UDDI数据库的 存储位置相独立的数据库表；并且预先建立的个性业务数据库中内容与和其 相关Web Service服务相绑定，这样当操作人员在查询时能够根据自己的个性 化业务查询到所需要的Web Service服务。

通过该步骤，可以根据用户输入的个性化业务请求进行相应的个性化操 作。

此外，在本申请实施例中，当步骤S202中判断结果为：UDDI规范内存 在特征关键词，那么就确定业务请求为规范业务请求。此时，如图3所示， 该方法还可以包括：

S400：通过UDDI规范接口在UDDI数据库内进行与所述业务请求相对 应的业务操作。

该步骤与现有的普通业务操作相同，本领域技术人员均已熟知，在此不 再赘述。

本申请实施例提供的该方法，首先判断业务请求是否为个性化业务请求， 然后当判断结果为个性化业务请求时，利用预先建立的个性业务接口，在预 先建立的个性业务数据库内进行相应的业务操作。所以使用该方法在UDDI 内进行个性业务操作，可以实现业务层的扩展，弥补了在UDDI实现中无法 快速扩展的缺憾，并且由于个性业务请求完全遵循了UDDI的实现规范，使 得WebService的管理具有规范性。

另外，该方法没有对UDDI规范性的表结构进行拆分，所以不仅可以进 行个性化业务操作，而且还可以进行规范化业务操作，使得个性化业务操作 可以与规范性的UDDI业务操作进行松散耦合性的分离。

实施例二：

本申请实施例还提供了一种UDDI系统，如图4所示，为本申请实施例 提供的UDDI系统的结构示意图。

该UDDI系统包括：业务请求接收单元1、UDDI规范接口2、UDDI数 据库3、判断单元4、个性业务接口5和个性业务数据库6，其中：判断单元 4与业务请求接收单元1相连接，UDDI规范接口2和个性业务接口5分别与 判断单元4，并且UDDI数据库3与UDDI规范接口2相连接，个性业务数据 库6与个性业务接口5相连接。

业务请求接收单元1作为人机交互界面，用于接收操作人员输入的业务 请求，这里操作人员可以为服务提供者——企业，也可以为服务使用者—— 用户。UDDI规范接口2和UDDI数据库3均为现有的UDDI系统内已有的， UDDI规范接头2用于根据规范化业务请求在UDDI数据库3内进行相应的操 作，UDDI数据库3用于存储企业的信息，包括：企业提供的服务以及与所提 供服务相关的技术信息。

如图4所示，判断单元4与业务请求接收单元1相连接，用于判断业务 请求接收单元1接收的业务请求是否为个性化业务请求。

在本申请实施例中，如图5所示，判断单元4可以包括：特征关键词提 取单元41、查询单元42和确定单元43，其中：特征关键词提取单元41与业 务请求接收单元1相连接，用于从业务请求接收单元1接收到的操作人员输 入的业务请求中提取特征关键词；查询单元42与特征关键词提取单元41相 连接，用于在UDDI规范内查询是否存在所提取的特征关键词；确定单元43 与查询单元42相连接，用于当查询单元42在UDDI规范内查询不存在关键 词时，确定业务请求为个性化业务请求。

个性业务接口5与判断单元4相连接，用于当判断单元4的判断业务请 求是个性化业务请求时，提供与业务请求相对应的业务接入，并且个性业务 接口4与UDDI规范接口2相独立。

个性业务数据库6与个性业务接口5相连接，用于当个性业务接口5提 供业务接入时，根据业务请求提供相对应的业务操作。在本申请实施例中， 个性业务数据库为在UDDI规范性表结构的基础上，创建的与个性化业务请 求相对应、且存储位置与UDDI数据库的存储位置相独立的数据库表，另外， 为了方便用户查询，个性业务数据库中的内容与和其相关Web Service服务相 绑定，这样当操作人员在查询时能够根据自己的个性化业务查询到所需要的 WebService服务。

该系统提供明确的业务框架接口，使得业务层的注册与查询功能实现个 性化交互操作实现简便。另外，该系统采用主流的业务框架，业务体系比较 成熟。

以上所述仅是本申请的优选实施方式，使本领域技术人员能够理解或实 现本申请。对这些实施例的多种修改对本领域的技术人员来说将是显而易见 的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下， 在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例， 而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。