Sunday, September 28, 2008

PureMVC web framework

When developping a web application, we all know that we have several parts to focus on ; presentation flow management, business rules development, data persistence, and so on... It is generally called N-Tiers architecture, N being function of the complexity of the application.
J5EE for instance aims to cover all the scope of web application concerns.
For the ones who don't want a all in one framework, or who develop with other languages than Java, it exists many "little" frameworks which focus on a particular part of the web application development problematics. It is the case especially of Struts, or Wickets, or Spring, etc...
This is in this context that the PureMVC framework occurs ; its scope is only to manage the presentation logics, ie how the developper has to design his application to manage views, actions, controls, ..., in the web pages. It is clearly a replacement of Struts and it is based uppon clear explained design patterns of the Gang of 4 : proxy, médiator, command, facade, observer ; five design patterns for building simple and well structured web applications from the presentation point of view.
The "plus" of the techno is that it has been derived for many languages : Php, Ruby, Java, Flex, ... We may even consider now developping an entire application in different languages (for instance Php and Java) with the same underluing concepts... It could be the case in a SOA approach, eg a web portal (public access) in Php which would focus on referencing, and in java/gwt for the business part of the application (private access).
Another interesting view is that it is ,by construction (it is only based uppon the use of design patterns, not libraries), compatible with other frameworks like Spring or Restlets...
For the best, I would like to make notice that PureMVC has been derived for GWT, ie indirectly for Javascript :-).
So let imagine the following global architecture :)
  • GWT for the graphical part
  • PureMVC4GWT for controls and UI logics
  • Restlets for ressource access on the server(s)
  • OSGI for managing component efficiently
  • DB4O for storing data in database
Is it not a nice proposal? ;-)

28 comments:

German Viscuso said...

Niice! It's a nice proposal indeed, specially the choice of db4o for the persistence layer!

Best!
German Viscuso
developer.db4o.com

Xavier Méhaut said...

Thanks German. I actually like a lot DB4O... It is fast and easy to use... Heaven in comarison with Hibernate ;)
Regards
Xavier

ltaurines said...

I have been looking for a global architecture for a while.

-> GWT. I love it even thought the compiler is proprietary and it lacks of graphical sophistication (as Flex) so far.

->PureMVC4GW: no doubt, it almost perfect.

->Restlets: Why is GWT-RPC an opaque mechanism? It seems good enought to me.

-> OSGI: I am not familiar at all.

-> db4O: Yes fast and easy BUT GPL license or nightmare. The DB4O's price policy is not clearly exposed on their web site. It means troubles.

Regards,

Laurent Taurines

Xavier Méhaut said...

Hi Laurent,
You're right about GWT-RPC ; it is convenient and efficient. But I also like the REST architectural pattern considering accessing ressources instead of services. We handle less threads (GWT-RPC is based uppon servlets), proxies can handle ressources in cache, and furthermore each ressource is addressed uniformely.
Another interest of restlets is the ability not to use a web container but to see the application as a whole.
best regards
Xavier

ydna said...

Nicer still would be to have a standards based API (JDO or JPA) with db4o and DataNucleus, which provides these APIs for db4o, is also OSGi-enabled.

Xavier Méhaut said...

Hi Ydna,
Could you give us a little more information about that? Whatare the improvements expected of this?
regards
Xavier

andy said...

What are the benefits of a standardised API ?
So you can in principle swap your persistence process to an alternative implementation. Developers don't need to learn a proprietary API.

What are the benefits of using DataNucleus in this respect?
You can use db4o for persistence, but then also persist data to LDAP, or RDBMS, or XML, or Excel, or ... with a simple change of a URL (no changes to your data model, or persistence code). Also since DataNucleus jars are already OSGi enabled you can just drop them in your container rather than having to add special treatment.

--Andy
DataNucleus

Xavier Méhaut said...

Hi Andy/ydna,
Thanks for the explanations. What I fear is to add another level to the already rich cake we have. What is the leaning curve of this technology? What for its comlexity? What for execution time cost?
Could you give us more information?
regards
Xavier

andy said...

Where exactly is the "another level"? You propose using a proprietary API to handle persistence, and I suggest that you would be better to use a standard API : 1) more developers who already know standardised APIs (JDO/JPA) and 2) you have other benefits by choosing that route. Please define where the disadvantage is ?

Assuming your developer doesn't know any persistence API, what is the learning curve for the db4o API? about the same as JDO/JPA IMHO, however they'll find more docs for JDO/JPA since there are more implementations. You don't code to DataNucleus proprietary APIs.

Speed ? very little difference to db4o native speed. No need to use db4o transparent persistence/activation since its done for you by DataNucleus. You can have application identity capabilities (define primary key fields in your class) using JDO/JPA and DataNucleus whereas with db4o's API this is impossible.

The DataNucleus site has adequate documentation of the available APIs should you be interested.

ltaurines said...

I agree Andy, the use of JPO/JPA is the right approach to me too. And DataNucleus seems also to be the best candidate (JPOX was undertaken by DataNucleus).

Dan Kibler said...
This comment has been removed by the author.
Dan Kibler said...

I'm building a web app with gwt and db4o, but I'm finding db4o is not the dream solution I thought it would be. Becasue db40 has nothing built-in to handle reconnecting "disconnceted objects," I'm having to write lots of boring code to ensure I don't get duplicated objects in my database.

Xavier Méhaut said...

Hi Dan,
Could you please explain a little more what is your problematics?

Dan Kibler said...

Caveat: I am not a DB4o expert.

DB4o works great if bjects stay in the JVM. If you retrieve an object to modify it, and call store, it will know the object is already in the database and updated appropriately. However, if you detach the object by sending it to a web client db4o has no way to track the object. If the object is edited, sent back to the server and stored, db4o will think it is a new object. The problem is exacerbated if your object is complex- contains other objects or, worse, collections of other objects.

The way I know to solve this problem is to walk through the object graph and replace each object with its stored counterpart. This can get complicated quite quickly.

ORM approaches like hibernate provide ways to deal with this problem. I know of no direct support in db4o.

Xavier Méhaut said...

and what if you keep trace of the object by and ID?

German Viscuso said...

It's true that there's no support for disconnected objects in db4o but we're well aware of this and have filled some issues in the jira tracker. Please see:

Issue a
Issue b

and

Doc a
Doc b

Best! (Keep db4oing =)

Xavier Méhaut said...

Hi Dan,
Considering information given by german, could you indicate us if it resolves your problematics which indeed the problematics of every Restful or web service application.
Could you then give us your return of experience?
thanks in advance

Xavier Méhaut said...

The question about object relational databases is still : "what we want to do with it" and "what is the context of your application". There is not a definitive right choice. There is always advantages and drawbacks to use OODBMS or RDBMS, or to use DB4O or Versant if we absolutely want to use OODBMS.
This thread is interesting to read, even if it quite "old" now:
http://www.javalobby.org/java/forums/t99143.html

German Viscuso said...

I should add that we do have the functionality to mirror object trees in our replication framework (dRS). I would be cool if someone from the community could extract it from there and turn it into a general purpose solution for handling usecases where you need to reconnect complex external objects to the db.

We've added a description for the project in our Incubator (Merge Module).

Best!!

Xavier Méhaut said...

another interesting thread :http://www.infoq.com/news/2007/06/orm-obms-debate

Xavier Méhaut said...

and the last one :
http://rbtech.blogspot.com/2007/05/desire-vs-need-odbms-vs-rdbms.html

German Viscuso said...

Yes, the blog post: The Vietnam of Computer Science about object relational mapping is a classic. I highly recommend it!

Xavier Méhaut said...

:-)
I'm a former Smalltalker (but we stay ad aeternam a smalltalker indeed :) ) and Smalltalk is actually itself the first OODBMS through the concept of image running uppon a VM. But with the pressure of the market, I've started to use Java, and eclipse too. For OODBMS, it is a llitle the same shame :-( I believe in OODBMS, use it some times personally, but I've the difficulty to propose my choice to my company colleagues, because there are many variables to take into account in the context of a commercial project. In my first company many years ago, we worked with O2, and also Gemstone. They were not mature then, Versant or DB4O are a little more... From now,, it is more a markting and lobbying effort to do than a technical one in order to convert or live in good intelligence with the other DBMS...
We always speak about RDBMS or OODBMS, but we also have to think about vector database which are uncomparable in a performance point of view, which can be needed for instance in heavy Business reporting. Many companies in the semantics area also use other technologies we have to take into account like Intuition, Fast, search server, exalead, ...
So the pb is not easy, and we always have to make choices... Nevertheless, long life to OODBMS :-)

German Viscuso said...

What a coincidence, I'm a former (ad aeternam) Smalltalker too! =)
I agree with your point of view.

Best,

German

Xavier Méhaut said...

How many Smalltalkers frustrated in nature ;) !But thanks to Smalltalkers we have Pattersn, Eclipse, OODBMS, VM, Ruby, Groovy, Continuations, Inversion of Control, and more...

German Viscuso said...

=) and XP!

Xavier Méhaut said...

XP of course ;) but also multiwindowing system, mouse, and chocolate cake. Humm chocolate!
Are German full time developper on DB4O? or have you another job too?

German Viscuso said...

Hi Xavier!

I work full time for db4o but I'm not a core developer. I manage the db4o community and that involves, among other things, helping db4o users, doing some evangelizing and some marketing and, of course, participating in db4o related threads on blogs =)
I used to be a full time developer though and I have an mcs in computer science.

Kind regards.