Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Can't we just keep it simple?

Use SOAs to add real value, not complexity, to Java enterprise applications

By Humphrey Sheil, JavaWorld.com, 01/09/06

Page 5 of 5

A proposed SOA taxonomy

By now, you probably appreciate my zeal in keeping things as simple as possible. But I'm not after simplicity per se; my main driver is pragmatism. As applied to software projects, I define pragmatism as the correct balance between commercial and project realities on one hand and software design/engineering best practices on the other. Simply put, let's build the best system we can, leveraging the resources we have available to us.

A great example of pragmatism comes from civil engineering history. Isambard Brunel (sometimes called the man who built the world) regularly built wooden bridges while constructing railroads even when he knew that iron bridges would be better. He constantly juggled the best engineering solution against the pressures from railroad company shareholders who wanted the rail line open and the initial capital investment controlled. Sound familiar?! Exactly the same principles apply to the software engineering discipline.

With this spirit of pragmatism in mind, I propose that we subdivide the SOA world into three sections: simple, medium, and complex, where the benchmark for separation is quite simply the features required to meet the business needs. If you need a simple SOA, then don't waste time and money on a complex SOA.

Simple SOA: Level 1

Example implementations of a simple SOA:

• Your own queue implementation with plain-old Java objects (POJOs) receiving and sending messages to the queue
• Java Message Service (JMS) queue/topic with message-driven beans (MDBs) as consumers of messages

Key SOA concepts covered by the simple-complexity scenario:

• Enterprise service bus
• Component model for producers/consumers

Medium-complexity SOA: Level 2

Example implementations of a medium-complexity SOA:

• JMS queue/topic with MDBs as consumers of messages, with additional attributes now enabled, including security, transactions, use of JMS metadata attributes on the core message classes, etc.
• Web services, for example Apache Axis

Key SOA concepts covered by the medium-complexity scenario are the same as the simple SOA plus:

• Error/retry queues for increased robustness and reliability
• Introduction of XML as the message payload content instead of serialized Java objects to support other technologies, specifically .Net

Complex SOA: Level 3

Example implementations of a complex SOA include:

• JMS queue/topic with MDBs as consumers of messages, with additional attributes now enabled, including security, transactions, use of JMS metadata attributes on the core message classes, etc.
• Web services
• Vendor/industry-specific SOA-enabling toolkits (especially for financial services)

Key SOA concepts covered by the complex scenario are the same as the medium complexity SOA plus:

• A well-defined and rigorous component model (for example Java Business Integration, service component architecture, or something similar)
• Enhanced vendor support, especially in the creation of new producer/consumer components to slot into the SOA
• Finally, I see the need for a component registry to detail the services available on a particular SOA implementation

Conclusion

SOA as an architecture is here to stay and will become as embedded in our minds as "client-server" or "n-tier." However, it is still relatively immature and falls prey to subjective vendor positioning at present. My advice? Start small and keep your SOA as simple as possible. Do not equate SOA to Web services by default, and do not try to force the SOA design pattern on all layers of your Java EE application, particularly the Web layer.

Which SOA implementation do I recommend for most Java EE applications? A Level 2 SOA implemented as a JMS queue with MDBs as message consumers, and POJOs or stateless session beans as message producers. However, if you are sure you will need to integrate with non-Java applications, consider a Web services implementation. It is important that the solution you adopt now has headroom for growth in the future. How far ahead to look is often the cue for debate, but I propose that the farthest forward we can look for any software application is 36 months. If you see additional SOA requirements in that timeframe, look to build them in now.

About the author

Read more about Enterprise Java in JavaWorld's Enterprise Java section.