snip... >>> A SCA OSGi Binding can enable interworking between SCA components and OSGi >>> services >> >> I'd like to understand the scenario in a little more detail. Do you >> mean here that an SCA component and a Non-SCA OSGi based service will >> be interacting within the same JVM? >> >> Simon >> > > My understanding of binding.osgi is that is what it does. The OSGi > service implementations live in the same JVM, but are outside the > management of SCA. This, for me, makes it seem like a slightly > strange binding (from an SCA perspective), but it may make sense from > an OSGi-centric perspective. >
That's why I was asking the question as I'd like to understand when a user would choose to use binding.osgi vs implementation.osgi say. The specific scenario that comes to mind is... Start tuscany runtime in an OSGi container This OSGi contain may hold other bundles which are nothing to do with SCA but which may of course expose services via the OSGi registry Contribution is made which contains a composite that wishes to reference these non-OSGi services. It seems similar to the difference between implementation,ejb and binding.ejb to me. However what about the service side. In SCA terms it would be natural to be able to add a binding.osgi to an SCA service and have that appear in the local OSGi registry in order that non-SCA OSGi bundles can access it. Am not a supporter or detractor at the moment but want to understand how we would recommend people exploit such a feature if we had it. Simon
