I was on a conference call the other day with a customer talking about their deployment of Ipedo. This customer has done some pretty cool, cutting-edge stuff, combining rules technology, virtualization, XML and SOA, all for a very large user population with a very large and growing data set.
What stuck me during the conversation was how they were building out their data services layer (Actually, they modified the term, calling it a 'knowledge services layer,' as it adds intelligence and the collective wisdom of the user base to the data, but it's all available as a service. Intriguing.)
Anyway, what was interesting was that they installed the data services layer to help build their application, but they are leaving the data services layer open for others to build upon later on. Since they know other groups will want to do different things with the data, they just standardized on the data integration layer and will let others go to town. So they get what they need for their app, and the company gets a 'data foundation' they can use later on.
In fact - and this is where XML stylesheets come in - they think that getting the data integration right was the bulk of the work. Many people will just want a different slice of the data, presented in a different way. So what they do is let them get the data slice in XML, then the developer just applies a stylesheet to it, and voila, new Web application. This is something I wrote about three years ago in an article called 'Send Me Your Stylesheet.' Nice to see it actually happening.
You'll notice that I used the term 'data services layer' in this entry rather than EII. Perhaps its more fashionable to talk about data services when people are using XML and SOA. EII seems more to do with relational databases accessed with an ODBC/JDBC View. Ipedo does ODBC/JDBC/SQL and SOAP/XQuery/XML, and combinations of the two, so we don't really care. It should just be interesting to see if EII and data services emerge to mean the same thing to people over time.
Comments