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
General unified Configuration/Management functionality
Logging functionality
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(a)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(a)jboss.com>
To: "Brian Stansberry" <brian.stansberry(a)redhat.com>, "Guillaume
Nodet" <gnodet(a)redhat.com>
Cc: "jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>, osgi-wrk-grp(a)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(a)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