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 <[email protected]> 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 [email protected] 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.
