So I want to pontificate about SOA in the Enterprise for a few minutes here. I, as an “enterprise” developer obviously have an opinion on this topic, but this final rant was spawned by listening to Dalibor on Java Posse speaking of OSGi in the Enterprise. I had a similar conversation with
Brian Ehmann, the Java Posse intern, a while back. So I want to address several things.
First, I want to talk about OSGi, and why I would never allow it in “my” enterprise. In “my” enterprise I want absolute control over what every service has in its runtime environment. Indeed, as a longtime Fedora user, one of the things I loathe about its Java support is the dependency system that works just as Dalibor describes — at the OS level. The beauty of Java on the server is that applications and their API dependencies can be packaged into a single artifact (WAR/EAR) that is completely isolated from the library install or configuration of the server itself. Anyone who has dealt with install libs on Unix machines understands this. Indeed, if any two of your “enterprise apps” had to have the same version of something even trivial, like Log4J, this could become a serious problem for deployments.
Secondarily, the last thing I want is my application “updating” itself without my (or Major League Baseball’s) expressed written consent. One of the “theories” I have espoused for a long time, and indeed one of the reasons I fell in love with J(2)EE is the WAR file, and having a singular artifact from the developers. A WAR/EAR file is an artifact that can be built by development and move seamlessly from development, to QA, staging and production as a singular, atomic unit. As soon as you introduce dynamic dependency updates in your production systems, you have lost this atomicity in terms of production bits. It is true that OSGi does not mandate this loss of atomic control, but it does encourage it.
Of course, this example has a certain narrowness of focus. Of course things within the enterprise change, but one of the advantages of a Web Services based infrastructure is low-level dependencies as I have discussed to this point are maintained independently. At the service level, of course you need to control change. In my current environment we do this by endpoint management and control. This is one of the things that strikes me as a failing of “SOA” as a “solution”. Endpoint discovery is almost never a real problem for the enterprise. Low level network services like DNS are perfectly adequate for controlling this. Barring that, in the “WS” world. simple things like controlling HTTP routing through Apache or a specialized load balancing product work well. These solutions make it easier than most “SOA” products to run multiple live versions of a service without forced deprecation as well. Sure OSGi can operate at this level for service version control, but why trust it? Why allow binary update of runtimes on servers when endpoint URIs are easier to control over time?
Finally I want to address the issues of SOA as a failed technology. Bill de hOra and Joe Gregorio have noted that SOA has reached the “assign blame” state of failure. Indeed, here on the O’Reilly network shadows of this meme have kicked around.. I want to note that SOA is still a valid idea, but much like BPM, the marketing doesn’t live up to the hype. In enterprises with “architect” staff who are fundamentally unqualified– though I don’t believe the position is unnecessary in medium-large organizations — or a technical debt load that has become unmanageable, SOA proffers no real solution to any problem. Companies selling their SOA product as a silver bullet to said architects that will eradicate said debt are doing so at their own peril. Best case, their thousands of dollar projects will be quickly forgotten failures. Worst case, these enterprises will feel scorched by the failure and never want to deal with the same companies again. In reality, the former is most likely, since the people making the decision to go with the failed technology products will keep their jobs, blaming the failure not on their own lack of understanding of the enterprise they are responsible for but the vendors. Indeed, these sales relationships mean the same vendors get to come back when the next “Silver bullet” enterprise solution is available.