On 11/07/2014 04:53 PM, Vojtech Szocs wrote:
----- Original Message -----
From: "Yair Zaslavsky" <[email protected]>
To: "Alon Bar-Lev" <[email protected]>
Cc: "Vojtech Szocs" <[email protected]>, "Mark Proctor" <[email protected]>,
[email protected]
Sent: Wednesday, November 5, 2014 9:40:05 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
----- Original Message -----
From: "Alon Bar-Lev" <[email protected]>
To: "Vojtech Szocs" <[email protected]>
Cc: "Mark Proctor" <[email protected]>, [email protected]
Sent: Wednesday, November 5, 2014 6:16:15 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
----- Original Message -----
From: "Vojtech Szocs" <[email protected]>
To: "Alon Bar-Lev" <[email protected]>
Cc: [email protected], "Mark Proctor" <[email protected]>
Sent: Wednesday, November 5, 2014 6:07:50 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
----- Original Message -----
From: "Alon Bar-Lev" <[email protected]>
To: "Vojtech Szocs" <[email protected]>
Cc: [email protected], "Mark Proctor" <[email protected]>
Sent: Wednesday, November 5, 2014 4:32:31 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
----- Original Message -----
From: "Vojtech Szocs" <[email protected]>
To: "Alon Bar-Lev" <[email protected]>
Cc: [email protected], "Mark Proctor" <[email protected]>
Sent: Wednesday, November 5, 2014 5:24:14 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
----- Original Message -----
From: "Alon Bar-Lev" <[email protected]>
To: "Vojtech Szocs" <[email protected]>
Cc: [email protected], "Mark Proctor" <[email protected]>
Sent: Wednesday, November 5, 2014 4:12:06 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
----- Original Message -----
From: "Vojtech Szocs" <[email protected]>
To: [email protected]
Cc: "Mark Proctor" <[email protected]>
Sent: Wednesday, November 5, 2014 5:04:24 PM
Subject: [ovirt-devel] Thoughts on modularization
Hi guys,
I've discussed this recently with Yair and Mark, I just wanted to
share
some more thoughts on this topic -- in particular, how
modularization
problem can be approached (regardless of implementation details).
I see two approaches here. The typical one is to define APIs for
modules
to consume. For example, oVirt Engine extension API has API for
auth
stuff; oVirt UI plugin API has API for showing tabs and dialogs,
etc.
The advantage is strict consistency, disadvantage is burden of
having
to maintain the whole API. With this approach, you tell modules:
"This
is the API to work with system, defining how you can plug into
it."
Now turn 180 degrees. The other approach, which is really
interesting,
is to let modules themselves export API. This naturally leads to
module
hierarchies. Ultimately, this leads to micro-kernel-style
development,
where all logic resides in modules. Now you might ask: "What if
we
want
to employ some consistent work flow across multiple modules? For
example,
have some pluggable *auth* infra?" -- this can be done via some
"higher"
level module, that exports API and "lower" level modules consume
that
API.
If you have any ideas, please share!
Both solutions can be applied using existing extension api, an
extension
can
locate other extension and interact with it the same way the core
interacts
with extensions.
But how does core interact with extensions? I assume via well-defined
API, i.e. in accordance with first approach mentioned above.
presentation:
http://www.ovirt.org/File:Ovirt_3.5_-_aaa.pdf
Thanks for sharing!
package org.ovirt.engine.api.extensions;
/**
* Interface of an extension.
*/
public interface Extension {
/**
* Invoke operation.
* @param input input parameters.
* @param output output parameters.
*
* <p>
* Interaction is done via the parameters.
* Exceptions are not allowed.
* </p>
* <p>
* Basic mappings available at {@link Base}.
* </p>
*
* @see Base
*/
void invoke(ExtMap input, ExtMap output);
}
OK, so it was my lack of knowledge of AAA implementation :)
Since Extension interface is invoke-based, I assume that Engine
core (backend) invokes extensions on specific occasions, right?
correct, and nothing prevents extension to invoke other extensions.
With second approach mentioned above, core would not interact with
extensions at all (or in a very limited way), instead - extensions
would interact with each other. In other words, extension would not
need to implement core-specific API (there would be none), instead
it would inject its dependencies (other modules/extensions) and
consume their APIs. This is the difference I wanted to point out :)
The extension interface is primitive to enable exactly that, provided
java
people will open their minds :)
Simple interface means great flexibility, now I understand the
rationale behind typed maps in extension API.
What I had in mind was something like this (maybe crazy):
* imagine for a moment that the backend is fully modular
(logic lives in modules, no logic outside modules)
* @DependsOn("SomeOtherModule") // modules can form hierarchies
public class MyModule implements Module {
public void loaded() {} // executed just once per module
}
you again using java magic for something that can go to declaration...
Vojtech, I have to agree with Alon here,
as much as I enjoyed in the past seeing hibernate move to annotations , I
think in our case a configuration file is better.
I'm not against config files, annotations are static metadata too anyway.
correct and CDI has both abilities - annotation and XML configuration
some of the things you are talking about here is established for long
time using jboss-osgi btw.
will dig for examples for OSGI & CDI interactions as I seen few .
* API for fetching modules, i.e. getModuleByName('xxx')
there is no need as within the extension context you have access to this
information, all you need is iterate a list, see Base.java.
API for exporting module API, i.e. exportApiObject(foo)
not sure why it is needed... once extension is loaded it is available.
This way, you'd have one "core" module, providing most general
functionality/abstractions. Then you'd have more specific modules,
plugged into "core" module's API etc. In other words, hierarchy of
modules. This is essentially modularization taken to extreme :)
(BTW, above is just an idea.)
not sure I understand what is the functionality difference between this and
the primitive approach we already have...
1. every configuration at /etc/ovirt-engine/extensions.d and
/usr/share/ovirt-engine/extensions.d are loaded during engine startup.
2. each extension has two phases load and init, during init an extension
can
locate other extensions by name via its context. it is true that probably
missing functionality is to support ordering of the init and load, we left
it into future as there was no actual need for this.
3. each extension can interact with other extension.
4. there must be core model to trigger the entire thing, core cannot be
just
a loader.
Alon, can you elaborate here on number 4?
In an ideal world, wouldn't you want to have the "engine core" be a small as
something that goes over the extensions and loads them? and maybe let each
extension expose somehow its relevant part of rest-api (besides of using
ext-api to interact between extension and of course each extension should
have the relevant logic implementerd within)
Alon
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
