JSR-313 for J2EE 6.0 received a setback (temporary)

An effort to standardize the next version of J2EE (6) as JSR-313 received a “temporary” setback at JCP, mainly due to licensing concerns. (Just to re-iterate my disclaimer: opinion/observations expressed in this blog are my own personal and does not necessarily reflect my employer’s views.)

A review ballot for JSR-313 was filed on April 3rd and was to be approved on April 16th. However, it was withdrawn on Friday the 13th!

From a sequence of events, I see interesting coincidences.

On April 10th, ASF sent an open letter to Sun over licensing issues related to J2SE 5.0. ASF has completed almost 95% compatible implementation and wanted to TCK license. However, the efforts failed to get mutually acceptable resolution. Hence, ASF went public with an open letter.

Though it is hard to establish the influence of the open letter on the fate of JSR-311. It might be more than a mere coincidence that ASF sent this open letter in the time window when this JSR was filled. More interesting coincidence is the comments concerning the licensing terms were expressed around the day when the letter went to a public. The letter created awareness and expressed the concerns of many others.

Anyway, since the next version on J2EE is an inevitable thing, I was told by the specifications leads that the JSR will be resubmitted after alienating the licensing concerns. J2EE6.0 would continue a Java's momentum to provide various SOA artifacts. This JSR specifically mentions that it would consider SCA artifacts. However did not mention JSR-235 or SDO. As you may know that JSR-235 was also withdrawn (by BEA and IBM) due to licensing issues. I understand that the SDO specification is also going to be resubmitted. I hope that it would also get added in this JSR.

The JSR proposes to include the following new JSRs:
* JSR-196 Java Authentication SPI for Containers
* JSR-236 Timer for Application Servers
* JSR-237 Work Manager for Application Servers
* JSR-299 Web Beans
* JSR-311 JAX-RS: Java API for RESTful Web Services

Other than these JSRs, there are some impacts on JAX-WS and JBI specifications too.

1. JSR-313 filing
http://jcp.org/en/jsr/detail?id=313

2. Comments and votes on JSR-313
http://jcp.org/en/jsr/results?id=4216

3. Open letter from ASF
http://www.apache.org/jcp/sunopenletter.html

4. ASF FAQ
http://www.apache.org/jcp/sunopenletterfaq.html

JSR-311 Java API for REST approved ballot after a Mixed reactions from developers:

JSR proposal http://jcp.org/en/jsr/detail?id=311


JCP formed a JSR expert group to publish an API for RESTful services. JSR-311 is in ballot review period in this month (till Feb 26). Software companies like Apache, BEA, Google,JBoss and Sun Microsystems are on the board. Individuals like Jerom Louvel (RESTlet framework) and Douge Lea are also on board of it. However, according to others, Roy Fielding whose dissertations documented the REST pattern, seems to be unhappy about Sun using REST as a name.

According to this request, this JSR intends to provide a high level easy to use API for developers to write RESTful web services that would run on top of the Java EE or the Java SE platforms. The JSR would provide API with declarative style of programming using annotations for developers. It would also enable low level access in cases where needed by the application.

Sun's lead on this specification, Marc Hadley, outlined following conceptual model:

@UriTemplate("widgets/{widgetid}")
@ConsumeMime("application/widgets+xml")
@ProduceMime("application/widgets+xml")
public class Widget {

@HttpMethod(GET)
public Representation getWidget(@UriParam("widgetid") String id) {
String replyStr = getWidgetAsXml(id);
return new StringRepresentation(replyStr,
"application/widgets+xml");
}

@HttpMethod(PUT)
public void updateWidget(@UriParam("widgetid") String id,
Representation update) {
updateWidgetFromXml(id, update);
}

@LastModified
public Date getChangeDate(@UriParam("widgetid") String id) {
return getLastChanged(id);
}
}

Interestingly, the JSR furthers states " The specification will define
how RESTful services are deployed as JAX-WS (Java API for XML Web
Services) endpoints or Servlets."  The API will be packaged as javax.ws.rest.
I assume there could be WSDL representation of this using HTTP binding type defined in WSDL1.1 where
get,put, post etc can be captured as "verb" e.g. http:binding verb="GET

While REST based services may fit into a broader definition of webservices, a SOAP centric RPC styled
definition of Webservices is not suitable for RESTful services. Following page
compares SOAP and REST.
http://rest.blueoxen.net/cgi-bin/wiki.pl?HowSoapComparesToRest

Anyway, a comment suggesting a direction of using JAX-WS and a reference to "DL based on annotations" has stirred the developers
community. Particularly on a background where WS vs REST battle is still not yet completely
settled.

W3Consortium has published a presentation on reconciling Webservices and REST.
http://www.w3.org/2005/Talks/1115-hh-k-ecows/#(1)



(Unofficial)Develoeprs Polls at
http://java.net/pub/pq/146 as of Feb 25th
Approve 126  34%
Disapprove 67  17%
no opinion 99  25%
wait and see 95 24%
other 7

Latest News: The JSR 
The Executive Committee for SE/EE has  approved this ballot.

http://jcp.org/en/jsr/results?id=4168

The next (tentative schedule)schedule:

February 2007	Expert group formed
June 2007	First expert draft
August 2007	Early Draft review
November 2007	Public Review
January 2008	Proposed final draft
March 2008	Final release.

Refereces:
1. JSR-311: http://jcp.org/en/jsr/detail?id=311
2. JAX-WS: http://java.sun.com/webservices/jaxws/
3. Restlest API: http://www.restlet.org/tutorial
4. Marc Hadley http://weblogs.java.net/blog/mhadley/
5. W3c on WS and REST: http://www.w3.org/2005/Talks/1115-hh-k-ecows/#(1)
6. SOAP and REST: http://rest.blueoxen.net/cgi-bin/wiki.pl?HowSoapComparesToRest

REST

JSR-311