Opentaps 2.0 Planning

IMPORTANT!

This document is out of date. Please see opentaps 2.0 for more current information.

The Idea

With opentaps 2.0, we plan to move towards a more modular architecture based on the Domain Driven Architecture and OSGi 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

We plan on maintaining backward compatibility with your data from older versions of opentaps.

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 opentaps 2.0, we will use the webapp user interface entities from opentaps 1.5 to allow you to customize your user interface elements in the database. We will expand it beyond the screen widget to allow your screen elements to 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.

Building new features for opentaps 2.0 will be a different experience. We will provide you with OSGi bundles which serve as a compatibility layer with opentaps 1.x plus higher level "domain" bundles which provide business logic. For example, domain bundles could be for business domains such as Customer or Order or Product.

You can either load our compatibility bundles or load other bundles to persist the data model, while using the same higher level domain bundles to reuse our business logic. If you are using opentaps 1.x, the compatibility bundles will continue to work with opentaps 1.x. But if you want to build an application with a native data model, you can use a different persistence bundle. Finally, if you want to have your application compatible with another application framework, such as salesforce.com, you will be able to load a separate bundle for that framework. All these lower level bundles will be compatible with the same higher level opentaps domain bundles.

You will be able to access our domain bundles either directly, if you are using Java and OSGi, or remotely if you are using PHP or Ruby On Rail.

Your user interface can be written in a separate framework altogether and loaded into the opentaps UI framework.

Architecture

This is currently a work in progress

Lower level bundles are used for talking to the database and/or operational systems, suchas opentaps 1.x. For opentaps 1.x backward compatibility, the lower level bundles are:

• base entities - Java classes for the data model from opentaps 1.x, automatically generated with markup for JPA 2.0 persistence as well.
• base constants - Java classes for the literal data constants (i.e., ORDER_APPROVED), automatically generated from opentaps 1.x
• base services - Java classes for the services available from opentaps 1.x, automatically generated with invocation back in opentaps 1.x, using XML-RPC or other protocols.

Middle level bundles define the business tier logic. These are sets of abstract entity classes and interfaces to repository and services. They should be similar to the `org.opentaps.domain` packages. They cover general business domains such as:

• Party - people
• Order - orders
• Product - products
• Billing - invoicing and payments

etc.

Implementation bundles implement the interfaces defined by the middle level business tier bundles. These bundles would be similar to the packages in org.opentaps.common.domain or org.opentaps.financials.domain.billing, etc. The implementation bundles would use the lower level bundles to implement the middle level bundles.

Higher level bundles are more specific to the particular applications. For example, a higher level application bundle for CRM might define:

• Leads
• Accounts
• Contacts

which draw upon the Party bundle and its implementation.

A Proof Of Concept

Let us imagine a very simple application for working with sales leads, where you can:

• create a lead
• find a lead
• view a lead
• edit/update a lead

The lead has very basic fields such as first name, last name, company name, industry, etc.

The Leads bundle is the high level application bundle. It would have services for:

• createLead
• findLead to return List<Lead>
• updateLead

The Leads bundle would call upon similar services in the Party bundle, whose implementation would reference the create/update/find services in opentaps 1.x:

The Old Proof Of Concept

This is the original POC from early 2010.

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:

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
• test

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.

The test bundle contains the data for the test portal you've just seen.

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.

Development Plan

We will develop and roll out opentaps 2.0 in successive (hopefully rapid) milestones. Currently we are planning these milestones:

1. User and security framework -- ability to access users and security permissions. The users would already be defined in another system, such as ldap or opentaps 1.x
2. Webapp framework -- adapt the webapp user interface entities from opentaps 1.x to create the screens. Also allow a screen to be composited from segments defined in the database.
3. Application POC -- basic features to create, view, update, and find leads. Includes both services, implementation of the services, and user interface. Demonstrates how to build a complete application.
4. Basic Leads application -- add contact information, activities (calendar), notes, and status updates to leads. We will be simplifying some of the purposes from opentaps 1.x, so for example all postal addresses are shipping destinations.
5. Basic CRM application -- extend the same to contacts and accounts. Allow create/view/update/find leads, contacts, accounts. Convert leads to accounts. Create/view/update/find activities for accounts/leads/contacts. Notes for all.

The user interface will be modernized compared to opentaps 1.x.