We Need a Map to Talk to Each Other

In a conversation I was having today the question about how two gadgets would communicate with each other came up. Initially, I was thinking that two gadgets would talk through an intermediary gadget which would convert the output of one gadget into the input for the second gadget.

There are a couple major problems with this approach:

1. Anytime you added a gadget you would possibly have to write a whole slew of interpreter gadgets for the gadgets you wanted to give input to or take input from. At a minimum, every gadget would require at least one interpreter gadget.
2. The whole gadget as a web service concept breaks down when you start talking about interpreter gadgets. They do not need to reside on the web, they need to reside on the platform. Should you have a platform based gadget? Is that really worthwhile or does it break the nice clean system we've conceptualized?

In the midst of the conversation the idea of being able to do mash-ups was discussed, and this spurred me into a new area of thought regarding how gadgets could talk. Mash-ups always make me think of PopFly. If you've never played with PopFly, I highly recommend it. It's one of the coolest things to come out of Microsoft since Surface.

In PopFly, you capture two (or more) web service endpoints and then you map the fields in the endpoints together. This allows you to create dynamic mash-ups on the fly, among other things. So, let's say that I have a web service that gives me a weather report for a list of locations and I have a mapping web service (like Google Earth). I can map the location info from the weather report list onto the mapping service and create a series of push-pins on the map that will show you the weather report when you mouse over them. It's pretty nifty and very simple to use.

Why not use the mapping between web services concept for our platform?

It's a much more elegant solution. It has several advantages over the other approach I mentioned:

1. A mapping is much easier to generate than a complete gadget. What's more, if done right, it could be done in a UI! PopFly has demonstrated this very well.
   
2. The platform would only have to remember a mapping (which could be done in XML quite easily) for any communication between gadgets. That eliminates the problem of having platform-bound gadgets.
3. The mappings could be based off of the WSDLs that the web services publish. This would allow a direct mapping from the output of one gadget to the input of another. No intermediary step is needed.

I have to say, I'm quite enamored of the idea. I think that the first step is going to be creating a set of gadgets that are supposed to talk. I've already created the first gadget (a charting gadget). I can create a simple gadget that spits out a set of variables and then try to map that onto the chart gadget. I'll have to dig around the net a bit to see if I can come up with some good examples of the best way of mapping web services together.

I shall post my progress here!

Architecting Things Out

I'm now going down the path of fleshing out the architecture for our project. We're working with the concept of "gadgets" coupled with a "platform" as the basis for our architecture.

A gadget is simply an object (in a conceptual sense, not a programmatic sense) which takes an input, processes that input and produces an output. The platform will coordinate the gadgets in such a way that you can string gadgets together in order to get a chain of information, or a work flow, that you like.

Those are the concepts, but how does that play out in an application?

Well, the first idea that comes to mind is a service oriented architecture. Here, the gadgets have two components: a webservice that takes the input, does the processing and then gives an output; a component that plugs into the platform, interfaces with the webservice and provides any UI. A good example of a gadget is one that takes input and provides a visualization dependent on the input.

The platform would ideally be a flexible piece of software that would allow you to "wire together" different gadgets into the work flow that you want, among other things. I'd like to take a page out of Spring's book and make the wiring together of gadgets by the platform be definable in XML. This would allow for dynamic wiring at run time which would mean you could build an "application" out of gadgets as you saw fit, ad hoc.

I like the idea of using webserivces because it provides such flexibility. It also means that you could create a gadget out of an existing web service (assuming that it was all right with you that you don't control webservice).

All in all, it's a rather web 2.0 concept that I think we're developing here, and I really like it. I'd like to get to a place where someone could wire together their own version of the application and then run it, change things and then rerun it to see if the output changed. Remember, this software is in support of research, so the ability to prototype a system is incredibly useful.

Hibernate Musings

So, I'm working my way through this tutorial on hibernate. It basically takes you through creating a basic (and trivial) Hibernate project, all the way to the point where you create the database and put info into it, then take it out.

Wait, did I just say "create the database"? That I did. I think this is the coolest feature in Hibernate that I've come across so far. The work flow basically works like this: First, you create your POJO bean which will hold a record. Then, you create a mapping file which will map the properties of the bean onto a table in the database. Next, you set a special property in your hibernate.cfg.xml file (called hbm2ddl.auto) to "create". Finally, you create some utility classes that drive Hibernate.

Set up an ant task to do something (in my case, I stored a record) with the database and run it.

On start up Hibernate will create the database using the mapping files. The more mapping files you have, the more tables will be created. I still don't know if you can create multiple tables from one mapping, but the ability to create a database based off of POJO beans is some kind of powerful and is a feature that I will hopefully use to a great degree in order to get around some of my relative inexperience with database design.

Spring!

I'm reading a book right now by Rod Johnson, called "J2EE Design and Development". It's a fabulous book which conveys all kinds of refinements on the architecture of a J2EE application.

In the book, Johnson puts forth his own novel framework for managing various aspects of the application. This framework became know as Spring and can be found here.

Of particular interest to me is the MVC framework that can be used to create a thin and clean front end for your web app. After reading a bit about this in the book I went and got Spring and ran through a tutorial that helps you create a non-trivial but simple front end for an inventory system. It's all included in the Spring download, if you're interested.

So, what are the highlights? First off, anything that can be configured in XML is configured in XML, allowing for dynamic shifting of classes at run-time! Further, one of the big Spring tenants is to program to interfaces (which is simply a sound principal and one I'm finding myself adopting quickly). These two things taken together means that Spring is incredibly non-invasive. You can use the Spring framework without having to write a bunch of code aimed at the Spring framework.

Let me walk you through a request flow to give you an example of how this works in the MVC framework.

To start off with, I have set up an index.jsp that redirects to hello.htm so that you can easily enter the application. I've set up a servlet-mapping in my web.xml which intercepts any and all .htm pages and redirects them to the Spring master controller.

So, enter the Spring master controller (which I use right out of the jar). The master controller will process the request, then hand off the request to a sub-controller which you define. All of this is configured in an XML file as well. I called my application springapp, so I created an XML file called springapp-servlet.xml.

I have a bean definition in springapp-servlet.xml for /hello.htm:

<bean name="/hello.htm" class="springapp.web.InventoryController">
<property name="productManager" ref="productManager"/>
</bean>

The master controller sees the class that is attached to /hello.htm and interprets this as the sub-controller which it should forward the request to. So, off the request goes.

My InventoryController does some logic processing and data gathering (for instance, it gathers a list of items to show in the inventory view) and puts all of this into a model which, in this instance, is a Map which contains a list of Products as well as a Date object. The InventoryController forwards the model and the name of a view back to the master controller and the master controller then forwards the model to the view specified which, in this case, is a jsp called hello.jsp.

The jsp page loops through the products list (which is model.products) and displays the products.

We also have a link on hello.jsp which will take us to the price increase page (called priceincrease.jsp). This page allows you to implement a price increase by percentage over all the products.

Here's where things really get cool. Spring ships with a tag library, called form. It adds on to some normal HTML tags, such as form or input. The specific design, though, is to allow you to map a form or input back to a specific class. So, to enter in the price increase, I use an input defined by the form tag library:

<form:input path="percentage"/>

I also define a form which this input sits in:

<form:form method="post" commandName="priceIncrease">

The command name maps back to a bean in the springapp-servlet.xml file. That bean has a controller class specified (PriceIncreaseFormController) with it as well as a name (/priceincrease.htm). You see how the pattern is forming up? In that controller, there is a mapping to several things. First off is a mapping which corresponds with the commandName. This is mapped to a class (called PriceIncrease in this instance). PriceIncrease has a field called percentage. So, when the form is submitted, a new object of class PriceIncrease is created with the value in the input attached to the field percentage. PriceIncrease is considered a command, as it provides direction on what the ProductManager should do with the Products.

Further, a validator is specified for PriceIncrease and is automatically run. All of this is then passed into the PriceIncreaseFormController. The controller evaluates the results of the validator, does any processing necessary, builds a model if necessary, and then forwards everything to a view (which is hello.jsp in this case).

So, that's the basic workflow. I think it's pretty awesome that so much can be specified in XML. That gives you an amazing amount of flexibility at run-time.

All in all, I think I'm going to benefit a lot from Spring. It has more than just an MVC component. It provides an abstraction for almost every level of J2EE applications, from the database level (a JDBC abstraction) to a replacement for the EJB tier.

I'm Pushing this on You

So, one of the requirements we have is to be able to alter the content of a page given a users input, where that user is either another user entirely or the main user of the given session. The aim is to impart a collaborative aspect on a given page so that anyone on the page can view the collective changes that have been made to that page.

This has brought me around to thinking about AJAX in a different manner. Normally, AJAX is used to pull info from the server. The page (or component on the page) makes a request of the server, and the server sends the response to the page/component. However, what do you do when you need to reflect changes to your model in near real time?

Well, the thought that comes to my mind is that you move to a push model. In the push model, whenever the data model changes it pushes those changes out to the view. Now, this is totally doable with AJAX, it's just a different way of thinking about things. I think it's been termed reverse AJAX.

Of course, the poor man's way of doing a push model is to actually do a pull model with automated (instead of user-requested) pulls on a short interval. The downside to this is that it can result in a ton of network traffic at the very least. Another downside is that you don't have true data coherence. You're basically taking a guess as to when the data model has changed.

So, I'm now investigating ways in which I can use a push model. I've found two promising leads: CometD and Pushlets. I might still opt for the poor man's approach, at least for now, but both of these bear investigation. When I know more, I'll post it here.

If you're interested in a good article which outlines some of the ways of going about this, check out this article here.

J2EE Survey Software: Opinio

A requirement came up recently wherein we need to be able to conduct online surveys. Thinking that this was an area where I'd best be served leveraging existing software, I started searching for Java based survey tools.

I quickly found that there is a severe dearth of Java survey tools in the open source community. Most projects haven't been updated since 2005 and all of them seem cumbersome. If I am going to use something, I'm going to make sure it is easy to use and also looks good.

So, abandoning open source for the moment, I started looking at what was available in the closed source world. I quickly found a piece of software that fit my needs perfectly. Called Opinio, it is a very nicely built J2EE application that can be deployed on anything from Tomcat to JBoss (even IIS, or so they claim).

It has 3 versions: Lite, Corporate and Enterprise. The Lite version is free for use, but has a much reduced feature set. However, the reduction is in the analysis side and since we're going to be building our own analysis tools, this application fit perfectly!

My only gripe so far is that it doesn't have a great community or a good set of docs. I'm currently trying to set it up so that it will write the surveys to our SQL Server database. There are directions on the site for setting up MySql and Oracle, but no SQL Server. Once I get the issue solved, though, I may post how to do it, here.

And the Winner Is...

JBoss.

1. First and foremost, JBoss has the best community. Documentation exists for all facets of using JBoss, from developing on it to deploying it to a production environment. Most of these docs exist in Wiki form on the JBoss.org website, but a Google search of any term prefixed by JBoss (ie: JBoss Administration) will return many, many relevant links. This in and of itself is the primary factor for using JBoss.
2. While GlassFish provides the latest in JEE 5, JBoss is not far behind (actually having a release candidate with JEE 5 support available). Further, we will most likely not be harnessing a lot of the JEE 5 specification. What we will be using of the JEE 5 specification, mainly JSP and Servlet are provided, along with a JAX-WS compliant stack in the form of JBossWS.
3. JBoss has an Eclipse plugin (as does GlassFish).
4. JBoss’s system requirements are lower than GlassFish’s.
5. While GlassFish’s admin console is very nice and very polished (specifically it’s log viewer), the lack of being able to run in a console window is constrictive to development. From a developer productivity standpoint, having to open up a web page and refresh the view to get the latest log files would be detrimental.
6. Hibernate, the ORM solution we will be using, is a JBoss project, and is built directly into JBoss.
   

The choice came down to JBoss vs. GlassFish. I never really considered Tomcat with Metro.

While I really liked GlassFish, it didn't seem as suitable for a development environment. Both of them seemed completely competent in a production environment, with each having its best features. So, it came down to which would be better to develop on.

The answer to that question is that JBoss is easier to develop on and it has the most widely available community. Those two factors weighted things to JBoss.

The Purpose

So, this is my developer's blog. It's the "in vogue" thing for developers to do. I see them all over the place, so why shouldn't I have one, too?

I've recently changed jobs and am working on a project now that is starting from the ground. I'm also the lone developer on the project. That kind of makes it my show, to a certain degree. I'm responsible to the Customer (who shall remain nameless) and to the Company (who shall also remain nameless) I work for.

Being in on a project from the ground up is a pretty cool thing. You get to make a lot of decisions that will have a huge impact on the project months, if not years, down the line. Some of the decisions I've already made have been which language I will use: Java; what type of application it will be: a web app.

A few decisions were made for me, including which database I'll be using, which is Microsoft SQL Server. That suits me fine, as I'm going to try to take a database agnostic approach by using Hibernate. We'll see how true to that desire I can stay later on down the road.

It does have the up-side, or so I've heard, in that SQL Server is supposedly easy to administer. It certainly seems easier to administer than Oracle, the only other database I've worked with. The tools seem to be a lot more developed and "user-friendly". That's good in my book, as I don't want to spend all my time adminstering the database.

The big decision I'm working on right now is what application server I'm going to be using. I've basically narrowed it down to three choices. The first is to use Tomcat augmented with the Metro web stack that is available from the GlassFish project. The second is to use the actual GlassFish server itself (or whatever lame name Sun gives it once it's released officially). The third is to use JBoss.

I'm researching all three right now and I plan on posting here what I find and my ultimate decision.

So, back to the purpose of this blog. I'd like to document the steps that I take as I build this application. I'd like to make note of the pitfalls I fall into and how I got out of them. I'd like for this to be part history, part road-map to how to do it better in the future.

We'll see how it goes from here.