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 Fri, 19 Feb 2010 13:46:01 GMT
I'm sorry but I'm not sure what you are reluctant to introduce as a
result it is difficult for me to comment.

On 18 February 2010 21:24, Guillaume Nodet <> wrote:
> Fwiw, I'm a little reluctant to introduce such a mechanism given I
> think it does not support all the use cases.
> If you consider the application as a composite with external
> dependencies, what we want to do is be able to draw the boundaries
> between what should be inside the composite and what should be
> outside, but also  what needs to be imported and what's need to be
> exported.   Exporting is quite important since you may want to have
> services and packages defined by the application being visible to
> other applications.
> I think we need to support having applications being completely shared
> (including the application content) or completely isolated (including
> all the dependencies).  But we should look for something both powerful
> and easy to use for the common cases.
> What about using osgi headers such as Import-Package / Export-Package,
> Import-Service / Export-Service for that.
> If a package that is a dependency is in the Import-Package list, this
> means it should come from outside the composite, else the bundle
> should be installed inside the composite and isolated.   Same for
> services.
> On Tue, Feb 16, 2010 at 18:21, Alasdair Nottingham <> wrote:
>> I think perhaps this is where a subsystem is different from an
>> application, but I'm a little out of my depth here having not been on
>> the subsystem calls or having read the RFC/RFP.
>> Alasdair
>> On 16 February 2010 16:20, Guillaume Nodet <> wrote:
>>> 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
>>> bundle.
>>> 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 <>
>>>>> 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
>>>>>> 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
>>>>>> nested frameworks or manifest rewriting for example.
>>>>>> On Mon, Feb 15, 2010 at 22:58, David Jencks <>
>>>>>>> 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
>>>>>>> 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,
>>>>>>> where the framework has a way to resolve the osgi dependencies
>>>>>>> maven-like dependencies.
>>>>>>> I don't think this idea is expressed in the current code in any
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog:
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog:
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>> --
>>>> Alasdair Nottingham
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog:
>>> ------------------------
>>> Open Source SOA
>> --
>> Alasdair Nottingham
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> Open Source SOA

Alasdair Nottingham

View raw message