Hi Francesco Comments in line
Regards Simon On Thu, Nov 20, 2008 at 4:57 AM, frantuma <[EMAIL PROTECTED]> wrote: > Hi Simon > > thanks for the clarifying answer. > > You are right, one of the issue here is that requirements are somehow > unclear: the "application" I am working on is a EC project in the area of > information services for freight transportation in Europe basing on a > high-high level idea of "intelligent cargo". > > What are going to be the functional requirements of the project is to the > moment not clarified; this is the because of the very nature of the project, > which assembles in subsequent iterations requirements and use cases from > several partners of the project. This from one point of view ..Concurrently > in the opposite direction - not to be stuck in project evolution and to > unify business view with the technical reality - an infrastructure to host > all future applications/services and to bind them is being built base on the > fixed points currently identified. > > Briefly, the domain of the projects will: > > A. be composed of several physical devices, both with high and low > resources (PDAs, mobile phones, dedicated mobile, HW, etc.). > B. these will be linked in a discontinuous and erratic ways with different > network topologies and protocols > C. sensors and actuators will be attached to the devices and will need to > exchange data with the rest of the system > D. internal applications will need to be plugged in easily into the > infrastructure and communicate with possibly all other services and nodes. > E. external application will need to interact with the system as well > F. different security and authentication domains ar going to be involved. Sounds like a really interesting project! > > > To be able to set up an infrastructure able to handle requirements > inferable from the points above OSGI and SCA seemed to be a good choice. > OSGI seemed to me able to handle the dynamic wiring and discovering of > bundles (=services=applications=devices) through the registry mechanism, the > remote management and classloading model. > > SCA seemed good at: > - group components into distributed composites with mutual references and > sync/async bindings to handle complex business cases > - handling remote component bindings > - handling C++, BPEL or other languages pieces of software needed to be > executed on the nodes > Sounds like you have the right model in your head. > > > Other OSGI and SCA capabilities are interesting as well (policies, > security, etc.) but I don't have yet at all a complete view. > > the main "integration point" imo would be adding dynamic wiring to SCA > composites, the area fulfilled partly (single VM) by OSGI as far as I > understand. > Agreed. We can wire up a domain automatically at the moment using out domain manager function. The thing that is lacking is the ability to change the wiring without stopping all the nodes and restarting them. This is certainly an area I'm interested in. > > >From what you explained I guess as you said that scenario 1 is the base > for such an integration. > > Scenario 3 would allow existing OSGI bundles to: be part of a SCA composite > and reference local and remote SCA components. > If I am correct however dynamic availability is not possible in this > scenario: references within the SCA composite are not dynamically wired and > rewired when for examples new services are available. Currently references and services are wired when the domain is brought up but are not rewired until a node is restarted. We should look at making the wiring more dynamic. All help is much appreciated;-) > > > As understood so far (main source: Power Combination: SCA, OSGi and Spring > at http://www.osoa.org/display/Main/SCA+Resources) SCA non OSGI > components could reference and be referenced by OSGi native bundles through > the implementation of some OSGi binding. With this mechanism SCA We used to have an OSGi binding but it went away for some reason. You can imagine that a component with and implementation.osgi e.g. something like <component name="MyOSGIComponent"> <implementation.osgi bundle="MyOSGiBundle"/> <service name="MyService"? <binding.ws/> </service> <reference name="myReference"> <bining.ws/> <reference> </component> Could arrange to have its service registered in the OSGi registry so that it is available locally (it's already available remotely via the SCA binding). On the reference side the reference here indicates that a remote service will be contacted so SCA could populate the local registry with SCA proxies to the remote SCA service. As the reference defines the contract that the SCA component thinks should be in place for this bundle there is probably no need to reinstate binding.osgi but I'm interested in you views here. As an aside I think the OSGi Enterprise Expert Group ( http://www.osgi.org/EEG/HomePage) is thinking about such distributed scenarios so It'l be interesting to see what comes out of that. > components would be able to register to OSGI registry, invoke OSGi > services and participate in the OSGi service discovering and life cycle > management mechanism, within machine boundaries. > Some other binding would be needed (I guess i.e. Newton is using Jini > binding) to span references across machine boundaries. Still unclear how > remote dynamic wiring would be handled. In SCA the natural choice would be to use the default SCA binding which manages local and remote communications transparently but of course you can choose a specific binding if required. > > > If I am correct about this point, a question would be if there is any > effort going on in this area. I can imagine this will be an area of interest as we continue bring up the 2.x code base. Also anyone is welcome to come in and help shape these kinds of features. > > thanks for your help > > Francesco > > > > > Simon Laws wrote: > >> >> 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 >> >> >> >
