Object Serialization, Persistence, and Distribution: An Overview. Jeff Johnson Brigham Young University-Hawaii Campus

Transcription

1 Object Serialization, Persistence, and Distribution: An Overview Jeff Johnson Brigham Young University-Hawaii Campus

2 1 Introduction In the programming market place, there are ever changing winds, directing the future of software design and implementation. In the early eighties, there was the mass movement to GUI interface, currently these winds are driving the designers to the "New" field of Object-Oriented Programming. As with the GUI interface, Object-Oriented Programming offers wonderful benefits and new challenges to conquer. This paper will give an overview of two major problem areas in Object Programming; the areas of Persistence and Serialization. Object-Oriented programming centers around the use of objects. Objects come in many forms, including functions with a persistent state, and the more often used form, encapsulation of data and functions which act on that data. For this paper, the latter definition will be used. In most object-oriented programming languages, there is a data type, such as type class, which is used to create new object types. Individual objects are then instances of a given class type. Because of this, an object-oriented programming approach usually uses more user-defined data types than a non-objectoriented programming approach. Because object-oriented programming provides different capabilities, there is a different design process which is related to object-oriented programming. An example of this is designing an object-oriented database, verses designing a relation database. As Saake et al. explain, by using an object-oriented approach, the real world model which is created is much more accurate. Usually it is also easier to see the relationships between object in an object-oriented model, than in a non-object-oriented system [SAAKE1]. Computer Science is a relatively young discipline, so there are many terms which do not have concrete definitions, persistence, distribution and serialization are good examples of this problem. The definition for persistence which will be used in this paper is the ability of an object to exist beyond the life of the program. Of course this means that the object must be stored on some sort of long term storage device, or be transferred to a different program. In order to have persistency, there needs to be some way to change the objects from the form in which the exist in memory into a form that can be used to make the object persistent. Serialization will be the term I use to for the process of converting an object to a more mobile state. Distribution is the ability to share data between computers. Because this paper is concerned with objects, I will only be concerned with object distribution, and the issues that surround it.

3 2 Object Persistence In most many software products, there is a need to have data that persists. This is especially true in database application, it would be a serious short fall if the objects could not persist exiting the program. Because of the obvious need, many approaches to solving the problem have been offered. They include: Accessing the file system directly Using virtual machines and images Using third party object-oriented database systems Using third party relational database systems Using third party extended relational database systems [LOOMIS1] Each of these approaches offers different benefits and hindrances. A programmer must decide what a particular situation requires, and choose the appropriate approach. In the article "Making objects persistent", Mary Loomis gives the following table, showing the advantages and disadvantages of each of the persistency approaches [LOOMIS1]. File access Smalltalk Image ODBMS RDBMS Extended RDBMS Cost ok ok no no no C++ ok no ok ok ok Smalltalk ok ok ok ok ok COBOL ok no no ok ok C ok no ok ok ok Concurrently no no ok ok ok Large objects no no ok ok ok Seamlessness no no ok no no

4 Distributed database SQL compatibility Highly interrelated objects no no ok no future no no future ok ok no no ok no future The top row of this table consists of the five approaches to persistency discussed in Loomis paper. The first column is composed of eleven criteria which might influence the programmers decision. Theoretically of these criteria, the first should hold the least importance, because it has the least to do with needs of the program. Unfortunately this is often the item that most influences the decision. The next four criteria all deal with the host language. Since this paper deals more with the issues, and less with how to resolve the issues, I will be classifying them into one criteria, Host Language. Concurrent accesses to an object means that multiple users can use a single object. Obviously multiple people can t access or modify data at the same time, so the system must control those access, ensuring that the object is not corrupted, and that each user sees the changes made by other users. There are a variety of ways to accomplish this, which have discussed by others [NIERSTRASZ1]. From the table it is possible to see that the amount of memory objects take up could be a deciding factor in which approach a programmer will choose. If the size of the objects is larger than what can be held in main memory, then it is necessary to use some sort of database capabilities to give objects persistence. Some techniques for giving these capabilities to a program which access files directly have been discussed by many people, including Daniel L. McCue and Santosh K Shrivastava [MCCUE1], and John J. Shilling [SHILLING1]. Most of these approaches have some way to group objects in the storage area, and a new object which takes care of finding the correct object, and restoring it to memory. Some believe this should be done transparently [MCCUE1], while others believe that there should be a clear distinction between the way system which have this functionality behave, and systems without this ability [WALDO1]. Seamlessness is the amount transparency between using an object which exist only in storage, and using an object that is "alive" in memory. The need for a distributed database is a useful to give portability as well as distribution. SQL compatibility refers to the ability of the product to support the Standard Query Language. The need for performance with highly interrelated objects is evident when large numbers of objects and vast amount of message passing will exist in the system. As the table shows, each approach may or may not meet the needs of a particular situation. Some of these

5 approaches are coupled with different techniques for serialization. Serialization techniques will be covered at greater length later in this paper. 3 Object Distribution Since the advent of the computer, there has always been a desire to share information. Today we see the reality of these dreams in the World Wide Web. Because of the inherent properties of encapsulation and message passing, it would seem that objects are well suited to distribution. Unfortunately, the objects add many obstacles to distributed computing, not found in non-object oriented programs. Since object distribution requires object persistency, it also encompasses the issues that object persistency creates. Some additional issues created by distributing objects include: Portability in Multi-Architecture Network Systems Degree of Distribution Transparency Desired Latency Local verses Remote Memory Access Partial Failure Replication of Objects Migration of Objects [WALDO1] The problem of portability is a major issue. At the byte level, data can be saved in two ways: Big-endian and Little-endian. Big- endian is when the system saves the most significant byte of information first. Little-endian, on the other hand, is saving the least significant byte first. Since computers which need to share objects might be using different kinds of byte level saving, objects and programs using objects need to be designed in such a way as to make this transition invisible to users. To overcome the big-endian/little-endian problem, the programmer can choose which way he wishes to save the data, and then swaps bytes on those systems that require it. An example of this is shown using the Microsoft Foundation Classes in an article by Chane Cullens [CULLENS1]. Transparency has a double meaning; one that applies to the programmer, and one that applies to a user. Obviously programs should be written so that end users don t realize that objects might not be resident on their computer. Transparency for programmers is a much less cut and dry issue. Some people feel that it is best to have a product that will convert program code designed in a nondistributed fashion, to fully distributed code, with little or no help [PARRINGTON1]. Others feel that the programmer

6 should realize that the object will be distributed, and write the source code accordingly [WALDO1]. Happily both sides of this argument can see that there are benefits to the other viewpoint, and for the most part agree that some transparency is needed for the programmer, but a programmer should approach distributed object programs in a different way than non-distributed object programs. Latency involves the problems incurred by the time it takes to perform distributed computing. Since it is necessary to look up and retrieve and object before using it, there is extra time needed above the amount used by a non-distributed system. To show the importance of this issues, Walled et al. said, "Ignoring the difference in time it takes to make a remote object invocation... is to ignore one of the major design issues" [WALDO1]. To overcome this obstacle, they suggest determining which objects can be placed remotely, by using tools that allow the programmer to see that patterns of communication between object. Then the programmer must write the code so that those objects that communicate the most, will be closest together. Memory addressing is a problem area, because on a non-distributed machine it is possible to use programming techniques such as C pointers, which are not available at a distributed level. This is part of the transparency discussed earlier, the programmer must make it possible for an object to reference another object in a remote manner. Again there are different ways to do this. A natural way to do this is through the use of unique identifiers for each object. Then the object finder/retriever can use this identifier to find and retrieve the object, whether the referred object is located on the same machine, or a machine half-way across the world. Hardware failure appears whenever and wherever computing exists. A partial failure could be caused when part of the system is unreachable because of a hardware related problem, or it could be caused by concurrency mismanagement. These situations never occurs in localized computing, since there is only one computer, with one user, every transaction completely succeeds, or completely fail [WALDO1]. On a non-distributed system, the reason for failure can often be determined. This is not always true on distributed systems [WALDO1]. One way through which it is possible to overcome partial failure by using object replication techniques Object replication might help with partial failures, but it also adds problem of keeping data integrity through all copies of the object. One way to do this, that was suggested by McCue and Shrivastava, is to update all available copies, and take any unavailable copies out of the copy lookup list. This makes those copies with incorrect data disappear, without effecting the other copies [MCCUE1]. Object replication adds to the persistency problem of concurrency. To overcome concurrency in a distributed system, an object-locking technique can be used. In this technique, the objects are lock (set into read only mode) until all copies can be accessed and updated. This helps to ensure that data integrity exists in all copies. Object migration involves the idea that objects should be able to move, thus decreasing the amount of time it takes for those who use the object the most to access it. This can be accomplished with little difficulty by directly ensure that if an object moves, the object finder/retriever knows where it is, or by leave the equivalence of a forwarding

7 address for the object finder/retriever [MCCUE1]. 4 Serialization As described earlier, object serialization is putting the object into a form that can be stored on a storage medium, or be sent as a message across network cabling. In order to deserialize a serialized object, both the class information and the data members must be serialized together. The class type is usually serialized first, so that as the rest of the information comes it can be deserialized according to its proper size and type. There are three major areas of concern that an approach to serialization must confront, they are: Serialization overhead Transient and Static Data Object Relationships Serialization overhead deals with the amount of time, and space needed to serialize a given object. Transient and static data present a problem, because of the nature of this kind of information. Object relations are a tricky area because two object can reference one object. When this happens, only one object should be serialized. The serialization. deserialization process must include a way to recreate these sorts of complex object relationships. One way to do this is through the use of object identity (oid) values for each object. Then as an object is serialized, the first time an object is serialized it is given an oid. All future serialization attempts would result in the object s oid being sent to serialization, instead of the object itself [JAVA1]. There are four main approaches for implementing object serialization. Each has its benefits, as well as drawbacks. They are: All objects can serialize themselves All objects are saved as part of an image All objects must be serialized using a storage class Some non-object serializes the objects One way to enable object to serialize themselves it the approach used by Microsoft in the Microsoft Foundation Class library. They use the approach of creating a class that is serializable (CObject), and the use this class as the base class, and let all other classes which need to have serialization capabilities inherit this ability as a sub class [BEVERIDGE1].

8 Though this approach is not bad, it forces programmers to make their objects part of the a hierarchy that may take a way from the object model intended. The other way, (and possible more often used way) is presented by John Schillings. He allows implementation of the serialization functionality in any class, which can be inherited as needed, but he does not require all object to come from a single serializable object [SHILLING1]. The problems with this method include dealing with the portability issues on a class by class basis. The major problem with having objects serialize themselves, is in keeping the object relationships intact. This is because the object might not realize that an object it references has already been serialized. This issue can be dealt with by using object identifiers, and a table (or object) which keeps track of which objects have been serialized [SHILLING1]. An example of saving objects as part of an image is Smalltalk. An image is a memory dump made by a virtual machine. The concept of virtual machine is used by Smalltalk, and Java. A virtual machine is a program which can run other programs. The program acts as if it were the operating system, and give an interface to the real operating system. The biggest drawback to using the image approach is the size of the image to be stored. Since all objects have to be in the image, it can become gigantic. To get around this, the object relationships are often stored as images, while the actual data is stored using one of the other methods. A major advantage to the image dump system is the fact that object relationships are saved as found in the machine, rather than being broken up into separate parts at serialization time. Using a storage class means only one class is serializable, all objects must be stored in as data in an instance of this class. Problems associated with this approach include: the difficulty in representing objects in terms a the storage class., the added overhead (in both time and space) needed by the storage object, and the difficulty in keeping object relationships. The least object-oriented approach is that of using a non-object to save the objects. This approach is often used, because it takes the least amount of overhead, though it does have some because of the function calls necessary to get the member data from an object which needs serialized. This approach can use a table or object to keep track of object relationships, similar to the one used by the first approach. Non-object oriented databases with object support use this approach to saving data. Problems also arise when it comes time to deserialize the objects. Some major issues in deserialization are: deciding which type of object to deserialize, skipping objects that can t be loaded, and rebuilding the object relationships. Many of the headaches associated with deciding which object to deserialize can be overcome by sending this information before the member data. Object relationships can be handled the same way as in serialization, through the use of object identifiers. In order to skip objects, the size of the object (in serialized form) must be serialized with the rest of the objects information.

9 5 Conclusions In this paper, issues related to object serialization, distribution, and persistency were introduced. It was shown how all three issues are inter-related. All share certain problems, and each have problems specific to that area. This paper also gave some approaches to overcoming these obstacles, though in depth solutions can be found else where. The following table describes how some of the above issues inter-relate with the three main topics. Serialization Persistency Distribution Concurrency Not an issue Use database techniques Use object locking techniques Large Objects Not an issue Break it up using database techniques Store parts of object separately, with oid. Object Relationships Use oid Use oid Use oid Portability Choose endian style and convert as needed. Serialize properly Serialize properly With the Internet, there is a whole new frontier waiting to be introduced to the object oriented approach to computing [INGHAM1]. In order for this to happen, the solutions must be found for the issues dealing with object serialization, object distribution, and object persistency.

10 References [SAAKE1] Saake, G. and S. Conrad, I. Schmitt, and C. Trker. Object-Oriented Database Design: What is the Difference with Relational Database Design. ObjectWorld Frankfurt Conference Notes, Wednesday, October 11. Found on the Internet at October [INGHAM1] Ingham, David and Mark Little, Steve Caughey, and Santosh Shrivastava. W3Objects: Bringing Object- Oriented Technology to the Web. Found on the Internet at November 1994 [LOOMIS1] Loomis, Mary E.S. Making Objects Persistent. Journal of Object- Oriented Programming, October [NIERSTRASZ1] Nierstrasz, Oscar and Michael Papthomas. Viewing Objects as Patterns of Communicating Agents. From the proceedings of OOPSLA [CULLENS1] Chane Cullens. Serialization and MFC: Extending MFC for cross-platform portability. Dr. Dobb s journal, #229 April 1995 can be found on the Internet at [MCCUE1] McCue, Daniel L., Santosh K. Shrivastava. Structuring Persistent Object Systems for Portability in a Distributed Environment. Appeared in the Proceedings of the Fourth ACM SIGOPT Workshop, Bologa, September Found on the Internet at: [SHILLING1] Schillings, John J. How to roll your own persistent objects in C++. Printed in Journal of Object-Oriented Programming. July/August [WALDO1]

11 Waldo, Jim and Geoff Wyant, Ann Wollrath, and Sam Kendall. A Note on Distributed Computing. [BEVERIDGE1] Jim Beveridge. Inside MFC Serialization. Dr. Dobb s Journal, October Found on the Internet at November 3, [JAVA1] Sun Microsystems. Java Object Serialization Specification Revision 0.9. Found at November Originally drafted May 8, [INGHAM1] Ingham, David and Mark Little, Steve Caughey, and Santosh Shrivastava. W3Objects: Bringing Object- Oriented Technology to the Web. Found at October [PARRINGTON1] Graham D Parrington. Programming Distributed Applications Transparently in C++: Myth or Reality. Proceedings of the OpenForum 92 Technical Conference, pp , Utrecht, November 1992 Found on the Internet at ac.uk/arjuna/papers/openforum.ps, Oct 19, 1996.