[kepler-dev] [Bug 4483] - Module dependencies in MoML files

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4483





------- Comment #9 from welker4kepler at gmail.com  2009-10-22 14:19 -------
Hi Aaron,

I think it is an interesting idea.

So, you are basically saying that when an actor is added to the workflow, that
actor should know all the modules it depends on and somehow register them,
right?

But what if a dependency could actually be satisfied in the alternative by
multiple modules? i.e. Either module X or module Y will satisfy the dependency.
What if a specific version of a module is necessary to satisfy the dependency?

How does this fit into versioning and the concept of time? I can say that X is
necessary, but it might be only X after version A but before version B that
satisfies my dependency. It seems the developer needs to know not only that X
satisfies his dependency. The developer needs to know which versions of X
satisfy his dependency and which do not.

What is the advantage of your proposal? One advantage is that perhaps workflow
developers have to know slightly less about their dependencies. In contrast,
actor developers have to be constantly aware of precisely what they depend on.
But it also seems less flexible. It is possible that the needs of the actor
could be satisfied in multiple different ways and those solutions might exist
in different modules that could be specified in the alternative.

Also, workflow developers are going to be very aware of modules in general. If
they do not want to figure out what modules they minimally depend on, then they
can just go with the default (i.e. the modules they were actually using when
they developed the workflow) at the cost of minor inconvenience to the end user
of those workflows.

So, what I see are some trade-offs. There are advantages and disadvantages to
both approaches. I think your proposal has some interesting potential in terms
of being automated, especially with some clever metadata. (i.e. if your module
depends on another module because reflection or third-party libraries, then it
needs to be specified explicitly.) These are both fairly low level approaches,
however.

What do you think?

Yet another approach we might take is by abstracting this stuff out and using
the concept of services. We could require modules to say they depend on service
X, Y, or Z, which must be satisfied through well-defined contracts and then
other modules will say whether they satisfy X, Y, or Z. So, a module that in
one context depends on A to provide X, B to provide Y, and C to provide Z might
in another context depend on only D, which actually provides all of X, Y, and
Z. Implementing a service would be analogous to implementing a service, except
that a service would actually consist of potentially multiple contracts or
interfaces instead of just one. Also, things like the module manager could be
aware of services, so that if you have a module that wants service X, but there
is no module that provides service X, it freaks out. Also, services probably
would need to be versioned so that you may need something that implements
service X.5 or later and older versions such as X.3 will not work.

At this point, I would also be interested in considering how OSGi handles this
problem, at least for inspiration. It turns out that JSR 277 is inactive and
will probably die. Check out this post from Jeet Kaul, Vice President of Sun
Microsystem's Client Software Group for more information here:
http://blogs.sun.com/meetjeet/entry/osgi_vs_jsr_277. I think it is really lame
that Sun abandoned this project. They seem to be very indecisive. But, if JSR
277 is dead (probably forever) then our alternatives are either OSGi or we
solve our module problems with custom solutions (like we have been doing up to
this point).

Would OSGi help us solve this problem? If so, how? It is an interesting
question that I hope to research in the days ahead.