OpenShift is a Platform As A Service (Paas) offering from Red Hat joining the likes of Heroku, GAE, Jelastic and others. OpenShift supports Java EE, PHP, Node.js, Ruby, Python and Perl applications. I tried out deploying a simple Java EE application based on ZK Framework, interested people can have a look at the application running live here.

This article would cover:

• Setting up of OpenShift account, Maven and creating an application on cloud
• Developing and deploying the application on cloud

Setting up OpenShift Account, Creating application

First step to setting up of application is to create an account on the OpenShift website here. Once you have registered, you have to download and install the Command line tool for OpenShift cloud control which is Redhat Console(rhc). I used the Ruby gems to install the RHC tool which is as simple as:

$ sudo gem install rhc

Creating a domain and application

All the applications deployed on OpenShift are in a namespace which is nothing but the domain you create. Domain names have to be unique and are part of the URL to access the application.

#Creating a domain
$ rhc domain create -l <login> -n <domain name>
Password: <password>

Once the domain has been successfully created, the next step is to create an application:

#Creating an application
$rhc app create -a <application_name> -l <loginname> -t jbossas-7.0

-t option is used to specify the type of the application, which can be any one of the following:
php-5.3 — for PHP applications
wsgi-3.2 — for Web Server Gateway Interface applications
rack-1.1 — for Ruby Webserver Interface applications
perl-5.10 — for Perl applications
jbossas-7.0 — for JBoss AS applications (used for ZK project)
raw-0.1 — a raw cartridge type used to create applications of no specific type

A Cartridge is the other infrastructure elements that your application would use and these can be added using the same rhc app command. In our application we would not be using any of those and hence not being added.

The same operations can be performed from their web console as well. An advantage of using the command line is that once you create an domain using rhc command line, it adds the necessary ssh-keys, and also while creating the application it sets up the git repository as well. Deploying to OpenShift is as simple and pushing the application to the remote git repository, this is similar to the approach in Heroku.

Setting up Maven

The application is nothing but an Maven project. So if you are interested to run the application locally then you need to setup Maven as well. Download the Maven package from here, and setup the M2_HOME environment variable to the Maven home i.e the folder where the Maven package was extracted and also update the PATH variable to the M2_HOME/bin.

$mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 14:14:56+0530)
Maven home: /home/mohamed/maven
Java version: 1.7.0, vendor: Oracle Corporation
Java home: /home/mohamed/jdk1.7.0/jre

Developing and Deploying the Application

We would be using ZK framework for our sample application. The application reads from a JSON source about the Marathon Events in India and plots them on a Google Map. For reading the JSON source we would be using the GSON library.
We have to update the contents of pom.xml to reflect the ZK, GSON and other dependencies. One can even use Eclipse to develop the application and that is exactly what I did:

$ mvn eclipse:eclipse

and then load the project in eclipse. Also Eclipse should be able to resolve the libraries used in the application i.e all the ZK jars and the GSON jar. If you find any issue where eclipse complains about not finding the jars, then you must add a variable M2_REPO to Eclipse environment variables which would point to the directory where Maven downloads all the jars.
The JSON source for the marathon events is constructed from the details available on RunInfinity website.

There are few things to be done to plot the above data on a map:
1. Construct Gmarker data from the above data.
2. Obtain the Latitude and Longitude data from the location information. For this we make use of the Google Geocoding API.

The Model which holds the Marathon event information is:

public class MarathonEvent {
  @SerializedName("event_url")
  String url;
  String name;
  String date;
  String location;
  Location geoLocation;
  String formattedContent;
  @Override
  public String toString(){
    if ( formattedContent == null ){
      StringBuilder builder = new StringBuilder();
      builder.append("Date: "+date);
      builder.append("<br/>");
      builder.append("<a href=\""+url+"\">"+name+"</a>");
      builder.append("<br/>");
      builder.append(geoLocation.name);
      formattedContent = builder.toString();  
    }
    return formattedContent;
  }
}

Parsing the JSON source for Marathon Events list where the JSON source is marathon_events.json:

InputStream marathonEvenJsonSource = 
    getClass().getResourceAsStream("marathon_events.json");

Gson gson = new Gson();

JsonReader jsonReader = new JsonReader(
    new InputStreamReader(marathonEvenJsonSource));

JsonParser jsonParser = new JsonParser();

JsonArray jsonArray = jsonParser.parse(jsonReader).getAsJsonArray();

for ( JsonElement element : jsonArray){
  MarathonEvent marathonEvent = 
      gson.fromJson(element, MarathonEvent.class);
  marathonEvent.geoLocation = getGeoCode(marathonEvent.location);

  Gmarker gmarker = new Gmarker(marathonEvent.location,
      marathonEvent.geoLocation.latitude,
      marathonEvent.geoLocation.longitude);
  gmarker.setContent(marathonEvent.toString());
  
  marathonEvents.add(gmarker);
}

if you are not able to follow the JSON parsing code, please read our previous article regarding the same here.

The interesting part here is the getGeoCode(marathonEvent.location) call which is defined as:

public Location getGeoCode(String location) 
    throws MalformedURLException, IOException{
  String url = 
    "http://maps.googleapis.com/maps/api/geocode/json?address="+URLEncoder.encode(location, "UTF-8")+"&sensor=false";
  Location geoLocation = new Location(location);
  Gson gson = new Gson();
  InputStream in = new URL(url).openStream();
  JsonReader reader = new JsonReader(new InputStreamReader(in));
  JsonParser parser = new JsonParser();
  JsonObject jsonObject = parser.parse(reader).getAsJsonObject();
  //Fetch all the possible latitude/longitude results for this place
  JsonArray resultsArray = jsonObject.getAsJsonArray("results");
  
  if ( resultsArray.size() > 0 ){
    //Generally there's only one result, so pick the first. 
    JsonObject geoInformation = 
        resultsArray.get(0).getAsJsonObject();
    String formattedAddress = 
        geoInformation.get("formatted_address").getAsString();
    JsonObject locationJsonObj= 
      geoInformation.get("geometry")
                    .getAsJsonObject()
                    .get("location")
                    .getAsJsonObject();
    String latitude  = locationJsonObj.get("lat").getAsString();
    String longitude = locationJsonObj.get("lng").getAsString();
    geoLocation.latitude = Double.parseDouble(latitude);
    geoLocation.longitude = Double.parseDouble(longitude);
    geoLocation.name = formattedAddress;
  }
  return geoLocation;
}

The above code parses the JSON response obtained from the Google Places API and retrieves the formatted_address field and the latitude(lat) and longitude(lng) values. Here as well the GSON Library is used for parsing. The above two code snippets are part of the MarathonEventsSource class which is our source for model information to the views.

Now lets create a ZK based View and Controller/View Model class.

ZK Based View

<zk>
  <script type="text/javascript" 
  content="zk.googleAPIkey='AIzaSyAgYZVjw15TQWGxAMFv0ayA8OlAtVFkyx0'" />
  <window id="main" width="100%" height="100%" apply="net.javabeat.MarathonHomeComposer">
    <borderlayout>
      <north size="70px">
        <div>
        <html><![CDATA[
        <h2 style="color:#0C7A9A;margin-left:10px">Marathon Events in India</h2>
        ]]></html>
        </div>
      </north>
      <center flex="true">
        <div id="contentDiv" >
          <gmaps id="eventsMap" width="100%" height="100%" showSmallCtrl="true">
          <attribute name="onMapClick"><![CDATA[
          org.zkoss.gmaps.Gmarker gmarker = event.getGmarker();
          if (gmarker != null)
            gmarker.setOpen(true);
          ]]></attribute>
          </gmaps>
        </div>
      </center>
      <south size="20px">
        <hbox pack="center" width="100%">
        <html><![CDATA[
        <span style="color:#0C7A9A">Developed by Mohamed Sanaulla</span>
        ]]></html>
        </hbox>
      </south>
    </borderlayout>
  </window>
</zk>

Interesting pieces from the above code:
1. ZK provides different layouts for organising the contents and BorderLayout is one such layout. In this the content can be organized into 4 regions (exactly similar supported by Swing).
2. Gmaps is the component for embedding the Google Maps.
3. Each view can be backed a View Model class by using the apply attribute of window component apply="net.javabeat.MarathonHomeComposer"

Lets have a look at the MarathonHomeComposer class which is the View Model/Controller class.

public class MarathonHomeComposer extends GenericForwardComposer{

  MapModel mapModel;
  Gmaps eventsMap;
  Div contentDiv;

  public MarathonHomeComposer() 
      throws MalformedURLException, IOException{
    String marathonEventScheduleSource = 
      "http://runinfinity.com/calendar/india-marathon-calendar";
    MarathonEventsSource marathonEventsSource = 
        new MarathonEventsSource();
    List<Gmarker> marathonEvents = 
        marathonEventsSource.getMarathonEvents();	
    mapModel = new MapModelList(marathonEvents);

  }
  public void doAfterCompose(Component comp) throws Exception {
    super.doAfterCompose(comp);		
    eventsMap.setModel(mapModel);
    eventsMap.setZoom(9);
  }
}

Few observations from the View Model class:
1. It extends the GenericForwardComposer class which supports binding of the components between the View and the View Model based on the ids. For example- gmaps component has an id=”eventsMap” and the View Model MarathonHomeComposer class has an instance field by name: eventsMap. This is an easier way of binding the UI element to the Java layer, the other ways can be by using Annotations.
2. The model for the Gmaps is MapModel which is constructed using the MapModelList and the List obtained from the JSON parser (MarathonEventsSource class)
3. doAfterCompose method would have all the components (read Gmaps) initialized and hence we set the model in this method.

If you are interested in the source of this application, you can get it from the git repo here.

Deploying the application to OpenShift

As I said earlier, deploying the application is as simple as running git push command. If you run:

$ git remote -v
origin	ssh://ad221d298243438491c77f9cd9a83206@marathons-mylearning.rhcloud.com/~/git/marathons.git/ (fetch)
origin	ssh://ad221d298243438491c77f9cd9a83206@marathons-mylearning.rhcloud.com/~/git/marathons.git/ (push)

The remote named origin points to the git repo in the cloud. Deploying the application to OpenShift platform:

$ git push origin
# other output
remote: [INFO] BUILD SUCCESS
remote: [INFO] -------------------------------------------------
remote: [INFO] Total time: 30.888s
remote: [INFO] Finished at: Tue May 29 12:24:43 EDT 2012
remote: [INFO] Final Memory: 11M/111M
remote: [INFO] -------------------------------------------------
#other output

Once you have deployed the application, you can access the application by visting: http://-.rhcloud.com/marathonHome.zul

Let me summarize this huge post into:
1. Constructing the Model source for the Map- this involves reading the JSON source, obtaining the latitude and longitude information and then constructing the Gmarker objects.
2. Construct the view- marathonHome.zul which has the gmaps component.
3. Wire the View with the View Model class and also wire up the gmaps component with the model.

This sample application can be accessed here.

Some of the useful resources for this sample:
1. Gmaps Java documentation.
2. ZK Components Java Documentation.
3. ZK Live Demo.
4. Google Geocoding API
5. OpenShift Developer Resources.
6. Git Repository in GitHub.

This article presents what is new in the Java EE 6.0 edition. There is lot of new activities in the JCP expert groups to add more valuable features in Java EE 6.0 version. Roberto Chinnici and Bill Shannon are Spec Leads for the JSR 316. For the past two releases of Java EE versions, sun is focusing on making the environment more easier for the developers instead of adding more new technologies.

For example, EJB 2.x is more difficult for the developers particularly the Entity Beans part in the EJB, then it has simplified the EJB 3.0 programming model in Java EE 5.0 by extensive use of annotations and introduced JPA 1.0 to reduce the complexitiy on persistance layer. The same approach continues in the Java EE 6.0 version also, they define it in the two topics namingly Extensibility and Profiles. Writing about all the changes in one article would become lengthy, so we will see some of the notable changes in this article like Profiles, Modularity and focus on Web tier.

also read:

• J2EE Books
• Servlets interview questions
• Annotations in Java 5.0

2.New Features in JEE 6.0

Before looking into the details of the features, lets list what are the new things to be added in the Java EE 6.0. This section will list only the outline of the features with few lines of explanations. As we have already stated, the main goal of this release is ease of development and provide support for the third party frameworks. The new things in 6.0 is, adding new capabilities like Profiles, improving the technology like using annotations instead of XML in most of the technologies(Servlets 3.0, JPA 2.0) and removing the features (EJB’s CMP) which is not widely used by the developers. As rod Lets jump into the features list:

2.1.Servlets 3.0

One of the major release in the Java EE 6.0 is the new version on Servlet technology which is given more attention by the community. The new version uses annotations to declare the servlets and making the deployment descriptos optional. Apart from using the annotations, as a whole the specification more focued on simplifying the web tier technologies. From Servlets 3.0 it is not required to changed web.xml for adding the third party libraries like Struts, Spring, JSF, etc. Servlets 3.0 introdues Web Fragments descriptor to specify the details of each libraries which is used by the container. This is one of welcome feature to the web developers since most of them finding hard to integrate the frameworks. There is more detailed article on New Features in Servlets 3.0 written by Christy. This article will give you more insight on the features. Please read on.

2.2.Web Beans 1.0

The problem with the Java EE edition is, the presentation layers(Servlets, JSP and JSF) and persistance layers(EJB 3.0, JTA, JCA and JPA) are grown seperatly without much closer interactions. There is no common technology to integrate the both web tier and the persistance tier. Web Beans main goal is to address this issue by defining beans which can be interacted by multiple tiers. Web Beans will be compatiable with technologies in the both tiers. Web Beans is influenced by the popular frameworks Google Guice and JBoss Seam. There is more detailed article on Web Beans and its Features.

2.3.JPA 2.0

Java Persistance API (JPA 1.0) is released in with the Java EE 5.0 edition on May 2006. JPA is one of the crucial technology for the Java platform to develope more flexible and simplified database applications. In the earlier days EJB CMP considered as more complex to develope database applications. So, sun has introdued JPA 1.0 with EJB 3.0 technology.

An excerpt from the JSR 317 says “including additional object/relational mapping functionality and query language capabilities, a criteria-based query API, and standardization of features currently designated as optional, and to align it with related JSRs that are currently in-process and/on in-plan for the Java EE 6 timeframe.”. The following are the features may be included in the JPA 2.0 version:

• Expanded object/relational mapping functionality, including greater flexibility in combining existing mapping options, support for collections of embedded objects, multiple levels of embedded objects, ordered lists, combinations of access types, etc.
• Additions to the Java Persistence query language
• An API for “criteria” queries
• Standardization of sets of “hints” for query configuration and for entity manager configuration
• Standardization of additional metadata to support DDL generation and “Java2DB” mapping
• Expanded pluggability contracts to support efficient passivation and replication of extended persistence contexts in Java EE environments
• Standardization of additional contracts for entity detachment and merge, and persistence context management
• Support for validation

2.4.JSF 2.0

JSF 2.0 promises to ring lot of new developments to the web application. They classify the changes in this release as Ease of Development, New Features and Fixes, Performance, Technology Adoption. There will be bunch of annotations to be used in the JSF 2.0 and try to avoid use of faces-config.xml and web.xml. Everything can be done through annotations how Servlets 3.0 has done.

The specification provides lots of new features like expand the request processing life cycle to be aware of Ajax, allow for bookmark able JSF pages, provide a mechanism to easily access persistent store.

2.5.Other Features in Java EE 6.0

The mentioned features are the major changes in the new release. Apart from these major changes, there is lot of small changes in the technology. Look into the list of new JSR’s:

• 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

In the next section I explain about the another new features Profiles and how to pruning the features in Java EE specifications.

3.Profiles in Java EE 6.0

Profiles feature is major new feature in the Java EE 6.0 environment. It brought lot of controversies on its addition to the Java EE. The main goal of the Profiles is to reduce the size of the environment when it is not required. In the existing environment, what ever the small applications you are going to write about, it will come with all the pre existing technologies in the environment. The developer may not intend to use all the technologies provided by the vendor even though he has to adhere everything in one shot. To avoid this situation, Java EE expert group come up with Profiles.

Profiles are designed for a particular solution or a specific requirement. For example, you are developing a web project where you are required to use only JSF and JPA. In this case adding all the capabilities not needed and its more expensive. In this case you can use specific profile which suits for the web applications development. This is the basic idea behind designing Profiles into Java EE. As of now Java EE 6.0 specification includes only Web Profiles and there is no other profiles defined either. In the future version we can expect more profiles based on the feedback from the community members.

In the initial Java EE 6.0, there will be only Web Profiles added to the platform. Still the technologies to be used for the Web Profiles are not decided. The discussion is under way to make the conclusion. Roberto Chinnici, the spech lead for Java EE 6.0 blogged about the possible two options for the Web Profiles. He categorised it as the profile A and profile B.
The below table lists all the technologies in both the profiles:

Still the technologies are not finalized by the committee. This feature itself brought lots of discussions on the blogs about its pros and cons. Those who are against this features argues that giving extra on the server doesn’t harm the developer, also providing many profiles will confuse the developers to choose the right profiles for their applications and also it will end up in compatibility issues if they could not choose the correct profiles. We have to wait and see the implementation for the Web Profiles.

4.Pruning the Features

In the past releases, none of the features has been completely removed from the specification. This become drawback for the SDK in terms of size and the installation time. So, the experts comitee decided to remove the features from the specification if the
feature is not widely used by the developers or any alternatives available for the same feature. Here the removal may not happen
immediately since it might break the past releases. The removal process will go through several steps before it is completely removed.

It is performed in the multistep process where a feature is declared in one release may be moved as optional component in the next release. The JSR has few proposals for initial pruning of features. The two suggested proposals are JAX-RPC and EJB CMP.Here JAX-RPC is replaced by the JAX-WS and EJB CMP is replaced by JPA with more simplified manner.

also read:

• J2EE Books
• Servlets interview questions
• Annotations in Java 5.0

5.Summary

In this article I have explained what are the new features in Java EE 6.0. This is only the introduction article and there is lot of changes are coming in Java EE 6.0 version. keep watching the section, we will publish more articles on the different topics. The notable changes in the Java EE 6.0 version is Servlets 3.0, Web Beans 1.0 and the Profiles. Apart from these three improvements, lot of small changes in the new version.