Freigeben über

SOA drives an odd data model

  • Artikel

Information Architects are an interesting crew.  Take everything you know and love about a person who "thinks" in data, add layers of set theory that you haven't looked at since college, throw in a pinch of realism, a flair for idealism, and an ability to generalize things that you didn't think could be generalized, and you get an Information Architect. 

But sometimes, that way of thinking can lead you astray. 

If we are to create an Enterprise SOA, with services that are both independent and composable, we will not succeed unless those services surround objects that make sense to the business.  Sometimes, when you generalize too freely, you create an object that cannot be understood by the business.  And while you can store the information, efficiently, you cannot manipulate it independently.

Take the concept of an invoice.  It has a header and lines and information about products.  Looks a lot like a purchase order. 

An average database engineer may tell you that you can create a table for the invoice header and put in a status flag or two.  Then you can store both invoices and purchase orders in the same structure.  Some information architects would agree.

SOA thinking says "no."  If you are going to build an independent service, then you have to seperate the logic between services, so that there are no side effects between them.  It is nearly impossible to insure that there are no side effects between services when they store their core data in the same data structures.  Especially when you consider the temptation to place logic into stored procedures.  While you don't have to create one set of stored procedures for one table, there is nothing in a normal database system to prevent it.  Complexity creeps in.

To seperate the logic, you have to have a good partition to seperate it on.  As any information architect can tell you, the number of different ways to represent something is close to infinite.  So you have to decide what things need to be stored, and represented, in seperate ways.

So when you are busy creating your data models, remember not to generalize too much.  If you are tempted to combine two entities, consider this: if different people create or manipulate those objects, or they have different lifecycles, resist the temptation.  Keeping things seperate on the basis of roles and processes is a good thing. 

It's a good way to keep your independent services... independent.

Comments

  • Anonymous
    September 07, 2007
    PingBack from http://msdnrss.thecoderblogs.com/2007/09/08/soa-drives-an-odd-data-model/

  • Anonymous
    September 07, 2007
    I agree. In short (generalized): data should be modeled within the boundaries of a service. This principle helps in determining the right level of granularity of the services. Also data persistency should be organized within the boundaries of a service. This may lead to redundant data as an architectural principle, which is right to maintain independency. Event driven architecture priciples are at the basis of keeping the redundant data in sync.  

  • Anonymous
    September 09, 2007
    Nick I have been wondering for while whether SOA should come up with different data models than traditional applications.  My thought was that the data structures may be driven by the message formats but that you might get to the same data model in the end.  Your example points out a problem with this theory.  Well done.

  • Anonymous
    September 11, 2007
    Nick, Thanks for this posting. This is a topic I feel has seen too few blog posts. Beeing one of the ordinary breathers this is a question that confuses a lot of us. I really would like to see concrete examples of a couple of service’s data models along with the services operations and if data redundancy exist within these models how data is kept synchronized? I think this would be very useful for “the masses” to get a concrete view of what a service model could look like.

  • Anonymous
    September 11, 2007
    Hi Robin, You know... you are right.  When my current crush is over, I'll pull out some items and make them available as examples.   I'll see if I can describe the principles that I work with to allow those examples to be reusable. --- Nick

  • Anonymous
    September 11, 2007
    Thanks Nick, really looking forward to this!

  • Anonymous
    September 12, 2007
    Please note that this blog is no longer on CodeBetter but at http://samgentile.com/blogs/samgentile/default