OSGi企业级规范将要发生的变化

个人简介 David Bosschaert是Red Hat的首席软件工程师，他将主要的时间都用于JBoss OSGi框架、JBoss AS7、Apache Aries以及其他的开源项目。他还是OSGi企业级专家组（OSGi Enterprise Expert Group）的联合主席，在OSGi Cloud方面的参与尤其活跃。在2010年加入JBoss/Red Hat之前，David服务于爱尔兰都柏林的IONA Technologies and Progress Software。

EclipseCon是在Eclipse社区中关注于分享最佳实践、深刻见解、案例研究以及创新的会议，并且在更为广阔的世界中关注软件开发。其目标在于为社区创建一个论坛，从而能够互相学习、联络共同爱好者并帮助生态系统实现繁荣发展。

   

1. 大家好，我现在位于EclipseCon 2013会议上与David Bosschaert在一起。David是Red Hat的首席工程师以及OSGi企业级专家组的领导者之一。那么，David，在OSGi领域之外，在世界范围内，云计算正在变得流行起来，OSGi将会如何演化以满足将来的计算架构呢？

围绕着云，现在企业级专家组确实在做一些有意思的工作。我们正在进行一组RFC的制定，它们基本可以称为OSGi规范的前奏。其中的一个就是使用REST API来管理OSGi框架，REST是使用云的过程中所选择一个协议，此举会将REST带入到OSGi管理之中。另一个我们正在制定的很有趣的规范被称为OSGi云生态系统（OSGi Cloud Ecosystem），它关注于如何创建一个可以提供逻辑功能的应用，这个应用会有多个云节点协同工作，每个节点都由不同的OSGi框架所组成，这些框架会满足不同的用途并且互相协作来提供功能。在可伸缩性尤其是将应用进行独立地组件化方面会有特殊的作用，另外它们会运行在OSGi的服务模型之上，针对云环境中所面临的动态化问题，它们已经做了很好地处理。

   

2. 它基于已有的远程服务架构和管理（remote services architecture and administration）进行构建的吗？

是的。它基于已有的远程服务和OSGi服务模型构建的，并在此之上添加了新的特性，主要在于发现和提供元数据。所以，你可以发现指定的位置有什么，它所运行的云基础设施是什么类型，如果发生死机的话，你能够发现。这些信息能够让你更有效地处理或使用云动态化所带来的可伸缩性。

Alex: 这样的话，如果特定的节点或服务在一个环境中出现了失败的话，那么你能够在其他的地方将其启动起来。

是的。或者指定机器的负载超过了某一个特定的阀值，你就可以增加其容量。如果你的云发生问题了，你可以将所有的事情转移到另外的云上，用户可以继续进行操作。

   

3. 这件事只有Red Hat在背后进行推进还是在企业级专家组中有其他的人也在参与？

Red Hat当然是推动者之一，在这方面Paremus也是非常活跃的推动者，我们邀请了很多的研究人员以及其他在专家组中很活跃的公司为其进行工作，像IBM、TIBCO以及Oracle在专家组中都很活跃，他们也为这项工作提供反馈以及输入信息。

Alex: 我猜这就是Eclipse生态系统以及OSGi生态系统的一个方面了，在这里有很多的共识，众多不同的公司协同工作将其进行标准化，然后每个人都可以进行实现。

是的。任何人都可以实现OSGi标准，在这方面来讲，OSGi联盟是一个很友好的组织，它没有被某个公司所支配。我们尽量很民主地做事并寻找共识，在这一点上，我们一直以来做的很成功。

Alex: 我想这也有助于避免厂商绑定到特定的产品上。

这就是规范所能带给你的，我们对自己很自豪的一点在于提供了很便利的规范。OSGi规范有很多的实现并且过去已经证明如果人们愿意的话，可以很容易地从一种实现切换到另一个。在纯粹的API之外，可能会有某些原因导致人们这样做，比如在特定的环境中某一个实现工作得会更好。

   

4. 在OSGi领域之外所发生的一件事就是使用注解来进行处理获得了切实的增长，所以JMS2规范很大程度上就是注解驱动的机制，Eclipse4平台的挂钩（hook）主要就是基于注解的。OSGi如何应对这一点？

是的，所以我们在最新版本的声明式服务规范中添加了一些注解的支持，这还有些有限，但至少是开始了。目前在制定中的规范里会有更多声明式服务的注解，但是对于喜欢Java EE领域注解的人来说，可能更感兴趣的是我们正在为OSGi制定的CDI规范，它是完全基于注解的。

   

5. CDI代表什么？

上下文与依赖注入（Context and Dependency Injection），它是一个JCP规范也是Java EE规范，在Java EE领域它很活跃也很流行，人们确实很喜欢它的注解，借助它可以创建bean、使用bean并按照这种方式将系统装配起来。在企业级专家组中，我们正在进行的是一项RFC，这样你可以使用这些注解并将其带入到OSGi之中，所以人们可以在OSGi上下文中基于注解使用相同的编程模型。

Alex: 我猜这类似于Google Guice或Spring的一些东西，会有一些Inject以及PostConstruct等等。

是的。有些注解甚至是与它们共享的，因为在Java中注入注解是很通用的注解。特殊的工作在于基于CDI规范，围绕着EJB也有一些工作，它是基于Java EE EJB规范的，也支持在OSGi中使用注解，希望能在下一版本中释放。

   

6. 您认为在将来OSGi框架能直接运行EJB吗？

是的。这是目前的规划，我们正在做这件事，这是另外一个RFC，现在它正处于活跃的开发之中。

   

7. 我们已经可以这样使用Servlet规范，我猜会使用HttpService。但是最近有新的特性加入了进来以支持新的上下文；关于这一点，你掌握什么背景信息吗？

是这样的。目前或者在最近的规范中，有两种方式来支持Servlet。那就是HttpService，它基本上就是使用OSGi特定的编程模型来使用Servlet，它很流行也很简单。除此之外，围绕着Web应用程序还有另外一个规范，它允许直接将WAR文件高效地部署到OSGi上下文中，所以会有不同的工作方式。HttpService规范是OSGi特定的一个规范，已经存在了很多年，目前进行了更新，它原来有些过时了，因为它基于旧版本的Servlet规范并且关于在OSGi中如何使用服务的新理念并没有包含在其中。所以，我们对HttpService做了一些工作，Adobe在进行推进。我们对所使用的Servlet API进行了更新，所以它能够运行在更新的Servlet容器之中，比如你可以使用ServletFilter、错误页面等等，也就是说我们对其进行了现代化，不过我们也添加了一个新的编程模型，它基于白板模式（whiteboard pattern）。OSGi广泛使用了白板模式，这意味着如果要提供某一项功能时，将其在服务注册表中注册为一个服务，在这种情况下，如果你要提供一个Servlet的话，你要将其注册到OSGi服务注册表中，HttpService会找到到并且会让它在Web站点上可用。因此，在HttpService规范中，这是一种新的编程模型、新的特性。

   

8. 你提到了REST，它当然可以用于Servlet等场景之中，但是我认为你所表述的是在这种情况下，REST可以用于监控框架的状态。你能介绍一下这方面的情况吗，以及数据传输对象和远程访问OSGi VM的方式？

过去有多种方式来对一个框架进行管理和监控，有JMX和DMT管理（DMT admin），现在REST成为实现这一点的一种方式。它们基本上都会达到相同的目的，但是会以不同的形式，对于这项特定的技术什么方式最为合适呢？JMX对于Java来说是很棒的，但是在云中就不能表现这么好了，因为远程JMX连接器并不能穿越所有的云防火墙。所以，在云的上下文中，使用REST更为合适。REST是云部署和访问所选择的协议。所以，我们开始了这项工作并且取得了相当大的进展，如果人们愿意看的话，已经可以查看一个早期的访问草案（early access draft）了，但是这些不同方式的问题在于，如果你想让所有的规范都能使用这些不同的方式来进行管理的话，那么这种组合将会导致我们所要完成的工作呈爆炸性地增长，我们会发现很难维护所有的管理技术，尤其是单项的规范也正在制定中。所以，我们解决这个问题的方式是提供了与管理技术中立的API或者是为特定组件提供元数据的机制，我们启动了这个框架并将其称之为“数据传输对象”。因此，你可以在框架中获取关于各种事情的数据传输对象，如可以获得一个代表bundle的对象，这个数据传输对象只包含数据并没有行为，如果你想与其他的事情进行对比的话，它就像C语言中的struct，这意味着你可以与各种管理技术进行匹配，你甚至可以编写很机械化的映射，这样让所有的管理技术保持最新会更为容易。目前，主要的关注点在核心规范方面，不过对于如何去做，我们一旦有了清楚的想法，所有的compendium规范和企业级规范都会定义自己的数据传输对象，这样的话，你可以使用任意支持这些对象的技术来对它们进行管理。

Alex: 我认为这些数据传输对象要支持基于REST的接口或基于JMX的接口时，只需传递数据就可以了而不必嵌入进去。

确实是这样的，在一些方式中可以很机械化。REST规范是第一个基于这些DTO的规范，所以它不支持其他的方式，只支持DTO的方式，以后其他的管理规范也会更新为支持这种DTO的方式。

   

9. 现在，在EclipseCon上，你也提到了企业级规范将要包含的其他特性，如不同的作用域、服务作用域等等。你能不能为我们介绍一下服务作用域背后的理念？

在OSGi中，我们喜欢用服务注册表做很多的事情。服务注册表的确是一项很好的方式来查找和发布对象，事先并不用知道这些对象是什么，所以在过去的多年之中，它被证明非常非常有用，但是它所支持的交互模型数量有点受限，在这方面，现在有两种模型可供使用了。第一种就是你在服务注册表中注册一个服务对象，人们可以查找到这个对象，尽管你可以注册多个实例进去，但实际上会是一个单例，它们会被所有的用户所共享。第二种模型中，你给每一个使用服务的bundle一个独立地实例，这种方式被称为服务工厂（service factory）。它已经存在很长时间了，但是一直不能很好地适应EJB或CDI工作的一些需求，例如在这种情况下会具有基于会话（session）的对象，如果有一个有状态的会话bean，你会希望与特定的对象进行关联。在这种情况下，你实际上希望每次查找服务注册表的时候能够得到一个新的实例。所以，这就是OSGi核心规范尚没有支持的模型，目前有一个正在进行中的RFC会支持做到这一点，EJB和CDI RFC会是这项功能的主要用户，但是它会位于核心规范中，任何想要这项功能的人将来都可以使用它。

   

10. 在企业级规范中，将要出现的另外一个功能就是便携式协议（portable contract），它们是什么，有什么用处呢？

这是一个很复杂的话题，我尽量简洁地描述一下。在OSGi之中，我们会对事情进行版本化，我们喜欢语义化的版本（semantic version），如果使用正确的话它能够带来很大的收益，尤其是我们将其应用于Java包的时候。关于版本号的增长，这里会有一些规则，取决于发生了什么样的变化。这确实非常有用也很强大，但并不是每个人都使用语义化的版本，当我们开发一些便携式bundle的时候会使用到其他规范实体中的包，比如JCP。举例来说，如果你想编写的bundle要使用Servlet规范3.0之中的Servlet API，这里并没有明确定义这个API的包版本是什么，不同的应用服务器供应商会以不同的方式来实现它，并没有统一的便利方式，关于怎样做也没有形成有共识的方式，这是因为JCP有自己使用版本的方式并且稍微有所区别。正在制定的便携式协议的目标在于，使用来源于其他规范实体或其他组织的具备不同于语义化版本机制的API也能够便利地用于bundle的编写，我们依然能够知道在OSGi中如何以一种方便的方式，用特殊的版本来导入这些API。这就是它要真正解决的问题，因此借助它，这些OSGi之外的技术能够在OSGi上下文更为便利地使用。

   

11. 企业级OSGi规范将来会如何发展，下一个版本释放的时间安排是怎样的？

在较高的层面来讲，我们关注三件事，也就是云、Java EE集成以及一些已有规范的更新，我已经提到了其中的很多，另外一项正在日程上进行更新的是Blueprint，目前正在为其添加一些新的功能。下一个企业级释放版预计会在2014年初，虽然具体还不太确定，但这其中肯定会有包含一些新东西，目前还不能确定正在进行的这些规范会不会都包含进去。当然，我期望HttpService和CDI能够包含在里面，其他的一些规范可能还无法完成，有可能会在一年后释放。一般来讲，在年初会有释放培训，到目前为止我们都是每两年进行一次释放，不过我们可能在2014年释放一个版本，在2015年释放另一个版本。

Alex: David，非常感谢。

谢谢。