Cloud Computing and Hannibal Let You Be You

Recently, The Federal Government announced it will offer Cloud Computing to federal agencies through Apps.gov. As Werner Vogels, the CTO of Amazon, recently pointed out in his blog, the move comes as a result of the realization that there is too much effort spent on managing IT infrastructure. Amazon realized this years ago and created Amazon Web Services to help alleviate this cross organizational concern.

Cloud Computing solves this problem by turning Infrastructure into a utility. By abstracting the key problems and offering a simple way to manage IT Infrastructure allows an organization to focus on the real task at hand.

We have observed the same phenomenon of duplicated effort in creating software. We have taken the philosophy of automating wherever possible to solve many common problems of creating an application. Hannibal takes care of creating the core of a web application, from persistence to presentation.

Hannibal enables you to focus on creating interesting applications instead of worrying about the common problems of creating an application. The same way Cloud Computing lets you focus on more important things besides IT Infrastructure.

Hannibal makes Testing ReST easy

The Browser class in Hannibal makes testing ReSTful Web Services easy. Simply call get, put, post, delete, or options and pass in a url and if needed a parameter map. The code would look something like this:

var response = browser.delete(myUrlString)

browser.post(myUrlString, [parameterName: "someParameterValue"])

Then get the response from the web service call and make assertions. Take a look at the unit tests from our SvnServices project for more examples.

Look for more tips on using Hannibal in the future.

Hannibal is in the Cloud!

We just pushed code generator support for Amazon's S3 key value store into Google Code. Now developers can generate data access objects that can persist data to S3. Active records are serialized to JSON then published to an S3 bucket named after your application's name. Retrieving data simply involves changing the JSON string back to an active record using the fromJson() method.

Here is what a URI path for a marathonracing's race domain object in S3 would look like

marathonracing/race/cherryblossom

where marathonracing is your S3 bucket name and race/cherryblossom is your S3 object.

Very simple.

We are testing this functionality now. Expect to see this in the next major release of Hannibal.

Svn Services

Lucid has released Svn Services, an open source project that provides restful Web Services using SVNKit and Hannibal.

You can use Svn Services to manage your Subversion repositories via web services. Using Svn services you can create or remove new Subversion repositories. You can manage your Subversion repository users as well. Svn Services is deployable as a war file in Tomcat.

You can download the alpha war file here.

Hannibal is Simple Too

So we were just reading an interesting post over at The Disco Blog regarding the simplicity of creating web services using Grails. Grails is a very popular framework for creating web applications. After reading that article we were convinced that creating a web service using Grails was indeed simple; of course we wondered how Hannibal stacked up to that ...

So we decided to implement that "runners and races" example in Hannibal. Please visit the wiki for a treatment!

Hannibal S3 support

Deploying Tomcat in Amazon's cloud just got a little easier! Tomcat provides a JDBCRealm that allows developers to access user password and role information in their database. Lucid extended that concept by creating an S3Realm that allows developers to retrieve user credential and role information from S3.

Configuration of an S3Realm is easy. Just create an entry in tomcat's server.xml that identifies your application credentials bucket name, along with your AWS secret and access keys. That's it.

Of course the appropriate S3 bucket should contain the user principal and role information as well. Developers are still responsible for populating this as users register.

This functionality is undergoing testing right now and will make the next release of Hannibal! Once it does we will provide the appropriate documentation in the Wiki.

Open Data

When Vivek Kundra was the CIO of the District of Columbia, he championed the idea of a more open government. His thought was that by making the District's data more open, both DC's government and its citizens would inexorably benefit from this in unpredictable ways.


One of the many data opening initiatives he encouraged was Apps For Democracy. This was a project that encouraged private citizens to explore opportunities to mash up government data in ways not thought of by the District itself. The purpose of this project was to provoke a few thoughtful responses from the crowd of application developers with free time to engage in such pursuits.


In just over a month, Apps For Democracy received 47 useful data mash up applications. Why was this so successful?


We think it was successful simply because the District data was made accessible to people who cared about it. And the people who cared about the data did what they wanted to do with it. We call this approach, "The Client Knows Best". Give the client access to the raw data, get out of the way, and watch them produce what they want!


What would happen if this was done in the enterprise? Our own observation is that large corporations do the opposite. Data is not even made fully open to the members of the organization itself. For various reasons, enterprise information is usually trapped within the systems of the business pillars that make up the organization. When these data sets were first established, little or no thought was given towards sharing this information with other departmental groups. Later, when it became apparent that data sharing would be a good thing to have, attempts to make the data more accessible are hamstrung by the initial lack of forethought.

Complicating this is a tendency to "over own" the data. This desire to control the presentation is understandable, but many times the old fashioned mechanisms for achieving data ownership are so restrictive, the consumers of the data are unable to get what they want in a timely fashion. If data is not open, this will always be true!


What do we mean by open data? Well, open data does not mean data that is available to anyone. It is to be expected that some data should not be shared with everyone due to privacy and other concerns; it is also expected, that for an individual that is deemed privy to a data set, the information should gracefully be made available to that individual. How do you accomplish this? Here is what we think the minimum requirements a data store must meet in order for it to be considered open.

1. Published data taxonomy - The data's categorical structure shall be made readily apparent to prospective users.
2. Robust search capabilities - A user of this data shall be able to perform free text queries against the data store.
3. Fundamental CRUD operations - Reading data is fundamental, and so is creating, updating and deleting data. Provided the security credentials of the data user checks out, these functions shall be readily available.
4. Change notification - Users of the data store shall have an avenue to understand how the data they have accessed has changed over time.
5. Centralized but portable data production rules - Other enterprise systems shall have the ability to create and manipulate new data resources outside of the system of record. Strange as this may sound, enabling other systems to create resources outside of the system of record can result in large magnitude improvements in reliability. This shall be encouraged as long as consumers always consider the data sources system of record to be the single source of truth. It is expected that data resources created in this manner shall eventually be synchronized to its system of record.
   

Many data stores in large organizations consistently fall short of these goals. As a point of fact, we have never witnessed a departmental data store that had all these criteria met. This functionality is never built in from the inception. This is a shame, since the truth of the matter is that such functionality is actually quite easy to provide up front.

Our code generation suite Hannibal makes it really easy to have this from the inception. Hannibal allows developers to generate code that performs search, CRUD operations, and change notification out of the box. Furthermore, developers can stipulate declarative security rules that govern who is allowed to view this information. Finally, it makes all of this available via restful web services, so that applications from mainframe processes to desktop browsers can effortlessly access this data as well.

Now your data is open.

In the following posts, we will give real world examples of data sharing applications built using Hannibal, and illustrate how typical problems experienced in the enterprise can be easily solved by some creative combination of the five aforementioned bullet items.