背景技术
随着移动通信技术的飞速发展和移动多媒体时代的到来,手机作为人们必备的移动通信工具,已从简单的通话工具向智能化发展,演变成一个移动的个人信息收集和处理平台。借助操作系统和丰富的应用软件,智能手机成了一台移动终端。
目前,主流的智能手机操作系统包括Google Android和苹果的iOS等。其中,Android操作系统中,使用以Activity为单位的应用来实现一个特有的服务场景,仅支持有限制地访问其他应用的Activity。无论是Android还是iOS,用户想要完成一项业务,往往需要在多种不同的应用之间多次跳转,而在不同应用之间进行跳转时,数据流转也有不少限制。以如下场景为例,用户出门旅游,需要研究旅游攻略,制定日程,预订机票、酒店,进行支付,关注目的地天气信息等。在Android或iOS操作系统中,基于上述场景,用户需要使用浏览器搜索旅游攻略,使用旅行服务应用程序来预定机票和酒店,使用支付应用程序进行支付,使用天气应用程序来关注天气。这需要在多种应用程序之间进行跳转切换,并且因无法将已制定的数据传递到其他应用程序,用户需要多次重复操作,比如进行目的地、日期等的选择和搜索。
如何实现不同服务之间的跳转,以满足灵活方便的业务需求,是目前亟需解决的问题。
申请内容
本申请实施例提供了一种服务组件管理方法及系统。
本申请实施例提供的服务组件管理方法,包括:
接收第一服务组件发送的指向第二服务组件的信息实体;
向所述第二服务组件发送所述信息实体。
进一步地,向所述第二服务组件发送所述信息实体之前,还包括:创建第二服务组件的实例。
其中,创建第二服务组件的实例,包括:
获取所述第二服务组件对应的可执行程序代码;
运行所述可执行程序代码,并为所述可执行程序代码分配运行环境。
进一步地,向所述第二服务组件发送所述信息实体之后,还包括:
接收所述第二服务组件返回的对所述信息实体的处理结果;
将所述第二服务组件返回的处理结果发送给所述第一服务组件。
优选地,所述信息实体中至少包括目标服务组件的URI,所述目标服务组件的URI对应一个第二服务组件,或者对应多个第二服务组件。
其中,所述目标服务组件的URI中还附带有参数。
其中,所述参数根据所述第一服务组件接收到的事件确定。
其中,所述事件,包括:
所述第一服务组件对应的用户界面UI上的控件被触发产生的事件;
设定的系统事件;
设定的非系统事件。
优选地,所述参数用于指示所述第二服务组件的设定入口。
优选地,所述信息实体中还包括以下内容之一或任意组合:数据,事件。
进一步地,还包括:所述第二服务组件处理所述信息实体。
其中,若所述信息实体中包括数据和事件,则处理所述信息实体包括:根据所述信息实体中包括的数据,执行所述信息实体中包括的的事件所对应的操作。
优选地,所述信息实体中至少包括目标服务组件的URI和事件时,所述目标服务组件的URI包括用于表征广播事件的信息;
向所述第二服务组件发送所述信息实体,包括:
根据所述信息实体中目标服务组件的URI中所包括的用于表征广播事件的信息,确定注册监听所述事件的至少一个第二服务组件;
向注册监听所述事件的第二服务组件发送所述信息实体。
优选地,所述信息实体中还包括指示信息,所述指示信息被所述第二服务组件用来确定所进行的处理操作。
其中,所述指示信息中包括第一指示信息;所述第一指示信息用于指示所述第一服务组件和所述第二服务组件是否在同一服务组件组内。
其中,所述服务组件组中包括至少2个服务组件,所述服务组件组根据业务场景设置。
优选地,所述指示信息中包括第二指示信息;所述第二指示信息用于指示所述目标服务组件是否需要进入指定的状态,或者指示所述目标服务组件与用户界面的交互方式。
其中,所述指定的状态,包括以下状态中的一种:
隐藏状态,该状态下的服务组件在后台运行,对用户不可见;
可见地非交互状态,该状态下的服务组件对用户可见,但不响应用户输入;
可见地交互状态,该状态下的服务组件对用户可见,并且响应用户输入。
其中,所述交互方式,包括以下方式中的一种:
可见地交互方式;
可见地非交互方式。
优选地,所述信息实体中还包括:
所述第一服务组件的URI;和/或
所述第二服务组件的组件标识ID,所述组件标识ID用于在所述第二服务组件存在多个实例时,指示所述多个实例中与所述ID对应的实例。
优选地,所述第二服务组件为本地服务组件或远程服务组件。
其中,向所述第二服务组件发送所述信息实体,包括:
确定所述第二服务组件为本地服务组件或远程服务组件;
若为远程服务组件,则向所述第二服务组件对应的服务器发送所述信息实体。
进一步地,向所述第二服务组件对应的服务器发送所述信息实体之后,还包括:
接收所述服务器发送的对所述信息实体的处理结果;
将所述服务器发送的处理结果发送给所述第一服务组件。
本申请实施例提供的服务组件交互方法,包括:
第一服务组件根据接收到的信息生成指向第二服务组件的信息实体,所述接收到的信息包括事件和/或数据;
所述第一服务组件发送所述信息实体。
优选地,所述事件,包括:
所述第一服务组件对应的用户界面UI上的控件被触发产生的事件;或
设定的系统事件;
设定的非系统事件。
优选地,所述第一服务组件根据接收到的信息生成指向第二服务组件的信息实体,包括:
所述第一服务组件根据接收到的事件,确定所述事件被配置的目标服务组件;
所述第一服务组件将所述目标服务组件的统一资源标识符URI,写入所述信息实体的相应字段。
进一步地,所述第一服务组件根据接收到的信息生成所述信息实体,还包括以下至少一项:
所述第一服务组件将接收到的事件和/或数据,写入所述信息实体的相应字段。
优选地,所述第二服务组件为本地服务组件或远程服务组件。
进一步地,还包括:接收所述第二服务组件返回的对所述信息实体的处理结果。
进一步地,还包括:
接收第三服务组件发送的指向所述第一服务组件的信息实体;
处理所述第二接收单元接收到的信息实体。
其中,处理所述第二接收单元接收到的信息实体,包括:
若接收到的信息实体中包括数据和事件,则根据所述信息实体中包括的数据,执行所述信息实体中包括的的事件所对应的操作。
本申请实施例提供的服务组件管理装置,包括:
第一接收单元,用于接收第一服务组件发送的指向第二服务组件的信息实体;
第一发送单元,用于向所述第二服务组件发送所述信息实体。
优选地,还包括:创建单元,用于在向所述第二服务组件发送所述信息实体之前,创建第二服务组件的实例。
其中,所述创建单元,具体用于:
获取所述第二服务组件对应的可执行程序代码;
运行所述可执行程序代码,并为所述可执行程序代码分配运行环境。
优选地,还包括:
第二接收单元,用于向所述第二服务组件发送所述信息实体之后,接收所述第二服务组件返回的对所述信息实体的处理结果;
第二发送单元,用于将所述第二服务组件返回的处理结果发送给所述第一服务组件。
优选地,所述信息实体中至少包括目标服务组件的统一资源标识符URI,所述目标服务组件的URI对应一个第二服务组件,或者对应多个第二服务组件。
其中,所述目标服务组件的URI中还附带有参数。
其中,所述参数根据所述第一服务组件接收到的事件确定。
其中,所述事件,包括:
所述第一服务组件对应的用户界面UI上的控件被触发产生的事件;
设定的系统事件;
设定的非系统事件。
优选地,所述参数用于指示所述第二服务组件的设定入口。
优选地,所述信息实体中还包括以下内容之一或任意组合:数据,事件。
进一步地,还包括:所述第二服务组件处理所述信息实体。
优选地,所述信息实体中至少包括目标服务组件的URI和事件时,所述目标服务组件的URI包括用于表征广播事件的信息;
所述第一发送单元具体用于:
根据所述信息实体中目标服务组件的URI中所包括的用于表征广播事件的信息,确定注册监听所述事件的至少一个第二服务组件;
向注册监听所述事件的第二服务组件发送所述信息实体。
优选地,所述信息实体中还包括指示信息,所述指示信息被所述第二服务组件用来确定所进行的处理操作。
其中,所述指示信息中包括第一指示信息;
所述第一指示信息用于指示所述第一服务组件和所述第二服务组件是否在同一服务组件组内。
其中,所述服务组件组中包括至少2个服务组件,所述服务组件组根据业务场景设置。
优选地,所述指示信息中包括第二指示信息;
所述第二指示信息用于指示所述目标服务组件是否需要进入指定的状态,或者指示所述目标服务组件与用户界面的交互方式。
其中,所述指定的状态,包括以下状态中的一种:
隐藏状态,该状态下的服务组件在后台运行,对用户不可见;
可见地非交互状态,该状态下的服务组件对用户可见,但不响应用户输入;
可见地交互状态,该状态下的服务组件对用户可见,并且响应用户输入。
优选地,所述交互方式,包括以下方式中的一种:
可见地交互方式;
可见地非交互方式。
进一步地,所述信息实体中还包括:
所述第一服务组件的URI;和/或
所述第二服务组件的组件标识ID,所述组件标识ID用于在所述第二服务组件存在多个实例时,指示所述多个实例中与所述ID对应的实例。
优选地,所述第二服务组件为本地服务组件或远程服务组件。
其中,所述第一发送单元具体用于:
确定所述第二服务组件为本地服务组件或远程服务组件;
若为远程服务组件,则向所述第二服务组件对应的服务器发送所述信息实体。
进一步地,所述第二接收单元还用于:在向所述第二服务组件对应的服务器发送所述信息实体之后,接收所述服务器发送的对所述信息实体的处理结果;所述第二发送单元还用于:将所述服务器发送的处理结果发送给所述第一服务组件。
本申请实施例提供的服务组件,所述服务组件为第一服务组件,该服务组件包括:
生成单元,用于根据接收到的信息生成指向第二服务组件的信息实体,所述接收到的信息包括事件和/或数据;
发送单元,用于发送所述信息实体。
优选地,所述事件,包括:
所述第一服务组件对应的用户界面UI上的控件被触发产生的事件;或
设定的系统事件;
设定的非系统事件。
优选地,所述生成单元具体用于:
根据接收到的事件,确定所述事件被配置的目标服务组件;
将所述目标服务组件的统一资源标识符URI,写入所述信息实体的相应字段。
进一步地,所述生成单元还用于:
在根据接收到的信息生成所述信息实体时,还包括以下至少一项:
将接收到的事件和/或数据,写入所述信息实体的相应字段。
优选地,所述第二服务组件为本地服务组件或远程服务组件。
进一步地,还包括:第一接收单元,用于接收所述第二服务组件返回的对所述信息实体的处理结果。
进一步地,还包括:
第二接收单元,用于接收第三服务组件发送的指向所述第一服务组件的信息实体;
处理单元,用于处理所述第二接收单元接收到的信息实体。
其中,所述处理单元具体用于:若所述接收单元接收到的信息实体中包括数据和事件,则根据所述信息实体中包括的数据,执行所述信息实体中包括的的事件所对应的操作。
本申请实施例提供的终端装置,包括:
存储器,用于存储计算机程序指令;
处理器,耦合到所述存储器,用于读取所述存储器存储的计算机程序指令,并作为响应,执行如下操作:
接收第一服务组件发送的指向第二服务组件的信息实体;
向所述第二服务组件发送所述信息实体。
本申请的上述实施例中,接收到第一服务组件发送的指向第二服务组件的信息实体后,向第二服务组件发送该信息实体,实现了服务组件之间基于信息实体进行交互,从而实现了服务组件之间的关联。操作系统中的服务组件可以执行指定功能或提供指定服务,该功能或服务可以是系统的功能或服务,也可以是应用程序可提供的功能或服务,多个服务组件间传递的信息实体可以实现在多个服务组件间进行交互,进而实现特定场景下的业务。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请作进一步地详细描述,显然,所描述的实施例仅仅是本申请一部份实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本申请保护的范围。
下面结合附图对本申请实施例进行详细描述。
本申请实施例提供了一种服务组件管理方案,用于实现不同服务组件的交互和关联,进而可为实现不同服务组件之间的跳转。本申请实施例可应用于各种操作系统,比如云OS,尤其适用于YunOS。以下实施例均以YunOS为例,描述基于YunOS的服务组件管理方案。
下面首先对YunOS中与本申请实施例相关的架构以及组成部分进行说明。
(1)Page
Page称为服务组件,是对本地服务和远程服务的抽象,也即服务的基本单元,通过对数据和方法的封装,可以提供各种服务。一个服务场景可以包括多个Page。举例来说,一个Page可以是UI(用户界面)、拍照等服务,也可以是后台服务,如账户认证。运行态Page称为Page实例,是本地服务或远程服务的运行载体,可由DPMS创建(比如DPMS收到PageA发送的指向PageB的PageLink后可创建PageB的实例)、调度、管理,DPMS可维护Page实例的生命周期。
每个Page可以在YunOS中被唯一标识,比如可以使用URI(UniformResource Identifier,唯一资源标识符)对Page进行标识。URI可以通过各种方式生成,只要可以保证唯一性即可,本申请并不对URI的生成方式进行限制。
优选地,用于标识Page的URI中可包括以下信息域:
-资源类型域,用于承载资源类型指示信息;
-域名域,用于承载资源所属域的指示信息;
-路径域,用于承载资源所在的路径,比如资源在其所属域中的路径。
其中,资源的类型可包括三种,分别称为第一类型、第二类型和第三类型:
-第一类型:用于表示资源存储于外部存储器;
-第二类型:用于表示资源未存储于外部存储器,如存储于本地,比如未存储于外部存储器而存储于SIM卡中,且资源为应用程序本身的资源,比如,应用程序安装包解压后的资源;
-第三类型:用于表示资源未存储于外部存储器,如存储于本地,比如未存储于外部存储器而存储于SIM卡中,且资源为应用程序运行时的资源,比如,运行时产生的资源。
此外,资源类型还可以包括:
-第四类型,用于表示资源存储于网络侧(如云端)。
当然以上资源类型仅为示例,本申请实施例不排除其他资源类型分类方式。
进一步地,基于上述分类,资源类型域包括第一字段和第二字段。若第一字段的取值表明资源的类型为第一类型,则第二字段为空;否则,第二字段的取值表明资源的类型为第二类型或第三类型。
进一步地,用于标识Page的URI中还可包括以下信息域中的一种或组合:
-用户信息域,用于承载用户信息,该用户可以是资源请求方用户;
-参数域,用于承载参数。
下面示例性地示出了一种资源URI的格式:
scheme://username/domain/subscheme/path?param1=xxx¶m2=xxx
上述URI格式中的各信息域的含义如下所述:
scheme域:资源类型域,用于承载资源类型指示信息。该信息域为必选项。该信息域的取值为page或file。若scheme域的取值为file,则表示该资源为第一类型;若scheme域的取值为page,则需要进一步依据subscheme域的取值确定资源的类型。scheme域的取值还可以是“http”或“https”,表示访问的资源为云端资源。
subscheme域:扩展的资源类型域,用于承载资源类型的扩展指示信息。该信息域为可选项。当scheme域的取值为file时,URI中不包括subscheme域,或subscheme域的取值为Null;当scheme域的取值为page时,URI中包括subscheme域。subscheme域的取值可以是asset或data,若subscheme域的取值为asset,则表示该资源为应用程序本身的资源,若subscheme域的取值为data,则表示该资源为应用程序运行时的资源。
username域:用于承载发起资源访问请求的用户的信息,比如用户名;
domain域:用于承载资源所属的域的指示信息,比如域名;
path域:用于承载资源在其所属域中的路径,即相对路径;path中也可以包含“asset”或“data”,这里的asset或data代表相对路径的结构,比如其中的一级目录;
param域:用于承载需要传递的参数。
URI可以理解为一个地址链接,通过该URI可以唯一地确定出其对应的Page。例如,为了便于区分Page提供的服务,为该Page分配的URI中可以选择性地包括该服务的相关信息,例如:服务名称、服务内容、服务提供方等。
例如:A公司提供的日历服务,为其对应的Page分配的URI可以如下:
Page://calendar.a.com
其中:“Page://”用于区分该地址为Page对应的地址,以和其他类型的地址区分;“calendar”表示提供的服务名称;“a”表示该服务的提供方。
根据场景需求,一个Page可能需要创建多个Page实例,为便于区分同一Page的不同实例,可以进一步为每个Page实例分配唯一的Page ID进行标识,该标识可以在Page实例被创建时分配。Page实例是指Page的运行态,即本地或远程服务的运行载体,由DPMS(Dynamic Page Manager Service,动态Page管理服务)创建调度并管理其生命周期。进一步地,该Page ID可以被携带在信息实体PageLink中传递。
Page之间可以传递事件和/或数据,Page可以通过UI与用户进行交互,以提供服务,如图1所示,PageA可以向PageB发送事件(Event),并从PageB获取返回的数据(Data),PageA可以通过UI与用户交互。其中,PageA可以提供服务A,PageB可以提供服务B。进一步地,PageA还可以以UI方式向用户提供显示界面,通过该界面为用户展示服务以及接收用户的各种输入,PageB可以主要在后台运行,可以为其他Page提供服务支持。
Page可被创建和销毁。Page从创建到销毁有三种状态:
Created(建立)状态:表示Page被创建,Page被创建(即被实例化)后首先进入Created状态;
Running(运行)状态:Page被激活后进入Running状态,Running状态下的Page之间能够传递事件和/或数据,以及能够处理其他Running状态的Page传递来的事件和/或数据;
Stopped(停止)状态:Page被去激活后进入Stopped状态,Stopped状态下的Page不能够与其他Page进行事件和/或数据的传递。
Page可在上述不同状态之间进行转换,并在转换的时接收到生命事件通知,该生命事件通知用于指示Page转换后的状态。其中,Page的状态转换以及生命事件通知可以由DPMS控制。图2示出了Page状态转换示意图,如图2所示,当Page从Created状态进入Running状态时,会收到onStart事件,当Page从Running状态进入Stopped状态时,会收到onStop事件,Page在Running状态下,可以通过onLink接口接收到其他Page发来的Pagelink。。其中,onStart事件是用于指示Page开始进入Running状态的生命事件通知,onStop事件是用于指示Page开始进入Stopped状态的生命事件通知。
若Page具有用UI(用户界面),则Running状态可以扩展成为以下三种状态中的一种:
Hided(隐藏)状态:Hided状态下的Page能够在后台运行,对于用户来说不可见;
Showed-inactive(可见地非交互)状态:Showed-inactive状态下的Page对于用户来说可见,但是不响应用户输入;
Showed-active(可见地交互)状态:Showed-active状态下的Page对用户来说可见,并且可以响应用户输入。
例如:PageA为全屏窗口,PageB为非全屏窗口,当PageB在PageA之上显示时,PageA是Showed-inactive状态,PageB是Showed-active状态。
通过生命事件通知,Page可在上述不同状态之间进行转换。图3示出了Page状态转换示意图,如图所示,Hided状态下的Page收到onShow事件后进入Showed-inactive状态,Showed-inactive状态下的Page收到onHide事件后进入Hided状态;Showed-inactive状态下的Page收到onActive事件后进入Showed-active状态,Showed-active状态下的Page收到onInactive事件后进入Showed-inactive状态。
(2)PageLink
PageLink是Page之间流转的信息实体,可以在Page间传递信息,例如,事件和/或数据等。具体传递数据可以使用设定的API(Application ProgrammingInterface,应用程序编程接口),YunOS以此为基础记录服务组件之间的关联关系。PageLink可以指定目标Page的URI,并且可以包含事件、数据、服务等信息中的一种或多种。
Page通过PageLink以更加灵活的方式的组合,可以实现丰富的服务场景。
(3)DPMS
DPMS是Dynamic Page Manager Service的英文简称,中文称为动态Page管理服务,可以被看作是服务组件管理实体,是一种系统服务。DPMS可以管理Page生命周期以及运行时调度,Page从创建到销毁的生命周期管理,以及Page间经PageLink的交互都可以通过DPMS实现。
基于以上描述,本申请实施例提供了一种服务组件管理系统,该系统可包括服务组件管理实体以及N个(N为大于1的整数)服务组件。基于该架构,服务组件管理实体可接收一个服务组件(为方便描述,此处称为第一服务组件)发送的指向另一个服务组件(为方便描述,此处称为第二服务组件的信息实体),并发送该信息实体给第二服务组件进行处理。
以YunOS为例,该服务组件管理系统可以被看作是YunOS中的一个组成部分。如图4所示,该服务组件管理系统可包括DPMS以及N个Page。其中,DPMS可以是OS内的资源调度管理模块,各种Page可组成一个服务资源池。相应地,DPMS可接收一个Page(为方便描述,此处称为第一Page)发送的指向另一个Page(为方便描述,此处称为第二Page),并发送该PageLink给第二Page进行处理,从而实现不同Page之间的交互、关联以及跳转。
下面结合图5,以YunOS为例,对上述服务组件管理过程进行详细描述。
如图5所示,该过程可包括如下步骤:
步骤502:第一Page向DPMS发送指向第二Page的信息实体(以下称PageLink),DPMS接收第一Page发送的指向第二Page的PageLink。
其中,第一Page可以是本地Page也可以是远程Page,同样,第二Page可以是本地Page也可以是远程Page。通常,作为PageLink发送方的第一Page在Running状态下发送指向第二Page的PageLink。
进一步地,在步骤502之前,可以包括以下步骤:第一Page根据接收到的信息生成指向第二Page的PageLink,所述接收到的信息可包括事件和/或数据。具体来说,触发第一Page生成PageLink的因素可能存在以下情况中的一种或多种组合:
-接收到其他Page发送来的PageLink;
-对其他Page发送来的PageLink进行处理,根据第一PageLink的业务处理逻辑需要向第二Page发送PageLink;
-接收到其他Page返回的处理结果后,根据第一PageLink的业务处理逻辑需要向第二Page发送PageLink;
-用户在第一Page对应的用户界面上进行了界面操作,该界面操作触发第一Page生成指向第二Page的PageLink;
-设定的事件(包括系统事件或自定义事件)发生,因此触发第一Page生成指向第二Page的PageLink;
-根据设定的时间点或周期,第一Page生成指向第二Page的PageLink。
其中,第一Page根据接收到的事件生成指向第二Page的PageLink时,所述事件可包括以下事件中的一种:
-第一Page对应的UI上的控件被触发产生的事件;
-设定的系统事件;
-设定的非系统事件,可以是自定义的事件。
更具体地,第一Page在生成PageLink时,可根据接收到的事件,确定该事件被配置的目标Page,将该目标Page的URI写入指向该目标Page的PageLink的相应字段。
更具体地,第一Page在生成PageLink时,还可指向以下至少一项:将接收到的事件和/或数据,写入该PageLink的相应字段。
步骤504:DPMS向第二Page发送该PageLink。
该步骤中,DPMS可首先确定第二Page为本地Page还是远程Page,若为远程Page,则向第二Page对应的服务器发送该PageLink。通常,具体实施时,每个Page在发布时,会有一个列表,用于维护哪些Page是本地的,哪些是在云端,如果在本地,则需要在本地保存该Page对应的代码,如果在云端,则将PageLink发到云端(根据云端提供的URL),由云端反馈处理结果。
进一步地,步骤504之后还可以包括如下步骤:
步骤506:第二Page处理接收到的PageLink,并向DPMS返回对该PageLink的处理结果;
步骤508:DPMS接收第二Page返回的处理结果,并将第二Page返回的处理结果发送给第一Page。
对于上述步骤506至步骤508,如果在步骤504中DPMS向第二Page对应的服务器发送该PageLink,则在步骤506中,第二Page对应的服务器向DPMS返回对该PageLink的处理结果,在步骤508中,DPMS将该服务器发送的处理结果发送给第一Page。
进一步地,DPMS在收到第一Page发送的指向第二Page的PageLink后,可以首先创建第二Page的实例,即在步骤504之前,还可以包括如下步骤:
步骤503:DPMS创建第二Page的实例,该实例用于处理第一Page发送的PageLink。进一步地,根据前述内容,Page具有不同的状态,优选地,在创建第二Page的实例的同时还可以将其状态设置为Running状态,通常Running状态下的Page才能给处理接收到的PageLink。
具体地,DPMS创建第二Page的实例的过程可包括:获取第二Page对应的可执行程序代码,运行该可执行程序代码,并为该可执行程序代码分配运行环境。具体地,可首先创建第二Page对应的进程,然后搭建该进程的运行环境,比如可设置第二Page自身的可执行代码的位置以及资源的位置,分配内存等,然后加载可执行代码以及资源的入口,启动该进程运行。具体实施时,可参照对象实例化的标准流程创建Page实例。
以PageA通过DPMS向PageB发送PageLink为例,PageA通过DPMS向PageB发送PageLink的过程可如图6所示。其中,PageA生成指向PageB的PageLink并发送给DPMS,DPMS触发PageB进入Running状态(即激活PageB)并将该PageLink发送给PageB,PageB处理接收到的PageLink,并将处理结果发送给DPMS,DPMS将该处理结果返回给PageA。
上述流程中第一Page发送指向第二Page的PageLink中,至少包括目标Page的URI,也可以进一步包括第一Page的URI。在一种替换的方案中,第一Page发送的PageLink中不包含该第一Page的URI,DMPS在接收到该PageLink后将该第一Page的URI等标识信息添加到该PageLink中。在系统运行过程中,DPMS或者YinOS系统的核心框架层可记录各Page之间的关联关系,比如记录PageLink的发送方Page的URI以及接收方Page的URI。
该目标Page的URI对应一个第二Page,或者对应多个第二Page。具体实施时,Page的URI可以分为两种类型:明确的URI和泛指的URI,明确的URI对应一个Page,泛指的URI对应多个Page,比如,可以预留一些URI作为泛指的URI,这部分URI并不对应一个唯一的Page,而是可以对应多个Page。泛指的URI是系统预留的,通常不允许有Page自身的URI和泛指URI相同。
作为一个例子,DPMS对目标Page的URI为泛指URI的PageLink的处理方式是:接收到这样的PageLink后,查找系统中所有的Page,凡是注册监听了PageLink携带的Event的Page都会收到此PageLink以进行处理。
优选地,本申请的一些优选实施例中,第一Page发送的指向第二Page的PageLink中,在第二Page的URI中还可以附带一些参数,以便传递给第二Page。该参数用来指示第二Page的设定入口,比如,第二Page的服务入口、功能入口、信息入口等,该参数通常与页面加载相关,一般来说,不需加密、与页面加载相关的参数可附带在URI中。
作为一个例子,发送到设置页面的PageLink中所包含的目标Page的URI为:
page://setting.example.com/setting?subpage=wifi
其中,subpage=wifi为附带在该URI中的参数,则设置页面会根据subpage=wifi直接跳转wifi设置二级页面。这些参数与URI的格式要求可参照HTML协议的规定,或者其他协议规定,只要第二Page能够识别即可。通过在URI中附加参数,可以更好地兼容HTML5页面。
在另一些优选的实施例中,附带在第二Page的URI中的参数可根据第一Page接收到的事件确定,即,第一Page根据接收到的事件确定需要在目标PageURI中携带的参数。例如,这些事件可包括以下之一或任意组合:
-第一Page对应的UI上的控件被触发产生的事件;
-设定的系统事件;
-设定的非系统事件。
进一步地,指向第二Page的PageLink中还可以包括以下内容之一或组合:
-数据(Data)
第二Page处理发送来的PageLink时,可根据传递来的Data处理该PageLink。
传递给第二Page的数据可以有一个或多个,传递给第二Page的数据可以有多种数据类型,比如这些数据类型可以包括数字(整数或浮点数),字符串,逻辑值(true或false),数组,对象,null等,在此不再一一列举。
优选地,这些数据可采用JSON(JavaScript Object Notation,JavaScript对象标记)格式进行组织。JSON格式是一种轻量级的数据交换格式。JSON采用完全独立于语言的文本格式,是一种适合数据交换的语言,易于阅读和编写,同时也易于机器解析和生成。JSON的数据格式采用名称/值对组合对形式,名称/值对组合中的名称写在前面(在双引号中),值对写在后面(同样在双引号中),中间用冒号隔开,不同的名称/值对组合中间用逗号隔开,例如,{"key1":"value1","key2":"value2"}。当然,也可以采用其他数据结构组织这些Data,比如XML(ExteileMarkuLaguage,扩展标记语言),在此不再一一列举。
需要说明的是,第一Page通过PageLink传递给第二Page的数据,可以携带于PageLink中的Data字段或信息单元,也可以附加在目标Page的URI中。这些数据是通过Data字段传递还是附加在目标Page的URI中传递,可以由通信双方(Page)预先约定。
-事件(Event)
第二Page可根据传递来的Event执行相应的操作。
作为一个例子,若指向第二Page的PageLink中包括数据和事件,则第二Page处理该PageLink包括:根据该PageLink中包括的数据,执行该PageLink中包括的事件所对应的操作。例如,通过PageLink传递给第二Page的事件为当用户点击网页上的“支付”按键执行支付事件,通过该PageLink传递给第二Page的数据包括用户账号、支付金额、收款方,则第二Page在处理该PageLink时可执行以下操作:当用户点击网页上的“支付”按键时,用该用户账号登录支付应用页面,向该收款方进行该金额的网上支付操作。
事件(Event)是可以被控件识别的操作,如按下确定按钮,选择某个单选按钮或者复选框。每一种控件有自己可以识别的事件,如窗体的加载、单击、双击等事件,编辑框(文本框)的文本改变事件,等等。事件有系统事件和用户事件。系统事件由系统激发,用户事件由用户激发。事件驱动控件执行某项功能。
第一Page发送的指向第二Page的PageLink中,可以传递一个或多个Event,传递的Event的类型可以包括系统事件和/或用户事件。
进一步地,在一些优选实施例中,可以预先定义两种事件类型:广播事件和非广播事件,所谓广播事件是指被注册为需要进行广播的事件,所谓非广播事件是指未被注册为需要广播的事件。比如,可以将系统相关的事件(比如系统关闭的事件,该事件可对应一系列关闭系统的操作,如退出用户界面等操作)定义为广播事件,广播事件的发生通常不仅仅是影响目标Page(比如上述第二Page)而是还会影响除此以外的其他Page;相对应地,将其他与特定业务相关的事件(比如网上支付操作的事件,该事件可对应网上支付的操作)定义为非广播事件。广播事件可默认被所有Page监听,也可针对广播事件预先注册监听该广播事件的一个或多个Page。优选地,广播事件可通过URI中包含的用于表征广播事件的信息进行标识。
DPMS接收到第一Page发送的PageLink后,会识别其中包含的事件类型是广播事件还是非广播事件,如果其中包含广播事件,则针对该广播事件,DPMS可以确定注册监听该事件的Page,并向注册监听该事件的Page发送该PageLink,以便这些Page进行相应操作,优选地,向注册监听该事件的所有Page发送该PageLink,其中,可预先配置所有或部分特定的Page监听广播事件;如果该PageLink中包含非广播事件,则针对该非广播事件,DPMS可将该PageLink发送给第二Page,以便第二Page根据该非广播事件进行相应操作。
作为广播事件的一个例子,比如针对系统关机这个场景,电源管理服务发送一个PageLink,该PageLink中包含“URI=broadcast.yunos.com,event=shutdown”,其中“broadcast”表示名称为shutdown的事件是广播事件,则DPMS将该PageLink向所有注册监听该shutdown事件的Page发送。作为非广播事件的一个例子,比如针对账号登录场景,登录页面可以发送一个点对点的PageLink给账号服务,该PageLink中包含“URI=account.yunos.com,event=login,data={id=a,passwork=b}”,由于其中没有包含用于表征名称为login的事件为广播事件的信息,则DPMS将该PageLink向目标Page发送。
在上述各种实施例中的PageLink所包含的内容的基础上,在一些实施例中,第一Page发送的指向第二Page的PageLink中还可包括指示信息,该指示信息被目标Page用来确定所进行的处理操作。指示信息的数量和类型不做限制。
举例来说,指示信息中可包括第一指示信息,该第一指示信息用于指示第一Page和目标Page(比如上述第二Page)是否在同一Page组内。优选地,该第一指示信息可以是布尔型数据,比如第一指示信息的取值为True时表示第一Page(PageLink的发送者)和第二Page(PageLink的接收者)在同一Page组内,第一指示信息的取值为False时表示第一Page和第二Page可以不在同一Page组内。
一个Page组中可包括一个或多个Page。Page组可以预先配置,也可以根据需要进行调整,比如可以由发起者(如上述的第一Page)在PageLink中指定。一个Page组中的Page可根据业务场景来设置,一个Page组中的Page通常与特定的业务或者业务场景相关,比如,对于旅游出行业务场景来说,可以将实现机票查询的Page以及实现网上订购机票进行支付的Page配置在一个Page组内;再例如,对于日常订餐的业务场景来说,可以将订餐查询的Page以及实现网上订餐支付的Page配置在一个Page组内。
以上述旅游出行场景为例,第一Page为实现机票查询的Page,第二Page为实现订购机票进行支付的Page,第一Page发送的指向第二Page的PageLink中,第一指示信息的取值为True,表示第一Page和第二Page应在同一Page组内。这种情况下,DPMS在接收到第一Page发送的该PageLink后,可以判断当前是否存在与第一Page在同一Page组的第二Page,如果没有,则创建第二Page的实例,该第二Page的实例与第一Page属于同一Page组,在创建第二Page的实例时,可以根据旅游出行场景的需要创建适合该业务场景的实例,比如允许使用信用卡支付但不能使用其他预付卡支付。
以上述日常订餐场景为例,第一Page为实现订餐查询的Page,第二Page为实现网上订餐支付的Page,第一Page发送的指向第二Page的PageLink中,第一指示信息的取值为False,表示第一Page和第二Page不在同一Page组内。这种情况下,DPMS在接收到第一Page发送的该PageLink后,如果当前已创建第二Page的实例且该实例不属于任何Page组,则可以将该PageLink发送给第二Page进行处理。
通过Page组的划分,对于一种通用的服务组件,比如实现支付的服务组件,可以根据不同的业务场景需要,创建适合于不同业务场景的实例。
再举例来说,PageLink所包含的指示信息中可包括第二指示信息,该第二指示信息用于指示目标Page是否进入指定的状态,该指定的状态具体可以包括Showed-active状态或者其他状态(如Hided、Showed-inactive等状态)。优选地,该第二指示信息可以是布尔型数据,比如第二指示信息的取值为True时表示第二Page(PageLink的接收者)需要进入指定的状态,第二指示信息的取值为False时表示第二Page不需要进入指定的状态。该第二指示信息也可以用于指示目标Page与UI的交互方式(比如可见地交互方式或非可见地交互方式)。优选地,该第二指示信息可以是布尔型数据,比如第二指示信息的取值为True时表示第二Page(PageLink的接收者)需要采用可见地交互方式与UI交互,第二指示信息的取值为False时表示第二Page不需要采用可见地交互方式与UI交互(或者采用可见地非交互方式与UI交互)。
如前所述,Page的Running状态可进一步细分为Hided状态、Showed-inactive状态和Showed-active状态。在一些实施例中,第二Page可根据第一Page发送的PageLink中的第二指示信息,确定是否进入Showed-active状态。
根据上述对PageLink的内容描述,表1示例性地示出了一种PageLink的数据结构。
表1:PageLink的组成
在一个PageLink中,目标Page的URI一项,仅填写“明确的URI”或者“泛指的URI”。表1中的needActibe=True时,目标Page被激活,即进入Showed-active状态。表1中,除Referer字段以外,其他字段可由PageLink发送方指定,Referer字段可由YunOS系统的核心框架层自动填写。
在实际的业务场景中,可能需要多个Page以串联的方式进行交互,比如PageA需要通过PageLink传递数据和事件给PageB,PageA也可能同时需要通过PageLink传递数据和事件给PageC,PageB需要通过PageLink传递数据和事件给PageD等等,这种情况下,针对每两个需要通过PageLink传递数据和事件的Page,均可按照上述实施例提供的方式进行交互,从而将一个业务过程所需的所有Page串联起来,基于PageLink进行数据和事件的传递,完成该业务过程。
图7示例性地示出了两种业务场景下,Page的关联情况示意图。其中,在业务场景1下,用户在该业务的UI界面上的操作触发Page1生成指向Page2的PageLink并通过DPMS发送给Page2,Page2收到Page1发送的PageLink后进行处理并生成指向Page3的PageLink,并通过DPMS发送给Page3,Page3收到该PageLink后进行处理,一方面生成指向Page4的PageLink并通过DPMA发送给Page4处理,另一方面生成指向Page9的PageLink并通过DPMS发送给Page9处理,Page4收到PageLink后进行处理并返回处理结果给Page3。
在场景2下,用户在该业务的UI界面上的操作触发Page5生成指向Page2的PageLink并通过DPMS发送给Page2,Page2收到Page5发送的PageLink后进行处理并生成指向Page6的PageLink,并通过DPMS发送给Page6处理,Page6收到PageLink后进行处理并生成指向Page7的PageLink,并通过DPMS发送给Page6处理,Page7收到PageLink后进行处理并生成指向Page10的PageLink,并通过DPMS发送给Page10处理,Page10收到PageLink后进行处理并返回处理结果给Page7。
以旅游出行的业务场景为例,如果要完成该场景的一个业务过程,需要多种Page且需要按照一定的逻辑顺序运行这些Page,比如一种实现方式为:
1、PageA向DMPS发送指向PageB的PageLink
PageA为旅游出行攻略应用,PageB为机票酒店查询应用;该PageLink中的options一项中,inGroup=false,needActive=True;该PageLink中的Data一项中,需要传递的参数包括:目的地以及往返时间,还可以进一步包括一些其他参数,比如机票、酒店住宿的价格范围等参数,PageA可通过UI界面获取这些Data的具体取值并携带于PageLink;这样,PageB在收到该PageLink后可根据传递过来的目的地和往返时间查询相应的往返机票以及在该段时间内目的地的酒店情况,进一步地,PageB可将查询结果通过DMPS返回给PageA。
2、PageB向DMPS发送指向PageC的PageLink
PageC为支付应用;该PageLink中的options一项中,inGroup=true,needActive=true;该PageLink中的Data一项中,需要传递的参数包括:订购的飞机航班信息、订购的酒店信息,用户的支付账户信息等;这样,PageB在收到该PageLink后可使用该支付账户根据传递过来的机票以及酒店的订购信息进行支付,进一步地,PageC可将支付结果通过DMPS返回给PageB;
3、PageA向DMPS发送指向PageD的PageLink
PageD为天气查询应用;该PageLink中的options一项中,inGroup=false,needActive=false;该PageLink中的Data一项中,需要传递的参数包括:目的地以及往返时间;这样,PageD在收到该PageLink后可根据传递过来的目的地和往返时间,查询在相应时间段内该目的地的天气情况,进一步地,PageD可将查询结果通过DMPS返回给PageA。
通过以上描述可以看出,在YunOS中,可以用十分自然的方式将以一个业务场景所需的所有Page串联起来,如以上例子所展示的:浏览网页寻找攻略,跳转到感兴趣地点的酒店和机票服务Page,跳转到支付服务Page,跳转到天气服务页面。跳转过程中通过PageLink将前一Page的数据传递到下一Page,不需要用户重复的数据输入。其中,一个Page提供某项本地或远端的服务,Page之间跳转没有应用的限制,通过PageLink将几个Page组合起来就可以实现各种服务的需求。
上述各实施例可应用于云OS操作系统。云OS也可称为云操作系统或者云计算操作系统或者云计算中心操作系统,是以云计算、云存储技术作为支撑的操作系统,是云计算后台数据中心的整体管理运营系统。它是指构架于服务器、存储、网络等基础硬件资源和单机操作系统、中间件、数据库等基础软件之上的、管理海量的基础硬件、软件资源的云平台综合管理系统。
基于相同的技术构思,本申请实施例还提供了一种服务组件管理装置,该装置可以是前述实施例中的DPMS。
参见图8,为本申请实施例提供的服务组件管理装置的结构示意图,该装置可包括:第一接收单元801、第一发送单元802,其中:
第一接收单元801,用于接收第一服务组件发送的指向第二服务组件的信息实体;
第一发送单元802,用于向所述第二服务组件发送所述信息实体。
进一步地,该装置还可包括创建单元803,用于在向所述第二服务组件发送所述信息实体之前,创建第二服务组件的实例。具体地,创建单元803可具体用于:获取所述第二服务组件对应的可执行程序代码,运行所述可执行程序代码,并为所述可执行程序代码分配运行环境。
进一步地,上述装置中还可包括:
第二接收单元804,用于向所述第二服务组件发送所述信息实体之后,接收所述第二服务组件返回的对所述信息实体的处理结果;
第二发送单元805,用于将所述第二服务组件返回的处理结果发送给所述第一服务组件。
优选地,所述第二服务组件为本地服务组件或远程服务组件。
相应地,第一发送单元802具体用于:确定所述第二服务组件为本地服务组件或远程服务组件,若为远程服务组件,则向所述第二服务组件对应的服务器发送所述信息实体。
相应地,第二接收单元804,用于在向所述第二服务组件对应的服务器发送所述信息实体之后,接收所述服务器发送的对所述信息实体的处理结果;第二发送单元805,用于将所述服务器发送的处理结果发送给所述第一服务组件。
优选地,所述信息实体中至少包括目标服务组件的URI,所述目标服务组件的URI对应一个第二服务组件,或者对应多个第二服务组件。
其中,所述目标服务组件的URI中还附带有参数。
其中,所述参数根据所述第一服务组件接收到的事件确定。
其中,所述事件,包括:
所述第一服务组件对应的用户界面UI上的控件被触发产生的事件;
设定的系统事件;
设定的非系统事件。
优选地,所述参数用于指示所述第二服务组件的设定入口。
优选地,所述信息实体中还包括以下内容之一或任意组合:数据,事件。
优选地,所述信息实体中至少包括目标服务组件的URI和事件时,所述目标服务组件的URI包括用于表征广播事件的信息。相应地,第一发送单元802具体用于:根据所述信息实体中目标服务组件的URI中所包括的用于表征广播事件的信息,确定注册监听所述事件的至少一个第二服务组件,向注册监听所述事件的第二服务组件发送所述信息实体。
进一步地,所述信息实体中还包括指示信息,所述指示信息被所述第二服务组件用来确定所进行的处理操作。
其中,所述指示信息中包括第一指示信息;所述第一指示信息用于指示所述第一服务组件和所述第二服务组件是否在同一服务组件组内。
其中,所述服务组件组中包括至少2个服务组件,所述服务组件组根据业务场景设置。
优选地,所述指示信息中包括第二指示信息;所述第二指示信息用于指示所述目标服务组件是否需要进入指定的状态,或者指示所述目标服务组件与用户界面的交互方式。
其中,所述指定的状态,包括以下状态中的一种:
隐藏状态,该状态下的服务组件在后台运行,对用户不可见;
可见地非交互状态,该状态下的服务组件对用户可见,但不响应用户输入;
可见地交互状态,该状态下的服务组件对用户可见,并且响应用户输入。
其中,所述交互方式,包括以下方式中的一种:
可见地交互方式;
可见地非交互方式。
优选地,所述信息实体中还包括:所述第一服务组件的URI;和/或,所述第二服务组件的组件标识ID,所述组件标识ID用于在所述第二服务组件存在多个实例时,指示所述多个实例中与所述ID对应的实例。
基于相同的技术构思,本申请实施例还提供了一种服务组件。
参见图9,为本申请实施例提供的服务组件的结构示意图,如图所示,该服务组件可包括:生成单元901、发送单元902,其中:
生成单元901,用于根据接收到的信息生成指向第二服务组件的信息实体,所述接收到的信息包括事件和/或数据;
发送单元902,用于发送所述信息实体。
其中,所述第二服务组件为本地服务组件或远程服务组件。
优选地,所述事件,包括:
所述第一服务组件对应的用户界面UI上的控件被触发产生的事件;或
设定的系统事件;
设定的非系统事件。
优选地,生成单元901可具体用于:
根据接收到的事件,确定所述事件被配置的目标服务组件;
将所述目标服务组件的统一资源标识符URI,写入所述信息实体的相应字段。
进一步地,所述生成单元还可用于:
在根据接收到的信息生成所述信息实体时,还包括以下至少一项:
将接收到的事件和/或数据,写入所述信息实体的相应字段。
进一步地,上述装置中还可包括第一接收单元903,用于接收所述第二服务组件返回的对所述信息实体的处理结果。
进一步地,上述装置中还可包括:第二接收单元904和处理单元905,其中,第二接收单元904可用于接收第三服务组件发送的指向所述第一服务组件的信息实体;处理单元905可用于处理所述第二接收单元接收到的信息实体。
更具体地,处理单元905可具体用于:若所述接收单元接收到的信息实体中包括数据和事件,则根据所述信息实体中包括的数据,执行所述信息实体中包括的的事件所对应的操作。
基于相同的技术构思,本申请实施例还提供了一种终端装置。
参见图10,为本申请实施例提供的终端装置的结构示意图,该终端装置总体来说可包括:处理器1001,存储器1002、显示器1003。
其中,处理器1001可以是通用处理器(比如微处理器或者任何常规的处理器等)、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。存储器1002具体可包括内部存储器和/或外部存储器,比如随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质。显示器1003可包括触摸屏控制电路。
处理器1001与其他各模块之间存在数据通信连接,比如可基于总线架构进行数据通信。总线架构可以包括任意数量的互联的总线和桥,具体由处理器1001代表的一个或多个处理器和存储器1002代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口提供接口。处理器1001负责管理总线架构和通常的处理,存储器1002可以存储处理器1001在执行操作时所使用的数据。
本申请实施例揭示的流程,可以应用于处理器1001中,或者由处理器1001实现。在实现过程中,各步骤可以通过处理器1001中的硬件的集成逻辑电路或者软件形式的指令完成。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。
具体地,处理器1001,耦合到存储器1002,用于读取存储器1002存储的计算机程序指令,并作为响应,执行如下操作:
接收第一服务组件发送的指向第二服务组件的信息实体;
向所述第二服务组件发送所述信息实体。
进一步地,处理器1001向所述第二服务组件发送所述信息实体之前,还用于:创建第二服务组件的实例。
其中,处理器1001创建第二服务组件的实例的过程,包括:
获取所述第二服务组件对应的可执行程序代码;
运行所述可执行程序代码,并为所述可执行程序代码分配运行环境。
进一步地,处理器1001还可用于:在向所述第二服务组件发送所述信息实体之后,接收所述第二服务组件返回的对所述信息实体的处理结果,将所述第二服务组件返回的处理结果发送给所述第一服务组件。
优选地,所述信息实体中至少包括目标服务组件的URI,所述目标服务组件的URI对应一个第二服务组件,或者对应多个第二服务组件。
其中,所述目标服务组件的URI中还附带有参数。
其中,所述参数根据所述第一服务组件接收到的事件确定。
其中,所述事件,包括:
所述第一服务组件对应的UI上的控件被触发产生的事件;
设定的系统事件;
设定的非系统事件。
优选地,所述参数用于指示所述第二服务组件的设定入口。
优选地,所述信息实体中还包括以下内容之一或任意组合:数据,事件。
其中,若所述信息实体中包括数据和事件,则处理器1001可根据所述信息实体中包括的数据,执行所述信息实体中包括的的事件所对应的操作。
优选地,所述信息实体中至少包括目标服务组件的URI和事件时,所述目标服务组件的URI包括用于表征广播事件的信息。相应地,处理器1001可用于:根据所述信息实体中目标服务组件的URI中所包括的用于表征广播事件的信息,确定注册监听所述事件的至少一个第二服务组件,向注册监听所述事件的第二服务组件发送所述信息实体。
优选地,所述信息实体中还包括指示信息,所述指示信息被所述第二服务组件用来确定所进行的处理操作。
其中,所述指示信息中包括第一指示信息;所述第一指示信息用于指示所述第一服务组件和所述第二服务组件是否在同一服务组件组内。
其中,所述服务组件组中包括至少2个服务组件,所述服务组件组根据业务场景设置。
优选地,所述指示信息中包括第二指示信息;所述第二指示信息用于指示所述目标服务组件是否需要进入指定的状态,或者指示所述目标服务组件与用户界面的交互方式。
其中,所述指定的状态,包括以下状态中的一种:
隐藏状态,该状态下的服务组件在后台运行,对用户不可见;
可见地非交互状态,该状态下的服务组件对用户可见,但不响应用户输入;
可见地交互状态,该状态下的服务组件对用户可见,并且响应用户输入。
其中,所述交互方式,包括以下方式中的一种:
可见地交互方式;
可见地非交互方式。
优选地,所述信息实体中还包括:
所述第一服务组件的URI;和/或
所述第二服务组件的组件标识ID,所述组件标识ID用于在所述第二服务组件存在多个实例时,指示所述多个实例中与所述ID对应的实例。
优选地,处理器1001可确定所述第二服务组件为本地服务组件或远程服务组件;若为远程服务组件,则向所述第二服务组件对应的服务器发送所述信息实体。
进一步地,处理器1001向所述第二服务组件对应的服务器发送所述信息实体之后,还可接收所述服务器发送的对所述信息实体的处理结果,并将所述服务器发送的处理结果发送给所述第一服务组件。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。