Analysis of the persistence layer from the SCEA 5 perspective

The technology grew up too fast and there's a lot of different ways to perform data persistence in an Enterprise application, you can do a simple INSERT sql, like:

INSERT INTO Customer VALUES (1, 'Isaac', 'Newton')

or you could use a more sophisticated way to do that, with some ORMs frameworks, but... before to talk about the benefits of one over the other, and which one should you pick in the real life or in the SCEA, lets explain every word.

ORM (stands for Object relationship management): The definition from wikipedia says:

"Object-Relational Mapping (aka ORM, O/RM, and O/R mapping) is a programming technique for converting data between incompatible type systems in relational databases and object-oriented programming languages. This creates, in effect, a "virtual object database" which can be used from within the programming language."
but what does this means in the real life of an application?, ok... this is really simple, instead of doing this:

INSERT INTO Customer VALUES (1, 'Isaac', 'Newton')

you will do:

Customer cust = new Customer();
cust.setName('Isaac');
cust.setLastName('Newton');

somepersistenceframework.doPersist(cust);

its very clear in the second sample that the LastName is Newton and the First name is 'Issac', futhermore you don't have to care about the type mapping. What will happen if your customer has a birthday and you want to save it? lets see:

INSERT INTO Customer VALUES (1, 'Isaac', 'Newton', '1642/Dec/25');

but... will be the '1642/Dec/25' a valid SQL format? I don't think so... ok, lets fix it:

INSERT INTO Customer VALUES (1, 'Isaac', 'Newton', '1642/12/25');

Now... will this gone a work? it depends on which database you are working on, if the DB is SQL Server then it will, but if this is an Oracle DB then... nope... why? in Oracle you must specified the Date format as: "TO_DATE('YYYY/MM/DD', '1642/12/25')", then you will need to hard code your formatting options in your code if you want to create a good application.

But, what if you use ORM? then your application should look like:

Customer cust = new Customer();
cust.setName('Isaac');
cust.setLastName('Newton');
cust.setBirthDate(new java.util.Date(1642, 11, 25)); // or use a java.util.Calendar to get a Date

somepersistenceframework.doPersist(cust);

its easier right? ok, this is what ORM means, create objects and let the framework (or container) do the work of synchronize the object with the underlying DB. (this will be done in two ways, to persist the data like INSERTS, UPDATEs or DELETEs and also will be done to retrieve the data).

Note here: btw, I don't forget the use of Named parameters in the javax sql statements (that will fix the date format problem), I just put it as an example, but if you will judge me... ok, lets change the problem, what if the problem is with the identities? in SQL you have it but in Oracle you must implement it as Sequence in a dual table, then you will need code a different method for SQL and Oracle... or what will you say about the BLOB datas? or... I think I made my point in here :D


The evolution of the concept

One of the earliest implementation of this ORM was JDO as a framework and EJB 1.1 as a J2EE standard, in the EJB 1.0 the first approach of this was something called BPM (Bean Persistence Management), which means: "Separate all the SQLs from the Data and the container will let the object know when to synchronize"... so... what's the difference with the DAO Pattern? the main difference is that the server will do all the caching work and will let you know when the data must be saved or retrieved, this will ensure that your application will be scalable, and it will have a good performance (off course, everything depends on the quality of your SQL statements), also it's easily maintained. Then, how this works in our previous sample? here its is:

the Customer class will implement a two new methods named "ejbStore" and "ejbLoad", with these new methods your class should call a DAO class which will implement the persistence.

The only advantage here is the separation of concerns and, off course, the scalability, etc. But the developers quickly hated it, just because it was a lot of work and seems not to powerful. (but it was!)

With this problems in EJB 1.0 the JDO was a good start point for a really ORM framework, the main idea in here is that you will create the objects and an XML which will tell the framework how it will persist this object. JDO could work as a standalone framework, this will able your simple applications to use a persistence framework and forget the behaviour of the persistence layer, this was one of the biggest advantages over EJB.

The big disadvantage in EJB was that the developer should care about the implementation issues I talked about (the problem with formats like Oracle and SQL Server dates), so the developers were angry about that.

Then Sun came out with the CMP (Container Management persistence Entities) which has the advantage that it will take care of the SQL stuff and you will only need to create the entities, the promised land came to earth... but was not the best thing in the world, in fact Sun recommended that if you will need performance then you need to go back to the BMP because the algorithm was not the best and so the performance. That changed in EJB 2.0 and 2.1, were the new Entities had a very good performance (even better than if you write your own code), but they were too complex and the people still had in mind the poor performance in the earlier version.

Recently Sun launched EJB 3.0 based on a new ORM framework (JPA) and a new specification (mainly based over the current persistence frameworks like hibernate and JDO).

Ok, that was the quick flash back, lets move to the main of this discussion, comparison between the different persistence approaches. (maybe I miss some points in the history or omitted some details)

Analysis of the persistence layer from the SCEA 5 perspective

Ok, first of all... let me tell you something... the test will rely on the new JEE specification, so you will not need to be worried about CMP or BMP (why? just because they disappeared and were replaced by JPA). So the question will be, what is the best for my application: JPA, DAOs, JDBC, etc. in front of this topics: ease of development, performance, scalability, extensibility, and security?

The JPA is a framework based on the idea of POJOs (Plain Old JavaObjects) which means: "Leave the Customer class as you have it and the container (or framework) will take care of the persistence", the only thing you need to do its to provide some information about your object to the container, how you do that? if you're using JPA you will do that using Annotations, if you're using Hibernate then you will have the option to put it in a mapping xml file. Lets see how the Customer class will be if you put the JPA annotations:

import java.util.Date; import javax.persistence.Entity; import javax.persistence.Id; @Entity public class Customer implements java.io.Serializable { @Id private int id; private String name; private String lastName; private Date birthDate; public int getId() { return id; } public void setId(int id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } public String getLastName() { return lastName; } public void setLastName(String lastName) { this.lastName = lastName; } public Date getBirthDate() { return birthDate; } public void setBirthDate(Date birthDate) { this.birthDate = birthDate; } }

and how can you retrieve and save a Customer? just doing a minimum work:

put this as a variable in your Session Bean:

@PersistenceContext(unitName="BizAgi.RenderPU")
private EntityManager em;

and the persist the Customer using:

em.persist(c);

so, if you ask me what will be the easier method for development be my guess... the EJB 3.0 its really easy and far more maintainable than the previous EJB 2.1, what about the performance? the performance its not really a problem of one Entity or the way you access your db, I think its a problem of how did you solve your design issues before start the development, but from the SCEA perspective... again EJB 3.0 its faster because it has a lot of improves in performance, cache things and reuse, unless you create your own framework to persist and take care of all the cache issues and object queries EJB 3.0 will be faster every time. Off course, if you compare a simple statement over EJB 3.0 the statement will be faster than the entities, but... that's not the normal behaviour in an Enterprise application, you will have several tables, and several rows on them.

What about scalability? ok, the container ensures that your data will be replicated over all the nodes in the cluster, so you will not need to add anything else to keep the clusters up to date, in this way you could add new nodes to the array and made your application more scalable writing zero code lines, what about JDBC? it is not scalable? mmm scalable relies on how you would add new customers, the jdbc protocol will not be a limitation, the JDBC problem relies on the data cache, with the JDBC aproximation you will need to be in touch with your db to keep synchronization between the nodes, and this will be very expensive. In this way, the JDBC its scalable yes, but will lead you to a performance problem because the lack of cache. And JDO? well JDO and EJB 3 are pretty much the same thing (in the approach concepts) the difference relies again in the cache service, the framework will not replicate the changes and this will generate some problems. DAO will solve any of this? really... it does not, why? just because DAO its an implementation pattern and it will be implemented using JDBC, EJB 3 or JDO as the persistence layer.

In the extensibility context which one is best? all of the approaches are extensibles, but which one will needs more time? I think JDBC, just because the addition of new fields will need a lot of changes, UPDATE, INSERT, FIND and DELETE statements could change, in the EJB 3 you will need to add a new variable to the class and create its accessors (getters and setters) and thats it. Again EJB 3 wins the battle over JDBC, but what about JDO or hibernate? in terms of extensibility JDO and hibernate has a disadvantage, the mapping xml file, you need to do one more step over EJB 3, put the mapping data in that file (beware, hibernate has a new implementation that will get the entity information from the annotations, so hibernate will be as extensible as EJB 3 is).

And Security? ok, let me define security... do you need a user and password to create a connection with the db? for all the approaches the answer will be YES, so where is the difference? as far as I see none.

Conclusion

In the SCEA you will not be answered to choose between EJB 3, EJB 2.1 (CMP or BMP), JDO or Hibernate, it will assume if you are doing the SCEA test you will be approach your answers with his framework JPA, so you will be asked about how to ensure transactions or change things, you will not be asked about which one is the best solution. (From Sun's perspective EJB 3 is the best... off course... I do either :D)

Hope this article solves all the questions about the persistence you could have in order to pass the test, if you have any further questions about it please let me know and I will edit this article to solve some of them.

Two, Three, N-tier which one should I pick?

Jeff asked me (in the Post How to pass SCEA 5) about the following:

• Explain the advantages and disadvantages of two-tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security.
• Explain the advantages and disadvantages of three-tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security
• Explain the advantages and disadvantages of multi-tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security.

I will try to put my thoughts in here about this and I will use the following example to illustrate the case of study: Your assignment is to create a check in application for a counter in an airport. so it will show the current flights, allowing you to pick one, then lists the customers for that flight and assign the passenger's seat. (use your imagination here)

Two Tiers:

First a brief description of the situation, a two tier application its mainly a client application which has everything in one layer and connects to a repository (a database if you prefer), this is also known as Client-server architecture. (this is just a brief introduction, you could go client-server architecture to get more detail.

Lets ask first, if all the code is in one place (the client... like a swing application) the client will have all the power force and everything depends on its machine, is it an scalable solution? what will happen if you add new clients? the network overload will be a problem, because these type of application uses it a lot.

In the example the work flow will be as follows:

1. Executes a SQL to get all the current flights (between some date range)
2. shows the flights, and select the one using the ticket information
3. Executes a SQL to get the customers on that flight
4. Shows the list and select the passenger
5. Executes a SQL to verify the status of the ticket.
6. and so on.

The DB connections are very expensive and very slow, so, if you put new customers your application will have serious problems in bandwidth, overload, etc. So your application is not easily scalable. But... if you have only 3 clients (maybe three counters) this will be a very fast solution, the client application will do all the work and will be very effective. The troubles will come if you want to export this to Internet, because the clients will not have access to your internal network, you will need to spread the user and password for the db, etc.

Is this application maintainable? Think of this, if all the code is in the client will be easy to find an error? I don't think so.

What about reliability? the reliability states: "the ability of a system or component to perform its required functions under stated conditions for a specified period of time." so will the client-server be reliability? its hard to figure it out. If the system could be easily break down (because the code is in the client side) someone could change its reliability changing a part of the code. If the network configuration change the client might have problems to establish the connection to the DB, so the reliability will be affected, but as the definition states, everything depends on the conditions not the architecture.

The system will have a high availability? because all the code will run on the client this configuration will not react to a fail over problems, because everything is in one machine if that machine fails the system will not work, so the availability will decrease with this architecture.

Extensibility, mmm... I think no, its hard to maintain and extend a Client-server application, just because everything is in one place.

Performance, ok, here is the big question, the performance in a Client-server application relies on how it will work, if it has several calculations everything depends on the client, there's no way to distribute the work between several machines, all the work will be running in one PC, but... the client-server applications runs fast if you do some tricks. In the example above the performance could be an issue in here, just because it has a lot of DB queries dependencies.

Manageability, think if you are able to change some parameters and your application will run fast or will have a better reliability, the answer will be no, just because everything runs in the client and you will have absolutely no control over it.

In general I would say that increasing the tiers will ensure extensibility, maintainability, security but will decrease performance.

Remember, tiers refers to the layers in which your system could split off, if your application have a lot of classes but works in a single machine which connects to a DB then it's a client-server application.

Three Tiers

In the three tiers your application will have some logic in the client (usually the presentation and some validations), the business tier will have the 80% of the application logic (lets say this will have most of the business code) and the DB which could have some Stored Procedures in it.

What will be different from the previous approach? you will have a lot of things running in one machine, so its easier to maintain, you will increase security because the client will not have the user/password pair to access to the DB, and will be more extensible than the client-server application. But what will you gain or lose? the answer is not easy, I would say It's relative, If the application is a calculation centric then you might lose performance (because the server will do a lot of work for several clients at the same time) or you could gain performance if the application is mainly a db application, just because you could place the DB server near (referring to the network topology not the physical distance) to the business server in order to avoid the network overload.


In comparison with the Client-server you will have:

- better scalability, you could increase the hardware in the business machine and could have more clients.
- better maintainability, everything is in one place so you can replace a component and fix a bug quickly
- better reliability, because you have a better control of the environment in which the business code runs.
- better availability, if the business machine has problems you can easily replace it by a new machine a your client will be running in a blink of an eye
- better extensibility, you could add new functionality in a better way
- decrease or increase in performance, this depends on the application, if its a db application its 90% to get a better performance.
- Better manageability, its easy to control the environment in the business tier, so you can change configuration settings, improve connections etc
- Better security (I think this does not need further explanation...)

N-Tier

I think N-tier and 3-tier are pretty much the same thing, if you have a good security in 3-tier you will have even better security with N-tier and this applies to all the statements. (Even to the performance thing, a bad decision could lead to a poor performance if you choose N-Tier over the others and you don't pay attention on the specific requirements)

Why will you prefer N-Tier over 3-tier, you could distribute the work in several machines, so if you are working in a collaborative application (I loan application which will need a CRM, ERP etc then will be distribute its responsabilities over several machines and will have a better performance because of it)

In JEE you could easily use some patterns like Service Locator to change a N-Tier to a 3-Tier application (or, at least, behave as a 3-tier application), just changing the uses of the EJBs from Remote to Local. So if I need a tiered application I will choose N-tier over 3-tier every day of the week (and twice in Sunday)

(Please let me know if you need further explanation and I will add more information on N-Tiers)