Sascha Tayefeh's Homepage

While Spring Framework – and in particular Spring Security – provides many ways to deal with authentication and authorization, there are some new approaches that are becoming increasingly popular. As in most cases, the requirements of the cloud along with that of mulitenant applications have been the driving force of this evolution.

For example, while SSL is definitely a secure layer, many (if not most) home grown applications simply do not want to pay for a signed certificate (even less in face of the fact that such a certificate is mostly restricted to a single domain) and, thus, simply do not use SSL. Of course, this is worst, but still common practice.

Also, basic authentification is, presumingly with respect to its simplicity, still widespread. However, basic authentification in combination with a non-secure transport layer is a security black hole.

And finally, with SaaS rising, comfortable single sign-on in a multitenant environment must be considered in modern software design. Latter issue, cloud based single sign-on, is supported by the Spring Security (see ref. manual).

There are some more requirements emerging from the evolving cloud: for example, RESTful web services as part of asynchronous data transfer need to be secured on user level. While such scenarios can definitely be realized with the Spring Security, it definitely focuses on securing classic synchronous data transfer and flows (for instance, I would rather not choose Spring Web Flow to implement the flow of an highly AJAXian web application). In order to implement flows based on highly asynchronous communication between the client and server, there is definitely some hacking to do (see e.g. this tutorial).

However, the most important issue in times of millions of home grown smartphone apps is sharing credentials with such a client. Using same password over and over again, because you cannot remember millions of different passwords? Of course, this is worst, but still common practice. Now, what if your credentials are misused by your app? Wouldn’t it be much better, if you would not share your credentials with the client at all?

OAuth is an open protocol to allow secure API authorization in a simple and standard method from desktop and web applications. It has been developed with most of the issues that emerged from cloud-based authentification and authorizastion in mind. Furthermore, it is being used by global players like Digg, Jaiku, Flickr, Twitter, and developers of OAuth are hopeful to see Google, Yahoo, and others soon to follow. With so many heavy weight service providers relying on OAuth, it may definitely be considered as quasi standard. Unfortunately, Spring Security is not (yet) shipped with out-of-the-box support of OAuth, although I am pretty sure that the extremely capable Springsource team will deliver Spring with OAuth support as soon as possible.

For those who cannot (and should not) wait, a promising approach is described in OAuth for Spring Security. The purpose of this project is to provide an OAuth implementation for Spring Security. I have tested their implementation, and hereby I strongly recommend their approach. For me, the most striking advantage of this design is the combined power of both, OAuth and Spring Security. While you still have the comfort of Spring and its AOP framework, you have implemented the security of OAuth.

There has been a lot of talk about the pros and cons of HTML5, in particular as some consider it as full replacement for other rich ui solutions. There is a nice video showing a developer presenting his HTML5 demo … and it is really an extraordinary piece of work:

Just wonder how long it will take until designs like the one used by this webpage are going to be soooo 2010 …

Further References

• HTML5 resources overview
• Designing a HTML5 layout from scratch
• Animation Demo
• HTML5 Demos
• HTML5 Gallery
• HTML5 Spec

To demonstrate how mapping is carried out by ORM, Hibernate was used with JPA2 annotation syntax and MySQL as database. Two trivial entities are used, “Book” and “Store” for both, one-to-many/many-to-one and many-to-many demo. However, this is no particularly good design, since an individual book cannot be physically located in two places, but for this demo, it is an appropiate abstraction.

A book is considered as being owned by one (many) store(s).

1. One-To-Many/Many-To-One

1.1 Unidirectional

1.1.1 Many-To-One

First, let’s have a look at an excerpt the “Book” class. The association has got to be defined here, because many using unidirectional association of the many-to-one type, this one is the “many” side:

@Entity
public class Book extends BusinessObject {
    // Unidirectional Many-to-one
    // No assoc. in Book required
    // getters/setters required
    @ManyToOne
    @JoinColumn(name = "store_fk")
    private Store store;
...
}

Since this is an unidirectional association coming from the Book side, the Store (one) side needs no further association.

@Entity@Table(name = "store")
public class Store extends BusinessObject {
    // No assoc. required
...
}

Running this will result into two tables created, one per entity (ignoring the obligatory and hibernate specific “hibernate_sequences” table). “store_fk” as defined by @JoinColumn of the Book class is mapped as an attribute of the table “Book”.

mysql> show tables from dbjava;
+---------------------+
| Tables_in_dbjava    |
+---------------------+
| book                |
| hibernate_sequences |
| store               |
+---------------------+
3 rows in set (0.00 sec)

mysql> describe `dbjava`.BOOK;
+-------------+----------+------+-----+---------+-------+
| Field       | Type     | Null | Key | Default | Extra |
+-------------+----------+------+-----+---------+-------+
| id          | int(11)  | NO   | PRI | NULL    |       |
| store_fk    | int(11)  | YES  | MUL | NULL    |       |
+-------------+----------+------+-----+---------+-------+
6 rows in set (0.00 sec)

mysql> describe `dbjava`.STORE;
+----------+--------------+------+-----+---------+-------+
| Field    | Type         | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| id_store | int(11)      | NO   | PRI | NULL    |       |
+----------+--------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

1.1.2 One-To-Many

In this case, the association is defined from the inverse point of view, leaving Book without an association to be declared, while the association is now declared by the Store entity.

@Entity
public class Book extends BusinessObject {
    // No assoc. required
}

@Entity
public class Store extends BusinessObject {

    // Unidirectional One-To-Many
    // No assoc. in Book required
    // getters/setters required
    @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    @JoinColumn(name = "store_fk")
    private Set<Book> books;

    public Set<Book> getBooks() {
        return books;
    }

    public void setBooks(Set<Book> books) {
        this.books = books;
    }
    ...
}

And the resulting database which, using these queries, looks identically:

mysql> show tables from dbjava;
+---------------------+
| Tables_in_dbjava    |
+---------------------+
| book                |
| hibernate_sequences |
| store               |
+---------------------+
3 rows in set (0.00 sec)

mysql> describe `dbjava`.BOOK;
+-------------+----------+------+-----+---------+-------+
| Field       | Type     | Null | Key | Default | Extra |
+-------------+----------+------+-----+---------+-------+
| id          | int(11)  | NO   | PRI | NULL    |       |
| store_fk    | int(11)  | YES  | MUL | NULL    |       |
+-------------+----------+------+-----+---------+-------+
6 rows in set (0.00 sec)

mysql> describe `dbjava`.STORE;
+----------+--------------+------+-----+---------+-------+
| Field    | Type         | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| id_store | int(11)      | NO   | PRI | NULL    |       |
+----------+--------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

1.2 Bidirectional with the “many” side as the owner

In order to define a bidirectional association between both entities, one side is considered to be the owner. In this case, it is the Store that owns a Book. This fact is realized by the “mappedBy” parameter on the owner side, while the owned side carries the Owner’s id within the database.

@Entity
public class Store extends BusinessObject {

    // Bidirectional One-To-Many
    // This side is owner, thus, this collection is mappedBy
    // getters/setters required
    @OneToMany(mappedBy = "store")
    private Set<Book> books;

    public Set<Book> getBooks() {
        return books;
    }

    public void setBooks(Set<Book> books) {
        this.books = books;
    }
...
}

@Entity
public class Book extends BusinessObject {

    // Bidirectional Many-To-one
    // Book is owned by one store
    // getters/setters required
    @ManyToOne
    @JoinColumn(name="store_fk")
    private Store store;

    public Store getStore() {
        return store;
    }

    public void setStore(Store store) {
        this.store = store;
    }
...
}

mysql> show tables from dbjava;
+---------------------+
| Tables_in_dbjava    |
+---------------------+
| book                |
| hibernate_sequences |
| store               |
+---------------------+
3 rows in set (0.00 sec)

mysql> describe `dbjava`.BOOK;
+-------------+----------+------+-----+---------+-------+
| Field       | Type     | Null | Key | Default | Extra |
+-------------+----------+------+-----+---------+-------+
| id          | int(11)  | NO   | PRI | NULL    |       |
| store_fk    | int(11)  | YES  | MUL | NULL    |       |
+-------------+----------+------+-----+---------+-------+
6 rows in set (0.01 sec)

mysql> describe `dbjava`.STORE;
+----------+--------------+------+-----+---------+-------+
| Field    | Type         | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| id_store | int(11)      | NO   | PRI | NULL    |       |
+----------+--------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

2. Many-to-Many

Many-to-many relations typically need another table that provides the association of the associated entities. Both classes need to define the association, however, since one side is regarded as the owner, the definition is asymetric.

@Entity
public class Book extends BusinessObject {

    // Many to many, the other side is the owned
    // Getters & setters are required
    @ManyToMany(
            cascade = {CascadeType.PERSIST, CascadeType.MERGE},
            mappedBy = "books",
            targetEntity = Store.class
    )
    private Collection stores;

    public Collection getStores() {
        return stores;
    }

    public void setStores(Collection stores) {
        this.stores = stores;
    }

@Entity
@Table(name = "store")
public class Store extends BusinessObject {
    @ManyToMany(
            targetEntity = de.tayefeh.businessobjects.Book.class,
            cascade = {CascadeType.PERSIST, CascadeType.MERGE})
    @JoinTable(
            name="store_book",
            joinColumns = @JoinColumn(name = "store_id"),
            inverseJoinColumns = @JoinColumn(name = "book_id")
    )
    private Collection books;

    public Collection getBooks() {
        return books;
    }

    public void setBooks(Collection books) {
        this.books = books;
    }
...
}

In this case, the “store_book” table is actually created and we have three entity tables for two entities. However, there are no additional columns added to the tables of the original entities:

mysql> show tables from dbjava;
+---------------------+
| Tables_in_dbjava    |
+---------------------+
| book                |
| hibernate_sequences |
| store               |
| store_book          |
+---------------------+
4 rows in set (0.00 sec)

mysql> describe `dbjava`.BOOK;
+-------------+----------+------+-----+---------+-------+
| Field       | Type     | Null | Key | Default | Extra |
+-------------+----------+------+-----+---------+-------+
| id          | int(11)  | NO   | PRI | NULL    |       |
+-------------+----------+------+-----+---------+-------+
5 rows in set (0.00 sec)

mysql> describe `dbjava`.STORE;
+----------+--------------+------+-----+---------+-------+
| Field    | Type         | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| id_store | int(11)      | NO   | PRI | NULL    |       |
+----------+--------------+------+-----+---------+-------+
2 rows in set (0.01 sec)

mysql> describe `dbjava`.STORE_BOOK;
+----------+---------+------+-----+---------+-------+
| Field    | Type    | Null | Key | Default | Extra |
+----------+---------+------+-----+---------+-------+
| store_id | int(11) | NO   | MUL | NULL    |       |
| book_id  | int(11) | NO   | MUL | NULL    |       |
+----------+---------+------+-----+---------+-------+
2 rows in set (0.01 sec)

When I migrated an old project from JUnit3 to JUnit4, I ran into some problems. mvn:test produced an error:

junit.framework.AssertionFailedError: No tests found in minimal.DoSomeActionTest

>The test classes were no longer available. I found that I had to remove inheritance from :TestCase() and annotate all test methods with @Test. Here is a trivial example:

package minimal;
import org.junit.Assert;
import org.junit.Test;
public class DoSomeActionTest {
    @Test
    public void testIsThisReallyTrue() {
        Assert.assertTrue(true);
    }
}

In case you have your project managed by maven, remember to make use of the maven-compiler-plugin to enforce Java 1.6 (required for annotations):

            <plugin>
                <groupId>
                  org.apache.maven.plugins
                </groupId>
                <artifactId>
                  maven-compiler-plugin
                </artifactId>
                <version>2.3.1</version>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>

When running mvn:test you should get following positive message:

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running minimal.DoSomeActionTest

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2 seconds
[INFO] Finished at: Sun Jul 11 17:22:44 CEST 2010
[INFO] Final Memory: 10M/19M
[INFO] ------------------------------------------------------------------------

I have prepared a working maven project. It was published at github. Get your local copy by cloning with git:

git clone git://github.com/sastay/JUnit4-and-Maven-Example.git

If only two years ago somebody had dared to suggest that RDBMS was not the first choice and the future of data modeling, nobody would had believed him. However, there have been a lot of talk about non-relational (“NoSQL“) databases emerging (refer to 1, 2, 3, 4). Evidence for their success: Facebook (refer to 5), Twitter, Google, and Amazon heavily prefer NoSQL solutions.

Rob Conery recently wrote a bold and astonishing statement:

“Default to denormalization”. Wow! So here we are now: The times of “do normalize, do normalize, just do it” are over! Normalization alway is a performance issue and for simple data models there is actually no need for maximizing integrity by normalizing. As far as I am concerned, the strongest pros for non-relational NoSQL dbs are

• scalability,
• performance and
• simplicity.

There have been a lot of reports saying that migrating from relational to non-relational models have saved them a lot of time and money (refer to e.g. 6). I must agree: If you ever had to go through the hell of coping with the object-relational impendance mismatch and the Anemic Domain Model dilemma you would give anything to simplify your persistence layer. So many hours (months, years, decades) have been spend by developers dealing with these issues instead of focusing on the business logic.

However, when it comes to complex data models and where data integrity is more important than performance, I still believe in the power of RDBMS and their low-level consistance enforcement mechanisms. Since mixed solutions are encouraged too (refer to 6, 7), I guess an intelligent trade-off is the best solution: Using both data models alongside brings you the best from both worlds.

I am quite convinced that more and more project leaders will (have to) prefer NoSQL dbs wherever possible and carry on using RDBSM wisely wherever data integrity and complexity is an issue.