Exit Condition

The holiday season is approaching.  Since Sam Summer turned into Sam Oktoberfest[1] I’ve seen a frightening array of tinsel slowly invade area department stores, and I know that some dreaded chorus of electronic carols cannot be far behind.  But it’s not the commercialism that concerns me.  It’s not the burden of shopping, the endless pursuit of parking, nor the $400 doll that some daytime talk show turned into the must-have accessory for our nation’s toddlers.  Once I’ve accounted for everyone on my “Good” list…it’s time to sit down and do the wrapping.

The scissors.  The tape.  Silly cards that unnecessarily explain, “Hey, this is a gift.”  It’s not enough that I’ve spent my time considering what you’d like before building or acquiring it; you, princess, need a shiny cover too.  Ungrateful bitch.

Application servers are similarly prissy.  By specification, they might not have a clue what to do with your programs unless you’ve got cutesy little descriptors littered exactly where they’re expecting.  Annotation support introduced in JEE5 helps by reducing the amount of boilerplate XML, but there’s some other implicit metadata within archives.  ClassLoading scope says that every resource within a bundle will be able to see each other, and atomicity guarantees that we’ll be treated as a singular deployment.

Traditionally, we have a build process responsible for packaging our resources in expected form.  The problem this presents is that our development cycle must look like:

* Code
* Build Step – Compilation
* Build Step – Packaging
* Test

In practice, most IDEs offer incremental compilation which we’ll often overwrite or ignore during the build process.  But the most egregious flaw in this setup is the context switching it imposes; you must redirect your attention from the code to run a build.  I want to code, test, code, test.  Because I’m a very poor coder prone to making mistakes, I test nearly every method for coverage as it’s written.

Scripting the build is a PITA as well.  I’m constantly looking at Ant or Maven documentation to figure out the correct syntax.  Again, because I’m a poor coder and have low retention for rote tasks.  I don’t think it’s a tremendous leap to assume that Java programmers are most proficient in Java.  Any context switching we do is distracting.  Code, test, code, test.

So we should be writing our tests in Java, without any dependencies on a build process.

The ShrinkWrap[2][3] project enables you to do just that.

// Make an archive; put some classes in there
JavaArchve archive = Archives.create("myejb.jar", JavaArchive.class).addClasses(MyLocalBusiness.class, MyBean.class);
// Deploy into EmbeddedAS
server.deploy(archive);
// Log out the full contents in an "ls -l" -type output
archive.toString(true);
// Export to an InputStream in ZIP/JAR format
InputStream in = archive.as(ZipExporter.class).exportZip();

Ultimately, I wanted to continue the support for “manual deployment of archives” pioneered by Bill Burke[4] within EmbeddedJBoss[5].  Previously we used to provide this by leveraging JBoss Virtual File System (VFS)[6] and its in-memory files.  After some further consideration we were able to skip *all external library dependencies*.  We have a great mission and featureset:

* Intuitive, clean API
* Export to ZIP/JAR or exploded directory
* Import from ZIP/JAR or exploded directory
* Typesafe specialization
* Domain-specific language extensions (To declare web.xml servlet metadata for instance; Under development)

From an administrative standpoint, I can’t be prouder of how this project was run.  We took good ideas from history, added some of our own, and collaborated in public with a couple of talented community contributors.  Aslak Knutsen[7] and John Bailey[8] in particular gave a lot of their thought and time into ironing out each feature and public interface.  We have a testsuite with strong coverage and have used the excellent FindBugs[9] code analysis framework to catch things we didn’t.  Jesper Pedersen[10] of JBoss JCA fame gave us a great peer review.  And now ShrinkWrap is a first-class citizen in the upcoming release of EmbeddedAS, a new API for the JBoss Application Server.  More on that later; watch this space.

Looking forward, I’d love to see some more community involvement; for instance I’ve invited the Glassfish team to consider supporting us in their embedded server.

In the meantime, we’ll be building out our Wiki and documentation.  Early-access release 1.0.0-alpha-2[11] was just cut a couple days back, so it’s not too late to give some input before we freeze the APIs[12].  There’s virtually no barrier to entry here; if you know the core JDK you’ll be able to join our development team.

So consider this my holiday present to you.  Wrap it yourself.

S,

ALR

[1] http://en.wikipedia.org/wiki/Boston_Beer_Company#Seasonal_beers
[2] http://jboss.org/shrinkwrap
[3] http://www.jboss.org/community/docs/DOC-14138
[4] http://bill.burkecentral.com/
[5] http://www.jboss.org/community/docs/DOC-9685
[6] http://java.dzone.com/news/jboss-virtual-file-system
[7] http://jboss.org/community/people/aslak
[8] http://jboss.org/community/people/baileyje
[9] http://findbugs.sourceforge.net/
[10] http://relation.to/Bloggers/Jesper
[11] http://www.jboss.org/shrinkwrap/downloads.html
[12] http://docs.jboss.org/shrinkwrap/1.0.0-alpha-2/api

The year after Fleischer and I finished University we weren’t quite ready to give up Spring Break. So with mischievous intent on the Ides of March, 2004, we stuffed ourselves into an AirBus headed straight for the Gulf Coast of Florida.  It’s like a playground for 20-somethings, and the toys are alcohol and each other.

On the third evening of our stay we happened across a nightclub eager to take our money.  After a couple hours of rubbing up against perfect strangers, I distinctly remember Ludacris’ plea for a “lady in the street but a freak in the bed” piercing through the haze.  This I attribute to a DJ who had apparently put Usher’s “Yeah”[1] on indefinite repeat.

Lady on the street.  Freak in the bed.  Stunning irony, considering that we were hopelessly surrounded by young women showcasing a brand of behaviour typically unfit for public space.  And it occurred to me that though many of my dancing brethren would find some late-night nude adventures, none would be taken home to meet the parents.  Sexy often lacks staying power.  But this guy wants both the Veronica and the Betty[2].

In the world of Enterprise software, there’s a real clash between features desired by developers and those required by business stakeholders.  Throughout the JBoss maturation process we’ve made great strides, especially for an open-source unit, in meeting the demands imposed by the most discerning of powerhouse clients.  Government regulations, security audits, compliance tests – we’ve delivered each one as needed.  And we’ll continue to do so.  That’s reliability.

On the other side of the coin, smaller vendors have been able to differentiate by pushing their application servers geared more to the whims of the community.  Ease of use is a powerful argument which first heralded JBossAS into the market alongside much more well-endowed players, and it fosters a healthy ecosystem where developers love the tools they’re using.  That’s excitement.

Recent surveys have concluded that you, the programmer, want both[3].

It speaks mostly to my unhealthy need for validation that I’ve spent the past few months focused on giving you exactly what you want.

Easy Testing

Unit Tests are fantastic for ensuring that the fine-grained functions of your program work as expected.  Their small scope is simultaneously their advantage and weakness; to truly know how your application will work we must see the interaction of components working in tandem.  This is where Integration Testing comes in.

In the case of JBoss Application Server, this has traditionally involved launching AS as a separate process, deploying your archives, checking your business logic, then shutting down the remote process.  In fact, this is the same approach we take in the AS TestSuite itself, eased through the use of some custom Ant macros.

But in writing the examples for my upcoming EJB 3.1 Book, I’ve found the same problems reported by our users for some time now – it’s cumbersome to test within standalone AS.  What we’ve needed is a simple mechanism to manage the configuration and lifecycle elements of JBossAS and start in the currently-running JVM.

/**
* Configures and starts JBossAS in-process
* @throws Exception
*/
@org.junit.BeforeClass
public static void startJBossAS() throws Exception
{
// Create Server
final JBossASEmbeddedServer server = new JBossASEmbeddedServerImpl();
// Configure
server.getConfiguration().jbossHome("/path/to/JBOSS_HOME")
.bindAddress("myhost.com").serverName("myconfig");
// Start
server.start();
}

This is the result of some prototyping currently underway in the JBoss Embedded project[4].  In fact, it’s the culmination of a bunch of really boring, rote work preparing the AS itself to run in this kind of environment.  I’ve given focus to a clean API and addressing use cases in a concise, predictable fashion.

For the time being, JBoss Embedded will run backed by a traditional JBOSS_HOME installation.  In the future we’ll provide a single JAR distribution which will be the sole dependency in launching the server.  Also on the roadmap is a Maven2 Plugin wrapper to tie the server launch into the Maven lifecycle (such that you won’t have to manually code startup/deploy/shutdown in your tests).

At the moment, I’ve verified the following works:

* EJB3 Stateless Session Beans
* Servlets / JSPs
* Java Message Service (JMS) and EJB3 Message-Driven Beans
* Persistent DataSources and EJB3 Entity Beans (some caveats at press time)
* Local EJB invocations pass by reference
* Blocking MDBs to wait for them to process messages

You can even take advantage of launching straight from the IDE, for instance in Eclipse’s JUnit Integration:

JBossAS Embedded in Eclipse/JUnit

This has gotten a bunch of the other JBoss Core Developers all excited, so we’re pushing forth full steam ahead to cut an early Alpha alongside the next JBossAS release.

Virtual Archives

Alongside the server elements of Embedded is the need to provide some tools to shorten the test lifecycle.  A particularly nagging point is introduced by the packaging requirements of the various Java Enterprise Edition specifications; classes and resources must be assembled in a very specific arrangement, and this provides some implicit metadata to the server during deployment.  The problem is, writing build scripts is a real pain when you just want to see your stuff working.

We’re therefore including the notion of a “VirtualArchive”, which is used to declaratively assemble bits and pieces scattered about the filesystem into one fake unit.  You determine the structure of the archive, and pass it along to the server.

final VirtualArchive archive = VirtualArchiveFactory.createVirtualArchive("slsb.jar")
.addClasses(OutputBean.class,OutputLocalBusiness.class);
log.info(archive.toString(true));
server.deploy(archive);

The verbose toString() form helps with debugging:

slsb.jar - 0 bytes
slsb.jar/org - 0 bytes
slsb.jar/org/jboss - 0 bytes
slsb.jar/org/jboss/embedded - 0 bytes
slsb.jar/org/jboss/embedded/testsuite - 0 bytes
slsb.jar/org/jboss/embedded/testsuite/fulldep - 0 bytes
slsb.jar/org/jboss/embedded/testsuite/fulldep/ejb3 - 0 bytes
slsb.jar/org/jboss/embedded/testsuite/fulldep/ejb3/slsb - 0 bytes
slsb.jar/org/jboss/embedded/testsuite/fulldep/ejb3/slsb/OutputBean.class - 844 bytes
slsb.jar/org/jboss/embedded/testsuite/fulldep/ejb3/slsb/OutputLocalBusiness.class - 312 bytes

This is actually my favorite feature of Embedded thus far.  The amount of time you can save by putting off the composition of JAR/EAR/WAR files is astounding, and it also opens the doors to quick testing specific EJBs in isolation.

Next Steps

From here we keep plugging.  I’m assembling a crack team of contributors to help with tests, patches, and feature development.  The projects themselves are fairly self-contained and well-documented, so diving in shouldn’t be much a problem.  Contact me directly and I’ll point you to some low-hanging fruit.  Make some good patches and I’ll hook you up with commit access.  If you can hack it, hack on our stuff.

Once AS has a formal release I’ll shout again with instructions for using it as detailed above.  I encourage you all to be proactive in downloading and giving this all a spin.  It’s the feedback from early adoptors which will be critical to the success of these projects.

And so it is for JBossAS.  On the street, we’ve already got the cred.  But behind closed doors in shops around the world, we want to get you off quickly.

Lady on the street.  Freak in the Embed.

S,
ALR

References:
[1] http://en.wikipedia.org/wiki/Yeah!_%28Usher_song%29
[2] http://en.wikipedia.org/wiki/Archie_Comics
[3] http://www.jboss.org/community/wiki/JBossASTop10
[4] http://www.jboss.org/community/wiki/JBossEmbedded

We used to throw the best parties in our Coolidge Corner[1] bachelor pad.  The recipe was simple: we’d blast an eVite to the city of Boston, pick up a keg of Good Decision[2], break out the Beirut[3] table, and ask the local police to turn a blind eye.

In the midst of one of our more smashing affairs, conversation turned to concurrent polygamy and if any of us were fortunate enough to have practiced the art firsthand.

Josh had.  Of course, Josh had.

And he offered us this advice: “You don’t go looking for it.  It’s given to you, so don’t ask questions and just take advantage of the opportunity.”

Don’t you know it, opportunity knocked upon my roommate Jon’s door not three hours later.  With a couple of part-time models.  Two models at the same time.

While the next morning’s brunchtime report was entertaining enough, my inner geek preferred to explore how some of the same themes might be applied to component architecture.

Models:
* Are not necessarily mutually exclusive
* Should be encouraged to focus on their own domains
* May share in some concerns, each from a different angle
* Combined are worth more than the sum of their parts

Shoot forward a few years, when an enabling technology caught up with my musings in the form of JBoss Microcontainer[4].

My first impression of MC was that it was “another DI Container”.  And at its core, sure, it provides the kind of POJO autowiring that we’ve come to expect from this class of framework.  Over the past year, however, I’ve come to appreciate MC for its extensibility, a truly differenciating characteristic from other offerings.

DI is all very nice, but I’m accustomed to having some greater utilities available to create my runtime environment.  A quick glance at the MC feature list boasts Virtual Deployment Framework (VDF), a filesystem abstraction (VFS) and aspectized classloading facilities.  Armed with these, I was set to kick the tires in hopes of discovering some deficiencies in the design and thus gaining bragging rights over Ales[5].

Mission: Provide @EJB injection into MC Beans

In short, I want MC Beans to be able to inject references to EJB3 proxies.  This will be our integration point for interacting with EJB from MC-based Services.

MC applies a metadata-collecting vistor to beans that are installed, and this is passed along to an AnnotationPlugin[6] whose responsibility is to apply the requisite info to the visitor.  By implementing an AnnotationPlugin to handle javax.ejb.EJB, we’ve got our hook[7].  This process is eased by abstract support from FieldAnnotationPlugin, and the main goal here is to supply a ValueMetaData describing the injection value.:

/**
* Create @EJB value meta data.
*
* @param annotation
* @return @EJB metadata
*/
@Override
protected ValueMetaData createValueMetaData(FieldInfo propInfo, EJB annotation)
{
// Get properties from the annotation
String beanName = annotation.beanName();
String beanInterface = annotation.beanInterface().getName();
String mappedName = annotation.mappedName();
// Supply beanInterface from reflection if not explicitly-defined
if (beanInterface == null || beanInterface.equals(Object.class.getName()))
{
String reflectType = propInfo.getType().getName();
beanInterface = reflectType;
}
// Create a reference
EjbReference reference = new EjbReference(beanName, beanInterface, mappedName);
log.debug("Found @EJB reference " + reference);
// Return a new ValueMetaData w/ the reference
return new AbstractEjbReferenceValueMetadata(this.getResolver(), reference, this.getNamingContext());
}

The “EjbReference” above is a value object used by the EJB3 Reference Resolver, responsible for finding the JNDI Name to which a reference is bound.

The return value is AbstractEjbReferenceValueMetadata[8], an implementation of ValueMetaData able to:

1) Declare a dependency upon the JNDI target value.  This ensures our MC Bean will not deploy until the referenced EJB has
2) Obtain the EJB Proxy from JNDI so that it may be injected

Simple enough.

From here, the only thing left to do is let MC know that it should consider our new AnnotationPlugin upon installation of new beans.  For this task I’ll create a simple POJO[9] which, installed, will alter MC’s behaviour.  The key here is in the lifecycle “@Start”:
@Start
public void start() throws Exception
{
// Install the BeanAnnotationAdapter w/ callback to add annotation plugins on install
BeanAnnotationAdapter beanAnnotationAdapter = BeanAnnotationAdapterFactory.getInstance()
.getBeanAnnotationAdapter();
String beanAnnotationAdapterBindName = MC_NAMESPACE_EJB3 + "BeanAnnotationAdapter";
BeanMetaDataBuilder bmdb = BeanMetaDataBuilder.createBuilder(beanAnnotationAdapterBindName, beanAnnotationAdapter
.getClass().getName());
bmdb.addMethodInstallCallback("addAnnotationPlugin");
bmdb.addMethodUninstallCallback("removeAnnotationPlugin");
try
{
this.getKernel().getController().install(bmdb.getBeanMetaData(), beanAnnotationAdapter);
}
catch (Throwable e)
{
throw new RuntimeException("Could not install " + beanAnnotationAdapter, e);
}
}
Here we get at the BeanAnnotationAdapter and install it into the KernelController along with some callbacks to automatically add AnnotationPlugins when they, in turn, are installed.  From here on out, all we need is to throw EjbReferenceAnnotationPlugin into MC.

I’ve tracked this feature[10], along with passing integration tests in the EJB3 TestSuite[11].

Unfortunately, I’m left with nothing to hold aver Ales’ head as MC provided me, as a framework developer, with all the tools needed to extend the provided groundwork.  In fact, I’m even at a deficit because I needed to consult the Microcontainer Users’ Forum[12] for some suggestions.

I’d like some input from application developers – in what situations would you like to call an EJB from a POJO?  Managed objects within Microcontainer act as singletons within the confines of the system, so there should be plenty of occasions to call upon a pooled/cached distributed component.  This is the goal we address by providing integration between component models.

Because nothing catches on without a proper title, I’ll name our approach right now: Concurrent Polyforma.

So now we’ve put JBoss MC to a real-world test, proving that it can wrap your favorite model.  As an additional exercise, I also did this quite literally:

Caylin Loves MC

This is how we’ll help you bridge two models.  You just can’t Eiffel Tower[13] them.

S,
ALR

[1] http://en.wikipedia.org/wiki/Coolidge_Corner
[2] http://www.beeripedia.com/index.php/Samuel_Adams
[3] http://en.wikipedia.org/wiki/Beer_Pong
[4] http://www.jboss.org/jbossmc/
[5] http://www.jboss.org/community/people/alesj
[6] http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kernel/src/main/java/org/jboss/kernel/plugins/annotations/AnnotationPlugin.java
[7] http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/mc-int/src/main/java/org/jboss/ejb3/mcint/metadata/plugins/EjbReferenceAnnotationPlugin.java
[8] http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/mc-int/src/main/java/org/jboss/ejb3/mcint/metadata/plugins/AbstractEjbReferenceValueMetadata.java
[9] http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/mc-int/src/main/java/org/jboss/ejb3/mcint/annotationadaptor/AddAnnotationPluginOnBeanAnnotationAdaptorCallbackService.java
[10] https://jira.jboss.org/jira/browse/EJBTHREE-1624
[11] http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/testsuite/src/test/java/org/jboss/ejb3/test/ejbthree1624/
[12] http://www.jboss.com/index.html?module=bb&op=viewforum&f=228
[13] http://www.urbandictionary.com/define.php?term=eiffel%20tower&defid=1242963

2002 was the year of Bad Ideas.

An overly-anxious United States Congress granted “immediate emergency powers”[1] to the President, resulting in war[2].  WorldCom and United Airlines both went Chapter 11.  Journalist Daniel Pearl was executed by terrorists in Pakistan.[3]  Two yahoos sniped at civilians in Washington, DC.[4]  And Britney cheated on Justin.[GASP]

Amid the muck Rod Johnson quietly released “Expert One-on-One J2EE Design and Development”[5], and it was chock-full of Good Ideas.  Among them:

* The contract between the bean provider and the container was too verbose
* The remoting model imposed bulky access
* Aspect-oriented programming should be used to apply orthogonal concerns
* Entity Beans sucked
* Testing business logic contained in EJBs was difficult
* EJB inhibited good OO design due to its API restrictions

I can see why the Spring movement was seen as such a breath of fresh air to developers sick of coding Local, Remote, Local Home, Remote Home, and Implementation classes for what might be a trivial service.  The community owes a debt of gratitude to the assertions presented by Rod & co.

To underscore how correct many of these anti-EJB claims were, the Expert Group behind JSR-220[6] independently came to many similar conclusions, and after 3 years of work released the EJB 3.0 Specification in May of 2006.

Bringing simpliciation to the standard was not applauded by the Spring-a-lings.  “[They believe] the same thing Wednesday that [they believe] on Monday, no matter what happened Tuesday.”[7]

Which is fine.  Really, conflicting views within the industry should be embraced as its the consumer who will benefit in the long run from a variety of options.

But today I read something disturbing, taken straight from the Product Page of the SpringSource tc Server[8]:

“The Spring container has replaced the EJB container in a majority of enterprise Java applications and is now the de facto standard for enterprise Java.”

Oh, fuck you with a rake.

I’ll break this down into two components:

1) Spring has replaced EJB in the majority of JEE outfits
2) Spring is the standard (in practice, not law) for Enterprise Java

This evokes memory of some poorly-conceived graphs and analysis posted by Rick Hightower[9] and later covered by InfoQ[10] in 2006, where job postings and brain-dead search terms drew the picture that EJB as a platform was flaccid in comparison with Spring’s reign.  Ignoring for the moment that we’re extrapolating fact from subjective assumptions, it’s only proper that I present some current numbers using relatively impartial queries:

Here we’ve got Google search terms.  Note the top three.

Looks like “J2EE” is still a very popular job posting, despite being a deprecated grammar.  “EJB 3″ doesn’t even show on the map if charted.

What I’d really love to see are some third-party analysts’ metrics.  Or maybe the Spring Flingers can back these claims up with hard data. Until then, I’m relegated to hold the position that EJB is maintaining its dominance[11].  Not to mention that even today JEE hasn’t yet shaken the bad blood accumulated in the days of the EJB 2.x spec, when DI and AOP were the new hot toys.

Or maybe I’m being unkind.  After all, if the community was aware that every single bullet in the Spring mission statement[12] was addressed by a specification and backed by a series of compliant implementations, they’d have no business left.  What’s the value-add to a company that is proud to do little more than aggregate other proven technologies?

Again, Springers mostly have it right.  Simplicity is great.  But it doesn’t have to come at the expense of EJB anymore; we’ve adapted, you should too.  If Pluto can stop being a planet, surely you guys can stop being dicks.

S,
ALR

[1] Star Wars Episode II: Attack of the Clones
[2] http://en.wikipedia.org/wiki/Iraq_Resolution
[3] http://en.wikipedia.org/wiki/Daniel_Pearl
[4] http://en.wikipedia.org/wiki/Beltway_sniper_attacks
[5] http://www.wrox.com/WileyCDA/WroxTitle/productCd-0764543857.html
[6] http://jcp.org/en/jsr/detail?id=220
[7] Stephen Colbert in reference to George W. Bush, 29 April 2006, http://en.wikipedia.org/wiki/Stephen_Colbert_at_the_2006_White_House_Correspondents%27_Association_Dinner
[8] http://www.springsource.com/products/suite/tcserver
[9] http://jroller.com/RickHigh/entry/stack_of_choice_jsf_hibernate
[10] http://www.infoq.com/news/2006/11/job-trends-ejb3-spring
[11] http://bill.burkecentral.com/2008/02/13/ejb-maintains-its-dominance/
[12] http://www.springframework.org/

Avid readers will note that I’ve been silent for some time here.  It’s a new philosophy I’ve adopted: “Put Up or Shut Up“.

Anyone monitoring JBoss EJB3 source control activity over the past couple months has noticed around-the-clock commits from our team.  4AM on a Sunday.  Midnight on a Thursday.  Hell, I’ve even been known to do some work during business hours when things are really cranking.

All of this has been dedicated to one goal: JEE5 Compliance of the JBoss Flagship project, Application Server 5.  And just last week, we pushed out binaries capable of making some 27412 Integration Tests maintained by Sun turn green.

Sacha and Dimitris have already spoken to the ongoing status and importance of this milestone, so I won’t reiterate their points.

But I’m not celebrating yet.

Compliance is a prerequisite.  It cedes vendor lock-in, promotes uniformity among programmers the world over, and sets a contract for what application developers may expect from their runtime.

And I think we’ve reached a point where you should be able to take that all for granted.  Now we go back to the regularly-scheduled, which in JBoss’ case is innovation and love for the community.

The best place to start is under the hood.

Get Out of the Application Server

We invested heavily in this one.  Simply put, we moved the EJB3 implementation out of the Application Server source tree, created APIs/SPIs where coupling was required (separating contract from implementation) and set proper dependencies.  This gives EJB3 a life of its own and unbinds it from the AS release cycle.  While there’s still some work to be done in this regard, the end goal is twofold:

1) Release EJB3-only updates to AS with regular frequency
2) Don’t require AS to run EJB3

Componentize

@see http://en.wikipedia.org/wiki/Software_componentry

The idea here is to separate the logical moving parts into isolation; this way we don’t:

1) Mix concerns
2) Allow bugs in one area to pollute another

…while we do:

1) Enjoy small, easily-maintainable projects
2) Promote Unit Testing (in the true spirit of “Unit”, not to be confused with “Integration” or “Acceptance”)

Unit Test

We’ve always tested, by means of an integration testsuite that takes ~90 minutes to complete.

But componentization has given us the opportunity to create small, focused, and quick Unit Tests.  Currently we’re at 207 of ‘em, which run in about 5 minutes locally or 8.5 minutes from a freshly checked-out CI server.

Baby, that shit’s textbook.  Better curves than a pinup girl.

All told, we’re beginning to see the concrete benefits of these investments, which translate into accelerated, reliable development.

JEE Compliance is like marriage – not a conclusion, but a beginning.  I just hope compliance doesn’t mean you stop having sex.

S,
ALR

My childhood home really had it all.

Nice deck overlooking Callahan State Park, bicycle-friendy cul-de-sac, open living room with French windows, eat-in kitchen, and suburban zip code.

For years, it even had a hugeass Oak tree that seasonally fired acorns at your skull if you dared retrieve the mail.

So my parents never moved, and that’s why I’m friends with the same fuckers I knew back in preschool. I guess the house just worked for my folks.

And it must have worked for my neighborhood’s developers too, because don’t you know – they put three-hundred just like it next door.

[STAMP] 7 Rolling Drive [STAMP] 9 Rolling Drive [STAMP] 11 Rolling Drive …

Clearly, the economies of scale provided by a reproducible build plan were obvious to those guys.

My least favorite responsibility as Application Developer is the composition and maintenance of build files. Every once in awhile I’ll read a book that cites different roles within an organization – DBA, Backend Programmer, Frontend Programmer, GUI Designer, Assembler, Deployer, SysAdmin – and wonder why I’m doing all of them for one paycheck. I always wished there was some sucker down the hall with a business card that read “Assembly Engineer” to whom I could shove off all copy/compile/JAR tasks before going about my day.

Guess I’ve never been lucky enough to have that resource.

Here’s the problem: As simple as JBossAS is to get set up, once you start developing your application it’s likely that your server configuration will begin to sway from the default. It’s no longer an “unpack and run” situation, and this introduces a dangerous element; the environment used for local development might look very different from that used in primetime. Unless these changes are kept in check, it’s really easy to introduce bugs. Your application is not what you craft alone, but the sum total of all code churning at runtime. Everything needs to play nicely.

Easily fixed; with the introduction of an automated process, we can install and configure our server at the click of a button. This will keep our various environments in sync, with explicit differences we knowingly introduce.

I used to accomplish these goals using a series of Ant scripts, but anyone with experience in this arena knows how hellish making extensible Ant files can be. And forget cross-project portability. So this time around I’ll piggyback on Maven’s conventions.

Though close, CodeHaus’s jboss-maven-plugin didn’t quite hit the nail on the head for me. Architecturally, I needed some backing common libraries (unbound to the Maven Plugin API) such that I could mashup many of the components together for the new JBoss EJB3 Mavenized TestSuite. Not to mention that the SVN links are either outdated or the project is gonzo (Anyone? Bueller?), and I needed to add features.

Therefore, now under construction is the JBossAS Control Maven Plugin. This Blog entry is a Request for Comments.

Current Roadmap of Supported Goals Targeted for 1.0.0.GA:

install

Check for an installation at $JBOSS_HOME, and if not there, download and unpack a fresh version. May run in forced mode to always wipe the existing installation. Before I release this feature I’ll have to check with the appropriate channels about the legality of grabbing binaries from SourceForge, if there are some consent agreements or other useless red tape that have to be addressed.

create-config

From a specified base, create a new configuration. Customize by adding/overwriting/deleting as appropriate. This starts us off from a well-known default, applies the delta that makes our custom configuration, and exits. An added benefit is that we know our custom changes implicitly. KISS.

deploy

Grab the specified deployable unit(s) and deploy ‘em.

undeploy

Control-Z the deployment of specified artifacts.

start

Start a JBossAS configuration with appropriate JVM/Server arguments.

stop

What goes up, must come down.

Anything else I should be including? Or specific implementation requests for these features?

In the short term, I’ll update this entry with Anonymous SVN Access[1] and links to other instructions when they become available.

I think that should do it for this project’s scope. Also in the works right now is a functional sample project illustrating the proper configuration of these goals within the Maven Lifecycle. With one command you can get a fresh copy of the server, configure it, start it up, deploy your application, run integration tests, and bring the whole thing down before generating reports.

Good for continuous build. Good for ensuring your local development environments are sync’d up with the stuff you’re putting in Stage/Production.

[STAMP] My Application 1 [STAMP] My Application 2 [STAMP] MyApplication 3 …

Well-planned integration testing addresses the differences in your server environments.

[STAMP] My Application 4 …

Reproducible build plan at every level is an absolute necessity.

Until you come home drunk one night, and can’t find your house because they all look the damn same.

S,
ALR

Reference:
Continuous Integration, Martin Fowler, 2006

Edits:
[1] http://anonsvn.jboss.org/repos/maven/plugins/jboss/trunk/

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