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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> 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 <[email protected]> >>>>>>>> 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 >>>>>> [email protected] >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Guillaume Nodet >>>>> ------------------------ >>>>> Blog: http://gnodet.blogspot.com/ >>>>> ------------------------ >>>>> Open Source SOA >>>>> http://fusesource.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Alasdair Nottingham >>>> [email protected] >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> >> >> >> >> -- >> Alasdair Nottingham >> [email protected] >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
