SOA tools--virtually bridging the legacy divide Part 2

Semantic integration

Once services link applications, some tool has to figure out what the data in different applications means, to see how it relates. For instance, if data in one application is classified by the heading "PO" and data in another is classified by the heading "Purchase Order," the data probably is related. Therefore, to track an order through a B2B process that spans those applications, users have to leverage SOA intelligence that correlates those two data sets as being the same kind of data. Semantic integration tools provide that intelligence.

According to Bloomberg, vendors offering semantic integration are trying to come up with a way of naming semantic links within the context of particular business processes. "So if you're talking about electronic claims submissions," he says, "then there are certain things you can assume--for instance, that an electronic claim would have a provider, a date of service, etc."

A semantic integration tool developed for electronic claims, he explains, would then be able to identify the fields that mean the same thing in different electronic claims applications, and indicate the relationships among the data in those fields once a company has linked those disparate applications via services. That capability lets users process orders, for instance, by accessing the same type of data in disparate systems in a consistent way. However, it does not convert data formats and message protocols.

Service-oriented integration

According to Daryl Plummer, Group VP of software infrastructure at Gartner (gartner.com), tools called enterprise service busses (ESB) convert message protocols and data formats of different kinds of middleware either into a common language, in which the relevant systems can communicate, or have adapters for all the middleware customers might have so communication can occur using original protocols and formats. Companies generally use the common language approach if they already have an infrastructure based on the common language of the vendor's ESB, Plummer says, and the other approach for very heterogeneous environments, with many middleware systems all over the organization where data has to be accessed from its existing location in its original protocols and formats. Some environments are better suited to a hybrid approach where they add adapters to an existing ESB.

How the majors approach SOA tools

Any company that implements an SOA environment will do so by working from a legacy platform provided by one or more of the major platform players, and will probably have used cross-platform software like enterprise application integration (EAI) to link applications on disparate platforms. So vendors of that ilk have a great stake in providing customers with SOA tools that complement their legacy products and services to extend their reach into their existing and new customers' environments and build market share in the new SOA paradigm. Because most of them offer tools and consulting across multiple categories and life cycle phases, the majors tend to offer SOA programs built around multipurpose, not point, products.

IBM

Plummer believes IBM's approach will be to adapt its wide range of large-scale, message-oriented middleware to be SOA-friendly and support customers with SOA integration through Global Services via two soup-to-nuts programs, the Business Integration Adoption Model and SOA Integration Framework. However, it's late to the game with a true ESB, a key SOA tool. Its strength, therefore, will be SOA professional services. Its weakness, says Bloomberg, will be lack of software focus. "They're trying to pull together all the pieces of their software suite--WebSphere, Tivoli, Rational, DB2, Lotus," he says, "into single SOA story … but it comes across as a collection of mismatched parts that you have to stick together."

Oracle

With its SOA Suite, Oracle is trying to integrate technologies, like process management, that it's gained through acquisitions to convince customers it has a soup-to-nuts SOA platform and strong and various applications. Plummer says its strength is the breadth of technology to which it has access, while its weakness will be the time it will take to seamlessly integrate rather dated technology in its own and acquired products. Oracle's brand app, of course, is its database, and it eschews professional services. Convincing customers it has more than database-centric expertise will take time too.

Microsoft

With its Dynamic Systems Initiative platform program and Windows Communication Foundation (a kind of ESB), says Plummer, Microsoft is proving it can create and deploy services, but still relies on partners to do governance and management. On the one hand, .NET apps already are pretty easily integrated, says Bloomberg, so evolving an SOA environment using just them might take less time than using best-of-breed products. But adopting .NET creation and deployment tools may make it harder to dynamically interoperate with disparate platforms down the road. However, he thinks Microsoft sees SOA as a way of getting into the back-office legacy environment dominated by high-powered middleware and database vendors like IBM and Oracle, so it might embrace true interoperability to help this happen.

Hewlett-Packard

Through the HP OpenView and, more specifically, HP SOA Manager programs, HP offers end-to-end management professional services and some software. According to Bloomberg and Plummer, HP has excelled in enterprise systems management so it will emphasize high-level architecture mapping and governance, and systems-level management activities like root-cause analysis over early phase activities like service creation.