Opentaps 2.0 Planning - Revision history

Sichen at 23:00, 5 January 2012

2012-01-05T23:00:43Z

Sichen at 23:00, 5 January 2012

2012-01-05T23:00:28Z

Sichen: /* Development Plan */

2011-03-02T00:44:59Z

‎Development Plan

Sichen at 00:44, 2 March 2011

2011-03-02T00:44:36Z

Sichen: /* A Proof Of Concept */

2011-02-25T00:58:18Z

‎A Proof Of Concept

Sichen: /* Architecture */

2011-02-25T00:50:10Z

‎Architecture

Sichen: /* Architecture */

2011-02-25T00:43:28Z

‎Architecture

Sichen: /* The Idea */

2011-02-25T00:34:41Z

‎The Idea

Sichen: /* The Idea */

2011-02-23T21:25:26Z

‎The Idea

Sichen: /* The Idea */

2011-02-23T21:07:16Z

‎The Idea

← Older revision		Revision as of 23:00, 5 January 2012
Line 1:		Line 1:
	__TOC__		__TOC__
		+
		+	==IMPORTANT!==

	'''This document is out of date. Please see [[Opentaps_2_0\|opentaps 2.0]] for more current information.'''		'''This document is out of date. Please see [[Opentaps_2_0\|opentaps 2.0]] for more current information.'''

← Older revision		Revision as of 23:00, 5 January 2012
Line 1:		Line 1:
	__TOC__		__TOC__
		+
		+	'''This document is out of date. Please see [[Opentaps_2_0\|opentaps 2.0]] for more current information.'''

	==The Idea==		==The Idea==

@@ Line 171: / Line 171: @@
 We will develop and roll out opentaps 2.0 in successive (hopefully rapid) milestones.  Currently we are planning these milestones:
-#.  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
+#  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
-#.  Webapp framework -- adapt the [[Customizing_opentaps_Applications#Webapp_User_Interface_Database_Entities|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.
+#  Webapp framework -- adapt the [[Customizing_opentaps_Applications#Webapp_User_Interface_Database_Entities|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.
-#.  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.
+#  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.
-#.  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.
+#  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.
-#.  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.
+#  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.

@@ Line 68: / Line 68: @@
 ==The Old Proof Of Concept==
-''This is the original POC from 2010.''
+''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.
@@ Line 167: / Line 167: @@
 For more information, see the [[opentaps OSGI Proof Of Concept Tutorial]].

← Older revision		Revision as of 00:58, 25 February 2011
Line 50:		Line 50:

	==A Proof Of Concept==		==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 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.		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.

@@ Line 40: / Line 40: @@
 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.
+Implementation bundles implement the interfaces defined by the middle level business tier bundles.  These bundles would be similar to the packages in <tt>org.opentaps.common.domain</tt> or <tt>org.opentaps.financials.domain.billing</tt>, 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:

@@ Line 33: / Line 33: @@
 * 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 for general business 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:
+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
@@ Line 40: / Line 40: @@
 etc.
-Implementation bundles implement the interfaces of the business domain
+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
+Higher level bundles are more specific to the particular applications.  For example, a higher level application bundle for CRM might define:
 ==A Proof Of Concept==

← Older revision		Revision as of 00:34, 25 February 2011
Line 23:		Line 23:

	Your user interface can be written in a separate framework altogether and loaded into the opentaps UI framework.		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., <tt>ORDER_APPROVED</tt>), 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 for general business 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 of the business domain
		+
		+	Higher level

	==A Proof Of Concept==		==A Proof Of Concept==

@@ Line 14: / Line 14: @@
 [[Image:Opentaps-screen-layout.jpg|700px]]
-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 use the [[Customizing_opentaps_Applications#Webapp_User_Interface_Database_Entities|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.
-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 <tt>org.opentaps.webapps</tt> 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.
+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.
-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.
+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.
-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.
+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.
-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.
+Your user interface can be written in a separate framework altogether and loaded into the opentaps UI framework.
 ==A Proof Of Concept==

@@ Line 3: / Line 3: @@
 ==The Idea==
-With opentaps 2.0, we plan to move towards a more modular architecture based on the [[Domain Driven Architecture]] and [[Opentaps Google Web Toolkit|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:
+With opentaps 2.0, we plan to move towards a more modular architecture based on the [[Domain Driven Architecture]] and [http://www.osgi.org 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
 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: