On 5/18/05, Knut Wannheden <[EMAIL PROTECTED]> wrote: > You say you have a small number of interfaces and a large number of > matching implementations. From this it is not quite clear to me if you > will end up with a small or large number of services. For HiveMind it > is no problem to have many services with the same interface. So my > question is: Do you need a service for every implementation or are the > implementations intended as alternative implementations of a single > service?
The implementation are alternative for a single service. I've 10 java interfaces which represent 10 different business process but for each of this java interfaces I've 40 different implementations, so from HiveMind point of view, I'll end up with 400 services Which different implementations choose to process data are based on some kind of meta-data associated with the real data and are performed by the "main class" of the application. I think I'll approach this with a solution with a lot of thin jar, maybe keeping separated the interfaces from the implementations so I'll have implementation-jar depending on interface-jar. I hope to have been more clear now. Does this sounds good ? > Normally you will define one HiveMind module with every jar file. You > are free to chose how many jar files you want and how many services > you define in every module. Whatever you think is appropriate :-) Fine :) > Further it is also important to note that a HiveMind module is a > namespace. If you have two modules with the IDs 'a' and 'b' it is > perfectly legal to define a service in each of these with the ID 'x'. > The fully qualified IDs of these services are 'a.x' and 'b.x'. Yes, I've read that in the doc and for my purpose is really a good thing (TM) :) > Hope this helps, Sure, thanks. -- Massimo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
