5:21 p.m.
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
11:33 p.m.
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
3:59 p.m.
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
12:01 a.m.
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
4064
days inactive
4067
days old
3 comments
2 participants
participants (2)
-
Andrig Miller -
Thomas Diesler