DOD needs bricks, not just java clay and sand (ala JBI/SCA/SoaKit)

Note Added: This is a old article that I wrote to address the SOA Blindness that is now prevalent within DOD; the belief that SOA-scale integration is all that DOD needs. Its tries to show why an intermediate level of integration can address a major unsolved problem; SOA security and interoperability.

JBI and SCA seek to provide this intermediate level, which is why I singled them out by name. But on digging deeper, they turned out to be far more complex than this problem requires.  I eventually adopted a much simpler approach based on plain threads and queues with OSGI for modularity. I call this approach SoaKit; a collection of pluggable components for addressing SOA security and interoperability. Such components are the bricks mentioned throughout this blog. Plain java class libraries are the clay and sand.

Java Business Integration (JBI) is a Sun initiative to provide a Enterprise Service Bus for SOA services. Software Components Architecture (SDA) is a newer and far more ambitious OASIS-sponsored initiative to meet the same goal in a language-independent manner. SoaKit was originally based on JBI but has since switched to a much simpler bus based on native Java threads and queues. The needs explanation remains sound although SoaKit is no longer based on either JBI or SCA.

Consider some project building some SOA service, a sensor application for example. DOD would like to deploy that service to many different environments ranging from the lab's firewall-protected LAN to hostile environments on platforms as diverse as submarines, aircraft, and land vehicles. Each platform has unique communication capabilities and each threat environment has unique security and interoperability requirements.

But if projects are responsible not only for the services' core functionality, but also for its communication, security and interoperability requirements, the ability to reuse services across threat environments, platforms, and communication infrastructures is lost. So long as projects are responsible for developing service's full functionality in programming languages such as Java or C++, services cannot be deployed to diverse environments without changing the code and testing it from the ground up.

To gain SOA's promise, we need a way to let service development projects focus on their core competencies (the project's functionality objectives; sensor functionality in this example), and address enterprise requirements (connectivity, threat environments, security, communication links) without without changing the product (the sensor service)'s core logic.

A relatively new standard is available that does exactly that, although its advantages are largely unknown, obfuscated into oblivion by astonishingly bad terminology. JBI (Java Business Integration) is actually an integration technology similar to SOA. I'll concentrate here on why JBI is so important without explaining the arcane terminology used by its devotees, as this is available elsewhere.

JBI is an integration technology, just as soldering irons are the integration technology for making circuits out of chips, resistors and so forth. The technology is wielded by a new class of developer that I'll call configurators to distinguish them from programmers. Just as programmers assemble JBI components from lower level objects in programming languages like Java, configurators assemble SOA services from pre-existing JBI components by using XML as the configuration language.

Our general-purpose sensor service is one example of a JBI component but there are many others. Anything that abides by the JBI specification can be used as a JBI component. JBI development environments (Glassfish is one of several examples) have many others that configurators use to deploy bare Java functionality to meet the requirements of each new operational environment. Attach a pair of LAN transport components and the service qualifies as a participant within a fire-walled SOA lab environment. Replace them with transport components suitable for an aircraft or submarine and the sensor component can participate as a service within a low-threat SOA environment. To deploy to higher-threat environments, just configure in encryption, signing and integrity components, which are all provided by the JBI environment. If the sensor must communicate with incompatible services, just mediation/translation components can be added just as easily.

JBI does this by defining an internal bus like the external bus that SOA services use to communicate. Configurators use XML to connect off-the-shelf JBI components via this bus to achieve the needed effect. The net effect is that new components (like that sensor package) can be developed and tested for functionality without concern for how the service might be deployed later. This allows sensor experts to concentrate on building sensors without concern for matters beyond their specialty, such as how to secure that sensor against every-changing threats, platforms and communication technologies.

The same advantages apply to testing. Without JBI, obtaining authority to operate, for thousands of SOA services involves testing not just the services functionality, but whether it complies with security, interoperability, and transport constraints. JBI means that the new service need only be tested for whether its core functionality is correct. The service can then be protected by pre-existing encryption, signing, verification, transport and even mediation components, each of which is developed and tested within its own independent development cycle.