Olá Pessoal, li recentemente este Report do Forrester sobre o ritmo de adoção SOA e achei muito interessante, pois mata de vez aquele boato “Is SOA dead?” – segundo as pesquisas do Forrester, não!

Na verdade está longe de morrer, segundo o relatório: mesmo com a crise do ano passado abalando os departamentos de TI, dentre outros, SOA neste período continuou com um ritmo de adoção bastante forte, tanto por empresas de grande porte quanto por empresas de médio e pequeno porte.

A pesquisa também mostra que mais de 80% das empresas estão usando SOA agora (o agora é o Q42009) ou estarão até o final de 2010. E que o nível de satisfação continua alto: mais de 70% das empresas que estão adotando SOA se manifestaram satisfeitas com os resultados que estão conseguindo com a abordagem. No entanto, enfatizam que não foi fácil chegar aos resultados satisfatórios e que governança SOA é um fator crítico para o sucesso.

Related posts:

1. Aplicação de Metodologia Ágil em Consultorias SOA
2. O Modelo Canônico em uma abordagem SOA
3. O papel dos Repositórios SOA

No último post escrevi sobre o princípio que define que serviços abstraem a lógica, com um exemplo de uso.

Voltando a falar sobre os princípios básicos da arquitetura orientada a serviços, nesse post escreverei sobre o quinto item da nossa lista: os serviços são capazes de se compor. A cada princípio, eles se mostram cada vez mais complementares e, de certa forma, até mesmo intuitivos. Isso deve facilitar o entendimento dos conceitos aqui apresentados.

Serviços são Capazes de se Compor

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 de composição de serviços

No próximo post falarei sobre o sexto princípio da nossa lista: os serviços devem ser autônomos.

Related posts:

1. O Modelo Canônico em uma abordagem SOA
2. O lado técnico da aquisição de um ESB

Após um tempo sem escrever, vou continuar explicando um pouco mais sobre os princípios básicos de SOA. Relembrando o que já foi escrito, passamos pelos primeiros três princípios, que tratam de serviços serem reutilizáveis, compartilharem um contrato formal e possuírem baixo acoplamento.

Hoje vou falar sobre o princípio que diz que os serviços devem abstrair a lógica nele contida. Ao final da explicação vou inserir um exemplo em JAVA para tentar ilustrar o princípio e facilitar a compreensão.

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.

Related posts:

1. Avaliando a maturidade em SOA
2. O Modelo Canônico em uma abordagem SOA
3. O lado técnico da aquisição de um ESB

Serviços Possuem Baixo Acoplamento

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).

Como havia dito no post anterior, 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.

No próximo post falarei sobre abstrair a lógica dos serviços, que favorece a interação de sistemas complexos.

Até mais!

Related posts:

1. O Modelo Canônico em uma abordagem SOA
2. O lado técnico da aquisição de um ESB
3. O papel dos Repositórios SOA

No post anterior falei sobre o primeiro princípio de SOA, que trata de definir que Serviços devem ser Reutilizáveis. Nesse post falarei sobre o segundo princípio que diz que os serviços devem possuir contratos formais.

Serviços compatilham um Contrato Formal

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.

No próximo post falarei sobre a característica de baixo acoplamento, que os serviços devem possuir dentro da Arquitetura Orientada a Serviços.

Até a próxima!

Related posts:

1. O Modelo Canônico em uma abordagem SOA
2. Aplicação de Metodologia Ágil em Consultorias SOA
3. O papel dos Repositórios SOA

• 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 que descreverei 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.

No próximo post falarei um pouco mais sobre o segundo princípio de SOA: os contratos formais de serviços. Além disso, apresentarei alguns protocolos, como o WSDL.

Related posts:

1. O Modelo Canônico em uma abordagem SOA
2. O lado técnico da aquisição de um ESB

Aqui no blog temos discutidos diversos tópicos avançados a respeito de SOA, e até mesmo por pedidos de alguns visitantes, segue aqui uma visão inicial do que seria a Arquitetura Orientada a Serviços, se tivéssemos que a definir em poucas palavras.

Esse post é escrito para aqueles que são iniciantes na abordagem de Arquitetura Orientada a Serviços. Recentemente essa área ganhou muito espaço no meio corporativo, com ela muitos são os conceitos presentes em documentos que tratam de SOA e para os iniciantes o assunto torna-se um bicho de sete cabeças.

Origem de SOA

O desenvolvimento de aplicações em ambientes corporativos ganhou, com o tempo, proporções que não poderiam ser previstas a curto prazo. Esse crescimento desordenado criou uma espécie de “colcha de retalhos” onde cada componente é desenvolvido para ligar 2 pontos específicos e possuem alto acoplamento dentro do sistema fazendo com que haja uma grande redundância de funcionalidades.

Arquitetura Tradicional

O que é acoplamento? É o nível de interdependência entre os módulos de um sistema. Por outro lado, um módulo é considerado coeso quando possui uma atividade bem definida. (veja mais)

Definição de Acoplamento

Diferentemente do que as pessoas pensam, SOA não se trata de uma simples invenção. A arquitetura orientada a serviços nada mais é que a evolução natural da arquitetura de sistemas tradicional para solucionar as necessidades de desenvolvimento e capacidade de adaptação às novas demandas de mercado, que se faz cada vez mais exigente em qualidade e agilidade.

Para os desenvolvedores isso significa ter que criar sistemas semelhantes com ajustes particulares para cada componente. Para as empresas isso significa dinheiro jogado fora, já que os componentes poderiam ter sido feitos voltados para o reúso.

O que SOA não é

Para reforçar a definição de SOA cabe deixar explícito o que não faz parte desse conceito. Para começar, vale deixar claro que SOA não é uma tecnologia. SOA é mais baseada em logística e conceitos e menos em ferramentas.

SOA não é um produto, portanto não é possível comprar SOA.

Os conceitos de Arquitetura Orientada a Serviços, WebServices, XML e BPM são relacionados no mundo SOA, mas são distintos no mundo de TI, portanto:

SOA != WebServices != XML != BPM

Definição de SOA

SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas.

Princípios Básicos de SOA

Segue abaixo uma lista com os 8 princípios básicos da Arquitetura Orientada a Serviços.

• 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.

Em breve escreverei com mais detalhes sobre cada um deles.

Por fim, não posso deixar de agradecer a ajuda especial do Rafael no desenvolvimento do post!

Até a próxima.

[]‘s

– Gabriel

Related posts:

1. O Modelo Canônico em uma abordagem SOA
2. O lado técnico da aquisição de um ESB