incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <bhais...@apache.org>
Subject Re: [DISCUSS] Decouple your code by text file(e.g XML)
Date Mon, 25 Feb 2013 02:06:02 GMT
On Fri, Feb 15, 2013 at 5:54 AM, Frank Zhang <Frank.Zhang@citrix.com> wrote:
> I have said too much about XML files recently, excuse me for raising this topic again,
> I really want to elaborate why text (e.g XML) configuration files is so important and
how
> it decouples your project especially for project written by static language like java.
>
> Let me cite our new ApiDiscoveryService as an example(This service is very good, I use
it
> as example just because I encounter a small problem and the problem is a good study case
> for decoupling code using text configuration files).
>
> The problem is: ApiDiscoveryService discovers API commands by invoking PluggableService.
getCommands().
> Each plugin service needs to implement getCommands() which returns a List<Class<?>>
including classes of
> API command the plugin service supports. This is good, lots of project use similar way
in plugin system.
>
> ManagementServerImpl is a special API service, it registers all orchestration API commands
like *addHost*. Now
> I have a special API called *addBaremetalHost* which inherits *addHost* adding one more
field.  *addBaremetalHost*
> is actually handled by the same orchestration code as *addHost*(but different HostDiscover
which is another story),
> unfortunately, this API belongs to my Baremetal plugin that means I can't add it into
 ManagementServerImpl. getCommands()
> because orchestration code should not have a dependency to plugin code.

Hi Frank, sorry for a really late reply I've a lot of pending email to
reply to or comment on. So, actually you can in your case. Just
implement a manager in your baremetal plugin, the managerimpl would be
a spring component that implements PluggableService and therefore
implements/overrides getCommands() which returns list of cmd classes.
For example, the api discovery plugin itself is a pluggable service
that return listApisCmd.class

>
> The solution is simple, I use a BaremetalManager to register *addBaremetalHost* and inject/call
orchestration code to deal with it.
>
> However, this case shows us how compiling time dependency in static language makes your
code tight coupling.
> Everybody programing in java/C/C++ knows the pain of planning your project skeleton to
avoid circular dependency.
> One of solutions is to use text configuration file. Back to our example, ApiDiscoveryService,
we can put a folder which
> stores API configuration XML at a well-known place, every PluggableService has a XML
file describing its API and Spring bean
> name in the folder. for example:
>
> <apiService>
>         <api>
>                 <command> com.cloud.baremetal.manager.AddBaremetalHostCmd</command>
>                 <acl>some acl</acl>
>                 <owner>Spring_bean_name_of_baremetal_manager</owner>
>         </api>
> <apiService>
>
> When ApiDiscoveryService starts, it scans the folder and parses XML files to discover
every api/theirs properties/owner bean. By doing this, ApiDiscoveryService/
> PluggableService/API command classes totally have no compiling time dependency, they
can freely seat in any packages as long as these packages present in
> classpath during runtime. To my case, I don't have to inject orchestration code in my
plugin anymore,  I just use a XML file to tell ApiDiscoveryService that addBaremetalHost
> is taken cared by ManagementServerImpl as well though ManagementServerImpl has no knowledge
about it.
>
> CloudStack used to have similar idea command.properties, unfortunately it's only used
as ACL declaration now.

The XML based config may help, but I'm not sure. I see a problem with
maintaining acl/xmls for every plugin. The ACL is not a property of
the plugin itself, it's actually a property of an ACL plugin, or
CloudStack/API server.

We separated policy from mechanism with ACL refactoring (which is not
totally complete, we still have ACL annotations and preprocessing
pending), so every plugins returns a list of cmd classes, but we've
another plugin called StaticRoleBasedACL which enforces some ACL rule
(in this case a static role mask defined in it's command.properties
file, one can diy acl plugin) for all apis.

Having just one command.properties file makes it easier for the
sysadmin to apply acl rules, and also this file does not belong to
CloudStack or all its plugins. It's actually only belong to the static
ACL plugin.

Should we use XML, yes but we'll have to group them in such a way that
it makes life of a CloudStack user, a sysadmin easier and not
difficult.

Regards.


>
> This is a trivial example,  but it reflects a truth that compiling dependency is naturally
making your code tight. Many people criticize dynamic language is error-prone because it
> lacks compiling time check, but as another side of coin, it's also easy to produce loose-coupling
code. Thinking about OpenStack, if you were going to use Java to fork it, I am pretty
> sure the compiling time dependency will drive you crazy.  For instance, java-nova and
java-cinder both need to know Volume that represents vm disk, now where do you define it?
in java-nova?
> in java-cinder? Then who depends on who? Or totally don't define any data structure,
using a HashMap to transmit primitive variables, then where is beauty of compiling check?
>
> As we have adopted Spring that uses XML a lot in CloudStack, I suggest us taking more
consideration of text configuration file when designing a new feature. it really works.
>

Mime
View raw message