Exit Condition

Single life is damn fun.

You’re a swingin’ bachelor(ette), your nights are nothing but body shots and hoping that “put your number in my phone” leads to “put your thingy in my hoohoo.” But most importantly, it’s a time to know yourself - your true wants and needs. Immediate fulfillment of desire is the name of the game, and because there’s no true investment in any particular individual, you’re free to explore the next hot piece that walks in the door.

Inevitably, however, restlessness will set in. There are only so many dark. loud places serving alcohol and only so many prospects who enjoy “going out, having fun, being with friends, or just hanging around”. Somewhere inbetween the morning walks of triumph/shame and evenings of lonely discontent, the whole scene becomes a cyclic deja vu starring a predictable roll of typecast players.

And at these times, you’ll be a lucky stiff to find that one of your flames has some lasting firepower. There’s a little something more there, and as sexy as the relationship began, the real attraction lies within underlying compatibility.

Now it’s prudent to unmount your head from its swivel and focus on a longer-term plan.

A successful software startup is likely to encounter a similar experience. At the helm is A Novel Idea, and the requirements gathering process should ideally yield a well-defined business plan. Once the investors, lawyers, and analysts have exhausted the ink in their fountain-tips, it’s time for some deliverables. And the pressure is on.

Specifically, it’s on the development team to set some realistic goals, often managing expectations up the chain to bring management to reality. And discussions begin to center on the core technologies, languages, and frameworks to be used for implementation. Shopping!

I believe there are 4 categories from which to choose:

• Proprietary 3rd Party
• Proprietary In-House
• Web Two-oh-eey Open Source
• Professional Open Source

Only one of these is going to offer the benefits of the other three.

Proprietary 3rd Party

Good: These guys are backed up by blue-chip assets with proven history in various markets. They’re a household name; Jim Kramer flies about yipping their P/E ratios, and you feel secure putting your backbone in the hands of seasoned veterans backed by an established support system.

Bad: You have no idea what’s going on under the hood, and no way of fixing it on your own. This is the high-end European automobile of software; any misbehaving components must be plugged into a specialized computer for analysis, and you’re getting straight played on the maintenance costs. You’re also so far from the cutting edge that you’ve grown a beard.

Proprietary In-House

Good: You know the ins-and-outs of every single byte running your application.

Bad: You must explain to the Board of Directors that they hired an individual who should be thankful to be equipped with the skills requisite for respiration. It’s impossible to do everything on your own; modern-day mathematicians take advantage of Newton’s research, they don’t redefine Physics.

Web Two-oh-eey Open Source

Good: Ease-of-use, rapid turnaround, shallow learning curve, only 4 keystrokes to a database-driven application. This category is the quickest to adopt and integrate with the latest buzzwords, generate excitement in the industry, and add an impressive “Wow” factor to developers and end-users alike.

Bad: What we have in heart here is lacking in maturity. To list: instability, ever-changing APIs, poor scalability, and ignorance of issues requiring attention for high load. Everything you’d expect from a subculture championed by 20-somethings (I’m aware of and comfortable with this hypocrisy).

Professional Open Source

I’m most familiar with JBoss, and since I’m clearly pushing an agenda (born from honest observation), will speak to our offerings.

We make available a hybrid solution stemming from approach duality. At the core of this notion is “Project vs. Product”.

Our project line is the model historically associated with JBossAS when it first launched. Motion on this front is relatively rapid for such a low-level technology, and we’re continuously releasing, componentizing, and adding featuresets as they become available via community demand or developer innovation. This is the migration path ideal for younger applications - get started easily, for free, and experiment with the wide variety of components to evaluate how they fit your needs. If you’ve got a requirement we haven’t yet supported, this is the place to collaborate, implement on your own, and get upstream for the rest of the world. To boot, there’s an active informal support system in the form of forums, IRC, and mail lists to help you stay on track.

The product concept is newer. While JBoss has long provided pay-for support and training, in this case you’re actually buying software. At first glance, this seems contrary our mission to deliver free bits and charge only for our efforts dedicated to your business specifically, but in actuality, this is a necessary and important evolution in our model.

Every commit to the codebase comes with inherent risk of introducing regression, breaking previously-intact code. So in order to provide the highest level of reliability, after a project has reached a level of stability verified by our QA teams it is branched off into its own lifecycle and granted “product” status. At first, this very closely resembles the project counterpart, but as time and development continue, the two diverge. The product receives only security, high-priority, and customer-identified patches, maintaining and enhancing the integrity of the official release. To boot, the platform is now in form where we can pledge to support each release for seven years. You’re not paying for the bits, you’re paying for our support - but we’re ensuring that you stay within code we can guarantee will remain backwards-compatible. When you upgrade, you change nothing in your application, and it still works. That’s powerful.

My focus is to the community; it’s where my interest lies. I’m assured that by providing quality software free of most restrictions (LGPL) no marketing or sales folks will need to convince you that JBoss is a generally wise partner.

So please, go out and fool around. Make and learn from some mistakes, sample the wide variety of options out there. Then come give us a real visit.

Because we’ve got the T-and-A to pique your interest, and as time goes on you’ll come to cherish that we’ll be there for you. When you do make that realization, we’ll be ready with an enthusiastic “Yes!” when you finally pop the question.

S,
ALR

New York City has an inexcusable population density, and its inhabitants are some of the most self-important existentialists on Earth.

We’ve all got something to do, it’s urgent, we need it accomplished now, and heaven help your sorry butt if you keep us waiting.

So the Service Industry has gotten pretty damn good at getting us our Iced Quad Nonfat Caramel Macchiatos, with Whip!, in due time.

There are some impressive retail strategies for dealing with the masses. I’ve seen:

• One queue feeding into many sales registers
• One queue per register
• One queue, with many associates performing specialized units of work; processing a transaction in phases

Selection of one over the others is generally dependent on the business rules governing the transaction. But there is a common denominator here: The Queue.

Traditionally called “lines” in the United States, the queue represents a holding pattern of service requests until resources become available. This guarantees an even thoroughput.

But hey, I’ve got a new idea! Waiting blows…so I’m going to remove the queue from this equation. Let’s see what happens.

• I arrive at the bank, noticing one teller who is dealing with a customer.
• I approach the counter and give the busy banker my deposit slip and checks.
• The teller alternates between the work she was doing prior to my arrival and the new task I’ve just given her, switching repeatedly.
• The existing customer gives me a dirty look; her work is now being performed at 1/2 speed.
• A new couple walks in, giving the teller 2 requests for a withdrawl.
• Work on Customer 1 is still not done, and is now being performed at 1/4 speed.
• Murder Scene

Maybe I need to rethink this. So its back to the lab, where I send all computational problems to Carlo de Wolf for analysis.

“The issue,” he explains, “is one of Resource Starvation.”

And the EJB3 lead of JBoss kindly continues to draw up reproducible test cases.

Let’s assume a stressing function, where we calculate Pi to 10000 digits 100 times. The idea here is just to get the CPU crunching to simulate some heavy processing.

We’ll invoke this once using traditional IoC/Dependency Injection, and again using EJB3 mechanics. Then we’ll compare the metrics.

//  Make an IoC Container Instance
IocContainer ioc = new IocContainer();
// Install the Calculator class, bound to a key
ioc.install("calculator", CalculatorBean.class);
// Lookup an instance
Calculator calculator = ioc.lookup("calculator", Calculator.class);
// Run the Stressor and print metrics
StressCreator.createStress(calculator);

Neat. Pretty simple. We programatically register a class, grab an instance, and use that instance to churn out our results:

Total Time: 28.21 Seconds
Not Executing: 0.235 Seconds
Invocation Time: 27.814 Seconds

Allright. Because we don’t have a queue here, we spend very little time outside of actual invocation of the test, and the majority of time is spent processing Pi 100 times.

Let’s do another run, using the same Stressor, but using EJB.

// Make an EJB Container
EjbContainer ejbC = new EjbContainer();
// Deploy the EJB
ejbC.deploy(CalculatorBean.class);
// Lookup an EJB Instance
Calculator calculator = (Calculator) new InitialContext().lookup("CalculatorBean/remote");
// Run the Stressor and print metrics
StressCreator.createStress(calculator);

Wonder what we’ll get this time.

From The Caller’s View:
Took 27.691 Seconds
Not Executing: 0.035 Seconds
Invocation Time: 27.541 Seconds

Collected From Inside the EJB Container:
Average Time Waiting on Queue: 13.37449 Seconds
Average Invocation Time: 1.3689 Seconds

From the point of view of a unified caller requesting 100 intensive service calls…looks pretty similar to IoC.

But there’s more here. We’ve now got a hook into the EJB Container, and can clearly see…average execution time of each of the 100 calls is about 1/100 the amount of time spent waiting on an available processor. WHY?

Because with EJB, you get instance pooling for free. When all available instances are taken from the pool, new invocations must queue up. And when you block incoming requests from slowing down your whole system, each individual request can be handled in a reasonable fashion.

The obvious question might be: What’s the damn difference? Both methods take nearly the same amount of time!

Sure. As fantastic as the EJB specification is, it can’t invent CPU cycles on the fly. What it CAN do is provide for incremental return. So the first requests in make it out without having to wait on everyone else in line to complete.

So I can easily draw the following conclusions, assuming 100 concurrent requests:

• At WORST, the last service request in EJB will return at the same time as the full IoC return.
• At BEST, EJB will begin to return requests in under 2 seconds, and these clients may be on their way.
• You will not have any N number of Threads spreading your processor too thin.
• If you’re allowing an Enterprise System to spawn a Thread for each request, you should work for McDonald’s.

On second thought, I revoke my last point. Even pre-teens working the McDonald’s drive-through make each car wait its turn.

S,
ALR

So Encyclopedia Brown was born into the game; his father is Chief of Police in Idaville, Florida.

But every time Pops gets a tough file, his best bet is to go home and explain to his prepubescent son The Case of The Missing Lollipop, which junior infallibly cracks before dessert.

Geez, Dad, you suck. How did you even get your job?

S,
ALR

For my respect, you may be either unintelligent or unkind, but not both.

In fact, there’s an undeniable allure to the brazen arrogance of the unapologetic elite. I think that’s why NBC’s House is still on the air.

But over the past couple years, I’ve been a difficult co-worker to suffer. Unfortunately for me, life isn’t a TV show and I’m not Hugh Laurie. Being an ass doesn’t make you correct.

Life at JBoss has been therefore humbling. Which is good, because my ego was writing checks my body couldn’t cash. And since this is a Meritocracy, every developer I’ve met is The Shit. Which can make the act of contribution a little intimidating.

So as part of this reformation of character, I’m appointing myself to the role of “Community Outreach Ambassador”. Wanna be a part of something distributed the world over? Wanna give back to the software that powers your business? And most importantly, wanna do my homework?

This all ties into the proactive stance I’m taking to remain true to my application-based roots. My job as a server developer is to handle application concerns in a generic, standardized manner. But hell, if I stop developing apps I’m going to pretty quickly lose touch with my ability to identify the major pain points. That’s what’s in it for me.

And why should you donate your valuable time without pay? Great question with better answers:

• You want a bug fixed before we’re able to schedule it in
• You want to discuss a new feature or idea, and get it upstream and supported
• You want to better understand the black box upon which your application is built
• You want to compile your own binaries between official releases

It gets better. By focusing inward towards the community, the software itself becomes a byproduct of demand. This leads you, the developer, to choose JBoss AS as your JEE implementation. Your management in turn purchases support, and now you’ve got a supported platform loaded with features proven relevant in the field. To boot, you’re equipped with the tools necessary to debug problems on your own. How easy is your job now?

I therefore offer an initial push to anyone with more than a fleeting desire to take part in EJB3 Development. If you swim, you swim.

All told, the JBoss ecosystem will benefit from an influx of external contributors, and everyone reaps the rewards.

Especially me, who will be delegating my work to you, while on paid holiday.

S,
ALR

Water in my apartment comes in one of exactly two temperatures; prolonged exposure to either requires medical attention. See, it’s an old building and the ancient plumbing isn’t great at the even distribution of flow to each unit. So I simply cannot shower; I must run a bath and manually regulate the heat levels coming out the faucet.

My landlords tell me there’s not much that can be done - stripping out the internals is just not cost-effective. It’s better for them to let me suffer. Were I a shrewd businessman, I’d understand.

But I’m a programmer, and I have a heart.

There’s perfectly good hot water down there. Mother January in NYC gives us unlimited cold water. And ain’t nothing wrong with my tap. It’s the transport. The damn plumbing. Once you install plumbing, you’re married to it. And divorce is expensive.

Incredible how much of the same is true in Web Application Development. Most Enterprise Applications take advantage of at least one Service-Oriented Architecture exposing its API in platform- or language-agnostic mechanisms. The “M” of MVC. This is Good.

Also Good is the wide variety of templating options available to handle the “V” of MVC. JSP/JSTL, Facelets, Velocity, XSL…all are pretty swappable.

The “C” word, as we always knew, is Bad.

Oh, Controller, responsible for parsing a request, determining an appropriate action based on its content, delegating to the correct processor, and passing the result onto the view. Historically it was identified that this common concern should be addressed in a generic fashion, and every programmer began his own proprietary solution to the problem. Soon after, Struts, and in the years following, The Framework Wars.

The AJAX Movement has not made this any easier, as often the “MVC within an MVC” pattern is applied; one each for the client- and server-side.

When I look over some of the greatest architectural decisions I’ve made in the past few years, the common thread has been my heavy use of the “delete” button. Removing entire layers of code. No more transfer/value objects. No more Business Delegates.

Now I want to get rid of the Web Tier in many cases. I love you Tomcat, but we’re doing you a disservice through abuse and overuse.

It’s time to expose our EJBs directly to our frontend teams. Asynchronous JS calls can so easily hook into business logic, and there’d be no more custom Servlet code inbetween. RPC for JS.

Not that this is unchartered territory, but all solutions I’ve encountered involve a webapp (Framework) to be deployed inside a Servlet Container, and I want to avoid the extra dependencies, glue code/configs, and unnecessary traffic over those channels.

I want JavaScript that reads:

EjbRequest request = new EjbRequest("com.alrubinger.BusinessInterfaceName","methodName","arg1","arg2","argX");
request.setResponseHandler = myResponseHandlerFunction;
request.send();


The beauty of this is that aside from the required import of a JavaScript library, theres no imposition on the application inbetween.

And behind the scenes, beyond the worry of either the frontend or application developer:

• Request is sent (as JSON, XML, etc)
• Received by separate, slim, non-blocking server as JCA Resource Adaptor.
• JS > Java Object Mapping
• Sent to “onMessage” of MDB
• Dispatched to specified EJB, JNDI lookups transparent
• Invocation
• Result sent to Response Queue
• Unwrapping, Java Object > JS Mapping
• Write the response

I think back to all the occassions I’ve been asked to expose some method to my UI guys, and its horrifying the amount of time I’d spent (and errors introduced) simply getting well-tested data from points A to B. Stopping actual development to build a pipe. It makes me feel dirty.

So now I need a bath.

S,
ALR

While putzing around the apartment tonight I stumbled across my girlfriend watching the premiere of a new Lifetime Original Series, “How To Look Good Naked“. My initial excitement quickly throttled back to reality when I discovered that my visions of skin on parade were replaced with the insufferable Carson Kressley doing some version of “Queer Eye for the Insecure Girl”. I could blame false advertising, but it’s my own fault for expecting greatness from Lifetime while simultaneously possessing a Y chromosome.

But the intent of the show mirrored some discussions I’ve been having with Michael Neale, Aussie on the JBoss Rules team. Changing your perception is a lot of the game.

Now, I’ll never, ever argue that marketing or a pretty face will make up for a crap product, but lately I’ve been ramped up over the public view that JEE, and JBoss AS in particular, are “Heavy”. And in context, this is somehow bad.

So it’s time to dispel some of that by embracing the reality of what “Heavy” means.

In the case of JBoss AS, it means:

• Resource Pooling (Threads, Objects, Database Connections, etc)
• Transaction Management
• Conversational Context (Application Sessions)
• Pass-by-Reference Semantics (Avoiding Serialization cost and Network Latency)
• Security
• Process Scheduling
• …etc, etc.

…by default.

Default.

Love it. And love even further that the above is implemented to open specification (JPA, JCA, EJB, JTA), minimizing your vendor lock-in.

I21 advocates will proclaim Spring as more relevant than the Second Coming because it DOESN’T have any of that.

…by default.

Default.

See, the beauty of Spring is that it’s merely an environment into which other modules may be plugged. Light as a feather in space. Starts up before you hit “enter”, scales to the moon and back. And is extensible by adding implementations of whichever components you need.

Dirty little secret about JBoss AS: It also does nothing on its own.

The JBoss Microkernel has, for years, simply been a deployment mechanism. And today, I started it in 3 seconds in minimal configuration. If I want to add features, I drop ‘em into a folder.

Sounds Springy to me.

For a long time, I’ve hated everything:

• Dynamically-typed
• Ending in “uby” or “roovy”
• Agile

…because they just don’t address Enterprise Concerns, and trade the long- for the short-term, good practice for easy-to-learn.

But that era’s got to come to an end. Development, and open-source in particular, is about choice. And we’ve got lots of great stuff in the JEE space to offer to languages and methodologies of all walks. It’s time to reach out and integrate.

So here’s my concession: EJB is powerful, but I’m going to recognize that not everyone has the desire to invest the time to learn its complex underpinnings, even if the 3.0 Specification made the semantics dead simple.

Maybe frontend JavaScript developers want to call Service code directly, eliminating the need for a Web Tier in many cases. We can do that. Maybe JRuby kids want to leverage Rails for its strong points, and shuffle off the distributed business logic to EJBs. We can make that easier, too.

So Heavy can be really, really good.

Except when you were hoping for lite porn, and instead got some chick crying in front of a three-way mirror.

S,
ALR