Buu Nguyen's Blog

Paul Graham said Microsoft is dead (in the sense that it is losing its domination in the information technology world) and one of the reasons provided by Paul is the emergence of Ajax. While it is easy to see that the rise of Ajax-based applications is taking more and more away the land of desktop applications and, hence, the dominating position of MS, I believe that if there is any dead at all, it will be a very slow dead. Let me quickly throw out two reasons.

1. Desktop applications will still long be there. There are just many kinds of applications that I don’t see the point of having them implemented on the web, or even if that is possible. Think about games like Final Fantasy, Half Life. With JavaScript? Forget it. WPF/E or Flash? It’s GBs of data over the internet, baby (and these are MS’ and Adobe’s toys, not “open” toys as Ajax)! Okay, there is even image processing application on the web – but it is nowhere close to the desktop Photoshop in term of functionality and performance. And even if it is close, I need to be able to work offline and save my files since the internet does not go with me all day long.

2. MS will still long be there. Not to mention about the huge cast and market share MS is having, the point is that despite being big, innovations are still happening at MS. Think about cool stuffs like .NET generics, Windows Workflow Foundation, Orcas, Office SharePoint Server 2007, C# 3.0, WPF(/E) (the two techs that I think are part of an attempt to reduce the Ajax’ heat, although MS also has ASP.NET AJAX as a fall-back solution in case WPF(/E) cannot be the big next thing), and a whole more interesting stuffs at MS’ labs around the world, like the Singularity operating system or the C-Omega language (whose many concepts are being brought into C# 3.0). Oh, and I almost forgot, they even have XBox .

So, I don’t think desktop applications cannot be killed, and I don’t think MS cannot be killed. But that will take time, a lot of time. Enough from me, read what Don Dodge at MS thinks about Paul Graham’s article.

There are several interesting discussions at The Code Project regarding my article on db4o, I think it may be useful to compile those discussions into a blog entry so that those who missed the comments section at The Code Project can read.
Read more…

In Part 1 and Part 2 of the article entitled The Legend of Data Persistence, I have introduced you to the O-R impedance mismatch, O-R/M tools, ODBMS and its advantages and disadvantages in comparison with RDBMS.  Now, once you have decided that you would use an ODBMS for your project, which ODBMS should you use?  This article, as a follow-up of The Legend of Data Persistence, aims to introduce you to one of today’s most popular ODBMS implementations, db4objects (db4o). 

Read more…

In Part 1 of this article, I have discussed about the Object-Relational (O-R) impedance mismatch, the problem it causes as well as the pitfalls of some O-R/M tools.  In this part, I will examine Object Database Management System (ODBMS) and compare it with Relational Database Management System (RDBMS).

1. What is ODBMS

Basically, an ODBMS is a DBMS which stores objects as opposed to rows or tuples in respectively a SQL or a RDBMS [Wikipedia, Object Database] and bornt out of the need for transparent and non-intrusive persistence of complex object model, tasks which could not easily be addressed by RDBMS because of the O-R impedance mismatch.  As a DBMS, besides being a data respository for storing object graphs (together with their identities, attributes, associations, and inheritance information), an ODBMS would, at the very least, include a query engine, a concurrency management system, and a data recovery mechanism.  (The very first effort to define the features of ODBMS was the ODBMS Manifesto first published in 1989 by Malcolm Atkinson et al.)

Standardization

Before examing the types of ODBMS, it’s worth to learn about the ODMG (Object Data Management Group), which is a standardization committee established in 1991 with the goal of promoting the adoption of ODBMS via the creation of standardized ODBMS specifications.  In 1999, the latest version of the ODMG specification (3.0) was released with the four major components:

• Object Model: defines the common data model (which is a common denominator for OO database systems and programming languages) to be supported by all ODMG-compliant ODBMSs.  With this common data model, object definitions within object databases can be portable among different applications, programming languages, and platforms
• Object Specification Languages: include Object Defition Language (ODL) and Object Interchange Format (OIF).  ODL is used to define the database’ object schema and is equivalent to the Data Definition Language (DDL) in the relational world.  On the other hand, OIF is a means to dump and load the object databases’ state to and from files (e.g. XML files) (e.g. to support the exchanging of objects between different object databases)
• Object Query Language: is a query language based on SQL 92 and is equivalent to SQL in the relational world.  OQL supports the querying of complex objects, polymorphism and late-binding calls, and is interoperable with specific language bindings
• Language Bindings: written for C++, Smalltalk, and Java and expose a persistence API so that these languages can interact with ODMG-compliant object databases

Despites this standardization effort, as of 2001, there was no ODBMS fully compliant to all ODMG standards [Barry, 2001].  In this same year, the ODMG disbanded as the member companies decided to concentrate their effort on the Java Data Objects specification, which was resulted from the ODMG Java Language Binding submitted to the Java Community Process.  In 2006, the Object Management Group (OMG) announced that they would develop a new specifications on the ODMG 3.0 specification and has yet to release any specification since then.  As a result, while many standards (including SQL and the mathematics-based relational model) have been consistently adopted by virtually all RDBMS vendors, widely adopted ODBMS standards simply do not exist yet.

2. Types of ODBMS

Depending on how an ODBMS implementation chooses to persist objects, there are two types of ODBMS: non-native and native.

a. Non-native ODBMS

In a non-native object database, there are two separate object models, one of the application and the other of the database itself.  ODMG-compliant ODBMSs are examples of non-native ODBMSs since they require a separate data schema to be defined, regardless of the existance of the application object model.  In order to query or persist objects from and to non-native object databases, the mapping between these two distinct models must be performed.  For ODMG-compliant databases, the schema is defined by the ODL and the application object model can either be generated from that schema or manually written by developers and then modified by a source-code or bytecode/CIL enhancers (as part of the persistent API, such as JDO, for that particular database implementation) to add persistent behaviors (e.g. to make the class an Active Record) and information (e.g. mapping information).

While the separation between the application object model from the database object model gives non-native ODBMS the advantage of having its databases portable across applications, programming languages, and platforms, it is also the source of problems because application developers have to maintain both of these models as the application evolves.

b. Native ODBMS

In native object databases, objects are stored exactly as they are, without the need to map them into a different object model supported by the databases and vice versa.  In other words, in the world of native object databases, there is just one single object model: the application object model and thus, unlike non-native ODBMS, no ODL and common object model are necessary.  (Note that while no new object model is required, it does not mean that a native ODBMS cannot have its proprietary data format to represent the application object models in the data store.)

The interesting thing is that one can easily implement a simple non-native ODBMS in Java, Ruby or a .NET language using the built-in serialization mechanism which can serialize objects into byte-stream, which can then be stored into a file or sent over the network, and deserialize objects from the same byte-stream.  With the serialization infrastructure, no extra work is necessary for storing objects’ attributes, associations, and inheritance information, and thus one will only need to add an object identification mechanism (e.g. assign an OID field to each object, either hand-coding or, more sophisticated, using bytecode/CIL enhancement [no need in Ruby thanks to its "open-class" feature]), a query API (e.g. query-by-example) and a simple concurrency system (assume the database is shared by just one application at a time, the built-in thread locking mechanism is sufficient) in order to have an ODBMS implementation ².

In contrast with its non-native counterpart, native ODMBS while simplifies the querying and persistence of application object model to the minimum, its databases are not easily portable across applications, programming languages and platforms.  In fact, for two or more applications to make use of the same database, they must have the exact same persistence classes bundled with them (same name, same package/namespace, and attributes with their types).  It is even harder for applications written in different languages to share the same database file because of the differences in naming conventions and base types (framework classes) ³.

3. ODBMS Versus RDBMS

Having looked at the basic features and types of ODBMS, let’s examine its advantages and disadvantages in comparison to RDBMS

a. Advantages

• Rich domain model: since ODBMS can store objects at any level of granularity and has built-in suport for identity, association, and inheritance, OO developers can model their domain classes as richly and expressively as they want without being constraint as with the relational world
• Maintainability: since the application object model and database object model are closely related to each other (in non-native object databases) or even are the exact same model (in native object databa
  ses), it takes less effort to maintain these models as the application evolves
• Development effort: the ability of developers to implement rich domain domain with the least maintainance effort would result in a significant reduction in development time and cost.
• Performance: ODBMS is supposed to perform much better than its RDBMS counterpart, regardless of whether O-R/M tools are used or not, in systems with highly complex object model, since no complex queries (e.g. joins) and mapping are required

b. Disadvantages

• Portability: data in RDBMS can be shared by applications written in any paradigm and platform while ODBMS is tied to the OO world.  The situation is even worse for native object databases since the data cannot be used by multiple applications with different domain classes, even if they share the same data.  As a matter of fact, the clear separation between the relational model and object model further assists portability of RDBMS since these two can evolve independent of each other
• Legacy applications: there are so many applications built with a RDBMS back-end that it is impractical to migrate all these data into ODBMS.  In addition, not only the data has to be migrated, the applications which consume the data will also need to be modified to make use of a OO data access mechanism
• Maturity: the ODBMS industry are new (emerged since the 90’s) and thus is far from close to RDBMS world (emerged since the 70’s) in terms of available system vendors (including the compatibility among database systems from different vendors) and tool supports (such as reporting, OLAP, data transformation, and clustering services etc.)

With the above analysis, ODBMS is not so much of a silver-bullet that some people hope for and thus the decision whether to use ODBMS in a project or not must be considered very carefully.  However, once we have done the homework and decided that object databases can be used for our applications, then we can sit down and enjoy the huge productivity gain which cannot be achieved if we stick with relational databases.  In the final part of this article, we will look at the DB4O object database system.  Stay tuned!

Endnotes

¹ The very first effort to specify the features of ODBMS was the work of Malcolm Atkinson and others in 1989 with the ODBMS Manifesto

² This simplistic implementation, besides the lack of functionalities, has several major drawbacks.  First, searching of serialized objects requires all objects to be deserialized into memory first before an in-memory search can occur while deserialization is a extremely costly operation.  Next, databases created by this implementation are not portable across platforms (e.g. Java to .NET) since the proprietary serialization mechanism of the host programming language is used.  Finally, the serialization infrastructure will break down as soon as the object model evolves with new attributes, associations, and data types.  An alternative could serialize objects into a custom XML format so that searching can be performed quickly using XPath, schema evolution and portability can be handled via the XML binding layer; but then, this is not simple anymore and it is usually better to make use an existing ODBMS system, like DB4O, instead

³ While these are hard, they are not impossible in native ODBMS such as DB4O which allows developers to change the default mapping rules in code (although awkward and should be avoided as much as possible), which we will see in Part 3 of the article

References

• Database Systems, Paul Beynon-Davies, Palgrave Macmillan, 2004
• Java Data Object, David Jordan and Craig Russell, O’Reilly, 2003
• [Barry, 2001], ODMG Compliance, Barry et al, Barry & Associates, Inc., 2001
• ODMG 2.0: A Standard for Object Storage, Doug Barry, Component Strategies, 1998
• ODBMS Manifesto, Malcolm Atkinson et al, University of Glasgow, 1995
• ODMG’s website: http://www.odmg.org/
• DB4O’s website: http://www.db4o.com/
• JDO’s website: http://java.sun.com/products/jdo/
• http://en.wikipedia.org/wiki/Object-oriented_database_management_system
• http://en.wikipedia.org/wiki/Java_Data_Objects

Lately, I’ve seen some job posts in the local newspapers which seek for senior .NET developers and senior Java developer who have at least 4 years of experience in .NET/Java, and feel a little bit dissatisfied with them. Read more…

MS has decided to incorporate WinFX’s technologies (WPF, WCF, WF, WCS) into the current .NET Framework 2.0 so that they altogether make up .NET Framework 3.0. In other words, the compilers (C#, VB.NET etc.) and the CRL are still 2.0, and there’s no LINQ yet (which will be shipped as part of VS.NET Orcas and .NET 3.5). Whether to like this naming scheme or not is a matter of personal taste. Personally, I like the fact that .NET Framework 3.0 is used as an “umbrella” for WinFX because it makes a lot of sense for technologies like WPF and WCF to be part of the framework, instead of being part of a separate download, given that those technologies will likely to be very popular tools for .NET developers (just like WinForms and ASP.NET currently are).

On the other hand, although this plan generates the mismatch between the framework version and the language/compiler version, I don’t see it a big problem because this will eventually happen, if not now because changes to the language need not to be dependent on changes to the supporting platform (e.g. class libraries)

See more at: http://blogs.msdn.com/somasegar/archive/2006/06/09/624300.aspx and http://blogs.msdn.com/kaevans/archive/2006/06/11/626299.aspx

Now, they even make a C#-2-JavaScript compiler, besides the GWT on the Java space. Guys, the next step is to completely eliminate all JavaScript we have to write, including those embedded in the HTML pages, port as many JavaScript libraries to .NET and Java as possible and vice versa, and make those libraries browser-independent. The point is to make JavaScript and its infamous browser-incompatibility problem completely transparent from application developers. By doing that, developers do not have to care about JavaScript any longer and it will become the machine language of the browsers. I do not care about the machine code since the appearance of Java and C#, neither do I want to care about JavaScript if you guys decide to generate it from Java/C#.

WPF/E CTP released. Now, a subset of the CLR is actually brought down and hosted in the browser. Download and get start with some apps. OK, now I don’t have to regret not having time to learn Action Script. JavaScript means not only a better integration with the page’s DOM but also a lot of people can reuse their skills, and more search-engine-friendly contents. BTW, feeling scared away by JavaScript? Try Google Web Toolkit

It’s coming to an age in which we have so many options in doing highly interactive and functional web applications. I can foresee that in the near future, most business applications will be operated on the web. The browser will be the one single big hosting environment in which I use to run all kinds of my daily works such as spreadsheet, project tracking, and even designing and programming.