LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Jumping Off the Bandwagon


By Allen Holub
November 1, 2005 — 
I’ve just won (I hope) a metaphoric knock-down-drag-out fight with a co-developer who adhered to BOD (bandwagon-oriented design) principles. The issues are interesting, and so is some of the technology.

The system architecture is straightforward: A “data collector” object collects real-time data from various chunks of hardware, all of which speak different protocols, and translates to a single XML-based protocol; a “history manager” keeps a historical record of that data; a UI-server builds a couple of multipage user interfaces. These components are stand-alone servers that talk to each other using XML over JMS.

I’ve been burned recently by several projects that were way more complex than they should have been, primarily because the developers mindlessly fixated on the “standard” BOD way of doing things, and I wanted to avoid that problem here.

Probably the most commonplace examples of BOD are Web interfaces built on the “standard” architecture: Web server, EJB-based application server and a database server typically wrapped in an object-relational layer like Hibernate or JDO. The UI must be built on Struts or JSF, etc. Though all of these technologies can work in the right situation, none is appropriate in every situation (and EJB is hardly appropriate in any situation—but that’s another column). An average-size Web application that used all of the above would be about two orders of magnitude more complex than necessary, impacting both cost and schedule.

My current battle concerned the “transport” and “persistence” layers. I’m a big believer in messaging (in the JMS sense). Message-based architectures are easily scalable, and messaging promotes loose coupling between components, so the components are easier to write as independent programs. I’ve come to live with XML as a communications lingua franca (though I don’t like it). Consequently, JMS Text messages carrying an XML payload have become my communications mechanism of choice.

My first battle was then getting my co-worker to abandon XML-RPC. The attraction of point-to-point communication protocols is familiarity—a remote procedure call, regardless of underlying transport, looks like a local procedure call. All RPC systems have problems, though: speed, configuration complexity, mismatches between the Java argument types and the argument types required by the protocol. The biggest drawback is that RPC systems aren’t scalable—it’s just too hard to throw on another server if you need it.

So, we tossed RPC and used the ActiveMQ (activemq.codehaus.org) JMS implementation. In the past, I’ve used OpenJMS (openjms.sourceforge

.net) for this purpose. It’s free, has been around for a long time and does the job. But based on a few weeks’ trial, I’m really impressed with ActiveMQ—it’s better than OpenJMS in almost every way. It’s faster, supports enterprise-level capabilities (like guaranteed delivery and clustering) and has a few bells and whistles that could be quite useful in some situations.

For example, it’s possible for a Web client (running on the browser) to subscribe to a message via AJAX. This way you can use messaging for virtually all network communication. At the core of ActiveMQ is a solid JMS implementation, however, and you don’t need to use any of the bells and whistles.

The next battle was persistence. My co-worker wanted to use an object-to-XML converter coupled with an object-persistence layer. For example, the raw data would be put into objects; the objects would be translated to XML, which would be put into a JMS message and sent to the history component; the history component would then convert the XML back into an object, and then store that object using a roll-your-own persistence layer that my co-worker had invented.

Replacing this thing with Hibernate is an obvious improvement, but object persistence is just not useful here. There are only a dozen or so entities involved. It will take longer to install and configure Hibernate than it will to just write the code that puts the XML into a JDOM and then updates the database using JDBC. The JDBC code will be vastly simpler to maintain, faster and smaller than the equivalent Hibernate system. More to the point, this server does nothing but translate data from one format (XML) to another (SQL). There are no objects at this level—there’s just data. Converting the data to an object solely to be able to use Hibernate to put the data into the database is a colossal waste of effort.

Where there are objects, we ended up using the XStream library (xstream.codehaus.org/index.html) to create the XML. XStream does XML serialization. Unlike Java’s brain-dead JavaBeanConverter, XStream uses introspection to generate the XML, so the serialized class doesn’t need getter/setter methods. No hideous XML configuration files are required. If you need to do something complicated, you can provide a gang-of-four Builder to create the XML for your special-purpose object, so you can synthesize XML elements if there are no associated fields.

With all the junk removed, what’s left is refreshingly simple. All network communication is over JMS. The XML payload is built using XStream serialization where there are objects; it’s built directly where no objects exist. We talk to the database with JDBC. No XM-Hell configuration files, no steep learning curve, and the system is fast, scalable and easy to maintain.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.


Share this link: http://www.sdtimes.com/link/28947
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading