GIDS.Java

Day 3 of the Great Indian Developer Summit had its key focus on Java, and Enterprise applications. The conference saw a sea of delegates from the major IT companies all around Bangalore. The usually quaint and quiet premises of IISc was today beaming with techies and nerds noisily discussing their favorite programming language or tool. Age was no bar here. The gray haired were as much (if not more!) geeky as the college pass-outs (or drop-outs!). Organized by Devmarch, the conference had the likes of Microsoft, Yahoo!, IBM, Adobe, Red Hat, Intel for its sponsors.

The attendees had various things to choose from. There were sessions conducted by leading speakers in the industry. There were expos hosted by the sponsors. There were workshops; after all what's programming without some hands-on! And of course there was a lot of opportunity and scope for networking with the speakers and attendees.

Sessions for the day were grouped in five parallel tracks. They dealt with the key technologies like cloud computing, RESTful web services, Ruby on Rails, Groovy, Agile development and Ajax in addition to Java of course.

Craig McClanahan, the creator of Struts started off the morning session with an insightful talk on Cloud Computing. It means different things for different people. For some it is Software as a service, for some it's virtualization, for a few it is utility computing, grid computing, and for others it is application hosting platform. Truth is that it is a combination of all these and more and has created a lot of buzz amongst the enterprises and developers alike. What's driving their interest is the low cost and agile business model that the cloud promises to achieve. The pay as you go economic model, the rapid, self provisioning and API driven development model and the flexibility offered through standard, elastic, on-demand services is attractive to one and all. There are many clouds out there and Craig spoke about what they all share and what they don't. He also highlighted the three layers in cloud computing - Software as a service (SaaS), Platform as a service (PaaS) and Infrastructure as a service (IaaS) from top to bottom. These are the primary areas where the vendors are focusing be it Amazon Web services and EC2 or Google App Engine or Salesforce.com. At closing he introduced the upcoming cloud platform of Sun (or Oracle!) and hinted on the announcement of the Sun storage and compute services at JavaOne (shhhh!).

Jim Webber, author of "Developing Enterprise Applications - Architect's guide" conducted an engaging session on Introducing REST - the Starbucks example. He used the Starbucks coffee shop example to drive home the RESTful paradigm of web services. He started off with the Richardson Maturity Model - a model of technologies stacked up based on the level to which they embrace the web. The stack has the traditional RPC at its peak and then moves down to technologies that use URIs, web services and finally to REST that completely embraces web. REST is all about resources, their states and how they can be accessed with URIs. It's quite hard to believe that what was always there around us (meaning the web) eluded us all with it's power and scalability. While we focused all the energies on building middleware to support the integration, scalability, security and other "abilities", it was all already there in the form of the web. Jim talked about the HTTP implementation of REST, the CRUD operations using the POST, GET, PUT and DELETE verbs, and how HTTP supports metadata in its header. He also stressed on the microformats and media types that are again intrinsic to a RESTful implementation. Jim's humor, the informal style of presentation and animated hand waving was very well taken by the audience. Needless to say that it kept them all engaged and on the edge of their seats!

Last session for the day was one on testing Java with JRuby. It was delivered by another Thoughtworker Ola Bini [Ola Bini blogs]. Now this was a very interesting topic. All the more for me as I had been thinking about this for some time now. Since the dynamic languages are known and used for stitching components, using them for testing is a natural extension. Especially when one has to come up with the test code quickly (which is usually the case), JRuby can be of great help. And its many gems provide added capability for avoiding repetition, and for writing plain text stories and scenarios. Bini kept shuffling between the presentation and demos and did complete justice to the topic.

Kudos to the organizing team. With over 3000 attendees at the conference, the logistics was well handled. The sessions were well timed and but for a couple of changes to the agenda, all the others started and got over on time. The only grouse was the long queues and crowd at the dining area; some arrangement there would have helped. And did I say that the food was awesome! :)

~Ashish

REST explained

Came across this funny yet revealing post of this guy explaining REST to his wife. It's simplistic and comprehensive starter on all that is REST.

REST to my wife

~Ashish

XML generation using SAXTransformer in Java JDK

XML generation is a common found requirement in applications. Typical way to address it in java is to manually append the XML string in a StringBuffer. Firstly this can be quite tedious. Secondly it is susceptible to manual errors while writing the XML. Also, the developer needs to take care of the escape characters etc. Clearly this is not the best way of XML generation in Java.
A better way of achieving this is to use the classes in javax.xml.transform package of JDK. These are traditionally used for XML parsing and transformations. Their use of XML generation is uncommon and unobvious. here's a code snippet that shows how these classes can be used for XML generation:

SAXTransformerFactory saxFactory = (SAXTransformerFactory) TransformerFactory.newInstance();
StringWriter writer = new StringWriter();
try {
TransformerHandler handler = saxFactory.newTransformerHandler();
Result result = new StreamResult(writer);
handler.setResult(result);
handler.startDocument();
AttributesImpl atts = new AttributesImpl();
atts.addAttribute("", "", "name", "CDATA", "");
atts.addAttribute("", "", "version", "CDATA", "6.2");
handler.startElement("http://wbe.ibm.com/6.2/Event/connect", "","connector", atts);
atts.clear();
atts.addAttribute("", "", "name", "CDATA", "connect");
atts.addAttribute("", "", "type", "CDATA", "Event");
handler.startElement("", "", "connector-bundle", atts);
atts.clear();
handler.startElement("", "", "connect", atts);
String paramValue = null;
for (ScenarioParameter param : scenarioParams) {
atts.clear();
atts.addAttribute("", "", "type", "CDATA", param.getType());
handler.startElement("", "", param.getName(), atts);
paramValue = getParamValue(param.getParamId(), params);
handler.characters(paramValue.toCharArray(), 0, paramValue.length());
handler.endElement("", "", param.getName());
}
handler.endElement("", "", "connect");
handler.endElement("", "", "connector-bundle");
atts.clear();
handler.startElement("", "", "system", atts);
String systemName = InetAddress.getLocalHost().getHostName();
handler.characters(systemName.toCharArray(), 0, systemName.length());
handler.endElement("", "", "system");
handler.startElement("", "", "timestamp", atts);
String timestamp = new Date().toString();
handler.characters(timestamp.toCharArray(), 0, timestamp.length());
handler.endElement("", "", "timestamp");
handler.startElement("", "", "loginfo", atts);
String logMsg = "Sending values at runtime";
handler.characters(logMsg.toCharArray(), 0, logMsg.length());
handler.endElement("", "", "loginfo");
handler.endElement("", "", "connector");
handler.endDocument();

System.out.println(writer.toString());

TransformerHandler listens for XML parse events and transforms them to Result. Since we are not using it for parsing, here the handler generates those events like startDocument, startElement and transforms them into Result. The Result thus contains the XML that we wanted to generate. Note that it is the developer's responsibility to take care of the well formedness of the XML. A startElement has to have a matching endElement and a startDocument has to have a matching endDocument.

~Ashish.

Dynamic EJB lookup using Java Reflection

Applications often need to lookup resources based on their JNDI names. The lookup code can be made short and dynamic using Java reflection.
In my application there was a need to lookup an EJB. The JNDI name was dependent on the value of a constant (called cepengine). This is how I implemented the lookup.
I wrote a constants file (constants.properties) with these entries:

cepengine=wbe
eventdefinition.bean.jndi=ejb/com/ibm/eventmanagement/eventdefinition/EventDefinitionServiceHome
eventdefinition.wbe.bean.jndi=ejb/com/ibm/eventmanagement/eventdefinition/wbe/WBEEventDefinitionServiceHome
eventdefinition.bean.home.wbe=com.ibm.eventmanagement.eventdefinition.wbe.WBEEventDefinitionServiceHome
eventdefinition.bean.home=com.ibm.eventmanagement.eventdefinition.EventDefinitionServiceHome

I then wrapped this up with a java class (PropertyLoader.java) with methods to return the various values in the properties file. For instance here is the method that returns the JNDI name:

public String getEventDefinitionServiceJNDI() {
String cepEngine = getCEPEngine();
String constStr = null;
if (cepEngine != null && !cepEngine.equalsIgnoreCase("")) {
constStr = "eventdefinition." + getCEPEngine() + ".bean.jndi";
} else {
constStr = "eventdefinition.bean.jndi";
}
return bundle.getString(constStr);
}

Similarly there is a method that returns the name of the home interface class.

Next I implemented the lookup code using the ServiceLocator pattern in a class aptly named ServiceLocator.java. Here's the code snippet that looks up the home interface object and creates the bean object:

private Object locateEJBHome(String jndi, Class homeClass)
throws ClassCastException, NamingException {
Object ejbHome = ejbHomeObjects.get(homeClass);
if (ejbHome == null) {
ejbHome = PortableRemoteObject.narrow(getInitialContext().lookup(jndi), homeClass);
ejbHomeObjects.put(homeClass, ejbHome);
}
return ejbHome;
}

public EventDefinitionService getEventDefinitionService() {
EventDefinitionService facade = null;
Object facadeHome = null;
PropertyLoader propLoader = new PropertyLoader();
String eventDefHomeName = propLoader.getEventDefinitionServiceHome();

try {
facadeHome = locateEJBHome(propLoader.getEventDefinitionServiceJNDI(), Class.forName(eventDefHomeName));

if (facadeHome != null) {
facadeHome = Class.forName(eventDefHomeName).cast(facadeHome);
Method createMethod = facadeHome.getClass().getMethod("create",new Class[] {});
facade = (EventDefinitionService) createMethod.invoke(facadeHome, new Object[] {});

m_log.info("Received the Event Definition service bean handle");
}
} catch (NamingException ne) {
m_log.severe("NamingException getting event definition EJB facade home."+ ne);
} catch (Exception e) {
m_log.severe("Exception getting event definition service object."+ e);
}
return facade;
}

Let's look at the getEventDefinitionService() method. The method first gets the bean JNDI name and home interface class name using the PropertyLoader. It then uses the generic locateEJBHome() method to look up and return the home object. We then typecast the returned object to actual home class. Using java reflection we get the method object for the method called "create". This is the method that creates the bean object. Note that in my requirement there was a hierarchial relationship between the bean implementations. WBEEventDefinitionService is a subclass of EventDefinitionService. Therefore when I invoke the create method object, I know that the returned object is an instance of either EventDefinitionService or its subclass. However if this is not the case, the same notion of reflection can be extended here as well.

Thus you can see that this code makes is extremely short and easy to do look up the EJB what might have otherwise required separate lookup code for each EJB.

~Ashish