Java in 2009


Today the last day of 2009, people say time to look back on the year passed by and prepare to  welcome a new year.For me a New Year day is just like any other day.. I feel and live the day of New Year just like all other days.

For Java Community, the year 2009 was major acquisitions like,
Oracle buying Sun,
Terracotta took over the Quartz and ehCache open source frameworks,
SpringSource acquire G2One and Hyperic, 
VMWare acquire SpringSource.

Other interesting development is happening in JVM languages. Groovy, Scala, Clojure, and JRuby gained more popularity this year. JVM is getting remodelled as a platform for other languages.

The fight of dominance in the world RIA is continiuing with Java FX, Flex. Microsoft Silverlight is alos in the race. I feel Adobe has the upper hand in the RIA world.

Cloud Computing continued be discussed in 2009 . Cloud got prominence as IT world start thinking of ways to reduce cost. Google is the most prominent player in this area.Sun, Microsoft recent joined this arena. Microsoft with Azure Platform. Google currently not supporting Java , but urges developer to go with Python.

2010 we may see the languages other Java getting more acceptance.But Java will continue to be strong and will be the most powerful of all. OSGI world seems to busy with projects like Gemini.

Have a great year ahead !!!.


REST - Building Better Systems

REpresentational State Transfer (REST) in short is a simple solution for invoking Web Services through URL's

REST defines a set of architectural principles to design Web services. The RESTful Web Services focus on the system's resources, including how resource states are addressed and transferred over HTTP by a wide range of clients written in different languages.

REST is now a predominant Web service design model. REST is much simpler that the SOAP- and WSDL-based interface design.

REST style of Web Service invokes HTTP methods explicitly. The basic CRUD (create, read, update, and delete) operations are mapped with HTTP methods POST,GET,PUT,DELETE respectively.

In bad designs there is a chance of using these HTTP methods for unintended purposes, For example;

GET /addemployee?name=Chris HTTP/1.1

addemployee is a state changing operation over HTTP method ,GET. If the above request is successful, it will an employee to the database.

HTTP Servers are designed to respond to GET method to retrieve information for the data store. So from the view of HTTP servers the above usage is wrong.

Similar to Create or operations like update ,delete can be invoked in a similar way, which will cause a state change in the server.

The other side of the problem is , this will cause sever side changes if the link is crawled even un intentionally.

To overcome this, the parameter name and values can be represented as XML tags and sent as a body of the HHTP POST request.











The receiver of this request will process this and add the resource in the body as a child of the resource identified in the request URI. In the above example the employee is the resource in the request URI, and Chris will be added under employee.

This is an example for RESTful service.

To update the name of an employee, the RESTful way of doing is to send a PUT request.













The key concept behind defining Restful interface is reusing the “verbs” defined the protocol. For example, employee, parts, machine all are nouns, think of what we can do with theses nouns, it could be get employee, get parts etc. “GET” is the common verb for all the nouns. GET is already defined in the protocol. The service should not define new verbs or remote procedures.

To be more clear, instead of defining services like getemployee, getpart use the universal verb , “GET” to define these services. POST for the services like addemployee, addpart etc. For Update use the PUT request.

The URL will define the resource on which the action needs to be taken ex, employee in the case of the URL, POST /employee HTTP/1.1

The other important design concept in REST is that the body part of HTTP request should carry only the state of the resource and not to carry any name of the remote method or remote procedure.
REST design reduces dependency with the application server than the SOAP- and WSDL-based kind.

Domain Driven Design (DDD)

Domain-Driven Design (DDD) is a collection of principles and patterns that help developers to create software abstractions called domain models. These models highly expressive and encapsulate business logic.These models will  bridge the gap between business and code . These models that is understandable by all the stake holders involved in the project and not just software developers.

For non technical people, the models can be represented in different ways. Typically, a model of a domain can be depicted as a UML diagram, as code, and in the language of the domain.

As an example of using language,
A user wants to order a book online. He searches for the book based on Author, Title. This book is available, user can purchase the book. An order number is issued which the user can use to track the order status.
The language used has to do more with the concepts. It has to explain what the intention is. How the it is implemented is not significance. This helps in better interaction with the developers and the domain experts.

As an example,
A user wants to order a book online. He searches for the book based on Author, Title. If this book is available, user can purchase the book. The user Credit Card is validated by calling a Web Service offered by a third party vendor. Once validated, an order number is issued which the user can use to track the order status.

Here the validating credit card is important. But the Web Service is the implementation, which is insignificant.
So the language used to model the concept must be in line with those of the domain experts.
To have a better understanding the concepts can be explained as "Stories" or "Scenarios". This is the key in Behavior-Driven Development (BDD). What is in story , http://dannorth.net/whats-in-a-story is an interesting article.

Story usually tells about a user wants to do an action, so that he will be benefited. So the above model can be rephrased as,

Story about Buying a Book.
I want to search for a book on Java. I want to buy that. This will help to improve my Java Knowledge.
As the story develops, it will have turning points or scenarios.
Scenarios for the story will be like, 'When' the book is out of print, 'Then' add this book to my wish list and send me a mail when book is available. 'When' describes and event, and 'Then' explains what is the outcome of that event.
Lot of discussion happens around DDD. Some good resources
http://msdn.microsoft.com/en-us/magazine/dd419654.aspx
http://dddstepbystep.com/