Aquele blog de SOA

Sistemas possuem diversas necessidades. Para apoiar o negócio, sistemas precisam executar regras de negócio, fluxo do processo de negócio, lógica de conectividade, persistir dados em algum lugar. Por isso, aplicações são divididas em camadas, deixando esses aspectos mais organizados (apresentação, aplicação, negócios, infra-estrutura), possibilitando que alterações sejam contidas, por exemplo, alterações simples na apresentação ou na persistência não obriguem que quase todo o sistema seja alterado como conseqüência direta.

Pensando corporativamente, a situação fica mais complicada. Processos de negócio atravessam diversas áreas e sistemas de uma empresa, obrigando constantes integrações. Muitos sistemas duplicam regras de negócio e é necessária uma lógica de conectividade muito complexa.

Para evitar que pequenas alterações no processo de negócio ou em regras de negócio sejam inviabilizadas, obrigando grandes alterações em diversos sistemas, algumas abordagens são necessárias como, por exemplo, CBD, DbC, SOA. Essas abordagens, assim como camadas, lidam com limitações humanas, por exemplo, memória limitada dificultando a manutenção de processos grandes e complexos, mas com um foco corporativo.

SOA busca agilizar alterações no processo de negócio, dividindo sistemas em serviços que possibilitam a separação da lógica do processo de negócio da logica do domínio. Podemos considerar serviços como interfaces que definem uma topologia corporativa. Obter serviços bem projetados é o principal desafio.

Abordagens como SOA evitam o desenvolvimento baseado em silos (que misturam todo tipo de lógica):

Simplesmente ligar todos esses silos criando pontes (ESB) no estilo “mega construções” da discovery não resolve o problema. Como mostra Jim Webber, Ph.D., Global Architecture Lead, ThoughtWorks.

A bagunça continuaria (muito acoplamento), muitas vezes, escondida dentro de um ESB. Algo parecido com isso:

Serviços bem projetados são essenciais, principalmente serviços que ajudam a separar a lógica de regras de negócio da lógica dos processos de negócio, possibilitando uma evolução mais independente.

Contamos com serviços básicos que encapsulam regras de negócio, representando um conceito principal da corporação (isolando um domínio específico), evitando duplicidade de regras e acoplamento de conceitos de negócio importantes.

Contamos também com serviços que orquestram esses serviços mais básicos, criando uma indireção, para atender uma tarefa do processo de negócio, ou ainda, para publicar algum passo do UC que precisa ser corporativo.

O processo de negócio, muitas vezes instanciado com ajuda de linguagens como BPEL, orquestra todos tipos de serviços.

Thomas Erl classifica como SOA contemporâneo os serviços que seguem princípios específicos, quais sejam: a reutilização; o contrato formal; o baixo acoplamento; a autonomia; entre outros. Serviços servem a propósitos diferentes e desempenham papéis muito distintos. A classificação dos serviços em uma corporação é essencial para o sucesso da abordagem.

Existem várias formas de categorização de serviços, considerando o tipo de lógica encapsulada, o potencial de reutilização, a origem, os domínios existentes e a segurança, entre outros. Existem vários autores com abordagens diferentes; Thomas Erl, por exemplo, define algumas classificações em seu livro. Exemplos: Application Service; Business Service; Controller Service; Coordinator; Entity-centric business sevice; Integration service; process service; task-centric business service; Utility Service; Wrapper service;

Há três classificações de serviço principais definidas por Erl – usando uma abordagem em camadas:

– Entidade

Representa conceitos principais em uma organização, também conhecidos como serviços básicos por alguns autores. Uma rede hoteleira, por exemplo, poderia ter um Serviço Hotel. Esse serviço teria como responsabilidade obter apartamentos disponíveis e ocupar apartamentos. E, ainda, poderíamos ter um Serviço Cliente, para tratar questões coesas com clientes.

É considerado um serviço altamente reutilizável porque é agnóstico a maior parte dos processos de negócio. Algumas técnicas de identificação de componentes de negócio podem auxiliar na identificação deste serviço.

– Tarefa

Representa uma tarefa do processo de negócio. Este tipo de serviço tende a ter menor potencial de reutilização (mas com grande ganho quando reutilizado) e geralmente é responsável por “orquestrar” serviços de Entidade. Além disso, é responsável por garantir a pré-condição dos serviços que “orquestra”.

Um serviço de reserva, por exemplo, poderia ser uma tarefa de um processo maior, ficando responsável por “orquestrar” os serviços Cliente (capacidade: verifica cliente aprovado) e Hotel (capacidade: ocupar apartamento) para efetuar a reserva. O SOMA, metodologia da IBM para SOA, fornece estratégias interessantes para a identificação destes serviços.

– Utilitários

Serviços não associados diretamente ao processo de negócio e também não associados aos conceitos principais corporativos. Exemplos: retorna se um ano é bissexto; converte unidades de medida. Também podem assumir um caráter mais tecnológico ou de infra. Possuem alta reutilização.

Serviços bem projetados são essenciais para SOA, no entanto, não podemos esquecer que uma arquitetura provada (mecanismos funcionando e consolidados) e uma governança bem definida (com quem eu reclamo se meu serviço cair? como encontrar serviços?) também são essenciais.

Continuação dos posts: anatomia do serviço parte 1 e parte 2.