“SOA starts to blur the difference between data and applications,” says Ron Schmelzer of ZapThink, an SOA market research firm. When a set of applications performs some function, isolated as an independent service, the results can look a lot like data as they’re passed off to another application. Likewise, a query to a service that triggers a stored procedure in the database yields results that look a lot like an outcome of application logic. In services, data ceases to exist as something distinct from the application logic.
Not everyone is a fan of the iWay approach to integrating data across services. “I have always been somewhat skeptical,” says ZapThink’s Schmelzer, because it is too close to the old application-to-application integration of yesteryear, where each connection has to be set up individually and is inflexible.
Services need to be architected so that they yield data that can be consumed by various applications, although iWay’s Service Manager manages much of that task. Companies also need to be able to change how data is presented without altering the service interface. IWay, however, often requires an interface for each presentation rather than producing data that can be easily used across all of them, Schmelzer says.
Read more at: InformationWeek


Discussion
No comments for “Two Ways To Deal With SOA’s Data Integration Challenge”