river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Grahn <jgr...@simulexinc.com>
Subject Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Date Tue, 14 Jul 2009 23:30:36 GMT
Lest I ruffle any feathers, the last sentence was meant to be neutral, 
not a thumbs-down to OSGi.   Poor phrasing.


James Grahn wrote:
> I'm utterly unfamiliar with OSGi (hadn't heard of it until it shambled 
> into this mailing list), but I will say this about using Groovy for 
> configuration:
> The existing Jini configuration is the ultimate "one-off"; it's a DSL 
> that is a narrow subset of Java that's not used anywhere else other than 
> configuration, even within Jini (AFAIK).
> Groovy is a generalization of the existing Jini configuration that also 
> grants developers access to better abstractions.   Groovy is quite 
> similar to Java, so there's little to explain to developers as they get 
> started, and the resources to explain it are much larger (the Groovy 
> community).
> So it's a marked improvement over the status quo in my book.
> I can't comment on how well this fits in with OSGi, nor am I certain 
> that OSGi integration is desirable.
> jamesG
> Sam Chance wrote:
>> Tom,
>> I think you are "tracking" in the direction I was suggesting.  Peter's 
>> email
>> is similarly aligned.  I'm not meaning to imply that I am "right"; I'm 
>> just
>> saying your and Peter's thoughts are congruent with my own.  In fact, 
>> OSGi
>> does help a lot with "Classpath Hell". OSGi also adds another layer of
>> security above the standard Java.  Versioning is a "first-class 
>> function" in
>> OSGi.
>> Distributed OSGi, in my view, is almost an indirect reference to Jini!
>> Minimally, D-OSGi is well aligned with Jini/River and the opportunity to
>> implement it using River is clearly present.
>> As for Jigsaw, Groovy, and Java 7 modules, I would steer clear. Decisions
>> about technology adoption are clearly not the result of superior 
>> technology.
>> (Look no further than Jini!)  OSGi is already enjoying wide adoption and
>> acceptance. Frankly, I attribute much of it to the *simplicity* of OSGi,
>> coupled with its elegance.  Jigsaw is obscure at best; Groovy IMHO is
>> "one-off", and Java 7 is - well, who knows?
>> The broad adoption of OSGi in automotive, mobile and enterprise 
>> sectors is
>> clearly the enabler for "mass convergence".  The press releases and other
>> public literature are pervasive and reflect a strong consensus.
>> Having said all that, I also know that "computer science" can sometimes
>> appear to be an oxymoron! For all we know, Groovy and Jigsaw could be all
>> the rage next week!  Still, it is logical and probable that OSGi will 
>> become
>> the ubiquitous module system for Java.  And convergence across heretofore
>> separate networks will usher in an enormous need for distributed services
>> and their requisite management.
>> Just some thoughts.
>> Sam
>> On Mon, Jul 13, 2009 at 7:53 AM, Tom Hobbs <tom.hobbs@sucfin.com> 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 5AZ
>>> 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