去年三月,2012EclipseCon / OSGi的开发者大会举行期间,第二届OSGi的云研讨会顺利举行。会上不乏好的演讲和讨论,可以在http://www.osgi.org/Design/Cloud找到相关信息。

据我们了解,人们已经在云计算环境中广泛使用OSGi,并且愿意花时间讨论可以做些什么使OSGi更适用于云。会上提出了许多问题相关问题汇总:https://mail.osgi.org/pipermail/cloud-workshop/2012-March/000112.html.

上周OSGi Enterprise和Residential专家组举行会议,讨论并寻找解决这些问题的潜在途径,你可以在接下来的内容中找到讨论结果。在这份列表中,我会依据之前发布在云讨论的邮件列表(cloud-workshop mailing list)内的需求开始每个主题。下面介绍最近参加EEG / REG会议的一些想法。

1.Topic: 能够描述各种不可用服务的状态。

一种服务在云中不可用,会有多种原因:

  • 也许因为今天调用的次数过多;
  • 也许你的信用卡过期了;
  • 也许节点运行服务崩溃了;
  • ……

它应该可以为这些不同的故障状态进行建模,并且可以注册callback(“回调”)机制,以便可以用适当的方式处理这些故障(黑名单服务,等待一段时间,发送电子邮件至信用卡持有人等)。

Follow up:一个围绕监控和管理的潜在RFP正在讨论中。Residential专家组正在讨论新的RFP,但最终它应对OSGi 运行的所有上下文产生作用。RFP的需求,可以解决这个topic中提到的一些服务质量问题。

此外,还讨论了是否有意义地扩展OSGi ServiceException,从而能够报错不同类型的服务故障(即支付需要,超出配额等)。

2.Topic: 应该能够快速部署和重新部署。

其中的一个要求就是需要在现有的框架(远程)远程运行测试套件。现在也有测试OSGi的框架支持这种行为(如Pax Exam, Arquillian and other),但他们可能需要云友好的远程部署/管理的解决方案,例如目前正在RFC 182讨论的基于REST的OSGi框架管理来完善。

2b. Topic: 有一个额外的用况是关于用来恢复在升级过程中产生的数据和配置更改。如果我们需要在升级后回到之前的版本,那么我们可能需要将数据转换/配置恢复到它之前的状态。

2b. Follow-up: 通过提供OSGi API对框架状态进行快照能实现这一目标。API可以使用户保存当前的状态,并检索过去保存的状态。恢复到以前的部署时,此操作可以结合一个可插拔的修正过程将数据恢复(如果适用)。
在即将创建的新的RFP中,将探讨关于快照框架状态的想法。数据修正过程本身很有可能超出 OSGi 的范围。

3.Topic:拿出一个通用的架构用于开发。

这应该包括远程服务,远程事件和分布式配置管理的考虑。

Follow-up: 这是新RFC 183中云发现的话题。

4.Topic:资源利用率。

应该有可能为每个云节点测量/报告资源利用率,包括可用的线程数,内存量,功耗等...很有可能为此创建OSGi功能命名空间。

Follow-up: 这涉及到RFP上面提到的监控。

5.OBR Scaling。

可以在一个高度可用的方式使用OBR。应支持故障转移。

Follow-up: OSGi企业R5规范第132章(见下载http://www.osgi.org/News/20120326的最新草案的说明)中定义的资源库服务提供了一个无状态的API,它可以与知名的HA解决方案(复制,故障转移等)协作。此外,该库支持 referrals的概念,允许多台,联合库被合并成一个单一的逻辑视图。

6.Topic:我们需要跨框架的子系统。

可以把它们称为“生态系统”。描述可以在不同框架上部署的子系统。

Follow-up: 尽管其有用性没有争议,但是也没有人及时的提出这点。如果人们强烈地感受到这个问题必须予以解决,他们应该挺身而出帮助定义解决方案来解决这个问题。

7.Topic:异步服务和异步远程服务

Follow-up: 这是RFP 132最近重新启动的主题。 RFP 132是纯粹的异步OSGi服务。一旦建立,异步远程服务可以作为一个顶层建模。

8.Topic:应用的隔离和安全性

  • 多组织应用
  • 保护对文件系统的访问
  • 应用程序的生命周期处理
  • 隔离的OBR (多个组织不应看到对方的OBR)
    这些都需要可配置。

Follow-up: 显然,单独的虚拟机提供最佳的隔离,单独JavaVMs在一个单一的OS-level VM也提供了相当强大的隔离(但是,要知道本机代码和资源可能会耗尽,出现副作用)。嵌套的OSGi框架和子系统区域也提供了一定程度的隔离(参见Graham的子系统),但需要的保护级别,依赖于给定的应用的安全性需求。部署者可以从这些选项中选择作为部署bundle和/或子系统的目标。

9.Topic:应该可以查看看云系统状态:

  • 我在哪里 (云的类型,地理位置)?
  • 节点和它们的状态是什么?
  • 什么框架在云系统时可用的?
  • 我的OBR在哪里?
  • 我的状态是什么?
  • 需要做些什么在这里开展业务?
  • 其他…

Follow-up: 这是在RFC 183云调查中讨论的问题的一部分。

10.Topic:在云中的使用管理机制

  • JMX?不可能;
  • REST? 有可能

除了bundle/框架状态之外,应用程序管理的状态也应当是可能的。

Follow-up: 基于REST的云友好的管理API正应用在RFC 182REST。一旦建立,也可形成子系统的管理技术的基线,可用于应用级的管理。

11.Topic:部署。

部署重复的节点时,应尽可能指定副本不应部署在某些节点,以避免所有副本都部署在同一节点上。

Follow-up: 这也涉及到RFC 183中的讨论。管理代理可以使用此信息来执行这样的约束。

12.Topic:单点登录的OSGi

Follow-up: 某一成员公司已基于用户管理服务完成了与此有关的项目。将创建一个新的RFP进一步讨论需求。

There You Are

云计算研讨会的想法值得赞赏,并为今后的工作提供了方向。如果您有兴趣参与,像往常一样,我们计划定期推出比较成熟草案。或者,如果你有兴趣参加这些规范的创建,加入我们吧!欲了解更多信息,请参见: http://www.osgi.org/About/Join或与我联系(David在redhat.com )或其他任何人获取在OSGi的更多信息。(出自 OSGi Alliance Blog,2012年5月2日)
查看英文原文:http://blog.osgi.org/2012/05/follow-up-on-2nd-cloud-workshop.html


wmz 2015-05-15 09:28

OSGi在线演示平台,http://osgi.jxtech.net

顶(1) 踩(0) 回复

最受欢迎的文章

最新评论