The currently popular distributed, n-tiered, object-oriented application architecture provokes many design debates. Designs of such applications are often divided into logical 'tiers'-usually user interface, business logic and domain object, or data, tiers, each with their own design issues. In particular, the latter contains data that needs to be stored and retrieved from permanent storage. Decisions need to be made as to the most appropriate way of doing this-the choices are usually whether to use an object database, to communicate directly with a relational database, or to use objectrelational mapping (ORM) tools to allow objects to be translated to and from relational form. Most often, depending on the perceived profile of the application, architects make these decisions using rules of thumb derived from particular experience or the design patterns literature. Examples include: object-oriented databases ease programming, relational databases ease report generation and data mining; object-oriented databases are good for navigation around an object model, relational databases are good for sequential processing and complex queries; if you are writing an application from scratch, use an object database, if you need to integrate to various sources of legacy data, use an ORM tool. Although helpful, these rules are often highly context-dependent and are often misapplied. Research into the nature and magnitude of 'design forces' in this area has resulted in a series of benchmarks, intended to allow architects to more clearly understand the implications of design decisions concerning object persistence. In this paper, the performance of selected open source object persistence tools is investigated, to attempt to clarify the myths surrounding the performance of the different options. In particular, we compare Hibernate, representative of the ORM stable, and db4o, representative of object-oriented databases. The OO7 benchmark is used to compare the speed of execution of a suite of typical persistence-related operations in both candidates. We then propose some preliminary explanations of the sometimes surprising results.

Over the past four decades, software engineering has emerged as a discipline in its own right, though it has roots both in computer science and in classical engineering. Its philosophical foundations and premises are not yet well understood. In recent times, members of the software engineering community have started to search for such foundations. In particular, the philosophies of Kuhn and Popper have been used by philosophically-minded software engineers in search of a deeper understanding of their discipline. It seems, however, that professional philosophers of science are not yet aware of this new discourse within the field of software engineering. Therefore, this article aims to reflect critically upon recent software engineers' attempts towards a philosophy of software engineering and to introduce our own philosophical thoughts in this context. Finally, we invite the professional philosophers of science to participate in this interesting new discourse.

No abstract

No abstract

Abstract. The observation that the Open Source Software development style is becoming part of corporate software development, raises questions about its compatibility with traditional development processes. Particular compatibility questions arise where the existing corporate development style is in the agile tradition. These questions are identified and discussed. Measures that can be taken to avoid clashes are suggested. An example illustrates how Corporate-, Agile-and Open Source Software could intersect, and SPEM modelling is employed to show how corporate processes would need to adapt to accommodate the new scenario.