Re: [ovirt-devel] Thoughts on modularization

From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; Sent: Wednesday, November 5, 2014 6:07:50 PM Subject: Re: [ovirt-devel] Thoughts on modularization ----- Original Message ----- > From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; > Sent: Wednesday, November 5, 2014 4:32:31 PM > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > ----- Original Message ----- > > From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; > > Sent: Wednesday, November 5, 2014 5:24:14 PM > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > ----- Original Message ----- > > > From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > > To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > > > Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; > > > Sent: Wednesday, November 5, 2014 4:12:06 PM > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > > > > To: devel(a)ovirt.org > > > > Cc: "Mark Proctor" <mdproctor(a)gmail.com&gt; > > > > 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?

> > > 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 }

* API for fetching modules, i.e. getModuleByName('xxx')

API for exporting module API, i.e. exportApiObject(foo)

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.)