Mas que raio de WSDL...

Agora que já consegui realizar uma primeira implementação do CGA em JAVA, falta interligar com a outra parte do projecto e que tenho vindo a aprender por custo próprio aos poucos: fazer o algoritmo genético circular pela rede, ou seja, pôr clientes a trabalhar num vector população e criar um servidor que gira (de gerir) o trabalho de todos os clientes, distribuindo por todos os clientes o vector população que necessitam para por o CGA a trabalhar. Basicamente, trata-se de uma arquitectura "worker-manager" que é explicada neste artigo. Tenho, portanto, de pôr um manager (ou servidor) e workers (ou clientes) a comunicarem entre si através de Web Services. E para definir Web Services é necessario criar um ficheiro XML que descreva os Web Services atraves de um formato conhecido por WSDL. Atraves deste formato sao descritas coisas como o nome da API (função), como os seus parâmetros, o seu tipo assim como o tipo de retorno da função que o cliente necessita de invocar do motor de Web Services (eu chamo-lhe motor porque é um módulo que roda num servidor Web, ou seja, é um componente do servidor e não um servidor por si próprio, que neste caso concreto é o Apache Axis). Deste modo, é definida uma interface do Web Service (WS), que pode ser explorada por toda uma diversidade de clientes, escritos nas mais variadas linguagens. Pois é assim mesmo que deve ser: uma vez que na Internet coexistem a mais diversas plataformas e linguagens, um formato universal que permita descrever a interface do WS de modo que permita que qualquer cliente o possa utilizar. De modo que neste momento as dúvidas é que se põem estão relacionadas sobre quais devem ser as APIs a utilizar, eu pensei nas seguintes, não sei se serão as melhores, mas em minha opinião acho que não desagradam:

• DownloadPopulationVector - o worker pede ao manager um vector população com o qual possa começar a trabalhar. Este passo é feito no princípio por um novo worker disposto a iniciar um novo trabalho ou então na ocasião em que estando completo o trabalho depois de cumpridas m iterações do algoritmo - que é por outro lado, um parâmetro da resposta enviada pelo manager ao worker quando é descarregado o vector população para o worker - de modo que o worker possa saber quando a fase presente de trabalho terminou e pode enviar o resultado obtido para o manager.


• SendPopulationVector - o worker completou finalmente o seu trabalho e está disposto a enviar o vector população apenas com as diferenças entre o último vector população que recebeu do manager e o estado em que ficou o VP (vector população) depois de cumpridas as tais m iterações estabelecidas pelo manager. A esta solicitação o manager deve responder - depois de verificar se o VP já atingiu alguem critério que permita terminar o algoritmo - com uma resposta que informe a conclusão do trabalho ou então. No caso da resposta ser negativa, ou seja que o VP ainda não convergiu, então o cliente tem o dever de invocar a API anterior para que possa descarregar um novo VP e prosseguir o seu trabalho.
  

Até agora, é este o "estado do arte", que, no entanto, ainda nem comecei a implementar!!! É apenas, por enquanto, e ainda, uma declaração de intenções.