Not Just Java

I have been asked about how we support SOA many times over the last few months.  The emergence of SOA as an architectural paradigm has been a huge influence on the middleware software market.  You can’t find a middleware or integration platform today that doesn’ t pitch how great it supports SOA.  Having built a couple systems with SOA technologies I can tell you that most of that hype is misplaced.  SOA is really a combination of two main features.  First it is an agreement by everyone to use the same syntax for interface invocations and second its a way to organize your software system’s capabilities.  The first feature is enforced by standards like WSDL, SOAP, and UDDI as well as recent additions like the SCA, SDO, and of course the collection of WS-* standards.  The second feature however really can’t be enforced.  To me the web service standards are important but I would say the organization of software into services is really the critical feature of a SOA.

Sam Charrington in a recent interview had a great quote that I’ll repeat here about how Appistry helps in a SOA architecture:

"SOA is great about providing agility from the perspective of software infrastructure," he said. "What SOA doesn’t help with is agility as it pertains to physical infrastructure. If you have a service that is mission-critical, you end up being encumbered by a traditional IT approach."

With a traditional IT approach, if a service really takes off, Charrington said, organizations may think they have to put it on an expensive box to meet availability and performance demands. "But this is not the agility of SOA; it takes away from the huge benefit of SOA."

This is where virtualization comes into play, he said. "By virtualizing applications across a commodity infrastructure, managed by, or as part of an application fabric, you’re able to get the full benefit that SOA offers."

So basically Appistry’s EAF become the "service container" in a SOA stack.  Once you have an ESB and expose your services with a WSDL interface where do you actually run your services?  You can continue to run them on legacy hardware after integrating with the ESB if you wish.  But at that point is when I ask my favorite question, "What happens if it works?"  Basically what happens if all your efforts come to fruition and people actually start using your services?  There’s really no reason to build a SOA if that’s not what you want to happen.  So what do you do when you have to scale your services beyond your legacy hardware’s capacity?  That’s when you need agility at the hardware layer.  An application fabric is the best way to bring the promise of SOA full circle to the hardware architecture.  That’s why I came up with the phrase, "The last mile for SOA".  You can get close to a full SOA without an application fabric, but you may end up pushing your integration pain into a scalabilty problem pretty fast.  But with Appistry’s EAF as the service container, you don’t have to worry about that either and you get the full benefit of the dream of a true service oriented architecture, not just a way to call code over web services.

-jasen

In order to break my slump I thought I’d give a quick description of a project I recently worked on.  I was helping set up a demo of an application that was moved onto the fabric.  The app was written in C and we didn’t change any of its code.  We ended up running it by shelling out from Java to make it easy for the developers who didn’t know C.  The person asking for the demo wanted to see our reliability feature but didn’t want to see the usual hardware demo we give which involved pulling a power cord or network cable.  So I had to invent a software bug that would illustrate how an application can be made reliable by running it on top of Appistry’s software.

So to make a short story long, here’s what my first try looked like:

Random generator = new Random(System.currentTimeMillis());
if( (generator.nextInt() % 4 ) > 0 )
{ 
   doSomething();
}

The basic idea being that by generating a random integer in the code running on the fabric I could then use the modulo operator to inject a bug about 25% of the time.  Because it’s random, it would be unpredictable (the best kind of bug).  The modulo operator would give me values from 0-3 and therefore if I got a 0 I would run the bug:

else
{
   throw new Exception();
}

The error case just throws an Exception because the fabric will attempt to retry the job if an unchecked exception is thrown.  We tested out our new bug and it didn’t work.  It was running the error case way too much.  So basically I had a bug in my bug.  After reading the javadoc on the Random.nextInt() method I figured out that it will generate negative numbers!  So I added the following fix:

if( Math.abs(generator.nextInt() % 4 ) > 0 )

Now I get my 25% failure rate like we wanted.  We show the client running and submitting a handfull of requests to the fabric.  Then, on the log on, the fabric, we show in realtime that the failure randomly occurs.  But when it does, the job is automatically resubmitted on the fabric and the answer is sent back to the client.  The client doesn’t have to be concerned with retry logic and only gets its correct answer.

I thought a cool web demo would be to use Ajax and setup a button for people to cause a software bug to happen while the results are coming back to the browser in realtime.  Maybe I’ll write that in my "spare" time…

-jasen