You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2010/02/05 03:20:08 UTC
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
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 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.
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sure Freeman, feel free to post any thoughts. What are your thoughts
Dennis?
Cheers,
Peter.
Freeman Jackson wrote:
> 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 <ji...@zeus.net.au> 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 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.
>>>
>>>
>>
>
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Freeman Jackson <sy...@gmail.com>.
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 <ji...@zeus.net.au> 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 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.
>>
>
>