The Symbian OS (779886), страница 76
Текст из файла (страница 76)
At the same time it provides a native,object-oriented persistence framework that, for example, enables applications to externalize and internalize state without explicitly invokingfile system APIs. It also provides a native database storage model, whichis extensively used by applications such as Agenda and Contacts. GeertBollen was the original architect of the persistent-storage frameworks.Geert Bollen:At my previous company I had implemented a persistent object database overRDBMS in C++.
Actually, I had done that several times. So I was brought inas a C++ and design expert, and I was given the persistent-storage job. I had ateam of two, me and Andrew Thoelke.Andrew Thoelke:It was only 18 months after I started and EPOC 32 was really kicking off ina big way. So I started working with Geert Bollen shortly after they had themajor discussion about ‘Is it going to be a database? Is it going to be a filesystem? Is it going to be some object soup? Are we going to buy it in? Are wegoing to write it ourselves?’To start with they designed and implemented a DBMS API based onthe DBMS API in the 16-bit system (which had originally been written byColly Myers).Geert Bollen:The design and implementation is that of a classic, by-the-book RDBMS light,because it was always designed, for example, not to have joins.
It was light.The design layered a stream serialization interface over a dictionarystyle persistent store over a (conventional FAT-style) file system.Andrew Thoelke:Initially they were going to say, ‘Right, well pretty much every file’s going toA THOROUGHLY OBJECT-ORIENTED OPERATING SYSTEM361be a database’ and that was refined a bit later on, so it turned out that everyfile should be a database but they were going to go with a file system, and youhad different sorts of databases for different sorts of files. And then the ideas gotrefined somewhat to having two separate layers, having a store architecture,and the notion of Streams and Stores which is slightly more basic than a fulldatabase, and then you have the database sitting on top of that for applicationsthat explicitly want that kind of data storage.Geert Bollen:DBMS was always intended to be the heart of application storage. The PsionSeries 5, recall, was to ship with a suite of built-in applications, includingAgenda, which was a diary, meetings, and to-do list application, as well asoffice style apps.
DBMS was intended to provide storage for them all.For more conventionally file-based applications, such as the spreadsheet and the word processor in the original Psion Series 5 applicationsuite, a more document-centric Store interface was available.Later, the decision was taken to design a less abstract storage frameworkwith object serialization at the heart of it. DBMS is a natural storagemodel for a database application, such as Data, but, for document-basedapplications, the requirement was somewhat different.Geert Bollen:We needed a Store for document-based applications which load up theirapplication data when they launch and write it out when they suspend.The question was then how this fit with the needs of the moretransaction-based applications (such as the Data application, which explicitly used a database format, or the Agenda application, which implicitly used a database format); in other words, applications which didn’tload their data into working memory, but had a store on permanentstorage and conducted transactions against the store.Geert Bollen:The requirement was to build a framework which combined the needs ofdatabase operations with the simplicity of object serialization.
That led toa transaction-based API for Store and we provided that as a fat API-styleframework.It is a ‘fat API’ because its single interface had to encompass themultiple interfaces it needed to support the multiple different kinds of362THE USE OF OBJECT-ORIENTED DESIGN IN SYMBIAN OSobjects. In other words, Store exposed a single, ‘maximal’ interface whichwas only partially implemented by any one of the concrete objects whichimplemented the Store interface and which were available at run time. Inother words, the concrete objects which were available at run time eachimplemented a subset of the complete interface. The ‘fat API’ approachwas adopted as an alternative to multiple inheritance, against whichthere was a strict injunction.
Since at that time the ‘mixin’ solutionhad not yet been adopted, there was no other way to expose multipleinterfaces.Just as the database layers over the generic Stream–Store architecture,so it in turn layers over the more or less conventional filing system.The goal of the Stream–Store design was to define a generic persistentstorage mechanism suitable for any application type and robust enoughto guarantee bullet-proof data safety in a model in which ‘the user neversaves’. Data safety was required no matter what the user might do or failto do, including pulling out a removable media card while an applicationwas using the data stored on it or even pulling out the batteries whileapplications were active.Peter Jackson:The end-user requirement is that you don’t want corrupt data still around, youwant a transaction-oriented filing system at some level so that if somethinggoes wrong in the middle of what you’re doing you don’t have to do someexpensive repair process.
You might have lost a couple of transactions becausethat’s when it went wrong, but the transactions that have already happened aresafe. And the whole Stream–Store technology gives you that kind of layer. Andfor that reason I would say it’s a lot better than just having a raw I/O system.Andrew Thoelke:I think for Streams, in particular, the actual class design went through somethinglike four or five iterations, because we were trying to deal with the many waysyou might want to use Streams and chain them together and run them backto back without resulting in a system that passes one byte around betweendifferent classes, which gives you performance problems.Store is a complex design problem because what’s required is reallynot a single solution at all, but multiple orthogonal solutions, serving the fundamentally different needs of different applications workingwith data in essentially different ways, that is, document-based versustransaction-based.Andrew Thoelke:DBMS is just a template API for a database, whereas Store is an extensibleA THOROUGHLY OBJECT-ORIENTED OPERATING SYSTEM363Steams and Store architecture where you can have different types of back endto it.No design allows an application to continue writing to or reading from a media card that the user has removed from the device.However, different design choices provide different levels of protection against such unexpected failures.
A conventional file system isthe least robust solution. From a developer perspective, on the otherhand, file-based semantics are so widespread and so engrained as toseem like second nature. In contrast, object-based serialization usingexternalize–internalize and store–restore semantics imposes a new learning curve at what should be a very basic level of programming,saving and restoring data. Inevitably too, if developers don’t understand a model, they use it wrongly (or, indeed, even deliberatelysubvert it). In some respects then, the persistence architecture is anotherexample of a Symbian OS idiom which has been described as abarrier to new developers, but which is firmly rooted in the original design requirements for the system (unrivalled robustness for adevice class which is quite different from the conventional desktopdevice).Object Orientation in the KernelThe Application Architecture framework, the Control Environment hierarchy (CONE), the Graphics Device Interface framework and Store allmake aggressive use of object-oriented and C++ techniques includinginterface inheritance, polymorphism, templates (in the Symbian OS ‘thintemplate’ style) and so on.At first sight, most of these techniques are absent in the design andimplementation of the kernel (whether the EKA1 or EKA2 architecture).Andrew Thoelke:If you look at the features of C++ that get used in the kernel, you don’t seevery much in the way of templates and you don’t see very much in the wayof derivation and you don’t see very much in the way of virtual functions andoverrides and frameworks, so it’s a simpler use of object-oriented design.
Butit’s still object-oriented design.In fact, the kernel design has some interesting object-oriented featuresand they are sufficiently fundamental to persist in the design of EKA2.364THE USE OF OBJECT-ORIENTED DESIGN IN SYMBIAN OSGeert Bollen:There is something interesting. There is a key insight of Colly Myers’s whichis very interesting, and it’s an interesting use of OO concepts. A lot of whatan OS does is very close to the metal, which is not an area that lends itselfto standard OO-programming mechanisms. But Colly’s key insight was that atone level the kernel is a model of an executing system. That’s what the kernel’sjob is, parceling out the hardware resources of the underlying machine, and ofcourse managing the computation, which is what the central processor is thereto do.
So what else really is the kernel? The kernel is really just a dynamicmodel of the computation which is in progress, of the thread of execution andthe processes which exist and the way they are locked and communicating.You can make an OO model of that. You can implement that model usinga bunch of objects. And essentially that’s what Colly did. That was a veryinteresting use of OO concepts to design a kernel.The basic kernel objects derive from this approach.Andrew Thoelke:Any kernel is going to have a control block for a process, but rather than justsaying it’s a control block, in Symbian OS it’s actually an object with responsibilities to manage that process and the things that belong to that process.So it’s not just a data structure that says, ‘This is the process control blockassociated with this dynamic collection of threads and memory space.’ It’s anobject and it has the responsibilities for that management within the kernel.The kernel takes a different approach to the use of object orientationthan is taken in the UI or Application Services layers, for example.Nonetheless the ‘object-oriented clouds’ are there.Andrew Thoelke:In the kernel in some sense you can say there are clouds, because you’ve gotencapsulation, and you’ve got objects.
Perhaps it depends on whether you say,‘Well, if you don’t really use advanced inheritance and virtual functions thenyou aren’t really using OO’, right? So OO is derivation, using virtual functions,polymorphism and whatever, but a key part of it is about encapsulation androles and responsibilities and the way the different objects in your systeminteract with each other using defined methods or messages, rather than byjust invasively tinkering with each other’s data structures. That’s OO too. Youcan see that in the kernel.A THOROUGHLY OBJECT-ORIENTED OPERATING SYSTEM365Object orientation is not just a way of making a design tidier.
It enforcesdiscipline, not just on the design of a piece of software, but also on theway that users must go about designing their own use of the software.Andrew Thoelke:From the point of view of modeling a system and having clearly definedcomponents which interact in well-defined ways, the kernel is really quiteobject-oriented. Whether EKA2 is as rigorously so, it probably is at the samelevel although for the sake of performance occasionally we don’t always tryand protect data.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
