Java EE Simplification Project For Simplicity, Productivity, Agility and Cost Reduction

We’ve been working on a project that will yield a product to simplify Java EE web development. Java EE 5’s leading principle was to simplify Java EE development. Simplifying EJB usage and adding some language features were an important step but there is more to do. Most of the difficulties for Java EE is about too many specifications and complexity of the technologies. To develop a software application with only pure Java EE technologies is today a costly option in terms of complexity. In fact complexity source is not only Java EE. Add web technologies to that list. A standard web developer should have many facets in addition to Java EE knowledge fighting on many fronts; JavaScript, CSS, SQL, XML, AppServers, HTTP Servers, DBMSs, IDEs, Tools etc. Most of the software teams embraced open source libraries to cure this complexity problem. We developed an ERP application with our development platform and we are getting ready to release this full-scale enterprise platform to ease enterprise web development. In this post, I am going to give you details about our ongoing project and our motivations to prepare such a platform.

This is a very fresh start. This is a solution in Java EE space but not built with only standard Java EE technologies. Our approach is pragmatic and what Java technologies we used are just according to common sense. We are trying to find a middle path in Java EE space. I think Java EE simplification will not be with a new language that is popular recently. Java simplification would be possible with API simplification and powerful tools. Instead of a new language, we aim to provide simplicity with a full-scale API set ranging from utilities to persistence with an integrated approach (Integrated Development Frameworks).

Simplicity Motivations

1- Current Java EE API Depth & Vast Web Technologies: There are numerous low-level APIs in Java language and that is a real drawback for entry-level programmers. Teams are built with senior and junior programmers. A development platform should be learned and used with senior programmers with high knowledge level. But in Java space, even many senior programmers still can not cover the details of standard technologies. A classic example for web development is lack of JavaScript knowledge. For that reason, web project teams are not agile enough to provide fast solutions that lead to cost reduction. Today, everybody knows the meaning of the cost in current economic climate.

2- Open Source Integration and Maturity Problems: Companies that are providing Java solutions and complaining about Java complexity problem usually embraced lightweight solutions which exist only in open source world (Java vendors couldn’t support these solutions because they are selling Java EE certified solutions and this is going to be conflicted with their current policy). Open source solutions come with their own problems (I mentioned in an earlier post). As they get attention from developers their lightweight solutions improved and turned into another heavy giant software stack. Library dependencies are a new nightmare to be solved in open source solutions which is one of the main integration problems. What is needed is simple, a new fresh start that adheres some Java web standards and don’t have zillions of dependencies.

3- We don’t Need a New Language for Simplicity: We don’t need a new language for simplicity, why? Current API granularity is good enough for an enterprise level programming. I analyzed many ERP domain language (i.e. ABAP, X++) but they generally lacks low-level access that what they want to hide. They are proprietary and require a new learning curve. I think Java language is good enough if a successful API simplification is done. Many developers are pondering over learning a new scripting dynamic language to simplify development but I believe that is not going to simplify development as wanted. Those languages may be used only in small web projects. As scale increase, their scripting capabilities would not meet requirements. One of the API approach advantages is the ease of switching to Java normal APIs if needed. For example, our file system APIs may not suit a special need and at that time, it is very easy to use Java’s own API set.

4- Agile Development: Today, we need fast solutions. Speed is only possible if we craft the solution easily. Development time reduction is not enough. Speed begins with requirement analysis and lies to post-production. We have to focus on total-time reduction covering all phases. Some platforms may provide to build software speedily but maintenance may be very hard or may require more time thus diminishing total gain. Total agility should be targeted.

Simplification Elements

We are trying to achieve Java EE simplification by following elements:
1- Simplified High-Level APIs with Frameworks: Our platform contains base development frameworks; application, reporting and messaging frameworks. I’ve already mentioned the details of our frameworks in my previous posts by explaining their architecture. We are targeting “Enterprise Web Development”. We are not writing an application server or IDE or database. We’ve developed application service APIs by eliminating details of many enterprise level problems. What is a simplified development API? We aimed to be used by average programmer without any problem or fuss. In our early ERP development phase we had former-IT members those were not software engineers and they today become Java developers. We always considered their COBOL-based background and wanted to make them Java developers with a very minimal Java education. A very interesting story is that a non-programmer IT member began to write applications within our simplified enterprise development environment. On the other side, software engineers complain about short learning curve.

We make simple development services for following areas:
Persistence Framework: We developed a very flexible and simple persistence framework to use. It is used as a transaction engine for our current ERP. We wrote ORM library even before many open source emerged. We tried to achieve the items mentioned in my criticism of persistence framework post.

Web Framework: We developed a web framework to develop web applications easily. It contains the elements of a standard web framework with integration advantage with persistence framework. It contains the features which I mentioned in better Java web framework post.

Messaging Framework: We wrote a simplified API set to make messaging-oriented programming easy. I mentioned about it in an early post.

Reporting Framework: We wrote a simplified API to develop reports in Java. It has many features that I also mentioned about it in an early post.

Followings are some services provided by our Application frameworks:
Connection Cache
Logging
Database Change Logging
Data Caching
Session Tracking
Locking
Profile Management
Scheduling
Batched Tasks
Resource Management
Replication
Distributed Query
Portal APIs
Identity Generation
Simplified Email API
Simplified File System API
Adapter API
Authorization Service
Authentication Service
Encryption Service
Clustering
Simplified Localization
Customization and Extension APIs
Rule Engine
Workflow Engine
Metadata Management
Mobile Support
JavaScript Library for Rich Web Applications (Many AJAX-enabled web components I mentioned in previous posts)

2- Development Tools: We developed some MDA tools that facilitate code generation. To develop a CRUD application is just in minutes, believe me. These tools are not dependent on any IDE and works as a web application. Generated codes are touchable codes and can be altered and not encryptic codes to comprehend. Simplification is possible with tools and even if your APIs are simple, this is not enough. Tools boost productivity a lot. Agile development and easy prototyping is possible with development tools.

3- ALM Tools: ALM is going to be popular in coming years as Oracle and other vendors invest more on this field. This is a natural step for software vendors because ALM means automation. Every software company needs an application set to manage their processes. These applications repeatedly developed in every software organization, remember; bug-feature tracking software, run-time management, user management, version management, license management etc. We developed many ALM modules easy to use and ready to use and integrated with development frameworks. These modules complete the simplification goal.

We are Seeking Investor Partners
Our project continues, we are the last phases to release our product (planning to release in early months of 2010). We are also working to package our in-house ERP to sell as a new ERP product. What we aim is to introduce 2 products; one is an application platform I detailed here, second is a web-based ERP product based on the application platform. This is a very unique strategy. Many ERP vendors tried to sell their ERP development platform but that was not possible without an accompanying ERP sales. They maybe didn’t have the vision to sell their platform at the beginning and always had a proprietary locked-in architecture.

We are open to hear from serious investors that are big enough to support our team and strategies. We may make some kind of partnerships if an agreement is established. Branding may be done through new partner since we are not an IT company yet. If we don’t find any partner, we are going to begin in domestic market alone.

Our projects resembles IBM’s former San Francisco project with one distinguishing difference, we’ve already developed a big ERP system using this platform and our platform already verified itself. Our platform is not dependent to the ERP system and can be independently used to develop any enterprise application. Let’s make it true that “Java is new COBOL” by powering enterprise Java projects.