计算机专业外文资料翻译

1、英文文献Object persistence and JavaBy Arsalan Saljoughy, JavaW, 05/01/97Object durability, or persistence, is the term you often hear used in conjunction with the issue of storing objects in databases. Persistence is expected to operate with transactional integrity, and as such it is subject to strict c

2、onditions. (See the Resources section of this article for more information on transaction processing.) In contrast, language services offered through standard language libraries and packages are often free from transactional constraints.As well see in this article, evidence suggests that simple Java

3、 persistence will likely stem from the language itself, while sophisticated database functionality will be offered by database vendors.No object is an islandIn the real world, you rarely find an object that lacks relations to other objects. Objects are components of object models. The issue of objec

4、t durability transcends the issue of object model durability and distribution once we make the observation that objects are interconnected by virtue of their relations to one another.The relational approach to data storage tends to aggregate data by type. Rows in a table represent the physical aggre

5、gate of objects of the same type on disk. The relationships among objects are then represented by keys that are shared across many tables. Although through database organization, relational databases sometimes allow tables that are likely to be used together to be co-located (or clustered) in the sa

6、me logical partition, such as a database segment, they have no mechanism to store object relationships in the database. Hence, in order to construct an object model, these relationships are constructed from the existing keys at run time in a process referred to as table joins. This is the same well-

7、known property of the relational databases called data independence. Nearly all variants of object databases offer some mechanism to enhance the performance of a system that involves complex object relationships over traditional relational databases.To query or to navigate?In storing objects on disk

8、, we are faced with the choice of co-locating related objects to better accommodate navigational access, or to store objects in table-like collections that aggregate objects by type to facilitate predicate-based access (queries), or both. The co-location of objects in persistent storage is an area w

9、here relational and object-oriented databases widely differ. The choice of the query language is another area of consideration. Structured Query Language (SQL) and extensions of it have provided relational systems with a predicate-based access mechanism. Object Query Language (OQL) is an object vari

10、ant of SQL, standardized by ODMG, but support for this language is currently scant. Polymorphic methods offer unprecedented elegance in constructing a semantic query for a collection of objects. For example, imagine a polymorphic behavior for acccount called isInGoodStanding. It may return the Boole

11、an true for all accounts in good standing, and false otherwise. Now imagine the elegance of querying the collection of accounts, where inGoodStanding is implemented differently based on business rules, for all accounts in good standing. It may look something like:setOfGoodCustomers = setOfAccounts.q

12、uery(account.inGoodStanding();While several of the existing object databases are capable of processing such a query style in C+ and Smalltalk, it is difficult for them to do so for larger (say, 500+ gigabytes) collections and more complex query expressions. Several of the relational database compani

13、es, such as Oracle and Informix, will soon offer other, SQL-based syntax to achieve the same result.Persistence and typeAn object-oriented language aficionado would say persistence and type are orthogonal properties of an object; that is, persistent and transient objects of the same type can be iden

14、tical because one property should not influence the other. The alternative view holds that persistence is a behavior supported only by persistable objects and certain behaviors may apply only to persistent objects. The latter approach calls for methods that instruct persistable objects to store and

15、retrieve themselves from persistent storage, while the former affords the application a seamless view of the entire object model - often by extending the virtual memory system.Canonicalization and language independenceObjects of the same type in a language should be stored in persistent storage with

16、 the same layout, regardless of the order in which their interfaces appear. The processes of transforming an object layout to this common format are collectively known as canonicalization of object representation. In compiled languages with static typing (not Java) objects written in the same langua

17、ge, but compiled under different systems, should be identically represented in persistent storage.An extension of canonicalization addresses language-independent object representation. If objects can be represented in a language-independent fashion, it will be possible for different representations

18、of the same object to share the same persistent storage.One mechanism to accomplish this task is to introduce an additional level of indirection through an interface definition language (IDL). Object database interfaces can be made through the IDL and the corresponding data structures. The downside

19、of IDL style bindings is two fold: First, the extra level of indirection always requires an additional level of translation, which impacts the overall performance of the system; second, it limits use of database services that are unique to particular vendors and that might be valuable to application

20、 developers.A similar mechanism is to support object services through an extension of the SQL. Relational database vendors and smaller object/relational vendors are proponents of this approach; however, how successful these companies will be in shaping the framework for object storage remains to be

21、seen.But the question remains: Is object persistence part of the objects behavior or is it an external service offered to objects via separate interfaces? How about collections of objects and methods for querying them? Relational, extended relational, and object/relational approaches tend to advocat

22、e a separation between language, while object databases - and the Java language itself - see persistence as intrinsic to the language:Native Java persistence via serializationObject serialization is the Java language-specific mechanism for the storage and retrieval of Java objects and primitives to

23、streams. It is worthy to note that although commercial third-party libraries for serializing C+ objects have been around for some time, C+ has never offered a native mechanism for object serialization. Heres how to use Javas serialization:/ Writing foo to a stream (for example, a file) / Step 1. Cre

24、ate an output stream / that is, create bucket to receive the bytes FileOutputStream out = new FileOutputStream(fooFile); / Step 2. Create ObjectOutputStream / that is, create a hose and put its head in the bucket ObjectOutputStream os = new ObjectOutputStream(out) / Step 3. Write a string and an obj

25、ect to the stream / that is, let the stream flow into the bucketos.writeObject(foo); os.writeObject(new Foo(); / Step 4. Flush the data to its destination os.flush(); The Writeobject method serializes foo and its transitive closure - that is, all objects that can be referenced from foo within the gr

26、aph. Within the stream only one copy of the serialized object exists. Other references to the objects are stored as object handles to save space and avoid circular references. The serialized object starts with the class followed by the fields of each class in the inheritance hierarchy./ Reading an o

27、bject from a stream / Step 1. Create an input stream FileInputStream in = new FileInputStream(fooFile); / Step 2. Create an object input stream ObjectInputStream ins = new ObjectInputStream(in); / Step 3. Got to know what you are reading String fooString = (String)ins.readObject(); Foo foo = (Foo)s.

28、readObject(); Object serialization and securityBy default, serialization writes and reads non-static and non-transient fields from the stream. This characteristic can be used as a security mechanism by declaring fields that may not be serialized as private transient. If a class may not be serialized

29、 at all, writeObject and readObject methods should be implemented to throw NoAccessException.Persistence with transactional integrity: Introducing JDBCModeled after X/Opens SQL CLI (Client Level Interface) and Microsofts ODBC abstractions, Java database connectivity (JDBC) aims to provide a database

30、 connectivity mechanism that is independent of the underlying database management system (DBMS).To become JDBC-compliant, drivers need to support at least the ANSI SQL-2 entry-level API, which gives third-party tool vendors and applications enough flexibility for database access.JDBC is designed to

31、be consistent with the rest of the Java system. Vendors are encouraged to write an API that is more strongly typed than ODBC, which affords greater static type-checking at compile time.Heres a description of the most important JDBC interfaces:java.sql.Driver.Manager handles the loading of drivers an

32、d provides support for new database connections.java.sql.Connection represents a connection to a particular database.java.sql.Statement acts as a container for executing an SQL statement on a given connection.java.sql.ResultSet controls access to the result set.You can implement a JDBC driver in sev

33、eral ways. The simplest would be to build the driver as a bridge to ODBC. This approach is best suited for tools and applications that do not require high performance. A more extensible design would introduce an extra level of indirection to the DBMS server by providing a JDBC network driver that ac

34、cesses the DBMS server through a published protocol. The most efficient driver, however, would directly access the DBMS proprietary API.Object databases and Java persistenceA number of ongoing projects in the industry offer Java persistence at the object level. However, as of this writing, Object De

35、signs PSE (Persistent Storage Engine) and PSE Pro are the only fully Java-based, object-oriented database packages available (at least, that I am aware of). Check the Resources section for more information on PSE and PSE Pro.Java development has led to a departure from the traditional development pa

36、radigm for software vendors, most notably in the development process timeline. For example, PSE and PSE Pro are developed in a heterogeneous environment. And because there isnt a linking step in the development process, developers have been able to create various functional components independent of

37、 each other, which results in better, more reliable object-oriented code.PSE Pro has the ability to recover a corrupted database from an aborted transaction caused by system failure. The classes that are responsible for this added functionality are not present in the PSE release. No other difference

38、s exist between the two products. These products are what we call dribbleware - software releases that enhance their functionality by plugging in new components. In the not-so-distant future, the concept of purchasing large, monolithic software would become a thing of the past. The new business envi

39、ronment in cyberspace, together with Java computing, enable users to purchase only those parts of the object model (object graph) they need, resulting in more compact end products.PSE works by post-processing and annotating class files after they have been created by the developer. From PSEs point o

40、f view, classes in an object graph are either persistent-capable or persistent-aware. Persistent-capable classes may persist themselves while persistent-aware classes can operate on persistent objects. This distinction is necessary because persistence may not be a desired behavior for certain classe

41、s. The class file post-processor makes the following modifications to classes:Modifies the class to inherit from odi.Persistent or odi.util.HashPersistent.Defines the initializeContents() method to load real values into hollow instances of your Persistent subclass. ObjectStore provides methods on th

42、e GenericObject class that retrieves each Field type.Be sure to call the correct methods for the fields in your persistent object. A separate method is available for obtaining each type of Field object. ObjectStore calls the initializeContents() method as needed. The method signature is:public void

43、initializeContents(GenericObject genObj)Defines the flushContents() method to copy values from a modified instance (active persistent object) back to the database. ObjectStore provides methods on the GenericObject Be sure to call the correct methods for the fields in your persistent object. A separa

44、te method is available for setting each type of Field object. ObjectStore calls the flushContents() method as needed. The method signature is:public void flushContents(GenericObject genObj)Defines the clearContents() method to reset the values of an instance to the default values. This method must s

45、et all reference fields that referred to persistent objects to null. ObjectStore calls this method as needed. The method signature is:public void clearContents()Modifies the methods that reference non-static fields to call the Persistent.fetch() and Persistent.dirty() methods as needed. These method

46、s must be called before the contents of persistent objects can be accessed or modified, respectively. While this step is not mandatory, it does provide a systematic way to ensure that the fetch() or dirty() method is called prior to accessing or updating object content.Defines a class that provides

47、schema information about the persistence-capable class.All these steps can be completed either manually or automatically.PSEs transaction semanticYou old-time users of ObjectStore probably will find the database and transaction semantics familiar. There is a system-wide ObjectStore object that initi

48、alizes the environment and is responsible for system-wide parameters. The Database class offers methods (such as create, open, and close), and the Transaction class has methods to begin, abort, or commit transactions. As with serialization, you need to find an entry point into the object graph. The

49、getRoot and setRoot methods of the Database class serve this function. I think a few examples would be helpful here. This first snippet shows how to initialize ObjectStore:ObjectStore.initialize(serverName, null); try db = Database.open(dbName, Database.openUpdate); catch(DatabaseNotFoundException e

50、xception) db = Database.create(dbName, 0664); This next snippet shows how to start and commit a transaction:Transaction transaction = Transaction.begin(Transaction.update); try foo = (Foo)db.getRoot(fooHead); catch(DatabaseRootNotFoundException exception) db.createRoot(fooHead, new Foo(); mit();The

51、three classes specified above - Transaction, Database, and ObjectStore - are fundamental classes for ObjectStore. PSE 1.0 does not support nested transactions, backup and recovery, clustering, large databases, object security beyond what is available in the language, and any type of distribution. Wh

52、at is exciting, however, is all of this functionality will be incrementally added to the same foundation as the product matures.About the authorArsalan Saljoughy is asystems engineer specializing in object technology at Sun Microsystems. He earned his M.S. in mathematics from SUNY at Albany, and sub

53、sequently was a research fellow at the University of Berlin. Before joining Sun, he worked as a developer and as an IT consultant to financial services companies. ConclusionAlthough it is still too early to establish which methodology for object persistence in general and Java persistence in particu

54、lar will be dominant in the future, it is safe to assume that a myriad of such styles will co-exist. The shift of storing objects as objects without disassembly into rows and columns is sure to be slow, but it will happen. In the meantime, we are more likely to see object databases better utilized i

55、n advanced engineering and telecommunications applications than in banking and back-office financial applications.英文翻译对象持久化和Java深入的了解面向对象语言中的对象持久的讨论Arsalan Saljoughy,JavaW, 05/01/97对象持久化这个术语你常常会和数据存储一起听到。持久化被期望用于事务完整性和更严格的条件（参看文献部分获取更多的事务处理的信息）。但是，编程语言提供的标准类库和包都没有包含事务约束。正如本文中我们将清楚的看到简单的java持久化很有可能会滋

56、生语言本身，而复杂的数据库功能将由数据库厂商提供。没有对象是一个岛屿在真实的世界，你很少发现一个事物跟其它事物之间没有关系，事物是对象模型的成分。对事物的持久比对对象模型的持久要困难，而且我们可以观察到对象之间是通过他们之间的关系关联在一起的。关联方式的数据存储趋于根据类型进行数据汇总，表中的行表示硬盘上同一种类型对象的物理存储，对象之间的关系是通过多张表共享关键字表现的。虽然通过数据库组织，关系数据库有时允许多表能在同一逻辑块中一起使用组成群集，例如，一个数据库部分，它没有机制存储对象关系。因此，为了构建一个对象模型，这些关系从进程运行时已经存在的关键字被构建的，又被称作表连接。这同样时众所

57、周知的关系数据库的一个特性叫做“数据独立性”。几乎所有的对象数据库都提供一些机制来增强系统的性能，包括复杂的对象关系，都超过传统的关系数据库。查询或浏览？在存储数据到磁盘上时，我们要面临的选择是协同定位有关的对象以更适合浏览访问，或者存储到表上根据对象的类型进行汇集使更容易进行查询访问（查询），或者两者一起使用。对象的协同定位是持久化存储中关系和面向对象数据库非常不一样的一个方面。选择查询语言是另外一个值得考虑的方面。结构化查询语言（SQL）和它的扩展已经证明使用条件判断存取机制的关系系统的成功。对象查询语言（OQL）是SQL的一个变种，由ODMG定制的标准，但是对这个语言的支持却非常的少。多

58、种形式组合的方法使对象的集合在构建语意查询上空前的简洁。例如，假设一个账户有多种行为组合叫做isInGoodStanding，这样所有的in good standing的账户都将会返回正确，其它的返回错误。现在可以想象查询账户集合的简洁性，ingoodstanding为多有in good standing的账户实行不同的基础上的业务规则。它看起来像：setOfGoodCustomers = setOfAccounts.query(account.inGoodStanding();大多数的对象数据库能够处理在C+和Samlltalk中像这样的查选语法，但是它门确很难处理更大数据的集合和更复杂的查询表达式。许多关系数据库公司，例如Oracle和Informix，将很快提供其它的方式，基于SQL语法来达到同样的效果。持久化和类型面向对象语言的支持者会说持久化和类型是对象的两个相交的特性，也就是说，同一类型的对象的持久和变化过程是能够相同的，因为一个特性不能够影响其它的特性。另一类观点认为持久化只是可持久对象的行为，某些行为可能被应用于持久性对