在动态类加载器环境下管理遗留软件的静态数据结构

摘要

一种用于在动态类加载器环境下管理遗留数据建模软件产品的静态数据结构的方法包括：在动态类加载器环境下构造用于每个软件捆绑包的捆绑包特定注册表，并且当创建与特定的软件捆绑包相关联的数据模型类的内存表示时，指示所述遗留数据建模软件产品使用所述捆绑包特定注册表，而不是它的默认注册表。构造捆绑包特定注册表可以包括使用所述捆绑包的配置元数据来计算依赖图，所述依赖图识别所述软件捆绑包所依赖的其他捆绑包。初始化器可以构造捆绑包特定注册表的初始集合，并且监听器可以构造用于进入所述系统的新的软件捆绑包的捆绑包特定注册表。

说明书

相关申请的交叉引用：本申请与2010年5月10日递交的、题目为“在具有元数据驱 动线的动态类加载器环境下管理遗留软件的静态数据结构(Managing static data structures of legacy software in dynamic class loader environments with meta-data driven wiring)”的美 国临时专利申请No.61/333.235相关，并且要求该专利申请的优先权，该专利申请通过引 用被并入本文。

技术领域

本公开内容总地涉及一种用于便于遗留软件包(legacy software package)与更复杂的 软件环境之间的互操作性的机制，更具体地，涉及在动态类加载器环境下管理遗留软件的 静态数据结构。

背景技术

在计算机科学中，“序列化”是将结构化数据模型类(即，“对象”)的内存表示 (in-memory representation)转换或者转化为可以是持久的并且可以使用外部类型标识符 识别的标准外部形式的过程。该序列化过程有时被称为“缩小对象(deflating an object)” 或者“编列对象(marshalling an object)”。从外部类型标识符所识别的持久的标准外部 形式提取数据模型类的内存表示的反向过程被称为“反序列化”、“扩大对象”或者“反 向编列对象”。

数据建模软件产品已被开发用于序列化和反序列化进程。这样的数据建模软件产品通 常使用将外部类型标识符与定义数据模型的内存表示的数据模型类相关联的数据结构，比 如，注册表(registry)。数据建模软件然后使用该数据结构来识别这样的数据模型，该数 据模型的类要被实例化和配置。

遗留数据(legacy data)建模软件产品的一个示例是基于Java^TM语言的Eclipse建模框 架(EMF)。从外部模型规范，EMF为模型提供生成Java类集合的工具和运行时间支持。 EMF库将来自各种外部形式(比如，XML)的模型实例转换为由一个或者更多个Java对 象组成的内存形式。在至少一些配置中，EMF库使用注册表来执行转化。注册表项(registry key)是外部类型标识符(比如，统一资源标识符(URI))，注册表值是定义模型的内存 表示的Java类。用于将XML文档反序列化为Java对象的EMF软件将得到该XML文档 的外部类型标识符，在注册表中查找外部类型标识符以找到该外部类型标识符的对应Java 对象，然后使Java对象读取外部信息并且将它转换为一个或者更多个内存模型对象。在 存在来自不同模型的多个嵌套模型对象(nested model object)的情况下，当EMF反序列 化软件对XML进行解析时，它可以执行多次注册表查找。

许多具有这种功能的软件包假设：需要反序列化的任何软件可以仅在注册表中查找信 息，并且能够实例化匹配的内存模型类。这样的软件还可以假设实例化特定模型对象所需 的所有类可供使用。在简单的Java URL类加载器环境下，事实的确如此，并且EMF使用 该机制。然而，在更复杂的动态类加载器环境下，软件可以被划分为不同的“捆绑包 (bundle)”。每个捆绑包可以与描述例如该捆绑包的名称、该捆绑包的版本和依赖信息 的配置元数据相关联。每个捆绑包的元数据于是可以被用来计算识别该捆绑包所依赖的捆 绑包集合的依赖图。该依赖关系集合描述捆绑包可以实例化的类，并且限制可供该捆绑包 使用的类。在这样的动态类加载器环境下，特定捆绑包的多个版本均具有独立的存在，并 且能够同时被其他依赖图中的其他捆绑包的其他版本使用。这样的环境可以被描述为具有 元数据驱动线(metadata-driven wiring)。

具有元数据驱动线的更复杂的动态类加载器环境的一个示例是OSGi框架。OSGi框 架是基于Java之上的类加载器环境，但是，不是支持包含所有类的单个类路径，OSGi而 是支持多个捆绑包特定的类路径。EMF的单注册表方法可能不能与OSGi的更复杂的类加 载器环境一起工作。EMF注册表包含所有可能的外部类型标识符及其对应的模型类，每 一模型可以仅存在这些模型类的一个版本。如果试图读取特定的外部模型格式的OSGi软 件捆绑包不可以访问必要的类，则它将不能实例化对应的内存表示，即使这些类在单个注 册表中。如果存在包含模型类的特定捆绑包的多个版本，则一次仅一个版本能够存在于注 册表中，即使捆绑包的多个版本存在并且可供在OSGi环境下使用。

发明内容

本文公开了用于在动态类加载器环境(比如OSGi)下管理遗留数据建模软件产品(比 如EMF)的静态数据结构的系统和方法的各种实施方案。动态类加载器环境可以包括可 变的多个软件捆绑包，并且可以包括软件捆绑包的多个版本。遗留数据建模软件产品可以 使用将外部类型标识符与数据模型类相关联的注册表来创建数据模型类的内存表示。所述 方法的实施方案可以包括构造用于供遗留数据建模软件产品使用的软件捆绑包的捆绑包 特定(bundle-specific)注册表。

在一些实施方案中，数据模型类可以包括Java类，并且内存表示可以包括Java对象。 外部类型标识符可以使用XML来指定。捆绑包特定注册表可以通过Java系统属性来指定。

在一些实施方案中，初始化器(initializer)可以在动态类加载器环境下构造用于每个 软件捆绑包的捆绑包特定注册表。监听器(listener)可以构造用于进入动态类加载器环境 的新的捆绑包的捆绑包特定注册表。捆绑包特定注册表可以在超注册表(super-registry) 中被管理。超注册表可以取代遗留数据建模软件产品所使用的注册表，并且可以将正确的 捆绑包特定注册表提供给遗留数据建模软件产品。

捆绑包特定注册表构造的实施方案可以包括使用与软件捆绑包相关联的配置元数据 来计算依赖图，所述依赖图识别该捆绑包所依赖的软件捆绑包的依赖子集。注册表碎片可 以针对依赖子集的每个成员而构造，并且这些注册表碎片可以被合并到捆绑包特定注册表 中。

附图说明

图1是图示说明根据本公开的使用遗留数据建模软件产品的动态类加载器环境的示 意图；

图2是图示说明根据本公开的自定义包注册表实现方式的实施方案的示意图；

图3是图示说明根据本公开的初始化过程的实施方案的流程图；

图4是图示说明根据本公开的初始化过程的实施方案的流程图；

图5是图示说明根据本公开的初始化过程的实施方案的流程图；

图6是图示说明根据本公开的捆绑包监听器的实施方案的示意图；以及

图7A和图7B是图示说明根据本公开的新捆绑包进入系统的示例性过程和捆绑包离 开系统的示例性过程的流程图。

具体实施方式

如图1所图示说明的，示例性遗留系统100包括硬件110、操作系统120和执行环境 130。执行环境130可以是利用分层类加载器系统的任何执行环境。硬件110可以是能够 实现遗留系统100的处理器、存储器、储存器、联网装置、路由器、布线、发射机、接收 机、输入/输出装置、机器、机械装置、电子装置以及其他物理资源的任何组合。操作系 统120可以是能够结合硬件110实现遗留系统100的可执行程序代码、数据以及其他软件 或固件的任何组合。

遗留系统100中的执行环境130的示例性实施方案是利用线性父子分层类加载器系统 的基础Java环境。在基础Java环境下，如果子类指定类A的一个版本，但是子类的层次 结构中的父类指定了类A的不同版本，则子类在运行时将加载类A的这个不同版本，而 不管子类的指定如何。遗留系统100中的执行环境130的另一个示例性实施方案是利用树 层次结构的类加载器系统的J2EE环境。在J2EE环境下，如果子类指定类A的一个版本， 则类A的这个版本将在运行时被加载，即使子类的兄弟类(或者较低层次的实体)指定类 A的不同版本。然而，如果子类的层次结构中的父类指定类A的不同版本，则子类在运行 时仍将加载类A的这个不同版本，而不管子类的指定如何。所以，尽管J2EE支持相同层 次的类隔离，但是父-子类冲突仍然存在。

数据建模软件产品140已被开发用于示例性执行环境130下的类加载器所执行的序列 化和反序列化。这样的数据建模软件产品140通常使用将外部类型标识符与定义数据模型 的内存表示的数据模型类相关联的数据结构(比如，默认注册表150)。数据建模软件140 使用默认注册表150来识别这样的数据模型，该数据模型的类要被实例化和配置。

图1还示出了从示例性遗留系统100到示例性系统200的迁移。系统200包括硬件210、 操作系统220和执行环境230。执行环境230比执行环境130更复杂，并且可以是利用在 其中显式依赖关系(explicit dependency)可以被定义的动态类加载器系统(而不是执行环 境130的分层类加载器系统)的任何执行环境。硬件210可以是能够实现系统200的处理 器、存储器、储存器、联网装置、路由器、布线、发射机、接收机、输入/输出装置、机 器、机械装置、电子装置以及其他物理资源的任何组合，并且可以与硬件110类似或者甚 至相同。操作系统220可以是能够结合硬件210实现系统200的可执行程序代码、数据以 及其他软件或者固件的任何组合，并且可以与操作系统100类似或者甚至相同。

系统200中的执行环境230的示例性实施方案是利用图解的非分层类加载器系统(比 如OSGi)的动态类加载器环境。在OSGi环境下，软件可以被划分为不同的“捆绑包”。 每个捆绑包可以与描述例如该捆绑包的名称、该捆绑包的版本以及类依赖关系信息的配置 元数据相关联。每个捆绑包的元数据于是可以被用来计算识别该捆绑包所依赖的捆绑包集 合的依赖图。该依赖关系集合描述捆绑包可以实例化的类，并且限制可供该捆绑包使用的 类。在这样的动态类加载器环境下，特定捆绑包的多个版本均具有独立的存在，并且能够 同时被其他依赖图中的其他捆绑包的其他版本使用。OSGi框架是基于Java之上的类加载 器环境，但是，不是支持包含所有类的单个类路径，OSGi而是支持多个捆绑包特定类路 径。

遗留数据建模软件140的单个默认注册表150方法可能不能与更复杂的环境230一起 工作。这样的单个注册表150可以包含所有可能的外部类型标识符及其对应的模型类，每 一模型可以仅存在这些模型类中的一个版本。如果试图读取特定的外部模型格式的软件捆 绑包不可以使用必要的类，则它将不能实例化对应的内存表示，即使这些类在单个注册表 150中。如果存在包含模型类的特定捆绑包的多个版本，则一次仅一个版本能够存在于注 册表150中，即使该捆绑包的多个版本存在并且可供在动态类加载器环境230下使用。

被开发以供复杂性较低的执行环境130中的类加载器使用的遗留数据建模软件产品 140可以通过自定义注册表250被配置为供动态类加载器环境230中的类加载器使用。在 图2中所图示说明的实施方案中，动态类加载器环境230中的软件被划分为捆绑包：捆绑 包A、捆绑包B、捆绑包B.2、捆绑包C等至捆绑包X。每个软件捆绑包可以与它自己的 捆绑包特定注册表250A-X相关联，所述捆绑包特定注册表250A-X基于每个软件捆绑包 的依赖图来表示这样的外部格式集合，该外部格式集合的内部格式类可供每个软件捆绑包 使用。这些捆绑包特定注册表250A-X共同形成超注册表250。超注册表可以被描述为注 册表的注册表。每个捆绑包特定注册表项是与该捆绑包相关联的外部类型标识符，并且捆 绑包特定注册表值是与这些项相关联的数据模型类。这些数据模型类定义数据模型的内存 表示。通过使用该多注册表方法，给定的软件捆绑包仅知道如何反序列化这样的模型对象， 该给定的软件捆绑包可以使用该模型对象的类。如果存在特定捆绑包的多个版本(比如捆 绑包B和捆绑包B.2)，则每个捆绑包具有它自己的注册表(分别为250B和250B.2)、 它自己的依赖关系以及它自己的任何内存模型类的版本。

如图1中所示的在动态类加载器环境230中使用遗留数据建模软件产品140的系统的 实施方案在OSGi环境下利用Eclipse建模框架(EMF)。EMF和OSGi两者都在Java环 境下运行。EMF是用于定义和管理数据模型的框架。EMF所提供的能力之一是将持久的 数据模型读取为由一个或者更多个Java对象构成的内存格式。如以上所讨论的，该处理 被称为反序列化。

持久的数据模型可以被储存为各种形式，例如，XML元数据交换(XMI)。XMI文 件包含XML命名空间QName形式的模型类型信息。换句话讲，QName唯一地识别这样 的数据模型，该数据模型的实例已被持久保存在XMI文件中。

描述如何将XMI转换为内存表示的数据被包含在共同构成EMF包的各种Java对象 中。EMF通过提供包注册表来支持反序列化，所述包注册表将数据模型QName映射到对 应的EMF包对象的Java类名称。

在传统的“平坦的”类路径环境下，通常存在单个EMF包注册表。该单个注册表负 责将EMF已知的QName映射到它们对应的EMF包对象。该映射带来了至少两个问题。 首先，它允许EMF模型的单个版本在EMF安装中被使用。如果你想要EMF模型包的多 个版本，则不同的QName和不同的Java类名称可以被使用，有效地使得它们成为不同的 模型，而不是同一模型的不同版本。这意味着当新版本出现时该方案中使用模型的新版本 的软件应该被重写。其次，平坦的类路径环境下的所有软件共享所有模型。因此，该环境 可能不能被这样结构化，以使得它可以支持在其中运行的多个应用程序，其中一个应用程 序可以使用模型集合，而第二应用程序可以使用恰巧具有相同的XMI QName或者EMF 包Java类名称的不同的模型集合。

在OSGi环境下，类加载架构要复杂得多。如上所述，它定义软件的具有它们自己的 依赖关系的“捆绑包”，可以存在这些捆绑包的多个版本。在该环境下，支持多个应用程 序要容易得多，所述多个应用程序中的每个应用程序或者使用相同数据模型的不同版本， 或者使用恰巧具有相同的XMI QName或者Java包名称的完全不同的模型。该环境是非常 动态的：捆绑包可以在任何时间被添加到系统，并且可以在任何时间被移除。不是重写 EMF以在OSGi环境下工作(这将不仅意味着改变EMF本身，而且还意味着改变使用EMF 的应用程序)，在本实施方案中，EMF而是被配置来使用自定义的OSGi优化的序列化注 册表，而不是EMF默认静态注册表。该注册表覆盖(override)通过使用由EMF提供的、 允许通过Java系统属性指定替换注册表实现方式的机制来实现。因此，本实施方案允许 EMF及其应用程序在利用OSGi的类加载复杂性的同时保持基本上不变。

如图1所示并且如以上所讨论的，被开发供复杂性较低的执行环境130中的类加载器 使用的遗留数据建模软件产品140可以通过管理遗留数据建模软件的一个或者更多个静 态数据结构来被配置为供动态类加载器环境230下的类加载器使用。在实施方案中，用于 管理这样的静态数据结构(比如注册表)的系统和方法可以包括，但不限于，自定义注册 表250、初始化器和监听器。

自定义注册表

图2图示说明遗留数据建模软件产品140中的自定义注册表250实现方式。在实施方 案中，自定义注册表250可以是Eclipse建模框架(EMF)包注册表。标准EMF软件允许 其使用者安装覆盖默认注册表实现方式的自定义包注册表实现方式。在这样的实施方案 中，默认注册表实现方式150被更适合于动态类加载器环境230的自定义注册表250取代 (参见图1)。该自定义注册表实现方式250对于EMF表现得像单个注册表，但是，实 际上，它是注册表的汇集：用于每个软件捆绑包A至X的一个注册表250A至250X。该 注册表汇集可以被描述为超注册表。

每个软件捆绑包A至X具有它自己的依赖捆绑包图，所述依赖捆绑包图包括该捆绑 包所需的软件。每个软件捆绑包具有它自己的注册表，所述注册表包含在该软件捆绑包的 依赖图中可供使用的那些模型的那些版本。自定义注册表实现方式可以自动地确定哪个软 件捆绑包正试图使用EMF，找到该软件捆绑包的对应注册表，并且使得它对于EMF是可 见的。当另一个软件捆绑包使用EMF时，则通过使用该软件捆绑包的注册表，类似的进 程发生。因此，EMF相信它正在使用单个注册表，使用EMF的软件以常规方式使用它， 并且动态类加载器环境的复杂能力可以被权衡利用，而无需对EMF实现方式或者使用 EMF的软件的实现方式进行任何实质性改变。

初始化器

在实施方案中，用于在动态类加载器环境下管理遗留数据建模软件产品的静态数据结 构的系统可以使用负责在启动时初始化多注册表系统的初始化器。在动态类加载器环境为 OSGi的实施方案中，初始化器可以是激活器(activator)。OSGi系统允许每个捆绑包具 有激活器，所述激活器是每当捆绑包被启动或者停止时就运行的一个软件。在实施方案中， 用于管理具有OSGi的遗留数据建模软件产品的静态数据结构的系统本身被实现为OSGi 捆绑包。该捆绑包的激活器负责当该捆绑包被启动时初始化多注册表系统并且当该捆绑包 被停止时移除它。

图3是图示说明初始化多注册表系统的示例性过程的流程图300。初始化器查找动态 类加载器环境下当前可用的所有捆绑包。在步骤310，如果在所述环境下仍有未被检查的 软件包，则初始化器得到320下一个软件捆绑包以进行检查。初始化器然后确定330与该 软件捆绑包相关联的数据模型类，然后构造340用于该软件捆绑包的注册表。初始化器可 以使用与软件捆绑包相关联的元数据来确定该捆绑包的相关联的数据模型类。所构造的注 册表项可以是与在步骤330中确定的数据模型类相关联的外部类型标识符集合。注册表值 可以是数据模型类。在构造340注册表之后，初始化器返回到步骤310。如果在所述环境 下仍有未被检查的软件捆绑包，则重复所述过程。如果在步骤310，在所述环境下并不存 在未被检查的软件捆绑包，则初始化过程结束。

图4是图示说明初始化多注册表系统的另一个示例性过程的流程图400。初始化器查 找在动态类加载器环境下当前可用的所有捆绑包。在步骤410，如果在所述环境下仍有未 被检查的软件捆绑包，则初始化器得到420下一个软件捆绑包以进行检查。初始化器然后 在步骤430确定该软件捆绑包是否定义了一个或者更多个数据模型类。如果它定义了一个 或者更多个数据模型类，则将这些模型类添加440到用于该捆绑包的捆绑包特定注册表。 注册表项可以是与数据模型类相关联的外部类型标识符集合，注册表值可以是数据模型 类。

在处理了捆绑包所定义的任何数据模型类之后，初始化器计算450这样的依赖图，该 依赖图识别该捆绑包对其具有直接或者间接依赖关系的所有其他捆绑包，从而创建软件捆 绑包的依赖子集。在步骤460，如果在依赖子集中仍有未被检查的软件捆绑包，则初始化 器得到470下一个子集成员以进行检查。初始化器然后在步骤480确定该子集成员是否定 义了一个或者更多个数据模型类。如果它定义了一个或者更多个数据模型类，则将这些模 型类添加490到用于软件捆绑包的捆绑包特定注册表。返回到步骤460，如果在依赖子集 中仍有未被检查的软件捆绑包，则对该子集的下一个成员进行处理。当所有依赖子集成员 都已被处理时，该捆绑包的注册表完成。然后返回到步骤410，如果在所述环境下仍有未 被检查的软件捆绑包，则对所有剩余的软件捆绑包重复整个过程。如果在步骤410，在所 述环境下并不存在未被检查的软件包，则初始化过程结束。

图5是图示说明初始化多注册表系统的另一个示例性过程的流程图500。初始化器查 找在动态类加载器环境下当前可用的所有捆绑包。在步骤505，如果在所述环境下仍有未 被检查的软件捆绑包，则初始化器得到510下一个软件捆绑包以进行检查。初始化器然后 在步骤515确定以前是否针对该软件捆绑包构造了注册表碎片。这样的注册表碎片可以仅 包含例如该捆绑包的序列化映射。在步骤515，如果没有注册表碎片可供使用，则初始化 器在步骤520确定该软件捆绑包是否定义了一个或者更多个数据模型类。如果它定义了一 个或者更多个数据模型类，则构造525注册表碎片，并且将所构造的碎片中的模型类与用 于该捆绑包的捆绑包特定注册表合并530。但是如果在步骤515，注册表碎片可供软件捆 绑包使用，则将该碎片与捆绑包特定注册表合并530，从而消除冗余的注册表计算。

在处理了或者构造了捆绑包的注册表碎片之后，初始化器计算535这样的依赖图，该 依赖图识别该捆绑包对其具有直接或者间接依赖关系的所有其他捆绑包，从而创建软件捆 绑包的依赖子集。在步骤540，如果在依赖子集中仍有未被检查的软件捆绑包，则初始化 器得到545下一个子集成员以进行检查。初始化器然后在步骤550确定以前是否针对该子 集成员构造了注册表碎片。在步骤550，如果没有注册表碎片可供使用，则初始化器在步 骤555确定该子集成员是否定义了一个或者更多个数据模型类。如果它定义了一个或者更 多个数据模型类，则构造560注册表碎片，并且将所构造的碎片中的模型类与用于该捆绑 包的捆绑包特定注册表合并565。但是如果在步骤550，注册表碎片可供子集成员使用， 则将该现有碎片与捆绑包特定注册表合并565。返回到步骤540，如果在依赖子集中仍有 未被检查的软件捆绑包，则对该子集的下一个成员进行处理。当所有依赖子集成员都已被 处理时，该捆绑包的注册表完成。然后返回到步骤505，如果在所述环境下仍有未被检查 的软件捆绑包，则对所有剩余的软件捆绑包重复整个过程。如果在步骤505，在所述环境 下并不存在未被检查的软件捆绑包，则初始化过程结束。

尽管在图3、图4和图5中示出了用于在动态类加载器环境下管理遗留数据建模软件 产品的静态数据结构的系统的初始化过程的实施方案，但是设想可以使用附加步骤、更少 步骤、不同步骤或者这些图中所描述的步骤中的步骤的组合的其他实施方案。

如前面所讨论的，在一些实施方案中，动态类加载器环境为OSGi，并且初始化器可 以是捆绑包激活器。在这样的实施方案中，遗留数据建模软件可以是EMF，并且OSGi 环境下的每个软件捆绑包可以定义一个或者更多个EMF模型，这些EMF模型的数据可以 被放置在自定义EMF包注册表中。对于给定的捆绑包X，捆绑包激活器使用该捆绑包X 的OSGi配置元数据来计算X对其具有直接或者间接依赖关系的所有捆绑包的依赖图。对 于所得的依赖图中的每个捆绑包，激活器可以找到属于给定的依赖图成员的所有EMF模 型，并且将它们放置在与捆绑包X相关联的注册表中。结果是这样的注册表，该注册表包 含整个OSGi环境下的所有模型的子集并且对于捆绑包X是可见的。

因此，在这样的实施方案中，每个捆绑包具有它自己的EMF包注册表。所有这些注 册表本身都由自定义包注册表(超注册表)中的OSGi捆绑包维护。当捆绑包X中的软件 使用EMF时，或者当系统软件代表捆绑包X使用EMF时，自动地使得捆绑包X的注册 表可作为它的单个包注册表供EMF使用。因为每个捆绑包具有它自己的注册表，所以该 注册表的内容可以根据捆绑包而改变，不同的捆绑包具有相同EMF模型的不同版本，或 者恰巧具有相同的QName和/或EMF包Java类名称的完全不同的EMF模型。

OSGi捆绑包监听器

在用于在动态类加载器环境下管理遗留数据建模软件产品的静态数据结构的系统的 一些实施方案中，软件捆绑包可以在任何时间进入或者离开环境。在这样的实施方案中， 监听器可以监视这样的捆绑包到达和离开，并且可以作为响应执行注册表维护。图6是图 示说明捆绑包监听器602的示意图600。在图示说明的实施方案中，每当捆绑包进入或者 离开动态类加载器环境时，监听器602就接收事件。还设想其他监控方法；例如，监听器 可以对新的捆绑包到达或离开进行投票。在动态类加载器环境为OSGi的实施方案中，可 以自动地使用标准OSGi捆绑包监听器功能来维护注册表。遗留数据建模软件注册表的 OSGi实现方式可以创建它自己的捆绑包监听器，所述捆绑包监听器在每当捆绑包被添加 到OSGi框架或者从OSGi框架移除时就接收事件。当捆绑包被添加时，监听器可以从该 捆绑包提取所有的序列化绑定，并且将它们放入用于该捆绑包的专用注册表。它还可以创 建以输入捆绑包为根的捆绑包依赖图，也提取它们的所有序列化捆绑包，并且将它们放置 到新的捆绑包的注册表中。

图7A是图示说明捆绑包进入系统的过程的示意图700。捆绑包监听器可以被通知702 新的捆绑包已进入系统，可以构造704用于该捆绑包的注册表，并且可以将该注册表添加 706到自定义包注册表(超注册表)。当该捆绑包开始使用遗留数据建模软件时，或者当 其他软件代表该捆绑包使用遗留数据建模软件时，使得该捆绑包的注册表可供使用。图7B 是图示说明捆绑包离开系统的过程的流程图750。每当捆绑包离开系统时，捆绑包监听器 就被通知752，并且它从注册表的注册表(超注册表)移除756该捆绑包的注册表，因为 它将不再被使用。

在实施方案中，捆绑包监听器可以对进入系统的每个捆绑包构造仅包含该捆绑包的序 列化映射的注册表碎片。每当捆绑包被添加时，监听器然后就可以创建依赖图，并且将所 有图成员的碎片合并到新的捆绑包所使用的注册表中。因为在各个捆绑包的依赖关系之间 可能存在许多重叠，所以注册表信息可以被计算一次，然后根据需要被并入到给定捆绑包 的序列化注册表中。在一些实施方案中，捆绑包监听器可以如上所述并且如图3、图4和 图5所示那样对新的捆绑包执行捆绑包处理。设想可以使用附加步骤、更少步骤、不同步 骤或者分开的图中所描述的那些步骤中的步骤的组合的其他实施方案。

尽管本公开深入讨论了在OSGi环境下使用EMF的特定实施方案，但是本领域技术 人员将理解，本文所公开的技术和方法可以普遍地应用于在具有元数据驱动线的其他动态 类加载器环境下管理其他遗留软件包的静态数据结构。此外，虽然以上描述了根据所公开 的原理的各种实施方案，但是应该理解它们仅以示例性的方式被给出，而非限制性的。因 此，本发明(一个或多个)的宽度和范围不应被上述任一实施方案限制，而是应该仅根据 本公开公布的权利要求及其等同形式来限定。此外，以上优点和特征在所描述的实施方案 中被提供，但是不应将这些公布的权利要求的应用限于实现以上任一优点或者所有优点的 过程和结构。

此外，本文的段落标题是被提供来与37CFR 1.77的建议一致，或者用于提供本文的 结构线索。这些标题不应限制或表征可以从该公开公布的任何权利要求中所阐述的一个或 多个发明。具体地并且作为示例，尽管标题指“技术领域”，但是权利要求书不应被该标 题下所选择的语言限制为描述所谓的技术领域。进一步，“背景技术”中的技术的描述不 是要被解读为承认该技术是该公开中的任意一个或多个发明的现有技术。“发明内容”也 不是要被认为是在公布的权利要求书中所阐述的一个或多个发明的特征描述。另外，该公 开中对单数的“发明”的任何引用不应被用于证明在该公开中仅有一个新颖点。根据从该 公开公布的多个权利要求的限定，可以阐述多个发明，并且这些权利要求相应地定义了由 其保护的一个或多个发明，以及它们的等同形式。在所有例子中，这些权利要求的范围应 根据该公开按照这些权利要求本身的实质来理解，而不应被本文的标题限制。