[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ormf-dev] A matter of arcitecture
|
Hi Wolfgang,
I am very glad that you have OSGI experience. I am very much looking
forward to picking up the technology so it will be good to have
someone on the team who is already forward on the learning curve to
lead the way.
As far as Spring is concerned, I do agree with you about the baggage;
no argument whatsoever. In the truth our usage of Spring in the
beginning will be light, so one may well wonder why bother with the
learning curve which is not trivial. On the other hand my motivation
for bringing it up is that my experience tells me that when you build
a project as complex as ORMF and there is no underlying framework you
quickly start building your own. Take transaction support f.i., do we
roll our own? Life cycle management of our Stateless beans? The point
is that frameworks like J2EE and Spring came together because mostly
because the services were proven to be required in a broad range of
server applications.
This does not mean that Spring is the only way to satisfy these
requirement and we should certainly consider alternatives before
buying in. Btw, one significant reason not to use Spring is that it
has not been used by any EF projects yet, thus IP due diligence has
not been do yet and that is not a trivial task for a large framework.
However, Swordfish has filed CQ's for it, so if we go that way at
least they have got the ball rolling.
That brings up another thought. Is Swordfish a possibility for our
framework? It is OSGI based and it is SOA so while it is young and in
Incubation I would like to throw its hat in the ring for
consideration. Does anyone know much about it?
All the best,
Joel
On 3 Aug 2008, at 20:26, Ingenierubüro Ponikwar (ORMF) wrote:
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
_______________________________________________
ormf-dev mailing list
ormf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ormf-dev
