The problems of develop a highly-flexible framework

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.


About fergunet

PhD at Computer Science. I like Doctor Who.
This entry was posted in CUSL7, Design, OSGi, Project development and tagged , , . Bookmark the permalink.

2 Responses to The problems of develop a highly-flexible framework

  1. Eeeh… I don’t know too much about EAs, but I’d bet for the flexible one solution. Having several services should allow to your EA to choose the stop criterion services in which you are interested. These criterions should know which other services they have to subscribe to determine when the criteria that they implement is reached. And if a criteria is reached, the stop criterion service should be the one who sends the ALG_STOP event.

    I think this way keeps the flexibility of the SOA system, allowing to reuse easily stop criterions services between different EAs.

    ps: or you can ignore this comment cause I really don’t have any idea about what OSGiLiath really is.

    • fergunet says:

      The stop criterion service is called at the end of each generation (isFinisihed() operation) to determine whether the algorithm should stop. So, it is similar to your idea. Other services can access this stop criterion service to set their inner status to STOP or this service can listen the ALG_STOP event. We can discuss these ideas in the Hackathon if you want 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s