How it all works
ercatons are the result of the ercato project
to create a server environment which does not just export
web services but is actually fully programmable using web
services. In this context, many shortcomings of web services
have been addressed and a decent security model has been created,
to start with.
Keep the J2EE model
small and focused
In all traditional J2EE frameworks and J2EE
itself, XML plays a helper role, as carrier of data from model
to view, or from one application to another, or as a configuration
language. In contrast, ercatoJ treats XML as what it is: a
first class citizen. It is the first and only J2EE-based product
which does so: XML documents contain and store all the business
data plus as much business logic as is required.
But why is the ercato programming model that powerful? Because
it exactly starts from the simple idea we mentioned above:
treat every XML document as being an object (and call it an
ercaton). Inheritance, polymorphism, encapsulation, persistence,
methods, appearance etc. may all be expressed at the declarative
level of XML. This includes some properties of real-world
objects which software objects usually do not posses. Additionally,
the full procedural power of Java and J2EE is made available
as well.
Did you ever wonder why you should care about the distinction
between object and class when creating an UML business model?
ercatons make this distinction obsolete and in many cases,
an ercaton just is the perfect representation of a business
object or process. On the other hand, an ercaton looks as
much as a Java object to Java code as you want it. There is
nothing to sacrifice.
Consider the following scenario: “In some application,
customer data is expressed as an XML document with actually
no Java involved. At the same time, a customer’s account
is expressed as an entity bean delegating to an account class.
Both, customer and account have been modelled as objects (ercaton
and Java class).” We anticipate and fully support this
situation. Of course, an SQL database will be involved, too.
For maximum freedom, ercatoJ does not restrict ercatons to
any XML schema (or XML at all...) and any Java class is able
to interoperate. It is not very elegant but perfectly legal
for some Java code to manipulate an ercaton at the XML-DOM
level.
Every XML document is
an object
ercatons represent business data and business logic at the
XML level. This may have introduced problems at the levels
of orthogonality and redundancy, change management, or consistency.
Yes, and ercatoJ solves all of them.
It is impossible in this booklet to discuss the background
of prototype-based languages or XML node-set algebra which
are part of the scientific foundation of the ercato programming
model. Rather, we just claim the following here: “Once
an example of a business object or a description of a business
process is written down (in XML, maybe using a text editor),
the implementation of this object or process as part of a
J2EE application is already complete or very close to completion”.
You probably need to see to believe.
|
