Real World SOA | David Linthicum | InfoWorld | Using a Common Data Model with SOA | July 3, 2007 05:13 AM

MORE ENTRIES

Using a Common Data Model with SOA

July 03, 2007 | Comments: (0)

Using a Common Data Model with SOA

Lately I've been hearing a lot about common data models when it comes to SOA. As organizations attempt to figure out the data in the context of SOA they are driven many times to the notion of a common way to view data as a part of the architecture.

Case in point is this post from Kjell-Sverre Jerijærvi who points out the need and the notion of a common or Canonical "Data" Model.

"An important topic when designing service oriented systems is how to enable different services to share semantics to be able to be composed into working solutions."

While this is something I've been pushing for years, I'm now seeing some good thinking around this problem and some good technology behind it as well. The data is the single most important component of an SOA, and you need to think carefully about how the data is managed. Simply tightly coupling the data to the services won't serve the notion of agility, and you're really not solving your data problems.

"Making every service contract depend on the One True Schema will make it impossible for the services to evolve separately, they will no longer be autonomous."

Thus, the data is important, and you need to figure out management, aggregation, and abstraction approaches before you begin bolting on services. While many agree that starting with the data is a sound approach, the majority of SOA projects I see are starting with the services, and working back to the data. While that's not a horrible approach, you'll find that you'll be redesigning and redefining services after you figure out your data layer, and in many instances the services will have to change significantly.

Some key takeaways from all this:

You need to face the data first and define a common data or abstraction layer so that the services are not bound to a particular schema, but enjoy the use of the data nonetheless. I would not push a common schema as much as an abstraction layer.
The abstracted or common model should be tested like any other component.
Don't focus as much on force fitting a data model as agreement across the service domains, and leverage a schema mapping layer to provide choices in the future and agility down at the data layer.

Posted by Dave Linthicum on July 3, 2007 05:13 AM

RATE THIS ARTICLE:

COMMENTS

Hello David,

I blogged on this topic recently:
http://blogs.msdn.com/nickmalik/archive/2007/06/30/getting-the-enterprise-canonical-data-model-right.aspx
and
http://blogs.msdn.com/nickmalik/archive/2007/06/12/canonical-model-canonical-schema-and-event-driven-soa.aspx

One key thing to keep in mind: it is as important to create the event model as the data model. That is where the SOA model, based on Event Driven Architecture, becomes real to both developers and business users.

Posted by: Nick Malik at July 11, 2007 10:00 AM

"SOA projects I see are starting with the services, and working back to the data."

Since the purpose of the data is to achieve something related to the business, it seems to me that starting with the service is the most natural approach. You really have to ask "What do we want to do?" before you can say what you will need to do it.

"you'll find that you'll be redesigning and redefining services after you figure out your data layer, and in many instances the services will have to change significantly."

I don't see why the service would "have to change significantly" since the service defines the data. Of course, if the service was postulated on the availability of data that turns out to be problematic, then certainly the service would probably be redefind.

As for "redefining services after you figure out your data layer", I have often found one version of that almost always present but underutilized. As a developer and programmer, when I am defining the components that solve a problem, I am generally limiting them to solving the problem at hand. However, while defining the objects I am creating, I often can see ways they might be expanded to provide additional dimensions to the business model.

For example, when I was told that large client x was going to get a special, negotiated rate for various services, and would I please program the rates, naturally I proposed a slight generalization that enabled them to offer special rates to any client. I realized the limit management had originally placed on the change and was in a unique position to explain the benefits of relaxing that limit.

I think it is agile programming that has a motto that means something like don't make it if it isn't necessary, but a keen eye can discern opportunities for improvement that will well repay a slight additional effort.

Posted by: fred at July 12, 2007 08:35 PM

REAL WORLD SOA PODCAST

Listen to the latest podcast:

MP3 •

•

• Archive •

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert