You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Guillaume Nodet <gn...@gmail.com> on 2010/02/15 22:34:13 UTC
[DISCUSS] Applications and subsystems
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 ?
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Applications and subsystems
Posted by David Bosschaert <da...@gmail.com>.
I guess I wasn't thinking so much about increments or exceptions to
the default. I was more thinking that the override would be a complete
redefine rather than a tweak. I guess I see your point a bit better
now. It might be worth working out a few use cases to see whether
tweaking the default is much better than simply redefining the
behaviour.
Thanks,
David
On 25 February 2010 13:14, Graham Charters <gc...@googlemail.com> wrote:
> I think for the 'deviation' model to work, each statement needs to be
> a small incremental progression from the default. I don't yet see how
> that would work. If I have an "all shared" subsystem (type 1), then
> the small increment is to prevent something, whereas, if I have an
> "explicitly shared" subsystem (type 2), then the small increment is to
> allow something (would need to be a different header). I don't think
> we should be allowing any statements about sharing in "application
> subsystems" (type 3).
>
> Maybe you could give me a bit more detail on how you seen the
> increments working?
>
> Regards, Graham.
>
> On 25 February 2010 11:52, David Bosschaert <da...@gmail.com> wrote:
>> Right, the defaults would be different, but I guess there should be a
>> way to deviate from the defaults. Would it not make sense to use the
>> same syntax in use cases 1/3 to describe the deviation from the
>> defaults to what you are using in use case 2?
>>
>> What I'm thinking is: nothing specified -> defaults
>> something specified -> overrides defaults
>>
>> I don't fully understand why you would use different configuration
>> settings for this in options 1/3 just yet...
>>
>> Cheers,
>>
>> David
>>
>> On 25 February 2010 11:16, Graham Charters <gc...@googlemail.com> wrote:
>>> Hi David,
>>>
>>> I think I see it a little differently. If we try to common up the
>>> headers, then we end up with a matrix of rules for which headers are
>>> allowed on which type of 'subsystem'. Take the example you gave
>>> below; for the three types of subsystem I described earlier, only the
>>> second type (Explicitly shared) would ever make statements about the
>>> services that are exported or imported. Types 1 and 3 have different
>>> rules for defaulting what is shared.
>>>
>>> Regards, Graham.
>>>
>>> On 22 February 2010 10:24, David Bosschaert <da...@gmail.com> wrote:
>>>> I'm not entirely sure what you're thinking yet, could you maybe give
>>>> us an example?
>>>>
>>>> I would imagine that configuration entities with the same meaning
>>>> would be configured in the same way across the different types. So you
>>>> define the services that you're exporting using the same header/tag,
>>>> whether this is a subsystem or an application. Or do you see this
>>>> differently?
>>>>
>>>> Best regards,
>>>>
>>>> David
>>>>
>>>> On 19 February 2010 16:04, Graham Charters <gc...@googlemail.com> wrote:
>>>>> I'd been thinking the different sets of manifest. I think the way
>>>>> these types of subsystems will be used will be quite different and
>>>>> subsystem definitions will typically not morph from one type to
>>>>> another. It therefore seems to make sense to emphasise the
>>>>> distinction.
>>>>>
>>>>> On 19 February 2010 15:01, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>> On Fri, Feb 19, 2010 at 15:00, Graham Charters <gc...@googlemail.com> wrote:
>>>>>>> <snip>
>>>>>>> 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.
>>>>>>
>>>>>> I agree with having different default policies. What do you have in
>>>>>> mind as to identify those different use cases from a user point of
>>>>>> view ? Are you thinking about completely different set of manifest
>>>>>> headers ? Or simply one which would contain the "kind" of
>>>>>> application/subsystem defined ?
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [DISCUSS] Applications and subsystems
Posted by Graham Charters <gc...@googlemail.com>.
I think for the 'deviation' model to work, each statement needs to be
a small incremental progression from the default. I don't yet see how
that would work. If I have an "all shared" subsystem (type 1), then
the small increment is to prevent something, whereas, if I have an
"explicitly shared" subsystem (type 2), then the small increment is to
allow something (would need to be a different header). I don't think
we should be allowing any statements about sharing in "application
subsystems" (type 3).
Maybe you could give me a bit more detail on how you seen the
increments working?
Regards, Graham.
On 25 February 2010 11:52, David Bosschaert <da...@gmail.com> wrote:
> Right, the defaults would be different, but I guess there should be a
> way to deviate from the defaults. Would it not make sense to use the
> same syntax in use cases 1/3 to describe the deviation from the
> defaults to what you are using in use case 2?
>
> What I'm thinking is: nothing specified -> defaults
> something specified -> overrides defaults
>
> I don't fully understand why you would use different configuration
> settings for this in options 1/3 just yet...
>
> Cheers,
>
> David
>
> On 25 February 2010 11:16, Graham Charters <gc...@googlemail.com> wrote:
>> Hi David,
>>
>> I think I see it a little differently. If we try to common up the
>> headers, then we end up with a matrix of rules for which headers are
>> allowed on which type of 'subsystem'. Take the example you gave
>> below; for the three types of subsystem I described earlier, only the
>> second type (Explicitly shared) would ever make statements about the
>> services that are exported or imported. Types 1 and 3 have different
>> rules for defaulting what is shared.
>>
>> Regards, Graham.
>>
>> On 22 February 2010 10:24, David Bosschaert <da...@gmail.com> wrote:
>>> I'm not entirely sure what you're thinking yet, could you maybe give
>>> us an example?
>>>
>>> I would imagine that configuration entities with the same meaning
>>> would be configured in the same way across the different types. So you
>>> define the services that you're exporting using the same header/tag,
>>> whether this is a subsystem or an application. Or do you see this
>>> differently?
>>>
>>> Best regards,
>>>
>>> David
>>>
>>> On 19 February 2010 16:04, Graham Charters <gc...@googlemail.com> wrote:
>>>> I'd been thinking the different sets of manifest. I think the way
>>>> these types of subsystems will be used will be quite different and
>>>> subsystem definitions will typically not morph from one type to
>>>> another. It therefore seems to make sense to emphasise the
>>>> distinction.
>>>>
>>>> On 19 February 2010 15:01, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>> On Fri, Feb 19, 2010 at 15:00, Graham Charters <gc...@googlemail.com> wrote:
>>>>>> <snip>
>>>>>> 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.
>>>>>
>>>>> I agree with having different default policies. What do you have in
>>>>> mind as to identify those different use cases from a user point of
>>>>> view ? Are you thinking about completely different set of manifest
>>>>> headers ? Or simply one which would contain the "kind" of
>>>>> application/subsystem defined ?
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>
>>>
>>
>
Re: [DISCUSS] Applications and subsystems
Posted by David Bosschaert <da...@gmail.com>.
Right, the defaults would be different, but I guess there should be a
way to deviate from the defaults. Would it not make sense to use the
same syntax in use cases 1/3 to describe the deviation from the
defaults to what you are using in use case 2?
What I'm thinking is: nothing specified -> defaults
something specified -> overrides defaults
I don't fully understand why you would use different configuration
settings for this in options 1/3 just yet...
Cheers,
David
On 25 February 2010 11:16, Graham Charters <gc...@googlemail.com> wrote:
> Hi David,
>
> I think I see it a little differently. If we try to common up the
> headers, then we end up with a matrix of rules for which headers are
> allowed on which type of 'subsystem'. Take the example you gave
> below; for the three types of subsystem I described earlier, only the
> second type (Explicitly shared) would ever make statements about the
> services that are exported or imported. Types 1 and 3 have different
> rules for defaulting what is shared.
>
> Regards, Graham.
>
> On 22 February 2010 10:24, David Bosschaert <da...@gmail.com> wrote:
>> I'm not entirely sure what you're thinking yet, could you maybe give
>> us an example?
>>
>> I would imagine that configuration entities with the same meaning
>> would be configured in the same way across the different types. So you
>> define the services that you're exporting using the same header/tag,
>> whether this is a subsystem or an application. Or do you see this
>> differently?
>>
>> Best regards,
>>
>> David
>>
>> On 19 February 2010 16:04, Graham Charters <gc...@googlemail.com> wrote:
>>> I'd been thinking the different sets of manifest. I think the way
>>> these types of subsystems will be used will be quite different and
>>> subsystem definitions will typically not morph from one type to
>>> another. It therefore seems to make sense to emphasise the
>>> distinction.
>>>
>>> On 19 February 2010 15:01, Guillaume Nodet <gn...@gmail.com> wrote:
>>>> On Fri, Feb 19, 2010 at 15:00, Graham Charters <gc...@googlemail.com> wrote:
>>>>> <snip>
>>>>> 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.
>>>>
>>>> I agree with having different default policies. What do you have in
>>>> mind as to identify those different use cases from a user point of
>>>> view ? Are you thinking about completely different set of manifest
>>>> headers ? Or simply one which would contain the "kind" of
>>>> application/subsystem defined ?
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>
>
Re: [DISCUSS] Applications and subsystems
Posted by Graham Charters <gc...@googlemail.com>.
Hi David,
I think I see it a little differently. If we try to common up the
headers, then we end up with a matrix of rules for which headers are
allowed on which type of 'subsystem'. Take the example you gave
below; for the three types of subsystem I described earlier, only the
second type (Explicitly shared) would ever make statements about the
services that are exported or imported. Types 1 and 3 have different
rules for defaulting what is shared.
Regards, Graham.
On 22 February 2010 10:24, David Bosschaert <da...@gmail.com> wrote:
> I'm not entirely sure what you're thinking yet, could you maybe give
> us an example?
>
> I would imagine that configuration entities with the same meaning
> would be configured in the same way across the different types. So you
> define the services that you're exporting using the same header/tag,
> whether this is a subsystem or an application. Or do you see this
> differently?
>
> Best regards,
>
> David
>
> On 19 February 2010 16:04, Graham Charters <gc...@googlemail.com> wrote:
>> I'd been thinking the different sets of manifest. I think the way
>> these types of subsystems will be used will be quite different and
>> subsystem definitions will typically not morph from one type to
>> another. It therefore seems to make sense to emphasise the
>> distinction.
>>
>> On 19 February 2010 15:01, Guillaume Nodet <gn...@gmail.com> wrote:
>>> On Fri, Feb 19, 2010 at 15:00, Graham Charters <gc...@googlemail.com> wrote:
>>>> <snip>
>>>> 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.
>>>
>>> I agree with having different default policies. What do you have in
>>> mind as to identify those different use cases from a user point of
>>> view ? Are you thinking about completely different set of manifest
>>> headers ? Or simply one which would contain the "kind" of
>>> application/subsystem defined ?
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
Re: [DISCUSS] Applications and subsystems
Posted by David Bosschaert <da...@gmail.com>.
I'm not entirely sure what you're thinking yet, could you maybe give
us an example?
I would imagine that configuration entities with the same meaning
would be configured in the same way across the different types. So you
define the services that you're exporting using the same header/tag,
whether this is a subsystem or an application. Or do you see this
differently?
Best regards,
David
On 19 February 2010 16:04, Graham Charters <gc...@googlemail.com> wrote:
> I'd been thinking the different sets of manifest. I think the way
> these types of subsystems will be used will be quite different and
> subsystem definitions will typically not morph from one type to
> another. It therefore seems to make sense to emphasise the
> distinction.
>
> On 19 February 2010 15:01, Guillaume Nodet <gn...@gmail.com> wrote:
>> On Fri, Feb 19, 2010 at 15:00, Graham Charters <gc...@googlemail.com> wrote:
>>> <snip>
>>> 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.
>>
>> I agree with having different default policies. What do you have in
>> mind as to identify those different use cases from a user point of
>> view ? Are you thinking about completely different set of manifest
>> headers ? Or simply one which would contain the "kind" of
>> application/subsystem defined ?
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
Re: [DISCUSS] Applications and subsystems
Posted by Graham Charters <gc...@googlemail.com>.
I'd been thinking the different sets of manifest. I think the way
these types of subsystems will be used will be quite different and
subsystem definitions will typically not morph from one type to
another. It therefore seems to make sense to emphasise the
distinction.
On 19 February 2010 15:01, Guillaume Nodet <gn...@gmail.com> wrote:
> On Fri, Feb 19, 2010 at 15:00, Graham Charters <gc...@googlemail.com> wrote:
>> <snip>
>> 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.
>
> I agree with having different default policies. What do you have in
> mind as to identify those different use cases from a user point of
> view ? Are you thinking about completely different set of manifest
> headers ? Or simply one which would contain the "kind" of
> application/subsystem defined ?
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: [DISCUSS] Applications and subsystems
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Feb 19, 2010 at 15:00, Graham Charters <gc...@googlemail.com> wrote:
> <snip>
> 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.
I agree with having different default policies. What do you have in
mind as to identify those different use cases from a user point of
view ? Are you thinking about completely different set of manifest
headers ? Or simply one which would contain the "kind" of
application/subsystem defined ?
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Applications and subsystems
Posted by Graham Charters <gc...@googlemail.com>.
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
co-located.
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 <gn...@gmail.com> 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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org> 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 deployment.mf that is used when
>>>>>> install is called (we call out to a resolver to do this). This
>>>>>> deployment.mf 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 Application.mf is isolated content,
>>>>>> but the Deployment.mf contains additional shared bundles that are
>>>>>> required to support the application.
>>>>>>
>>>>>> What do you think?
>>>>>> Alasdair
>>>>>>
>>>>>> On 16 February 2010 11:21, David Bosschaert <da...@gmail.com> 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 <gn...@gmail.com> 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 <da...@yahoo.com> 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: http://gnodet.blogspot.com/
>>>>>>>>>> ------------------------
>>>>>>>>>> Open Source SOA
>>>>>>>>>> http://fusesource.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Alasdair Nottingham
>>>>>> not@apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alasdair Nottingham
>>>> not@apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: [DISCUSS] Applications and subsystems
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org> 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 deployment.mf that is used when
>>>>> install is called (we call out to a resolver to do this). This
>>>>> deployment.mf 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 Application.mf is isolated content,
>>>>> but the Deployment.mf contains additional shared bundles that are
>>>>> required to support the application.
>>>>>
>>>>> What do you think?
>>>>> Alasdair
>>>>>
>>>>> On 16 February 2010 11:21, David Bosschaert <da...@gmail.com> 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 <gn...@gmail.com> 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 <da...@yahoo.com> 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: http://gnodet.blogspot.com/
>>>>>>>>> ------------------------
>>>>>>>>> Open Source SOA
>>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Alasdair Nottingham
>>>>> not@apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>>
>>>
>>> --
>>> Alasdair Nottingham
>>> not@apache.org
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Applications and subsystems
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gn...@gmail.com> 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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org> 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 deployment.mf that is used when
>>>> install is called (we call out to a resolver to do this). This
>>>> deployment.mf 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 Application.mf is isolated content,
>>>> but the Deployment.mf contains additional shared bundles that are
>>>> required to support the application.
>>>>
>>>> What do you think?
>>>> Alasdair
>>>>
>>>> On 16 February 2010 11:21, David Bosschaert <da...@gmail.com> 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 <gn...@gmail.com> 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 <da...@yahoo.com> 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: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alasdair Nottingham
>>>> not@apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: [DISCUSS] Applications and subsystems
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org> 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 deployment.mf that is used when
>>> install is called (we call out to a resolver to do this). This
>>> deployment.mf 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 Application.mf is isolated content,
>>> but the Deployment.mf contains additional shared bundles that are
>>> required to support the application.
>>>
>>> What do you think?
>>> Alasdair
>>>
>>> On 16 February 2010 11:21, David Bosschaert <da...@gmail.com> 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 <gn...@gmail.com> 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 <da...@yahoo.com> 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: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Alasdair Nottingham
>>> not@apache.org
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Applications and subsystems
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gn...@gmail.com> 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 <no...@apache.org> 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 deployment.mf that is used when
>> install is called (we call out to a resolver to do this). This
>> deployment.mf 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 Application.mf is isolated content,
>> but the Deployment.mf contains additional shared bundles that are
>> required to support the application.
>>
>> What do you think?
>> Alasdair
>>
>> On 16 February 2010 11:21, David Bosschaert <da...@gmail.com> 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 <gn...@gmail.com> 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 <da...@yahoo.com> 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: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: [DISCUSS] Applications and subsystems
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <no...@apache.org> 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 deployment.mf that is used when
> install is called (we call out to a resolver to do this). This
> deployment.mf 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 Application.mf is isolated content,
> but the Deployment.mf contains additional shared bundles that are
> required to support the application.
>
> What do you think?
> Alasdair
>
> On 16 February 2010 11:21, David Bosschaert <da...@gmail.com> 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 <gn...@gmail.com> 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 <da...@yahoo.com> 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: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Applications and subsystems
Posted by Guillaume Nodet <gn...@gmail.com>.
FWIW, currently if the deployment.mf is provided in the archive, it
has to be transitively closed,
i.e. the resolver is not called at all. The list of bundles to be
installed comes either from the
deployment manifest or the resolver at the moment.
On Tue, Feb 16, 2010 at 17:12, David Bosschaert
<da...@gmail.com> wrote:
> On 16 February 2010 13:28, Alasdair Nottingham <no...@apache.org> wrote:
>> So the Application-Content in the Application.mf is isolated content,
>> but the Deployment.mf contains additional shared bundles that are
>> required to support the application.
>>
>> What do you think?
>> Alasdair
>
> So this allows one to describe the transitive closure of all the
> dependencies without forcing them all into the application. Maybe some
> of the shareable dependencies are already there in your framework, in
> which case they're ignored from the Deployment.mf file, right?
> This sounds like a very useful approach to me, especially if you put
> everything in a single .zip file - like the .eba. Just download the
> .eba, install and your done.
>
> Although I also think that in some deployments the Deployment.mf file
> may not be required as all the transitive dependencies could be
> resolved from OBR (I know - OBR doesn't really exist yet, but
> hopefully it will soon). If your system is hooked up to an OBR, the
> dependencies from your application could be resolved from there.
> I guess it depends on how dynamic you want your deployment to be, but
> to me these are both valid scenarios...
>
> Best regards,
>
> David
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Applications and subsystems
Posted by Guillaume Nodet <gn...@gmail.com>.
FWIW, there is an OBR resolver attached as a patch to
https://issues.apache.org/jira/browse/GERONIMO-4971
I'm working on it and I think we should commit it to aries asap.
On Tue, Feb 16, 2010 at 18:25, Alasdair Nottingham <no...@apache.org> wrote:
> On 16 February 2010 16:12, David Bosschaert <da...@gmail.com> wrote:
>> On 16 February 2010 13:28, Alasdair Nottingham <no...@apache.org> wrote:
>>> So the Application-Content in the Application.mf is isolated content,
>>> but the Deployment.mf contains additional shared bundles that are
>>> required to support the application.
>>>
>>> What do you think?
>>> Alasdair
>>
>> So this allows one to describe the transitive closure of all the
>> dependencies without forcing them all into the application. Maybe some
>> of the shareable dependencies are already there in your framework, in
>> which case they're ignored from the Deployment.mf file, right?
>
> That would be the plan, I wouldn't describe it as ignored, but
> installing the bundle would be a no op :)
>
>> This sounds like a very useful approach to me, especially if you put
>> everything in a single .zip file - like the .eba. Just download the
>> .eba, install and your done.
>
> I agree
>
>>
>> Although I also think that in some deployments the Deployment.mf file
>> may not be required as all the transitive dependencies could be
>> resolved from OBR (I know - OBR doesn't really exist yet, but
>> hopefully it will soon).
>
> A Guillaume notes if the .eba has a the deployment.mf we don't go to
> OBR. This is so we can get some level of consistency between
> JVM/Frameworks. The idea would be you resolved once, save the file to
> disk and use the "resolved" file.
>
>> If your system is hooked up to an OBR, the
>> dependencies from your application could be resolved from there.
>> I guess it depends on how dynamic you want your deployment to be, but
>> to me these are both valid scenarios...
>>
>
> Right now we don't have a Resolver implementation that uses OBR, but
> that is definitely possible, and was the intent. When Mark committed
> the code we were thinking OBR, but wanted to get the AriesApplication
> interfaces available even if the Resolver wasn't done.
>
> If you want dynamic you get an OBR implementation of Resolver and use
> an EBA without a deployment.mf. We generate the deployment.mf which is
> held in memory.
>
>> Best regards,
>>
>> David
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Applications and subsystems
Posted by Alasdair Nottingham <no...@apache.org>.
On 16 February 2010 16:12, David Bosschaert <da...@gmail.com> wrote:
> On 16 February 2010 13:28, Alasdair Nottingham <no...@apache.org> wrote:
>> So the Application-Content in the Application.mf is isolated content,
>> but the Deployment.mf contains additional shared bundles that are
>> required to support the application.
>>
>> What do you think?
>> Alasdair
>
> So this allows one to describe the transitive closure of all the
> dependencies without forcing them all into the application. Maybe some
> of the shareable dependencies are already there in your framework, in
> which case they're ignored from the Deployment.mf file, right?
That would be the plan, I wouldn't describe it as ignored, but
installing the bundle would be a no op :)
> This sounds like a very useful approach to me, especially if you put
> everything in a single .zip file - like the .eba. Just download the
> .eba, install and your done.
I agree
>
> Although I also think that in some deployments the Deployment.mf file
> may not be required as all the transitive dependencies could be
> resolved from OBR (I know - OBR doesn't really exist yet, but
> hopefully it will soon).
A Guillaume notes if the .eba has a the deployment.mf we don't go to
OBR. This is so we can get some level of consistency between
JVM/Frameworks. The idea would be you resolved once, save the file to
disk and use the "resolved" file.
> If your system is hooked up to an OBR, the
> dependencies from your application could be resolved from there.
> I guess it depends on how dynamic you want your deployment to be, but
> to me these are both valid scenarios...
>
Right now we don't have a Resolver implementation that uses OBR, but
that is definitely possible, and was the intent. When Mark committed
the code we were thinking OBR, but wanted to get the AriesApplication
interfaces available even if the Resolver wasn't done.
If you want dynamic you get an OBR implementation of Resolver and use
an EBA without a deployment.mf. We generate the deployment.mf which is
held in memory.
> Best regards,
>
> David
>
--
Alasdair Nottingham
not@apache.org
Re: [DISCUSS] Applications and subsystems
Posted by David Bosschaert <da...@gmail.com>.
On 16 February 2010 13:28, Alasdair Nottingham <no...@apache.org> wrote:
> So the Application-Content in the Application.mf is isolated content,
> but the Deployment.mf contains additional shared bundles that are
> required to support the application.
>
> What do you think?
> Alasdair
So this allows one to describe the transitive closure of all the
dependencies without forcing them all into the application. Maybe some
of the shareable dependencies are already there in your framework, in
which case they're ignored from the Deployment.mf file, right?
This sounds like a very useful approach to me, especially if you put
everything in a single .zip file - like the .eba. Just download the
.eba, install and your done.
Although I also think that in some deployments the Deployment.mf file
may not be required as all the transitive dependencies could be
resolved from OBR (I know - OBR doesn't really exist yet, but
hopefully it will soon). If your system is hooked up to an OBR, the
dependencies from your application could be resolved from there.
I guess it depends on how dynamic you want your deployment to be, but
to me these are both valid scenarios...
Best regards,
David
Re: [DISCUSS] Applications and subsystems
Posted by Alasdair Nottingham <no...@apache.org>.
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 deployment.mf that is used when
install is called (we call out to a resolver to do this). This
deployment.mf 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 Application.mf is isolated content,
but the Deployment.mf contains additional shared bundles that are
required to support the application.
What do you think?
Alasdair
On 16 February 2010 11:21, David Bosschaert <da...@gmail.com> 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 <gn...@gmail.com> 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 <da...@yahoo.com> 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: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
--
Alasdair Nottingham
not@apache.org
Re: [DISCUSS] Applications and subsystems
Posted by David Bosschaert <da...@gmail.com>.
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 <gn...@gmail.com> 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 <da...@yahoo.com> 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: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: [DISCUSS] Applications and subsystems
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <da...@yahoo.com> 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: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Applications and subsystems
Posted by David Jencks <da...@yahoo.com>.
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: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com