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.
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
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.
>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.
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
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.
If I am correct about this point, a question would be if there is any
effort going on in this area.
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
