Guys,

Thanks again for discussing all this with me.

Let me explain in a little more detail what I'm doing here. Currently, I am
at the beginning of a meduim-sized project. At this point, I'm just
investigating various issues. What I'm interested in doing is making the
project component-based, so I'm investigating what technology to use to
accomplish that. I'm also looking at how to build the framework, the goal
being to add a little overhead to greatly simply the system as a whole. From
a business perspective, I'm looking at trying to lower costs, promote reuse,
and so on. Eventually, if things go well for this project, we'll reuse the
same approach for the entire company.

Essentially, the project consists of various models that may or may not
interact. A model ranges from trivial to complex. Now, to understand the
vocabulary I'm using, and to simply things a little, let's suppose that each
model has a Manager, and this Manager is a POJO. So, for the n models in the
system, there will be n POJOManagers. (Of course, this is a vast
simplification, but it will do fine for this discussion.)

What I mean by "service" is using an Avalon component as an adapter to each
POJOManager. (After all, a model provides a service, even if it's just
changing the state of something...) So, by my reasoning and using this
simplification, if we want to "Avalonize" the entire system, there will be n
ServiceProviders, each acting as an adapter to a POJOManager.

Now the fun starts. You see, for me, the promise of Avalon is being able to
mix and match the various services (using my definition above) as
components. In other words, a component comprises one or (probably) more
services. The developer should be easily able to grab any combination of
services to quickly put together any kind of component. In fact, components
could also be composed of other components.

So far, I think this is what Avalon/Merlin is intended for.


When dependencies are clear, everything works beautifully! Each service will
fire the services it depends on and all goes amazingly well.


Where things get messy, however, is when you want to build components from
services that should NOT be dependent, but you want the services to execute
sequentially. (For a good comparison of what I mean here, think, for
example, Ant tasks and they are executed sequentially.)

It appears that this can be done, but it's not what Merlin was intended for,
so the solution is a hack. Out of the possible solutions that have been
suggested to me are:

1. Declare artificial dependencies. This does solve the problem,
   but it creates a spaghetti of artificial dependencies that
   just shouldn't exist. To me, the whole point of using a
   component model is that each component should be independent.
   In the extreme, that means that I'll have to declare every
   component dependent on every other component, just to be
   sure. That makes no sense!


> How can you listen to a component that you don't "know about" (i.e
> no dependency). Please note that the dependency can be declared both
> optional and against very generic interfaces.

I think what I didn't explain well here is that, reusing my definitions
above, my Component will use two ServiceProviders. So, of course the
Component will "know about" the ServiceProviders, but each ServiceProvider
should not need to know anything about the other.

In any case, the thing is, to me "optional dependency" is an oxymoron.
Either there is a depedency or there is not. A dependency cannot be
"optional". If it were optional, than there is no dependency to begin with!

Also, declaring to a more generic interface makes sense... but isn't that
what the component-based model in intended for to begin with?


2. Use an event listener to wait for the completion of the services's
   execution. Ok, but shouldn't the framework be doing this for me?
   What's the point of having a nice framework if I have to go and
   make while loops while waiting for an event? This also complexifies
   the code, which is not something I want to get into.

3. Make a new service interface for each sequence. Say that in my case,
   I have ServiceProviderA (which, we remember, is an Avalonized
POJOManager,
   that I want to execute before ServiceProviderB. Well, I could make
   a ServiceProviderAB, which, like ServiceProviderB, is an Avalon
   component adapter for POJOManagerB, but this time actually
   declares a dependency (since one arguably exists in this particular
   scenario).

But again, with this approach, we'll end up with a gazillion components,
complexifying the system and making things worse, not better. In any case, I
feel uncomfortable with this approach.


4. Make a Component that simply directly uses the POJOManagers, rather
   than the ServiceProviders. Well, again, this defeats the whole
   purpose of using the ServiceProviders, doesn't it?


All these work, but none are desireable. Really, the best situation is to
have, within something like the Executable interface, a way of making a call
like:

  execute()
  {
    executeAndWait(serviceProviderA);
    executeAndWait(serviceProvicerB);
  }

Or perhaps:

  execute()
  {
    execute(serviceProvideA).execute(serviceProviderB);
  }

Or maybe:

  execute()
  {
    executeSequentially(serviceProviderA, serviceProviderB);
  }

Or whatever.


THAT would be sweet!!

But since that doesn't exist, either I'll have to choose one of the above
hacks, or give up on Merlin. I don't want to give up on Merlin, but I don't
really like any of the workarounds I've seen so far. So it looks like I'm
SOL.



> Somehow I have the feeling that you are just trying to fool around
> to get grips with the concepts, and perhaps not very comfortable
> with the way we do things in Avalon. If you are trying to give us a
> simplified view of a real-world problem, perhaps it is better if
> you give me the 'reality' and explain what you try to do, and I'll
> tell you how to go about it.

You are correct. As I explained above, I'm still trying to imagine the long
term effects of refactoring the entire project (and eventually the whole
company) to use Avalon. Will this LOWER costs or RAISE them? At this point,
I'm not so sure...

So, at this point, other than my tests, I am indeed speaking relatively
theoretically.


Thanks again for the help!



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to