SOA e Web Services não são sinônimos

Um dos maiores enganos em torno de SOA é o seu tratamento como sinônimo para as tecnologias e padrões Web Services (leia-se SOAP, WSDL, UDDI, WS-*, etc).

SOA trata de arquitetura e desenho de serviços de negócio. Web Services são tipicamente a primeira escolha tecnólogica para a implementação de tais serviços. Além deles, há uma infinidade de opções como CORBA, RMI, DCOM, DCE, sockets, REST, etc. Algumas não são mais usadas mas o ponto é que a escolha tecnológica para a implementação de SOA não é uma das responsabilidades em si de um projeto como esse.

Várias analogias existem: Modelos Entidade-Relacionamento - MER de Peter Chen (ou "Entity-Relationship Models" - ERM em Inglês) para representação lógica de dados e informações não definem qual a tecnologia de banco de dados será aplicada para a implementação. Usualmente, Gerenciadores de Bancos de Dados Relacionais são empregados por permitirem a implementação mais direta da lógica definida nos modelos. Entretanto quaisquer outras tecnologias poderiam ser usadas como Hierárquica, Rede, arquivos, XML, etc, etc.

O mesmo acontece com a especificação de programas. Um algoritmo não pressupõe o uso de nenhuma linguagem para a sua implantação. Seja ela Java, C#, Pascal, Cobol, etc.

Então, em resumo: SOA pode ser implementado sem Web Services. Web Services podem ser usados em projetos que não sejam de SOA.

Outro ponto a considerar é o seguinte: o uso de Java, C++ ou qualquer outra linguagem de programação não resulta em programas "orientados a objetos". É preciso que tenhamos bons desenhos de programas orientados a objetos. Mais uma vez a analogia procede: o simples uso de Web Services não implica necessariamente em Arquitetura Orientadas a Serviços. Muitas arquiteturas serão construídas com Web Services e não serão "orientadas a serviços" pelo mero fato de terem sido mal desenhadas.

O uso (e consequente confusão) de Web Services para a construção de "serviços" talvez tenha como base a maior facilidade, flexibilidade, etc proporcinadas por esta tecnologia em relação a outras. Afinal o "S" de SOAP quer dizer "simple"... Todavia os atributos de "simples" e "fáceis" para os Web Services têm sido questionados. Richard Monson-Haefel, em 22 de Abril de 2006, postou em seu "blog" o já classico "Dave Podnar’s 5 Stages of Dealing with Web Services". Reproduzo os cinco estágios no original em Inglês:

1. Denial - It’s Simple Object Access Protocol, right?
2. Over Involvement - OK, I’ll read the SOAP, WSDL, WS-I BP, JAX-RPC, SAAJ, JAX-P,… specs. next, I’ll check the Wiki and finally follow an example showing service and client sides.
3. Anger - I can’t believe those #$%&*@s made it so difficult!
4. Guilt - Everyone is using Web Services, it must be me, I must be missing something.
5. Acceptance - It is what it is, Web Services aren’t simple or easy.

Tecnologias como REST prometem "simplificar" de verdade o desenvolvimento. Isso fica prá outro "post"...
Outra típica confusão instaurada está relacionada ao Modelo de Implementação de Serviços baseado em "find-bind-execute". Abaixo temos uma figura ilustrativa.

Funciona mais ou menos assim:

1. Provedores registram seus serviços em um repositório público.
2. Consumidores procuram no repositório serviços que satisfaçam seus requerimentos.
3. Os repositórios fornecem aos consumidores o “contrato” para o uso do serviço.
4. Consumidores usam o “contrato” para interagir com o provedor.

O engano acontece imaginando que este modelo seja particular aos Web Services. Na realidade, é o contrário: os Web Services são mais uma tecnologia que também segue este paradigma. CORBA, por exemplo, baseia-se neste mesmo princípio. Em última análise, o conceito de "contrato" sendo exposto a consumidores permeia quase todas as tecnologias existentes. Um arquivo ".h" na linguagem C é um contrato sobre as funções expostas por uma biblioteca. A "novidade" em Web Services talvez seja a publicação dos contratos em servidores específicos.

Enfim, enfatizando, SOA não é sobre tecnologia. É uma arquitetura. Anne Thomas Manes, diretora de pesquisa do Burton Group escreveu em 2007 um "post" em seu "blog" chamado "When Technology Matters in SOA" que resume muito bem a questão.