Why Sun bought SeeBeyond

Acquiring SeeBeyond skews Sun's SOA strategy even more firmly into Java. That's fine if customers want to center their applications infrastructure on an all-Java strategy — plus Windows in places, since Sun's interoperability pact with Microsoft should safeguard the service interface to the .NET environment — but what if they want their SOA to embrace other platforms too, anything from legacy mainframe environments to the latest new ideas to emerge from the LAMP or grid communities? I know Java has the advantage of being a multi-vendor platform, at least in principle, so you could do a lot worse than standardize on Java. But as I said when Sun first announced its SOA strategy at last year's JavaOne, the main point of SOA is supposed to be platform independence, and "when [vendors] talk about having an SOA strategy what they're really advancing is a plan that allows them to offer SOA on their own terms. That will rarely coincide with what's best for an individual customer."

Sun has kept faith with the schedule it set out last year, delivering its services registry and the Java Business Integration framework (aka JSR 208) as promised in the first half of 2005, along with upgraded SOA and web services support in its development tools. It has also strengthened its identity management products and promised to ship an open source ESB.

There are a few more rough edges to smooth down, but once it ships version 5 of Java Enterprise Edition (Java EE 5), all the missing pieces should fall into place. Anyone who wants to build a Java-based SOA should find everything they need, either within Sun's product range or available from partners.

Provided that an organization is happy about standardizing on Java (as I say, there are a lot worse platforms to standardize on), the main pitfalls to beware of are scattered along the very fuzzy boundary dividing infrastructure from applications. That dividing line begins somewhere within Java Business Integration (JBI), which despite having won formal approval from the Java Community Process, did so in the face of reservations expressed by both IBM and BEA, who abstained from voting.

BEA described JBI as "an incomplete attempt to standardize the interfaces between multi-vendor infrastructure," while IBM said that other technologies and specifications offer "more compelling interoperability and better mechanisms for component composition." IBM went on to explicitly say that it was unhappy about JBI precisely because it is tied to Java: "integration with the broadest range of platforms, applications, and existing business assets ... demands a language-neutral approach using today's Web Services standards."

In this context it's interesting to look afresh at the acquisition of SeeBeyond, which Sun will promote to customers as the preferred vehicle for implementing JBI. The SeeBeyond deal was unexpected, but only because Sun hadn't been expected to buy an EAI vendor. Sun was already close to SeeBeyond, having announced an alliance to jointly build and market SOA solutions last October. SeeBeyond's platform is Java through and through, so integrating the company's technology and culture into Sun's isn't going to present any major difficulties. Once you accept that Sun was going to buy an EAI vendor, then SeeBeyond becomes the obvious choice.

But isn't it a contradiction in terms to buy an EAI vendor to complete an SOA stategy? The whole point of SOA is to be able to move on from EAI — which is why all the EAI vendors, SeeBeyond included, have been eager to cast off their legacy EAI heritage and recreate themselves as SOA vendors. They can see the writing on the wall. Indeed, SeeBeyond's ICAN 5 suite, announced two years ago, launched into this strategy at full tilt, embracing open web services standards and Java EE (then known as J2EE).

But few of SeeBeyond's own customers have chosen to migrate to ICAN 5. One of those that did was the subject of a Loosely Coupled feature article entitled Going halfway to SOA. As the title suggests, even then the objective was not to move to full SOA, simply to adopt a messaging-based architecture that ran on a vendor-independent J2EE foundation.

The trouble with SOA for business integration, as SeeBeyond will readily tell you, is that the standards are not really in place to co-ordinate things at that level in a non-proprietary way. If you're going to build composite applications today, you're going to have to fill in some of the gaps that currently exist between the various proposed specifications (few of which have yet been submitted to standards bodies, let alone reached formal standards status). EAI vendors like SeeBeyond are quite pleased about this, of course, because it means they can still add lots of proprietary value-add. For vendors like Sun, it gives them a choice between holding back until the standards firm up some more, or of going ahead with a more proprietary platform. BEA has chosen the former path with its AquaLogic announcement, much of which is focused on composing applications using tools and platforms that it hasn't yet finished developing. By buying SeeBeyond, Sun has chosen the latter option, and in this context you can see the vital role that JBI plays in adding a veneer of standards compliance to a product that uses proprietary code to achieve most of the higher-level business integration.

More than a few times when researching and writing about SOA migration and adoption, the phrase 'putting lipstick on a pig' crops up. Legacy EAI, proprietary platforms and vendor-centric roadmaps are the pigs in the SOA farmyard. In transitioning to SOA, vendors often need to put a more pleasing facade on infrastructure that frankly doesn't measure up to the ideals of SOA. The combination of SeeBeyond and JBI gives Sun some fancy new lipstick, but a much less attractive reality lies beneath the surface gloss.

posted by Phil Wainewright 9:47 AM (GMT) | comments | link