[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ormf-dev] A matter of arcitecture
|
See inline
On 3 Aug 2008, at 16:40, Achim Lörke wrote:
See below
>
> I have been reconsidering the back end architecture and I would like
> to propose a two step simplification:
>
> The first step would be to replace the full Java EE 5 dependency
with
> a Java EE 5 web container (f.i. Tomcat or Jetty) and Spring
> implementation.
Jetty is available as an OSGi bundle (even in Equinox) so we should
use what's readily there.
Yes, and for the the OSGI implementation we will certainly use it. One
thing we need to consider, I think, is whether we want only an light
weight OSGI implementation or if we also want a web WAR to drop into
an existing web server. The question is, would folks who are already
managing a web server prefer to deploy ORMF into it rather than having
to deploy another standalone server. I think that is likely, but it
would be wise to see what real users/adopters have to say about it.
> This would be a fairly straightforward surgery of
> replacing the EJB Stateless beans with Spring beans;
Sorry, no experience with Spring. I take your word for it.
> the current
> implementation uses JPA entities rather than EJB Entity beans, so
> they will work unchanged in a Web container architecture.
And there is the initial release of EclipseLink (formerly Oracle's
TopLink) available as an OSGi bundle. EclipseLink implements JPA and
should be easy to use in an OSGi server architecture (sorry, no
experience in using this either).
> All of the
> current Web Services can be move up to web tier rather
transparently.
>
> The second step is that I would like to move to a pure OSGI
(Equinox)
> server. This will require more effort, especially (well at least
for
> me) in the learning curve.
If the above assumptions hold the way to an OSGi only server seems
straightforward. I'm not sure about the amount of work the Spring
framework needs but there is an OSGi implementation of Spring (http://www.springframework.org/osgi
). So in the long run it may be easiest to go directly the OSGi route.
>
> The advantages, as I see them are:
> simplified development environment
> simplified installation
> simplified maintenance
> lower the bar of entry
> simple single user environments would be realistic
I agree with this statements.
>
> I would like to throw these ideas open to the team. If there
> consensus then I would like to expand the conversation to the
> community via the newsgroup and/or bugzilla.
>
In my opinion we should go for OSGi (but I'm kind of a nerd when it
comes to new/exciting technologies). It's always harder to use new
and possibly buggy technologies but we are not on a tight schedule
for a producton release so we can use the best possible approach.
I am tempted and it is mostly my lack of experience with OSGI that
holds me back. While you are of course right that the only schedules
we have will be self imposed, I for one am eager to start getting
feedback from real live users.
Achim
