On Wed, Nov 19, 2008 at 4:18 PM, frantuma <[EMAIL PROTECTED]> wrote: > > Hi, >> >> I am trying to integrate OSGI and tuscany following info on WIki and >> mailing list. >> >> The goal is to have some sort of "OSGI distributed environment"; the >> framework would be composed of OSGI runtimes running on several network >> nodes with SCA components and composites spanning multiple nodes exposed as >> OSGI services. >> >> The best result would be to have OSGI bundles wired to other OSGI services >> independently from their location, local or remote. Bundle lifecycle would >> be managed by OSGI, while SCA would take care of remote bindings and of >> composite assembly (exposed as OSGI services callable from other bundles >> everywhere in the domain). >> >> Being quite new to both technologies I am still confused about how >> implementing such an integration. From the wiki and mailing list I guess I >> understood that 3 different models are proposed: >> >> 1) Package tuscany runtime modules and 3rd party dependencies as OSGi >> >>> bundles, and use an OSGi runtime such as Felix or Equinox to install/run >>> these bundles. >>> >> >> 2) Package application artifacts into OSGi bundles and contribute them to >> >>> SCA domain as SCA contributions >>> >> >> >> 3) Support OSGi bundle as a component implementation type for Tuscany/SCA, >> >>> expose OSGi services as SCA services and inject references to OSGi >>> services >>> >> >> Could you please help me by answering the following questions? >> >> What would be the best approach for our need? >> >> What would be the "relation/integration" between OSGI and SCA runtime in >> the three models? >> >> thanks a lot >> >> Francesco >> >> >> Adding the issue mentioned in the subject. > > osgi-supplychain sample gives a ClassNotFound when the test or client is > started with ds.composite. IS there any suggestion to make it work? > > WARNING: Unable to resolve bundle 3 (org.osgi.framework.BundleException: > Unresolved package in bundle 3: package; > (package=org.osgi.service.component)) > java.security.PrivilegedActionException: java.lang.ClassNotFoundException: > supplychain.retailer.Retailer > at java.security.AccessController.doPrivileged(Native Method) > > thanks > > Hi Francesco
I'm not an OSGi expert either so you'll have to bear with me a little but let me give you some background on where we are with distributed domains and OSGi support on Tuscany. Reflecting on the questions you ask, there are a number of moving parts that have to be in place to create a running application in Tuscany. 1/ All of the Tuscany runtime jars and 3rd party dependencies. These implement the composite model and runtime required to run SCA applications. The tuscany runtime, when it is run, is able to read SCA contributions; 2/ SCA contributions contain all of the artifacts (.composite file, .class, .wsdl, .xsd etc.) required to run your application. Part of the contribution are the component implementations that provide the business logic of SCA components. Basically the bit the users build 3/ SCA component implementations can be on several different types. Tuscany supports things like implementation.java, implementation.bpel and we did have implementation.osgi going at one stage. In the 1.x codebase, which is our current working code stream, there are a number of OSGi related modules focusing on using OSGi in the three scenarios above. However I'm not sure how functional this support is. We are just starting up work on the 2.x code based. This code base will be an OASIS compliant SCA runtime but also there is a lot of effort going in to making it work properly in an OSGi environment. This is starting by looking at scenario 1 but I guess will move on to look at the other two if people are interested in doing that. The current distributed support allows you to describe an SCA composite application in a number of separate composites (and contributions), have the domain wire references to services and then have the resulting reconfigured composites run on a distributed set of Tuscany nodes (runtimes). I would be interesting to know a little bit about your starting point. For example, are you starting from an exisitng application, is it already OSGi based or is the use of OISGi an aspiration? Commenting on some of what you say sepcifically; "framework would be composed of OSGI runtimes running on several network nodes" - this sounds like the work we are doing to ensure that the tuscan runtime works well in an OSGi environment (scenario 1) "SCA components and composites spanning multiple nodes" - this will rely on our domain suports ability to wire up a composite application in a distribute environment "exposed as OSGI services." - this is interesting as this sounds like you want to use the OSGi programming model within your component implementation. This sounds like implementation.osgi (scenario 3) "The best result would be to have OSGI bundles wired to other OSGI services independently from their location, local or remote. Bundle lifecycle would be managed by OSGI, while SCA would take care of remote bindings and of composite assembly (exposed as OSGI services callable from other bundles everywhere in the domain)." - again this sounds like you want to see the OSGi programming model within an SCA assembly which I think is implementation.osgi Hopefully the above has given you some insight into the 3 different options you listed. The different approaches are othoganal so what you need depends on precisely what your requirment is. Looks like 1 and 3 from what you have said but lets explore what you need a bit more. Hope that helps Simon
