Is it possible to conduct a thought experiment using OSGi & JavaSpaces. Peter I am not saying that OSGi is a JavaSpaces issue but I think that most of I have seen with OSGi is more JavaSpaces related.
On Thu, Feb 4, 2010 at 6:20 PM, Peter Firmstone <[email protected]> wrote: > 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). It heavily utilises > ClassLoaders for limiting visibility to avoid 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 doesn't need to worry about > it. 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 the 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 utilises your service, it's bundle must lookup your service > from the Jini Lookup Service it might do this during bundle activation or it > might do so, at some other time. When that same client deactivates its > bundle that depends on your service (proxy), it also stops using your > service. > > Our bundles need to register with the Jini service registrar when activated > and de-register when deactivated. They don't need to be registered to the > OSGi service registry. Notice at no point here have I required any mapping > OSGi service. That would be a distraction abstraction ;) If I want to, > there's nothing stopping me from using an OSGi service from within my Jini > 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, instead create a > bundle that utilises a Jini Service, your bundle can register some other > service with the OSGi service registry so that you can plug in an > implementation that does work for an existing local software component, > which doesn't need to be aware that the Jini service even exists. Your > bundle will handle the 8 fallacy's of distributed computing and deactivate > itself if the you cannot rescue your service so that local components > depending on you are deactivated properly also. > > 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 [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. >> > >
