ADempiere has been ported to IBM i Operating System and IBM WebSphere Application Server. This port was done by Grant Quick, a student at the University of Technology, Sydney in collaboration with the IBM Innovation Centre for Business Partners. Grant Quick has put up his paper on his findings on his website.
ADempiere is the leading open source Enterprise Resource Planning (ERP) tool. These are enterprise-wide tools that orchestrate the operations of a business. An ERP can come with tools for generating financial reports, managing inventory, analysing the performance of employees, sharing information with other companies, etc. When wielded correctly, these things have the opportunity to drive an organisation’s efficiency. Imagine the waste, excess work and lost time you could save if your organisation could manage, schedule and negotiate transactions with other organisations seamlessly.
In the ERP field, ADempiere is particularly interesting because it is open source. That means that developers, enterprises, system integrators, anyone and everyone can take it free of charge and make their own modifications to it. Consultants can create consulting practices by offering “Design, Build, Operate” services. Trainers can develop courseware and train users how to use it, consultants how to consult with it, government officials to interpret its data.
Skip forward to page 63 and you find this gem …
Whilst the current OSGi developments will make it significantly easier to integrate new plugins with the core product, it will still leave a lot of work to be completed if the decision is made to create an SOA. The entire application suite would need to be restructured so that useful services could be externally exposed to other applications and swapped out for components supplied by other vendors. This would be a large undertaking and require the support of the whole community. Although OSGi may be used for the backbone of an SOA implementation, it may prove beneficial to use a more extensive and flexible framework such as J2EE. Since an architectural overhaul is scheduled for version 4.1 of ADempiere, discussion on adopting an SOA needs to begin in the community soon.I think transitioning to a SOA model could enhance ADempiere in versions to come. Here’s looking forward to 4.1!
This port is significant because ADempiere comes with the JBoss application server. This work makes ADempiere a lot more appealing to organisations that already have an existing IBM WebSphere application server infrastructure and would like to make use of that instead of implementing separate JBoss application servers for ADempiere. I feel that one of the characteristics of robust software is whether it is portable, and ported to a variety of platforms.
The paper touches on a key problem of ADempiere – which is database dependence. Right now ADempiere depends on PostgreSQL and Oracle RDBMSes, and doesn’t talk very well with other database platforms. ADempiere may find some difficulty penetrating into the market segment that has already chosen MySQL as their RDBMS, because implementing ADempiere would mean that enterprises would have to add another platform to their enterprise systems. Economies of scale rules, and having all your systems run on a robust enterprise RDBMS pays dividends.
Grant presents a number of solutions to the database dependence problem … and concludes that EJB 3.0 is the way forward because of it’s relatively open standard despite the amount of effort required to implement it. Grant then suggests that ORMs (Object-relational mapping) may improve in the future, and the performance hit may be reduced through application of new technology. Grant debates the use of the Spring framework (a competitor to the EJB 3.0 framework) but discounts it due to being a “one-pony show”, only one implementaiton from one vendor. I wonder what the author thinks of alternative frameworks, like the Seam framework.
No related posts.
Hi Izamryan,
I’m sure there will be lots of debate on the topic in the project forums and I will address this point there too, but I would take exception to the point that the Spring framework is a competitor in terms of persistence to Entity EJBs. Actually Spring has no persistence of its own and simple wraps the actually persistence. And it “wraps” it in the Spring Inversion-of-Control container… which is what Spring is really. A small, light and efficient IoC. Now for some reason the concept of IoC seems to be perplexing to many, but I think when one looks close it’s actually a very simple yet clever idea. More in the Adempiere forums.
To anyone that does believe Spring to include its own persistence I ask for an example? I think you’ll find any example is simply wrapping jdbc, Hibernate, Toplink or EJB or some other persistence technology.
Do you remember when SQL arrived on the scene first? It was going to standardise access to databases. In one sense it was a success but strange that we discuss in Adempiere (an application based on much SQL) the need for DB independence. Is SQL not a standard? To me Spring offers protection from that… protection that at some point Entity EJBs become non-standard or that we wish to move to a new persistence approach but the cost of rewriting all the EJB framework code embedded in our Business Logic is too much – much the same issue we in Adempiere face today with SQL, don’t you think?
Many find Spring complex. But actual I believe those people have failed to grasp the Inversion concept. There is a need to configure (in XML files) that is slightly more complex but then the reward is the business logic has zero (absolutely zero) framework code and you end up with plain old java objects (POJOs). This makes it easy for those not versed in the framework to write business logic witouy the need to understand EJBs, Hibernate, seam or any other framework!
Of course Spring offers many other benefits and it’s popularity I believe are making it (if it is not already) a “de facto” standard.
Colin
Hai Croo!
I see your point re: Spring & Entity EJBs. And I feel that the advantages of using POJOs hasn’t been emphasised enough! Inversion of Control (IoC) techniques can help create elegant, clean, functional code.
I’ve been playing around with CakePHP (and a little bit of Ruby on Rails), and I’m really beginning to appreciate IoC techniques.
Well … back to lurking in the ADempiere project forums …