The Foundation of Enterprise Java Frameworks
The Foundation of Enterprise Java Frameworks
Join the DZone community and get the full member experience.Join For Free
Atomist automates your software deliver experience. It's how modern teams deliver modern software.
Frameworks became one of the hottest topics in Java community. Then, Microsoft adopted a similar development architecture and later the .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 the Java Framework boom starter was EJB. Issues with EJBs lead to a new effort 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, the standard body changed its own standards and started adopting these library technologies like Hibernate.
Frameworks provided many useful utilities, eased software abstraction and layering, providing the 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):
The Application Framework contains functions and API’s for enterprise applications. These frameworks provide a run-time (like a 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 frameworks, such as 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 making integration more difficult.
A Messaging Framework enables communication between different process or servers in either a 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.
Reporting is the presentation of data for printing or publishing purposes. Reporting frameworks provide 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.
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.
All Frameworks have following aspects:
1- API: Every framework provides API’s. Maturity and simplicity of these API's are very important. There are many other characteristics of a good API which will be held within another blog post. Frameworks are tightly-coupled application blocks and an API is the 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, a developer's 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 boost developer productivity by encapsulating functions and dividing expertise. 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.
Published at DZone with permission of Adam Brown . See the original article here.
Opinions expressed by DZone contributors are their own.