[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ormf-dev] A matter of arcitecture

Hi all,

I have been working with OSGi for over a year and although it sounds difficult at the beginning, it is not when you're familiar with the basics. Apart from the management advantage (starting, and monitoring bundles, i.e. parts of the application), the most annoying requirement are the many configuration and description files. Don't get me wrong, I like XML, but you can certainly overdo things.
Anyway, OSGi is really helpful when you have many components to combine, although it will not solve all issues, escpecially dependency resolution and library management become central issues sooner or later.


With respect to Spring I do have mixed feelings. Yes, Spring is well established, but it does have its wrinkles and dead ends and I am not sure about our use case here. I am still a bit cautious on the baggage Spring comes with.
Joel, would you mind, and enlighten me a bit on this issue?


Kind regards,
Wolfgang


Joel Rosi-Schwartz schrieb:
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

_______________________________________________ ormf-dev mailing list ormf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/ormf-dev