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]) - revised
Date Fri, 05 Feb 2010 04:41:55 GMT
Hi Tom,

I thought I'd grab this thread again, as it still appears to be an issue
and I'm now in a better position to answer.

Both Jini and OSGi use their implementation of the Publish, Find, Bind
pattern as an abstraction or fa├žade to enable the implementation behind
it to be hot plugged, they both use the term service.

I've realised that there is no need to map a Jini service to an OSGi
service, nor worry about the different semantics between them.  Why?
You only need one abstraction, why have an abstraction on an
abstraction?  And if you want to get technical each solves a different
problem, so one is not better than the other or in a competitive
relationship:

    * You use your OSGi service to change out, swap between, iterate
      over or group your modules (bundles) and their functionality.  OSGi
      heavily utilises ClassLoaders to limiting visibility, avoiding
      classpath hell.
    * You use your Jini service to abstract away the communication
      protocol between two nodes, so they can exchange objects easily.
      When the protocol changes, the client software doesn't need to be
      concerned.
      It also enables the construction of a distributed system from
      the sum of its components and it enables the abstraction of
      hardware and software components.

Here's how to take advantage of OSGi from Jini, it is slightly different
from standard OSGi modularity practises, if you don't like it, use
Preferred Classloader instead, or use the existing http URL mechanism,
you are not committed to utilising OSGi, but those who are planning to
use Jini Services over the web will probably want to.

   1. Create a bundle containing your service interfaces.  The
      interfaces will then be in their own ClassLoader, this is
      important, so that others can implement the same service interface
      without being dependant on and having to download your
      implementation bundles.
   2. Create your Smart Proxy Implementation, it belongs within its own
      bundle, it depends on one or more of the Interface bundle
      packages.  If the interface bundle extends interfaces from
      external packages, (imports other bundle packages containing
      interfaces) then you must import those interface packages also
      otherwise the you will get a runtime exception.  Software on the
      client utilising your proxy will need to import the interface
      packages and any additional packages that these interfaces
      extend..  You also need to specify any permissions your proxy
      needs.
   3. For simple reflective proxies, the proxy will be loaded into the
      interface bundle Classloader at the client.
   4. Create your Server Service Implementation, it must import the
      packages from the Interface and the Smart Client Package bundles
      and any other packages that the interface bundle extends.

When a client from within an OSGI bundle utilises your jini service 
remotely, it must lookup your service from the Jini Lookup Service, it 
might do this during bundle activation, or it might do so during 
execution.  When a client deactivates its bundle, it also stops using 
your service (It doesn't actually depend on packages from your proxy 
bundle, only packages from the interface bundle/s).

Bundles containing Jini services, should register with a Jini service 
registrar during bundle activation and de-register when deactivated. 
They don't need to be registered with the OSGi service registry. Notice 
at no point here have I required any mappings to OSGi services.  That 
would be a distraction abstraction ;)   If I want to, there's nothing 
stopping me from using an OSGi service from within my bundles, it's 
purely up to the implementer.

At no time should we attempt to directly map an OSGi service to a Jini
Service or visa versa, they do not map well due to different lookup
semantics and the 8 fallacy's of distributed computing. If you must 
provide a Jini service to a local software component that utilises an 
OSGi service, create an adapter bundle that looks up and utilises a Jini 
Service.  Your adapter bundle can register an OSGi service with the OSGi 
service registry. Other OSGi bundles using your OSGi service don't need 
to be aware that the Jini service even exists, however you do need to 
take the network fallacies / latencies into account.

There isn't a requirement to create an OSGi service.  Your local bundle 
utilising Jini Services can be made to handle the 8 fallacy's of 
distributed computing and deactivate itself if suitable Jini Service are 
no longer available.  This way, local components that are directly 
dependant on your functionality are deactivated properly also and don't 
hang waiting, you'll want to write to the local service log before doing 
so, try to clean up gracefully.

If you have created an OSGi Service and registered it with the OSGi 
Registry, other OSGi bundles won't depend on your bundle.  Instead of 
shutting down your bundle, you might choose to look for another jini 
service, while doing this you de register your OSGi service, until you 
find another suitable Jini service.

I wouldn't recommend that Smart proxy's register an OSGi service 
directly, I suppose that someone might find a reason to do it, however 
there is nothing stopping a Jini Smart proxy from utilising the local 
OSGi services.

Simple Reflective Proxy's will never directly cause any other bundle to 
become deactivated by the OSGi framework.  Bundles that utilise Jini 
services must be designed with the 8 network fallacies in mind.

Cheers,

Peter.

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
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.
>   



Mime
View raw message