aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Charters <>
Subject Re: [DISCUSS] Applications and subsystems
Date Fri, 19 Feb 2010 14:00:01 GMT
I think there are three classes of 'subsystem', that I can almost map
to those listed by Guillaume.

1. All shared - this is more of an administrative concept, having not
influence over package/service resolution.  Karaf Features would be a
good example of this kind of subsystem.
2. Explicitly shared - this is like a coarse-grained bundle, just like
a composite bundle.  By default, nothing is exported or imported.
Selective importing/exporting allows the subsytem to have private
internals and be explicit about its externals (it's a modularity thing
;-) ).  These subsystems could then be further assembled by inclusion
in other subsystems or through package dependencies.
3. Application - this supports a common pattern for applications where
nothing is shared out, and any dependencies not satisfied inside the
subsystem are automatically pulled in from outside.  This type of
subsystem could be achieved through 2, but is far easier for a
developer to specify because it provides useful defaults.  I think
assembly of this class of subsystem more in the realm of distributed
services.  If we do local service integration between applications
with pass-by-reference interactions, then we force the two to be

I think what we have so far is the basics of 3.  We should aim for
consistency across all three, but I think the sharing policy defaults
need to remain separate.  If we were to choose just one policy, then
we will force the others into expressing a lot of unnecessary
information.  We could broaden Application to cover all three, but I
think that would be confusing.  Maybe there are other forms of
subsystem for the different sharing policies, where each is
specialized for the useful defaults.

On 19 February 2010 13:52, Guillaume Nodet <> wrote:
> I'm talking about the mechanism by which anything that comes from the
> Application-Content header would be isolated while all other computed
> dependencies from the resolver would be shared.
> This may be a good default behavior, but I don't think it's
> sufficient.  I'd like to discuss a possible way to solve the problem
> globally.
> On Fri, Feb 19, 2010 at 14:46, Alasdair Nottingham <> wrote:
>> 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
>>>>> 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
>>>>> 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 <>
>>>>>> 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
>>>>>> 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
>>>>>> 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
>>>>>> 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,
>>>>>> core, content of the application. When an application is installed
>>>>>> 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
>>>>>> today, but when you call createApplication on the
>>>>>> AriesApplicationManager we generate a that is used
>>>>>> 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
>>>>>> a specific version. In addition to doing this I was going to add
>>>>>> 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
>>>>>>> agreement on that, I think Guillaume's clarification helps.
>>>>>>> In my opinion it would be nice if Aries could provide both models.
>>>>>>> shared subsystem building block one as well as the more isolated
>>>>>>> application one. Since I tend to think about Applications as
>>>>>>> specialization of a subsystem it should be possible to do this
>>>>>>> naturally.
>>>>>>> Just my thoughts,
>>>>>>> David
>>>>>>> On 15 February 2010 22:21, Guillaume Nodet <>
>>>>>>>> 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
>>>>>>>> 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 <>
>>>>>>>>> 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
>>>>>>>>>> provided by subsystems such as
>>>>>>>>>> sharing / scoping, dependencies on other subsytems,
>>>>>>>>>> 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
>>>>>>>>> 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
>>>>> --
>>>>> 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

View raw message