Chrome for Open Source Software

Clustering in the Brave New Virtual World

2010-05-23T06:51:00.000-07:00

High Availability(HA) and Fault Tolerance(FT) in the Enterprise Java world is not the same as HA/FT in the VMware world, but the overarching goals are the same. HA in the Java world involves proper load balancing across more than one application server so that a single server failure does not take the entire application offline. The worst case scenario for the user is to get kicked out of the application and bounced back to the login page. The goal of FT is to eliminate the user kick out event and make the failover seamless. In the Java world, FT is usually delivered by using application server clustering. The biggest difference between Java and VMware FT is Java based clustering does not shadow copy at the VM(Virtual Machine) level. Instead only the "application state" is copied. On the HA side, Java applications will use either a hardware or software load balancer instead of vSphere and DRS(Distributed Resource Scheduler). Java based FT is painful. Does replication of just "application state" warrant the added complexity?

Clustering is a Cluster

For years, clustering has been a hot button issue in the Enterprise Java world. Architects desire both High Availability(HA) and Fault Tolerance(FT) and there are two leading approaches to HA/FT. The first approach is to architect a purely stateless solution and the other is to "minimize the use of state". In a stateless application, there is no need to replicate state and the only thing required to deliver HA/FT is a load balanced set of application servers. The "minimize the use of state" part was not the original intent of J2EE but Stateful Session Beans(SFSBs) and vertical scaling delivered worst of breed results. Worst of breed in that the hardware and software was extremely expensive, yet a very profitable business for BEA and IBM. And, even the best SFSB based systems performed and scaled worse than a stateless architecture. Even JBoss, the low cost alternative to WebSphere/Weblogic, was unable to deliver adequate scalability and performance for applications that use a lot of state. Thankfully, smart architects altered software design such that either "stateless" or "minimized use of state" is used. And, that design decision made Tomcat and JBoss a better, cheaper platform for most enterprise Java applications.

Modern Enterprise Java

For a typical Java application there are only two major "state" components:

HTTPSession - usually limited to user profile data or potentially "web conversations". Each user has an HTTPSession and that session remains available as long as the user is logged in to the application. HTTPSession is like a student's back pack. You can shove the back pack full of heavy books or go with an iPad. Spring Webflow, Grails and Seam provide a very nice way of "minimizing the use of state" just like an iPad minimizes a back pack's weight. More information about Spring Webflow based conversations can be found here: http://static.springsource.org/spring-webflow/docs/2.0.x/reference/html/ch03s05.html
Second level data cache - This state component sometimes violates the "minimized use of state" mantra but it is very common. Database intensive Java applications will store database query results in the cache so that future requests do not result in a subsequent round trip to the database. Most second level caches are not clustered, and a clustered second level cache is usually a bad sign unless a high end caching product like Terracotta or GemFire is used. For high end products, cache clustering is handled separate from application server clustering. A good cache will be "distributed" and "transactional", which is just a fancy way of saying that the cache product provides its own HA, FT and proper data synchronization with the underlying database.

Bottom Line

Virtualized Java applications may benefit from VMware based FT/HA instead of traditional load balancing(HA) and clustering(FT). There are not enough vSphere/FT/HA based Java deployments to prove that traditional load balancing and clustering are obsolete but that may be the case. Right now, the best practice way to deliver HA/FT is to have a:

Properly configured hardware or software load balancer (F5, Cisco, Apache, ERS).
Properly architected application that minimizes the use of state and a lightweight application server that supports HTTPSession clustering (Tomcat, tcServer, JBoss).
Properly architected data cache that is either NOT clustered or relegate data caching to a high end data cache product. (Ehcache or JBossCache for non-clustered), (GemFire or Terracotta for a clustered cache).

DISCLAIMER: I am employed by VMWare. The views expressed on this blog do not necessarily reflect the views of my employer. I am completely responsible for all content displayed here. Furthermore, no content of cfossguy.blogspot.com has ever been reviewed and/or endorsed by my employer.

Virtualized Java is the Real Deal

2010-05-08T06:53:00.000-07:00

Lately, I've been talking to more and more virtualization gurus and while most of my conversations are still with Java architect or middleware operations teams, change is coming. VMWare's acquisition of SpringSource has flung the virtualize Java door wide open. And, the biggest challenge we face is not technical. We need cross pollination of Java and virtualization talent. Virtualization gurus need to ramp on Java, and Java gurus need to ramp up on virtualization. I realize that virtualization gurus should not concern themselves with programming in Java. But, they do need to understand the tools of the trade, the strengths/weaknesses of the platform and configuration optimization techniques. My next series of blogs will target the virtualization guru audience. Here is a little taste of what is coming:

Quick JVM Optimization Checklist

64-bit JVM - If you see 32-bit Windows/Linux, recommend a move to a 64-bit operating system(OS) and Java Virtual Machine(JVM). The 4GB limit on a 32-bit OS is problematic for large enterprise Java applications. And, since the 4GB limit is for the entire OS, the maximum JVM allocation will range from 2GB to 3.5GB, depending on the OS. In a future blog, I will go into more detail on why Java can consume a ridiculously large amount of memory and why that is not necessarily a bad thing.
Min/Max Heap - Min=minimum heap size of the JVM, Max=maximum heap size of the JVM. The JVM manages memory similar to a hypervisor and the JVM's memory consumption will balloon up/down based on application design and user load. If the max heap setting is too low, the JVM will spend an inordinate amount of time managing memory. Or, worse yet throw an OOME(Out of Memory Exception). If the max memory setting is too high, memory is wasted because the ESX hypervisor will not be able to reclaim it from the JVM. Right now, memory management for Java is Highlander style, "There can only be one". You cannot drop memory reservations down on VMs that are running Java. But, if you set reservations properly, Java application performance on VMs will be similar to physical. For a development system, max heap will often be 512MB or lower on a lightweight application server like Tomcat. On a production system, anything lower than 1024MB is cause for concern, but not necessarily wrong. Many Java gurus will insist on setting min/max to the same value, but that is no longer required for most deployments. Prior to JVM 1.5 or Java 5, setting min/max to the same value was a no-brainer.
Permgen - The default permgen, if not specified, is 64MB and that is usually far too low. Permgen is the region of JVM memory that cannot be reclaimed. It is similar to the reservation in the hypervisor, but different. When you deploy an application to the JVM, the bytecode for all classes are loaded into the permgen region. If the application is large or uses a lot of framework JARs, it will require more permgen. Other memory may reside in permgen but this classloading activity is what causes most OOMEs that are permgen related. When the OOME is permgen related, you will see this message in the server log: "OutOfMemoryError: PermGen space". Application hot-deploys are usually the culprit. Most application servers support live deployment of a new application. There are JVM tricks to make hot-deploy work without killing permgen, but hot deploys should NEVER HAPPEN IN PRODUCTION. I will go so far as to say they should never happen outside of a developer workstation.

This is a small sliver of JVM optimization information but understanding how to properly configure min/max/perm will address a surprisingly large number of Java performance issues. More information about JVM tuning can be found here: http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html.

I will continue my virtualization ramp process by reading great blogs like: http://www.virtualinsanity.com and I believe that every Java guru needs to learn more about virtualization. Hopefully virtualization gurus will find this blog useful.

DISCLAIMER: I am employed by VMWare. The views expressed on this blog do not necessarily reflect the views of my employer. I am completely responsible for all content displayed here. Furthermore, no content of cfossguy.blogspot.com has ever been reviewed and/or endorsed by my employer.

A Little SQLite Goodness for Android

2009-11-28T08:23:00.000-08:00

I recently pattern locked my Sprint PCS HTC Hero and, somehow locked myself out of my phone completely. And, like many others, I found out that once you do this, there's no easy way to get back into your phone: http://forum.xda-developers.com/showthread.php?t=485903. Instead of calling technical support, I decided to solve the problem on my own and here's what I did:

I was lucky in that I had already enabled USB debugging on my phone. Otherwise, I would have been totally dead in the water. So, I highly recommend that you download the android development kit and turn USB debugging on before breaking your phone: http://developer.android.com/sdk/. If you have the android SDK and you change your phone settings to: Settings -> Applications -> Development -> USB Debugging = enabled, then you can hack at your phone from your computer.

Plug phone into computer via USB
Download http://zenthought.org/tmp/asroot2
adb push asroot2 /data/local/ && ./adb shell chmod 0755 /data/local/asroot2
adb shell
/data/local/asroot2 /system/bin/sh
chmod 777 /data/data/com.android.providers.settings/databases/settings.db

Now, you have root access to your android phone and you have changed the permissions to the "settings.db" so that you can pull/push it from your computer back to the phone. Many thanks to "briankwest" and this post for that valuable tidbit. Next, comes the hard part that I had to figure out on my own:

Pull the sqlite database file from your phone settings using this command: adb pull /data/data/com.android.providers.settings/databases/settings.db ./settings.db
Make a copy of this file to make sure you can push the original settings back, if needed: cp settings.db settings.db.bak
Download SQLite database browser from here: http://sourceforge.net/projects/sqlitebrowser/
Open the "settings.db" file that you pulled in #1 in SQLite Database Browser
Browse data in the "system" table. You are looking for 2 rows: "lock_pattern_autolock" and "lockscreen.lockedoutpermanently"
Make sure both rows have a value of "0" instead of "1". You can use SQLite to modify this data once you've browsed to it
Save the database file and close the SQLite browser
Push the sqlite database file back to your phone using this command: adb push settings.db /data/data/com.android.providers.settings/databases/settings.db
Turn your phone off/on and your phone will no longer be locked! And, you don't have to worry about fixing the permissions on settings.db. When your phone started, it reset the permissions on that file back to the default, which means you will have to root back in and re-chmod if you didn't update the settings.db file properly.

This information kept me from calling Sprint PCS customer service, something I only do if absolutely necessary. Also, this is a nifty way to change pretty much any SQLite data on your phone.

Excellent Blueprint for Startup Success

2009-09-20T08:00:00.000-07:00

If you work for a startup or if you take the plunge and create a startup, it is wise to learn more about proven principles for success. Often times, startup experience alone is not enough, because most startups fail and many of those failures are the result of repeating the same mistakes over and over. For those of us that started our career in large, well funded companies, the bare bones nature of a startup is unnerving. We will attempt to put proven "big company" processes/methodologies in place to ensure success, and we will be a key contributor to failure. Entrepreneurial superstars will revolt against any process/methodology and insist on constant change and micromanagement. And, those superstars will also be key contributors to failure. So, how much process should be present in sales, marketing, and product development? The answer is, it depends. Thankfully, this book explains, "it depends" and provides an invaluable blueprint for maximizing the chances of success.

There are two things you should know about this book before purchasing. First, the author, Steven Gary Blank, is a real-deal Silicon Valley VC veteran that teaches for both Stanford and Berkeley. This book is a great way to obtain MBA grade knowledge without quitting your day job. Secondly, the book is not cheap($40) but it is poorly edited. There are quite a few typos and the graphics are borderline bad, but if you look past the lack of editing polish, you'll realize that this information is easily worth ten times its cost. The book was released in 2005 and four years later most startups still ignore these proven principles. But, a new term for this type of startup has emerged, The Lean Startup. Here are three good resources that will get you up to speed on lean startups:

Books that Chronicle the Brave New IT World

2009-09-13T06:46:00.000-07:00

I recently finished reading an interesting book: What Would Google Do?, by Jeff Jarvis. While reading the book, I kept thinking about how this book builds upon many of the same ideas of another great book: The World is Flat, by Thomas L. Friedman. In fact, I believe that Jarvis' book chronicles the rise of a new breed of technology companies. And, Google is the poster child of what works in this Brave New IT World. Every enterprise developer should read both books. Moreover, after reading both books, you should be very concerned if the company you work for violates or ignores the laws that define this new age.

The World is Flat

I must admit that I've had my copy of The World is Flat: a Brief History of the Twenty-First Century for a couple years and I just recently read this excellent book. I was worried that the book would be outdated but I was surprised to find that the principles outlined in the book are dead on and will be applicable for several decades. Some aspects of the book scared me quite a bit. The most bothersome chapters are:

But, what makes this book timeless is the detailed review of the ten key flatteners that have led to the current state of the Information Technology industry. None of the flatteners are earth shattering discoveries, but I was surprised by the significant societal impact of these flatteners.

What Would Google Do?

I began reading What Would Google Do? immediately because I'm enamored with Google's technology and the way they are changing the world we live in. The following chapters describe the principles Google follows to dominate the search and advertising market and spread its dominance into other markets, like mobile(Android), and a wide array of applications.

New Relationship
New Architecture
New Publicness
New Society
New Economy
New Business Reality
New Attitude
New Ethic
New Speed
New Imperatives

This book explains how companies can embrace this Brave New World and re-use the ideas that led to Google's success. I use the concepts in this book to question my company's product development/delivery strategy. And, I believe that going against these laws is a recipe for disaster. Ironically, WWGD? does not have a preview on books.google.com, but a free Google like preview can be found here. the author does blog heavily at buzzmachine.com, and a good synopsis of his book can be found here.

The World is Flat describes how we arrived in this Brave New World. And, WWGD? provides survival tips for this Brave New World. Read them both and you will have a better understanding of the rules that dictate your fate as a technology professional.

HTML5 is a Big Deal for Enterprise Developers

2009-07-03T08:45:00.000-07:00

I was recently made aware of HTML5's canvas element and I believe that this could render Silverlight, JavaFX and Flex obsolete.

HTML5 Canvas Overview
The "canvas" tag allows you to embed script based graphics, usually JavaScript, in your page. The Filamant Group blog has an excellent writeup and they also provide a jQuery based charting script: http://www.filamentgroup.com/lab/creating_accessible_charts_using_canvas_and_jquery/.
For $80, the RGraph Beta is available: http://www.rgraph.net/. For custom visualizations, Mozilla provides an excellent canvas tutorial: https://developer.mozilla.org/en/Canvas_tutorial. For neat animations check out: http://jeko.free.fr/megapong/ and http://code.google.com/p/cakejs/

Why this is a Big Deal
HML5 is a big deal because it provides a standards based alternative to Silverlight, Flex and JavaFX. Expect the leading Ajax frameworks, like JQuery and GWT, to provide programmer friendly APIs for common visualizations. I was unable to find a good canvas visualization designer, but I do believe that we will see several in the coming years. Also, I expect canvas support on mobile devices even if Microsoft refuses to support it in IE. It looks like Firefox, Chrome, Safari and Opera already support canvas. And, I fully expect IE market share to continue to decline making it more likely for IE to suck it up and support HTML5 properly: http://www.w3schools.com/browsers/browsers_stats.asp.

Key Missing Ingredients
The missing ingredients for a HTML5 revolution are:

IDE Tooling - A killer HTML5 IDE that rivals Adobe FlashBuilder and Microsoft Expression is needed. Unfortunately, neither Microsoft or Adobe has an incentive to innovate here.
Framework Support - jQuery, GWT and other leading Ajax frameworks need to make it easy for programmers to build nice canvas based visualizations. I see significant movement here and I do believe that this will happen.
Blogs, Books and Success Stories - Programmers need to blog about HTML5, good books are needed on HTML5 for mobile/desktop and noteworthy success stories will round out the triple threat.

I hope HTML5 gains momentum and I will be keeping a close eye on this technology. Google has deep pockets and a lot to gain if this technology can replace plug-in based RIAs.

Ideas for Improving Software Quality

2009-06-20T09:17:00.000-07:00

Poor software quality is bad and should be avoided at all costs. Maintaining a high quality level is increasingly difficult as the project duration and team size increase, but it is not impossible. If you are using Scrum or another compatible agile methodology these ideas will help bring quality back.

MVP and Wall of Shame
At the end of every sprint, designate an MVP(Most Valuable Player). This MVP is the developer that has the highest feature to defect ratio. If you have a sophisticated issue tracking system, it will be easy to get this information, otherwise you will have to use a more subjective determination process.

It also helps to maintain a Wall of Shame list that goes out to the entire R&D organization on a weekly basis. Developers get on the Wall of Shame list when they:

Break the build
Fail to provide adequate unit tests for code
Commit code that passes unit tests but fails a simple functional test

Be careful with the Wall of Shame. It should be easy for developers to get off the Wall of Shame list, and no developer should stay on the list for more than one week. If a developer stays on the Wall of Shame for more than two weeks or is a frequent Wall of Shame member, he needs to be kicked off the project. Conversely, if a developer drastically improves his performance after going on the Wall of Shame, you need to acknowledge it and let the team know that this member has more than made up for his mistakes.

Automated Functional Testing
Unit tests are important but automated functional tests are also needed, especially if the project uses RIA(Rich Internet Application) technologies like Flex/GWT. Flex is hard to unit test, but RiaTest is a good tool. Resist the temptation to delegate functional test automation. The developer should maintain functional tests as part of normal code maintenance. This tenet is very hard to stay committed to, so expect less than ideal automated functional test coverage and fight hard for more each and every day.

Integration Test Cycle
After a sprint, resist the temptation to immediately begin a new round of development. If you have a demo worthy product at the end of the sprint, spend up to a full week on integration testing. Every developer, lead and QA team member should be fully dedicated to this test effort. If a developer finds a defect in his code, that defect should NOT put him on the Wall of Shame list, no matter how inexcusable. The developer should be commended for finding and admitting the flaw. The only "Get Out of Jail Free" time is in this short integration test period. Outside of this period, all defects are candidates for the "Wall of Shame".

These strategies can improve the quality of your software, but like all good ideas they are no silver bullet. As the size of a team and project duration grow, the likelihood of apathy increases. Team members assume that someone else will fix a problem, and a problem can explode into an impressive list of problems quickly. Your goal as a Leader is to keep this from happening, and if apathy creeps in, ruthlessly destroy it.

Blueprint for Getting Agile Embraced by the Enterprise

2009-05-31T06:13:00.000-07:00

I have always been a strong proponent of Open Source, and I have had success in convincing others to adopt Open Source. But, when it comes to development methodology, I resisted the temptation to push agile practices, until recently. The good news is that my first foray into agile was highly successful. My path is as follows:

Added the Agile Software Development Ecosystems book to my Safari book shelf and I actually read the book.
Selected the methodologies that I thought could best address our project development needs. In this case, I picked Scrum and XP(Extreme Programming).
Created a power point presentation and pitched it to the other lead architects and our managers. The power point was essentially a short overview of Scrum, along with a list of XP principles that would be combined with Scrum. Controversial XP practices like "pair programming" and strict "40 hour work week" were not included in this presentation. I will explain why a little later.
After receiving valuable feedback, I refined the power point and pitched it to the entire R&D organization. The interesting thing about doing #3 first is that this was no longer my idea. This pitch was now Management's idea. The end result was immediate acceptance, with a few intelligent, thoughtful concerns that were addressed in the meeting.
We began immediate implementation of Scrum and XP, but we modified both methodologies to fit our business and process needs.

Why I Eliminated Key Aspects of XP
The number one reason is because I don't believe in pair programming or a strict 40 hour work week. But, even if I did, I was not willing to risk the whole, adoption of agile, for those two XP principles. My goal was to get Scrum adopted as the product development and business requirements management process and gain acceptance of TDD(Test Driven Development), collective ownership, and CI(Continuous Integration). Accomplishing those goals and nothing more represented a quantum leap compared to what existed prior.

What I Would Have Done Differently
I would have spent more time addressing the real process and software needs up front before presenting. I was fortunate to have strong Management backing and I was dealing with a group of engineers that were not staunch waterfall advocates. We had some growing pains with CI(Maven, Nexus and Hudson). TDD is still something that we are trying to get better at, and our issue tracking system was not paired up with Scrum properly for the first nine months of development.

Despite the challenges, we are doing well. I think that is because I donated my idea early, allowed others to shape and mold that idea, turning it into a better idea, and in the process that idea became the domain of the collective group. The Open Source mindset is very powerful when it is applied in the Enterprise, and I attribute a large portion of our success to staying committed to key OSS principles.

Advice for Software Entrepreneurs

2009-05-23T10:00:00.000-07:00

Of course you should take this advice for what it is. I am a Java Open Source guy that has been working on a new Flex based product for the past year. I am not an Adobe Flash guy and I have not done a lot of high end visualization work. My take on Flex is from a Java Architect perspective.

You have an idea and you're sure you want to use Flex, right?
Flex and Flash provide a great way of visualizing data via sophisticated chart views or 100% custom components. But, when it comes to standard application screens, often times you will be able to develop a system faster using other technologies. The hot RAD(rapid application development) framework for the web right now is Grails. Google also has a very interesting platform for building and hosting prototype applications: http://code.google.com/appengine/docs/whatisgoogleappengine.html. Flex can be mixed with either platform without a lot of effort. Most people refer to this type of application as a “web mashup” architecture: http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid) and these two platforms are gaining attention because they automate build/test/deploy without the need to create formal software build infrastructure. If the application size is medium to large, I think it makes a lot of sense to use Flex for high quality visualizations, “hot fudge sundae with sprinkles screens” and a different technology for “steak and potato” screens. If the app is small, keeping everything Flex is probably the way to go, provided you have the need for high-end data visualization. Otherwise, Grails is the way to go.

You need experienced Flex talent, right?
This issue is a bit tougher because there’s still a shortage of Adobe Flex talent. I would avoid Flex gurus and focus my attention on Java developers that have a strong Open Source and UI design acumen. Key skills for UI design are: GWT, jQuery, Prototype and JSF/JSP. Key skills for Java are Hibernate, Spring, Groovy, Grails, JUnit. If someone can talk intelligently about these technologies and has a desire to master Flex, they are a good candidate for Flex and the back-end code that will be needed. For Flex talent, key skills are Actionscript, MXML, AMF remoting via BlazeDS or GraniteDS and Web Services. There are a lot of Adobe Flash guys out there that may be a horrible fit for a start up. Designing a beautiful user interface usually involves significant server side code effort, and many Flash guys are not proficient in AMF remoting or server side database programming. If I had an idea and funding, I would stay away from this type of programmer like the plague, and focus my attention on finding well rounded talent. If I needed high end graphic design work, I would use a contractor that’s well versed in Flash, for a very short engagement. Ideally, one month or less if I can negotiate it.

In this tough market, it takes courage to create a new software product. I hope this helps and I wish you luck.

Maven: Not Evil But Not Great, It's Just Good Enough

2009-05-16T15:00:00.000-07:00

I am getting really tired of "I hate Maven" sentiment. Maven is not great but it is not pure evil either. Maven is the dominant build system for enterprise Java applications because:

Maven provides one good way of structuring projects, and severely punishes deterrence from the Maven Way and rewards compliance with powerful build system automation.
Maven has a wide array of plugins for most build tasks and it is easy to find information on many Maven plugins.
Maven is the default standard for dependency management in popular Open Source projects. Ivy provides a good alternative, but it will not be compelling until more Open Source projects switch to Ivy from Maven for dependency management.
The Q4E Maven plugin for Eclipse makes using Maven in Eclipse enjoyable.
Getting started is easy. Seam, Grails and Google GAE contain noteworthy alternative build systems, but each has its own set of drawbacks.

One reason many people dislike Maven is the forced project structure and sequence of build operations for common tasks like application build and deployment. I used to be one of these people, but then I took a look at what my mountain of ant work really is. It is the same thing done over and over, but ever so slightly different. And, my desire to do things different was often misguided and not needed. In my experience consistency, especially in R&D is grossly underrated, probably because most good developers are individualists and feel the need to constantly make things better. Often times, Maven will punish this individualism. I used to hate Maven for this but now I realize the error of my ways.

A second reason to dislike Maven is build slowness. I have seen this first hand, but the culprit is not Maven, it is Flex. Flex compiles take forever, so the project build/deploy takes forever. I already blogged about my disdain for Flex in this area, so I will refrain from rehashing those thoughts.

The third reason a lot of people dislike Maven is stability. While Maven is quite stable, many of its plugins are not, and it is really hard to figure out where things went wrong when a plugin fails. I think this is the double edged sword of Maven. Yes, the plugins keep you from writing mountains of ant targets, but they also hide how your build system really works from you. It is something that can be overcome, but you have to get over your hatred of Maven and learn its internals. The interesting thing is, if the problem was in an ant target that a fired employee wrote two years ago, the challenge would be identical, but your position would be worse. With Maven, you have the advantage of being able to Google for a solution.

I'm going to add a fourth issue that may not be common but I've had to deal with it. When you have Eclipse and in particular FlexBuilder, compiling and deploying non Java artifacts to a test server, but Maven is used to deploy Java based artifacts, weird things can happen. I believe there are two common root causes. Either Windows has inappropriate file locks that cause problems for Maven or there is a Flex/Java code mismatch. Maybe this is only an issue for Flex/Java projects that use Flex AS code generation, but I suspect others have experienced weirdness between various Eclipse builders and Maven.

The last popular argument that anti-Maven people make has to do with the belief that the Maven repos in the Open Source community are of little value. I disagree with them. I think SpringSource, Red Hat, Codehaus and others do a good job managing dependencies for the entire enterprise Java community. The repos are not always perfect but there is great and free software that enables selective adoption of external dependency trees. Adopt either Artifactory or Nexus and get the best of both worlds.

In the end, you can either stick with Maven or move to an alternative build system. I do not believe Ant+Ivy is compelling, it is just the "do it yourself" build system that has a different set of problems yet results in the same overall complexity level, with one huge drawback. You will be the sole developer and maintainer of your Frankenstein build system. I am not ready to ditch Maven but I am keeping a close eye on alternative build technologies like Groovy Grape and Gradle. And, I have already embraced Gant in place of vanilla Ant. I know how to make Maven work, and I'm well versed in alternative build strategies, even deceptively simple alternatives like Grails. Maybe my insistence on sticking with Maven means I am evil. But, I hope it means that I am pragmatic and that I focus my effort on what really matters, building great software not a great build system. Maintaining a good, Maven based build system is not trivial but the alternative is not a walk in the park either.

Drools and Grails Should Win Community Choice Awards

2009-05-09T11:00:00.000-07:00

I submitted two nominations for the Sourceforge.net community choice awards this year. My decision criteria was based on three key tenets:

Enterprise grade, compelling project that can be used to solve a wide variety of problems.
Under utilized but rapidly gaining momentum in the enterprise software development realm. In 2004 great projects like Hibernate and Spring would have matched this criteria but five years later Hibernate/Spring are enterprise stalwarts.
Availability of vendor support and consulting services.

Grails
Many organizations should seriously consider building all prototypes and most real applications in Grails. Grails significantly reduces the lines of code required for an enterprise application without forcing Rails like database conventions. Grails runs on a standard JVM and it integrates with other frameworks better than anything else out there, including Seam. If your project leverages Spring, Hibernate, Spring Security(AKA Acegi), AJAX including (GWT, JQuery, Prototype), then Grails needs to be considered. The two things that really set Grails apart are its plug in based architecture and Groovy. Grails plug ins provide a nice way to pull in and upgrade other frameworks. And the use of Groovy as the programming language allows Grails to make mundane tasks, like data bootstrapping, MVC(Model View Controller), security, and CRUD(Create Read Update Delete) incredibly streamlined. The end result is rapid application development without compromise. I joined the Grails party late but the Sp ringSource acquisition, subsequent surge in downloads, and good Netbeans tooling have won me over. Grails has been around since 2006 and it is ready for the big leagues.

Drools
Having worked for JBoss and then Red Hat, I feel compelled to pick the new JBoss.org heavy hitter. Drools is the best way to de-couple business rules from Java code. Drools is fast, the Eclipse IDE tooling is good, and the BRMS(Business Rules Management System) makes it a serious threat to the proprietary competitors. Drools has some cool features, like rule flow, robust rule attributes, and useful conditional elements. Drools is the Hibernate of the rules engine space. It is the best Open Source framework in its category, it is full featured enough to displace proprietary alternatives, and it fits nicely in any Java project. I think Drools will evolve into a full featured rules engine with CEP(Complex Event Processing) plus BPM(Business Process Management). Drools has been around since 2001, and it should used in all business rules intensive applications. If your project uses a proprietary rules engine, be on high alert. You might need to learn Drools or face being replaced.

What projects are you voting for and why?

Will the Terrible Economy Help OSS Businesses Flourish?

2009-05-02T09:00:00.000-07:00

Many still question the viability of the OSS(Open Source Software) business model, despite the fact that Red Hat has been profitable for quite some time. Maybe that is because there are no other profitable, publicly traded OSS companies. And, many people do not believe that Red Hat is a pure OSS company, and I agree with them. But, RHN(Red Hat Network) is a valuable service that warrants proprietary underpinnings. And, since Red Hat contributes the vast majority of its engineering resources to pure OSS development and maintenance, it deserves to be recognized as an OSS company.

I bold the word service because that is how many OSS based companies will flourish, especially in down economies. Service is not about auditing customers to increase licensing revenue and gouging them into an operating loss. Service is about solving your customers' problems by bringing highly specialized knowledge and process to them. Companies like Black Duck Software get it and seem to be doing well, recent news post. Black Duck also contributes to the OSS community by providing Koders.com, a useful source code search tool, to all.

Other companies will follow this model, and they will succeed. And, one very large and profitable publicly traded company should be considered an OSS organization. Many will disagree with me on this but I believe Google is poster child for the next phase of OSS. I know they are one of the most secretive and proprietary companies in the world, but no one can deny that they are contributing an impressive amount of engineering effort to OSS. My running list includes:

http://code.google.com/ - Sourceforge alternative, but far better.
http://developer.android.com/ - Pure OSS mobile platform, and soon to be the dominant mobile platform.
http://code.google.com/webtoolkit/ - AJAX framework for Java developers with Eclipse based tooling.
http://code.google.com/apis/visualization/ - Interesting OSS visualization API for fancy charts and dashboards.
http://code.google.com/appengine/ - A free platform for building and hosting Python/Java applications with free access to their highly proprietary database technology.
http://www.blogger.com - Free blogger service that I use.
http://docs.google.com - Free, hosted Microsoft Office alternative
http://mail.google.com - Free email service
http://www.google.com/analytics/index.html - A free web site analysis service.

All of the projects/services listed above help foster and promote the key tenets of the OSS movement. But, I do not think Google is providing all of this free stuff out of the kindness of their hearts. Google understands that a strong OSS community increases its profit and reduces cost. That is great for Google and even better for the OSS community.

Full Disclosure: I'm a former JBoss/Red Hat employee, a GOOG shareholder, and a loyal Google technology consumer.

What Will Strobe Mean For Enterprise Developers?

2009-04-24T16:33:00.000-07:00

I just stumbled upon the news release of Adobe's new Strobe technology and I can't help but wonder what I will do with this technology. After thinking about it for a few minutes I came up with the following ideas:

I receive a daily video feed of offshore work completed the day prior and have the ability to quickly record and publish a video myself. All videos are catalogued, and easily searched via a fancy Flex front-end.
Create training/mentoring material using a JIT(Just In Time) model. When I find that the same people continually get stuck grokking the same problem, and that knowledge is hard to disseminate via wiki, I record/publish/share my knowledge in video format.
Not for me, but great for managers that like to talk but not listen! Record a "State of the Union" message that delivers information employees need to know, but Management is not quite ready to answer any questions around that information. Add content viewed confirmation hooks so that Management is informed when all employees have viewed the video.
Record and publish a high quality technology deep dive on my Mac in half a day or less. Post a link to my video on dzone, and charge a small $1 to view that content. I make $100 bucks and I have indisputable tech guru bragging rights.
Same as #4 but this time record a product demo and give the content away for free. My company makes more money, and I get to keep my job.

I just hope our CTO doesn't hear about this technology because he'll come up with fifty different ideas, all deceptively straightforward until it's time to write some code.

Flex Candy is Sweet, but it'll Make Your Tummy Hurt

2009-04-18T06:03:00.000-07:00

I've been working on a flex project over a year. I started out enamored with the super sweet eye candy that's easily produced in Flex. And, although most of my contribution to the project has been via back-end code and CI implementation, I've participated in the creation of some really cool stuff. But, just like the real thing, too much Flex candy will cause an upset stomach. I'm a little sick of Flex, and here's why:

Slow compile time - This gripe is pretty much a known fact to anyone working on a decent size Flex project. To make matters worse alternatives like Grails + GWT or jQuery or ExtJS shine in this area. I know slow compile time will be addressed in Flex 4, but I think it's a shame that Adobe hasn't made it better for Flex 3 developers. I feel like I've traveled back in time to my WebSphere 4 days. Waiting 2+ minutes for a code round trip should be long gone by now but Adobe has brought it back.
Unit test challenged - We found Flexunit to be an inadequate way to test our Flex code. So, we turned our attention to HP's Quick Test Professional (too expensive to even consider) and Borland's SilkTest(doesn't work). We did find a good tool, RIATest, but we had to wait for it to mature. We also had issues testing some custom components but we were able to make our code test tool friendly. Our latest unit test challenge involves a Flex component vendor that is not compatible with functional test tools. Our workaround is to limit the use of the vendor components to a small number of screens and test around that area of the application.
Load test challenged - JMeter kind of works, but it doesn't help you pinpoint AMF bottlenecks and it doesn't provide an easy way to interrogate or view the AMF requests/responses in plain text. WebLOAD and NeoLoad both work. Neither tool is cheap, but if you are committed to Flex, pick one and use it. I prefer NeoLoad.
Remoting challenged without some custom mojo - I can't share a lot about how we addressed the challenge of remoting to a large set of POJOs, but I can tell you that you will want to either create custom code to reduce the Flex XML boilerplate code, or go with GraniteDS's new Tide stuff. If you want to support both HTTP and HTTPS remoting for the same objects without 2 sets of configuration files, you're going to need some custom AS code. Lastly, if you want strongly typed AS objects, you have to use AS code generators. AJAX isn't any better here, but if Adobe can deliver strong typing to POJOs without code generation, it'll be very nice. Right now, it's barely acceptable to some and totally out of the question for anti-code generator folks. I know that FlexBuilder has some nice stuff for SOAP, but we're not interested in webservices based remoting.
Maven challenged - We were able to integrate flex compilation into our maven scripts but it wasn't easy. And, we've had issues with Maven and Flex from Day 1. I think most of the issues are centered around our desire to compile/deploy Flex code using FlexBuilder. We need this to keep developers productive. But, command line oriented developers and our CI tool need to use Maven to compile and deploy both Flex and Java projects. FlexBuilder and Maven can step on each other, especially on Windows Vista, resulting in weird file write issues. I can't tell you how many times I've had a shouting contest over this simple statement, "Did you do a clean build?". The answer's always 'yes', but often times a real clean build resolves all issues. That's easier said than done when Windows lets Maven believe that a file has been deleted, when it really has not.
Custom components screw up FlexBuilder design view - This is one of my personal gripes, mainly because I'm not a hard core AS/MXML guy. I like to see what the screen's going to look like in design view. Unfortunately, when you create custom MXML controls, the design view breaks. Maybe, we didn't write our controls correctly. Or, maybe I have to do something special in FlexBuilder for those controls to be recognized. But, I don't think either is the case. It's just the way things are when you go custom in Flex. You still have code completion for both MXML and AS, so real Flex studs remain highly productive. It's the GUI challenged guys that suffer. And, that suffering would be greatly reduced if my #1 complaint was resolved.

If Adobe can resolve gripe #1, Flex adoption will increase, otherwise RIA teams will migrate to other options. The Open Source community is doing a good job addressing #4 and #5 but a little more help from Adobe wouldn't hurt. I like Flex but I'm very happy that it's not the only viable RIA option. Adobe has stiff competition and I believe the next big battle ground is mobile. Will Flash be the preferred RIA platform for mobile devices? It's too early to tell, but my vote is, "No".

My Artifactory Versus Nexus Experience

2008-09-26T18:17:00.000-07:00

Like many software development teams, my team needed a decent internal maven repository. So, one of my trusted colleagues who just happens to be the smartest Java guy I know setup Artifactory 1.2.5. For those of you that haven't taken the time to setup an internal Maven repository, just know that you can get up and running with very little effort.

Some of the benefits of an internal maven repository

Proxy and cache JARs from 3rd party repos. This will usually decrease maven build time for first time builders. Of course, subsequent builds usually pull jars locally from the developer's .m2 cache.
Turn off proxies once all needed 3rd party JARs are available in your repo. This will reduce the risk of introducing broken dependencies, corrupt JARs or unwanted dependencies.
Deploy internally developed artifacts to a repository. Those artifacts can be downloaded by other internal development teams, but unavailable to the general public. Obviously, this is desirable for software companies and corporate internal IT teams.

There are other benefits, but these are the big three that motivated our team to setup a maven repository. We chose Artifactory 1.2.5 with default settings.

Some key aspects to Artifactory

Jetty based unzip and go solution. But a WAR is available that can be deployed to Tomcat if desired.
Artifactory uses a JCR based repository called JackRabbit. I really don't like this design choice.
Artifactory is user friendly and relatively straightforward to setup, assuming you are comfortable hand editing a single XML file for configuration.
If you want to run Artifactory as a windows service, you must create your own JavaService wrapper.
There is adequate security and user/role management.

Artifactory would still be in place right now if it weren't for one serious problem. Once our WAR became rather large (45MB), we started experiencing 500 errors that appeared to be caused by JCR node lock issues that made it impossible to deploy new internal artifacts. This crippled our development team in the middle of a very important sprint. In all fairness to the Artifactory guys, I didn't reach out to them for help. I googled for 1.2.5 issues and a common fix suggestion was to upgrade to 1.3.0-Beta. After googling for 1.3.0 upgrade suggestions, it became apparent to me that I would have to re-install and re-configure Artifactory. Since my manager, the second smartest Java guy I know sent me a link to Nexus a couple weeks earlier, I felt compelled to give it a go.

Here's my take on Nexus

Nexus is a Jetty unzip and go only offering. There is no easy way to run it in Tomcat.
There is no need to hand edit a XML config file. All of the setup can be done through the GUI. The GUI is ExtJS based and prettier than Artifactory, although I don't give a hoot about that.
Nexus provides a JavaService wrapper for Windows.
Nexus has a really nice feature that allows you to merge several repositories and publish them via a single URL. There is no need to have multiple URL entries in your pom.xml file or conduct tedious repository administration.
Nexus stores artifacts on the file system. It is easy to browse/fix these files outside of the GUI if something goes wrong.
Nexus time stamps all deployed artifacts. I'm not a huge fan of this because it makes the disk consumption higher than artifactory, but you can setup a scheduled task or cron job to clean up old JARs.
Nexus URLs for the latest version of an artifact are redirect URLs. Artifactory URLs don't ue re-directs and are easier to embed in scripts.
There is adequate security and user/role management.

Verdict

The Artifactory deploy issue confirmed my hatred of Jackrabbit. There are times when a JCR repository makes sense, however I don't believe a maven repository warrants a JCR backend. I think a vanilla fileystem based repository makes more sense and is easier to manage and fix. I think both projects are very good choices, but I believe Nexus 1.0.0 is better than Artifactory 1.2.5. Since both projects are in active development it is important for you to assess the latest stable offering of both projects and pick the one you like the best.

Extend Your Favorite Framework with Custom Annotations

2008-09-01T16:03:00.000-07:00

Introduction

Java annotations have replaced a great deal of XML wiring in enterprise applications. Hibernate, Seam Spring and EJB3 all provide annotation alternatives to XML wiring. The end result is faster development with IDE code assist and a significant reduction in the lines of code required to annotate versus XML wire. Now, that annotations are widely used as a alternative to XML wiring, it is important for developers to take annotations to the next level. When your favorite framework lacks a specific annotation, don't panic. When you see that a @Whatever seems to magically provide something special, don't get intimidated by its mysticism. Java annotation chrome isn't hard to do. Just follow a few simple steps, and you'll have everyone using your @Whatever voodoo magic.

Write the Custom Annotation

To keep things simple, the custom annotation for this blog is going to be a simple audit annotation. The audit annotation will write output to the console, but we will create a few annotation parameters that affect auditor behavior:

Audit.java

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Audit {

   AuditLevel auditLevel() default AuditLevel.MEDIUM;
   String message() default "Audit Message";

}

AuditLevel.java

public enum AuditLevel {

   LOW,
   MEDIUM,
   HIGH

}

This is a standard runtime annotation that can be added to any method declaration. Notice that the annotation does not actually do anything. It is just a marker with meta-data. I added an enumeration because a lot of annotations take enumerations as arguments.

Find a Interception Point

Intercepters are common in frameworks and the major frameworks have at least one good way to attach custom annotations. How you intercept will depend on the type of application and annotation but the most common options are:

Spring AOP Interceptor - This approach is pretty much a catch all, and can be applied when request listeners or framework specific extensions are not desired. More information about Spring AOP can be found here.

Framework Specific Extension Points - Hibernate Validator is the poster child for excellence in providing interception hooks for custom annotation processing. More documentation on this approach can ben found here.

Request listeners (often configured in web.xml) - If you're building a web application, this approach is the most straightforward way to intercept and attach custom annotation processing. However, testability, flexibility and elegance are compromised quite a bit. This isn't the best option for all annotations, especially annotations that are not request centric, but if you want to avoid AOP or framework extension points, this approach will work. Here are a few common listeners that can be sub-classed:
- Granite/Spring - org.springframework.web.context.request.RequestContextListener
- Spring MVC - org.springframework.web.servlet.DispatcherServlet
- Seam - org.jboss.seam.servlet.SeamListener
- Struts - org.apache.struts.action.ActionServlet
EJB3 Interceptors - EJB3 interceptors behave like Spring AOP interceptors, but they are less flexible. I'm not a fan of EJB3 interceptors, but they do work and can be used in EJB3 based applications. More information on EJB3 interceptors can be found here.

Once, you've made a decision on the proper interception point, it's time to attach your custom annotation processing logic. This article will demonstrate a Spring AOP Interceptor that can intercept pretty much any call. This example can be converted to a Request Listener or EJB3 based implementation, but why bother when Spring AOP gets the job done?

SystemArchitecture.java
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class SystemArchitecture {

   @Pointcut("bean(*Service)")
   public void inServiceLayer() {}

}
This class defines our point cut. The point cut is just a fancy way of saying, "Spring bean services with a name that ends in 'Service' are going to be inspected for interception." It does not mean that every method will be intercepted, just inspected.

ServiceInterceptor.java

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;

@Aspect
public class ServiceInterceptor {
@Before(value="cfossguy.examples.annotation.SystemArchitecture.inServiceLayer()" +
           "&& target(bean) " +
           "&& @annotation(cfossguy.examples.annotation.Audit)" +
           "&& @annotation(auditable)",
     argNames="bean,auditable")

   public void performAudit(JoinPoint jp, Object bean, Audit auditable) {

      System.out.println(String.format("Audit Level: %s",auditable.auditLevel()));
      System.out.println(String.format("Audit Message: %s",auditable.message()));
      System.out.println(String.format("Bean Called: %s", bean.getClass().getName()));
      System.out.println(String.format("Method Called: %s", jp.getSignature().getName()));

   }
}

ServiceInterceptor.java is where the real magic happens:

There is a @Before annotation declaration that starts with a reference to the SystemArchitecture point cut
If the point cut contains a spring bean, it'll be passed as a argument named "bean"
If the cfossguy.examples.annotation.Audit annotation is present, it'll be passed as a argument named "auditable"
The performAudit() will use the annotation meta-data and target bean instance to display console output

It is important to note that the SystemArchitecture.java can contain several point cuts. If there are data access centric methods another declaration like this can be added:

SystemArchitecture.java
@Pointcut("bean(*Dao)")
void inDataAccessLayer() {}

The same rules apply for ServiceInterceptor.java. Additional @Before, @After or @AroundInvoke interceptors can be defined.
Lastly, here's the XML wiring required to make all of the annotation magic:

application-context.xml

<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns:context="http://www.springframework.org/schema/context"
  xmlns:aop="http://www.springframework.org/schema/aop" 
  xsi:schemaLocation="http://www.springframework.org/schema/beans 
           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
           http://www.springframework.org/schema/context 
           http://www.springframework.org/schema/context/spring-context-2.5.xsd
           http://www.springframework.org/schema/aop 
           http://www.springframework.org/schema/aop/spring-aop-2.5.xsd">
 
 <aop:aspectj-autoproxy />
 <context:component-scan base-package="cfossguy.examples.service"  />
 <bean id="pointcutMgr" class="cfossguy.examples.annotation.SystemArchitecture"/>
 <bean id="serviceInterceptor" class="cfossguy.examples.annotation.ServiceInterceptor"/>
</beans>

There are only four real lines of code here:

Tell Spring that we want to enable AOP
A component scanner that will process any spring annotations for classes in our business service package
A bean declaration for the point cut manager
A bean declaration for the service interceptor

Use The Annotation in your Code

This spring bean service has 2 methods. One method has our custom annotation, while the other does not.

BizService.java

package cfossguy.examples.service;
@Service(value = "BizService")
public class BizService {

@Audit(message = "Something Important Happened")
public void doSomethingImportant() {
   System.out.println("Important Business Service Pre-pended by a audit message");
   System.out.println("------------------------------------");
}

public void doSomethingStupid() {
   System.out.println("Stupid Business Service With No audit message");
   System.out.println("------------------------------------");
   }
}

There are a few things worth mentioning here:

The package declaration matches the component scan entry in application-context.xml.
Configuration by exception is leveraged. Since the default AuditLevel is "MEDIUM", it does not need to be declared in the annotation, if that's the proper audit level for this method.
The method missing @Audit annotation will not have an audit message.

And here's the console output:

Audit Level: MEDIUM
Audit Message: Something Important Happened
Bean Called: cfossguy.examples.service.BizService
Method Called: doSomethingImportant
Important Business Service Pre-pended by a audit message
------------------------------------
Stupid Business Service With No audit message
------------------------------------

It appears that the annotation is behaving correctly. The audit level, message and target bean details are displayed. And, the "Stupid" business service method didn't get intercepted or audited.

Conclusion

There isn't a lot of work involved in creating custom annotations. Most of the effort involves runtime interception so that the annotation declaration actually changes the behavior of your code. Hopefully this reference implementation will help you find a way to "chrome" up your code. If you are interested in the source for this article, email me at: cfossguy@gmail.com.

Getting Seam, Seam-gen and Tomcat to Work Well

2007-09-11T06:15:00.000-07:00

I recently presented on Red Hat Developer Studio at the Rich Web Experience conference in San Jose CA and the following question was asked:

What steps are involved in getting seam-gen to work with Tomcat?

My answer to this question was pretty lame. I said, it should work. When pressed for a more specific answer as to whether seam-gen would work well with Tomcat, I said that it should work with maybe a tweak or two to the seam-gen scripts. Then, I admitted that I had not actually tried to run seam-gen with standalone Tomcat, but I still didn't think it would be hard to get working. After a few restless nights, I decided to bite the bullet and get Tomcat 6, Seam 2.0.0-Beta1 and seam-gen to play nice together. It turns out that it's not all that hard to get everything working, but there are a few noteworthy things that must be done:

Configuration Steps

It's best to install the embedded ejb3 container in Tomcat 6. Instructions for doing that can be found in the Seam reference guide located here. The embedded ejb3 container will provide datasource management, JTA and full support for EJB3. While Seam applications can be run without using the embedded ejb3 container, I took the path of least resistance and installed embedded ejb3.
This step is not documented as far as I can tell, but it was required for me to get JSF working properly in Tomcat. Copy the following JSF JAR files into the $TOMCAT_HOME/lib directory: jsf-api.jar, jsf-facelets.jar and jsf-impl.jar.
The seam-gen project build script needs to be changed so that the "deploy", "explode" and "restart" targets work correctly. This can be accomplished by overwriting the project build.xml template in seam-gen. The file is located at $SEAM_HOME/seam-gen/build-scripts/build-war.xml. If you're an ant guru, the changed lines will be of interest. Otherwise, just give the attached build-war.xml file the benefit of the doubt.

Using seam-gen from the Command Line

cd to $SEAM_HOME
type: ./seam setup (behaves exactly the same as it would without our tweaks)

Make sure the "Deploy as an EAR or WAR" value is: "war"

type: ./seam new-project (behaves exactly the same as it would without our tweaks)
edit the project's build.properties file:

Add a "tomcat.home" entry

type: ./seam explode (custom build script logic is executed, and the Seam WAR file and it's datasource are deployed properly)

WAR gets copied to: $TOMCAT_HOME/webapps
datasource gets copied to: $TOMCAT_HOME/lib/deploy

Using seam-gen in Red Hat Developer Studio

Start RHDS
click: Run -> Seam Gen -> Setup/Configuration -> Setup
make sure the "Deploy as an EAR or WAR" value is: "war"
let RHDS create a new project. But, once the project is created, just know that it didn't get deployed properly.
edit the project's build.properties file

Add a "tomcat.home" entry

select the project folder and type "F5"
now, the exploded WAR and datasource will be deployed to the right place

Of course, it's easier to just use RHDS with JBossAS, but if you feel the need to use standalone Tomcat, these instructions should get you up and running.

Looks like a good JBoss Host Provider

2007-07-09T09:14:00.000-07:00

Plan pricing is as low as $20/per month with simple plans ranging from 256MB RAM, 10GB storage, 100GB bandwidth ($20/month) to 2GB RAM, 80GB storage, 800GB bandwidth ($140/month). Not the cheapest I've seen, but looks to be a good choice for the power hoster that just wants root on a decent linux box!

http://www.slicehost.com/

Java Client to native ESB Listener

2007-07-09T05:00:00.000-07:00

Their are 2 ways to talk directly to a JBoss ESB 4.2 listener via a Java client. This comes in handy when you want to communicate directly with an internal ESB listener, bypassing the gateway listener:

Approach #1 - Quickstart/Unit Tests Only (Closes JMS connection pools)

//Setting the ConnectionFactory such that it will use scout
System.setProperty("javax.xml.registry.ConnectionFactoryClass",
"org.apache.ws.scout.registry.ConnectionFactoryImpl");

Message esbMessage = MessageFactory.getInstance().getMessage();
Call call = new Call();
call.setMessageID(new URI(UUID.randomUUID().toString()));
esbMessage.getHeader().setCall(call);

// set body contents with args[2], and send
esbMessage.getBody().setByteArray(args[2].getBytes());

ListenerUtil.tryToDeliver(esbMessage, args[0], args[1]);

Approach #2 - Recommended for Most direct EPR calls

//Setting the ConnectionFactory such that it will use scout
System.setProperty("javax.xml.registry.ConnectionFactoryClass",
"org.apache.ws.scout.registry.ConnectionFactoryImpl");
MessageDeliveryAdapter deliveryAdapter;
Message requestMessage;
Message replyMessage = null;

// Create the delivery adapter for the target service (cache it)
deliveryAdapter = new MessageDeliveryAdapter("MyServiceCategory", "MyService");

// Create and populate the request message...
requestMessage = MessageFactory.getInstance().getMessage(MessageType.JBOSS_XML);
requestMessage.getBody().setByteArray(toWhom.getBytes()); //
inject the value from the WS client

// Deliver the request message synchronously - timeout after 20 seconds...
replyMessage = deliveryAdapter.deliverSync(requestMessage,20000);

if (replyMessage != null) {
results = new String(replyMessage.getBody().getContents());
}
else {
results = "Hello World: " + toWhom + " on " + new java.util.Date();
}