用于向远程客户机虚拟传送软件应用程序的方法和系统的制作方法

文档序号:6593964阅读:243来源:国知局
专利名称:用于向远程客户机虚拟传送软件应用程序的方法和系统的制作方法
技术领域
本发明涉及一种用于向远程客户机虚拟传送软件应用程序的方法和系统。
背景技术
自计算机出现以来,涌现出了多种操作系统(OS,operating system),其中的 Linux/Unix.ffindows和MacOs是当今的主流系统。只不过能想到的是,对于一个特定的用 户应用程序来说,最有效的软件将是这些OS之一的特权。因此,对于广泛的应用程序范围, 以及为了提供可用的最优软件工具,人们需要获得并维护广泛的操作系统范围。此外,为了 满足用户日益提高的需求,一些应用程序需要比传统的台式计算机上可用的资源更多的资 源,这需要集成多处理器和硬件专用组件。后两点已经给用户和IT人员带来了阻力。对此存在很多原因专用硬件组件昂贵 且通常需要特定的编程技能,在多计算机环境上开发是一项挑战性的任务,并且维护多OS 涉及关于每个OS改变和安全问题的最新知识。多年来,已经出现了不同的解决方案,向用户和IT人员提供了改进的硬件基础结 构和计算机网络体系结构。然而,仍然存在一些主要的限制。应用于医学影像网络的所谓的胖客户机策略意味着与生成影像(例如图像绘制) 相关联的每个计算密集型任务要在从数据服务器(通常是医院PACQ获得的数据的本地存 储拷贝上本地执行。关于这种方法存在两个主要的缺点(1)必须在绘制执行之前传送数据,以及(2) 客户机计算机必须具有足够的处理能力来处理期望的数据。从而,用户必须适应其关于病 号数据何时在本地可用的工作流程,以及同一用户必须确保在那个时间具有到适当的计算 机的接入,以查看下载的病号数据。这部分解释了为何当在同一时间多位放射科医生希望 查看病历时影像室超负荷的原因。同样,由于消耗时间和带宽,因此也不推荐任意病号数据 的按需下载。可以认为所谓的瘦客户机方案为与胖客户机方法相反的策略。瘦客户机体系结构 包括服务器计算机以及连接到包含该服务器计算机的网络的多个瘦客户机计算机。服务器 包括或被连接到图像数据存储器(例如,医学图像数据存储器),并且集成期望的软件应用 程序和处理能力。为了本质上有益于服务器计算机在提取医学图像并进一步处理这些医学 图像方面的能力,瘦客户计算机经由网络请求特定软件应用程序的远程控制。虽然计算负 载在服务器位置上被执行,但是计算负载在瘦客户机位置上被可视化和交互。虽然瘦客户机网络可以负载很重(低带宽网络,同时连接很多瘦客户机),但是仍 可以在每个期望的瘦客户机位置上传送任意应用程序。因此,由于当服务器没有过载时,任意瘦客户机有可能在任意地方工作,因此通过瘦客户机方案显著改善了用户的工作流程。尽管其概念简单,但是瘦客户机技术具有很多试图或多或少有效负载服务器侧、 客户机侧和有效网络带宽的变形。此外,为了独立于客户机的硬件和软件体系结构并且独 立于要通过网络传送的应用程序,为了有效防止在客户机侧执行任意计算密集型任务,提 出了不同方案。用于图像绘制的介于“纯”胖客户机和“纯”瘦客户机网络体系结构之间的方法提 出了在服务器和客户机之间分割绘制任务的体系结构。这意味着为了绘制合成数据、表示 3D几何模型,其中背景和前景对象可以并必须在任意绘制之前被识别,以及其中前景对象 在客户机侧被绘制、背景对象在服务器端被绘制。然后,在客户机侧向用户显示两种绘制的 合成。这种方法是为涉及集成多个不同的几何对象的合成图像的应用程序(诸如计算机辅 助设计应用程序或计算机游戏)特别设计的。这种技术的两个限制是1)为了应用提出的 方案,从服务器传送到客户机的应用程序必须是先验已知的,即,这种策略必须直接集成到 被传送的应用程序源代码内,以捕获前景和背景对象(不适用于任意期望的随机应用),以 及2)这种方法不适用于不适用分解成前景/背景和/或不同几何对象的情况,例如在其中 合成数据由表示连续并不可辨的人体部分的体素组成的医学影像中。另一瘦客户机解决方案是向其传送应用程序的客户机必须提供合适的用户接口 以使用传送的应用程序。这意味着客户机先验知道可以被传送的应用程序的类型,并且意 味着客户机拥有期望的应用程序将需要的合适类型的接口。作为后备机制,提出的方法可 以经由基于Java的模块通过网页浏览器传送这样的特定用户接口。在很多情况下缺少这 样的要求,尤其是当考虑到例如在医院机构中最重要的网络和计算机安全问题时。这种技术的两个主要限制是1)为了应用提出的方案,从服务器传送到客户机的 应用程序必须是先验已知的,即,为了应用期望的缓冲策略,这种多节点分布结构必须直接 集成到被传送的应用程序源代码内(不适用于任意期望的随机应用),以及幻这种方法不 适用于客户机不具有期望传送的应用程序所需要的先验设置的用户接口的情况和/或客 户机具有严格的或没有启用的Java的因特网浏览器的情况(例如,不适用于如医院和银行 的安全基础结构内)。另一解决方案是一种用于基于网页传送视频流的方法,其中服务器必须特别适用 于应用程序传送过程。这种技术的三个限制是1)为了应用提出的方案,从服务器传送到客户机的应用 程序必须是先验已知的,2)这种方法不适用于客户机不具有期望传送的应用程序所需要的 先验设置的用户接口的情况和/或客户机具有严格的或没有启用的Java的因特网浏览器 的情况(例如,不适用于如医院和银行的安全基础结构内),以及3)在多个/协同流过程 (不适用于多客户机需要在唯一的流上交互的协同策略)的情况下,这种策略不提供保证 数据完整性的任何信息和/或实施例。对于单个或协同策略,一种可选的策略集中在医学数据可视化上。当考虑到在这些文件中所阐述该策略时,有两个主要限制1)客户机必须具有本 地安装的对应于传送的应用程序并集成传送的应用程序绘制特征的用户接口,即,如果的 传送的应用程序在医学数据体绘制方面的能力是未知的以及在库方面物理上不可访问,则 该应用程序不可传送(不适用于任意期望的随机应用程序),以及幻根据以下方案并考虑到其中多个用户正在同一传送的应用程序上同时工作的协同策略,每个客户机侧的每个用 户接口被物理上相互解除链接,并且一旦一个客户机已经执行一个操作并向其他客户机传 输其参数(没有实时协同工作),则必须更新每个用户接口。用于体绘制应用程序传送的策略提出了将体绘制引擎与视频流引擎接合以进一 步将生成的视频流传送到位于远程的客户机。这样的策略的两个限制是1)为了将这种体绘制引擎与视频流引擎接合,需要部 分或完整访问集成体绘制引擎的期望的应用程序的源代码(不适用于任意随机期望的应 用程序),以及幻在对传送到多个客户机的唯一应用程序多个协同工作的情况下,提不出 办法来维持应用程序数据完整性(不适用于在传送的应用程序上的实时协同工作)。上述限制的试验性解决方案依赖于基于其内容的视频信息的压缩。在医学影像中 不能满足这样的先验,例如,为了观察单个细胞,合成图像的内容可能与具有每个器官的整 个人体一样宽的情况。此外,在随机和/或未知内容的情况下不满足这种先验(不适用于 任意随机期望的应用程序)。没有方案来将未知应用程序从服务器传送到至少一个客户机(无需关于服务器 侧的应用程序的信息、在服务器侧上的应用程序源代码内没有侵入/修改、操作系统独立 方案),无需关于客户机侧的该应用程序的任意先验信息(在客户机侧无需图形用户界面 来与传送的应用程序交互),以及无缝地允许具有相同传送的应用程序的多个客户机协同 和同时工作(维护传送的应用程序数据的完整性、实时协同工作)。因此,需要一种克服本文中以上所述的缺点和不足的方法和装置。

发明内容
根据本发明,提供了一种用于虚拟传送软件应用程序的系统,包括电信网络;至少一个系统服务器;至少一个客户机设备,通过电信网络通信接合到至少一个系统服务器,该至少一 个客户机设备使用户能够向系统服务器请求软件应用程序;以及至少一个应用程序服务器,与至少一个系统服务器关联,该至少一个应用程 序服务器如此被配置从而执行请求的软件应用程序;其中,该系统服务器被如此配置从而生成至少封装应用程序服务器执行的软件应 用程序的图形用户界面超媒体流,并且将超媒体流传送到至少一个客户机设备;以及其中,至少一个客户机设备被如此配置从而显示超媒体流内容,以及允许用 户将交互信息传输到所述至少一个应用程序服务器以被提供给执行的软件应用程序。根据本发明,还提供了一种将软件应用程序从具有复合窗口管理器的应用程序服 务器虚拟传送到通过电信网络通信接合到应用程序服务器的至少一个客户机设备的方法, 包括将来自复合窗口管理器的执行的软件应用程序的图形用户界面内容存储到存储 缓冲器中;访问存储缓冲器;生成至少封装存储缓冲器的图形用户界面内容的超媒体流;
7
以及将超媒体流传送到至少一个客户机设备。在参照附图阅读只通过实施例的方式给出的本发明的示例性实施方式的以下非 限制性的描述之后,本发明的以上和其他目的、优点和特征将变得更加明显。


在附图中图1是根据本发明示例性实施方式的远程应用系统的框图;图2是人性化接口设备(HID)向系统服务器请求软件应用程序的过程的示例性实 施例的流程图;以及图3是HID与软件应用程序交互的过程的示例性实施例的流程图。
具体实施例方式通常而言,本发明的示例性实施例是关于一种用于通过计算机网络从系统服务器 向至少一个远程人性化接口设备(HID) (S卩,客户机设备)虚拟传送软件应用程序的方法和 系统。应用程序在系统服务器上被物理处理而被虚拟传送到至少一个HID。这就允许HID 从来自每个操作系统(OS)的每个软件应用程序以及位于服务器系统(诸如专用硬件组件 和多计算机处理单元)的任意处理能力受益。这样的方法和系统包括将服务器系统软件应 用程序和应用程序环境封装在超媒体流(HMQ中的过程,所述HMS在封装的和传送的软件 应用程序上提供无缝交互。参照图1,示出了虚拟软件应用程序传送系统100的示例性实施例,虚拟软件应用 程序传送系统100包括通过明确的或加密的协议(诸如UDP、TCP/IP、SSL或SSH等)经由 电信网络20(诸如例如以太网或千兆以太网、无线WiFi、有线因特网、卫星连接、蓝牙等)通 信接合到服务器系统30和40、以及可选代理服务器50的人性化接口设备(HID) 10a、10b、 IOcUOd和10e。每个服务器系统30和40包括关联的应用程序服务器32a、32b、32c和42 以及数据服务器33a、33b、33c和43。应指出的是,用于系统服务器30、40和HID 10之间的通信的网络20的通信协议 有利地独立于Os、软件应用程序和/或在系统服务器30、40和HID 10上运行的功能操作。HID 10a、10b、10c、IOd和IOe是能够接收来自网络20的数据、显示数据并接收用 户的输入命令还通过网络20发送这样的命令的最小的客户机设备。用户可以借助于HID 10a、10b、10c、IOd和IOe通过至少一个HSM访问至少一个服务器系统30或40上的至少一 个软件应用程序并与至少一个服务器系统30或40上的至少一个软件应用程序远程交互, 该HSM捕获任意软件应用程序图形用户接口(GUI)、封装捕获的数据并将其传送到访问软 件应用程序的HID 10a、10b、10c、IOd和10e。将进一步详细说明HMS编码器/解码器生成 的HMS。因此,每个HID 10a、10b、10c、10d和IOe包括网络接口连接、网络数据传输和接收 以及数据显示所需要的电子装置。因此,HID 10a、10b、10c、10d和IOe可以采用多种形式, 诸如例如计算机终端IOa和10b、具有关联的打印机11的个人计算机10c、膝上型计算机 10d、个人数字助理10e、或者任意其他这样的计算设备。为清楚起见,自此HID IOaUOb, IOcUOd和IOe将被统称为HID 10。HID 10包括对从系统服务器30、40发送的HMS进行解码并且与封装在HMS内的软件应用程序虚拟交互的最小客户机应用程序,任何虚拟交互被流动回物理上和本地执行 期望的客户机交互的系统服务器30、40。这样的最小客户机应用程序是独立的应用程序或 者是因特网浏览器插件,是跨平台的轻型软件,解码HMS并提供与HMS内的封装的软件应用 程序的交互,而无需关于流动的软件应用程序需要的先验知识。与现有技术相反,这样的最 小客户机应用程序不必是任何类型的⑶I。HID 10可以包括例如视频解码器、收发器、处理 器、视频显示桥、音频桥和外围桥。对于给定的软件应用程序,需要的GUI被封装在HMS内。此外,在同时查看由网络 20互连的多个HID 10上的一些处理数据的时候,由于HID 10的交互将在共享该软件应用 程序的任意其他HID 10的显示上具有同时和直接的操作,每个HID 10可以在同一⑶I上 仅以很少的延迟时间进行交互(延迟时间可以随网络20和子网络带宽而不同)。这是因为 实际上多个HID 10可以同时与在系统服务器30、40中的一个上运行的唯一的软件应用程 序交互,并且没有关于该软件应用程序的其他处理任务被发送到任意HID 10。服务器系统30、40可以包括呈并行和/或分布式中央处理单元(CPU)和/或计 算机、硬件和软件加速器、控制器和多种即插即用组件以及具有最小计算功能的任意其他 设备形式的多个32a、32b和32c或者单个42应用程序服务器。每个应用程序服务器32a、 32b、32c和42可以向一个或多个HID 10提供一个或多个软件应用程序。因此,软件应用程 序可以被多个HID 10所共享,使得每个HID 10具有与该软件应用程序交互的机会。因此,服务器系统30、40通过其关联的数据服务器33a、33b、33c和43和应用程序 服务器32a、32b、32c和42提供数据和计算功能。在HID 10上,删除除了生成到用户的输 出(例如,显示、语音等)、执行来自用户的输入(例如,鼠标、键盘、小键盘等)或用户交互 的其他外围设备(例如,扫描仪、照相机、可移动存储器等)之外的所有功能。所有计算都 由服务器系统30、40完成,并且该计算独立于生成数据的目的完成。来自外部源(诸如因 特网、万维网)或其他远程服务器(例如,医院中的PACS服务器)的数据也可以由系统服 务器30、40提供。这允许HID 10受益于服务器系统30、40的处理能力(例如,专用硬件组 件、CPU、计算机等)。由于用户与在应用程序服务器32a、32b、32c或42中的一个上执行的软件应用程 序远程交互意味着数据物理上保存在关联的系统服务器30或40上,因此这提供了敏感数 据的改进的安全性。此外,也避免了在每个HID 10 (即,桌上型/膝上型计算机)上安装敏 感软件的多个拷贝。这还允许HID 10使用软件应用程序,而不管其OS和硬件/处理能力。因此,不论 其OS、位置和硬件组件,任意HID 10都可以访问关于用户需要的最有效的软件和硬件。这 降低了通常关于在计算机网络中的多个OS和/或多个计算机上多个软件应用程序的传送 和集成的成本和风险。因此,新的软件应用程序的集成简单地需要在系统服务器30和/或40中的一个 上利用任意需要的硬件安装新的软件应用程序,便立即允许远程访问而无需重新编译和/ 或重新链接HID 10上的任意应用程序。如上所述,HMS是HID 10通过其访问服务器系统30和40上的软件应用程序并与 软件应用程序交互的装置,其将软件应用程序“虚拟传送”到HID 10。HMS由封装软件应用 程序和应用程序环境的HMS编码器/解码器生成,提供了封装的和传送的软件应用程序上的无缝交互。生成HMS,从而相关项的信息被关联起来并且可以被一起显示,包括任意组的多媒 体对象中的链接,包括但不限于声音(例如,语音命令等);视频(例如,电影、视频流、视频 会议等);虚拟现实;文本/超文本(例如,Word文件、HTML文件、XML文件等)。HMS编码器/解码器包括三个主要组件,一个名为HMS发生器的可选组件、HMS交 互管理器和可选代理管理器。HMS发牛器第一组件,通常集成在系统服务器30、40上的HMS发生器将软件应用程序⑶I绘 制窗口或者合成窗口管理器(CWM)提供的任何子窗口封装到视频流中。CWM可以纯粹基于软件或者完全集成到图形卡中(即,通过图形卡GPU和嵌入式 图形存储卡)。后者通过像NVidia的CUDA技术可以实现。纯粹基于软件的CWM的性能依 赖于本地CPU能力,而集成到图形卡中的CWM的性能将计算负载的部分从CPU移动到GPU, 从而释放了 CPU。要理解的是,CWM和HMS发生器两者可以都被集成在图形卡(分别诸如 Linux OpenGL CWM EComorph 和 Elemental ^Technologies 的视频解码器)上,得益于快速 存储器访问以及速度上的极大增益。还要理解的是,还可以使用混合两种方法的混合策略。HMS发生器可以包括可以适合于根据当前可用网络20和/或HID 10容量和/或 其他标准(诸如例如期望的无损量或图像分辨率)动态压缩视频信息的视频编码器。此外, 视频编码器可以从多个无损或有损压缩算法(诸如例如MPEG1-2-4或H. 264等)中进行动 态选择。然后,HMS发生器将HSM传送到HID 10。视频流可以被优化为传送适合于HID 10中的视频解码器而不是适合于屏幕显示 的格式的图像数据。例如,帧可以按组而不是按扫描线绘制,或者可以使用如同电视只对每 隔一行的颜色分量进行采样的格式。图形生成和视频编码之间的接合通常降低了硬件带宽 和复杂性。在可选的实施例中,HMS可以包含集成有与HMS视频流中封装的软件应用程序的 功能交互所需要的工具/操作按钮(例如以菜单选项的形式)中的所有或一些的特定对 象,从而防止了 HID 10改变以及使其图形用户界面适应与软件应用程序交互。菜单选项可 以根据来自HID 10的客户机命令在开和关上切换。HMS可以使消息或菜单选项能够嵌入为 非侵入式从而使在HID 10的屏幕显示器上正在查看的主要图像不模糊并提供了必要的信 息和功能。这样的嵌入式菜单选项还可以提供邀请其他参与者协同会话并处理任何进一步 的协同操作(诸如例如允许对HMS交互进行锁定和解锁或者在嵌入到单个HMS内的多个视 频流层之间切换的交互专用权)的能力。要理解的是,在可选的实施方式中,HMS发生器可以生成视频流、音频流、静态图像 数据、对应于交互信息或外围桥(以下将详细描述)的数据包、或者其组合。HMS交互管理器第三组件,通常集成在HID 10和系统服务器30、40两者上的HMS交互管理器使用 传送的虚拟软件应用程序处理远程HID 10交互。此外,HMS交互管理器处理来自HID 10支 持的外围设备(USB、打印机11等)的信息,从而可以从系统服务器30、40上执行的软件应 用程序虚拟访问(即,通过其关联的应用程序服务器32a、32b、32c或4 它们。此外,影响 位于HID 10上的用于HMS解码的任何硬件/软件是该组件的作用。在可选的实施方式中,针对在系统服务器30、40上执行的软件应用程序(即,通过其关联的应用程序服务器32a、 32b,32c或42),HID 10上的HMS交互管理器可以生成封装允许访问HID 10支持的外围设 备的至少一个外围桥的HMS。要理解的是可以用不具有解压缩视频流能力的HID 10使用HMS,在这种情况下, HMS发生器将检测这种情况并且生成具有未压缩的视频流的HMS。代理管理器可选的第四组件,通常集成在可选代理服务器50上的代理管理器与多种HID 10 和系统服务器40、50进行通信,以将来自HID 10的请求指向合适的系统服务器40、50和/ 或应用程序服务器32a、32b、32c和42、管理访问权、管理多种系统服务器40、50和/或应用 程序服务器32a、32b、32c和42等上的负载。要理解的是为了改进性能,HMS编码器/解码器中的一些或全部可以被集成在不 同的CPU和/或计算机(例如专用CPU或计算机)上。在本发明的示例性实施方式中,HMS编码器/解码器将集成视频流的HMS从系统 服务器30、40传送到HID 10,将集成合并到HID 10状态数据流的用户的交互的HMS从HID 10传送到系统服务器30、40。支持HID 10所请求的软件应用程序的系统服务器30、40使用与该软件应用程序 相关联的动态对象通过关联的应用程序服务器32a、32b、32c或42本地运行软件应用程 序,或者在动态对象已经并连续存在于系统服务器30、40存储器的同时本地运行软件应用 程序以进一步地监视每个OS事件和命令。这样的关联的目的是使动态对象位于存储缓冲 器中,可能在图形硬件组件中或者在系统服务器30、40(或者其相关联的应用程序服务器 32a.32b.32c或42中的一个)的物理RAM中,其监控与特定软件应用程序相关联的绘制视 口和/或GUI,以及监控的软件应用程序开始的绘制视口和/或GUI每个进一步实例。例 如,这可以通过捕获OS命令和事件实现。实际上,这对应于CWM管理远程操作系统上的多 个远程窗口管理器。与特定软件应用程序相关联的动态对象指向或捕获的存储缓冲器被进一步重新 指向提取软件应用程序GUI或与该软件应用程序相关联的任何其他绘制窗口的HMS编码器 /解码器的HMS发生器组件,并且进一步将其发送到生成包含特定应用程序绘制视口的视 频流的视频编码器。然后,生成的视频流被封装并且从系统服务器30、40发送到HID 10。每个新的存储缓冲器和/或由与特定软件应用程序相关联的动态对象指定或捕 获并且由集成在现有的HMS内的已经运行的软件应用程序示例的重新分配的存储缓冲器, 作为相对于属于示例新的绘制视口的软件应用程序的已经存在的视频流的附加视频流层 被编码。在后者情况中,最终的HMS将包含与初始软件应用程序示例的视口数目相同的视 频流层数。与特定软件应用程序相关联并且指向或捕获存储缓冲器的动态对象表示存储缓 冲器是否已经被更新。在存储缓冲器尚未改变的情况下,视频编码器可以编码NULL流, 从而避免任何进一步的带宽浪费,或者编码高分辨率视频流以从未更新的时间获益来改进 HMS质量(以及从而改善HID 10位置上的用户的体验)。在存储缓冲器已经更新的情况 下,视频编码器将根据HID 10的特性编码新的视频帧,只传输存储缓冲器的更新的部分或 者重新传输整个的存储缓冲器。
然后,生成的HMS被中继转发到系统服务器30、40上的收发器,其根据中央/分布 式网络体系结构直接或者通过可选代理服务器50将HMS传输到HID 10。HID 10使用HMS 编码器/解码器的HMS交互管理器组件在HID 10上本地提供的合适的解码器或者系统服 务器30、40发送的合适的解码器解码HMS。应指出的是,为了解码HMS不需要关于HMS内容 的先验信息,并且不需要关于传送的软件应用程序类型的先验信息。对于HID 10, HMS交互管理器向服务器系统30、40传送关于交互的信息,该交互将 在链接到HID 10的和/或包含于由连接到HID 10的系统服务器30、40传送的HMS中的特 定软件应用程序上执行。HID 10传输的指令信息包括诸如鼠标、键盘、声音和操纵杆交互等 (例如,诸如移动、点击和诸如拖动释放的改进移动的简单移动)的用户输入、HID 10显示 分辨率、HID 10收发器组件速度(例如吉比特、无线带宽)以及HIDlO类型(例如,膝上型 电脑、移动设备、小型电话)等。这种指令信息被接收,并通过系统服务器30、40上的交互 管理器,该交互管理器在包含和/或链接到发送的HMS的软件应用程序上本地执行期望的 用户交互,然后更新HMS参数以生成HID 10类型匹配的新的HMS。盤当在协同模式下,来自任意协同HID 10中的任意一个的交互被其他协同HID 10 查看,不论每个HID 10通过发送交互参与协同工作还是简单地作为查看者。这可以通过允许对HMS内的数据或者链接到HMS的数据具有操作权限的多个HID 10同时向同一本地存储缓冲器或者在不同有利的网络位置上的这种特定存储缓冲器的准 确伪实时或实时复制访问同一HMS来实现。复制的这些有利的网络位置可以基于与HID 10 的网络位置和/或HIDlO连接的网络内的专门设计的一些高带宽区域相关的网络带宽和负 载均衡来确定。因此,无论是来自物理上不同的HID 10还是在一个或多个多输入多触摸设 备和/或应用程序上,多个HID 10可以同时交互以提供协同交互。为了提供对软件应用程序的协调访问,一个HID 10锁定HMS交互由HMS存储缓冲 器内的或者链接到HMS存储缓冲器的数据独占交互使用的一段时间。这种锁定是允许多个 HID 10同时访问同一存储缓冲器的计算机策略。当一个HID 10获得到执行的软件应用程 序的访问时,其锁定到执行的软件应用程序的访问,迫使他人等待直至其完成交互并对其 解锁。因此,多个HID 10可以访问同一 HMS和/或存储缓冲器并且在同一 HMS和/或存储 缓冲器上操作,而不会破坏HMS链接的和/或HMS内的数据,以用于希望访问该同一 HMS和 /或存储缓冲器的其它HID 10。这种锁定策略只应用于软件应用程序交互,在软件应用程 序交互期间,同时连接到HMS的所有HID 10可以实时看到锁定的HID 10的交互过程、请求 实时交互,或者使用音频HMS以进一步在看到的特权交互上(即,锁定的HID 10的交互) 注释。此外,单个系统服务器30、40可以将多个HMS传送到一个或多个HID 10,同时保留 链接到生成的HMS中的每一个的和/或HMS中的每一个中包含的数据的完整性。软件应用程序的请求参照图2,示出了 HID 10向系统服务器30、40请求软件应用程序的过程200的示 例性实施例的流程图。过程200的步骤用块202至214来表示。过程200开始于块202,在块202中,HID 10直接向系统服务器30、40或者通过可 选代理服务器50向系统服务器30、40请求特定软件应用程序。
12
在块204,请求的软件应用程序开始于在适当的应用程序服务器32a、32b、32c或 42。在块206,软件应用程序⑶I内容指向CWM。CWM是绘制窗口和/或其边界的计算 机绘制环境系统的组件。合成窗口管理器与标准窗口管理器之间的主要差别是取代了将 软件应用程序GUI从图形输出存储器输出到公共屏幕,每个软件应用程序的软件应用程序 GUI首先被存储到单独的、独立的存储缓冲器中,或者计算机内的临时位置,在该处它们可 以在显示之前被处理。然后,在块208,CWM在存储缓冲器中存储软件应用程序⑶I内容,在块210,通知 HMS发生器新的软件应用程序GUI已经存储在存储缓冲器中。在块212,HMS发生器访问存储缓冲器中的软件应用程序⑶I内容并且生成HMS,例 如视频流。要指出的是,由于HMS发生器访问的是软件应用程序GUI内容,所以任何2D和 /或3D过程已经根据软件应用程序的需要执行了,或者改变图形卡GPU、一个或多个GPU或 者任何其他可用的硬件组件。因此,HMS发生器对于软件应用程序执行是透明的。还要指出的是,由于在最终桌面环境的合成进一步发送到用于桌面显示的图形输 出存储器之前,HMS发生器直接从存储缓冲器访问软件应用程序GUI内容,因此不需要特定 驱动器。确实,由于所有的软件应用程序在被合成之前绘制到屏幕外的存储缓冲器,因此, 可以从存储缓冲器访问它们并且将它们进一步嵌入在其他应用程序中,例如HMS。直接从存储缓冲器访问软件应用程序GUI内容具有很多优点。第一优点是,由于 屏幕外缓冲器不断被软件应用程序更新,因此嵌入的绘制将是软件应用程序GUI的动态表 示而不是静态绘制。另一优点是,当多个HID 10被从系统服务器30、40存储缓冲器拉动时, 多个HID 10可以在多个或同一软件应用程序上交互,同时一切都在系统服务器30、40上正 常处理,而无需修改要形成流的任意软件应用程序,不需要在客户端施加3D操作。最后,在块214,将HMS传送到发起请求的HID 10。要理解的是,HID 10可以请求已经被另一 HID 10请求的软件应用程序,在这种情 况下,根据新发起请求的HID 10的权限和/或允许,将HMS用于协同模式。软件应用程序的交互参照图3,示出了 HID 10与软件应用程序交互的过程300的示例性实施例的流程 图。过程300的步骤由块302至312表示。过程300开始于块302,在块302中,发起请求的HID 10接收HMS。在块304,HID 10将交互请求发送到适当的应用程序服务器32a、32b、32c或42。 通过在显示的HMS内容上记录来自键盘、鼠标点击、移动等以及它们的协调配合的密钥序 列、并将其传送到适当的应用程序服务器32a、32b、32c或42来完成这一步。在块306,适当的应用程序服务器32a、32b、32c或42接收提供到HMS交互管理器 的交互请求。然后,在块308,在存储缓冲器中的软件应用程序GUI上执行交互请求。在块310,HMS发生器访问存储缓冲器中的软件应用程序⑶I并且生成HMS。最后,在块312,将HMS传送到交互的HID 10。然后,过程300返回到块302。要理解的是,多个HID 10可以协同并共享公共的软件应用程序,在这种情况下,交互的HID 10将HMS交互锁定HMS存储缓冲器内或者链接到HMS存储缓冲器的数据的独 占交互使用时间,之后,HMS被传送到协同HID 10中的每一个。中央分配策略可选地,HMS可以通过中央分配体系结构分配。在这种策略中,每个现有的HMS被 路由到网络(诸如例如专用系统服务器30、40或者代理服务器50)内的中心位置。然后, 从该特定的位置,每个HID 10可以通过HMS请求访问一个或多个软件应用程序。在以下位 置可以完成HMS的生成⑴在中心位置本身,即,在中心系统服务器30或40或者代理服 务器50上,或者(2)在独立生成HMS并进一步通过网络20将其提供到中心位置的一个或 多个远程系统服务器(未示出)上。前一个策略⑴在生成HMS所需的对象和处理能力可以由中央系统服务器30或 40或者代理服务器50本身处理的情况下,可以大大降低生成并发送HMS所需要的成本和网 络负载。此外,这种策略允许通过传送一个或多个HMS将特定功能传送到HID 10的专用的 和独立的设备的设计。后一个策略( 允许中心位置集中管理HID 10访问权并确定可以改进到HID 10 的HMS的传送的一组参数,诸如例如基于网络20负载权衡确定HMS压缩比例。此外,这种策 略允许要集成在生成HMS的远程系统服务器(未示出)上以及根据要通过HMS传送到HID 10的对象和功能的要求的硬件专用组件的确定。通过使用网络20上的多个设备的分布式 能力扩展了本地系统服务器30、40的能力使之超出了单个设备的能力。外围桥可以使用一个或多个远程HMS功能以创建允许完整功能的虚拟文件系统实现的 外围桥。这可以实现,从而不需要软件的补丁和/或其他软件被重新编译和/或重新链接。 这可以通过将涉及客户机本地文件系统的虚拟文件系统从HID 10传送到传送期望的软件 应用程序/功能的系统服务器30、40来实现。与必需保存数据到存储设备或者从存储设备检索数据的传统的文件系统不同,虚 拟文件系统实际上不存储数据本身。它们用作现有文件系统或者存储设备的视图或转换。 理论上,任何可用资源可以被输出到HMS服务器作为文件系统。此外,这种虚拟文件系统的 输出可以通过防止任何其外部方具有到该客户机环境的访问的加密流来实现。这允许任何系统服务器30、40传送可以打开/保存/更新任意HID 10本地和远 程文件/外设以及每个系统服务器30、40本地和/或远程文件/外设的软件应用程序和/ 或功能。这种能力对于使用Linux OS的计算机的例如X代理和GLX分支技术是极其有益 的。在多维成像设备(MDID)环境中软件应用程序传送系统的使用虚拟软件应用程序传送系统100可以有利地应用于医学影像,尤其是应用于网络 环境中的医学图像的处理,以及医学数据可视化、医学数据绘制和医学计算机辅助诊断等。计算机网络和更具体的医院基础设施允许医学数据、医学设备以及每个医学计算 应用程序在具有合适权限的每个用户之间共享。与硬拷贝(胶片、⑶、纸张和其他硬介质) 的传统数据管理相反,计算机网络通过图像存档及通信系统(PACQ允许大多数数据和计 算机资源的集中,提高了医院员工(临床医生、内科医生、放射线医生、远距射线医生、护士 等)间的合作水平。这显著降低了存储任何病号数据所需的空间量并提高了每个医院员工的工作流程。集成一个或多个多维数据处理服务器的MDID包括不同的软件应用程序,诸如网 络环境内并且无论是偶尔还是永久都适合于在图像获取设备(诸如例如CT扫描仪或PACS 服务器)附近的例如计算机辅助诊断软件(CAD)、数据绘制软件、数据处理软件。虚拟软件应用程序传送系统100允许一个或多个HID 10上的用户(例如健康护 理提供者)远程可视化、绘制、研究并诊断集成MDID的系统服务器30、40上的病号数据, MDID可以位于医院机构和基础设施的内部或者外部。无论是通过数字和/或算术确定需要 的处理技术参数自动使用一些默认参数,还是使用永久或准时链接到MDID的至少一个HID 10指定的一些处理技术参数,MDID (例如系统服务器30、40)从数据服务器33a、33b、33c和 43 (例如PACS服务器)获取图像,该图像然后被MDID处理。然后,任何进一步的处理结果 (无论是2D、3D还是在η维图像处理服务器上构建的n-D绘制体图像)以及任何CAD算法 (例如图像、容量、数字诊断等)的任意其他处理结果进一步传送和显示到一个或多个HID 10上。要处理的病号数据可以是包含单个病号图像数据集的单个数据集或者多个病号 的多个数据集。无论要调查的数据集是否包含多个程序,MDID可以自动处理病号数据集并 为每个数据集执行自动计算机辅助诊断。此外,HID 10上的用户可以与来自其他HID 10的链接到MDID的多个用户共享其 MDID的使用和处理结果。例如,对于放射科医生在各自的HID 10上同时观察正在构建的或在MDID上的CAD 处理过程中数字处理的三维图像是可能的。这通过促进多个拍摄射线照片的医生之间的相 互理解改进了关于医生的理解。与拍摄射线照片的医生构建的三维图像经由胶片等发送到 任意请求的部门的任何其他拍摄射线照片的医生的情况相比较,这是行得通的。由于数据集在MDID上初始处理,因此其可以通过HMS快速传送到连接的HID 10。 在使处理数据传送到HID 10之外,发起请求的HID 10还可以与软件应用程序处理内容交 互以修改任何处理技术参数。此外,具有足够权限的任意其他同时连接的HID 10还可以与 处理的数据交互。要理解的是还可以与MDID并行地请求其他的软件应用程序。这提供了非常高的成本效益,还提供了保护数据和管理数据的普遍存在的可用的 解决方案,并且显著放宽了网络和用户本地计算机的要求。此外,虚拟软件应用程序传送系 统100可以用作企业范围图像存档及通信系统(PACQ并且可以容易地与其他PACS和图像 分布系统集成。其他应用虚拟软件应用程序传送系统100确定适用于多种其他领域,诸如数据绘制、可视 化和科学处理、远距透视检查、防御、计算机辅助设计、有限元分析和仿真、天气预报和地球 科学成像、网络游戏、娱乐成像和电影院、电信、医疗成像、生命科学和生物科学影像、航空 航天和望远镜成像、航空控制和成像、财务和会计、文本编辑等。这本质上涉及虚拟软件应用程序传送系统100允许从服务器(例如,系统服务器 30,40)到客户机(例如,HID 10)的任意软件应用程序的传送,以进一步允许客户机在这样 的传送的软件应用程序上交互而保留服务器端的计算任务(不管客户机硬件和软件能力)的事实。通过允许跨操作系统部署而不考虑客户机设备硬件限制为应用程序开发者提供 了便利,通过最小化维护成本为IT员工提供了便利,以及通过阻止任意职员的桌上型电脑 和/或膝上型电脑的任意硬软件安装为公司提供了便利。要理解的是,虚拟软件应用程序传送系统100可以以硬件、软件或者硬件和软件 的组合实现。还可以在至少一个计算机系统中以集中方式或在不同元件遍布多个互连计算 机系统的情况下以分布式方式来实现。任意类型的计算机系统或适用于执行本文中所述的 方法和过程的其他装置都是合适的。硬件和软件的典型组合可以是具有计算机程序的通用 计算机系统,当计算机程序被加载并执行时,控制计算机系统以使其执行本文中所述的方 法和过程。还应理解的是,本发明不限于附图中所示的和上文所描述的配置的细节。本发明 允许其他的实施例以及允许被以多种方式实践。还应理解的是,本文中使用的用语和术语 是用于说明而不是限制的目的。因此,尽管已经通过本发明的示例性实施例描述了本发明, 然而在不背离本发明的精神的前提下可以考虑多种修改和应用。
权利要求
1.一种用于虚拟传送软件应用程序的系统,包括电信网络;至少一个系统服务器;至少一个客户机设备,通过所述电信网络通信地接合到所述至少一个系统服务器,所 述至少一个客户机设备使用户能够向所述系统服务器请求软件应用程序;以及至少一个应用程序服务器,与所述至少一个系统服务器相关联,所述至少一个应用程 序服务器被配置为执行所请求的软件应用程序;其中,所述系统服务器被配置为生成至少封装了由所述应用程序服务器执行的所述软 件应用程序的图形用户界面的超媒体流,并将所述超媒体流传送到所述至少一个客户机设 备;以及其中,所述至少一个客户机设备被配置为显示所述超媒体流内容,以及允许所述用户 将交互信息传输到所述至少一个应用程序服务器从而被提供给所执行的软件应用程序。
2.根据权利要求1所述的系统,其中,所述超媒体流包括从由视频流、音频流、静态图 像数据、与交互信息相对应的数据包、外围桥及其组合组成的组中选择的流。
3.根据权利要求1所述的系统,其中,所述超媒体流由超媒体流编码器/解码器生成。
4.根据权利要求3所述的系统,其中,所述超媒体流编码器/解码器包括用于生成所述超媒体流的超媒体流发生器,以及与所述至少一个系统服务器相关联的 超媒体流交互管理器;以及与所述至少一个客户机设备相关联的超媒体流交互管理器。
5.根据权利要求4所述的系统,其中,所述超媒体流发生器包括适合于动态压缩视频 信息的至少一个视频编码器,其中,所述至少一个客户机设备包括至少一个相应的视频解 码器。
6.根据权利要求5所述的系统,其中,所述视频编码器适合于根据所述电信网络的当 前有效容量动态压缩视频信息。
7.根据权利要求5所述的系统,其中,所述视频编码器适合于根据所述至少一个客户 机设备的当前有效容量动态压缩视频信息。
8.根据权利要求5所述的系统,其中,所述至少一个视频编码器从由MPEGUMPEG 2、 MPEG 4和H. 264组成的组中选择。
9.根据权利要求4所述的系统,其中,所述至少一个应用程序服务器包括复合窗口管 理器,所述复合窗口管理器在存储缓冲器中存储所执行的软件应用程序的图形用户界面内 容,其中,所述超媒体流发生器访问所述存储缓冲器以创建所述超媒体流。
10.根据权利要求9所述的系统,其中,所述存储缓冲器位于从所述至少一个应用程序 服务器的RAM、所述至少一个应用程序服务器的图形硬件存储器、所述至少一个系统服务器 的RAM、所述至少一个系统服务器的图形硬件存储器及其组合中选择的存储器位置中。
11.根据权利要求9所述的系统,其中,所述复合窗口管理器是基于软件的。
12.根据权利要求9所述的系统,其中,所述复合窗口管理器集成在图形卡内。
13.根据权利要求9所述的系统,其中,所述超媒体流发生器包括视频编码器,其中,当 所述存储缓冲器未改变时所述视频编码器对NULL流进行编码。
14.根据权利要求9所述的系统,其中,所述客户机设备上的所述超媒体流交互管理器以及所述至少一个应用程序服务器上的所述超媒体流交互管理器合作,以将交互信息从所 述客户机设备支持的外围设备传输到所述至少一个应用程序服务器从而被提供给所执行 的软件应用程序。
15.根据权利要求9所述的系统,其中,针对在所述至少一个应用程序服务器上执行的 所述软件应用程序,所述客户机设备上的所述超媒体流交互管理器生成封装了允许访问所 述至少一个客户机设备支持的外围设备的至少一个外围桥的超媒体流。
16.根据权利要求14所述的系统,进一步包括至少两个客户机设备,其中,公共超媒体 流被传送到所述至少两个客户机设备,以及其中,向所执行的软件应用程序提供交互信息 被选择性地锁定由所述至少两个客户机设备中的给定一个独占交互使用的一段时间。
17.根据权利要求4所述的系统,其中,所述客户机设备上的所述超媒体流交互管理器 以及所述超媒体流交互管理器合作,以将信息从所述客户机设备支持的外围设备传输到所 述至少一个应用程序服务器,以从所述应用程序服务器可以被访问。
18.根据权利要求17所述的系统,进一步包括至少两个客户机设备,其中,公共超媒体 流被传送到所述至少两个客户机设备,以及其中,外围设备对信息的访问被限制给所述至 少两个客户机设备中的给定一个的外围设备独占交互使用一段时间。
19.根据权利要求4所述的系统,其中,所述超媒体流编码器/解码器还包括代理管理 器,所述代理管理器通过所述电信网络通信地接合到所述至少一个系统服 务器和所述至少 一个客户机设备,从而将来自所述至少一个客户机设备的请求指向所述至少一个应用程序 服务器中适当的一个。
20.根据权利要求19所述的系统,其中,所述代理管理器管理对所述至少一个应用程 序服务器的访问权。
21.根据权利要求19所述的系统,其中,所述代理管理器管理所述至少一个应用程序 服务器上的负载。
22.根据权利要求19所述的系统,其中,所述代理管理器被集成到代理服务器上。
23.根据权利要求1所述的系统,其中,所述超媒体流包含提供与所执行的软件应用程 序交互的功能的对象。
24.根据权利要求1所述的系统,其中,所述至少一个应用程序服务器中的每一个从由 计算机、CPU和GPU组成的组中选择。
25.根据权利要求1所述的系统,包括至少两个客户机设备,其中,公共超媒体流被传 送到所述至少两个客户机设备。
26.一种将软件应用程序从具有复合窗口管理器的应用程序服务器虚拟传送到通过电 信网络通信地接合到应用程序服务器的至少一个客户机设备的方法,包括将来自所述复合窗口管理器的被执行的软件应用程序的图形用户界面内容存储到存 储缓冲器中;访问所述存储缓冲器;生成至少封装了所述存储缓冲器的所述图形用户界面内容的超媒体流;以及将所述超媒体流传送到所述至少一个客户机设备。
27.根据权利要求沈所述的方法,还包括将交互信息从所述至少一个客户机设备传输到所述应用程序服务器;以及向所执行的软件应用程序提供所述交互。
28.根据权利要求27所述的方法,还包括将所述超媒体流传送到至少两个客户机设备。
29.根据权利要求观所述的方法,其中,向所执行的软件应用程序提供交互信息被选 择性地锁定由所述至少两个客户机设备中的给定一个独占交互使用的一段时间。
30.根据权利要求沈所述的方法,其中,所述超媒体流包括视频流,生成所述超媒体流 的步骤包括动态压缩视频信息,所述方法还包括对传送到所述至少一个客户机设备的所述 超媒体流进行解压缩。
31.根据权利要求沈所述的方法,还包括针对在所述至少一个应用程序服务器上执行 的所述软件应用程序,生成封装了允许访问所述至少一个客户机设备支持的外围设备的至 少一个外围桥的超媒体流。
全文摘要
本发明提供了一种用于将应用程序通过计算机网络从服务器系统传送到至少一个远程客户机设备的方法和系统。应用程序在系统服务器上被物理处理而被虚拟传送到至少一个客户机设备。这允许客户机设备从每个OS的每个应用程序以及位于服务器系统的任意处理能力(诸如专用硬件组件和多计算机处理单元)受益。这样的方法和系统包括将服务器系统软件应用程序和应用程序环境封装在超媒体流(HMS)中的过程,所述HMS在封装的和传送的软件应用程序上提供了无缝交互。
文档编号G06F9/445GK102067085SQ200980122881
公开日2011年5月18日 申请日期2009年4月17日 优先权日2008年4月17日
发明者弗洛朗·尚德利耶, 雨果·杜维尔 申请人:微系统道格有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1