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

We are doing the European TSS show and I thought it would be fun to do some daily posts like I did for JavaOne.  I have noticed some interesting cultural differences between European techies and us Americans.  First of all, they don’t care about slinkys as much here.  We couldn’t keep our free slinkys on the table at JavaOne, here people always look at them and keep walking.  We have given some away, but people always laugh at them like they’re ridiculous.  A couple British people take them, but they always ask first which is also uncommon.  So to summarize:

1) Americans:  love slinkys, will try to trick you to get one for free, aren’t bringing them home for kids (that’s a lie they want it for their office to play with)

2) British:  partially amused by slinkys, will apologize for thinking of taking one, bringing them home to make fun of Americans

3) Germans:  think slinkys are foolish, will stare at you silently if you offer them one, may take one home to show kinder (children) how silly Americans are

4) All other Europeans:  think slinkys are part of our product, don’t realize they are toys, may take one home to beef up their car’s suspension

As for Appistry’s software however, there is a lot of interest, especially by GigaSpaces employees.  (I know they monitor use of their company name on blogs so this is a meta-joke to see if I can get their CEO to come say "Hi" to me.)  But seriously the crowd is full of architects and developers and they like to discuss how to scale Java appllications on commodity hardware.  They always ask great questions that show that they are engaged and are thinking about our solution.  From that perspective all the countires are on the same page, they don’t like complexity and expense.  Offering a simple easy to use product that cuts processing costs by an order of magnitude makes sense no matter where you’re from.

-jasen

I have been doing some reading and a few weeks ago I came across an article by Corey Klaasmeyer on JavaWorld’s website.  He discusses the original definition of what a "grid" is with some of the history.  For example he quotes Ian Foster and Carl Kessellman from The Grid: Blueprint for a New Computing Infrastructure as saying, "A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive and inexpensive access to high-end computational capabilities."

By this definition Appistry’s EAF qualifies.  But then Corey goes on to discuss the evolution of the definition and how Ian Foster has defined 3 requirements for being considerred a grid.  According to Ian a grid:

1. Coordinates resources that are not subject to centralized control;
2. Uses standard, open, general-purpose protocols and interfaces; and
3. Delivers nontrivial qualities of service.

So Appistry again easily meets 1 & 3 above.  However 2. is debatable.  We have our own xml based meta-data syntax that we use to coordinate task execution.  We have discussed exposing this as WSDL and BPEL (which would be much more verbose) but then at least it would be "standard".  We are based on good old TCP/IP and UDP/IP so that sounds like general-purpose protocols to me.  So basically if I provided a set of XSLT transforms from our succint meta-data syntax to WSDL and/or BPEL would that then make us a true grid by Ian Foster’s definition?

Corey and I met for lunch today and discussed this idea and other things over awesome food at Illegal Pete’s in downtown Denver.  Ultimately I think we both decided that Appistry isn’t the purist form of a grid, but that we were compatible with it.  We also discussed the industies move toward using the term "grid" in a larger way in the market place.  Fuzzy’s blog discusses this concept and refers to others who attempt to define the classes of grids that exist in the market place today.

We don’t like to call our product an application server or a cluster because that term has so much baggage.  If we just call it a grid then its not clear how we are different than the efforts of the original father’s of grid computing.  So we’ve settled on the term "virutualized grid".  It would be cool to hold a vote to see how developers and architects describe software in this space.  Maybe Slashdot could do a poll.  I would vote for Cowboy Neal Grid.

-j

I just read an interesting thread over at Panic from Fuzzy’s blog.  Here is the thread…

My favorite commenter Cameron Purdy of Tangosol/Oracle engaged in a friendly exchange with Fuzzy about the economics of releasing software as open source rather than keeping it closed and charging for licenses.  I am a big open source advocate and I proudly wear my OpenBSD shirt in public.  However I have never worked for an open source software company.  I don’t think that many people do actually.

Appistry is not an open source company, although we love open source software and are very careful not to lock in our customers.  I was very impressed with our CEO, Kevin Haar, when he advocated for adding even more features to our product to make it easy for customers to remain decoupled from any of our proprietary APIs.  However, we still charge money for our product and we don’t publish the source code.  But does charging money make us evil?  I don’t think so or I wouldn’t work here.  Fuzzy is clearly a strong open source advocate, but if you follow his argument to the extreme does that mean software should always be free?  Cameron points out that the amount of revenue made at a service company is much lower than a product company.  So are we here in the good old USA now supposed to give everything away because Apache and JBoss do?

I don’t know the answer, I only know that I like writing software for a living, and as long as companies like BEA and IBM are charging for their software and making millions then why can’t everybody else try?  One of Fuzzy’s points was standards, I totally get that.  Being a software architect, I have been careful to leverage standards whenever possible.  But if a product doesn’t lock you in architecturally and has years of intellectual property built up to help solve a problem, why can’t you charge for it?

I don’t think the whole software community wants to work as consultants during the day just so they can code open source apps at night.  There will always be a product market as long as the product 1) works and 2) makes sense economically.  I know full well that as our technology becomes more broad there will be a call to build an open source platform that is similar.  That’s fine, even JBoss doesn’ t have 100% market share.  And it never will, service companies cannot scale to the necessary size so a vacuum will always exist for product companies that can afford to support customers because of their license revenue.  So the waxing and waning of products and OSS will come and go.  But there will always be free software and there will always be commercial software.  That’s just the rules of the game now.

Or not.  If I was any good at making predictions about software I would have bought Microsoft stock back in the early nineties.  What can I say, I thought Windows 3.11 sucked.

-j

I’m a little behind schedule on this post. We found a piano bar and didn’t get back to the hotel until early in the morning.  I can still hear the chorus to Tiny Dancer ringing in my ears.

The last day of the booths being open at JavaOne was awesome.  We had a lot of people wanting to talk about how to solve problems.  It’s great to see people really resonate with our solution.  I was in one discussion with a guy named Mike Moleschi from the University of Oxford who presented an x86 emulator that ran on a Java VM.  It sounded really awesome.  He is also part of the group working on the Nereus Project which is a "Massively Parallel Computing" platform.  I am definitely going to have to play with the x86 emulator. I have some old DOS games that I’d love to play again.  I told my wife that saving those boxes of old software would come in handy someday.

All in all, JavaOne has been a perfect show for Appistry.  The attendees that come to the show are thinking about issues they need to solve and are looking for ideas.  I really enjoyed engaging with so many developers and architects.  The domains were diverse and interesting and the people were friendly.

I ended my San Francisco trip by shopping a little in Chinatown before catching a shuttle back to SFO.  Downtown San Francisco is an awesome place.  I hope to see you next year. Maybe the slinkys will make a come back.

-j

Today started with a keynote talk by the Oracle guys. Cameron Purdy, previously the CEO of Tangosol which is now owned by Oracle, stood up and showed a neat data grid demo.  Interestingly, his main points about reliability and scalability all sounded exactly like what I have been telling people at our booth.  The only difference is he’s talking about data reliability and I’m talking about processing reliability.  I’m still unsure about the Tangosol/GigaSpaces/TerraCotta data grid concept.  It sounds so much like EJB CMP to me.  The problem with CMP wasn’t that it was inside J2EE or on a cluster.  It was that the bigger you scaled, it the more problems you had with either stale data or performance.   If you try to fix the stale data problem by locking data instances on the cache, you now have scalability problems.  I don’t see how the data grid solutions address this.  I think what’s really happening in that space is specific domains are able to use optimistic locking, and therefore the ability to virtualize commodity hardware as a large memory cache works for them.  Maybe I’ll go lurk around their booths tomorrow and see if I can get one of them to explain to me how they address the stale data issue differently than CMP.

I had several good conversations with show attendees today. We didn’t give out as many slinkys as the first day, but they were still popular.  I think we have about 1 or 2 boxes left, so they should be gone tomorrow.  I do end up describing our product to people a lot.  Our concept isn’t an easy one to label.  We call ourselves an Application Fabric, but sometimes we say "virtualized grid", "next generation application server", or "execution platform".  Our VP of sales and I were having lunch and talking about different names we could use that would resonate with developers and architects.  I proposed Application Grid, so maybe we’ll try that out.  I had a booth visitor come up and ask straight out if we were a compute grid or a data grid.  He obviously understood the grid space, but I think compute grid wouldn’t explain what we do to most people.

Tomorrow I’m going to try to find some leftover t-shirts.  I have been so busy at the booth that all I have so far is a couple of pens from the Interface 21 booth.  They hinted at some upcoming ultra cool schwag.  I think we may have to turn this into a competition.  I’ll keep the updates on the blog.  Maybe we can get a bet going and an online poll or something.  I noticed we got a mention on Java the Hutt’s blog today which was cool.

I’m going to go get some food.

later,

-j

Well I survived the first day of working the booth.  Our signs all showed up and everything looked great.  We had 1000 slinkys to give away with our logo on one side and the phrase "Scale for Spring" on the other.  I predicted we’d only give away 300 and our VP of sales predicted 500.  I thought slinkys were a little passe, but I was completely wrong.  Those things were flying off our table.  I couldn’t unpack boxes fast enough.  Apparently, programmers love slinkys- like, really really love them.  We got a lot of foot traffic from people who heard our booth had slinkys, so the marketing guys were right about that, and I was not.

One interesting issue we dealt with was the contact reader.  It’s a little handheld PDA that has an RFID reader in it.  Everyone’s show pass has a smart card in it so as they talk to us we can scan it and get contact info.  Well, our reader crashed.  It was provided by the show and was running Windows.  I found that odd at a JavaOne show, especially when they’re making big Java ME announcements.  You’d think they’d want all their handheld devices running their own platform.  We probably lost 30 or so contacts because of that.  We were given a replacement and made do, but it was kind of lame.

Other than that, I’ve learned to never work a booth unless it has the extra carpet padding in your booth area.  My feet and back are sore.  It’s hard work to stand and talk to people all day, but I did get into some interesting discussions about the difference between Appistry and other solutions like TerraCotta.  That was fun.  We definitely have some distinguishing features besides slinkys.  At the end of the day, Rod Johnson came by to take a look at our Spring integration code.  I opened eclipse and showed him the project we were running and he was impressively good with the hotkeys.  He knew things I didn’t and was flying around pretty fast.

All in all, it was a good day.  I wish I could have made it to a couple of sessions, but I was so busy talking about our software with people, I didn’t have time.  Maybe tomorrow I’ll make it to a couple.  There are a lot of interesting topics at the show.  They do a great job of getting a diverse group of speakers.  I would definitely recommend this show to anyone looking to see what the latest java related technologies are in any area.

Now I’m going to get some sleep,

-j

So I’m at JavaOne, the Disneyland of Java.  We arrived a day early to setup our booth today.  There are a few shipping issues, some missing signs, etc.  but that is par for the course at shows, as far as I can tell.  I haven’t seen one without some type of last minute issue that resolves itself the next day.  But the tech part of the demo is working.  The development team, whom I have high respect for, delivered our most common demo with Spring integrated into it to correspond to our announcement for the show.  We have the ability to take a normal Spring application and deploy it on our fabric with no changes to the underlying code, which is consistent with the Spring philosophy (and Appistry’s as it turns out).  So we have this cool Swing app that sends a bunch of transactions into a fabric of machines that we truck around to these shows.  The development team took that app and converted it to a Spring app, and then put that on top of our fabric so that we can demonstrate code running on Spring with our dependability and scale it out on commodity hardware.

So yesterday I started debating as to what the dress code should be at JavaOne. I said jeans and t-shirts, the Sales and Marketing guys said khakis and dress shirts.  Today as I was walking around the floor with our VP of sales I pointed out the preponderance of people wearing jeans and t-shirts or jeans and whatever.  He pointed to one group of five people and said there were two wearing khakis.  I said one of those was wearing cargo pants so it counts for me, not him.  Tomorrow I’m going to wear jeans and a dress shirt in a blatant compromise.  If the majority of people walking up to our booth are dressed down in the standard programmer uniform, then I’m breaking out my OpenBSD t-shirt.  Remember the days when wearing ultra casual clothes meant you were so good at coding that you could wear whatever you wanted?  I had a boss once that accepted an interview as a favor when he was younger.  He didn’t want the job so he showed up in shorts and a tank top.  They thought he must have been so freakin smart that they fell all over him and did everything they could to hire him.  Man, I wish those days would come back.

I read in the paper this weekend (yes the paper, it comes to your house and is made from trees) that the telecom market is growing again based on high bandwidth applications.  I’m going to call this the "YouTube Effect" and hope that I’m the first one to say that.  Maybe we’re around the corner from actual sustainable technology growth?  That would be awesome, engineers being highly prized but without the bubble this time.  Just smack anyone that starts day trading tech IPOs at outrageously inflated values.

So anyway, day 1 at JavaOne was all about getting my cool "Java" backpack and a tshirt that won’t fit me.  But my stuff works, so I’m good to go.  Tomorrow we’ll take the nice JavaOne shuttle to the Moscone Center for our complimentary exhibitor breakfast and work the booth.  There are a couple of cool sessions that I want to find time for; they actually are scheduled all day until after 10:00pm.  My wife thought they’d end early so people could go see the sights.  I was like, "No these are uber-geeks and we want 12 hours of tech sessions all week because that’s how we roll."  Actually I said nothing like that, but I like to pretend how cool I sound retroactively.

See you tomorrow.

-j

I was in Chicago this week at a trade show.  We had our cool demo running on a table for people to see and play with.  It’s a stack of 5 AOpen computers hooked into a linksys router.  I run Tomcat on my laptop and then run a couple apps that I got from other tech reps.  One is what we call the "Dependability Demo" and its a Java Swing app that sends a bunch of transactions into the fabric that is running on the boxes.  I’m currently using Suse 10.2 linux for the OS on the boxes.  We always ask the people watching to come up and unplug an ethernet cable or a power cord from any of the boxes.  Then the Swing app display shows that some transactions are hung in various states.  As we are explaining what happened the fabric figures out what just happened and resubmits the the tasks that did not complete to different workers with the same state that existed before the cord was unplugged.  The transactions complete and the rest of the app just keeps working.  People really like that, they get the concept when they see the software do its job.  Then they also know we aren’t vaporware.

While I was at the show, we decided to change our ethernet cables.  On the first day we had 6-inch cables that were just too short to unplug easily because they were stretched so tight between the router and the machines.  So I had someone pick me up some 3-foot cables and bring them to the booth.  Then with the demo still running, I just started unplugging things and replacing cables.  Half way through I remarked that someone should be video taping it because I was taking down the entire network and taking machines offline without caring one bit about the application that was running.  The demo was happily completing all the tasks.  It was a good example of how IT management could change if someone employed an Appistry fabric on their mission critical apps.  How many times have you heard the story of someone unplugging the wrong ethernet cable in the server room and taking down the production app?  With Appistry it wouldn’t even be worth talking about anymore.  Imaging how much money is spent to avoid that scenario?  What if it just didn’t matter anymore?  I wonder how many middle ware solutions would survive a live network cable swap?

I’ll be at JavaOne next week, come over to our booth and I’ll let you unplug some cables.

-jasen