Free Newsletters

   All InfoWorld Newsletters
Real World SOA | David Linthicum » Modeling Data Access for SOA

October 11, 2007 | Comments: (0)

Modeling Data Access for SOA

There has been a lot of interest lately in modeling data access in the context of SOA, and few understand how to do it. Indeed, many of the same "traditional" data modeling techniques still apply, but SOA brings its own complexities.

At the core of the issue are models for access, or the way in which we view and access data and information at different levels within the SOA. Within a typical SOA we have levels to consider:

  • Physical, referring to visibility at the actual physical database level, in essence going after the raw data.
  • Schema, referring to visibility to the schema, in essence putting structure around the data.
  • Abstraction, referring to the remapping of the schema so it's more workable and logical for the SOA.
  • Semantic, referring to visibility into the meaning of the data.
  • Service, referring to exposure of the data through services.
  • Transaction, referring to the binding of the data and/or data service(s) to transactional service(s).

The core point here is around the different views, or models, leveraged at each level. Which model to employ when, depends on how you want to view and process the data in the context of your SOA. What's key here is that you select and define those views, including models employed and enabling technology and standards for access.

We'll have to dig a bit deeper here within future posts. Any comments are welcomed at this point.

 

Posted by Dave Linthicum on October 11, 2007 03:32 PM


RATE THIS ARTICLE:





 

  •  
  • COMMENTS




My personal point of interest in this discussion is the role played by the schema. I find that as SOA is discussed within our organization, schema is frequently the point at which most disagreement occurs.

Those who lean towards efficient data storage and maximum normalization across the enterprise tend to suggest that 1. We should concentrate on optimizing data storage as our top priority and that 2. We should therefore enable data access using an API + unified data source paradigm where all data access occurs through a tightly defined gateway.

Those who lean towards business process agility tend to suggest that 1. We should concentrate on optimization of business processes through service orientation and that 2. We should therefore allow services to regulate their own data access using a more federated data storage solution.

Obviously there are those who advocate a blended approach whereby services use dedicated data-handling services which abstract the access to data, but frequently this results in an uneasy tension between the efficiency and agility pundits. Is there a way to resolve this tension, or does this tension represent a positive creative force?

Posted by: Andrew Gibson at October 15, 2007 10:02 AM

Virtualizing your data to hide complexity and simplify data access is valuable for any type of solution, transaction or analytical, SOA or not.

Don't let these varied points of view obscure the fact that you have data silos that aren't going away and new applications that need the data they contain.

Your options are few:
1. Hand Code (with our without an ESB)
2. File extracts / database replication
3. ETL with marts/warehouses/operational data stores
4. Virtual

Virtual, where you avoid replication and federate the data on the fly, fits beautifully with the data abstraction models that Dave Linthicum advocates. All the other approaches are the anti-SOA; tightly-coupled, inflexible, costly, non-reusable, and more.

Robert Eve, Composite Software

Posted by: Robert Eve at October 16, 2007 11:07 AM

Technology White Papers

 

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert

Find out when the latest white paper is available:
 
 
» BUY A LINK NOW

Sponsored Technology Links