Although the OSGiLiath core is finished I am still developing new services and algorithms to add to the framework. Working with Service Oriented Architecture, publish/subscribe events and classic OOP at the same time gives you SO MUCH flexibility that your head may explode. For example, I am adding new ways for terminate an algorithm, but I have some doubts. Which idea is better?:
– A class (service) EventStopCriterion (implements StopCriterion) to finish if an event “ALG_STOP” is received.
Who can send this event? For example, a central server to all clients (because with ECF, events also can be distributed). Or maybe a local service (called DataCollector, for example) that receives other events from other services (“NEW_EVALUATION”, “NEW_GENERATION”…) and checks if the counter of this events reach a maximum value to send the “ALG_STOP”.
– Or, for example, EventStopCriterion could receive the previously explained events and decide when to stop.
– Maybe is more flexible to create implementation services of StopCriterion and program the behaviour of each. For example NGenStopCriterion, NExecStopCriterion or MinErrorStopCriterion gathering data from other sources. Which sources?
– Is better create a method terminate() in the StopCriterion implementations and call this method as a service access from… anywhere? (you don’t know who are going to call your services). Maybe call increaseIterations() method when a new iteration occurs? It is more easy to extend than the previous idea, but more difficult to combine if you need several stop criterions in your algorithm.
– Also, think that you could save bandwith with distributed islands to communicate, but not if you are executing several islands in the same machine with shared memory. Also, services can appear or dissapear during the algorithm execution, many different kinds of machines could participate in the experiments…
All this ideas can be implemented in OSGiLiath thanks to OSGi capabilites (as presented here), but sometimes you have to think a lot how to do it.