专利名称：在不同执行环境之间进行交换的方法和系统的制作方法
技术领域：
本发明总体上涉及在不同执行环境中的应用程序之间的通信，更具体地，涉及在不同执行环境之间的应用程序服务交换。
背景技术：
在许多嵌入式系统中，所有的应用程序在相同的固有执行环境中执行。执行环境在下述的方面限定了应用程序的可能性和约束如何访问和使用服务、如何接收事件、如何使用诸如存储器的共享资源、操作系统如何工作和如何使用操作系统、如何实现系统中的并行执行、以及如何在开始和停止方面对应用程序进行控制。换句话说，执行环境限定了应用程序的执行和安装的可能性和约束。对所有应用程序使用相同的执行环境意味着在整个系统中对所有应用程序的规则都相同，并且通过单个组织来控制执行环境规范。
然而，在移动设备中，引入其他执行环境(例如，非固有执行环境JAVA)，这些执行环境与移动设备的固有执行环境并行存在。而且，许多移动设备平台的客户具有私有的执行环境，这些执行环境被移植到移动设备平台上，以保持客户在遗留应用程序(legacy applications)中的投资。
诸如JAVA的标准化执行环境例如可以通过JAVA规范请求(JSR)规范对与标准化执行环境共存的其他执行环境赋予要求。例如，JSR 75规定当JAVA应用程序的最终用户编辑电话号码时，将调用系统中的现有电话簿，以使得能够选择所需的联系人，然后将该电话号码复制回JAVA应用程序的编辑域。因此，JAVA执行环境对可以在固有执行环境中或者另一商业/私有执行环境中执行的任意应用程序提出要求。由于这些应用程序的具体设计不在例如平台制造商的控制之下，所以这些要求需要使得不同执行环境中的应用程序能够跨越执行环境边界交换服务的技术。
发明内容
一种在不同执行环境之间进行应用程序服务交换的方法包括从在第一执行环境中进行操作的服务器应用程序接收用于处理服务的登记信息；从在第二执行环境中进行操作的客户端应用程序接收对该服务的请求；请求服务器应用程序的该服务；响应于该请求步骤从服务器应用程序接收结果；以及将该结果传送给客户端应用程序。
一种在不同执行环境之间进行应用程序服务交换的系统包括第一执行环境；适于在所述第一执行环境中执行的服务器应用程序；第二执行环境；适于在所述第二执行环境中执行的客户端应用程序；以及平台服务管理支持。所述平台服务管理支持适于接收所述客户端应用程序对服务的请求，请求服务器应用程序的该服务，以及将响应于该请求的结果传送给客户端应用程序。
结合附图，通过参考以下对本发明的示例性实施例的详细说明，可以更完整地理解本发明，其中图1是消息发送图，表示在客户端请求时，服务器已在运行时的客户端请求和该请求的服务器实现；图2是消息发送图，表示在客户端请求时，服务器没有运行时的客户端请求和该请求的服务器实现；以及图3是根据本发明的实施例，在不同执行环境之间的应用程序服务交换的逻辑框图概要。
具体实施例方式
现将参照附图更完整地描述本发明的实施例。然而，本发明可以以许多不同的形式实施，并且不应解释为限于在此所述的实施例。本发明应该仅被认为由现有的权利要求书及其等同物来限定。
根据本发明的原理，使用平台服务管理支持在服务级别上在客户端和服务器之间交换信息。例如，服务器将其自己登记为能够处理特定的服务或者一组服务，例如，上述示例中的“SupplyPhoneNumber(提供电话号码)”。如果在任意执行环境中的客户端请求该电话号码并且存在服务器登记，则通过移动设备平台服务管理支持将请求转发给被登记用于处理该服务的服务器。当该服务器已经执行了该服务时，通过该平台服务管理支持将结果转发给客户端。
通过在服务级别上而不是在它们各自的执行环境专用级别上定义在完全不同的执行环境中的客户端应用程序和服务器应用程序之间的连接，可以定义跨越执行环境边界交换信息的一般机制。端点(即，客户端和服务器)无需互相知晓，并且编译时和链接时彼此独立。端点只需了解平台服务管理支持并且与平台服务管理支持相适应。因此，平台服务管理支持可以作为服务路由器。从服务器的角度看，该平台只发布一组所请求的服务。从客户端的角度看，该平台发布一组潜在的可访问的服务。客户端可以指定服务，而服务器可以决定其是否能够处理该服务的请求。如果可以处理该请求，则服务器将其自己登记为能够处理该服务。
客户端(例如，在由JAVA标准化表示的示例中)指定服务，而服务器决定该服务器是否能够处理该请求。该客户端指定解决方案在一定程度上与大多数客户端一服务器设计相反，其中客户端进行检查以确定由特定服务器进行的服务的规范是否满足该客户端的需求。根据本发明的各种实施例的方法解决了这两种情况。与如何规定和表示服务及其功能性接口相关的两种示例性情况如下(1)以不限于特定执行环境或者服务的特定表示的方式来指定服务。然而，端点(即，客户端和服务器)必须与平台服务管理支持相适应。从实施的角度看，实现非特定服务表示的一种方式是使用字符串，除了字符编码方案以外，这些字符串独立于服务表示和执行环境。在这种情况下，例如，诸如“电话号码”和“地址”的概念表示对所有系统通用的数据语义。
(2)以与服务的平台服务管理支持表示相关的方式来指定服务。换句话说，端点(即，客户端和服务器)必须与平台服务管理支持相适应，并且知道如何通过互相知晓的平台服务管理支持来表示服务。
该平台服务管理支持包括两个部分(a)服务登记部分，用于跟踪哪一个服务器实施哪一个服务；以及(b)服务代理部分，其用作客户端和服务器的连接点。通过平台服务管理支持，将服务请求从客户端转发到服务器，并且将服务结果从服务器转发到客户端。
与平台服务管理支持在系统中位于何处和在哪里实施相关的三种示例性情况如下所述。平台服务管理支持位于何处的选择不会影响客户端或者服务器如何使用该平台服务管理支持。三种示例性的平台服务管理支持位置如下(1)将平台服务管理支持集成到平台中。
(2)以插件的形式实施平台服务管理支持。
在美国专利申请No.10/665,834中更详细地描述了插件，该申请的题目为“Plug-In Model”，并且通过引用将其并入。
(3)将平台服务管理支持的登记部分集成到平台中，而以插件的形式实施平台服务管理支持的服务代理部分。
对于外部可见性、集成度、进程和公司战略决策，如上所列出的三种平台服务管理支持位置中的每一种都具有不同的优点和缺点。例如，如果平台服务管理支持根据以上情况2或情况3定位，则例如需要固有服务的JAVA JSR的开发不必与总体平台开发同步。
现在参照附图，图3是根据本发明实施例的在不同执行环境之间的应用程序服务交换的逻辑框图概要。尽管图3表示平台服务管理支持位于平台中，但是本领域的普通技术人员应理解，平台服务管理支持可以根据上述三种情况中的任意一种定位而不会偏离本发明的原理。图3表示包括平台302的系统300。在美国专利申请No.10/359,835中更详细地讨论了诸如平台302的平台，该申请的题目为“Platform System forMobile Terminals”，并且通过引用将其并入。
平台302包括平台服务管理支持305。作为系统300的一部分，还示出了执行环境304、执行环境306和执行环境308。作为示例，执行环境304可以是JAVA执行环境，执行环境306可以是客户遗留执行环境，执行环境308可以是平台定义的执行环境。
在执行环境304中示出了客户端应用程序310。在执行环境308中示出了服务器应用程序312。在各个执行环境304、306和308中也示出了各种其他应用程序。平台服务管理支持305包括服务代理部分314和服务登记部分316。还示出了作为平台302的一部分的多个平台服务318、320、322和324。箭头326和328概括地表示了通过平台服务管理支持305在客户端应用程序310和服务器应用程序312之间进行的通信，箭头326和328表示通过客户端应用程序310转发到平台服务管理支持305的服务请求和通过平台服务管理支持305转发到服务器应用程序312的服务请求。
图1是消息发送图，表示在客户请求时，服务器已在运行时的客户请求和请求的服务器实现。移动设备100包括执行环境102、执行环境104和平台106。执行环境102包括服务器应用程序108。执行环境104包括客户端应用程序110。平台106包括平台服务管理支持112。
在消息114中，服务器应用程序108使用平台106的平台服务管理支持112，以登记为给定服务的处理器。平台服务管理支持112存储该信息。以语义学上的通用方式指定该服务。在消息116处，客户端应用程序110使用平台106的平台服务管理支持112来请求该服务。客户端应用程序110不知道哪一个服务器应用程序或者哪一个执行环境实施该服务；然而，平台服务管理支持112知道实施所请求服务的服务器应用程序的识别信息。平台服务管理支持112知道哪一个服务器应用程序实施该服务，并且在消息118处，将该服务请求转发给适当的服务器应用程序(即，服务器应用程序108)。
在消息120中，服务器应用程序108进行服务，并且将服务的结果传送到平台服务管理支持112。平台服务管理支持112知道请求该服务的客户端应用程序110，并且在消息122处，将该服务的结果传送到客户端应用程序110。
再次参照附图，图2是消息发送图，表示在客户请求时，服务器没有运行时的客户请求和客户请求的服务器实现。在步骤202中，当安装服务器应用程序108时，服务器应用程序108提供在平台服务管理支持112中进行服务登记所需的信息。平台服务管理支持112存储该信息。
在消息203处，客户端应用程序110使用平台106的平台服务管理支持112来请求服务。客户端应用程序110不知道哪一个服务器应用程序或者哪一个执行环境实施该服务；然而，平台服务管理支持112知道实施所请求服务的服务器应用程序的识别信息。平台服务管理支持112跟踪哪一个服务器应用程序实施该服务(即，服务器应用程序108)。如图2中所示，如果服务器应用程序108还没有启动，则在步骤204中，平台服务管理支持112启动该服务器应用程序。在消息206处，平台服务管理支持112将该服务请求传送到服务器应用程序108。服务器应用程序108进行服务，并且在消息208处，将该服务的结果传送到平台服务管理支持112。平台服务管理支持112知道哪一个客户端应用程序请求了该服务(即，客户端应用程序110)，并且在消息210处，将服务的结果传送到客户端应用程序110。
如果不希望例如由于启动由执行环境使用的应用程序的特定方式而如图2所示平台服务管理支持112自动启动服务器应用程序108，而是希望在客户端应用程序110请求服务器应用程序108的服务时，根据需要启动服务器应用程序108，则在服务器应用程序108的执行环境102中可以使用代理应用程序。代理应用程序将知道在相同执行环境(例如，执行环境102)中的各种服务器应用程序的服务，并且能够响应于例如来自平台服务管理支持112的请求根据需要启动服务器应用程序。
本发明的各种实施例用于允许根本不同的执行环境互连，排除实施差异，并且提供用于嵌入式移动设备平台的动态方式以建立任何应用程序服务器都可以满足的所需服务的规范。此外，可以按照普通的方式使用本发明的各种实施例，以在任意执行环境中的应用程序之间进行通信。可以在信息交换方面对不同执行环境之间的实施差异进行桥接(bridged)。此外，与指定由服务器提供的一组服务相反，可以指定由客户端要求的一组服务。例如，通过使用字符/字符串以避免表示的依赖性，来进行执行环境之间的信息交换。此外，服务器和客户端不需要彼此知晓。可以在不同执行环境中的两个端点之间建立通用服务请求信道。而且，本发明的各种实施例支持服务器驱动和客户端驱动的服务规范。
前面的具体描述是本发明的实施例。本发明的范围不受该描述的限制。本发明的范围是由以下权利要求书及其等同物来限定。
权利要求
1.一种在不同执行环境之间进行应用程序服务交换的方法，所述方法包括以下步骤从在第一执行环境中进行操作的服务器应用程序接收用于处理服务的登记信息；从在第二执行环境中进行操作的客户端应用程序接收对所述服务的请求；请求所述服务器应用程序的所述服务；响应于所述请求步骤从所述服务器应用程序接收结果；以及将所述结果传送到所述客户端应用程序。
2.根据权利要求1所述的方法，其中，在移动设备的平台内执行所述步骤。
3.根据权利要求2所述的方法，其中，通过所述移动设备的平台的平台服务管理支持来执行所述步骤。
4.根据权利要求1所述的方法，其中，所述客户端应用程序不知晓所述服务器应用程序或者所述第一执行环境的位置。
5.根据权利要求4所述的方法，其中，所述服务器应用程序不知晓所述客户端应用程序或者所述第二执行环境的位置。
6.根据权利要求1所述的方法，其中，以独立于执行环境的方式指定所述服务。
7.根据权利要求6所述的方法，其中，使用字符串表示所述服务。
8.根据权利要求1所述的方法，其中，根据平台服务管理支持特定表示来表示所述服务。
9.根据权利要求3所述的方法，其中，通过所述平台服务管理支持的登记部分来执行接收所述登记信息的所述步骤。
10.根据权利要求3所述的方法，其中，通过所述平台服务管理支持的服务代理部分来执行接收对服务的请求、请求所述服务、接收所述结果和传送所述结果的所述步骤。
11.根据权利要求1所述的方法，其中，通过移动设备的平台服务管理支持来执行所述步骤。
12.根据权利要求11所述的方法，其中，所述平台服务管理支持是所述移动设备的平台的一部分。
13.根据权利要求11所述的方法，其中，以所述移动设备的插件的形式来实现所述平台服务管理支持。
14.根据权利要求11所述的方法，其中，所述平台服务管理支持包括被实现为所述移动设备的平台的一部分的登记部分；以及以所述移动设备的插件形式实现的服务代理部分。
15.根据权利要求1所述的方法，还包括以下步骤客户端应用程序指定至少一个服务；以及服务器应用程序确定该服务器应用程序是否能够处理由所述客户端应用程序指定的服务。
16.根据权利要求1所述的方法，还包括以下步骤服务器应用程序指定至少一个服务；以及客户端应用程序确定由所述服务器应用程序指定的至少一个服务是否与客户端应用程序服务请求一致。
17.一种在不同执行环境之间进行应用程序服务交换的系统，所述系统包括第一执行环境；适于在所述第一执行环境中执行的服务器应用程序；第二执行环境；适于在所述第二执行环境中执行的客户端应用程序；平台服务管理支持；并且其中，所述平台服务管理支持适于接收所述客户端应用程序对服务的请求；从所述服务器应用程序请求服务；以及将响应于所述请求的结果传送到所述客户端应用程序。
18.根据权利要求17所述的系统，其中，所述平台服务管理支持还适于接收登记信息以通过所述服务器应用程序处理所述服务；以及响应于所述请求步骤，从所述服务器应用程序接收所述结果。
19.根据权利要求17所述的系统，其中，所述平台服务管理支持被实现为平台的一部分。
20.根据权利要求17所述的系统，其中，以插件的形式来实现所述平台服务管理支持。
21.根据权利要求17所述的系统，其中，所述平台服务管理支持包括被实现为平台的一部分的登记部分；以及以插件的形式实现的服务代理部分。
22.根据权利要求17所述的系统，其中，所述客户端应用程序不知晓所述服务器应用程序或者所述第一执行环境的位置。
23.根据权利要求22所述的系统，其中，所述服务器应用程序不知晓所述客户端应用程序或者所述第二执行环境的位置。
24.根据权利要求17所述的系统，其中，以独立于执行环境的方式来指定所述服务。
25.根据权利要求24所述的系统，其中，使用字符串表示所述服务。
26.根据权利要求17所述的系统，其中，根据平台服务管理支持特定表示来表示所述服务。
27.根据权利要求17所述的系统，其中，所述平台服务管理支持包括登记部分；以及服务代理部分。
28.根据权利要求17所述的系统，其中，所述客户端应用程序适于指定至少一个服务，所述服务器应用程序适于确定所述服务器应用程序是否能够处理由所述客户端应用程序指定的服务。
29.根据权利要求17所述的系统，其中，所述服务器应用程序适于指定至少一个服务，所述客户端应用程序适于确定由所述服务器应用程序指定的至少一个服务是否与客户端应用程序服务请求一致。
全文摘要
一种在不同执行环境之间进行应用程序服务交换的方法包括从在第一执行环境中进行操作的服务器应用程序接收用于处理服务的登记信息；从在第二执行环境中进行操作的客户端应用程序接收对所述服务的请求；从所述服务器应用程序请求所述服务；响应于所述请求步骤从所述服务器应用程序接收结果；以及将所述结果传送到所述客户端应用程序。提供该摘要以符合下述的规则，该规则要求摘要能够使检索者或者其他读者快速确定该技术公开的主题。在下述的理解下提交本摘要本摘要不用于解释或者限制权利要求书的范围或含义。
文档编号G06F9/46GK1898645SQ200480038443
公开日2007年1月17日 申请日期2004年12月20日 优先权日2003年12月22日
发明者比约恩·比亚勒, 约纳斯·汉松 申请人:Lm爱立信电话有限公司