Customer: "Can you create a desktop application quick please?"
Developer: "ohhhh I desktop application, sure... I will use MS Forms"
Customer: "But why not java? you told me you feel more comfortable with java"
Developer: "Shh... Swing is a pain in the ass, its hard to develop and slower than other technologies, I suggest..."
I've heard this several times, and this led me to start this post.
The common concerns about Swing are as follows (if you know other ones, just let me know and I will include them):
1. Swing is hard to develop.
2. Swing is slow
3. Swing is not suitable for Enterprise applications
4. The user feels more comfortable if the look and feel is similar to other desktop applications like MS Office, or calc... etc. And Swing looks very different, this might confuse most of the final Users.
Swing is hard to develop.
This can not be more far from true, the main problem with the Java Technology is the lack of tools, everytime Sun releases a new JDK or specification, the users need to suffer this problem, so they must implement everything from scratch using a plain text tool application, just because the IDEs does not have support to this new feature, but... Swing is not new!!!! Swing was released a long time ago, if you use Netbeans or Eclipse you will find that creating a Swing form (class) is just like .NET, even better. (btw, I'm a netbeans lover and they are working very hard to keep the IDE as much up to date as possible.)
Using Netbeans, you can drag and drop controls, use code templates, doble-click to create code for events, etc. It's very easy to create a swing form from scratch. You can create your own controls very easy and use them as normal controls with drag and drop. In a future post I will write an example of how to create an interface swing in 5 minutes... maybe less, and How to do the same using .NET, I think you would not notice the difference between these approaches (ok, well... maybe you will notice it just because the interface in java will be auto-resizable, and some other improvements).
Take a look of this: Swing fast sample
Swing is slow
This is another lack of knowledge, the JDK 5 and 6 have a lot of improvements in this way, and there's a lot of techniques to improve your Swing code in order to have a better user experience. I will do a post with some of this techniques.
Swing is not suitable for Enterprise applications
The Swing applications could also have a good connectivity with the EJBs, and everything will depends on how you solve this interaction from the design and architecture. If you use a SessionBean to execute a work and then uses a new Session bean to retrieve data then you will have some remoting problems, but you can create a Session Bean at server side to work as Model in the MVC pattern, in this way you will be able to use this model to execute the task and retrieve the required data in one or more calls from the server side, so, as I said... everything depends on your ability as architect, create JSPs and HTML application requires a lot of work, so I think Swing will reduce the amount of work to create Enterprise applications. In a 3rd post I will compare how to do the same from a Web Application and a Swing application, then I will compare which one best suits your needs.
One of the arguments used by some people about this point is because Swing is not flexible, so everytime you change a "page" you will need to redeploy the whole jar in the client machine. Ok, here is JavaFX to solve this, so there's no excuses now. :D
Look and Feel
If you say that the look and feel is a problem... think again, the pluggable look and feel of swing will let you change everything in an application, you could even put a look and feel just like Mac even if you work on windows.
Conclusion
Swing is a very powerful framework and you won't believe how easy is. This is a starter post in a series of articles about the uses of swing in a "serious" environments.
Thursday, March 27, 2008
Tuesday, March 18, 2008
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:
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.
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.
Wednesday, March 12, 2008
Two, Three, N-tier which one should I pick?
Jeff asked me (in the Post How to pass SCEA 5) about the following:
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)
- 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.
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)
Wednesday, March 5, 2008
How to pass SCEA 5
I'm MCP, SCJP, SCBCD and now SCEA 5, when I took the SCEA 5 Beta, I was wondering if this will be as difficult or easy as the other ones, and it was very interesting just because Beta means "you will not have any help on, nobody took this test before and you will have only your knowledge with you".
Because of this I started this blog, to share my experience in this test and let you know the key elements you must be aware to pass this out.
Certification description
The certification is compound by 3 parts.
1. The first part is a multi choice exam just like the others, it will test your knowledge about JEE and Design patterns
2. The assignation is the second part, you will get an assignation which will be similar to a real life assignation, this means that you will face it as a real application should be faced.
3. The third part is the easy one if you did the assignation, they will ask you about some common decisions made during design time, like Authentication, authorization issues, security, scalability, maintainability, and so on. This part will be evaluated as part of the assignation, so you will not have to wait to pass the second part in order to start this one.
General Advice
If you think you are ready to pass this test, just ask yourself:
- Did I worked enough with Case Use , Sequence Diagrams, Class Diagrams, Deployment Diagrams, etc? if the answer is no, go and take some practice on this, I'm pretty sure you will not pass it if you don't have some experience about these topics. (you don't need to be a guru)
- Did you architect some solutions? were they successful solutions? scalable, maintainable, etc?
Part 1
The first part is easy, you must know the following topics (these are from the java certification page):
Scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security. These are very important and will be asked through all the test, you will have problems like: "How can you add new customers and keep the availability?" or "If you add a new layer you will lose in security, reliability, scalability or manageability?" (those are not exactly the answers, I'm not able to put the real ones in here)
Security. You will be asked for firewalls, protocols, etc. Its easy if you read about it.
Tiers. You will be asked about the advantages and disadvantages about two tier, three tier, n-tier, client-server. Remember, not always the n-tier is the best option, imagine you have a simple hello world application, will you create this with ejbs, db etc? be sure to take a look of this new post Two, Three, N-tier which one should I pick?
Messaging. You need to know how the JMS works, you will be asked for this, that's sure.
EJB. this test will be easy if you know EJBs and you already worked with them, GOOD NEWS: YOU WILL NOT SEE CODE IN HERE, yes... you will be asked about the life cycle, advantages, when to use Stateless, Stateful, CMT, BMT, etc, questions like: "will you use persistence to save the data in a Stateless or Stateful bean?", so be sure you create almost any JEE component in a sample and be sure how it works.
Web Tier. Here is the tricky part, you will be asked for JSF, JSP, Servlets, and will be little bit difficult if you didn't develop a web page, so... go and open your netbeans (or Eclipse) and start working in these concepts. I'm not sure why they ask the details of this, but they will. You will not find answers like: "Find the error in here ...", but you will be asked how can you use those technologies to solve some problems.
Patterns. Ok, here is the core of the test, you need to know the patterns described in the Blueprints guide, also the ones in the GoF, etc. The test does not ask too many questions about patterns, but its sure you will find some of them.
In addition, you can find some questions referring to CORBA, RMI, etc, so be sure to understand every term. If you have any further questions about the questions please let me know in the comments, I will try to answer it keeping care of the test disclosure.
Second Part
Once you get the result of the first part you will be ready for the practice test, so how it works?
You will get an assignment which you will download from a page Sun gives you, this assignment is private and its very difficult that somebody have the same (I think they must have a hundred of different assignments, but I'm guessing).
The assignment is compound by a description and a sort of Case Use you must solve, as the real life assignments it has description, domain model, requirements, and Case Use and its possible they have some errors, your job as architect is to detect those and write it down in your assumptions, for example if you get an assignment to do a check in a system for a hotel and you see that the case of use says something like: "The customer could ask for the check" you could assume the check will be in dollars, in this way you will not have to do a currency conversion. Or you could find something like: "The cat eats the dog at breakfast", and you will say "What a hell?, I think this is wrong my assumption is somebody did a mistake in here and it must be 'the dog eats the cat...' "
You must read very carefully the assignment, go to the bathroom, take a shower and go back on it, read it again and try to be sure you understood all the requirements of the system, if you fail to detect a requirement you will fail the test. Use your imagination to figure out how the steps in the Case Use works and how will your system is going to address these.
You will need to provide Class Diagram, Component Diagram, Deployment Diagram and your assumption list, also you will need to provide the sequence or collaboration diagrams (this will not influence your score, but will be a good way to get the other diagrams). Also you will need to provide a list of the top three risks you detected and how you managed them.
While you are trying to figure out how to solve your problem keep in mind the following: Scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security. These are the key points in the test, if your system architecture could lead to a performance problems then you will need to address that in your design.
Remember, Sun is asking you for the architectural design, not the detailed design, so keep in mind that to avoid any unnecessary detail. How do you know if your design is too detailed, I think you should be able to explain your design to your team in a 30 minutes meeting, if you went in too much detail the designers will not have any work to do.
The third part
Ok, this is the easy one, you will be asked for some of the decisions made in the previous step, how did you address the security, the scalability, etc. What is the tricky part in here?, take a look of all the questions before begin, when I took it I tried to answer the best I can, so I put all that comes to my mind, then when I moved to the next question... puff... they are asking for something I already answered in the previous question (and you don't have the copy/cut/paste option), so I needed to move back remove the unnecessary answer in the previous one and rewrite it in the next. The time flew and I only had 5 minutes to do a full review. So, go and read all the questions before begin.
If you have any further questions please let me know in the comments section, I will try to do another blog with those questions and answers.
Because of this I started this blog, to share my experience in this test and let you know the key elements you must be aware to pass this out.
Certification description
The certification is compound by 3 parts.
1. The first part is a multi choice exam just like the others, it will test your knowledge about JEE and Design patterns
2. The assignation is the second part, you will get an assignation which will be similar to a real life assignation, this means that you will face it as a real application should be faced.
3. The third part is the easy one if you did the assignation, they will ask you about some common decisions made during design time, like Authentication, authorization issues, security, scalability, maintainability, and so on. This part will be evaluated as part of the assignation, so you will not have to wait to pass the second part in order to start this one.
General Advice
If you think you are ready to pass this test, just ask yourself:
- Did I worked enough with Case Use , Sequence Diagrams, Class Diagrams, Deployment Diagrams, etc? if the answer is no, go and take some practice on this, I'm pretty sure you will not pass it if you don't have some experience about these topics. (you don't need to be a guru)
- Did you architect some solutions? were they successful solutions? scalable, maintainable, etc?
Part 1
The first part is easy, you must know the following topics (these are from the java certification page):
Scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security. These are very important and will be asked through all the test, you will have problems like: "How can you add new customers and keep the availability?" or "If you add a new layer you will lose in security, reliability, scalability or manageability?" (those are not exactly the answers, I'm not able to put the real ones in here)
Security. You will be asked for firewalls, protocols, etc. Its easy if you read about it.
Tiers. You will be asked about the advantages and disadvantages about two tier, three tier, n-tier, client-server. Remember, not always the n-tier is the best option, imagine you have a simple hello world application, will you create this with ejbs, db etc? be sure to take a look of this new post Two, Three, N-tier which one should I pick?
Messaging. You need to know how the JMS works, you will be asked for this, that's sure.
EJB. this test will be easy if you know EJBs and you already worked with them, GOOD NEWS: YOU WILL NOT SEE CODE IN HERE, yes... you will be asked about the life cycle, advantages, when to use Stateless, Stateful, CMT, BMT, etc, questions like: "will you use persistence to save the data in a Stateless or Stateful bean?", so be sure you create almost any JEE component in a sample and be sure how it works.
Web Tier. Here is the tricky part, you will be asked for JSF, JSP, Servlets, and will be little bit difficult if you didn't develop a web page, so... go and open your netbeans (or Eclipse) and start working in these concepts. I'm not sure why they ask the details of this, but they will. You will not find answers like: "Find the error in here ...", but you will be asked how can you use those technologies to solve some problems.
Patterns. Ok, here is the core of the test, you need to know the patterns described in the Blueprints guide, also the ones in the GoF, etc. The test does not ask too many questions about patterns, but its sure you will find some of them.
In addition, you can find some questions referring to CORBA, RMI, etc, so be sure to understand every term. If you have any further questions about the questions please let me know in the comments, I will try to answer it keeping care of the test disclosure.
Second Part
Once you get the result of the first part you will be ready for the practice test, so how it works?
You will get an assignment which you will download from a page Sun gives you, this assignment is private and its very difficult that somebody have the same (I think they must have a hundred of different assignments, but I'm guessing).
The assignment is compound by a description and a sort of Case Use you must solve, as the real life assignments it has description, domain model, requirements, and Case Use and its possible they have some errors, your job as architect is to detect those and write it down in your assumptions, for example if you get an assignment to do a check in a system for a hotel and you see that the case of use says something like: "The customer could ask for the check" you could assume the check will be in dollars, in this way you will not have to do a currency conversion. Or you could find something like: "The cat eats the dog at breakfast", and you will say "What a hell?, I think this is wrong my assumption is somebody did a mistake in here and it must be 'the dog eats the cat...' "
You must read very carefully the assignment, go to the bathroom, take a shower and go back on it, read it again and try to be sure you understood all the requirements of the system, if you fail to detect a requirement you will fail the test. Use your imagination to figure out how the steps in the Case Use works and how will your system is going to address these.
You will need to provide Class Diagram, Component Diagram, Deployment Diagram and your assumption list, also you will need to provide the sequence or collaboration diagrams (this will not influence your score, but will be a good way to get the other diagrams). Also you will need to provide a list of the top three risks you detected and how you managed them.
While you are trying to figure out how to solve your problem keep in mind the following: Scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security. These are the key points in the test, if your system architecture could lead to a performance problems then you will need to address that in your design.
Remember, Sun is asking you for the architectural design, not the detailed design, so keep in mind that to avoid any unnecessary detail. How do you know if your design is too detailed, I think you should be able to explain your design to your team in a 30 minutes meeting, if you went in too much detail the designers will not have any work to do.
The third part
Ok, this is the easy one, you will be asked for some of the decisions made in the previous step, how did you address the security, the scalability, etc. What is the tricky part in here?, take a look of all the questions before begin, when I took it I tried to answer the best I can, so I put all that comes to my mind, then when I moved to the next question... puff... they are asking for something I already answered in the previous question (and you don't have the copy/cut/paste option), so I needed to move back remove the unnecessary answer in the previous one and rewrite it in the next. The time flew and I only had 5 minutes to do a full review. So, go and read all the questions before begin.
If you have any further questions please let me know in the comments section, I will try to do another blog with those questions and answers.
Subscribe to:
Posts (Atom)