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.
(→‎SOA and data Hibernization)
(See comment on discussion page)
Line 66: Line 66:
 
SOA architecture would require more server resource, but it would be easier to deploy using
 
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.
 
multiple cheap servers (or blades) instead of few expensive (redundant) servers.
−
 
−
===SOA and data Hibernization ===
 
−
 
−
The main advantages of SOA are interoperability and open standards that it heavily relies on and that are supported by ALL major IT players and software vendors. Web Service is the main SOA driving force and powerful engine that allows clients and services running on different platforms to exchange information by sending and receiving XML messages. The syntax of these messages is formally defined by XML schema (XSD). The operations that are used to send messages are formally defined by a WSDL. There are different methods of enforcing message level security (defined in WS-Security standards) as well as enforcing transport level security, which is specific to a transport used for message exchange (e.g. SSL, TLS, Basic Authentication, X.509 certificates).
 
−
 
−
SOA also brings new idea to software development process. It's not about sharing code anymore, it's about creating contracts (WSDL/XSD) and sharing services between clients running on different platforms. Client should not care about a platform where a service runs and vise versa (at least theoretically). If the goals of SOA are not violated by major players, it will eventually lead to service commodization and just like in case with other commodities the clients will simply choose them based on the price and quality only. Monopolizing this technology using an advantage or pervasiveness of any single service's platform will not be possible.
 
−
 
−
That's why SOA must be considered as yet another way of exposing business entities defined in Adempiere data model. Hibernate data model can be used as a facilitator to achieve this goal. Using HQL result set created by Hibernate as a list of Java object and XML serializers that can convert latter objects into XML entities is probably a way to go. You can find more details on further Adempiere data virtualization and exposing business entities through SOAP interfaces here:
 
−
 
−
http://gryb.info/soapiere/SoapiereWhitePapers.html
 
−
 
−
All artifacts found in "Downloads" section can be rather considered as prototypes of future Adempiere architecture and not as a productionalized solution.
 
  
 
===GUI===
 
===GUI===

Revision as of 03:15, 5 April 2007

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"