Difference between revisions of "The Adempiere Next Generation (TANG)"

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.
(See comment on discussion page)
(Total rewrite of this page.)
Line 1: Line 1:
==Introduction==
+
=Introduction=
  
At first scope and goal of TANG project seemed quite clear. After little exploration
+
I have been part of Adempiere community since November 2006. I did not have
I found out that defining scope of the TANG project is not that simple.
+
any Compiere experience when I join in. Since day one I have been impressed
 +
about the amount of knowledge in this bazaar. Real power of the Adempiere is
 +
in community which shares ideas and information.
  
There is lot of new technologies (as always) which TANG should support in
+
Adempiere has great set of features things under the hood does not
future. So I have spent couple months reading specs and recommendations from
+
look equally impressive for new developers joining in.  
JCP and W3C. I have also briefly evaluated non 'standard' features that
+
J2EE containers offer.
+
  
==Main problems to solve==
+
Because Compiere were pioneer of its time it had to make own implementations
 +
for object-relational mapping, dynamic user interface, authorization,
 +
transaction management, business process management and many others.
 +
Today we have many open source implementation for those needs.
 +
Debugging, maintaining and developing own implementations of those core
 +
services is slowing down the development and making learning curve steeper for
 +
new developers.
  
While thinking about scope of the TANG I listed these problems with
+
=Birth of Tang project=
current Adempiere structure:
+
  
*Only 2 layers
+
In December 2006 I read many books about history and ideology of the Open Source
*Bad security
+
movement. One thing kept popping up all the time: Most successful OS projects
*Steep learning curve for new developers since so few common API's are used.
+
have very modular structure. Those successful OS projects that do not have
*Steep learning curve for administrators because of odd structure.
+
modular structure are so small that can be maintained by small group of people.
*All customization data is in database (AD tables) and that makes comparing and documenting changes difficult.
+
*Multiple "clients" in same database.
+
*In practice running multiple "clients" on same server is difficult.
+
*No good way of making modules/plugins.
+
*Proprietary way of describing GUI
+
*No support for standards.
+
*Bad persistence engine
+
*Bad transaction handling
+
*Too much code to maintain. Adempiere should focus on business logic and try to use more existing tools (persistence, transactions, workflows).
+
  
When developer tries to study Adempiere he cannot use his previous knowledge since so many things are done in proprietary way.
+
Since Compiere is mainly made by two people it had no need for modularity.
 +
Later on when Compiere grew up others were willing to contribute more, but
 +
core developers were too afraid that other contributors would destabilize
 +
the code. In a way lack of modularity made Adempiere to exists.
  
==Possible solutions==
+
I think that modularity of the OS software has four dimensions:
  
===Persistence===
+
;Technical:
 +
:Modularity allows development of new features without destabilizing the whole structure.
  
JPA (jsr220) is surely the way to go, but should we support multiple providers?
+
;Psychological:
Hibernate has tempting proprietary extensions. Also there is no common way
+
:It is easier to join the project and start contributing when something useful
of describing cache policies or query hinting.
+
:can be submitted without thorough knowledge of the whole code base.
  
Main problem in JPA is that adding new columns/tables requires always recompiling
+
;Social:
affected Java entity classes.
+
:Modularity allows development of the controversial features without flamewars.
 +
:Also community members which have difficulties to get along with each other
 +
:can work in same projects without constant conflicts.
  
===Business logic===
+
;Financial:
 +
:Modular software provides more business models for companies around the
 +
:core project. Customizing and maintaining proprietary extension is cheaper
 +
:with modular structure.
  
EJB3 is big improvement after EJB2.1 and solves many AOP (aspect oriented programming) needs.
 
EJB3 seems to be silver bullet for solving plugin/module problems.
 
  
Problematic areas are workflow engine, rules engine and ESB (Enterprise service bus). Although there is
+
Before Christmas 2006 I became aware of some security issues
commonly supported standards like BPEL and JBI (jsr208) those does not provide enough features. Good
+
[http://sourceforge.net/tracker/?group_id=176962&atid=879332] in
proprietary solutions exists in JBOSS, Glassfish and Geronimo but supporting all
+
the Adempiere. I started to think that maybe revolution would be better
would be tricky.
+
and less frustrating way than evolution.
 +
I decided to raise some waves [http://sourceforge.net/forum/message.php?msg_id=4064042]
 +
using my skills of being polite and diplomatic.
  
Choosing one platform can make development process lot easier, but involves risks.
+
=What has happened so far=
  
===SOA or not to SOA ? ===
+
At beginning of year 2007 I got subversion branch and mailing list for TANG.
 +
Original plan were just take current code and modify it to use Hibernate
 +
persistence, JTA transactions, EJB3 session beans, and webservices.
 +
I was planning to just sit down and start coding.
  
Service oriented architecture is latest hype in enterprise application field. Should TANG's internal
+
Soon it became evident that just replicating current structure with new
structure follow SOA principles or is providing WebServices for integration purposes enough ?
+
libraries is not going to be enough. We need to be prepared for handling
 +
fast growing and diverse community without constant arguments about
 +
which direction Adempiere is moving.
  
Once again nice proprietary ESB solutions exists, but no mature widely implemented standards.
+
So I end up spending three months just reading different JSR's, W3C
 +
recommendations, and documentations of different OS products. During that
 +
time I did got many good suggestion from others. Typical pattern were
 +
that I first turned those suggestions down in very impolite way. Just
 +
to find out couple weeks later that I had been totally wrong.
  
SOA seems to be also choose between ease of customization and flexibility. SOA application would
+
Many times during those three months I have formed strong opinions about
be really flexible, but managing / customizing SOA (even with graphical tools) requires quite
+
which is the right way to proceed. And usually those opinions have
a lot knowledge (http, wsdl, xslt, xml-schema, SOAP ...).
+
conflicted with each other. At least two times I decided to give
 +
up the whole TANG thing.
  
SOA architecture would require more server resource, but it would be easier to deploy using
+
Finally after three months of brainstorming I thought (once again)
multiple cheap servers (or blades) instead of few expensive (redundant) servers.
+
that now I have good picture of what Tang is going to look a like.
 +
I finally started to document my ideas (should done that for long
 +
time ago) under topic: [[Tang Berlin 2007 Proposal]]. I was happy
 +
about myself until I were forced (by Hengsin and Colin) to take
 +
better look at Osgi.
  
===GUI===
+
Osgi seems to be the final piece that makes TANG to be mostly collection
 +
of java POJO classes and xml files. I were also forced to review my
 +
stance to Spring Framework since it provides Osgi out of the box.
  
Since both rich and thin clients are going to be needed (and maybe thin mobile client also).
+
=What next ?=
Easy to customize GUI description language which has ready made implementations on many
+
platforms would be good. I tried to find xml based gui description languages which would suit
+
for Adempiere and would have support both thin and fat clients.
+
  
Only one I could find is W3C's xforms recommendation. There is many different kind of implementations
+
I will rewrite my Berlin proposal to include Osgi and Spring framework.
for it: http://www.w3.org/MarkUp/Forms/#implementations . Most interesting ones are mozilla and chiba project.
+
There surely will be some discussion about proposal on irc, tang mailing
 +
list and wiki talk pages. In Berlin I will have discussions with
 +
people attending if TANG could become 'official' roadmap for Adempiere
 +
long term development.
  
And mixing svg and xforms gives huge UI design possibilities. (more about this topic later)
+
Many Adempiere developers would like to proceed by taking small steps
 +
with current code base instead of total rewrite. Truth is that
 +
nobody knows for sure which way is better. But maybe we could learn
 +
something about Mozilla / Firefox case. Old Mozilla is still developed
 +
and many people use it. Writing Firefox from scratch were long and painful
 +
process but it did not matter so much since people could use Mozilla at
 +
mean time.
  
But will XFORMS mature soon enough ?
+
People developing current trunk would not have to worry about radical
 +
changes since TANG would be on its way. We could keep stable version
 +
really stable and not to try modify it to use JPA or session beans.
 +
And those companies that do not need new features in TANG can continue
 +
using current branch years from now.
  
==What is going on==
+
=Joining/Contributing=
  
I have give up hope finding way to implement workflows portable way. So it seems we have to choose
+
If you think that you could fit in subscribe adempiere-tang mailing list
between Sun microsystems and RedHat (I tried *hard* to avoid that). JBI is one solution but not ready yet.
+
[[http://sourceforge.net/mail/?group_id=176962]] and introduce yourself.
I would choose Sun and GlassFish since JBoss usually tries to be SUN compatible. If we take SUN road we
+
might find out that our solution runs on JBOSS's future releases. But if we choose Jboss (which has maybe
+
better technology stack) it will never be compatible with any other platform (many jboss modules can run
+
inside other servers though).
+
 
+
While server issue is open I try to make up POC using xforms.
+
 
+
==Forum entries==
+
These threads on Adempiere forums started TANG:
+
 
+
*http://sourceforge.net/forum/forum.php?thread_id=1634218&forum_id=610548
+
*http://sourceforge.net/forum/forum.php?thread_id=1634982&forum_id=610548
+
*http://sourceforge.net/forum/forum.php?thread_id=1634243&forum_id=610548
+
*http://sourceforge.net/forum/forum.php?thread_id=1635191&forum_id=610546
+
 
+
==Joining/Contributing==
+
 
+
If you think that you could fit in subscribe adempiere-tang mailinglist and introduce yourself:
+
http://sourceforge.net/mail/?group_id=176962
+
  
 
There is plenty of work to do.
 
There is plenty of work to do.
  
--[[User:Kontro|kontro]] 03:56, 15 March 2007 (EDT)
+
=Technical stuff=
  
==See Also==
+
See: [[Tang Berlin 2007 Proposal]] -  
*[[Tang Berlin 2007 Proposal]] - an expose that requires more minds than coders at the moment, so please participate - [[User:Red1|Red1]]
+
*[[TANG AD Manager]]
+
*[[TANG Service]]
+
*[[TANG Module Repository]]
+
*[[TANG Module]]
+
*[[TANG Component Interface]]
+
*[[TANG Instance]]
+
  
 +
----
 +
--[[User:Kontro|kontro]] 17:14, 6 April 2007 (EDT)
  
[[Category:Projects]]
+
[[Category:TANG]]
[[Category:Development]]
+

Revision as of 14:14, 6 April 2007

Introduction

I have been part of Adempiere community since November 2006. I did not have any Compiere experience when I join in. Since day one I have been impressed about the amount of knowledge in this bazaar. Real power of the Adempiere is in community which shares ideas and information.

Adempiere has great set of features things under the hood does not look equally impressive for new developers joining in.

Because Compiere were pioneer of its time it had to make own implementations for object-relational mapping, dynamic user interface, authorization, transaction management, business process management and many others. Today we have many open source implementation for those needs. Debugging, maintaining and developing own implementations of those core services is slowing down the development and making learning curve steeper for new developers.

Birth of Tang project

In December 2006 I read many books about history and ideology of the Open Source movement. One thing kept popping up all the time: Most successful OS projects have very modular structure. Those successful OS projects that do not have modular structure are so small that can be maintained by small group of people.

Since Compiere is mainly made by two people it had no need for modularity. Later on when Compiere grew up others were willing to contribute more, but core developers were too afraid that other contributors would destabilize the code. In a way lack of modularity made Adempiere to exists.

I think that modularity of the OS software has four dimensions:

Technical
Modularity allows development of new features without destabilizing the whole structure.
Psychological
It is easier to join the project and start contributing when something useful
can be submitted without thorough knowledge of the whole code base.
Social
Modularity allows development of the controversial features without flamewars.
Also community members which have difficulties to get along with each other
can work in same projects without constant conflicts.
Financial
Modular software provides more business models for companies around the
core project. Customizing and maintaining proprietary extension is cheaper
with modular structure.


Before Christmas 2006 I became aware of some security issues [1] in the Adempiere. I started to think that maybe revolution would be better and less frustrating way than evolution. I decided to raise some waves [2] using my skills of being polite and diplomatic.

What has happened so far

At beginning of year 2007 I got subversion branch and mailing list for TANG. Original plan were just take current code and modify it to use Hibernate persistence, JTA transactions, EJB3 session beans, and webservices. I was planning to just sit down and start coding.

Soon it became evident that just replicating current structure with new libraries is not going to be enough. We need to be prepared for handling fast growing and diverse community without constant arguments about which direction Adempiere is moving.

So I end up spending three months just reading different JSR's, W3C recommendations, and documentations of different OS products. During that time I did got many good suggestion from others. Typical pattern were that I first turned those suggestions down in very impolite way. Just to find out couple weeks later that I had been totally wrong.

Many times during those three months I have formed strong opinions about which is the right way to proceed. And usually those opinions have conflicted with each other. At least two times I decided to give up the whole TANG thing.

Finally after three months of brainstorming I thought (once again) that now I have good picture of what Tang is going to look a like. I finally started to document my ideas (should done that for long time ago) under topic: Tang Berlin 2007 Proposal. I was happy about myself until I were forced (by Hengsin and Colin) to take better look at Osgi.

Osgi seems to be the final piece that makes TANG to be mostly collection of java POJO classes and xml files. I were also forced to review my stance to Spring Framework since it provides Osgi out of the box.

What next ?

I will rewrite my Berlin proposal to include Osgi and Spring framework. There surely will be some discussion about proposal on irc, tang mailing list and wiki talk pages. In Berlin I will have discussions with people attending if TANG could become 'official' roadmap for Adempiere long term development.

Many Adempiere developers would like to proceed by taking small steps with current code base instead of total rewrite. Truth is that nobody knows for sure which way is better. But maybe we could learn something about Mozilla / Firefox case. Old Mozilla is still developed and many people use it. Writing Firefox from scratch were long and painful process but it did not matter so much since people could use Mozilla at mean time.

People developing current trunk would not have to worry about radical changes since TANG would be on its way. We could keep stable version really stable and not to try modify it to use JPA or session beans. And those companies that do not need new features in TANG can continue using current branch years from now.

Joining/Contributing

If you think that you could fit in subscribe adempiere-tang mailing list [[3]] and introduce yourself.

There is plenty of work to do.

Technical stuff

See: Tang Berlin 2007 Proposal -


--kontro 17:14, 6 April 2007 (EDT)