Now that GWT 2.0 is out, I want to take the new panels for a spin.
We have been upgrading our UI with the pre 2.0 widgets. Now I want to try the tab panel. We have spent a lot of time trying to get an X icon in the upper right. Hopefully it will be easier with the the widget.
I’m calling no mas on the ESB project for now. I’ve learned a lot in the last week. I’ve installed 2 two different ESBs (servicemix and mule) and have read the docs for several more (camel, spring, jboss). I learned a lot about JMS – installed and configured activemq (really liked the ease of initial usage).
But in the end, I couldn’t make it do what I wanted (at least quickly). I have about 60 hours into the project and am not done. The use case I was trying to implement was a provisioning service. The essence of which is:
I got to the last step and called no more. I am probably a few hours away, but there just seemed to be one more thing poping up. I was hoping the learning curve wasn’t so steep to get something simple going. So what I have learned…
We’ll a lot actually. First is that I understand why ESBs are not implemented everywhere and why point to point interface solutions are the norm. In fact the straw that broke the camels back that got me to implement an ESB in the first place was not as heavy as I thought. I went back into our app and extended our current infrastructure to support yet one more interface.
Second, doing something a little bit outside of “built in” requires a lot of knowledge. In Mule to create a dynamic host name for the outbound http endpoint took way more effort than it should have. Being able to “decorate” the functionality of an endpoint would be nice (basically I had to copy the Template router and make the hostname dynamic based on a property in the message – which I had to figure out how to get there in the first place).
Also, capturing the HTTP response was a lot tricker then it should have been. I have to imagine that is a frequent requirement but took custom code again. In mule I had to extended my custom router to also be a chained router…
And finally the community isn’t the largest in Mule. I don’t expect my questions to be answer immediately (or even at all). However, the lack of extensive historical advice in forums is a problem. I can’t believe I’m the first person that wanted to do either of these things.
Anyway, those were the biggest pain points so enough with the probably incoherent rant.
Third, ESB are actually very powerful. A messaging framework is something I want to implement at some point in the future. We have a strong need to integrate with lots of different inbound service. So in a couple of weeks when I get some other priorities completed, I will revisit this whole topic. However, I will choose new functionality to implement rather than try to replace existing stuff.
Fourth, being able to debug the running ESB in the java/eclipse debugger is 100% a requirement.
Fifth, so I don’t forget, the JBoss ESB looks promising. I read through some of the docs and like the fact that the message object is passed to the business logic components. I understand why/how mule takes the approach to have POJOs for components. But I found myself writing transformations when I needed access to the message. Also, it seems the JBoss message maintains previous items; whereas the mule message is a destructive context as it passes through different things. So I don’t get flamed to badly, these are just impressions after having spent only a relatively small time with each solution.
A concern about the JBoss solution is the weight of the standalone ESB. I liked Mules small footprint. The download for JBoss is very large. Hopefully it is not like the application server that includes everything but the kitchen sink (we have some experience with the JBoss AS and have removed it; EE was just too much overhead for us).
Sixth, good tooling support is a must. Mule has it (maven support), looks like JBoss ESB might, Spring does also.
We’ll that’s enough for now. The end result is there is ESB’s are powerful but come with a steep learning curve to implement and fully utilize. The ability to understand and customize an implementation to do exactly what you need takes more work that it should.
As our applications have grown, we have created one off interfaces to external systems. Each has been a carefully crafted hack. We’ve known all along that this is not sustainable in the long term; but like all shops we didn’t have the business case to spend time creating something more elegant. That changed today, the collective weight of all the interfaces finally caught up with us. So we are going to pay off our technical debt and implement an ESB.
We start looking by looking at a variety of them. Most cater to some form of web services, so they are out (most of our interfaces are not web services per se). I ran across ServiceMix from Apache and it looked promising. It is very easy to download and follow the examples and tutorial to get up and running. I really like the hotdeploy functionality. There is a lot of maven support to create projects and different configuration files for what they call a service unit.
However, once I got beyond the tutorial example, I hit a brick wall. Or more importantly ServiceMix put a smack down on me that I haven’t gotten up from yet. For my first test I wanted to create a service that took an http post file, did a transformation on it and saved the result to the filesystem. Easy enough. Turns out this is really tough to figure out. I’m sure if I was more familiar with ServiceMix this could be created in a few minutes. But after a day and a half of reading source code and googling I couldn’t figure it out. The docs on the website leave a lot to be desired – at least for new users.
So I turned my attention to other options. Next up was Mule ESB. I’m not done; however I can tell this is what we will implement. The docs are good. I was able to get the sample up and running (in Eclipse) in about 10 minutes. After taking my time and reading a lot and working through the tutorials/examples, I was able to create my first service that executed my first use case in about 4 hours. I could have done it quicker; but I wanted to take my time and understand more than just the simple items.
Mule also provides the Mule IDE which helps create new services and the icing on the cake is we can run Mule ESB services in Eclipse — which means debugging just became a whole lot easier.
Next up will be finishing (error handling, etc) my first service and then configuring Mule to run as a standalone application (not via Eclipse).
With the new GWT 2.0 (due to be released this year?), they have add a couple of great features. The one I’m most excited about from a users perspective is RunAsync (aka code splitting). To quickly recap, this feature will split a GWT application into multiple developer controlled (split points) downloaded files. We are reworking our internal GUI architecture and have decided to use the unreleased GWT version for development. Our largest application before compression (with obfuscation) is weighing in around 1.4MB. That’s pretty hefty for downloaded javascript files.
We have limped along waiting for GWT 2.0 and code splitting. We didn’t want to put in a temporary solution of using URL redirects and manually splitting our code into modules for a 6 month solution. We’re happy we didn’t. With our refactoring effort, we have designed it so that we can easily have split points at our “module” level (basically a group of related screens).
We don’t have hard numbers yet for an apples-apples comparison, we like our first attempt. It looks like we will have three downloads to start our application. The first bundle is about 140K, the second which is a module is about 80K and a leftover module which is 500K. The leftover module is primarly framework items (both GWT – e.g., Button, and our internal framework code).
We expect, as we work with the new functionality, to be able to get these values to go down (particularly the third – leftover download). After all, we only have one split point right now. We also are probably going to put in a new “home” page that displays when the user (same for every user) logs in so that the other download bundles can be download in the background.
The trick with RunAsync is to get the use case correct. RunAsync as it’s name implies doesn’t execute code sequentially. Therefore we had to add a callback mechanism into our code to display the GUI that was just downloaded.
For those interested it looks something like:
public void retrieveViaCallback(final OurInternalCallBackGuiObject callback){ GWT.runAsync(new RunAsyncCallback(){ public void onFailure(Throwable err){ Window.alert("code download failure"); } public void onSuccess(){ callback.show(); } }); }
We haven’t dealt with error handling yet (hence the call to Window.alert); but the RunAsync is pretty easy to get going if you have good modularization in your code base already.
In reality it can’t be done with the stock code. In our application we would like to be able to “stop” an event from being fired further.
One example, we have three event handlers that can be added A, B, C (validation, required check, and save rpc). We add the handlers to a button in that order when needed (sub class determine which handlers to add). We want to be able to specify in A or B handler that the event should stop propagating to other handlers.
We tried a couple of different things (including starting to add our own event handling logic) and we settled on two changes to GWT itself. We added a method to GWTEvent:
- public void stop(); /* record that the event should not be passed to more handlers */
- public void isStopped(); /* is the event stopped for further processing */
- public void unStop(); /* reset the stop flag to be false – did in case event is reused */
In our event handlers we can now call event.stop() to stop further propagation.
In HandlerManager.HandlerRegister we modified
private <H extends EventHandler> void fireEvent(GwtEvent<H> event, boolean isReverseOrder) { Type<H> type = event.getAssociatedType(); int count = getHandlerCount(type); if (isReverseOrder) { for (int i = count - 1; i >= 0; i--) { H handler = this.<H> getHandler(type, i); event.dispatch(handler); if(event.isStopped()) { // CUSTOM: event stop processing event.unStop(); // did this in case events are reused break; } } } else { for (int i = 0; i < count; i++) { H handler = this.<H> getHandler(type, i); event.dispatch(handler); if(event.isStopped()) { // CUSTOM: event stop processing event.unStop(); // did this in case events are reused break; } } } }
While this is a very specific use case, hopefully with enough examples, some thought will be put into an extension mechanism for HandlerManager. Until then, we get to live with our solution.
EDIT: After a post on the GWT list, it looks like this type of use case (developer extensions for the event handling) where considered but deemed too much/too varied to include anything in the GWT 2.0 timeframe. Here is the discussion.
