SOA - SOA - Service Oriented Architecture

Introdução

O SOA( Service Oriented Architecture) é um tipo de arquitetura de software que promove a integração, entre clientes e sistemas, e orquestração de processos de uma organização por meio de serviços (componentes abertos/webservices).

Uma arquitetura orientada a serviços é essencialmente uma coleção de serviços interligados que comunicam entre si formando assim um único sistema, porém a localização dos serviços não é importante, estes podem ser internos à empresa ou disponibilizados por outras empresa, pois a comunicação entre os serviços pode envolver apenas simples trocas de dados, ou uma coordenação entre dois ou mais serviços.

Para compreender claramente o que é uma arquitetura orientada a serviços é necessário definir o que é um serviço.

Um serviço é uma função ou funcionalidade que se encontra bem definida, que é estanque (self-contained) e que não depende do contexto ou estado de outros serviços.

Temos então, que o SOA é um estilo de arquitetura na qual aplicações são disponibilizadas em forma de serviços, e esses serviços são disponibilizados em uma interface, que podem ser os Web Services ou alguma outra forma de aplicação.

Best Practices

No desenvolvimento de um software baseado no SOA, deve-se ter em mente algumas respostas para as seguintes perguntas, para que o sistema seja bom e produzido com as melhores praticas para atender o mercado consumidor.

Quais são algumas das vantagens para o cliente de tal prestação de um serviço? Quais são as expectativas e objetivos do cliente?

Quais são os papéis, procedimentos, estruturas e responsabilidades que já estão no local no site do cliente para o planejamento de Tecnologia da Informação, tomada de decisão e direção?

Qual o nível de serviço, a descrição e padronização definição de serviço é adequada?

Como os serviços e prestadores de serviços melhor ser medido e controlado? Quem deve controlar, autorizar e definir mudanças nos serviços que existem atualmente?

Quais são os problemas atuais? Como o cliente pode ser ajudado a resolvê-los?

Deve-se ter em mente também algumas características que seu projeto irá utilizar, algumas citadas a seguir:

• Loose Coupling

Uma das praticas utilizadas no Arquitetura orientada ao serviço é o Loose Coupling entre agentes de Softwares. O Loose Coupling passa pela redução ao mínimo das dependências artificiais, sem que para esse efeito sejam comprometidas as dependências reais. Um exemplo é o serviço de roaming de um aparelho celular.

• Mensagens

São as ligações fundamentais numa arquitetura orientada a serviços, não menos importantes são as mensagens que passam através dessas mesmas ligações.

As mensagens que passam de um serviço a outro tem algumas regras:

- As mensagens têm que ser descritivas e não instrutivas,pois a responsabilidade de resolver o problema é do fornecedor do serviço, o consumidor apenas necessita de explicar o problema. - As mensagem têm que ser perceptíveis para o fornecedor do serviço, ou seja, têm que estar escritas num formato, estrutura e vocabulário que é compreendido por ambas as partes. - Quanto mais restritivo for o vocabulário e a estrutura da mensagem, mais fácil é a sua compreensão, no entanto, desta forma, limita-se a extensibilidade do serviço. - E ainda extensibilidade, que é o aumento do da estrutura e um vocabulario de dados para acompanhar a evolução dos sistemas de softwares.

O problema é que a restrição e a extensibilidade estão intimamente ligadas e é impossível aumentar a uma sem diminuir a outra. O truque está em encontrar o equilíbrio certo entre a duas

• Web Services

Os Web Services são uma implementação do Soa e são aplicativos servidores que disponibilizam 1 ou mais serviços ao cliente. [Cleuto Sampaio, 2003]. Estes permitem às aplicações enviar e receber dados em formato XML. Cada aplicação pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, o formato XML. Utilizando a tecnologia Web Service, uma aplicação pode invocar outra para efectuar tarefas simples ou complexas mesmo que as duas aplicações estejam em diferentes sistemas e escritas em linguagens diferentes. Por outras palavras, os Web Services fazem com que os seus recursos estejam disponíveis para que qualquer aplicação cliente possa operar e extrair os recursos fornecidos pelo Web Service, ou seja, Web Services foram criados para construir aplicações que são serviços na internet.

• Documentos XML

Tendo em conta a importância da extensibilidade nas mensagens trocadas entre os serviços, a escolha lógica parece ser utilização de XML, pois este satisfaz as condições necessárias para a obtenção de Loose Coupling e ainda os documentos XML podem ser restringidos por XML Schemas e, a não ser que as restrições não o permitam, podem ser estendidos.

- Schemas XML

Os Schemas XML exprimem vocabulários e definem as regras sobre as quais pode ser escrito um determinado tipo de documento XML, e permitem também a validação de documentos. Basicamente são um meio para definir a estrutura, os conteúdos e semântica de um documento XML, sendo um meio por excelência para definir os termos do contracto de comunicação entre os sistemas.

Um documento XML contém informação auto-descritiva, e isso pode ser uma das desvantagens de utilizar XML, pois as mensagens tendem a tornar-se muito maiores. Assim sendo existe aqui uma questão de performance. Ao utilizar XML troca-se a performance por flexibilidade, no entanto quanto maior for a largura de banda para comunicação menos se notará este problema.

- Exemplo XML

 <?xml version="1.0"?>
 <xs:schema xmlns:xs="http://exemplo.xml">
 <xs:element name="note">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="to" type="xs:string"/>
      <xs:element name="from" type="xs:string"/>
      <xs:element name="heading" type="xs:string"/>
      <xs:element name="body" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>
</xs:schema>

Serviços

Um serviço é um componente que atende a uma função de negocio especifico para seus clientes. Ele recebe requisições e as responde ocultando todo o detalhamento do seu processamento. Um serviço deve executar unidades completas de trabalho, não dependendo do estado de outros componentes externos. Assim, outra conclusão importante é que eles devem ser “Stateless”, ou seja, sem armazenamento de estado de conversação.

Alguns exemplos de serviços:

• Verificar a disponibilidade de vôos para uma determidada cidade.
• Efetuar a venda de um determinado produto.
• Reservar hotel para um cliente.

Um serviço é um componente de granularidade grossa, logo não deve executar funções muito detalhadas.

Alguns exemplos incorretos de serviços:

• Alterar o preço de um produto.
• Fazer baixa de um produto do estoque
• Debitar o valor da conta do cliente.

Estes exemplos são de granularidade muito fina para serem considerados serviços. Por exemplo: “Alterar o preço de um produto” poderia ser uma função de um serviço de gerenciamento de produtos.

Seguindo este principio, podemos criar serviços usando qualquer linguagem, tecnologia ou plataforma.

Web Services

Web Service é uma “encarnação” de SOA, mas não a sua definição. Pela sua natureza, a tecnologia de Web Services favorece muito a criação de componentes SOA usando qualquer outra tecnologia.

O importante é que para ser considerado de arquitetura SOA, um componente deve ser um serviço, o que implica em:

• Granularidade grossa;
• Relevância e alto nível de transação executada;
• Preferencialmente Stateless;
• Baixo acoplamento;
• Interface bem-definida;
• Detalhes de implementação bem encapsulados.

Princípios utilizados

Os Principios utilizados pelo SOA são:

Serviços são reutilizáveis; Serviços compartilham um contrato formal; Serviços possuem baixo acoplamento; Serviços abstraem a lógica; Serviços são capazes de se compor; Serviços são autônomos; Serviços evitam alocação de recursos por longos períodos; Serviços devem possuir a capacidade de serem descobertos.

As oito características dos serviços são úteis para definir o ambiente teórico no qual a Arquitetura Orientada a Serviços deve ser implementada. Apesar de serem de simples explicação, os princípios necessitam de uma certa experiência prática para serem aplicadas já que a cultura dentro do ambiente corporativo sofrerá profundas alterações, assim sendo, cabe observar algumas possíveis dificuldades na aplicação deles dentro da empresa.

1. Princípio: Serviços devem ser reutilizáveis

O que é: Um serviço reutilizável é aquele que não carrega particularidades técnicas de uma implementação ou regra de negócio específica e é genérico o suficiente para atender outros projetos. Aspectos positivos: Um serviço reutilizável abrange diversos cenários de uso por consistir em uma lógica mais genérica. Isso é mais simples quando a construção dos serviços é feita de forma corporativa, como nas fábricas de software. Dificuldades: A criação de um serviço de caráter reutilizável necessita de maior esforço já que a sua necessidade só surge quando os usuários do serviço se deparam com ela e, além disso, a implantação e os testes são tarefas não-triviais a serem executadas por terem uma especificação abrangente. As modificações em um serviço tendem a afetar diversas áreas de negócios, o que pode ser um empecilho, já que não é possível indisponibilizar o acesso ao cliente, para que as alterações que o transformem em serviço generalizado sejam feitas.

2. Princípio: Todo serviço deve ter um contrato formal

O que é: Contratos são documentos textuais que descrevem o que o serviço faz. Os padrões WSDL (Web Service Description Language), UDDI (Universal Description Discovery and Integration) e SOAP (Simple Object Access Protocol) são muito utilizados no dia-a-dia. O padrão SOAP é utilizado pelos Web Services e é responsável por definir o modelo da troca de mensagens. Para isso utiliza um arquivo XML que define envelopes e os nós intermediários da comunicação. O padrão WSDL é responsável por identificar o protocolo e o endereço no qual um serviço está publicado, assim como seus parâmetros de entrada e saída. O padrão UDDI permite que os serviços sejam categorizados, porém sem fornecer uma riqueza de textos para que buscas por um serviço específico sejam feitas. Aspectos positivos: Esses contratos são capazes de traduzir com detalhes a funcionalidade dos serviços especificados para que os clientes possam buscá-los e utilizá-los conforme a sua necessidade. Dificuldades: Para que todos os detalhes de implementação de um serviço sejam especificados, são necessários diversos padrões de contratos a serem utilizados por toda a corporação. Isso pode se tornar uma tarefa complexa caso haja a necessidade de migração de documentos (já criados) para o conjunto de padrões escolhidos. Os padrões básicos de SOA se autocompletam. Assim sendo, fica claro que a presença de contratos formais auxilia em um outro padrão a será discutido mais pra frente, que define que os serviços devem ser localizáveis.

3. Princípio: Serviços têm baixo acoplamento

O que é: O baixo acoplamento de um serviço está relacionado com a sua capacidade de ser independente de outros serviços para realizar a sua tarefa; Além do baixo acoplamento, é importante que um serviço tenha alta coesão, ou seja, a sua atividade seja bem definida e coerente; Existem alguns tipos de acoplamentos: Acoplamento de Implementação Acoplamento de Contrato Acoplamento de Service Policies Acoplamento de Processos Acoplamento de Estrutura de Dados Acoplamento de Infraestrutura Acomplamento Semântico A interoperabilidade dos serviços permite que clientes projetados em diversas tecnologias de linguagem de programação possam acessar os serviços de forma transparente. Com esse intuito, alguns padrões foram criados pela Web Services Interoperability (WS-I) para as interfaces dos serviços. Aspectos positivos: Hoje em dia os ambientes de desenvolvimento são cada vez mais heterogêneos. Um sem-número de tecnologias são utilizadas paralelamente e isso não deve influenciar na utilização dos serviços, que são tratados pela implementação de maneira idêntica; A adoção de uma boa prática de desacoplamento faz com que as estruturas respeitem um padrão utilizado dentro do ambiente corporativo; O desacoplamento aumenta o potencial de reúso do conjunto de serviços; Dificuldades: Identificar os pontos de acoplamento potencialmente elimináveis; Criar serviços totalmente desacoplados de qualquer estrutura, já que não existem padrões definidos para determinadas soluções (como por exemplo o uso de ESB‘s, no caso do desacoplamento de Infraestrutura). Sobre Contratos Formais, os princípios de SOA se autocompletam. O desacoplamento dos serviços também se relaciona com a criação dos contratos, assim como favorece o reúso.

4. Princípio: Serviços abstraem a lógica O que é: Serviços devem ser tratados como uma caixa preta, assim como componentes de um sistema. Assim sendo, a programação nele inclusa pode ser substituída a qualquer momento, sem afetar aqueles que o consomem. Essa abstração deve existir tanto na linguagem de programação quanto na tecnologia, ou seja, os serviços devem tratar todas linguagens e tecnologias que o consomem da mesma forma, ignorando distinções como por exemplo big-endian ou little-endian (ordem dos bytes nas palavras). Aspectos positivos: Esse princípio é rotineiramente aplicado hoje em dia, não possui dificuldades em sua implementação; Permite que agentes humanos interajam com sistemas complexos de forma simples, já que a suas interfaces são de simples compreensão. Dificuldades: Algumas dificuldades podem ser encontradas com linguagens mais antigas ou menos poderosas, como Cobol. O fato de serem menos complexas leva ao fato de poder exigir um certo esforço para converter os dados de modo a deixar as chamadas transparentes a qualquer consumidor. Exemplo: Situação inicial: Disponibilizamos um serviço que conta o número de verbos em um texto. Para isso, o serviço faz uma lista de palavras e, iterando essa lista, verifica quais são verbos, em um dicionário. …

 public Integer numeroDeVerbos(String texto){
   // quebro o texto nos espaços em branco
   String [ ] arrayDePalavras = texto.split(" ");  

   int contador = 0; // contador de verbos
   for (int i = 0; i<arrayDePalavras.length; i++){

     // verifica se a palavra é verbo
     if ( PalavraEVerbo(arrayDePalavras[i]) ){
       // se a palavra é verbo, acrescenta 1 no contador
       contador ++;
     }
   }

   return contador;
 }

…

Situação secundária: Queremos disponibilizar, além do serviço inicial, dois novos serviços. Um deles que retornará o número de substantivos de um texto e o outro o número total de verbos + substantivos. … public Integer numeroDeVerbos(String texto){ String [ ] arrayTemp = contaVerbosESubstantivos(texto); return arrayTemp[0]; }

public Integer numeroDeSubstantivos(String texto){ String [ ] arrayTemp = contaVerbosESubstantivos(texto); return arrayTemp[1]; }

public Integer numeroDeVerbosESubstantivos(String texto){ String [ ] arrayTemp = contaVerbosESubstantivos(texto); return arrayTemp[0] + arrayTemp[1]; }

/*

• esse método retorna um array com 2 posições,
• na primeira delas o total de verbos do texto, na segunda,
• o total de substantivos
• /

private Integer [ ] contaVerbosESubstantivos(String texto){

 // quebro o texto nos espaços em branco
 String [ ] arrayDePalavras = texto.split(" "); 

 int contadorDeVerbos = 0; // contador de verbos
 int contadorDeSubstantivos = 0; // contador de substantivos

 for (int i = 0; i<arrayDePalavras.length; i++){
   // verifica se a palavra é verbo
   if ( PalavraEVerbo(arrayDePalavras[i]) ){ 

     // se a palavra é verbo, acrescenta 1 no contador
     contadorDeVerbos ++;

   }else if(PalavraESubstantivo(arrayDePalavras[i])){

     // se a palavra é substantivo, acrescenta 1 no contador
     contadorDeSubstantivos ++; 

   }
 }

 Integer [ ] retorno = {contadorDeVerbos, contadorDeSubstantivos};
 return retorno;

} …

Na visão do usuário existem 2 novos serviços e o serviço antigo funciona como antes. Na visão do implementador, ele abstraiu a lógica do serviço inicial (numeroDeVerbos) e criou um método privado (contaVerbosESubstantivos) para reutilizar o código nos novos métodos (numeroDeSubstantivos e numeroDeVerbosESubstantivos) e o primeiro serviço continuou tendo a mesma funcionalidade de antes.

5. Princípio: Serviços são capazes de se compor

O que é: A característica de os serviços capazes de se compor consiste em criar serviços que sejam capazes de se juntar e serem acessados de forma a englobar e atender um problema maior. A composição dos serviços pode ser: Primitiva - quando há apenas a troca de mensagens entre um conjunto de serviços; Complexa - quando um conjunto de serviços oferece uma solução lógica sofisticada, ou seja, diversas trocas de mensagens entre um conjunto de serviços que são executados paralelamente. Aspectos positivos: O princípio de dividir para conquistar é muito conhecido há anos e tem como principal objetivo simplificar os problemas encontrados no dia-a-dia. Com possibilidade de criar composições de serviços, eles tornam-se capazes de resolver grandes problemas com a complexidade de um simples serviço. Dificuldades: A troca de mensagens entre os serviços pode torná-lo mais complexo e o princípio de baixo acoplamento não deve ser desrespeitado em detrimento disso. Os serviços devem comunicar-se para tornarem-se mais completos, e não interdependentes. Exemplo: Situação inicial: É necessário serviços de validação dos dados de um cadastro de usuários em um sistema. Os dados a serem validados são o CPF, o cartão de crédito e o endereço. No barramento de serviços A, é possível descobrir o serviço de validação dos dados. No barramento de serviços B encontramos 3 serviços: Validador de CPFs; Validador de Cartões de Crédito; Validador de Endereços. No diagrama abaixo podemos ver como os serviços simples são capazes de se compor e resolver o problema mais complexo que é a validação de dados. Cada seta ilustra a troca de mensagens entre os serviços. O serviço que valida os dados consulta cada validador individual e é responsável pela validação completa dos dados. A troca de mensagens entre o serviço de validação de cartões de crédito e de validação de endereços é uma forma de aprimorar a simples validação do número do cartão junto à operadora de cartões de crédito.

Exemplo prático

Exemplos de SOA

O SPC disponibiliza um serviço classificação de clientes inadimplentes, e um banco está disponibilizando um pacote de financiamento novo que deverá ser implementado um novo sistema para este pacote onde o desenvolvedor terá que fazer uso do serviço disponibilizado pelo SPC para avaliar o cliente que deseja fazer o financiamento, o desenvolvedor abstrai o código de classificação de clientes inadimplentes, e desenvolve o produto. sem contar que na próxima vez que o banco necessitar criar um novo pacote e um novo sistema ele já pode novamente contar com o serviço de classificação dos clientes.

Outro exemplo interessante e a utilização do mesmo serviço mas com interesses diferentes, suponhamos que uma empresa americana disponibilize um serviço de informação de fluxo de tráfego muito utilizada por taxistas e transportadoras, onde o motorista ao receber a avaliação de tráfego de uma determinada rua, poderá traçar uma rota alternativa para não atrasar sua entrega, este mesmo serviço e consumido por um despertador moderno que tem uma função soneca inteligente na casa de um trabalhador, no qual está programado para às 07:00hs, mas neste momento o despertador avalia a informação recebida pelo serviço, e se o trânsito flui normalmente o despertador dá ao trabalhador mais 5 minutos de tolerância no sono.

Referências

• SOA e Web Services em Java - Cleuton Sampaio
• Barry, Douglas K. (2003) Web Services and Service-Oriented Architectures
• Lane, Edward (2004). SOA fundamentals and characteristics