Venkatapathy said SDO supports both static and dynamic programming APIs, various tools and frameworks, disconnected programming models and custom data access layers. It can also decouple application code from data access code, paving the way for the reusability SOAs are known for.
IBM’s new WebSphere Process Server is the company’s most advanced tool for powering a service-oriented architecture (SOA).
One of the key motors driving the software, and other updated WebSphere products, is an abstraction layer technology Big Blue calls Service Data Objects (SDO) that goes where Java can’t in modern programming.
Chandra Venkatapathy, IBM WebSphere manager for Process Servers, said that SDO makes it easier for applications to handle data, providing the abstraction required for a distributed computing environment like an SOA.
“We wanted to get unified data access to heterogeneous sources,”
Venkatapathy said in a briefing this week with internetnews.com.
“It’s not necessarily a relational database. It can be a Web service, a flat file, or a business object from some other software.”
For a long time, IBM, Sun Microsystems, BEA and Oracle have hung their hats on Java, which offers a variety of data programming models and APIs
But Java does not always work well with other tooling types, and APIs such as the Java Database Connectivity (JDBC) deals strictly with relational data. SDO is intended to create a uniform data access layer that provides a data access solution for heterogeneous data sources
This separation is crucial for processes such as a Web-based purchase order, where customer information may come from one source and account information may come from another source, etc.
“When you go to service orientation, if you want to change one of the applications, the process may not change but the application will,”
Venkatapathy said. “How well your objects are decoupled is they key to success because they can handle the shock that happens in data relay. So, if a system goes bad, the SDO can do the mapping to change to something else.”
With SDO, this transformation happens seamlessly and on the fly — the way Web services
“The beauty of SDO as an abstraction layer is that we are using it and, surprisingly, not many people know that we are using it,” Venkatapathy said, noting that SDO is also used in WebSphere Application Server.
SDO may not be mainstream in terms of public exposure. That could change as the market for SOAs evolve and the demand for dependable plumbing grows.
IBM WebSphere Software General Manager Robert LeBlanc alluded to SDO in a conference call last week to unveil
the company’s new enterprise service bus (ESB)
Responding to a question about how its new products accommodate standards such as Java Business Integration (JBI), LeBlanc said:
“IBM believes integration should go beyond just Java and that there is set of a capability and technology we’re introducing within the Process Server that over time we will look at bringing to the open community,” LeBlanc said. “But we want to make sure the technology is hardened and can solve customer problems before we bring this forward.”
In SDO, Forrester Research analyst Mike Gilpin said IBM sees an opportunity to standardize a container interface and binding definition that would be more general and less Java specific than JBI.
Such a standard would have the same basic objective, he said: to enable containers from multiple vendors to federate with one another over Web services intermediaries like ESBs, and support composite applications.
“Today this is hard because each container has a somewhat different interface for deploying services, running them, and monitoring and managing them,” Gilpin explained.
“Although within the J2EE world there are some standards for this, there’s not a full equivalent set of capabilities available that would work across any container, including .NET. I don’t know that there’s a project there (open source or otherwise), but it sounds like a good idea to me.”