AVERTISSEMENT

En cas de doute ou de surprise, se reporter au texte français, qui a lui été revu de près!

Bertrand Meyer: How did you get into the field of Object Oriented data bases and what has your personal itinerary been?

Jacob Stein: I began working with David Maier on object extentions to a relational model at Stony Brook. I spent 8 years at Servio where ai got involved with the Object Database Management group. I spent a year and a half on my own afterwards and have been at Sybase for the last year and a half. Currently I'm Vice Chair of the Object Database Management group, I'm still involved with O.M.G. and I'm Strategic Planning Manager with responsibilities lying in the area of object technology at Sybase.

Bertrand Meyer: Do you think this itinerary is representative of the evolution in this field going from something that is fairly specialized and had the pure object label attached to it to something which is becoming more main stream........

Jacob Stein:I think that the fact that Sybase employed me is indicative of the fact that technology is moving more main stream. Whether it gets co-opted or compromised on the way, well the results aren't in yet we'll have to see.

Bertrand Meyer: Do you think that's a good evolution or a little bitter after the whole power of the ideas eventually made it?

Jacob Stein: Ultimately I don't think that it matters how the technology makes its way to the market place. It would be nice if the individuals in the companies that pioneered the technology were the ones that succeeded with it but that's not always the way it is.

Bertrand Meyer: What your appraisal of the actual success of Object Database ideas?

Jacob Stein: I think that the Object Database vendors as a whole haven't quite fulfilled the expectations that they had of themselves or the industry had of them. I think the vendors will still be successful but they'll be successful in specialized markets: Technical design markets, perhaps as middleware in future architectures, perhaps as data marks in data wherehousing architecture so that data's transformed from the operational system into an object data base to be used by applications built in object languages. But the notion that we held, I guess whenever a new industry starts you always have grand visions, that object data base vendors themselves represent the next generation of mainstream vendors in the sense of oracle Sybase in the performance doesn't seem to be happening.

Bertrand Meyer: And why is that?

Jacob Stein: I think for one thing, this time around, things are different than when the relational federation took on code. So I think that the large relational vendors were very well intrenched and the requirements, scaleability availability and reliability were in order of magnitude higher than when the relational products came into the market and that's a very hard wall to climb.

Bertrand Meyer: So is it partly a matter of the technology being introduced too early .........

Jacob Stein: I often wonder about that myself. About whether technology was indeed introduced too early in the sense that the products didn't at the time have all the availability, the reliability, scaleability, robustis requirements required in the commercial market. But there are also a few deeper questions relating to whether an architechture that tends to work best with a specific programing language and not well with all languages could ever have hoped to have dominated the market. Most of the products tend to be focused either on C++ or Small Talk and unfortunately the commercial market requires the you be able to access the data from a dozen programming languages and that's a more difficult thing to do.

Bertrand Meyer: And also another approach for someone...going even further into this direction that you critisized mainly taking a programming language and almost hiding the systems completely .......

Jacob Stein: I think persistant programming languages object data bases focus on a particular language have their place and certainly if the organizations commited primarily to a single language then a single language approach works well because of the degree of transparency you can see that otherwise impossible. The trouble arises when an organization grows and it has multiple applications to support compromised on the way, well the results aren't in yet we'll have to see.

Bertrand Meyer: Do you think that's a good evolution or a little bitter after the whole power of the ideas eventually made it?

Jacob Stein: Ultimately I don't think that it matters how the technology makes its way to the market place. It would be nice if the individuals in the companies that pioneered the technology were the ones that succeeded with it but that's not always the way it is.

Bertrand Meyer: What your appraisal of the actual success of Object Database ideas ......

Jacob Stein: I think that the Object Database vendors as a whole haven't quite fulfilled the expectations that they had of themselves or the industry had of them. I think the vendors will still be successful but they'll be successful in specialized markets: Technical design markets, perhaps as middleware in future architectures, perhaps as data marks in data wherehousing architecture so that data's transformed from the operational system into an object data base to be used by applications built in object languages. But the notion that we held, I guess whenever a new industry starts you always have grand visions, that object data base vendors themselves represent the next generation of mainstream vendors in the sense of oracle Sybase in the performance doesn't seem to be happening.

Bertrand Meyer: And why is that?

Jacob Stein: I think for one thing, this time around, things are different than when the relational federation took on code. So I think that the large relational vendors were very well intrenched and the requirements, scaleability availability and reliability were in order of magnitude higher than when the relational products came into the market and that's a very hard wall to climb.

Bertrand Meyer: So is it partly a matter of the technology being introduced too early .........

Jacob Stein: I often wonder about that myself. About whether technology was indeed introduced too early in the sense that the products didn't at the time have all the availability, the reliability, scaleability, robustis requirements required in the commercial market. But there are also a few deeper questions relating to whether an architechture that tends to work best with a specific programing language and not well with all languages could ever have hoped to have dominated the market. Most of the products tend to be focused either on C++ or Small Talk and unfortunately the commercial market requires that you be able to access the data from a dozen programming languages and that's a more difficult thing to do.

Bertrand Meyer: And also another approach going even further into this direction that you critisized mainly taking a programming language and almost hiding the systems completely ......

Jacob Stein: I think persistant programming languages object data bases focus on a particular language have their place and certainly if the organizations committed primarily to a single language than a single language approach works well because the degree of transparency as you can see is otherwise impossible. The trouble arises when an organization grows and it has multiple applications to support with a data base. When new languages are introduced that also have to be supported than it's difficult to provide that same level of transparency in multiple languages. So for small organizations or for applications that are in a sense stand alone that dont require a high degree of interaction with other applications to the rest of the environment language specific solutions probably are unbeatable in terms of the ability to quickly import and display applications and maintain them and there's a market there but I don't know if its what if it supports the 500.

Bertrand Meyer: So what is the market ........but we are reaching the end of that and we are going to conquer the industry at large ..... what is the market today and what will it be in a few years?

Jacob Stein: Part of the market I think is still taking a place for proprietary file systems. You look at Menta Graphics 10 years ago and they were able to be the market leader in their market running on one platform. Apollo. And today there's no hope of bringing out a cat cam product that runs on just one platform and when they run on one platform they can fill the database for that platform that's essentially a proprietary file sytem extension and then they discovered all of the sudden they were in the data base business cause they had to port this proprietary data base management system of course multiple operating systems and in a sense that began the intial opportunities for the object data base vendors. And to a certain degree that still is an opportunity because their are applications with very complex data where the data doesn't easily accomodate ... relationtional platform. Those are great candidates for using an object data base. Those sorts of applications wont go away because for all the scaleability and robustness that the large relational products bring to the market they cant satisfy every need. I think applications of those natures will always exist but I think there's room for the object data base vendors to grow but it will be likely within the domains of the larger relational vendors and playing roles within those environments but the object data base itself is not likely to become the central enterprise operational system but in terms of data marts and running specific applications on such as: Servio is running wafer fabrications with the TI . There's still room for these object vendors to grow to be profitable companies. The question is, will there be a few hundred million object data bases, I think there will be fifty one hundred million dollar companies. Will there be a half a billion dollar object data base vendors, a billion dollar object data base vendors, thats going to be much harder to achieve.

(Tape recorder went of)

Jacob Stein: ... using object data bases. There's a difference between having a half dozen referenceable mission to criticle applictions and being excepted within MIS. The tension in MIS is always one of "I need to be on the cutting edge and deliver a high degree of functionality and yet I still have to be conservative and make sure I deal with vendors that I know will be around in 5 or 10 years. Standards is the big issue.

Bertrand Meyer: ...

Jacob Stein: Sybase is company that believes there's certainly room within the data management world for object data base, they clearly play a role. I think that most of the relational vendors though are focused on extending their existing product lines rather than inventing entirely new data bases. In a sense our task is to deliver improved functionality to the existing customer base and to ask them to learn an entirely new data management paragon would make that task difficult. So I think the relational vendors by and large are going to focused on people who are ready to incorporate what are commonly referred to as abstract data types into their servers. The ability to introduce new indexing mechanisms into the server. Better intergration from their servers with object tools on the client side. I still believe and always have that the best way to get for organizations to get familiar with object technology is on the client side and the application side initially and not initially on the data base management side.

Bertrand Meyer: Why?

Jacob Stein: There's a certain amount of less risk. If a couple of applications don't work out than they don't work out and that's O.K. If you commit big time to an object data base and put a tremendous amount of corporations data in there and it doesn't work out, extricating yourself's harder. I think that in terms of value for effort intially you get more value by focusing objects on the client and applications development. It's on the application side where the fast development's required. It's all the less time to market issues. The data base has to support the applications and get them to market quickly but those focus in the world is really on applications. People buy applications, people don't buy data bases. It's time to move forward. Look at the Success of SAP down on Brad St. If organizations by and large want to buy solutions they're not looking to buy technology anymore.

Bertrand Meyer: So you're seeing in architecture where your have a kind of central data base depository which can be relational and a very high speed, fast access communicator with structurally just world data and in specialized applications where the intelligence ...

Jacob Stein: The operational systems of an organization have to be generalized and generalizeable cause they have to serve a tremendous number of needs. One of the trends you see in data management is the move towards the use of replication both in wherehousing and in nomadic computing. And so one of the options is that you have a generalized installational store, operational store, and then you have specialized stores adding departments and the visions and thats certainly an appropriate role for object data bases. So particular of you've committed to an object programming language within a particular task, lets say in manufacturing, your operational data base might still be relational but the soft form might be running it off of a replicate where you've done transformations as well as data movement into the object data base so the formats were easily accessible from those object programming languages. So that's a reasonable use. But I don't think the object data bases by and large are ever designed to do high transaction proccess rate. High alt to key environments.

Bertrand Meyer: ...

Jacob Stein: I don't think any of the object data base vendors targeted all line transaction proccessing. Primarily when you look at some of the applications they target as a design transactions, they're not all of the environments. They tend to be long transactions accessing large volumes of design data. All of the key environments tend to be very short transactions that are updating very small pieces of data. Given they didn't target that and that's still the primary use of operational data bases, the transactional data, then it's not resonable to expect them ... to capture that part of the market. But we are in a world where people are doing more replication and more data marts which are many wherehouses that are specialized for particular applications of departments. In that area I think they still have a lot of potential. Because a lot of data wherehousing is about data movement and data transformation. And the movement could just as easily be from relational data base and transformed into the formats of an object data base.

Bertrand Meyer:...

Jacob Stein: The issue with all the replication base strategies is that there's always gonna be a delta of time during which the copy is not quite up to date with the operational data base. But there's a large,large number of ... support applications where that's totally appropriate. If you were analysing markets and defining strategy, generally speaking, the data that's directly yesterday is adequate. You don't need data that's correct up to the moment.

Bertrand Meyer: Once in a while you still need to reconcile.

Jacob Stein: But you need to reconcile usually on a nightly or weekly basis. Usually your generally not performing updates on the copies so really it's a refresh more than a reconcilation or you attempt to make it a refresh rather than a reconciliation.

Bertrand Meyer: There seems to be some contraction between the traditional notion of database and O-O ideas. Object technology is based on the principle of data abstraction: this table doesn't exist other than what I use it for so if I'm a carpenter the table is something I make; if I am a restaurant waiter the table is something I put dishes on; and so on. But the table by itself doesn't really exist. Now this is completely different from the view of data base people for whom the data is there, independently of the programs that may use it, and it's my responsibility to get at it.

Jacob Stein: We've always partitioned the walls into proccess oriented aspects and into state oriented aspects. That's why we're able to get data bases verses application development environments. There were certainly some very good reasons for doing that when we did it. When we look at the data base side of the equation we're concerned about preservation that stayed over long periods of time. Accessing data, we developed core languages that had a subset of the functionality of programming languages because we thought that we could optomize those more effectively than full programming languages against tremendous volumes of data. This created problems as well as benefits. Some of the benefits is that the data base person is a very data-centric and the one of the good things about that is that they tend to focus on data integrity and preservation of data ... process oriented puts a little bit less of a focus on "I corupt the data it's totally useless forever" and in the data base arena we, in a sense, did keep data in a deep freeze because we didn't trust the application developers to just have random access to it. Things like data wherehousing and replication though make it possible to give the application developers a freer hand. Because if your working in a duplicate of the data then I know you can't corupt my core repository than I don't have an issue. So now we have the ability to start the flow of the lines between data and proccess. I think that some of the interfaces that the object data base vendors have for the system programming languages with object programming languages provided a greater degree of transparency than you find in any of the data manipulation languages from traditional vendors. The ability to do automatic dereferencing thats objects out of the backing store. They bring us a step closer to the persistant programming languages although you can never ultimately forget that there's a disk drive I mean the same way that you can never that there's memory.

Bertrand Meyer: ...

Jacob Stein: The application developer should be less aware that he's working with data from disk and that task should be, that distinction should only be clear to the people doing administration of the data. Which is a vision that, to a certain degree, the object vendors helped realize. Although it's still imperfect and there's still questions about how you clurry objects. When you doing non navigational actions and you not just following one reference to another reference and you need to find a bunch of data base upon some logical criteria. Most programming environments don't have the concepts that are strong enough to support that effectively. You clearly don't want to do that with brute force looping.

Bertrand Meyer: Are you satisfied with your ODMG standard?

Jacob Stein: ... In standards the primary contribution is in support of relationships and the core language. At Sybase we're working fairly closely with ODMG to help influence of the SQL3 effort. I think that the ODMG clurry language partly because they don't have the demands of backwards compatibility has more elegance than the current draft at SQL3. So we've been working actively with the ODMG trying to have them submit papers the Ansy committy.

Bertrand Meyer: ...

Jacob Stein: Servio, Object design, I think there are 5 or 6 members.

Bertrand Meyer: And there's none of the relational vendors?.

Jacob Stein: Sybase belongs as a reviewer member. We need to be shipping an object data base product supporting either C++ or Small Talk in order to be a full member. So none of relational members are full members and I think we're the only reviewer member.

Bertrand Meyer: And what about the SQL3 ... are all the data base members represented there?

Jacob Stein: The've attended some joint meetings and tend to follow the activity within the Ancy. It's a bit difficult for them to be full time participants. The've increased their level of activity. I think they're going to be submitting several papers to the Ancy group with the focus to modify SQL3.

Bertrand Meyer: ...

Jacob Stein: I don't know whether we'll see mergers or not. I think it's likely that in any competitive developing market not all the participants will grow as quickly and ultimately not all of them will be equals in 5 years. There's likely not sufficient space in the market for a half dozen vendors of equal size. So I think the likleyhood is that 2 or 3 of them will grow fast enough to survive as independent vendors the other 2 or 3 their technology, their companies will be aquired. I don't see mergers as very likely though.

Bertrand Meyer: ...

Jacob Stein: Frankly I don't have a very strong opinion about UNISQL partly because it's so difficult to find out any information. So to me it's just a big fuzzy cloud and we'll see how they do.

Bertrand Meyer: ... trying to bridge the gap.

Jacob Stein: There are a couple of vendors out there that have extended relational technology and the challenge for them is to add into these systems all of what the main stream vendors already have until the scaleability transaction proccessing tools and the like. That's a big challenge. What`s funny is when I work for a 5 million dollar a year company I was amazed we would get compared to billion dollar a year companies and now that I work for a billion dollar a year company I find it equally interesting to be asked to compare ourselves to a 5 million dollar a year company. They have interesting technology. They have a long road. Time will tell. If I knew the answer to who succeeds and who doesn't I would probably be a venture capitalist and not a technologist. I think it's also true now that extended relational in and of itself isn't adequate. I think you need to combine extended data bases with a good services infrastructure. Not everything's an abstract data type somethings are a service. If you take a look at someone who already has a text management system, lets say, now intergrate that in with an extended relational environment. That takes every operator, every index, every access message and register them independently or register each one of those in my extended relational environment. I'll bet you that text management system wasn't designed to allow arbitrary access to its primitive operators. As such you couldn't intergrate that text management system into one of these extended relational products. I'd argue that a text management system is a service not just a collection of agencies. And as such you need an infrastructure more atuned to an ORV or OA to intergrate those services and you need a crurry proccessing environment that cannot just handle new indexes and new types but can also handle crurries that can stand multiple data base services such as a text service. ... you start up some relational domain by working on half the problem. There's a lot to watch out for moving forward that it's all a lot of work ahead of them before they're gonna be able to be main stream players.

Bertrand Meyer: So who's working on the other half of the problem?

Jacob Stein: Right now I think we have a typical situation where people who have an operating system perspective are thinking about only services. People with a data base perspective are only thinking about extended data base products. There appears to be a few pioneers that realize that you need to have both and they need to work in an intergrated fashion. So you can't have a serperate service infrastructure that isn't intergrated to your data base infrastructure and you can't have a data base infrastructure that isn't intergrated to your service infrastructure. I think people will start to realize that over the next couple of years and you'll see better intergration.

Bertrand Meyer: Does it mean that what's usually known as the major players don't participate very much? Another suprising aspect of the situation is that hear very much when you talk about the data bases you don't hear very much about IBM and the like. ...

Jacob Stein: The relational vendors that had moved more slowly that tends to be what happened to the established vendors now. Moving more slowly does not mean you move to late.

Bertrand Meyer: Atleast they have made some noises. I was also thinking of the whole computer industry.

Jacob Stein: IBM has made a lot of noise relatively speaking. Their commitment to Small Talk, The dock in Som. It's been taking a while for them to intergrate all the pieces together there's no arguing about that.

Bertrand Meyer: ...

Jacob Stein: That can't be the case when you have to wait two years for you relational vendor to intergrate in a new index type. So if I have spacial data the data base vendors as a group need to be able to,more easily, incorporate access methods to spacial datas in their products. So one of the things that they're doing is using object technology in a sense within these products by creating abstractions within their infrastructure for indexing mechanisms and for types and for operators. That way you can introduce new types and use new index mechanisms for optimize queries that involves the new types of indexing mechanisms. And in some sense you view that as using object technology within the product line although it might be overtly visible for the outside world. That's clearly a step in the right direction. Also I think we're going to see a lot of changes in the area of core languages so that they're more flexable also. I think the world will soon realize that they need to intergrate data base services in with the other services. If you look at the OS vendors they do tend to have a very application oriented ... In the same way like at Sybase ... architecture took off these C protocols which weren't appropriate for data streaming, there were no data streaming facilities in most docu C mechanisms. We added data streaming to our PC so in a sense had a data oriented version of our PC that's worked very well for us.

Jacob Stein: There's still a lot of promise and a lot to be delivered.

Bertrand Meyer: ...

Jacob Stein: The LMG basically reflects the attitudes of the Unix vendors. They don't seem to realize that they're in a fight for their survival. So you have an inneroperability spec that is still so vague that your core for architechture would only work if I could develop services for the ... infrastructure and farily easily brought them to multiple core implamintations.

Bertrand Meyer: ...

Jacob Stein: Now if it's a case that I have to do a lot of very hard custom porting work to move from one ORB to another with this service than you greatly diminish the desirability of anyone entering the service business for ORBs.

• S'abonner à L'OBJET
• Retour à la table du numéro 1.3

© 1985-2011 Eiffel Software. All rights reserved. -- Privacy Policy