Opentaps 2.0 Planning

From Opentaps Wiki
Revision as of 01:05, 17 June 2010 by Sichen (talk | contribs) (Trying It)
Jump to navigationJump to search

The Idea

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: Opentaps-screen-layout.jpg

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?

A Proof Of Concept

This simple proof of concept application will be a Web portal which allows you to define different canvas items and widgets and allows users to sign in with security. It will be a standard J2EE web app and not require any ofbiz components. The key to this proof of concept is the ability to interact with external web-based applications through a common interface framework and security model.

The proof of concept application will have three tabs with the following tab items:

  • Google
  • Microsoft
  • Yahoo

There will be the following users with the following areas of access:

  • larry/larry: everything in the Google tab
  • sergey/sergey: search only in the Google tab
  • bill/bill: everything in the Microsoft tab
  • jerry/jerry everything in the Yahoo tab
  • opentaps/opentaps: everything in all the tabs

For all pages, we will also have these widgets:

  • On the left-hand side below the tab items will be the opentaps Facebook Fan widget.
  • On the right-hand side will be the "opentaps on Twittter" widget
  • below the main canvas will be Google Adsense ads

Trying It

Download the opentaps 2.0 OSGI Proof Of Concept zip file and unzip it. Or checkout the latest revision from svn

$ svn co svn://svn.opentaps.org/opentaps_portal/trunk opentaps_portal


You can try the proof of concept using either MySQL or an embedded HypersonicSQL database. To use it with MySQL, first create a database for it in mysql:

$ mysql -u root -p -h localhost
mysql> create database opentaps_2_0;
mysql> grant all privileges on opentaps_2_0.* to 'opentaps'@'localhost' identified by 'opentaps' with grant option;
mysql> flush privileges; 

Then, edit the file bundles/persistence/src/main/resources/OSGI-INF/blueprint/database.properties to set the database connection. Comment out the information for HSQL and comment in the ones for MySQL:

# Embedded HSQL
#database.url=jdbc:hsqldb:file:data/opentaps-portal.db;hsqldb.default_table_type=cached
#hibernate.dialect=org.hibernate.dialect.HSQLDialect
#driver.classname=org.hsqldb.jdbcDriver
#database.username=sa
#database.password=

# MySQL
 database.url=jdbc:mysql://127.0.0.1/opentaps_2_0?autoReconnect=true&useOldAliasMetadataBehavior=true
 hibernate.dialect=org.hibernate.dialect.MySQLDialect
 driver.classname=com.mysql.jdbc.Driver
 database.username=opentaps
 database.password=opentaps

Now, go to the opentaps-2.0-osgi-poc directory and use maven to build it:

$ mvn install

Finally, you can run it with Jetty:

$ cd war
$ mvn jetty:run

When you see this log message in your terminal, the opentaps portal has fully started up and is running:

DynamicSessionConfigurationListener: onBind: create seed data ...
getSessionFactory, returning proxiedSessionFactory: org.hibernate.impl.SessionFactoryImpl@3645ce28
Delegate factory invoked: org.hibernate.impl.SessionFactoryImpl@3645ce28 openSession
DynamicSessionConfigurationListener: onBind: create seed data DONE

Go to http://localhost:8080/opentaps/control/testportal (http://localhost:8080/portal/control/opentaps if you downloaded rc1). You will be prompted for a username and password. Enter "opentaps"/"opentaps" for now, and the portal should come up with the default page, which looks like this:

Opentaps portal poc.png

Click around and you can visit all the popular sites from Google, MSN, and Yahoo. You can also try the other username and password combinations listed above to see how the portal can restrict access to the different tabs using security settings.

How It Works

The proof of concept you've just seen is built with OSGI and consists of several OSGI bundles, each of which implement the core functionality of a web portal. The bundles are:

  • core
  • jdbc-hsql
  • jdbc-mysql
  • persistence
  • security
  • webshell

The core bundle consists of commonly used functionality, such as debugging and logging, and service management features for registering filters and static resources to OSGI services.

The jdbc-hsql and jdbc-mysql bundles are used for establishing JDBC connections with either the Hypersonic SQL embedded database or standard MySQL databases.

The persistence bundle handles persistence of Java classes, such as those used by the webshell bundle. It uses Spring Dynamic Modules to manage persistence and transactions using hibernate.

The security bundle handles security permissions. It implements the OSGi useradmin package interfaces for User, Role, Group, etc. In the first proof of concept, the users and their permissions are currently stored in war/users.xml. In later implementations, they can be implemented to use outside user permission systems, such as the opentaps user security model or LDAP.

The webshell bundle implements the portal structure, including the webapp with tabs, links, and screens. It is a controller in the "Model-View-Controller" sense. It uses on the security bundle for security permission checking and the persistence bundle for interacting with the database to retrieve the definition of the UI. It then uses the StringTemplate templating engine to render the user interface based on the definitions in the database.

All the bundles interact with each other through interface definitions and OSGi services to enforce modularity and maximize code reuse.

Finally, build and installation are now handled by maven instead of ant for earlier versions of opentaps.

For more information, see the opentaps OSGI Proof Of Concept Tutorial.