openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject System architecture Roadmap
Date Wed, 11 Apr 2012 09:43:17 GMT

I would like to start some discussion about our overall RoadMap on our
System architecture for the mid and long term.
This is not intend to be realized for the 2.0 release but I think there is
need to find some consens on the overall direction.

*1) Database Schema*
There is some inconsistencies (or maybe it is just Non-Standard compliant)
in the database schema, that have kind of historical reasons:

A) The tables have a column "deleted" with type Varchar
The reasone was that some tables where many-to-one relations that where
build by hibernate ORM mapping. In those many-to-one mappings you could
define a where-clause. The problem with that where-clause was/is that you
could not define a where clause based with boolean attributes in annotions.
So that is why the column "deleted" is a string instead of a boolean.I
think in openJPA there is currently the same problem. However we can use
NamedQueries instead.

B) Many-to-many tables contain attributes
The purpose of the table "organization_users" is only to hold a relation
between users and organizations. In a clean database scheme that table
would only contain two attributes: user_id and organization_id. There would
be not even a Java-Bean in our business logic layer. The User Object would
directly contain a List of Organizations. The problem here is that we
define an attribute "is_moderator" in the mapping table. The attribute's
meaning is to make an user a moderator of single organizations instead of
giving globally system wide moderation rights.
I think making a table "organzation_user_properties" and putting into that
table the "is_moderator" attribute would be the standard way to solve it.
There are some client side related issues if we move the Organization List
directly in the User object instead like it is now: User > Org_user >
Same for "rooms_organizations". But it should be easier here as there are
no attributes in the mapping table to clean it up to a standard schema.

C) Change annotations for primary keys to use the column "id"
I think we should make all our tables (except "meetme" because Asterisk
requires it that way) to have the primary key column name "id" instead of
for example "organization_id". I think we can change that in our ORM layer
only, no need to rename every attribute in the Java objects.

*2) DTOs instead of using persistence objects in the Client-Server
It was so far quite handy: If you wanted a new attribute for example in the
User Object you just changed the Mapping files, and directly all client
side objects also have that attribute. Quite handy to get things done fast.
However it will turn out that in our future our system will become hard to
maintain if we keep it that way. Every change in the persistence layer will
need changes on the client side. That will make it hard to improve certain
components or modules as you can't do it without changing/knowing the whole
We should try to separate the persistance beans from the data transport
beans (DTO).
That would mean we define Objects that contain exactly the information that
is needed in the client for each RPC call. In reality that will of course
mean that we will have in the beginning almost a 1:1 copy of the
persistence beans as DTOs. However the goal should be first to find a good
mechanism to convert persistence beans to DTOs without spending too much
time and effort on marshalling an object from persistence to transport
By doing that we will give client side developers a more stable API. Our
SOAP / REST API already contains a lot of API calls that only stay there
because of backwards compatibility. We have to do something here to make
our API more stable and still beeing able to do major changes in the core.

I don't think that those points will go into Apache OpenMeetings 2.0
Release (except 1) C ) but maybe for a Release 3.x

Thoughts on that?
There are other points that should be added here?


Sebastian Wagner!/dead_lock

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message