Hi Andy,

I talked about this in Brno a couple of times - not sure whether you were in the room/bar though ;-)

My idea would be the that the Core Runtime has


Today we wire stuff together by creating hard coded links between modules/components (in modules.xml). Hence tightly coupling stuff such that you cannot reason about A without taking B into consideration.

A future model could be more declarative. Every component, subsystem, abstract feature, etc could declare its respective capabilities/requirements. Today we already have a Resource API that talks about generic caps/reqs and associates them to resources, which can be an abstract resources that combine other resources. All resources live together with their associated caps/reqs in a Repository, for which we also have an API and a RI. The missing piece is a Provisioning Service that you can give a set of requirements (i.e. the feature(s) you want to provision). The Provisioning Service would go to the Resolver (which we also have) to find a consistent solution that provides the wanted set of capabilities. The resolver takes capabilities that already exist in the runtime into account and ultimately provisions additional resources from the repository such that the wanted feature(s) become available. IMHO, this should not be a human decision - for a complex system it could quickly become impossible for a human to make the correct decisions such that the wiring is consistent.

From the user perspective, the Core Runtime could have an SSH endpoint that you can connect to using your favourite SSH client (i.e. no proprietary client app). You could say

> add feature webservices,ejb3,configadmin

These would be abstract requirements that cause the webservice, ejb3, osgi subsystems (including their transitive set of dependencies) to get provisioned. The Resolver would know about the set of capabilities that are already available in the runtime and would provision only the missing delta from the repository. It would do a no-impact analysis first, i.e. try to find out if there is a consistent solution before anything gets provisioned which modifies the Runtime.

The resulting wiring between the components would be persisted (like in modules.xml) such that on subsequent startups we get an identical wiring and no performance impact. Such highly pluggable system would be nice for developers that only want the subsystems that they really need, but would probably be not so applicable for layered products. However productisation people could use the same mechanism to define their product stack and be sure that for the given set of features they only have the necessary set of binaries in the distribution with a guaranteed accurate wiring between them. 

What is described above for runtime, could also happen at build time. The productisation folks would give the set of wanted product features to the build. The result of the build would again be a distribution that only contains the necessary set of binaries with a guaranteed accurate wiring between them.

A side effect of this is that component, subsystem, abstract feature, etc can have an independent development lifecycle of each other and become more loosely coupled. An individual piece only needs to reason about its own capabilities and requirements. It is the job of a central, non-human authority (i.e. the Resolver) to bring everything together in a consistent way.

In a nutshell: Product features would be defined as abstract resources with associated caps/reqs and live in a repository. A provisioning service connects the resolver with the repository and can provision additional features/resources to the runtime taking existing resources and their wiring into account. This can be done at build time and guarantees a small as possible and consistent distribution. The process is also highly agile and can react quickly to changing product requirements.

If wanted I could talk lots about the details of this, but thats a little premature I guess. 

Good Luck in New Castle
--thomas 

On Mar 8, 2013, at 11:33 PM, Andrig Miller <anmiller@redhat.com> wrote:

This is a great topic, but it might be a couple of weeks premature.

During the FY'14 kickoff meetings in NewCastle, we will be discussing this topic, from the idea of having a core/base that all products, including EAP would be layered on top of.

I am responsible for presenting this basic idea, and have done some work already on understanding what I think that core or base infrastructure would look like.

Having said that, my general idea is that the base or core infrastructure would consist of the MSC/and domain components (along with others) that form the basis of a runtime and a management layer, with one management and configuration API.  Everything else would layer on top of that, and share the same management layer below.

Andy

From: "Thomas Diesler" <thomas.diesler@jboss.com>
To: "Brian Stansberry" <brian.stansberry@redhat.com>, "Guillaume Nodet" <gnodet@redhat.com>
Cc: "jboss-as7-dev@lists.jboss.org Development" <jboss-as7-dev@lists.jboss.org>, osgi-wrk-grp@redhat.com
Sent: Friday, March 8, 2013 9:21:33 AM
Subject: [jboss-as7-dev] Configuration/management functionality AS/Fuse

Hi Brian/Guillaume,

in the OSGi Working Group kick-off meeting I proposed a line of thought does goes like this:

  • AS can be seen as an R5 compliant Core Framework that can be bootstrapped like any other compliant framework. We can take proper behaviour of the OSGi API layer for granted and can therefore safely assume that the Core Framework that Karaf currently runs on (i.e. Felix) can be replaced by AS. 
  • For long term consolidation of the two product lines (i.e. EAP & Fuse) there are two functional areas key: management and configuration
  • There should be one way to configure the various subsystems that run on the platform
  • There should be one API for managing the platform
  • The consolidation effort could initially focus on these two areas and aim to elliminate functional overlap and conflicts

In parallel to the general requirement gathering I'd like to start a conversation about the respective management/configuration functionality in the two product lines and initially identify the overlap/conflicts. Perhaps we could start with the easier of the two (i.e. configuration) and hear from each other how this currently works. 

  • How are Fuse products configured?
  • How does AS unified configuration work?

The goal would be to come up with a specific set of requirements for the target platform that accommodates the configuration needs for both product lines. We could then have a simmilar approach for the management layer.

What do you think?

cheers
--thomas
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx




_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx