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

Fundamental SOA enablers

From the definition above, we should then be able to identify the minimal set of software services that must be provided to make up an SOA-enabled application. Succinctly, these services are:

• A messaging layer, allowing the transmission and reception of messages over a specific protocol. In SOA parlance, this layer is called an enterprise service bus or ESB (so-called because you can charge more money for something with the word "enterprise" in the title).
• A component model, i.e., some minimal contract to which an application must conform to send and receive messages from the message bus.

And, once again, that's it. Depending on your specific business requirements, these two services can increase dramatically in terms of complexity, but, at the very core, the combination of a messaging layer and common component model represent SOA.

Specifically, I exclude the automatic lookup and discovery of services from my definition of SOA—in most Java EE scenarios, this would be overkill. One of the driving ideas behind the Universal Description, Discovery, and Integration (UDDI) protocol is the belief that companies will eventually buy and sell to each other using software services that trawl through a vast repository of services, searching based on metadata (cheapest, most local, best quality, etc.). This dream is, at best, at least 10 years away, and may never come to fruition—people do business and make deals, not software.

Java EE applications should not automatically, for example, discover a login or payment service to use—these services are set once, at initialization time. Don't get me wrong, implementations of these services shouldn't be hard-coded into an application either, but you don't need SOA to solve that particular problem.

Next, let's move on to consider what need SOA addresses and what, if anything, it replaces.

Why SOA?

The last two major waves of software development for enterprise applications centered on the client-server and n-tier architectures. While the n-tier architecture possesses some strong advantages over the client-server architecture in terms of ease of deployment, platform support, performance, and scalability, neither architecture solves one key software-engineering problem in the enterprise computing space: how to reuse functionality written for one application in another.

As software developers and architects, we have never adequately solved the issue of software reuse. And as you read further, you will see that I do not believe SOA can solve it either. Nevertheless, software reuse is, to my mind, the number one reason for the advent of SOA, at least for Java EE applications.

Other SOA uses exist—the most well-known are Jini and grid computing. Important characteristics for a Jini-based environment are:

• Automatic discovery of components/services
• Self-healing

However, these characteristics don't apply or simply don't hold the same importance for Java EE applications. I configure the location of my database using a JDBC (Java Database Connectivity) URL once and once only. I expect the database to provide fault tolerance and graceful failover (for example, Oracle Real Application Clusters, or RAC), and I specifically don't want my Java EE application to try and auto-discover another database instance to use if my production instance goes down. On the other hand, a color printer that automatically advertises itself to an office with 2,000 workstations is a good thing and a key benefit to Jini-enabled hardware.