Tuesday, November 11, 2008

Foundation of Enterprise Java Frameworks

Frameworks became one of the hottest topics in Java community. Then, Microsoft adopted similar development architecture and later .Net platform was born (MS Enterprise Library). I am not going to describe what the framework is but try to frame the framework libraries. I think Java Framework boom starter was EJB. EJB problems lead to new seeking to find simpler and better alternatives. ORM libraries solved many problems of EJB while staying outside of the Java standard body. As time goes on, standard body changed its standards adopting these library technologies like Hibernate.

Frameworks provided many useful utilities and eased software abstraction and layering providing best practices of design patterns.

First of all, let me classify enterprise Java frameworks describing their functions (I think these are fundamental blocks and every enterprise application needs these frameworks):

1- Application Framework: Application framework contains functions and API’s for enterprise applications. These frameworks provide a run-time (like VM) for applications and hide the details of some services and functions. There are 3 main functions; User interface (View), server interaction-business logic execution (Controller) and persistence (Model). Some of them are complete application framework like MVC frameworks whereas some provides functions only for one aspect of application like UI, persistence or controller. It is very hard to find a complete and fully-fledged application framework. Today these functions are scattered to many frameworks thus hardening integration.

2- Messaging Framework: Messaging framework enables to communicate different process or servers in synchronous or asynchronous way with tightly or loosely-coupled manner. RMI and JMS are examples in Java. Depending on requirements, RMI or JMS could be used. JMS needs an implementation library as well. ESB (Enterprise Service Bus) is just a new acronym for this framework type. Web services and EDI (Electronic Data Interchange) can run with this framework functions.

3- Reporting Framework: Reporting is laying out the data for printing or publishing purposes. Reporting frameworks provides layout arrangement, paging and printing to different printers with different document formats. There are many open-source or commercial reporting frameworks with different capabilities. Many of them developed their own proprietary report writing script languages and XML formats with an API set.

4- Utility Framework: There are some special needs like XML parsing, String manipulation, source code generation, etc. These requirements are met by utility frameworks. A well-known example is Apache Commons.

Frameworks have following aspects:
1- API: Every framework provides API’s. Maturity and simplicity of these API are very important. There are many other characteristics of good API which will be held within another blog post. Frameworks are tightly-coupled application blocks. API is glue of these blocks. API is the most important aspect of frameworks which determines success.

2- Tools: Frameworks must be supported with tools. Sometimes frameworks are not usable in the absence of good tools. Tools depend on frameworks, any major code and API change brings many pains to tool writers. Tool support is one of the drawbacks of framework writers since no time remains from framework development jobs. One of the tooling misunderstandings is IDE dependency. Tools don’t necessarily require an IDE, for example code generators can be independent applications.

3- Run-time Management: Frameworks haven’t come to this level yet. I see only a few JMX support but this is not enough. On the other hand, JMX support is very hard for framework developers (Only Application Servers could use JMX). This job is left to profiler vendors but profiling in a production system is nearly impossible. Which job is running using which object through which connection can’t be answered in a running system, I haven’t encountered such tool yet. Session inspection, thread management and connection pool management do still not exist.

4- Standards: With so many options, developer toolbox is flooded with frameworks. Keeping standards and consistency across developer ecosystem is another important issue. If frameworks are utilized with careful planning, we can build and keep standards across programs and projects. Otherwise unmanaged development environment will be costly.

Frameworks boosted developer productivity by encapsulating functions and dividing expertise zone. Framework selection is a key part of any development project. Frameworks should be evaluated very carefully with the above aspects. In some circumstances, “Build” decision may be taken if we have enough resources (time, expertise). This was our case and eventually our libraries matured meeting ERP application expectations. Our frameworks turned out to be an Application Operating System (AOS) for web applications.

No comments: