aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [DISCUSS] Applications and subsystems
Date Tue, 16 Feb 2010 16:20:13 GMT
IIRC, we had some discussions around that on a subsystems conference call.
I think the outcome was roughly that we may want to support three modes:
   * all shared
   * all private
   * mixed content

It should be quite simple using a global flag somehow which could be
overriden for some specific bundles.  Shared would mean to install in the
main framework, while private would mean that the bundles would be
installed in a composite bundle.

I also think we need the same kind of flags at package and service
level so that one
can control what services and packages will be visible from outside
the composite

The approach you propose has the limitation of not being able to
deploy an application
in an all-shared environment IIUC.

On Tue, Feb 16, 2010 at 14:28, Alasdair Nottingham <> wrote:
> 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
> applications.
> 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?
> Alasdair
> 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

Guillaume Nodet
Open Source SOA

View raw message