The Adempiere Next Generation (TANG)

From ADempiere
Revision as of 03:15, 5 April 2007 by Kontro (Talk) (See comment on discussion page)

Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

Introduction

At first scope and goal of TANG project seemed quite clear. After little exploration I found out that defining scope of the TANG project is not that simple.

There is lot of new technologies (as always) which TANG should support in future. So I have spent couple months reading specs and recommendations from JCP and W3C. I have also briefly evaluated non 'standard' features that J2EE containers offer.

Main problems to solve

While thinking about scope of the TANG I listed these problems with current Adempiere structure:

  • Only 2 layers
  • Bad security
  • Steep learning curve for new developers since so few common API's are used.
  • Steep learning curve for administrators because of odd structure.
  • 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.

Possible solutions

Persistence

JPA (jsr220) is surely the way to go, but should we support multiple providers? Hibernate has tempting proprietary extensions. Also there is no common way of describing cache policies or query hinting.

Main problem in JPA is that adding new columns/tables requires always recompiling affected Java entity classes.

Business logic

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 commonly supported standards like BPEL and JBI (jsr208) those does not provide enough features. Good proprietary solutions exists in JBOSS, Glassfish and Geronimo but supporting all would be tricky.

Choosing one platform can make development process lot easier, but involves risks.

SOA or not to SOA ?

Service oriented architecture is latest hype in enterprise application field. Should TANG's internal structure follow SOA principles or is providing WebServices for integration purposes enough ?

Once again nice proprietary ESB solutions exists, but no mature widely implemented standards.

SOA seems to be also choose between ease of customization and flexibility. SOA application would be really flexible, but managing / customizing SOA (even with graphical tools) requires quite a lot knowledge (http, wsdl, xslt, xml-schema, SOAP ...).

SOA architecture would require more server resource, but it would be easier to deploy using multiple cheap servers (or blades) instead of few expensive (redundant) servers.

GUI

Since both rich and thin clients are going to be needed (and maybe thin mobile client also). 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 for it: http://www.w3.org/MarkUp/Forms/#implementations . Most interesting ones are mozilla and chiba project.

And mixing svg and xforms gives huge UI design possibilities. (more about this topic later)

But will XFORMS mature soon enough ?

What is going on

I have give up hope finding way to implement workflows portable way. So it seems we have to choose between Sun microsystems and RedHat (I tried *hard* to avoid that). JBI is one solution but not ready yet. 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:

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.

--kontro 03:56, 15 March 2007 (EDT)

See Also

Retrieved from "http://www.adempiere.com/index.php5?title=The_Adempiere_Next_Generation_(TANG)&oldid=29124"