What a Hell is SOA?

Arquitetura do ponto de vista de um desenvolvedor ...

Introdução

É realmente complicado tentar definir o que é SOA, mas comecemos pelo significado do acrônimo: Service Oriented Architecture ou em português Arquitetura Orientada a Serviços.

Com exceção da palavra "Orientada" as outras são muito difíceis de definir, ambas são termos sobrecarregados. 

Como definimos arquitetura? O que é serviço?

Arquitetura

Existem várias definições para arquitetura, nota-se que ela é muito subjetiva e está ligada ao ponto de vista, ao papel, por exemplo um desenvolvedor não tem a mesma visão de arquitetura que o gerente de projetos, e este por sua vez não tem a mesma visão que o cliente. Então, talvez alguns pequenos pontos ajudem a esclarecer.

Arquitetura é sobre:

• A organização da estrutura de componentes significantes, que interagem através de interfaces, no mais alto nível de um sistema e seu ambiente.

• Coisas importantes e difíceis de mudar no futuro. Tomar decisões sobre estas coisas é definir a arquitetura.

• Requisitos não funcionais: segurança, escalabilidade, confiabilidade, etc.

• Todo sistema envolve uma série de componentes maiores construídos sobre componentes menores. A equipe de desenvolvimento tem um entendimento compartilhado de como estes componentes interagem. Este entendimento pode ser chamado de arquitetura.

Serviço

Michaelis sobre serviço:

serviço

ser.vi.ço

sm (lat servitiu) 1 Ato ou efeito de servir.

Não há consenso sobre o que serviço significa, mas sabemos que ele deve estar disponível para atender quem queira consumi-lo. Mais provavelmente, um serviço deve ser o encapsulamento das regras de negócio, sem lógica de apresentação, auto contido podendo retornar a informação necessária em uma única chamada, sem estado, usável por diferentes aplicações e independente de localização.

Service Oriented Architecture

Para cada pessoa, ou papel desempenhado por ela, SOA pode significar algo diferente. Para alguns SOA é sobre expor a aplicação através de Web Services, para outros é apenas utilizar XML e para mais alguns SOA é a mesma arquitetura de sempre (Same Old Architecture) e nada muito diferente de CORBA, RMI ou DCOM.

Se para cada pessoa, a visão de arquitetura e de serviço é subjetiva, então, como fica a Arquitetura Orientada a Serviços?

Minha visão como desenvolvedor

Bem, o que eu vejo é uma ênfase, impulsionada pela dinâmica dos negócios da atualidade, focada na descentralização, no reuso, na independência, na facilidade de interligação da aplicação e do intercâmbio das informações com aplicações legadas ou mais modernas.

A todo momento empresas são compradas ou cooperam com outras, formam um conglomerado, etc, e faz-se necessária a exposição da informação e dos processos de negócio.

A justificativa para SOA não é muita nova, me parece a mesma que impulsionou outros paradigmas e tecnologias como:

• Linguagens orientadas a objetos, que aproxima o modelo do código à realidade;
• Desenvolvimento com componentes, que encapsula lógica do negócio em um bloco de classes autocontidas;
• Componentes distribuídos e chamada de procedimento remoto (RPC): busca da interoperabilidade e intercâmbio de informações, impulsionado por CORBA e COM+;

Então, onde entra a Arquitetura Orientada a Serviços? 

Usar uma linguagem orientada a objetos, distribuir a aplicação em componentes expostos através de chamadas remotas já não é isto?

Não.

Isto pode ser feito com Java EE e componentes EJB que usam RMI sobre IIOP ou Microsoft .NET com .net Remoting sobre HTTP ou TCP e SOAP binário (e é até relativamente fácil de fazer), mas ... -pequena pausa- ...  SOA é um problema de arquitetura (por isso o 'A'), não de implementação.

Obs.: até mesmo Web Services são fáceis de declarar, em plataformas como Java EE e .NET basta um metadado (anotação). Mas, outra vez, repita comigo, "não é uma implementação é uma arquitetura".

Orientando a Serviços

A solução SOA envolve geralmente um protocolo de comunicação e formato de mensagens conhecidos e populares, como TCP/HTTP/SOAP e XML/JSON, e possui características como requisições assíncronas e sem estado.

Pontualmente para orientar a arquitetura da aplicação por serviços, entre outros problemas de design, é necessário:

• Definir a política do serviço;
• Definir como o serviço será exposto, o contrato do serviço;
• Definir como os clientes se conectarão ao serviço;
• Definir o formato das mensagens trocadas entre provedor e consumidor do serviço;

Entre outros pontos relevantes, alguns são:

• Como serão feitas transações?
• Como o cliente obterá resposta do serviço?
• Como os clientes descobrirão o serviço?

Um serviço deve ser atômico e auto contido, alguns para leitura de informações, outros para gravação e outros mais complexos para Workflow. 

A ausência de estado (statelessness) é um requisito desejado, sendo que a escalabilidade é um fator que pesa muito na arquitetura, sendo um dos requisitos não-funcionais mais importantes.

Resumindo, um serviço, que representa uma atividade de negócio, deve permitir que qualquer cliente se conecte a ele, seja este cliente a camada de negócios de outra aplicação ou um frontend remoto.

É importante que não exista a dependência de tecnologias específicas. O consumidor é ignorante de como o provedor processa o serviço e vice-e-versa. A interoperabilidade deve ser dependente do formato da mensagem e tipo de protocolo, mais nada.

Note que a idéia de distribuir um serviço implica em mais algumas preocupações, dado que existem fatores que podem influenciar no seu funcionamento como:

• Problemas de comunicação: atraso no recebimento da requisição ou envio da resposta, ou mesmo o não recebimento;
• Problemas de validação: pode ocorrer o caso de o processo ser inválido dada uma regra do negócio e uma estratégia para o tratamento de exceções deve ser formulada;
• Problemas de autorização: definir quem acessará e o que é extremamente importante. Rastrear as alterações também é.
• Problemas de dependência e transações: no caso de o serviço ser dependente ou ter dependências de outros serviços. Como serão gerenciadas? E se um deles falhar?

E a implementação?

A maior parte dos problemas é promessa de solução da maioria dos ESB's disponíveis, entretanto, há que se avaliar.

Estou desenvolvendo um estudo de caso (sem ESB) e em outro tópico lanço para discussão.

Referências

Boa leitura, recomendo:

Who Needs an Architect?
http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

Ótimo livro sobre arquitetura corporativa:
Patterns of Enterprise Application Architecture
http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420

Embora não fale especificamente de SOA, fala muito, e bem, de integração de sistemas corporativos:

Enterprise Integration Patterns
http://www.amazon.com/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683/ref=pd_sim_b_1