分类：Java

Translate: 深入了解Java社区进程

Java语言发展初期，Sun Microsystems公司清楚意识到：Java若想成功，必须由社区需求驱动起来。正因如此，Java社区进程（JCP）得以建立。时至今日，JAVA语言推出已有17个年头，而JCP也建设了14年。目前JCP仍然发展良好。

JCP执行委员会监管JCP及JCP驱动下Java技术本身的发展和演化。现在有两个执行委员会，分别面向Java SE/EE和Java ME，计划在未来两年合并。

每个执行委员一般会由16名成员构成，包括：技术提供商，如Oracle、IBM和诺基亚；技术使用者，如瑞士信贷和高盛投资公司；Java用户组，例如巴西和伦敦用户组；个人，例如Werner Keil。

参与JCP必须先成为执行委员会一员并签署Java规范参与协议（JSPA）（更多参与JCP的相关信息参考www.jcp.org/en/participation/membership）。JCP赋予个人、组织和公司成员主持或参与Java规范请求（JSR）的权利。JSR是JCP完善自身或在Java领域引入新技术的流程。例如：Java相关的JSR就包括JSR 335 （Lambda项目），JSR 310 （时间、日期API）， JSR 337(Java 8).以及上面提到的合并两个执行委员会的JSR 355。

执行委员会会议一般是月度会议。除了三次面向全球、自愿参与的面对面会议，大多数会议都采用电话会议形式。下次会议定于9月份在捷克共和国首都布拉格市由德国电信主持召开。详情可查看JCP会议完整的日程表 jcp.org/en/whatsnew/calendar。

这次月度会议是2012年7月31日。

Java ME执行委员会需要参加的会议较少，这可能是Java ME地位被削弱所致。究其原因，在于移动应用中iOS本地应用程序和基于Java的可替代它的Andorid等的影响日益提高。

随着会议不断召开，一些JSR目前的阶段是：

JSR 359 （SIP Servlet）：于昨天投票截至；

JSR 358 （Revisions to JCP）；7月份投票截至；

JSR 340 （Java Servlet 3.1 Spec）：进入初步草案审阅阶段；

JSR 341 （Expression Language 3.0 for JSP’s）；投票在今天开始；

JSR 355 （JCP EC Merge）：已经处于公开审阅阶段，最终草案已经制定，最终的表决投票将在今天开始。

2011年10月制定的JCP执行委员会成员规章V 2.1（The JCP EC Standing Rules 2.1）规定：出席的定义是成员出席面对面会议。规章同时也规定：如果一个成员连续两次缺席会议将失去选举权；12个月内连续缺席2/3的会议将取消成员资格。

SK电信和三星在最近8次会议中缺席了7次，已经达到上面规定提到的数量：12个月内10次会议的2/3。所以他们很可能失去成员资格。当然，JCP主管Patrick Curran可以法外开恩，但是目前来看没有什么理由如此。

Aplix的John Rizzo指出Oracle在Java Me执行委员会已经很久没有大作为。所以他们要承担部分责任，Patrick 同意把这个意见反映给Oracle。 美国电话电报公司（AT&T ）也快被取消会员资格，因为前8次会议只参加了2次。如果今年再缺席一次，资格就会不保。

鉴于打印机业务是Java ME的主要应用之一，所以有传言三星的打印机部门会被重新被纳入JCP成员。

经过JSR355合并两个委员会之后，一些成员资格将被取消，具体实施计划如下：

  • 今年将除去两个重复的席位 – Oracle 和 IBM；
  • 每个新成员仅服务一年；
  • 2013年，额外减少3个候选席位和2个批准席位，所有成员都要重新参与竞争；
  • 会员任期将从3年减至2年；
  • 因为不得不换届，投票在50%以上的将获得2年任期，50%以下的一年，50%的由随机数决定。

JCP年度奖也在讨论中，提名工作在这星期结束，年度奖分为三类：

  • 年度JCP成员
  • 规范杰出主持者
  • 最重要Java规范请求

获奖者名单将在2012年10月2日三番市召开的JavaOne会议上公布。JCP接下来几个月的重要主题是JSR358（“JCP主要修订”）。相比较 JSR355用来处理执行委员会合并事宜，JSR358致力于简化JCP，让JCP更易吸纳成员，简化主要针对的是JSPA。经常有很多抱怨指出JSPA 是一份充满威胁感的合法协议，以至于很多只是想自由参与其中的成员觉得荒谬而无法签字。值得一提的是，正因如此，Apache软件基金会（Apache Software Foundation ）和其他一些高级成员在几年前纷纷退出，详见 interview with Patrick Curran on InfoQ。

目前JCP有3个层次的成员：

  1. 自由参与者： 可能去修复一些少重现的Bug；
  2. 有选举权，但是不想参与主持规范的；
  3. 规范主持者。

相对应的，JSPA将被修改成三个文档：

  1. 面向自由在线贡献者的有关条款；
  2. 面向想拥有选举权、有权利为JSR专家组（EG）服务的简单会员协议；
  3. 面向规范者主持者的完整协议。

令人担心的是：假设JSAP协议条款太宽泛，一些大公司可能因为担心在知识产权上失去控制而不想参加；但是假设太严格。他们又会觉得受”威胁“。因此现在必须平衡好这个矛盾。

假设JSPA修订成功的被大众认可，我们将在InfoQ开辟专栏论述。下次JCP执行委员会会议将在2012年9月11-12日在捷克共和国布拉格采用面对面的方式进行。

原文链接：Inside the Java Community Process

Translate: CAMP1.0 – PaaS应用程序管理的开放API

 

包括Oracle、Rackspace、Red Hat 、CloudBees在内的几个公司提出了一个针对PaaS应用程序管理的开放API。这套API让开发者可以在单一PaaS内或多个不同的PaaS间管理应用应用程序。这些PaaS实现规范不需要了解任何底层的“云”架构。

CloudBees、 Cloudsoft Corporation、Huawei、Oracle、Rackspace、Red Hat和 Software AG 已经公布 一个新的PaaS 管理API，称为CAMP(Cloud Application Management for Platforms)。

它可以让云服务提供商或用户创建管理“云”中资源的应用程序。起初的想法来源于这样的观念：“云”用户不应该需要关心虚拟机、存储或网络等低层次资源，而应该能直接访问应用程序或其组件的高层次资源。同样，用户能够用统一的管理控制台访问不同供应商提供的PaaS服务并能在不同的“云”之间轻松地传输资源。

CAMP API的构建基于HTTP/1.1，采用RESTful方式并以JSON格式传输资源。它以插件形式提供给应用程序开发环境（ADE）或应用程序管理系统，以便于开发者通过应用程序开发环境在他们自己选择的“云”内创建、上传、部署、初始化自己的应用程序。

CAMP[PDF]定义了多种资源，包括平台、平台组件、应用程序、应用程序组件。虽然都是可以通过CAMP访问的资源，但有所区别，例如云平台是完整的PaaS，而平台组件则是各式各样的服务。目前CAMP仅定义了一种这样的服务称为DbaaS （Database-as-a-Service）。

作为主要资源之一的应用程序，CAMP为其提供了贯穿整个生命周期（描述如下）的操作接口：

初始化应用程序直接按照下面的请求-响应序列执行一个POST命令：

POST /paas/asm_template/1 HTTP/1.1
Host: example.org

HTTP/1.1 201 Created
Location: http://example.org/paas/assembly/1
Content-Type: ...
Content-Length: ...

而暂停一个应用程序或许可以按照下面示例：

POST /<assembly-resource-url> HTTP/1.1
Host: example.org
Content-Type: application/vnd.org.example.PaaS +json;type=Xxxxx
Content-Length: ...
{"new_state": "suspend"}
HTTP/1.1 200 OK

为标准化，CAMP已经被提交给OASIS，这其中包括一个关于技术委员会的提议章节，以期作为未来18个月内采用的标准。CAMP的构建中Oracle参与最多，14个规范中有7个规范的作者都是Oracle的。

查看英文原文：CAMP 1.0 – An Open API for PaaS Application Management