aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <>
Subject Re: [DISCUSS] Applications and subsystems
Date Tue, 16 Feb 2010 13:28:11 GMT
I haven't been following the subsystem work in the alliance as closely
as you (Graham Charters has, but is on vacation this week so it'll be
interesting to see his thoughts when he gets back next week), but
based on my understanding I also see applications as a specialisation
of subsystems, and I do think that aries should support both
applications, and the more general sub-system solution. I also see a
strong affinity between an application and a composite bundle.

On the subject of applications being self contained I have a slightly
different view, in fact I was going to send an email today about
contributing some improvements. I'll try to explain my thoughts here
(let me know if it needs a different discussion thread). I'm going to
talk about this in terms of composite bundles, because that best
describes what I am trying to achieve.

The Application-Content of an application describes the isolated, or
core, content of the application. When an application is installed a
composite bundle is created and the bundles in the Application-Content
are installed into the composite. The application may need additional
packages or services that are not provided by the core content. This
is also possible and bundles that provide those packages are installed
outside the application composite and can be shared with other

This is not reflected in our current implementation, but I was going
to propose adding it in. I was not planning on changing the
Application.MF, it would still have the application-content as it is
today, but when you call createApplication on the
AriesApplicationManager we generate a that is used when
install is called (we call out to a resolver to do this). This currently contains a Deployed-Content header which
contains all the bundles in Application-Content, but ties them down to
a specific version. In addition to doing this I was going to add a
header named "Provision-Bundle" which denotes bundles that are needed
to support the application-content. These bundles would be installed
into the host framework and be shared with other applications.

So the Application-Content in the is isolated content,
but the contains additional shared bundles that are
required to support the application.

What do you think?

On 16 February 2010 11:21, David Bosschaert <> wrote:
> Yeah, maybe we need to tidy up the terminology a bit and come to
> agreement on that, I think Guillaume's clarification helps.
> In my opinion it would be nice if Aries could provide both models. The
> shared subsystem building block one as well as the more isolated
> application one. Since I tend to think about Applications as a
> specialization of a subsystem it should be possible to do this quite
> naturally.
> Just my thoughts,
> David
> On 15 February 2010 22:21, Guillaume Nodet <> wrote:
>> Are you talking about nested framework instead of subsystems ?
>> Subsystems are currently defined by RFC 152 and nested frameworks by RFC 138.
>> My understanding is that applications as they stand are meant to be
>> self-contained (or mostly) and isolated,
>> whereas subsystems can be considered more as building blocks with
>> sharing capabilities
>> The way applications or subsystems can be isolated could be done using
>> nested frameworks or manifest rewriting for example.
>> On Mon, Feb 15, 2010 at 22:58, David Jencks <> wrote:
>>> On Feb 15, 2010, at 1:34 PM, Guillaume Nodet wrote:
>>>> Aries applications model is quite similar to the subsytem model being
>>>> discussed in the OSGi EEG.
>>>> I'd like to think that subsytems are more generic than applications,
>>>> or said another way, that applications
>>>> are specialization of subsystems.  Subsystems allow reference to other
>>>> subsystems, scoping, etc...
>>>> I'd like to see how we can make both fits together.  I guess the first
>>>> question to solve it whether we want
>>>> to keep applications the way they are, without advanced features
>>>> provided by subsystems such as
>>>> sharing / scoping, dependencies on other subsytems, etc...
>>>> Once we've answered that, we can think about the way we want to support
>>>> both.
>>>> Thoughts ?
>>> My point of view.... perhaps shared by no one else.... is that an
>>> application would be deployed or installed into a particular subsystem, but
>>> that several apps and plain bundles can all be installed into a single
>>> subsystem.  I'm thinking of an application as a way to deploy a set of
>>> bundles at once, where the "maven-like" dependencies aren't specified, and
>>> where the framework has a way to resolve the osgi dependencies into
>>> maven-like dependencies.
>>> I don't think this idea is expressed in the current code in any way.
>>> thanks
>>> david jencks
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog:
>>>> ------------------------
>>>> Open Source SOA
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog:
>> ------------------------
>> Open Source SOA

Alasdair Nottingham

View raw message