[news.eclipse.technology.riena] Re: project similar to riena

[Filippo Carone <filippo.carone@xxxxxxxxxxxxxxxxx>]

Christian Campo ha scritto:
> Hi Filippo,
>
> Always good to hear from people that are building Riena type applications.
>
> You found boilerplate code in Riena ? I am not sure what classes you are 
> refering
> too. But I guess if its not in the samples and testcases, then this bound
> to happen in a generic framework. It contains the code that you as an 
> application
> programmer don't need to write anymore.
> That part should be mostly in the ServiceInjector and in the publisher 
> packages.

Hi Christian,
I was exactly referering to the ServiceInjector and publisher packages.

> Have we considered using Spring OSGI instead ? That would just move the 
> boilerplate code to Spring wouldn't it and add a bunch of bundles as a fixed 
> dependency to Riena if I get you right.

 Yes, Spring contains all the needed infrastructure for the general
application configuration, so all the dependency injection code and 
services lookup logic is inside it. Anyway the springframework is 
distributed as a single bundle (it's about 2.5mb) or as multiple 
bundles. In my case, I'm using the single bundle so it's just 1 fixed 
dependency.

> There is nothing wrong with creating applications on top of Riena using 
> Spring OSGi.
> Only that we didn't want to force everybody to always have the extra 
> bundles from Spring OSGi.

 I completely agree with this line, since including Spring would mean 
more than including an extra bundle, but the spring "way" of handling 
the application.

 Anyway, in order to avoid any names confusion, I'd like to clarify 
that with the springframework I mean the Springframework itself and not 
Spring OSGi (which is now called Spring Dynamic Modules for OSGi Service 
Platforms). The springframework is distributed as a library and it is 
also an OSGi bundle while Spring modules for OSGi is a spring project 
which helps to build OSGi bundles.

> Concerning security we are also using JAAS based security for 
> authentication and authorization only that we are more aiming at 
> using equinox security once it gets
> ready and rather not use a Spring-focused component like Acegi.

I agree again.

 In our case, Acegi was a perfect fit, since it can seamlessly connect 
to several backend systems to check authentication data, and we are 
deploying our application in different enterprise contexts.

> What are you doing about the other topics that Riena plans to adress:
> - persistency

 ATM, the client doesn't contain any data on startup, and all data are 
fetched from the server. We are already implementing the process 
oriented UI, so there's no concept of projects or classical workspace.

 Persistency is handled server side, with hibernate (with the usual 
service->dao->db pattern).

 Complex data are lazily loaded almost like in a web app with the 
opensession in view pattern, so we transfer the minimum needed amount of 
bytes for each serialized object and load the remaining part only when 
needed (for example when the user loads the object in an editor to 
edit/change it). You can find the code we wrote for this functionality on:

http://openutils.sourceforge.net/openutils-spring-rmibernate/source-repository.html

 Again we rely on the spring presence, but the concept itself may be 
replicated in any context.

> - objecttransactions

 Do you mean db transactions or object workflows? In the first case, 
spring has transaction support out of the box, in the second case we 
have the workflow logic in the client code: for example there's an 
object whose editor knows about its logical workflow. This is probably 
not a best practise, but it has proven solid and quick to develop.

> - integration of local apps

 Currently we export data from tables in excel format, using custom 
code to format table data appropriately in the excel file. Besides this, 
there has been no need for tighter integration with the local office 
apps, since the client itself offers alot of means to analyse data 
(graphs, tables, metadata, etc). I'm exploring the possibility to use 
the SWT OLE bridges, but I wish I can avoid any platform specific 
features and keep the client multiplatform.

> - software update

 No software updates up to now. Currently we release both the complete 
client and server to our customers. Since the client cannot run in 
offline mode, and the server is not OSGi based, making the update 
available only for the client when you manually have to stop and 
redeploy the server, has no advantanges.

 I think that software updates are a really cool way of handling new 
releases if you have both the client and the server based on the OSGi 
platform.

> - a different UI

 What do you mean by different UI?

> - etc.
>
> Any requirements or proposals from you on that ?

This mail was just a brief explanation of the general design and 
solutions we have adopted. I'm going to read riena specs once more, and 
write more considerations/requirements/proposal focusing on one feature 
at a time.

I'm sure we can exchange alot of interesting ideas.

Cheers,
Filippo