Looking for a way to solve the following problem....

Have about 40 services/products across the company. All of these services can be deployed individually or together. Unfortunately, they duplicate data. Would like to get rid of the duplication. Would it be possible to define something like an xsd per sets of tables(possibly a ddl???)? and then each product uses the ddl like a libary.

At deployment, the service A could then create tables A, B, and C and then service B is deployed, it would see table B is already there and add table D which it needs data from.

On top of this, I would be deploying admin pages that are paired with those tables, as I am not sure we would want two ways to change the same data(ie. one page through service A and one through service B).

Is there a clean way of doing something like the above? Can hibernate or some other O/R product take a ddl and some config file and spit out Java objects. Then I need something for the products in C/C++ also.

I would think this would be a very prevalent problem at large companies, and am confused as to why it would not have been solved already. Otherwise, you end up duplicating lots of data.

Take alook at this article. It's targeted at .NET, but it has a good section about XSD's.
http://www.developer.com/net/net/article.php/3388311

thanks for the reply. Actually, I am already very very knowledgable in xsd's. I have been working with them for quite while. I am however not too familiar with ddl's. Either way, I am still not how to solve my problem even having that knowledge of xsd's.

I am very scared of having every product access the data through xml, though it would solve the need for a contract, I am worried
1. how transactions would work
2. performance problems of putting an xml layer between the data and the services

I would much prefer to have the contract at the database level and services/products go through a connection pool which is shared when the services are in the same language and deployed on the same platform.
thanks for any other insight you have here,
thanks,
dean

The issue of database management, and in particular solving the data duplication problem, should be addressed by a competent database analyst/designer. Whether the database will then be accessed via layers of XML, Java objects, C++ objects or a VT-100 monitor and the command line is irrelevant to this issue.

For example, if your enterprise needs a table A then that table should be defined and managed once only. When deploying Service B, it is not a case of having to dynamically check whether table A exists, and creating it if not. Service B should be designed on the basis that there is a table A for it to use.

Things might be a bit different if you were selling systems to many customers: all customers need the core tables, but tables X, Y and Z are only required if the customer has purchased option C. This is simple configuration management, and again is unconcerned with XML, Java etc.

Apologies if I have missed the point, which is entirely possible!