专利名称：资源信息访问的实现方法和系统的制作方法
技术领域：
本发明涉及通信领域，尤其涉及一种资源信息访问的实现方法和系统。
背景技术：
资源管理是通信网络运营支撑的重要环节。通常，企业运营都需要建立统一的全 局资源管理系统平台，以便时刻掌握企业资源整体状况、运营能力，并借助资源管理系统的 服务来达成企业资源调配、更迭和运作的科学、高效、节约和协同。因此，从企业运营服务的 质量和效率来看，资源管理系统平台是至关重要的一个系统。资源管理平台只是一个IT系统，该系统管理的资源数据信息是企业的重要资源。 因此，资源管理平台的重要目标就是保证资源数据和信息的完整、准确、一致，并在需要调 配和更迭资源的时候提供科学合理的方案。但这个目标仅仅靠资源管理平台这个IT系统 是无法完成的。因为企业资源的变更与客户需求、外部要求、企业自身发展状况、新技术的 引入、不同领域的资源生命周期的情况等等多种因素有关，有的变更是主动行为、有的则是 被动行为；有的变更是全局性的，牵连的范围很广，有的则是局部的，不会带来扩散影响； 有的变更是粗粒度的，有的则是细粒度的。虽然，资源变更的情况看起来很复杂、很主观和 难以把握，但从根本上说，资源变更是与企业业务发展紧密相关的，而业务发展是由企业组 织和人来决策和推进的，所以，要想把握资源变更的方式、跟踪资源变化的情况，最佳的方 式就是跟随业务流程管理资源的变更问题。对于如何通过跟踪业务流程来管理资源信息的变化，目前主要有两种解决方案 方式(1)在资源管理系统内对用户角色和权限进行分割，明确不同用户的职责和分工，之 后再通过管理手段和制度建设，强制推行同一个系统内的分工与合作，从而达到资源数据 和信息的变更在约定前提下进行协同，而这些约定前提是遵循业务流程要求的，是由组织 行为和人为来决策和制定的；方式O)，该方式主要存在于业务流程自动化程度较高的企 业，通过(或部分通过)电子流程系统来驱动资源系统中数据和信息的变化，对于企业信息 化来说，业务流程系统通常也是统一的全局平台，该系统承载着企业内部的业务逻辑和协 作机制，这样的全局平台不仅要处理资源相关流程，还要处理企业内其他的流程，所以流程 系统是按照业务流程维度构建的，它不应该也不可能与企业的资源管理平台集成在一起， 所以，在采用这种方式时就会涉及到流程系统和资源系统之间的接口互动方式。如上，在上述方式⑵中，需要开发资源系统与流程系统间的接口，这样才能达到 流程驱动资源管理的自动化，进而保证资源数据准确、及时更新。目前，资源系统和流程系 统间接口的实现方式有如下两种。第一中实现方式通常是在流程系统中携带部分资源信息流转，而这些资源信息采 用文件附件(如Excel文件附件)作为载体，流程本身的交互仍然沿用流程系统固有的技 术实现方式，文件附件一般采用类似文件传输协议(如FTP)的方式交互。在流程流转的过 程中，每一环节的用户按照规范的文件模板填写和更新数据，完成数据维护工作，流程结束 后，再通过系统间接口，由流程系统转发给资源系统处理文件数据，如此完成流程驱动的资源变化。第二种实现方式是根据业务关系将流程分级，分别在流程系统和资源系统实现， 不同层级流程之间是嵌套和调用/返回关系。具体来讲，大的全局的流程在统一流程系统 实现(如系统跨部门的资源调度流程)，局部的业务规则明确并易于自动化的流程在资源 管理系统实现(如一个具体领域内部的资源方案设计、配置等)，不同层级流程之间建立接 口，这种接口要实现流程逻辑的控制，还要交互数据，并处理数据的同步和变更跟踪。一个 典型的例子是资源内部流程处理完成后，将资源的变化实时记录，生成静态的资源调度结 果表单反馈给流程系统，由流程系统继续流转。但是，以上描述的方案存在多种问题，具体如下上述的方式(1)本质上是通过限制人的行为来保证资源数据的准确、一致和完 整，因为在系统实现层面角色和权限的灵活性有限，更多要靠管理手段来保证。对于该方 式，流程中的抉择和推进由人来执行，所以这种流程驱动也可以说是人和制度在驱动。当资 源结构复杂、资源数据庞大的情况下，不仅管理费时费力，而且因为人的主观性、理解力和 判断均无法统一，会导致资源数据管理过程不可控、数据质量不可控，使得整个资源系统及 其数据失去价值。对于上述方式0)，第一种接口实现方法由于文件附件的引入带来了如下问题: 首先，是文件中的数据失控。文件本身不具备业务规则判断能力，数据在文件中也无法与资 源系统中的数据进行比对和同步，数据在文件中的变更无法控制和跟踪，数据值的错误在 所难免。其次，文件的格式需要统一约定，对于庞杂结构化的资源数据来说，这种格式统一 本身就是一个工作量大且重复性强的工作，而且对于不同格式的文件难以达成一致。此外， 这种接口方式还不可避免的涉及到附件文件的合并和拆分问题，因为资源信息的维护和变 更往往是分布式的。此外，文件附件的校验机制、保存机制、因文件数据本身的规范性问题 引发的流程回退和反复等，都将带来一系列的实现复杂性。对于上述方法0)，第二种接口实现方式的主要问题是复杂度高，实现代价大。首 先，流程分级实现后，存在于不同的系统中，实际操作中很难定义出流程间的契合点，接口 繁多复杂，诸如资源数据接口、流程控制接口、资源调度配置结果接口等。其次，流程系统需 要保存部分资源系统所管理的资源数据，以支撑整个流程的运转，因此需要解决资源同步 问题，包括同步机制、同步时机的选择等，这都会增加接口实现的复杂度。最后，这种实现方 式的结果，用户可能需要做多次切换，感知不好。针对相关技术中资源访问复杂度高、效率低的问题，目前尚未提出有效的解决方案。
发明内容
针对相关技术中资源访问复杂度高、效率低的问题，本发明提出一种资源信息访 问的实现方法和系统，能够降低资源访问和管理的复杂度，提高资源访问的效率。本发明的技术方案是这样实现的根据本发明的一个方面，提供了一种资源信息访问的实现系统，该系统包括资源 系统和流程系统，其中，流程系统用于向用户提供资源访问的界面，并根据用户对界面的操 作访问资源系统中存储的资源信息；并且，资源系统与流程系统之间设置有消息控制接口和内容服务接口，消息控制接口用于在流程系统访问资源系统的资源信息时传送资源系统 与流程系统之间的控制类消息，内容服务接口用于在流程系统访问资源系统的资源信息时 传送资源系统与流程系统之间的服务数据。并且，资源系统进一步用于响应于流程系统的访问对资源信息进行修改和/或呈 现。此外，流程系统进一步用于记录用户对界面进行的操作。优选地，消息控制接口通过基于HTTP协议类的消息接口、基于服务调用的接口、 基于组件调用的接口、或者基于TCP/IP协议栈和API开发的接口方式承载控制类消息。进一步地，内容服务接口通过基于界面集成方式、基于文件共享的方式、基于消息 中间件的方式、基于过程调用和共享数据的方式、或者基于数据库接口的方式承载服务数 据。其中，优选地，界面集成方式为基于HTTP/HTTPS的URL调用。优选地，基于HTTP 协议类的消息接口为WebService方式实现的接口。此外，上述控制类消息可以包括鉴权信息、流转请求控制信息、流程环节通知信 息、和/或资源服务状态查询信息。根据本发明的另一方面，提供了一种资源信息访问的实现方法。根据本发明的资源信息访问的实现方法包括流程系统通过其提供的界面接收用户的操作；流程系统根据用户的操作访问资源系统中存储的资源信息；其中，资源系统与流 程系统之间设置有消息控制接口和内容服务接口，在流程系统访问资源系统的资源信息 时，通过消息控制接口传送资源系统与流程系统之间的控制类消息，通过内容服务传送资 源系统与流程系统之间的服务数据。该方法可进一步包括资源系统根据流程系统的访问对资源信息进行修改和/或呈现。并且，该方法还可进一步包括流程系统将用户通过界面预先输入的鉴权信息经 由消息控制接口发送至资源系统；在资源系统对用户鉴权成功的情况下，允许用户根据预 设的工作流任务访问资源信息。并且，在用户完成服务数据的一个处理逻辑后，如果工作流任务需要进入下一个 服务数据的处理逻辑，则该方法进一步包括流程系统通过消息控制接口向资源系统请求流转，并通过消息控制接口将工作流 任务的当前流程状态通知给资源系统；资源系统完成业务和数据的状态更新和同步。此外，在用户受理完服务数据后，如果工作流任务需要下一个用户继续进行资源 数据受理，该可方法进一步包括流程系统通过消息控制接口将下一个用户的鉴权信息发 送给资源系统，由资源系统对下一个用户进行鉴权，并在下一个用户通过鉴权的情况下，根 据工作流任务的当前流程状态，通过内容服务接口向流程系统提供服务数据，以供下一个 用户受理。优选地，消息控制接口通过基于HTTP协议类的消息接口、基于服务调用的接口、 基于组件调用的接口、或者基于TCP/IP协议栈和API开发的接口方式承载控制类消息。
优选地，内容服务接口通过基于界面集成方式、基于文件共享的方式、基于消息中 间件的方式、基于过程调用和共享数据的方式、或者基于数据库接口的方式承载服务数据。本发明通过在资源系统和流程系统之间采用数据和流程相互独立的松耦合接口 设计，将流程控制和业务操作进行了明确分割，并且在流程系统上提供用于对资源系统中 的资源数据进行直接访问的操作界面，一方面能够解决人工驱动带来的数据管理过程和数 据质量不可控的问题，降低了管理成本和人力成本，提高了资源管理的效率，另一方面能够 避免流程分级分割带来的复杂的处理机制，无需处理跨系统的流程转接和数据交换问题， 简化了接口设计；此外，还能够省去复杂的数据导出、导入、拷贝、以及数据同步，降低处理 的复杂度，提高处理的效率，并且有助于对数据修改状况以及用户操作状况进行监控和管 理。
图1是根据本发明系统实施例的资源信息访问的实现系统的框图；图2是根据本发明方法实施例的资源信息访问的实现方法的流程图；图3是根据本发明方法实施例的资源信息访问的实现方法的具体处理实例的消 息流程图。
具体实施例方式针对相关技术中资源访问和管理复杂度高、效率低的问题，本发明提出资源系统 与流程系统的接口设计采用了数据和流程相互独立的松耦合结构。在这种结构中，流程系 统仅负责流程控制，对资源数据的操作信息进行透明化处理；资源系统则仅负责自身业务 数据的处理需求和业务逻辑规则的控制。通过本发明，能够在资源服务中解决资源权限控 制、资源维护实时性、流程流转控制、工作流状态同步、资源业务规则核查控制等关键问题， 流程驱动的机制通过来自流程系统的工作流状态同步来完成，从而能够有效解决工作流和 业务流多级耦合的问题，并避免了系统间数据同步带来的复杂度。下面将详细描述本发明的实施例。系统实施例 在本实施例中，提供了 一种资源信息访问的实现系统。如图1所示，根据本实施例的资源信息访问的实现系统包括资源系统和流程系统 (也可称为流程引擎平台或流程引擎)，其中，资源系统包括多个资源服务实例，用于提供 资源服务。参照图1，流程系统用于向用户提供资源访问的界面，并根据用户对界面的操作访 问资源系统中存储的资源信息；并且，资源系统与流程系统之间设置有消息控制接口和内 容服务接口，消息控制接口用于在流程系统访问资源系统的资源信息时传送资源系统与流 程系统之间的控制类消息，即，形成图1中所示的通道一，通过该通道可以实现访问控制和 流程同步，内容服务接口用于在流程系统访问资源系统的资源信息时传送资源系统与流程 系统之间的服务数据，形成图1中所示的通道二，通过该通道实现资源业务的访问。并且，资源系统可以进一步用于响应于流程系统的访问对资源信息进行修改和/ 或呈现。流程系统可以进一步用于记录用户对界面进行的操作。
相比于上述的方式(1)，根据本发明的资源信息的访问系统在进行资源访问时， 访问流程由流程系统驱动，从而增强流程的可控性以及避免由于认为操作带来的庞大工作量。在上述方式O)的第一中接口实现方法中，在对资源系统中的资源信息进行访问 时，需要导出数据，并且导出的数据需要拷贝到流程系统，之后由人工修改流程系统中的数 据，在该方法中，由于人工修改是认为操作，并非基于一定的规则，从而会导致文件内数据 的修改状况无法控制和管理，一旦修改出现不合法的情况，就会导致流程回转，并且，用户 的修改访问均基于拷贝到流程系统中的数据，但是资源系统中的数据并未发生变化，因此， 在用户完成访问之后还需要进行复杂的变更同步过程，该过程同样需要将数据导出导入。根据本发明的上述系统在进行资源访问时，用户可以通过界面实现访问，在资源 系统直接修改数据，省去了数据的拷贝、导出、导入资源系统中的同步数据，并且，基于界面 操作的方式，能够在界面上实现数据修改等操作的标准化，避免流程回转的问题。在上述方式O)的第二中接口实现方法中，流程系统和资源系统双方均控制流 程，流程的衔接需要在两个系统中均进行流程的接口，流程需要对接，并且需要交互流程之 间的处理中间结果，因此，对于资源的管理，需要获取资源系统和流程系统两者的处理结 果，才能够最终获知用户的访问操作状况，不利于对流程的监控和追踪，也不利于对每个用 户的操作进行管理，并且，在流程对接时需要实现复杂、繁多的流程接口，导致整个系统的 复杂度增加。根据本发明的上述系统在进行资源访问时，在流程系统中即可实现流程的监控、 跟踪、任务过程的记录(审计)等，数据的变化在资源系统中能够明确第体现出来，因此，不 需要结合两个系统的综合结果，有效提高了用户管理和资源数据管理的效率。在根据本发明的上述系统中，优选地，消息控制接口可以通过基于HTTP协议类的 消息接口(如ffebServidHTTP/HTTPS (超文本传输协议/超文本传输协议安全版)等)、 基于服务和组件调用的接口(如J2EE/EJB/RMI/JCA等)、基于其他组件技术标准和架构的 接口(如CORBA、TUXEDO等)、基于TCP/IP协议栈和API开发的接口(如SOCKET方式、私 有API接口开发等)等方式承载控制类消息。优选地，内容服务接口可以通过基于界面集成方式、基于文件共享的方式(如 FTP)、基于消息中间件的方式、基于过程调用和共享数据的方式、基于数据库接口的方式等 承载服务数据。其中，界面集成方式基于HTTP/HTTPS的URL调用方式实现，这种方式便于 实现，并能够有效降低业务数据同步和流程衔接的复杂度。此外，上述控制类消息可以包括鉴权信息、流转请求控制信息、流程环节通知信 息、和/或资源服务状态查询信息等，本文不再一一列举。优选地，考虑到技术标准化、可扩展性和实现简单性，可以将内容服务接口承 载在HTTP/HTTPS协议上。另外，考虑到协议标准化、技术发展趋势和可扩展性，推荐用 WebService协议承载消息控制接口，使得系统的应用具有更好的推广性，具有良好的标准 化性和可扩展性，实现代价较低。在采用了 WfebService和HTTP/HTTPS协议后，不需开发类似FTP (例如文件附件)、 HTML(例如资源调度结果表单)等的交互方式，因此简洁实用，便于资源服务组件的开发和 加载(并且可以plug-in的方式加载新资源服务)，接口维护也很简单。
此时，在进行接口消息交互时，涉及到资源相关的任务处理的消息通过HTTP/ HTTPS方式传输，涉及到流程确认、用户身份认证、鉴权等控制类消息则通过WebService方 式传输。在具体实现上，资源系统开发出基于各业务领域的资源服务，用户在流程系统的带 动下，经过了认证和授权，就可以通过HTTP/HTTPS接口访问资源系统提供的资源服务。可以看出，本发明的方案中接口实现简洁，通过设计两个相对独立的消息通道，从 设计上进行了流程和数据的分割，在抽象的资源服务的概念下，通过两个标准协议对这两 个接口进行承载，能够使这种分割获得实现层面的简单和标准化。实际应用中，在资源系统提供资源服务时，一个原子级的资源服务对外的接口包 含控制请求和业务请求两部分接口消息。其中，控制请求消息包括资源权限校验、流转请求 控制、流程流转环节告知、资源服务状态查询等信息。这部分消息只负责两个系统间的控制 交互，并不涉及资源数据信息。业务请求消息也可称为资源服务请求消息，用户在流程系统中可以根据流程状态 适时发起资源服务请求消息，调用资源服务的业务界面(资源服务的业务界面由资源系统 实现)，这样实现了资源系统与流程系统的松耦合。流程系统不需要再另行维护一套资源数 据，同时也不必关心资源服务的业务内容，只需要知道哪个环节调用哪个资源服务接口即可。在资源系统中，资源服务的结构可以是多层封装结构。首先，需要根据业务域的资 源需求分析结果，抽象出基本层次的资源服务，称为原子级的资源服务。由原子级的资源服 务可以组合成更高级的资源服务。多个资源服务可以纵向级联，从而构成复杂的资源服务 或是完成一个资源需求实现过程逻辑。资源系统中的资源服务实例构成了一个面向具体资源需求的业务逻辑的模块，其 外在表现就是提供了一系列的资源服务界面，并符合该资源业务流程的要求。资源服务实 例只负责资源的业务操作，如资源数据的查询、呈现、基于本资源服务业务逻辑的控制校验 等等。优选地，如上，资源系统提供的接口可以为内容服务接口，并通过HTTP/HTTPS承载。通过上述系统，基于业务和流程分离的接口配置方案，能够降低资源访问的复杂 度，提高管理的效率，有效解决工作流和业务流多级耦合的问题。方法实施例在本实施例中，提供了一种资源信息访问的实现方法。该方法可以基于上述系统 实现资源信息的访问。类似地，下文中提到的消息控制接口可以通过基于HTTP协议类的消息接口(如 WebService,HTTP/HTTPS等)、基于服务和组件调用的接口(如J2EE/EJB/RMI/JCA等)、基 于其他组件技术标准和架构的接口(如CORBA、TUXEDO等)、基于TCP/IP协议栈和API开 发的接口(如SOCKET方式、私有API接口开发等)等方式承载控制类消息。内容服务接口 可以通过基于界面集成方式、基于文件共享的方式(如FTP)、基于消息中间件的方式、基于 过程调用和共享数据的方式、基于数据库接口的方式等承载服务数据。如图2所示，根据本实施例的资源信息访问的实现方法包括步骤S202，流程系统通过其提供的界面接收用户的操作；步骤S204，流程系统根据用户的操作访问资源系统中存储的资源信息；其中，资 源系统与流程系统之间设置有消息控制接口和内容服务接口，在流程系统访问资源系统的
9资源信息时，通过消息控制接口传送资源系统与流程系统之间的控制类消息，通过内容服 务传送资源系统与流程系统之间的服务数据。在用户进行访问之前，流程系统需要将用户通过界面预先输入的鉴权信息经由消 息控制接口发送至资源系统；在资源系统对用户鉴权成功的情况下，允许用户根据预设的 工作流任务访问资源信息。在用户访问的过程中或访问结束之后，资源系统可以根据流程系统的访问对资源 信息进行修改和/或呈现。在用户完成对服务数据的一个处理逻辑后，如果工作流任务需要进入下一个资源 数据的处理逻辑，则该方法进一步包括流程系统通过消息控制接口向资源系统请求流转， 并通过消息控制接口将工作流任务的当前流程状态通知给资源系统，以便资源系统完成业 务和数据的状态更新和同步。在用户受理完服务数据后，如果工作流任务需要下一个用户继续进行资源数据受 理，则该方法进一步包括流程系统通过消息控制接口将下一个用户的鉴权信息发送给资 源系统，由资源系统对下一个用户进行鉴权，并在下一个用户通过鉴权的情况下，根据工作 流任务的当前流程状态，通过内容服务接口向流程系统提供资源数据，以供下一个用户受理。也就是说，对于每个执行工作流任务的用户，均需要通过消息控制接口完成鉴权 后才能访问资源系统，并执行各自的任务。下面将结合图3详细描述用户通过流程系统访问资源系统的一个资源服务实例 的处理过程。如图3所示，具体包括以下步骤步骤1，用户通过流程系统创建工作流任务。步骤2，流程系统根据任务类型判断所需资源服务类型，通过资源系统提供的认证 和鉴权服务对用户进行认证和授权，认证和鉴权可通过消息控制接口实现。步骤3，认证和授权完成后，流程系统调用资源系统提供的该任务相应的资源服 务。其中，资源系统可以反馈相应的服务调用界面以供执行具体的操作。该调用可以通过内 容服务接口实现，具体可以基于HTTP/HTTPS方式集成资源系统提供的资源服务业务界面， 在流程系统内进行资源服务访问。步骤4，在流程系统中，用户通过资源系统提供的资源服务操作界面，遵照相应的 资源业务规则和业务流逻辑(内置于资源服务当中)，对资源数据进行增加、删除、修改、查 询等操作，完成对资源的访问。其中，图3中最上方的4个步骤(步骤1至4)即相当于流程创建环节。步骤5，用户完成当前阶段操作，触发流程系统向前流转。步骤6，流程系统调用资源系统提供的资源服务，以确认资源配置合法性和可行 性。这其中涉及到资源数据的比对、业务规则的校验、关联资源的影响性和可用性等等，比 如资源配置是否已完成，是否可进行下一步操作。这些是基于资源全局的一种确认，需要资 源系统结合自身数据从全局角度进行分析和判断，因此只有资源系统才能很好的完成。然后，资源服务反馈流程系统发起的查询、请求等操作的结果。步骤6中的交互可以通过消息控制接口实现。
步骤7，根据资源系统接口服务反馈的结果，流程系统启动相应的规则和动作，并 通知用户。步骤8，流程系统调用资源系统的资源服务接口，通知资源系统当前工作流状态， 以便资源系统结合内置的业务逻辑和资源变化关系，由工作流状态判断资源信息生命周期 阶段，以完成资源数据的状态同步和管理。步骤8中的消息传输可以通过消息控制接口实 现。步骤9，经过流程系统中若干环节的流转，业务流的下一个用户开始受理，执行相 应的任务。步骤10，流程系统根据业务流的定义和要求，判断用户是否需要操作资源，如果需 要，同样需要启动认证和鉴权过程(如前所述)。实际上，是通过同一资源服务接口的不同 参数来认证和鉴权，以决定是否可访问服务，是只读访问还是可写的访问资源服务等。步骤11，本环节的用户受理业务完毕，完成本阶段任务，触发流程流转到下一环 节。步骤12，经过流程系统中若干环节的流转，审核决策角色的用户查看本次资源服 务流程的结果。同样需要先启动认证和鉴权过程(如前所述)，再启动资源系统的服务调用 接口以进行审查。步骤13，最终用户确认资源变更的结果后，触发流程系统结束工作流，完成工作流 的闭环。步骤14，流程系统触发工作流状态的传递，通知资源系统本次资源变更业务流完 成。资源系统同步工作流状态，完成业务逻辑和资源数据生命周期阶段的确认，资源变化最 终的更新完成。同样，这个消息的传递通过资源服务提供的消息控制接口实现。其中，对于中间进行工作流任务的每个用户，资源系统、流程系统、以及用户之间 的交互流程均可以按照步骤9、步骤2、步骤3、步骤10、步骤11、步骤6、步骤7、步骤8的顺 序执行，可以将这些处理称为受理环节。应当注意，尽管图3中示出了具体的处理顺序和处理步骤，但是本发明并不限于 此，在实际应用中，可以增加、删除、改变图3中的处理，或调整处理步骤的顺序。并且，尽管之前列举了用于承载控制类消息和服务数据的多种协议，但是本发明 并不限于此，凡是能够承载控制信息的协议均可以作为消息控制接口所采用的协议，凡是 能够承载业务数据的协议，均可以作为内容服务接口的协议，本文不再一一列举。综上所述，相比于上述方式(1)，本发明能够通过电子化的流程系统来自动驱动资 源数据的变更，解决了人工驱动带来的数据管理过程和数据质量不可控的问题，并简化了 管理成本和人力成本，提高了资源管理的效率；相比于上述方式O)中的第一种接口实现 方式，本发明无需文件附件传递资源数据信息，解决了附件文件中数据不可控问题，强化了 面向业务规则的检查机制，规避了文件附件方式引发的一系列复杂处理机制，从流程驱动 资源变化的实际粒度和效果上都有了明显的提升，并且，能够省去数据的导出、导入、拷贝、 以及资源数据的同步，有效提高了处理的效率，降低了资源访问实现的复杂度；相比于上述 方式O)中的第二种接口实现方式，本发明将流程控制和业务操作进行了明确分割，避免 了流程分级分割带来的复杂的处理机制，无需处理跨系统的流程转接和数据交换问题，简 化了接口设计，有效实现了流程中的权限传递、数据同步。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精 神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
权利要求
1.一种资源信息访问的实现系统，其特征在于，包括资源系统和流程系统，其中，所述流程系统用于向用户提供资源访问的界面，并根据所述用户对所述界面的操作访 问所述资源系统中存储的资源信息；并且，所述资源系统与所述流程系统之间设置有消息 控制接口和内容服务接口，所述消息控制接口用于在所述流程系统访问所述资源系统的所 述资源信息时传送所述资源系统与所述流程系统之间的控制类消息，所述内容服务接口用 于在所述流程系统访问所述资源系统的所述资源信息时传送所述资源系统与所述流程系 统之间的服务数据。
2.根据权利要求1所述的系统，其特征在于，所述资源系统进一步用于响应于所述流 程系统的访问对所述资源信息进行修改和/或呈现。
3.根据权利要求1所述的系统，其特征在于，所述流程系统进一步用于记录所述用户 对所述界面进行的操作。
4.根据权利要求1至3中任一项所述的系统，其特征在于，所述消息控制接口通过基于 HTTP协议类的消息接口、基于服务调用的接口、基于组件调用的接口、或者基于TCP/IP协 议栈和API开发的接口方式承载所述控制类消息。
5.根据权利要求1至3中任一项所述的系统，其特征在于，所述内容服务接口通过基于 界面集成方式、基于文件共享的方式、基于消息中间件的方式、基于过程调用和共享数据的 方式、或者基于数据库接口的方式承载所述服务数据。
6.根据权利要求5所述的系统，其特征在于，所述界面集成方式为基于HTTP/HTTPS的 URL调用。
7.根据权利要求1至3中任一项所述的系统，其特征在于，所述基于HTTP协议类的消 息接口为^febService方式实现的接口。
8.根据权利要求1至3中任一项所述的系统，其特征在于，所述控制类消息包括鉴权信 息、流转请求控制信息、流程环节通知信息、和/或资源服务状态查询信息。
9.一种资源信息访问的实现方法，其特征在于，所述方法包括所述流程系统通过其提供的界面接收用户的操作；所述流程系统根据所述用户的所述操作访问资源系统中存储的资源信息；其中，所述 资源系统与所述流程系统之间设置有消息控制接口和内容服务接口，在所述流程系统访问 所述资源系统的所述资源信息时，通过所述消息控制接口传送所述资源系统与所述流程系 统之间的控制类消息，通过所述内容服务传送所述资源系统与所述流程系统之间的服务数 据。
10.根据权利要求9所述的方法，其特征在于，进一步包括所述资源系统根据所述流程系统的访问对所述资源信息进行修改和/或呈现。
11.根据权利要求9所述的方法，其特征在于，进一步包括所述流程系统将所述用户通过所述界面预先输入的鉴权信息经由所述消息控制接口 发送至所述资源系统；在所述资源系统对所述用户鉴权成功的情况下，允许所述用户根据预设的工作流任务 访问所述资源信息。
12.根据权利要求11所述的方法，其特征在于，在所述用户完成所述服务数据的一个 处理逻辑后，如果所述工作流任务需要进入下一个服务数据的处理逻辑，则所述方法进一步包括所述流程系统通过所述消息控制接口向所述资源系统请求流转，并通过所述消息控制 接口将所述工作流任务的当前流程状态通知给所述资源系统；所述资源系统完成业务和数据的状态更新和同步。
13.根据权利要求11所述的方法，其特征在于，在所述用户受理完所述服务数据后，如 果所述工作流任务需要下一个用户继续进行资源数据受理，所述方法进一步包括所述流程系统通过所述消息控制接口将所述下一个用户的鉴权信息发送给所述资源 系统，由所述资源系统对所述下一个用户进行鉴权，并在所述下一个用户通过鉴权的情况 下，根据所述工作流任务的当前流程状态，通过所述内容服务接口向所述流程系统提供服 务数据，以供所述下一个用户受理。
14.根据权利要求9至13中任一项所述的方法，其特征在于，所述消息控制接口通过基 于HTTP协议类的消息接口、基于服务调用的接口、基于组件调用的接口、或者基于TCP/IP 协议栈和API开发的接口方式承载所述控制类消息。
15.根据权利要求9至13中任一项所述的方法，其特征在于，所述内容服务接口通过基 于界面集成方式、基于文件共享的方式、基于消息中间件的方式、基于过程调用和共享数据 的方式、或者基于数据库接口的方式承载所述服务数据。
全文摘要
一种资源信息访问的实现方法和系统，该系统包括资源系统和流程系统，流程系统用于向用户提供资源访问的界面，并根据用户对界面的操作访问资源系统中存储的资源信息；资源系统与流程系统之间设置有消息控制接口和内容服务接口，消息控制接口用于在流程系统访问资源系统的资源信息时传送资源系统与流程系统之间的控制类消息，内容服务接口用于在流程系统访问资源系统的资源信息时传送资源系统与流程系统之间的服务数据。本发明能够解决人工驱动带来的数据管理过程和数据质量不可控的问题，降低管理成本和人力成本，提高资源管理效率；并且能够避免流程分级分割带来的复杂的处理机制，解决处理跨系统的流程转接和数据交换问题，简化了接口设计。
文档编号H04L29/06GK102082772SQ20091023863
公开日2011年6月1日 申请日期2009年11月30日 优先权日2009年11月30日
发明者张戈 申请人:中国移动通信集团北京有限公司