[
https://issues.apache.org/jira/browse/KARAF-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090825#comment-13090825
]
Ioannis Canellos edited comment on KARAF-823 at 8/25/11 7:28 AM:
-----------------------------------------------------------------
Please let me share what I had in mind. By dosgi I am referring to remote
services (as described in the osgi compendium chapter 13) and not to a
specific implementation (e.g. cxf dosgi).
Since cellar already provides a) a node discovery mechanism b) means to
dispatch events, commands to remote nodes and c) distributed memory (which
can be used as a remote service registry), I was thinking to implement the
specification (or at least a part of it) on top of cellar.
I also have thought about using an existing implementation like cxf-dosgi,
and r-osgi, but I think that they don't fit well because simply they are
build from scratch (from discovery mechanism to transport layer etc).
Regarding the implementation, what I had in mind is to implement a service
listener that will create a queue (hazelcast queue) for each interface of
the exported service. A ListenerHook that will register a proxy for each
imported service (service that is not found locally but is found remotely).
And the actual proxy that will dispatch remote service call commands (cellar
commands) to the appropriate queue. The rest are already provided by
celllar.
I have implemented the above and also some samples and I am currently
testing it. So far it seems to be working fine, it requires no configuration
(only a property to mark a service as remote), it automatically scales (if
you add more nodes that export the service it automatically load balances
the load etc) and does not introduces any other dependency.
I was thinking to commit it to trunk by the end of the week. wdyt?
was (Author: iocanel):
Please let me share what I had in mind. By dosgi I am referring to remote
services (as described in the osgi compendium chapter 13) and not to a
specific implementation (e.g. cxf dosgi).
Since cellar already provides a) a node discovery mechanism b) means to
dispatch events, commands to remote nodes and c) distributed memory (which
can be used as a remote service registry), I was thinking to implement the
specification (or at least a part of it) on top of cellar.
I also have thought about using an existing implementation like cxf-dosgi,
and r-osgi, but I think that they don't fit well because simply they are
build from scratch (from discovery mechanism to transport layer etc).
Regarding the implementation, what I had in mind is to implement a service
listener that will create a queue (hazelcast queue) for each interface of
the exported service. A ListenerHook that will register a proxy for each
imported service (service that is not found locally but is found remotely).
And the actual proxy that will dispatch remote service call commands (cellar
commands) to the appropriate queue. The rest are already provided by
celllar.
I have implemented the above and also some samples and I am currently
testing it. So far it seems to be working fine, it requires no configuration
(only a property to mark a service as remote), it automatically scales (if
you add more nodes that export the service it automatically load balances
the load etc) and does not introduces any other dependency.
I was thinking to commit it to trunk by the end of the week. wdyt?
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
Apache Gora <http://incubator.apache.org/gora/> Committer
*
> Add DOSGi support for Cellar
> ----------------------------
>
> Key: KARAF-823
> URL: https://issues.apache.org/jira/browse/KARAF-823
> Project: Karaf
> Issue Type: New Feature
> Components: cellar-core
> Reporter: Ioannis Canellos
> Assignee: Ioannis Canellos
> Fix For: cellar-3.0.0
>
>
> It would be nice to have the ability to have distributed services on top of
> cellar.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
