A new stack: JOSH

---

An interesting
blog post was forwarded to me by another of my fellow ThoughtWorkers, which suggests
a new software stack for building an enterprise system, acronymized as “JOSH”:

The Book Of JOSH

Through a marvelous, even devious, set of circumstances, I'm presented with the opportunity
to address my little problem without proscribed constraints, a true green field opportunity.

Json OSGi Scala HTTP

Json delivers on what XML promised. Simple to understand, effective
data markup accessible and usable by human and computer alike. Serialization/Deserialization
is on par with or faster then XML, Thrift and Protocol Buffers. Sure I'm losing XSD
Schema type checking, SOAP and WS-* standardization. I'm taking that trade.

OSGi a standardized dynamic, modular framework for versioned components
and services. Pick a logger component, a HTTP server component, a ??? component, add
your own internal components and you have a dedicated application solution. Micro
deployment with true replacement. What am I giving up? The monolithic J2EE application
servlet loaded with 25 frameworks, SCA and XML configuration hell. Taking the trade.

HTTP is simple, effective, fast enough, and widely supported. I'm
tired of needlessly complex and endless proprietary protocols to move simple data
from A to B with all the accompanying firewall port insanity. Yes, HTTP is not perfect.
But I'm taking this trade where I can as well.

All interfaces will be simple REST inspired APIs based on HTTP+JSON. This is an immediate
consequence of the JOSH stack.

Scala is by far the toughest, yet the easiest selection in the JOSH
stack. I wrestled far more with the JSON or XML or Thrift or Protocol Buffers decision.

And, let’s be honest, the stack sounds a lot better than what he was working with
before....

[...] Yes, you see, I have a small problem.

So whats the issue, you say? I write a whole blog about nothing, you say? We all know
the right answer, you're pointing out? Yea, I know, its intuitively obvious to the
casual observer.

We'll rewrite it from scratch.

Course we'll need a cluster of WebSphere Application Servers, and an Oracle RAC cluster
for all that data. Don't forget the middleware needed to transition over from the
legacy systems, so toss in an ESB cluster, and what heck a couple of BPEL servers
too.

Need a SOA Center of Excellence of course too. Can't integrate without some common
XML Business Object Schemas. Also need to roll the Rational RUP suite and some beefy
IDE environments and for that shiny look, sprinkle the works with lots of WS-* sparkly
dust. Bake 3-5 years or until done, whenever.

My presentation slides for all this will be killer. I can sell this stuff. I'm good
at it. I'll look like a bloody genius. I'll have Vendors fawning all over me. And
the best part is the bubble on this mess won't pop for YEARS, when I'll have plenty
of plausible deniability. "Hey the plan was perfect, the business, IT managers
and their people were incapable of executing it."

I feel like the enterprise IT equivalent of an AIG trader pocketing ill gotten gains
from writing Credit Default Swaps that we can't pay off.

Ewww... even thinking about all that makes me want to go upstairs, step into the shower,
turn the water as hot as it will go, and wash. Scrub my skin raw with soap and sponge
until the top five layers of epidermis are gone, and still not feel clean.

On the surface of things, the stack sounds pretty good. OSGi is a pretty solid spec
for managing versioning and modularity within a running Java system, and more importantly,
it’s well-known, relatively reliable, and pretty well-proven to handle the classic
problems well. And of course, anybody who knows me knows that I’m a fan of the Scala
language as a potential complement or supplement to the Java programming language,
so that’s hardly in debate.

But there are a few concerns. JSON is a simple wire protocol, granted, but that is
both a good thing and a bad thing (it’s object-centric, for one, and will run into
some of the same issues as objects do with certain relationships), and it lacks the
ubiquity that XML provides. Granted, XML clearly suffered from an overabundance of
adoption, but it still doesn’t take away the fact that ubiquity is really necessary
if you’re building a baseline for something that will talk to a variety of different
systems. Which, I admit, may not be in his list of requirements, I don’t know. And
HTTP is great for long-haul, client-initiated communication, but it definitely has
its limitations (which he acknowledges, openly, to his credit), at least to internal-facing
consumers. There is no peer for external-facing consumers, that’s a given.

And the stack is clearly also missing something else...

The JOSH stack is lacking a letter, because a solution for persisted data is missing
in the stack.

A great deal of what needs to be done does not require a ACID RDB cluster. Some of
it does and I'm kicking that can down the road.

For the rest, either the data is ReadOnly and loaded a 1-3 times a day or is best
persisted by a distributed Key-Value storage system. A number of these are now available
as open source solutions and at the right moment I'll need to pick one and add that
letter to the JOSH stack.

As a commenter suggested, CouchDB might be a solution here, or I’ll even throw db4o
into the ring for discussion as an option. Again, it’ll depend on how far-and-wide
the data will be seen by other systems—the more other systems need to see it, the
less further away from a “regular” RDBMS we can go.

Certainly, it’s a great start for discussion, even if the acronym is likely to give
those named Joshua an unhealthy ego boost. :-)

Part of me wonders, though... what would the equivalent on .NET look like? JSON +
Assemblies + F# + HTTP = JAFH?

---

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.