J2EE problems solved
If J2EE is an operating
system, then ercatons add to it what the many small /usr/bin
binaries add to Unix: power and simplicity
J2EE is the best standardized application
server architecture available. Still it has problems which
can be addressed using ercatoJ:
The J2EE blueprints assume that all relevant details of
the business model (as expressed at an UML level) are implemented
as EJBs and that retrievable business data maps to persistent
attributes.
This assumption is fine for a project following the waterfall
model: every detail is designed first, then implemented.
However, many successful projects follow the model of the
Agile Process: start with a simple system and iterate until
the project goal is reached. Such projects are left with two
alternatives:
1. Frequently refactor the entire J2EE
model
2. Let the J2EE model contain “generic
parts”
The first leads to overly complex projects
because even a simple change is a tedious and error-prone
procedure. Some changes are close to impossible after the
application went productive.
The second alternative leads to projects where most of the
time is spent to create or use a technical framework to handle
the genericity: the initial business model moves out of focus.
Both, J2EE frameworks and J2EE-aware IDEs only push the
limit a bit without eliminating it.
Therefore, in the typical large-scale J2EE project, most of
the time is spent “to integrate, redeploy and address
technical issues”.
ercatoJ offers a way out by proposing a third option:
3. Keep the J2EE model small and focused.
Fig.1 ercatoJ is entirely based on J2EE and is able
to cooperate with
J2EE-based applications or frameworks -- or to hide J2EE details
where appropriate.
ercatoJ may interface itself to subsystems such as SAP/R3
using any
XML-based exchange protocol.
|
