JOSH: A Proposed Software Stack for the Enterprise

Posted by Abel Avram on Mar 25, 2009

Community

Architecture

Topics

Enterprise Architecture

Tags

Legacy Code ,

JSON ,

HTTP ,

OSGi ,

Scala

Grey Lens Man, a blogger who does not decline his identity, posted an interesting piece about legacy problems plaguing the enterprise and proposes a new software stack as viable solution: JOSH, JSON OSGi Scala HTTP.

Grey Lens Man tells a well known story of the enterprise IT:

You see, I have a small problem - 3 million lines of RPG and COBOL, 5,500 logical and physical files on a few AS400s that are not exactly cheap. Even better through the years, the system has been cloned and forked so several incompatible versions of exist through out the world.

And it is even more painful, as it happens:

I won't go into excruciating detail, but let me leave it like this; within that 2.5 T of data there resides a special flag in the customer file, which determines the fundamental nature of how a customer interacts with the system, and it can be found in Filler3, third byte from the left. In one file, the Account ID column sometimes actually does contain the Account number but not always, sometimes its something else and its torched us. And you'll never guess what that ZipLoc3 column_really_ contains (hint: nothing like a zipcode).

When he talks about a solution for the problem, Grey Lens Man is quite frank:

No one wants to keep it [the legacy system] on life support, so doubling down the head count to reverse entropy, or putting some sort of SOA lipstick on this pig is something we'd like to avoid. The problems are fundamental and systemic.

The solution proposed by Grey Lens Man is JOSH, 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.

Ted Neward appreciated the proposed solution but also expressed some concerns:

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. …

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. …

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.

And there is another important layer missing from the stack, the persistence layer, and Grey Lens Man is still looking for a solution. Ray Krueger proposes JOSCH, where C stands for CouchDB. Grey Lens Man appreciated the proposed solution but is inclined more toward Cassandra or Voldemort. Neward likes CouchDB as a possible solution, but also suggests db4o. He goes further pondering what a corresponding solution for .NET would be: JSON + Assemblies + F# + HTTP = JAFH.

1. Back to top

   JSON + REST

   Mar 25, 2009 8:44 AM by Christopher Brind

   I already use a similar stack:
   OSGi + AMF3 + HTTP + Flex (for UI) + db4o (for persistence)
   
   The advantage that AMF3 has over JSON is that it understands object references, so if you serialise the same object more than once, it will use a reference. Obviously, AMF3 is totally unreadable by humans, but perfect for Flex clients.
   
   That said, after listening to some of the guys at TheServerSide.com Java Symposium I am definitely going to consider using a REST oriented architecture in the future and am likely to switch to:
   OSGi + JSON + HTTP + Flex + db4o
   
   Main reason being that JSON is not much more difficult to handle in the Flex client and comes with a whole bunch of advantages that I'm prepared to lose AMF for.

   Reply

• Older >