Moving from SOA hype to reality requires a frank look at some problems SOA does not solve. This section will explain why SOA should not address them and show how a relatively new integration technology can help achieve SOA?s interoperability goals. Consider some project building some SOA service, a sensor application for example. We?d 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 so long as 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. Fortunately 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, much 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. -- Brad J. Cox, Ph.D.