Hi Simon, Raymon
Thanks for the quick responses. Comments inline... Thanks, Philipp From: Raymond Feng [mailto:enjoyj...@gmail.com] Sent: Wednesday, February 11, 2009 5:39 PM To: dev@tuscany.apache.org Subject: Re: Distributed OSGi, Dynamic wiring More comments in line. Thanks, Raymond From: Simon Laws <mailto:simonsl...@googlemail.com> Sent: Wednesday, February 11, 2009 12:53 AM To: dev@tuscany.apache.org Subject: Re: Distributed OSGi, Dynamic wiring Hi Philipp a) With 2.x branch became a base technology for Tuscany runtime. What are the plans about supporting the upcoming Distributed OSGi (RFC 119) standard? Any activities going on currently? Sources in trunk to play with? Would be good to have Tuscany/SCA play the role of the distirbution layer underneath OSGi. Nothing happening yet in Tuscany as far as I know. I have RFC 119 on the radar but nothing has happened yet. It is a great idea to have Tuscany/SCA be a distribution layer for RFC 124. At this moment, we are building the Tuscany runtime with OSGi as the infrastructure. And we will move up into the application level to support RFC 119. If you are interested in this area, I would be glad to help. [Konradi, Philipp] Yeah, definitely. Though Tuscany already now supports OSGi contributions (implementation.osgi), I see a lot of advantages in supporting the upcoming Distributed OSGi standard, which defines integration of any middleware into an OSGi container. I think many developers of OSGi-based apps would like to use on-board means if they exist. And at the latest after EclipseCon, there will be many people looking for RFC119-supporting middleware solutions. Tuscany with its flexibility, SCA-support, rich set on supported bindings and running on top of OSGi itself could be a great alternative for them. The Discovery parts of RFC 119 could also be interesting for Tuscany to interop with other infrastructures e.g. other SCA-runtimes (Inter-Domain-Interop), a use case which is not so rarely in big companies. Tuscany might make use of an existing Discovery Service implementation for this purpose (I'm actually involved in implementation of one and which is planned to be open-sourced at ECF, Eclipse Communication Framework, soon). Not sure whether I can contribute a lot to the coding, but as somebody who worked in the RFC 119 team and in Discovery Reference Implementation I can for sure help in spec clarifications, in discussions on the mailing list, check compliance and be a beta tester. b) Does Tuscany supports already dynamic wiring between components e.g. when a service goes down, that a client consuming that service get rewired to another service instance? Not at the moment. Our domain is static to the extent that all contributions must be present and endpoints resolved before you start any nodes. A way of providing some resilience with this scheme is to run a node in a cluster and rely on a network sprayer to do the re-routing for you. We are looking at refactoring our endpoint support as we've had requests to support later binding from various people. Just about to start in 2.x [Konradi, Philipp] Many of the projects I know require beside the availability requirements also addition, update and removal of components/whole nodes at a later point in time and restart the whole domain is unfortunately not an option for them. I look forward to 2.x. Are you mostly focusing on the OSGi environment to have Tuscany support dynamic wiring? For example, SCA contributions are packaged as OSGi bundles and they can be installed/uninstalled. Then some of the SCA domain-level wiring needs to be synchronized upon these events. Or do you look into a broader scope, such as a set of nodes that form a group (using a p2p protocol) which represents the SCA domain and they exchange metadata within the group? As the configuration changes, the SCA domain needs to rewire the components dynamically. [Konradi, Philipp] Actually we have both use cases in our focus. If you've got ideas feel free to jump in. [Konradi, Philipp] We've used discovery / distributed registry for this purposes. When a service starts up or is shutdown, this is published to all other nodes of the system. Those node check whether some service reference can be satisfied now or need to be rewired to another existing service. The knowledge about other existing services can also be used by service proxies to switch transparently to another service if the one they called failed, or for load-balancing purposes (kind of client-side load-balancing). Such proxies can be called kind of smart-proxies. I could imagine support for such smart proxies in Tuscany as well and intents would be great to do that e.g. configuring "automatic-fail-over" intent on service reference makes the proxy behave in the required way, releasing business logic to take care of such issues. Does Tuscany use some kind of dynamic distributed registry internally? BTW: It might be worth a thought to use RFC 119 discovery service for that purposes (incl. distribution of domain metadata) since 2.x branch is anyway based on OSGi. Simon
