November 15, 2006
Objects and Databases: State of the Union 2006William Cook, Moderator: I almost wondered whether there isn't a service-oriented impedance mismatch starting to arise. That's somehow related to the data one but the services are over there and how do we talk to them?
Patrick Linskey, BEA: How do we pretend that they're all somewhere nearby?
Erik Meijer, Microsoft: So one thing is -- remember that candle there -- I think the service orientation is one place where people have fallen into the trap of having this kind of unified data model that they think XML will solve everything, but I am personally not such a big believer in XML, hardly anybody needs comments, PIs, significant, insignificant write space, name space, all the crap that XML gives you. I think a lot of people just want to have their own data model so again that's why please for many having a solution that works for any data model -- don't fix yourself.
The other thing is that you want your data to be read only, you don't want that, people probably cannot modify or update data, the data will be distributed etc. So I think this all points to Monads again, to bring that up again. It works for any form of data and it focusses on "What are the common operations on the data?". Such that and then you can distribute these operations to the data or you can bring the data to the operations. But it becomes just a matter of optimization but you have kind of unified, really parametrized for all data models instead of picking XML or whatever will be the next big hype.
Derek Henninger, Progress Software: One of the things that we see at Progress is a lot of the companies that are using Service-Oriented Architectures, the loosely coupled, message based, are often using it to integrate two different databases. XML becomes that common model for a specific application, the other where I guess we'll see that is where you need to communicate across different companies within an industry.
Telecommunications is a great example of that: Your call gets transferred to a bunch of different providers, they need to communicate and they have common models that they are trying to define as an industry. It's a pain, it may not be successful but it is a way that they are interoperating. Basically every major industry is coming up with their own standard and I think that the solutions need to integrate into that.
One of the challenges that you look at service oriented architectures and in particular as you build business processes, kind of the silver bullet, where everybody points to is going to have all these services that everyone has built and then you can build this wonderful business process on top of it. One of the challenges that happen, is you work through from the first step to the second step to the third step is the data kind of builds up. We call it the "Snowplow", so as you go through each stage of the process in order to ensure that this next process and the next service gets the information it needs to proceed properly, you're accumulating all through that. And one of the things we've been talking about at Progress is whether there is an equivalent at the service layer, is there an equivalent sort of data channel on the service where you're keeping the individual processes up to date with the latest data so they can process the latest requests as opposed to having everything just built up and your XML file gets bigger and bigger and as the process gets more complicated the XML file continues to grow.
Christof Wittig, db4objects: I think it's a question that's very related to object database. If you look at a company like salesforce.com, to the outside it only has service APIs and many companies have shown it very well integrates into their business processes, and you don't ever access the database on a raw level. So I think people underestimate the change in the way of how ownership is redistributed through service oriented architecture. It actually gives you the chance to slice away applications and outsource them. As a result the application developer gets back into charge of how the data is stored, how it's most efficient and most performant, rather than having the DBA with his data store that sits on top of all the applications in my enterprise, you have a silo. And the application developer now is in charge of how to persist data in the most convenient way, which caters to the needs of Service-Oriented APIs and gateways. So that changes a lot and that opens the door for using object databases in an embedded way if you like. Because the end user is not aware... do you know whether salesforce.com is running an object database or an oracle database? And why would you care?
Erik Meijer, Microsoft: So did something in your youth happen, some dramatic experience with a DBA or something? [Laughter] 
Previous Page |
1 Introduction
|
2 Bob Walker, Gemstone Systems
|
3 Derek Henninger, Progress Software
|
4 Robert Greene, Versant
|
5 Erik Meijer, Microsoft
|
6 Christof Wittig, db4objects
|
7 Patrick Linskey, BEA
|
8 Craig Russell, Sun Microsystems
|
9 Ten Years from Now?
|
10 Data -- It's Scary
|
11 Acronym Soup
|
12 Business and Social Issues
|
13 Back to the Social Question
|
14 Different Viewpoints
|
15 A Bigger Picture Question?
|
16 A Service-Oriented Impedance Mismatch?
|
17 Wrap Up
Next Page
|
 |
|
|||||||||||||||||||||||||||||
|
|
|
