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

Equally, in a truly global grid-computing environment, automatic discovery and enlistment of computing resources to solve a problem at hand is a key part of the infrastructure—it isn't in a Java EE environment where the hardware is sized up-front to meet a defined user population and performance service-level agreement.

My point is, then, that SOA means different things to different people. In this article, I am concerned with SOA from a Java EE architect's perspective. And I believe that means functionality reuse. Other advantages to SOA from a Java EE perspective include:

• Loosely-coupled components, which is always a good thing in software design
• Potential total enforcement of "coding to the interface, not the implementation" by introducing the ESB as the messaging layer
• Asynchronous messaging, which increases application scalability

Let's examine the issue of software reuse in more detail by asking three specific questions:

• Why is reusing software a very good thing?
• How is SOA mooted to address the issue of software reuse?
• Does the promise of SOA in enabling software reuse live up to reality?

Firstly, software reuse is a good thing for these reasons:

• Efficiency in terms of time and cost—being able to take a suitable component off the shelf that meets a stated business requirement saves time and money on any project.
• Superior characteristics, including, but not limited to, stability, performance, manageability, documentation, and configurability. Why? Because the more a component is reused across projects, the more a team/company has invested in it, and it will improve over time.
• A well-designed reusable framework has a positive impact wherever it is used and can encapsulate best thinking on how to solve common problems—concrete design patterns if you will.

So we want reusability. What is the simplest way to get it? By packaging it as a set of well-defined components that meet a discrete functional requirement. Then, if another application needs the same component, it can be dropped in and used. There are other details to consider here, such as how do I configure it (Why, hello Inversion of Control, how are you?), but these details detract from the main thrust of my current point: to reuse lines of code written in any programming language, that code must have been designed as a set of discrete components or refactored to become that set.

Check out my first article for JavaWorld, "Frameworks Save the Day" (September 2000), for more details on software reuse as applied to Java EE projects.

Next, how does SOA approach the problem of software reuse? By building on the component model and by introducing an important mandatory requirement: that components communicate with each other via messages delivered on the ESB, thus ensuring loose coupling. In fact, the most widely deployed SOA implementation, Web services, can stitch together components developed in different programming languages by making the messaging layer technology neutral.

Lastly, does the promise of SOA in delivering software reuse live up to reality? No. I believe that SOA would solve the software reuse problem if it was invented in 1945, around the same time as the ENIAC (Electronic Numerical Integrator and Computer). But it wasn't, and billions of lines of code now exist that have been written between then and now—in COBOL, C, C++, Java, C#, and a myriad of other languages, some long forgotten but still in production somewhere.