Opentaps 2.0 Planning

With opentaps 2.0, we plan to move towards a more modular architecture based on the Domain Driven Architecture and GWT to make opentaps easier to use and easier to customize. Our goal is to turn opentaps into a "plug and play" platform, or a portal of business applications which could be developed in a number of frameworks and languages. With this framework, you will be able to:

• add user interface elements to existing opentaps applications without having to modify them
• choose from different implementations of essential components, such as email, calendar, search, files, etc.
• build extensions to opentaps in the language and framework of your choice, including PHP, Ruby, and Java
• reuse opentaps domains and GWT toolkit to build business applications for other platforms

Let's start with the user interface. This is a standard layout for opentaps, as well as for a lot of other web-based business applications:

In the current version of opentaps (1.4), the pages are laid out using the screen widget, so if you want to add additional elements to a screen, you need to edit either XML or freemarker files.

In opentaps 2.0, we will settle on this as the standard layout for opentaps, and the elements of screens (i.e., with the user sees when he views an account) will be stored in the database. A new package org.opentaps.webapps will retrieve what the elements of a screen are: webapps, tabs, leftbar groups, leftbar items, canvas, canvas items, and rightbar widgets. The screen would then be rendered from these screen elements using a fairly simple template and CSS. As a result, if you need to add additional items to a screen, you can just load them into the database as additional screen elements.

Further, the content for the screen elements could come from anywhere, including standard http requests. Thus, you can write an application in any programming language -- PHP, Ruby, or Java -- which generates HTML, and opentaps will plug it in to the screen, provided your application provides opentaps with the necessary security key.

The opentaps applications themselves will also be split up into smaller modules. The core opentaps modules will handle basic customer and order management (CRMSFA), supply chain and purchasing (Purchasing), accounting and financial management (Financials), and inventory/shipping/manufacturing (Warehouse) needs. Each one will in turn be enhanced by email, calendar, task management, search, file management, and notes features, which will be independent components that will interact with the core opentaps applications through GWT.

Finally, features such as forecasting, marketing, Material Resources Planning, and budgeting will be spun out of CRM, Purchasing, and Financials into their own modules, but they will cause additional screens to be loaded into the core opentaps applications.

Building new features for opentaps 2.0 will be a different experience, because you won't be writing just for opentaps anymore. Instead of going into an existing opentaps application and working with existing screens and entities, you will write a "platform-independent" module like this:

• get the opentaps GWT libraries
• reference the domains for your underlying data, such as the party or order domain
• write your business logic, manipulating data from the opentaps domains
• write GWT widgets, which take information from the screens themselves (i.e., partyId, orderId, etc.)

Then, you can package your module for opentaps by:

• using the Spring framework to wire the opentaps implementations of domains to your module
• creating entries in the database for opentaps to load your GWT interface onto existing opentaps screens, such as viewAccount or viewOrder

Note that you won't even have to package your module as a component of opentaps or use the same database as the one configure for opentaps. Our domain driven architecture will handle retrieving and storing data in an opentaps compatible fashion, so you just need to focus on the essential business logic of your module. Similarly, you will have to package your module as an opentaps component, because the new user interface framework will accept HTML fragments from applications running remotely. Thus, your application could be written with JSP/Tiles and running on an independent tomcat server, or even be written in PHP or Ruby, and still interact with opentaps. We will use CSS to keep the look and feel consistent.

Now here comes the best part: you can then port your module to another business applications platform, be it another open-source ERP or CRM application or even salesforce.com or NetSuite, by implementing a domain layer which is compatible with such a platform.

How's that for write once, run everywhere?