Thoughts on Structured/Unstructured and Shared Information Management using Wiki and other emerging technologies
Tuesday, April 15, 2003

Synchronizing code ... with data models

A typical server side, enterprise application taps data from databases and other stores, transforms it, and makes it available to different access mechanisms such as web.

Typical synchronization mechanisms watch changing data at one datastore, and replicate them at another (possibly mobile, disconnected, replicated ...) datastore. 'Watching' either means polling the data to identify changes (less common), or inserting triggers into Databases, or accessing changelogs of LDAP directories.

But consider another case: How often you have to change the application code because the data model, or the schema changed? Are there regular patterns?

Some of such patterns are already observable. For example, if you choose LDAP as your datastore, you are shielding the data model from the applications to some extent. Adding a new attribute in LDAP will not require that you change your code. If you used good coding practices, the attributes could be made available to both business logic and presentation interfaces without having to change any piece of code.

However, business logic heavily depends on data models. And typically, the very purpose of adding new attribute would be to introduce new business logic. The term 'synchonization' in this context would mean that the business logic is expressed in adata transformation language model - for example XSLT. And it should be possible for us to create a synchronization model that connects Data model in backend stores, business logic in XSLT specifications, and Presentation layer components such as menus, lists etc.

One thing to note: In any synchronization, the changes happen independently at one point, and get replicated elsewhere. In this model, the changes would be driven by any layer. For example, I might use a website design tool to add a new attribute (say, "size") to an item being shopped, and expect it to appear in (say) LDAP schema automatically. Once introduced this way, this schema element might become available to other team members for use in other screens.

Does this model make sense? If it does, it would make it very easy to write applications.

About this blog
All realms of collaboration:
  • Wiki. Weblogs
  • New Integration Platforms for combined structured and unstructured information: Wiki, Portals, Email Clients,
  • Collaborative Document editing, Collaborative knowledge building
  • Email Interfaces to collaborative shares
  • Information organization, management, Publishing: In context of organizations, individuals, Opensource projects etc.
About me:
Name:Vinod Kulkarni

Subscribe to Bloglines


January 2003
February 2003
March 2003
April 2003
May 2003
June 2003
July 2003
September 2003
November 2003
December 2003
January 2004
February 2004
March 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
May 2005
June 2005
November 2005
December 2005
May 2006
June 2006
October 2006

Powered by Blogger