Dentre os pontos de vantagens da arquitetura, creio que por mais que pareça conversa de vendedor, conhecemos os benefícios prometidos por SOA, como reusabilidade, aumento do ROI, alinhamento do negócio e TI, dentre outros.

No tocante às desvantagens levantadas pelo Éder, é que esse artigo irá se focar.

Os pontos mencionados na apresentação como "desvantagens" foram: maior complexidade, preocupação com performance, robustez e disponibilidade, testabilidade e segurança.

Após sua breve explanação, Éder foi duramente criticado quanto a todos os pontos mencionados como desvantagens:

Complexidade:

“Não há complexidade nenhuma em SOA. Na minha empresa, nós trabalhamos com um plugin no Eclipse que consegue mapear cada coluna do banco ao serviço desejado. Um treinamento de 3h seria mais que suficiente para a instrução na arquitetura”, “Desenvolver Orientado a Serviços não apresenta nenhum acréscimo de complexidade, pois existem ferramentas que geram os Web Services e WSDLS automaticamente”,  estas foram as primeira contra argumentações levantadas por um de seus colegas de classe.

Claramente é possível fazer uma distinção entre SOA e Web Services, a prática que está sendo defendida pela pessoa em questão. Isso me lembra um curso que realizei há algum tempo, e que em sua ementa constava a implementação em serviços utilizando-se SOA. O instrutor conduziu tal dinâmica com os seguintes passos: "Abra o Eclipse, crie uma classe com métodos, utilize a anotação @WebService no topo da classe".

Criar um Web Service, seguindo tal prática ou mapear um banco existente com algum tipo de plugin, realmente não expõe nenhuma dificuldade, a dificuldade está no valor de tal WebService ao negócio, no baixo acoplamento, nas possíveis alterações, dentre outras.

Basta ressaltar que como uma das boas práticas defendidas por muitos se encontra no “Contract First”, conceito prega a criação de modelos canônicos e WSDLs antes da dita implementação do serviço em si, facilitando assim um dos princípios buscados, a saber: - O Baixo Acomplamento.

O problema de se acoplar um banco de dados existente à sua implementação está na ausência de abstração e no alto vinculo com a implementação, imagine que seja necessário alterar alguma coluna, inserir novas colunas ou até mesmo removê-las, o quanto esse forte acoplamento pode atrapalhar usuários que já consomem esse "serviço".

 

Em breve continuaremos com mais considerações sobre o seminário, a idéia é passar por cada consideração levantada. Até a próxima.

 

Receive our SOA Magazine

Events Calendar

loader

Twitter