I think we are generally in agreement here, in terms of the base/core runtime that
everything layers on top of.
I have more than just the two things you have below in the base/core, but that really
because to have the management layer, you also have to have some basic networking and
security components, and some other things to make it actually function.
I'll leave the "how we actually layer additional capabilities that make up our
platforms" to everyone else.
If we can agreement on the base/core, at least conceptually, then we will be a very good
place. Based on my own research into the existing modules, and how they are structured,
there is some work that has to be done to refactor things (pull some things apart) to
accomplish this, but in the end it doesn't appear to be rocket science.
Andy
----- Original Message -----
From: "Thomas Diesler" <thomas.diesler(a)jboss.com>
To: "Andrig Miller" <anmiller(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, "Brian
Stansberry" <brian.stansberry(a)redhat.com>, "Guillaume Nodet"
<gnodet(a)redhat.com>
Sent: Monday, March 11, 2013 8:59:27 AM
Subject: Re: [jboss-as7-dev] Configuration/management functionality
AS/Fuse
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
> ----- Original Message -----
> > 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