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 4 of 5

The bulk of this code mass is not written as a set of discrete components that can be hooked together to create new applications, and no amount of SOA orchestration magic powder will address that. In fact, I postulate that the lion's share of work in any SOA brown-field project is spent refactoring the very same codebase that SOA is designed to give a new lease on life to.

Now, let's examine some of the problems with SOA when applied specifically to a Java EE application.

A criticism of SOA

The criticisms of SOA in this section stem from three sources:

• Deficiencies of SOA itself, based mainly on the immature implementations currently available
• Thoughts on the complexity of SOA
• Examinations of how vendors position SOA in the wider Java EE ecology of products and approaches

So, looking at SOA critically then:

• There is no formal specification in the same way that Java EE has a specification. When one is eventually published, most likely, it will be too complex and won't address the 80:20 rule (80 percent of applications need simple SOA; 20 percent need more powerful/complex capabilities).
• The issue of stateful conversations is still widely debated and is certainly not adequately solved by the default implementation of SOA—Web services. Stateless conversations, on the other hand, are very well supported.
• In the absence of a formal specification or recommendation, Web services has become synonymous in many people's eyes with SOA, when, again, Web services is often overkill.
• SOA adds complexity by default. Say what you like about hard coding and tight coupling; you don't need reams of XML configuration files to get a simple application working!
• SOA-enabling your application or product on its own achieves nothing. The business value comes from being able to expose discrete pieces of functionality through the SOA to other applications and modules. For example, if your validation routines for ordering widgets are poorly written in a JSP (JavaServer Pages) page's embedded Java code, then you will need to refactor this code into a well-defined server-side object with an API before the SOA can call it—so many vendors gloss over this important point.
• In some cases, vendors position SOA as a replacement for Web application frameworks! To my mind, a WAF is an ideal consumer of functionality defined through SOA, but it is complementary, definitely not competitive.
• Contrary to what some vendors would have you believe, some applications do not need SOA at all and should simply use a decent Model-View-Controller Web framework with an efficient persistence strategy. Short-sighted? I don't think so, and even if SOA characteristics are required, as stated above, the single most important prerequisite is a well-defined business logic layer that can be attached to an enterprise service bus, not the ESB itself.

But I do believe that an SOA has an intrinsic value once it is appropriately positioned and not regarded as a silver bullet for both existing and new applications. Let's now examine how a staged approach to adding SOA characteristics to your application will add business value proportional to the cost of implementation.