CN1924803A - 处理不同模态的数据的装置和方法 - Google Patents

Abstract

在用于处理不同模态的数据的装置和方法中，应用(16)访问由运行时环境(30)在加载时相应于配置文件(32)提供的服务组件(17)。由此可以节省资源和灵活地处理不同模态的数据。

Description

处理不同模态的数据的装置和方法

技术领域

本发明涉及一种采用多个用于处理数据的资源处理不同模态的数据的装置，借助这些资源可以执行至少一个让至少一个服务组件给出服务的应用。

本发明还涉及一种用于处理不同模态的数据的方法。

背景技术

这样的装置和方法由DE19625842A1公开。和公知装置和公知方法一样，不同模态的数据来自不同的尤其是拍摄图像数据用于医疗诊断的医疗仪器。该图像数据被相应于工业标准DICOM地传输和存储。数据的处理、尤其是通过与不同模态匹配的应用来为图形用户界面准备医疗数据。在公知方法和公知装置中，这些应用为了相互之间的通信以及按照DICOM标准读取和写入数据而采用按照OCX标准构造的服务组件。这些服务组件在设计时与该应用链接。

公知装置和公知方法的缺点是对不同的应用通常必须使用不同的服务组件。此外用于服务组件的、通常作为所谓DLL存在的汇编程序在加载时必须以与实现时相同的形式出现。否则该应用就有不稳定的危险。因此通常为每个应用分别将特定于该应用的服务组件与该应用链接并与该应用一起安装。在执行该应用时分别与该应用链接的服务组件必须与该组件一起被加载到计算机的工作存储器中。此外针对该应用的每个新版本都必须安装新的服务组件。如果不这样，就可能导致该应用的不稳定。

EP1037142A2还公开了一种装置和方法，其中服务组件通过配置文件中的相应项目而被补充配置到应用中。补充配置到应用中的服务组件在加载时对应于配置文件中的项目被加载并提供给该应用。

发明内容

从该现有技术出发本发明要解决的技术问题在于提供一种装置和方法，利用它们可以节省资源和灵活地采用服务组件。

在该装置和方法中，服务组件包括包含在分离的汇编程序中的服务接口和服务实现。此外该服务实现可由运行时环境根据配置数据在加载时修改。

通过服务接口和服务实现的分离，可以将服务实现与各应用的要求相匹配。这可以在加载时通过相应的配置数据来进行。由此可以为不同的应用使用一个服务实现并仅在需要匹配时才进行匹配。另一个优点是与现有资源的适应性。所述装置和方法因此容许节省资源和灵活地运用服务组件。

在优选的实施方式中，运行时环境根据配置数据产生由应用调用的服务组件的实例，并在服务存储库中管理所产生的实例。其优点是只需要分别产生一个服务组件的一个实例，因为在后续调用时只能返回对该实例的引用。

通过配置数据不仅可以确定运行时采用的服务实现，还可以确定不同服务组件相对于应用的可见性。由此保证这些应用只能调用其有权调用的服务组件。

在另一个优选实施方式中，配置数据是特定于应用的。这使得服务实现与引起调用的应用的要求相匹配。

此外配置数据还可以是特定于传输的。由此可以向这些应用提供能为应用提供跨机器界限的服务的服务组件。

优选的，提供跨机器界限的服务的服务组件具有至少一个至远程服务组件的通信接口。

可以进行跨机器界限的通信的这种服务组件可以既具有代理功能又具有服务器功能。具有代理功能的服务组件被分配给一个本地机，而具有服务器功能的服务组件位于远程的机器上。访问具有代理功能的服务组件的应用由此以好像通过本地服务组件给出服务的方式获得该服务。

在一个特殊的实施方式中，服务组件具有一个公用的通信接口，该通信接口可以由所有具有代理功能的远程服务组件使用。这种结构使得可以对由具有代理功能的服务组件取消的查询进行集中管理。尤其是可以对处理设置优先权、集中中断该处理和重新进行该处理。

在另一个优选实施方式中，配置数据是特定于资源的。这使得可以将服务组件与执行机器的相应给定匹配。

特定于资源的配置数据优选在安装时确定。为此还可以采用路径查找程序，其在安装具有所属服务组件的应用之前确定现有的资源并相应调整配置数据。

此外服务组件优选还包括另一个包含用于匹配服务组件的接口的汇编程序。这样该匹配接口就实现了一个单独的匹配实现。该匹配实现可以通过修改对应于服务组件的配置数据来补充配置到该服务组件中。通过这种方式可以将服务组件与相应的给定和要求匹配。

可以为服务组件分配涉及由该服务组件使用的另一个服务组件的配置数据。这有利于多层中的模块化结构和通用功能的可重用性。

服务组件的内部结构优选包括调用单元、执行单元和扩展存储库，在该扩展存储库中管理由运行时环境分配的、对其它被采用的服务组件的实例的引用。

附图说明

下面的描述给出本发明的其它优点和特性，其中结合附图详细解释本发明的实施例。在附图中：

图1示出医疗数据网络的框图，该数据网络用于处理不同模态的医疗数据；

图2示出准备不同模态的数据并显示给用户的工作流程的结构；

图3示出服务组件的汇编程序的结构；

图4示出服务组件的内部结构；

图5示出管理服务组件的实例的运行时环境的结构；

图6示出可以给出跨机器界限的服务的服务组件的结构；

图7示出在机器界限之外相互作用的服务组件的另一个结构；

图8示出具有服务器功能并具有用于查询远程服务组件的统一接口的服务组件的结构；

图9示出位于一个本地机上的不同服务组件的汇编程序的结构；

图10示出分布在本地机和远程机上的不同服务组件的汇编程序的结构；

图11示出不同服务组件的汇编程序的结构，其中一个汇编程序被新版本代替；

图12示出根据完整性区分的不同服务组件的汇编程序的结构。

具体实施方式

图1示出用于处理不同模态的数据的医疗数据网络。不同模态的数据由不同的医疗仪器产生。在图1中例如示出磁共振设备2、计算机断层造影设备3和常用的X射线设备4。这些医疗仪器由可以作为工作地点计算机的控制设备5操作。控制设备5与本地数据网络6连接，可以将产生的图像数据存储在中央数据存储器7中。该中央数据存储器7例如可以配置在中央服务器10中。此外该本地数据网络6与诊断设备8、9连接，该诊断设备针对诊断目的对由医疗仪器拍摄的图像数据进行分类。

本地数据网络6还具有网络接口11，该接口借助在全球数据网络12、如因特网中配置的传输13将医疗数据传送给远程诊断设备14。该远程诊断设备14例如可以设置在诊所内，而医疗数据网络1配置在医院内。

图2示出可以由医务人员针对诊断目的调用诊断设备8或9之一的工作过程的结构。该工作过程15访问用于分别处理不同模态的数据的不同应用16。例如可以将第一应用16用于从磁共振设备2拍摄的深度图像中建立感兴趣身体区域的三维模型。按照相同的方式第二应用16可以从计算机断层造影设备3拍摄的投影图像中建立感兴趣身体区域的三维立体图像。最后第三应用16可用于观看X射线图像。

应用16访问为应用16提供通用功能的服务组件17。例如服务组件17中的一个可以具有用于存储DICOM数据的高速缓存功能。在这种缓存中临时存储从中央数据存储器7获得的数据。这样的服务组件17借助操作系统提供的功能从文件系统中读取DICOM文件，按照DICOM标准对内容进行分析和分解，然后允许对该文件的DICOM属性的随机访问。借助这样的服务组件17，应用16可以加载DICOM文件、读取和更改其内容并也作为DICOM文件存储。接着应用16可以向其它应用16传递对被加载DICOM数据的引用，该其它应用通过该引用可以访问公用的服务组件17中的相同数据。通过使用公用的服务组件17，该工作过程的效率得到了提高，而且用于执行该工作过程15的资源也得到了节省，因为DICOM文件不需要被多次调用，不需要管理被调用DICOM文件的多个拷贝。

此外如果公用的服务组件17提供其它功能则是有利的。例如应当可以校正DICOM文件中的错误。该错误校正可以由不同的触发器激活。例如可以在发现某些私有的DICOM标记时触发错误校正。为了不必对每个新校正可能都产生一个服务组件17的新版本，服务组件17可以通过配置在加载时动态扩展，下面还将对此详细解释。例如可以为服务组件17既扩展校正算法又扩展启动和选择机制，该机制识别何时需要校正和必须采用哪些校正算法。

此外，视试图通过应用16访问数据的不同人员而定，可能存在记录对DICOM文件的访问和可能出于安全原因拒绝对该数据的访问的必要性。为了能提供这些功能，服务组件17自身必须可以访问其它能提供审查或数据保护所需功能的服务组件。审查和数据保护所需的功能可能对不同的安装情况有所不同。因此同样通过配置为服务组件17提供用于审查和数据保护的服务组件。

在图3中示出服务组件17的汇编程序的结构。服务组件17在各分离的汇编程序中都具有支持包含在另一个汇编程序中的数据接口19的服务实现18，其中该服务实现实现了服务接口19，服务组件17的特性和方法可以通过服务接口19提供给应用16。尤其是应用16具有对包含该服务接口19的汇编程序的引用。由于服务接口19是不变的，因此当服务实现18改变时不需要更改该引用。

服务接口19为应用16提供了同步和异步的方法，其中涉及异步执行的方法的结束通知总是在要求执行该异步方法的相应过程线程的语境中进行。

服务组件17还具有同样存在于一个分离的汇编程序中的匹配接口20。可以将一个服务组件17的所有匹配接口20组合在一个汇编程序中，或者还可以为一个服务组件17的不同匹配接口产生不同的汇编程序。如果要更改服务组件17的性能，则在匹配实现21中实现匹配接口20并以下面还将详细描述的方式将匹配实现的汇编程序补充配置到服务组件17中。服务组件17的性能由此可以通过匹配实现21的结构来影响。通过匹配接口20可以影响服务组件17的关于选择合适选择策略及其它的性能，该选择策略从多个补充配置到服务组件17中的匹配实现中选择最合适的匹配实现。

服务实现18的汇编程序与包含接口的不同汇编程序有关。这样的汇编程序包括服务接口19的汇编程序，此外还有具有至少一个由服务实现18在需要的情况下调用的匹配接口20的汇编程序，以及由服务组件17调用的其它服务组件22的服务接口19的汇编程序。服务实现18在加载时从下面还要详细解释的运行时环境那里获得对匹配实现21中定义的匹配对象的引用以及对其它服务组件22中定义的服务对象的引用。

服务实现18会被更新。新版本的服务实现18必须支持旧服务实现18的性能，只要该性能可以被该应用观察到。

图4示出服务实现18的内部结构。在此要注意图3的其它服务组件22可以具有相同的结构。

服务组件18具有通信接口23，服务组件18通过该接口与上级应用16交换信息。

此外服务组件22具有内部调用单元24。应用16对服务组件18的所有调用都由调用单元24进行，并分配给内部执行单元25。在该分配时考虑服务实现21以及引起调用的应用16的内部要求。尤其是必须考虑引起调用的过程线程的语境以及同步或异步服务实现18的详情。对由应用6发起的请求的分配例如可以借助由执行单元25顺序处理的等候队列进行。

执行单元25在考虑补充配置到服务组件17中的匹配实现21和补充配置到服务组件17中的其它待使用服务组件22的条件下提供由应用16请求的服务。执行单元25在此应当这样调用匹配实现21，以使得在该匹配实现21内部不可能出现与服务实现18的并行。相反，所使用的其它服务组件22可以被任意调用，因为该服务组件可以同时由不同的过程线程和不同的应用16调用，并将其结果返回到引起调用的过程线程的正确语境中。根据引起调用的过程线程的语境，执行单元25必须保证发送给引起调用的过程线程的进展消息、错误消息和结束消息都返回到其语境中。

最后服务组件17还具有内部的扩展存储库26，其在加载时由下面还将详细描述的运行时环境填入对已产生的扩展实例的引用，这些扩展已补充配置到服务组件17中。该扩展既涉及包含在匹配实现21中的匹配，也涉及将由服务组件17使用的服务组件22。在图4中服务组件17例如包含对将要补充配置到服务组件17中的匹配对象的引用27，对在匹配实现21中通过配置提供给服务组件17的选择方法的引用28，以及对将要使用的服务组件22的实例的引用29。

图5中示出运行时环境30的结构。其除其它之外还向服务组件17传递引用27至29等。运行时环境30除其它之外包括容器过程(Containerprozess)31。配置文件32包含所有现有服务组件17、22的逻辑名称，并通过相应的项目确定其可见性。在第一次调用服务组件17或22时，由运行时环境30产生该服务组件17或22的实例，并以所配置的名称记录在服务存储库33中。容器过程31的服务存储库33包括所有已在容器过程31中产生的服务组件17或22的实例。如果调用已产生实例的服务组件17，则对该调用的响应包括对已产生的服务组件17或22的实例的引用。

配置文件32可以包含针对服务组件17或22的所有信息。但还可以为各服务组件17分别分配一个自己的配置文件，其中记录匹配实现21和使用的其它服务组件22。基于这一信息和服务存储库33的内容，运行时环境30产生对已有实例的引用或产生新实例。这些引用只能在已为其配置了匹配实现21和其它服务组件22的相应的服务组件17中被访问。

为了实现对版本的无依赖性，为每个已配置的服务组件17设定必须满足所产生的实例的最小版本。运行时环境30产生服务组件17的最新的已安装版本作为实例，并保证在配置文件中没有要求更新的版本。

要注意的是，当多个应用16在配置文件32中将相同的逻辑名称用于服务组件17时，服务组件17对于该多个应用16是可见的。

在此描述的服务组件17和22的体系结构满足下列要求：一方面服务组件可以通过配置而与使用该服务组件的应用的要求匹配。该匹配既涉及服务组件17本身的功能又涉及由服务组件17使用的其它服务组件22。

另一方面通过配置确定服务组件17的实例数量和该实例对于不同应用16的可见性。

此外服务组件17还考虑使用该服务组件的应用16的过程线程的体系结构，其中服务组件17不产生对应用16来说可见的并行性，而是提供异步的方法。进展消息、错误消息和结束消息在异步调用的情况下可通过使用该服务组件的应用16在其过程线程的语境中提供出来。

此外应用16与服务组件17的版本无关。因为应用16不是由于服务组件17的实施而被链接，而是通过配置文件32与使用该服务组件的应用关联。

最后还要指出，服务组件17还可以在可下载的应用16中使用。

这将在下面详细解释。

基于上述特性，服务组件17的体系结构提供下列优点：

可配置的服务组件17允许用户将服务组件17的性能与使用该服务组件的应用16和现有资源的要求相匹配，其中用户将配置实现21补充配置到服务组件17中。在此可以为相同的匹配接口20给出多个不同的匹配实现21。

此外用户还可以通过配置合适的选择方法来匹配服务组件17的性能。所配置的选择方法实现了选择策略，以选择应当何时从可用的匹配实现组中使用哪个匹配实现21。

最后用户还可以通过配置确定待使用的其它服务组件22。在此要指出对其它服务组件22的依赖性不是在服务组件17内部硬性实现的，而是可以通过配置提供给服务组件17的。

通过可配置性，可以将服务组件17与不同的要求相匹配。

另一个优点是执行服务组件17不会产生与引起调用的应用的并行性。这在具有并行性和多个用户的环境中特别有利。用户不需要更深地理解服务组件17内部的内在并行性。更多的是将服务组件17内部的内在并行性与应用隔离开来。

另一个优点是应用16和服务组件17以及匹配实现21和其它待使用的服务组件22就版本而言是相互独立的。这使得可以在用户不注意的情况下更换各组件17。这通过服务接口19和服务实现18的严格分离以及由运行时环境30按照配置文件32产生的实例来实现。

最后还具有一个优点，服务组件17的可见性是可配置的。这使得程序员可以在配置时确定哪些服务组件17应当由应用16一起使用，哪些服务组件17应当是只分配给特定应用16的。

如下面还要详细解释的，在需要时可以下载服务组件17。因此服务组件17不必事先固定安装。

有时还必须提供跨机器界限的服务。为此再次参见图1。用户例如早上在诊断设备8上以特定的应用16工作，并存储了其对应用16的设置。这种偏好的典型例子是图形用户界面的风格、初始值、模式设计等等。如果用户下午在诊断设备9上又以应用16工作，则用户可能希望在诊断设备9上运行的应用16考虑其在早上建立起来的偏好

图6示出用于提供跨机器界限34的服务的可能解决方案。在本地机上，例如在诊断设备8或9上，访问代理服务组件35的应用16运行在容器过程31中。代理服务组件35是相应于服务组件17建立的，并相应于该服务组件17补充配置到应用16中。此外代理服务组件35相对于应用16实现了与服务组件17相同的服务接口19。

但是代理服务组件35将应用16建立的查询转发给在远程机、例如图1所示的服务器10上运行的服务器过程36。

在服务器过程36内部可以如图6所示运行任意服务器服务37，该服务器服务不一定要相应于图2至图5解释的体系结构那样构造。实际的服务器服务37之前还可以连接查询传递器38。

此外按照图7还可以在远程机上运行提供与运行时环境30相对应的运行时环境并包括服务存储库33在内的服务器过程39。在该服务器过程39中可以运行相应于服务组件14构造的服务器服务组件40，该服务器服务组件从查询传递器41获得由代理服务组件35传递的查询。

对应用16建立的查询的处理如下进行：

代理服务组件35的调用单元24将应用16获得的请求放置到等候队列中。一旦在该等候队列中存在消息并且存在与远程服务器服务组件40或服务器服务37的连接，对应的内部执行单元25就被激活。由远程服务器服务37或服务器服务组件40接收的响应可以保存在代理服务组件35中，并因此在稍后相同的查询时又被使用。由此有时在缺乏连接时好像还能使用远程服务组件40或远程服务器服务。没有保存的响应或已经无效的响应导致必须将相应的查询再次发送给远程服务组件40或远程服务器服务37。除了响应之外还可以在本地一直保存查询，直到建立起至远程服务组件40或远程服务器服务37的连接为止，从而查询不必存储在应用16本身中。因此响应时间强烈依赖于网络连接和远程服务器服务37或远程服务器服务40是否可用。

下面继续跟踪服务器过程39范围内的处理。在服务器服务37范围内的处理相应进行。在服务器过程39的范围内，查询由查询传递器41接收并传递给服务组件40。因此服务组件40看见的只是一次本地调用，就好像服务器服务组件40在引起查询的应用16的容器过程中运行一样。应用16和远程服务组件40因此都不会留意距离和它们之间存在的通信路径。

在服务器过程39内将查询传递给远程服务组件40是通过特定于该服务器过程39的机制进行的。例如服务器过程39可以运行在Web服务器上，查询传递器41可以实现为围绕该远程服务器服务组件40的Web服务。

由于服务器过程产生的响应可能经历相当长的延迟这一事实，因而远程服务器服务组件40的服务接口19只应提供异步的方法。如果所选择的代理服务组件35和远程服务组件40之间的通信协议是一种同步协议、例如http，则服务器过程39中的查询传递器41必须收集进展消息和完成消息，并在查询结束之后作为收集结果消息回传，而且代理服务组件35必须这样处理该响应，使得以正确的顺序并在发出请求的过程线程的正确语境中将相应的进展消息和完成消息回传给使用该服务组件的应用16。将异步协议用于代理服务组件35和远程服务器服务组件40之间的通信保证了比使用同步协议明显更接近当前情况地提供进展记录。也可以配备基于同步协议的异步通信。

原则上可以将服务器服务组件40也下载到本地机上并直接由应用16调用。在这种情况下该配置名为服务器服务组件40而不是代理服务组件35。因此在该更改后的配置中，服务是本地提供的，而应用16或服务器服务组件40没有被改变。

如果下载的服务器服务组件40在其实现时直接依赖于标准软件组件、如文本处理器、数据库或图像处理器，则存在下面的可能性：标准软件组件同样可以被下载。此外还可以在远程机上透明地调用标准软件组件。最后可以将通过服务组件对标准软件组件的访问封装到其它待使用的服务组件22中。这使得可以将该其它待使用的服务组件22本地运行，而使用的标准软件组件继续远程运行。

要注意，如果要使在不同机器上对多个代理服务组件35的使用实现高度的可伸缩性(Skalierbarkeit)，则服务器服务组件40中的功能必须无状态(zustandslos)地编程。涉及应用16的状态和用户会话(Benutzersitzung)可以保存在本地代理服务组件35中。

在图8中示出另一个变形的实施方式。在该实施方式中，所有服务组件都具有相同的服务接口19，而且与是常用的本地采用的服务组件17、代理服务组件35还是服务器服务组件40无关。在这种情况下服务接口19只包含一个具有消息块作为参数的执行方法。应用16产生该消息块，并因此建立对已配置的服务组件的查询。如果是本地服务组件17，则就在本地处理该查询。如果服务组件是代理服务组件35或服务器服务组件40，则将该查询传递给在代理服务组件35上配置地址(如URL)的服务器过程36或39。在该实施方式中，为所有可能的远程服务器服务组件40使用相同的代理服务组件35的服务实现。

该实施方式还提供了一个优点，还可以实现对等候队列的集中管理。因为通过为代理服务组件35使用相同的服务实现18，可以在服务器10上集中管理代理服务组件35和远程服务器服务组件40之间的通信。尤其是可以通过在服务器10上的干预集中停止和重新进行该通信，而应用16除了响应的延迟之外不会注意到这一点。对通信的这种集中管理尤其是在下面的情况下有意义：传送大数据量，但系统需要将其所有资源用于本地的、应当无干扰运行的时间紧迫的任务。

服务组件40除了满足向本地使用的服务组件17提出的要求之外还要满足以下要求：服务器服务组件40既可以在个别安装时在单个计算机上使用，又可以在分布式安装时使用，尤其是在应用16当需要时才被加载到计算机上的状况中。此外服务器服务组件40适应用于服务器服务组件40和代理服务组件35之间通信的通信协议的要求。最后代理服务组件35要这样构造，当网络连接中断或服务器服务组件40工作于其上的中央服务器10刚好不可用时应用16的服务也能看起来可用。

此外在借助图6至图8描述的实施例中，与借助图2至图5描述的实施例相比还给出了以下优点：借助图6至图8描述的体系结构使得服务组件可以可选地本地运行或跨机器界限地运行。运行方式在此仅通过所属配置文件32中的配置项目确定。应用16和服务器服务组件40都不必为此而改变。由此可以在智能客户端和移动应用的情况下为每个计算机这样匹配该配置，使得计算上现有的资源被最佳利用，并且也可以限制必须被下载的汇编程序的数量。

在与智能客户端有关的应用16中，还会出现其它问题。因为这种应用16在需要时可以下载到未知机器上。这些机器具有不同的资源，如不同的图形卡、不同的磁盘存储器空间、不同的存储结构、不同的网络连接——从拨入调制解调器到吉比特网络。尽管如此还是应当在每个计算机上为用户相同地表现应用16，即使应用16需要的服务不能在本地提供，因为为此所需的资源不能本地提供。因此有利的是在下载应用16时相应于现有的资源来配置要使用的服务组件17、35和40，并且向应用16提供适合的服务组件17或适合的代理服务组件35，而应用16不必与现有的资源匹配。

再次借助图1解释在此出现的问题。

针对医疗图像处理的应用16可以建立大数据体的表面再现。为此必须将整个数据体读入服务组件17中并进行处理。例如在诊断设备8或9上运行的应用16委托服务组件17在考虑由用户预先给定的偏好的情况下处理该数据体，然后显示再现结果。这例如可以是显示被检查患者的一个器官的旋转表面的电影。要处理的数据体可以具有很大的范围。如果服务组件17例如应当处理分别具有0.5M字节数据体的10000张图像，则数据体总共有5G字节。因此希望服务组件可以有效访问数据。此外服务组件17的执行还需要足够大的工作存储器和足够大的磁盘存储器空间。因此，有意义的是，仅当在诊断设备8和9上具有足够大的工作存储器和磁盘存储器空间并且存在对中央数据存储器7的快速网络连接时才将相应的服务组件17连同应用16一起下载到诊断设备8和9上。

但如果医生在其诊所内通过调制解调器连接将相同的应用16下载到诊断设备14上，则由于时间的原因而几乎不可能通过调制解调器将全部10000张图像都下载到诊断设备14上并在那里再现。替代的是，在这种情况下应当在医疗数据网络1中再现这些图像。服务组件17因此不需要加载到诊断设备14上。而是只要将代理服务组件35加载到诊断设备14上就足矣，该代理服务组件与服务器10上运行的对应的服务器服务组件40通信，该服务器服务组件40建立该再现并将结果传送给代理服务组件35。

借助通过DICOM协议进行的数据交换解释在远程机器上出现的问题的另一个例子。

在医疗诊断环境中在大多数情况下通过DICOM协议发送医疗数据。在DICOM协议的范围内，在参与的计算机之间建立连接，这些参与的计算机扮演DICOM节点的角色。出于安全原因DICOM节点通常必须相互已知。DICOM协议的展开和为了传输而对医疗数据的准备可以作为服务组件17来实现，该服务组件可以由很多应用16使用，以读取DICOM数据或同时存储在中央文档库中，本地服务组件17可以具有DICOM实现并直接向已知的DICOM节点请求DICOM数据。

如果应用16被下载到计算机、例如诊断设备8或14上，并且该计算机对其它DICOM节点不是已知的，则应用16不能直接通过DICOM协议向其它DICOM节点请求数据。但应用16可以委托代理服务组件35通过DICOM协议进行数据交换。

代理服务组件35例如通过其它通信协议、如http向中央Web服务请求DICOM数据。该中央Web服务现在可以扮演对各方都已知的DICOM节点的角色，并且与其它DICOM节点通过DICOM协议交换需要的DICOM数据。

在此需要注意，按照图9为应用16分配了多个服务组件17。在图9中应用16例如直接访问第一服务组件42和第二服务组件43。第一服务组件42又访问第三服务组件44和第四服务组件45。应用16因此建立在一个包括多层服务组件的服务组件网络上。

借助图2至图8描述的服务组件17和22以及代理服务组件35和服务器服务组件40可以这样分布在不同的机器上，使得服务组件网络最佳地与现有的资源相匹配。在图9中资源是足够的，因此服务组件网络和应用才能在目标计算机46上运行——应用16连同服务组件42至45一起下载到该目标计算机上。

图10相反示出了目标计算机46的资源对于第四服务组件45不足的情况。在这种情况下第四服务组件45在目标计算机46上被修改后的第四服务组件47代替，修改后的第四服务组件47的服务接口19与第四服务组件45的服务接口19一致，但其服务实现18是代理服务组件35的服务实现。修改后的第四服务组件47因此由第一服务组件42产生的查询传递给位于服务器10上的查询传递器41。因此向应用16提供了该服务层的全部功能，就好像服务组件42至45设置在目标计算机46本地。

由服务组件42至45形成的服务层的另一个优点是服务组件42至45之一的服务实现18可以被更换，而不必重新翻译或连接该服务层。举例来说，按照图11在第一服务组件42中服务实现18被修改后的服务实现49代替。修改后的服务实现49的接入可以通过更改配置文件32来进行。应用16和所使用的服务组件44、45都没有被涉及，可以以其原始版本继续使用。

最后图12示出了在目标计算机46上不需要多个服务的情况。例如在目标计算机46上可能缺乏用于本地交换媒介的驱动器，或者不具有用于输出声音的手段。相应的在图12示出的情况中没有例如将要补充配置到第一服务组件42中的服务组件44和45。

现在可以适应性地对服务组件42编程。这意味着缺乏其它要使用的服务组件44和45会导致在第一服务组件42的服务实现18中的相应调用被跳过。

此外第一服务组件还可以明确地面向待使用服务组件45、46的缺乏，其中为第一服务组件42使用功能范围减小了的版本，该版本绝不会使用所缺乏的服务组件44和45，即使这些服务组件被补充配置到第一服务组件42中。

借助图9至图12描述的服务层的建立借助配置文件32来进行，该配置文件对应于不同的可下载应用16。在配置文件32中确定服务组件17的哪些服务实现18应当在不同类型的目标计算机46上使用。举例来说，可以在配置文件中描述服务组件17本身必须被下载，然后该服务组件本地提供服务，或应当使用代理服务组件35，然后该代理服务组件与中央服务器服务组件40展开通信。

对不同类型的目标计算机46的描述可以事先一次性建立，然后在需要时采用。当总是要下载应用16时，首先按照实现建立的描述确定目标计算机46的类型，然后使用为该类型的目标计算机46产生的配置文件32。目标计算机46与特定类型的对应例如可以在医院的管理信息技术的部门集中进行。在该部门通常将安装的每台计算机登记在册，并获得唯一的计算机名。此外目标计算机46装备的资源是已知的，因此目标计算机46的类型也是已知的。如果现在由特定目标计算机46提出对下载应用16的查询，则可以通过引起查询的目标计算机46的名称确定其类型，并按照产生的配置文件32下载最适合该类型的服务组件版本。

在一个变形的实施方式中，首先将路径查找程序下载到目标计算机46上，该程序找出目标计算机的特性并在加载时确定最适合该目标计算机46的配置文件32，然后该配置文件32用于随后下载的应用16。

在此描述的服务层具有一系列优点：

该服务层可以实现服务组件42至45在多台机器上的分布，而应用16的用户或引起调用的服务组件不会注意这一点。从应用16的角度来看存在的是一个本地服务层。

分布策略还可以考虑很多不同的方面。

可以分别在超出与其资源(即存储器结构、特殊硬件、处理器速度、网络带宽、数据访问手段等等)有关的相应工作能力提供服务的计算机上提供服务。

此外还可以在没有网络连接的情况下(例如在移动计算机的情况下)提供服务，其中查询和任务也是在没有网络连接的情况下发送的。但在这种情况下只要不存在与远程服务组件的网络连接就不接收响应。如果所有需要的服务组件都已被下载到本地计算机上，则没有网络连接也可以本地提供服务。

通过只能在受保护的环境中执行包含受保护程序代码的服务组件，该分布策略还可以保证对知识产权的保护，并提供免受操纵的安全性。

此外分布策略可以考虑加载过程的复杂性。例如如果下载的服务组件需要本地具有例如本地数据库这样的先决条件，该本地数据库同样必须是在能提供服务之前首次安装的，则一般更为有效的是向可集中使用的服务组件请求服务，而不是下载该服务组件和本地执行。

此外该服务层的可配置性允许最佳地匹配目标计算机46的给定，而不必让应用16知道这些。

通过采用各服务组件分级和配置地建立服务层，各服务组件可以独立于彼此地更改其版本。因此可以逐步地继续开发该服务层，而不会影响该层中现有服务组件的功能。

由于每个服务组件独立于其它服务组件的服务实现，因此服务层的能力可以减小为只有那些在具体情况下也需要的服务组件和功能。

下面描述针对这里描述的服务组件的几种可能的应用情况：

-配置服务：

-客户端应用可以在需要时潜在地下载到每个工作位置上。有利的是下载的应用也像该应用的所有其它拷贝一样自动使用相同的配置数据。配置数据可以是在整个机构范围内为各工作位置或用户特殊预定的，并借助配置服务分配给提供该配置服务的服务组件。

-数据传输服务：

在医疗诊断领域图像是重要的信息来源。因此为了建立诊断通常必须访问医疗图像。图像在特定于模态的数据采集设备如磁共振设备、计算机断层造影设备或超声波设备上产生，存储在文档系统中并从该文档系统加载到建立诊断的工作位置。工作位置例如是诊断设备7、8、14。针对传输协议和图像的数据编码通常采用DICOM标准。如果客户端应用在其下载之后需要访问医疗图像，则该客户端应用为此使用数据传输服务组件。

-数据缓存服务：

如果客户端应用已被下载到工作位置并且该客户端应用通过数据传输服务将图像同样加载到工作位置上，则出于效率原因希望这些数据在本地缓存一段时间，从而随后对这些数据的访问不需要通过数据传输服务进行新的数据传输，并因此不会产生延迟。数据缓存服务的另一个优点是在有时缺乏对网络的访问(例如对于移动计算机)的情况下也能获取数据。这样的数据缓存服务组件必须包含用于数据保护、数据一致(Datenkonsistenz)和限制所需资源的策略。

除了图像数据之外还希望在本地临时存储器中保存其它相关信息，如刚开始由配置服务读取的配置数据。因此在缺乏网络连接的情况下也可以利用正确的、最后使用的配置数据来启动已下载的客户端应用。

此外重要的是在数据缓存服务中也将新产生的数据临时存储在客户端工作位置上。因此在仅间或具有网络接入的移动工作位置的情况下该应用可以将数据虚拟地存储在远程文档中，即使向该远程文档的物理的数据传输在重新存在网络连接时才通过数据传输服务进行。在该数据保存策略中必须确保新产生的数据仅在其事先已成功传送到远程文档中之后才从临时存储器中删除。

-数据安全服务：

医疗图像和诊断信息是敏感数据，只应当让特定的人员范围并仅在有限的时间内访问：在数据安全服务中对访问权限进行管理和检验。显然应当在所有工作位置上保证同样的数据安全，而与在哪些工作位置上下载了客户端应用无关。

-许可服务：

软件制造商对用户使用客户端应用的功能也要合理付费是感兴趣的。为此需要与下载客户端应用的工作位置无关地只能使用那些用户支付了费用的功能。该许可与在此描述的服务组件一起也在暂时没有网络接入的工作位置上起作用。

-数据管理服务：

用户必须选择其进行诊断所需的数据。为此客户端应用必须与下载该客户端应用的工作位置无关地向用户提供目前该客户可访问数据的概览，从而用户可以进行有效的选择。对用户恰好能看见的数据储备的管理由数据管理服务进行。

-数据访问服务

客户端应用必须在确定了要加载的数据并在必要时将该数据传送到远程文档之后在应用内被读取和处理。在医疗图像的情况下这意味着通常处理DICOM格式的数据。为了有效访问DICOM数据，读取全部DICOM数据流和将其内容以改变的格式保存在存储器中(例如借助哈希表)以便快速访问是有帮助的。由此虽然应用本身还必须了解DICOM属性，但不需要分析DICOM数据流所需的功能。

-图像处理服务

在医疗图像由客户端应用读取之后，必须显示其像素数据并进行可能的后处理，如更改图像对比度、产生立体表面、阴影等等。相应的算法封装在图像处理服务中，从而该图像处理服务可以同样可供其它客户端应用使用，各应用之间的图像质量对同一幅图像也是没有不同。还可以在远程计算机上运行图像处理服务，并且只向客户端应用传送各显示屏范围内的像素以用于显示。

-等候队列服务

在医疗领域有时要处理极大的图像数据量。大图像数据组的发送、打印或费事的后处理就是一项费时的任务，尤其是在所需的网络有时无法使用时，这例如对于移动的计算机或工作位置是常有的事。在这种情况下客户端应用可以通过将该任务传递给等候队列服务来启动该任务，从而应用可以继续进行其它任务，而不必继续操心一项长时间运行的任务。

等候队列服务的另一个应用是管理始终只能在特定的时刻最多执行一项任务的服务组件中的任务，如打印机或DVD刻录机(Brenner)。

等候队列服务应当可以由每一个能加载客户端应用的工作位置使用。在等候队列服务的令人感兴趣的特征中还有对设置的任务的可处理性，例如设置优先级、任务的停止、删除和重新运行。

-维护服务：

在工作位置上出现故障的情况下使用故障分析功能，或只将故障报告发送给中央控制台。这种涉及维护的功能通过维护服务提供给所有已下载了客户端应用的工作位置。

Claims (35)

1.一种采用多个用于处理数据的资源处理不同模态的数据的装置，借助这些资源可以执行至少一个让至少一个服务组件(17，22，35，40-45，47)给出服务的应用(16)，其特征在于，所述服务组件(17，22，35，40-45，47)包括包含在分离的汇编程序中的服务接口(19)和服务实现(18)，该服务实现(18)可由运行时环境(30)借助配置数据(32)在加载时修改。

2.根据权利要求1所述的装置，其特征在于，所述运行时环境根据配置数据(32)产生所述服务组件(17，22，35，40-45，47)的实例，并在存储库(33)中管理所产生的实例。

3.根据权利要求1或2所述的装置，其特征在于，所述配置数据(32)确定所述服务组件(17，22，35，40-45，47)的可见性。

4.根据权利要求2或3所述的装置，其特征在于，所述运行时环境(30)在给出服务组件(17，22，35，40-45，47)的一个已产生的实例时响应该服务组件(17，22，35，40-45，47)的调用而返回对该已产生的实例的引用。

5.根据权利要求1至4中任一项所述的装置，其特征在于，所述配置数据(32)是特定于应用的。

6.根据权利要求1至5中任一项所述的装置，其特征在于，所述配置数据(32)是特定于传输的。

7.根据权利要求6所述的装置，其特征在于，所述服务组件(35，40，47)具有用于与远程服务组件(35，40，47)通信的通信接口。

8.根据权利要求6或7所述的装置，其特征在于，所述服务组件(35)具有代理功能。

9.根据权利要求6至8中任一项所述的装置，其特征在于，所述服务组件(40)具有服务器功能。

10.根据权利要求6至9中任一项所述的装置，其特征在于，所述服务组件(35，40)具有一个用于跨机器界限(34)进行通信的公用通信接口。

11.根据权利要求1至10中任一项所述的装置，其特征在于，所述配置数据(32)是特定于资源的。

12.根据权利要求11所述的装置，其特征在于，所述配置数据(32)在安装时通过确定可用资源的路径查找程序来确定。

13.根据权利要求1至12中任一项所述的装置，其特征在于，所述服务组件(17)包括包含匹配接口(20)的汇编程序。

14.根据权利要求13所述的装置，其特征在于，将实现所述匹配接口(20)的匹配实现(21)补充配置到所述服务组件(17)中。

15.根据权利要求1至14中任一项所述的装置，其特征在于，可以将由服务组件(17)使用的其它服务组件(22)补充配置到服务组件(17)中。

16.根据权利要求13至15中任一项所述的装置，其特征在于，所述服务组件(17，22，35，40-45，47)具有内部存储库，该内部存储库用于管理对将要使用的匹配实现(21)或将要使用的服务组件(22)的引用。

17.根据权利要求1至16中任一项所述的装置，其特征在于，所述装置用于处理不同模态的医疗数据。

18.根据权利要求17所述的装置，其特征在于，为了处理不同模态的医疗数据可以执行多个应用(16)，这些应用一起形成工作过程(15)并访问公用的服务组件(17，22，35，40-45，47)。

19.根据权利要求1至18中任一项所述的装置，其特征在于，所述服务组件(17，22，35，40-45，47)形成可配置的服务层。

20.一种处理不同模态的数据的方法，其中借助多个用于处理数据的资源执行让服务组件(17，22，35，40-45，47)给出服务的应用(16)，其特征在于，应用(16)通过分开汇编的服务接口(19)访问所述服务组件(17，22，35，40-45，47)的服务实现(18)，并借助配置数据(32)在加载时提供服务实现(18)。

21.根据权利要求20所述的方法，其特征在于，由运行时环境(30)产生所述服务组件(17，22，35，40-45，47)的若干实例，所产生的实例在运行时环境(30)的存储库(33)中得到管理。

22.根据权利要求21所述的方法，其特征在于，所述服务组件(17，22，35，40-45，47)的可见性由所述配置数据(32)确定。

23.根据权利要求21或22所述的方法，其特征在于，所述运行时环境(30)分别产生一个服务组件(17，22，35，40-45，47)的实例，并在该服务组件(17，22，35，40-45，47)的重新调用时返回对该服务组件(17，22，35，40-45，47)的该已产生的实例的引用。

24.根据权利要求20至23中任一项所述的方法，其特征在于，所述配置数据(32)是在开发时特定于所述应用(16)产生的。

25.根据权利要求20至24中任一项所述的方法，其特征在于，所述配置数据(32)是在开发时或在安装时特定于传输产生的。

26.根据权利要求20至25中任一项所述的方法，其特征在于，所述服务组件(35，40)与远程服务组件(35，40)进行跨机器界限(34)的通信。

27.根据权利要求26所述的方法，其特征在于，一个服务组件(35)用作代理。

28.根据权利要求26所述的方法，其特征在于，一个服务组件(40)用作服务器。

29.根据权利要求26至28中任一项所述的方法，其特征在于，所述服务组件(35，40)之间的通信通过一个在所有参与该通信的服务组件(35，40，47)中以同样方式形成的通信接口进行。

30.根据权利要求20至29中任一项所述的方法，其特征在于，所述配置数据是在开发时或在安装时特定于资源产生的。

31.根据权利要求30所述的方法，其特征在于，所述配置数据(32)在安装时由路径查找程序根据目标计算机(46)上存在的资源产生。

32.根据权利要求20至31中任一项所述的方法，其特征在于，相应于配置数据(32)通过分开汇编的匹配接口(20)借助匹配实现(21)在加载时修改所述服务实现(18)。

33.根据权利要求20至32中任一项所述的方法，其特征在于，由运行时环境(30)在加载时相应于配置数据(32)向所述服务组件(17，42)提供其它待使用的服务组件(22)。

34.根据权利要求32或33所述的方法，其特征在于，对将要使用的服务组件(22)和匹配实现(21)的引用由运行时环境(30)分配给所述服务组件(17，22)的内部存储库(26)。

35.一种用于处理不同模态的数据的计算机程序产品，其特征在于，所述计算机程序产品包含用于执行根据权利要求20至34中任一项所述方法的程序代码。

Images