openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "seba.wagner@gmail.com" <seba.wag...@gmail.com>
Subject Re: System architecture Roadmap
Date Thu, 12 Apr 2012 12:48:12 GMT
1.e) *All data beans need to be unified to have "automatic references" to
related objects like *
*MeetingMember.meetingMemberId should be reference to internal object not
just Long.*
=> I don't understand this point. We are using primitive type "long" for
primary keys. What is wrong with that reference?

1.f)
=> I totally agree that Management Classes VS Dao(-Impl) is currently
inconsistent.
However from my point of view you can't put all logic in the Dao(-Impl)
classes.
Dao's basically access the DB and fill the Beans. Nothing else. There will
be still some Management-Classes that contain methods that access multiple
Dao's, for example the registration. You would not put the whole
registration logic in a single Dao nor would you put all the logic in the
Service classes.
The design could be with 3 Layers:
1) Service-Classes (Axis2 or Red5): Entry Point, validates input
2) ManagementClasses (Maybe Rename with different Naming Pattern, for
example UserHandler instead of UserManagement like the "MailHandler")
3) DaoImpl (access to DB)
[It would be still allowed from my point of view to put minor business
logic into the Service Class and bypassing the Management Class of layer 2)
and go directly from 1) to 3) ]

So the task would be more like moving all DB related stuff to Dao Classes
and maybe rename the Management Classes with a different naming
strategy/pattern.

I don't think we need an Interface for each and every "Impl" at this point.
The Interfaces where needed in the past for usage in Spring Beans when you
are using the XML based Dependency Injections with Spring and template
approach to "inject" the Hibernate/OpenJPA session. The "AutoWired" Spring
feature does not need those Interface Classes. So I see no need to create
an Interface for every DaoImpl at this point.

Sebastian

2012/4/12 Maxim Solodovnik <solomax666@gmail.com>

> I agree,
> Resolving 1.c will improve our Oracle support (we do not fit Oracle
> limitations because of long auto-increment fields)
>
> I would add
> 1.d) we have multistile DB table naming like appointmentremindertyps,
> room_poll_answers, I think is is good idea to unify them (and probably make
> shorter)
>
> 1.e) All data beans need to be unified to have "automatic references" to
> related objects like
> MeetingMember.meetingMemberId should be reference to internal object not
> just Long.
>
> 1.f) Currently we have *DaoImpl and *management working with DB (calling
> EntityManager directly) I see inconsistencies in this.
>      a) we have *DaoImpl but do not have *Dao (usually we have Interface
> *Dao, and 1 or more implementations *DaoImpl)
>      b) I fill we need to separate DB layer i.e. move all work with
> database to DAOs, and remove such work from management objects, this will
> reduce similar functionality and makes code more consistent.
>
> I think we need to review our services list and make them more consistent.
> Maybe separate "red5" services to separate package.
>
> 2012/4/11 seba.wagner@gmail.com <seba.wagner@gmail.com>
>
> Backup files are XML files. The relation between XML file and database
>> schema is not 1:1. The XML files are more like an aggregation of multiple
>> tables that represent together an object.
>>
>> It would be another idea to generate the code for the "XML BackupFile
>> Export and Importer" Java Classes directly from the Persistence Beans.
>> _Then_ we would have a direct relation between database schema and backup.
>> Anyhow ... this might be also a point for our future roadmap: Automatic
>> Code generator for Export/Import functionality based on persistence beans.
>>
>>
>> Sebastian
>>
>> 2012/4/11 Alexei Fedotov <alexei.fedotov@gmail.com>
>>
>>> If backup file structure won't change, great.
>>>
>>> --
>>> With best regards / с наилучшими пожеланиями,
>>> Alexei Fedotov / Алексей Федотов,
>>> http://dataved.ru/
>>> +7 916 562 8095
>>>
>>>
>>>
>>> 2012/4/11 seba.wagner@gmail.com <seba.wagner@gmail.com>:
>>> > Schema changing has no affect on update process.
>>> > Update process is:
>>> > export backup file,
>>> > install in blank database
>>> > import backup file
>>> >
>>> > There should be no problem as long as we stay with that process.
>>> >
>>> > Sebastian
>>> >
>>> > 2012/4/11 Alexei Fedotov <alexei.fedotov@gmail.com>
>>> >
>>> >> Changing schema would likely affect update process. That should not
>>> stop us
>>> >> from moving forward, but worth additional effort planning.
>>> >> 11.04.2012 13:44 пользователь "seba.wagner@gmail.com" <
>>> >> seba.wagner@gmail.com>
>>> >> написал:
>>> >>
>>> >> > Hi,
>>> >> >
>>> >> > 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
>>> >
>>> >> > Organization.
>>> >> > 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
>>> >> > communication*
>>> >> > 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
>>> >> > framework.
>>> >> > 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
>>> >> > bean.
>>> >> > 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
>>> >> >
>>> >> > --
>>> >> > Sebastian Wagner
>>> >> > https://twitter.com/#!/dead_lock
>>> >> > http://www.openmeetings.de
>>> >> > http://www.webbase-design.de
>>> >> > http://www.wagner-sebastian.com
>>> >> > seba.wagner@gmail.com
>>> >> >
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Sebastian Wagner
>>> > https://twitter.com/#!/dead_lock
>>> > http://www.openmeetings.de
>>> > http://www.webbase-design.de
>>> > http://www.wagner-sebastian.com
>>> > seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.openmeetings.de
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.openmeetings.de
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

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