Hi Eugen, Another option which you might consider looking at is the newton framework [1]. In this framework we decouple implementation (business objects) from bindings (communications protocols) via the SCA specification [2]. We support RMI communications as a core feature.
By way of background info, a lot of the work we did on the newton framework has been fed into the discussion for the requirements of RFC 119. As is the case with specification processes there has been some mangling on the way through, so RFC 119 whilst semantically similar to our approach, has some minor practical differences. However most of these differences are purely at the "edge" and don't really impact on how you design your business objects or architecture. One of the many things on our list for a future release of newton is to seemlessly support RFC 119, though we're currently waiting for the spec to finalise before we rush to close the gaps. Also being an open source project if someone wanted to contribute that would be welcome too ;) Anyway, hopefully that's of interest if nothing else. Regards, Dave [1] http://newton.codecauldron.org [2] http://www.osoa.org/display/Main/Service+Component+Architecture+Home On Wed, May 20, 2009 at 4:17 PM, Eugen Reiswich <reisw...@informatik.uni-hamburg.de> wrote: > Thanks Peter, > > this is exactly what I wanted to know! I will wait for RFC 119... > > Kind regards > Eugen > > Am May 20, 2009 um 17:02 schrieb Peter Kriens: > >> The upcoming R4.2 will provide a Remote Services section that allows you >> to decouple bundles from the underlying distribution provider. This means >> that the only dependency in your code you have on the distribution provider >> is a number of properties + the OSGi service API. These properties should be >> settable by configuration management. The intention is that you can switch >> distribution provider without changing your app bundles, only have to change >> the properties. We are currently working very hard to create the spec based >> on the RFC 119 for this area and things are still a bit in flux so the RFC >> 119 is currently unfortunately a bit stale. >> >> ECF, CXF, and others are implementing this specification as distribution >> providers. >> >> Kind regards, >> >> Peter Kriens >> >> >> >> >> >> On 19 mei 2009, at 20:05, Eugen Reiswich wrote: >> >>> Hi, >>> >>> we are developing a client/server application with osgi. Say I have three >>> bundles: >>> >>> 1. client >>> 2. common (includes the service interface and domain value objects) >>> 3. server (includes the service implementation) >>> >>> We've started to develop our application with the remote technology RMI >>> but switched now to Riena. As it was really a pain to remove all RMI >>> dependencies from our code (e.g. all RemoteExceptions) I wonder if there is >>> a best practise approach how to achieve a loose coupling of a specific >>> remote technology in our osgi bundles without using tons of wrappers. >>> >>> Regards, >>> Eugen >>> _______________________________________________ >>> OSGi Developer Mail List >>> osgi-dev@mail.osgi.org >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- ------------------------------------------------------------------------------------- Paremus Limited. Registered in England. Registration No. 4181472 Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA Postal Address: 107-111 Fleet Street, London, EC4A 2AB The information transmitted is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ------------------------------------------------------------------------------------- _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
