river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Date Tue, 14 Jul 2009 13:04:50 GMT
Hi Tom,

Can't say I'm one of the experts.

I've been trying to determine the differences and similarities between 
OSGi and Project Jigsaw and the changes to Java 7 to support modular 

This article is interesting: http://www.infoq.com/news/2009/06/jigsaw

It reports that OSGi has a dependency concept similar to Jigsaw called 
fragments, however that fragments don't themselves express dependencies, 
to form a dependency tree as such.  If you've ever played around with 
Debian's dpkg package manager, you'll know what I'm talking about.

I'd personally like to see what direction Oracle takes with the merger, 
perhaps there may be a convergence, cross pollination, competition or 
something similar, before we commit to OSGi or Jigsaw, perhaps 
dependency trees might assist with solving the fragmented container 
conundrum, I don't think we'll need to wait too long, we can get AR2 
rolled in the mean time.

One component that does have my interest is the possibility of class 
file versioning, (not Java bytecode versioning) so two incompatible 
versions of a class can coexist in the same classpath or runtime.  I was 
thinking that this would be useful for migration of live River djinn's, 
where incompatible class files could exist with dependency or class file 
versioning while one was phased out or trialled.

I'm also thinking that if we add support of compression to the http 
codebase (and serialization), we can download individual class files 
over the network individually instead of entire jar files (repeatedly 
compressed class files would be cached, to reduce CPU overhead).  This 
might make performance a bit snappier when only requiring a few classes 
from a large library that would normally be stored in a jar for instance.

I'd like to do something about packaging a Kerberos KDC Server (thinking 
TripleSec) with River, with support for RBAC, so that it runs out of the 
box to speak.

Translation of remote interfaces with OSGi sound interesting, River 
might become a migration path for those that needing something more 



Tom Hobbs wrote:
> "I know you guys are very busy, but it would be nice if the most
> experienced Jini/River software engineers were able to dissect the
> [OSGi] RFC 119 and provide an assessment as to how or if it is "suited"
> for Jini/River.  I know it's tough to allocate time to do that though."
> Well, in the absence of the most experienced you're left with me.  :-)
> For added confusion, I don't know a whole heap about OSGi either, so the
> follow is a likely mix of over simplification and misunderstanding.
> If that sounds useful, continue reading...
> This is the complete document, I skipped down to RFC 119 only;
> http://www.osgi.org/download/osgi-4.2-early-draft.pdf
> The RFC discusses the concept of a "Service Registry" which looks an
> awful lot like a River ServiceRegistrar.  Delving further into the RFC
> it seems to me that we if we can translate from the specified interfaces
> that describe an "OSGi Service" to that which describes a "River
> Service" then River could slot in quite nicely as a response to this
> RFC.
> Much of the work feels like translating from what OSGi say service
> descriptions and lookups *should* look like and what River says service
> descriptions and lookups *do* look like.
> The only tricky part, I think, would be how an OSGi component (which
> likely extends something else) can be made into a River service such
> that it is discoverable in the usual way.  This would be an interesting
> problem and raises the circumstance where an OSGi service might publish
> itself as an OSGi service, but because it's River underneath, would be
> discoverable by pure River clients on the same network also.
> Looking at how the RFC specifies what a service description is and what
> it looks like, I think that there is mileage in River adopting something
> similar.  It would be nice, in my opinion, to move away from the
> quasi-java config files River uses in favour of something else.  
> XML makes sense because that's what most of the rest of the world uses -
> although I personally don't care for it much.
> Someone on the Jini-Users (or similar, I can't quite remember) a while
> ago was talking about using Groovy classes to describe service
> configuration.  Something like this sounds pretty neat, but anything
> that needs to be recompiled for changes can take affect is likely to be
> unworkable for obvious reasons.
> Also, building in a mechanism to provide a similar version-sensitive
> lookup mechanism would 1) fit with OSGi nicely and 2) be a useful
> feature for River all other considerations not-withstanding.
> Anyway, that's this layman's interpretation of this OSGi RFC; if only
> for a few days or weeks of spare time to spend putting it together.
> Tom
> www.sucdenfinancial.com
> Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R
> Telephone +44 203 207 5000
> Registered in England no. 1095841
> VAT registration no. GB 446 9061 33
> Authorised and Regulated by the Financial Services Authority (FSA) and entered in the
FSA register under no. 114239
> This email, including any files transmitted with it, is confidential and may be privileged.
It may be read, copied and used only by the intended recipient. If you are not the intended
recipient of this message, please notify postmaster@sucfin.com immediately and delete it from
your computer system.
> We believe, but do not warrant, that this email and its attachments are virus-free, but
you should check.
> Sucden Financial Limited may monitor traffic data of both business and personal emails.
By replying to this email, you consent to Sucden Financial 's monitoring the content of any
emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any
opinions expressed by the sender where this is a non-business email.
> The contents of this e-mail do not constitute advice and should not be regarded as a
recommendation to buy, sell or otherwise deal with any particular investment.
> This message has been scanned for viruses by Mimecast.

View raw message