Hi,
If you are starting within JSF 2.0 technology, you will probably find this article very interesting: http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/
This new version of JSF spec. is already here (http://jcp.org/en/jsr/detail?id=314). Now it’s time to see how fast different vendors move to support this new exciting version witch, I guess, is the definitive push to this technology to become the most used view technology in JEE applications.
Regards.
Sometimes, one IT architect faces the challenge to choice between been conservative or been innovative when developing a new infrastructure. There is no good advice for all situations. As one “good” consultant would say: “It depends”.
This new drop tries to explain some of my thoughts when I have been in that situation.
Some pros and cons about them:
Conservative and reliable (well tested) system:
- Pros: One system stable, well tested. Minimum maintenance effort needed.
- Cons: It’s very difficult to introduce new requirements in a short time.
- Suitable for: Situations where maximum reliability is needed. Innovation is not such an important thing. IT is very strong and/business people is sympathetic whith IT.
Innovative and opportunistic:
- Pros: All the new technologies are there to fit every one’s needs
- Cons: Be the most innovative usually implies to be based on developments, frameworks and infrastructures not enough widely extended and tested.
- Suitable for: Innovation is the main goal. No matter the expense on maintenance costs it implies, you have to be there on that time.
As I said at the beginning, the correct choice depends of the situation. Someone has to define the strategy to follow and this has to be supported by the whole organization (every one has to know the game we are playing). If you are not able to do that, maybe your CEO/CIO should?
This post http://www.artima.com/forums/flat.jsp?forum=106&thread=238700 is one of the most pragmatic articles about Dependency Injection I have ever read. It’s very grateful to know that you are not alone in this world.
I recommend picking an eye to the whole article (it’s very short in fact), but the conclusion Ian wrote is the following:
“Despite the cosmetic differences between the Service Locator Pattern and Dependency Injection, the two are functionally quite similar. The biggest difference between them is not what can be accomplished, or even accomplished easily, but rather the style of programming that each requires. The Service Locator Pattern is a code-focused approach; when an instance of a service is needed, code explicitely calls out to a service locator to obtain it. In contrast, Dependency Injection is a more extralinguistic approach, providing clients their dependencies without any explicit action on the clients behalf.”
Thanks for everyting Ian. Very good post.
In the company I work for, we developed a custom framework for J2EE applications some years ago, when struts was the only serious candidate one in this world and it didn’t gave us all the functionality we needed. The main purpose of that custom-framework is to give an homogeneous architecture and development way for all the applications built by many external companies for us. Now, these times have changed and we think it’s time to re-think about that decision and the viability to keep on inverting time (and money) incorporating new features to it: AJAX support, EJB3, WS* support, new development utilities and so on.
The main pro of keeping our proprietary framework is taking the full control of the architecture and funcionalities provided: if you make something you can do anything you want. On the other hand, technology has evolved a lot on these years. There are many open source frameworks (Spring, Struts2, JBoss Seam, Tapestry, Wicket, Grails) with tons of capabilities built-in already. For these cases, only some development for specific components such our customized security system and that’s all. And these frameworks evolve themselves!!! I could write a long list of pro’s for adopting a standard .
On the other hand, I find it very difficult to make the correct bet for our “base-framework”. It was easier when Struts was “the one and only”, believe me.
I guess there is no silver bullet. I think it depends of the nature of the application to be built. It cannot be the same functionality required to make a complex application that must invoke WebServices exposed on a ESB following some conventions and standards compared to a simple CRUD app. In this case, you can think in a modular framework “choose-what-you-need” or even in different technologies and frameworks to support different needs.
What a hard job, don’t you think so?
Any comment will be appreciated.
I have been very busy doing my job (well, this is the reason I get paid for) and this blog has been abandoned for a while. A colleague of mine told me yesterday, thx Rober, “this is not serious” so today I have the purpose of following writing on a twitter mode in case of not having enough time to write a full article. Please, forgive me.
Well, landing this writing, one of my responsibilities at job is to define architectures an frameworks to develop, execute and monitor application on JEE environment. Because of that, I have been exploring about the possibilities of using Spring AOP on some points of our proprietary framework and have found this little treasure: http://www.infoq.com/articles/Simplifying-Enterprise-Apps
Incredible article about Aspect Oriented Programming. I suggest you to pick an eye!!
I have just read an article from “The Server Side” referring to a person making a review of RIA frameworks: http://www.theserverside.com/news/thread.tss?thread_id=50829 (the comments derived are more interesting than the article itself) . The most annoying thing about that review is that one article from that site, with so much influence in software industry, is only based on an opinion from a guy (Director, sorry) based on how much time it took to him to use the framework easily. Too brave for me, sure!!. I must agree that is a very interesting factor to keep in mind in order to evaluate the usage of one or another RIA framework, but not the most important one. At least in my opinion.
Framework
If you want to resolve one particular issue, you can think about a development of a fast (and frequently dirt) application in the scope of a project. Don’t consider the maintenance costs, upgrading, support of the framework and so on. These are the kind of issues a Service Provider is not used to consider, but the future owner of the application should to deal with once the developer has gone after finishing the project.
I think there are more important things one “architect” or “designer” of a company should consider. The previously mentioned about history and roadmap, support, experienced developers, integration with other frameworks and installed base are important points to keep in mind. Obviously easiness to use and user experience are key factors as well to help taking the right decision.
My advice is to make a table of key factors and, depending if the decision is for a particular control or a non-important application vs the future architecture for all the applications in the company, give different weights for each factor:
-
If the application is trivial or the usage of the RIA framework will be marginal, give more weight to the user experience and easiness to use.
-
On the other side, if the RIA framework will be an “implementation reference” for the future applications, take other things in mind. Considering the support, base installed and so on will be crucial.
I wish it helps.
Ciao!!
