SOA – Escolhendo e definindo bons serviços candidatos

Esse é o terceiro de uma série de artigos do nosso blog que estão abordando o tema SOA, conceito antigo e moderno que está enraizado nas atividades cotidianas da iProcess.

No primeiro post nós respondemos à pergunta: o que é SOA? Já no segundo definimos o que é um serviço.

Nesse terceiro post gostaríamos de trazer algumas estratégias que podem ser utilizadas na definição e na escolha de bons serviços candidatos.

 

Ciclo de desenvolvimento de serviços
O desenvolvimento em uma arquitetura orientada a serviços pressupõe algumas mudanças na forma com que tradicionalmente se faz o desenvolvimento orientado a sistemas.

O ciclo de desenvolvimento de serviços envolve:

Ciclo de Desenvolvimento de Serviços

Normalmente vemos que a descoberta de serviços nasce da necessidade de aprimorar alguma função ou processo de negócio. Nesse sentido, os candidatos a serviços de negócio são:

Candidatos a serviços de negócio

Existem duas abordagens comumente utilizadas na descoberta de serviços. Vamos ver abaixo.

  • Abordagem top-down: Essa abordagem identifica a necessidade de um serviço através da análise de processos de negócio ou das interações com entidades externas. Ela normalmente é realizada pelo analista de negócio em conjunto com arquiteto de sistemas e tem como principal benefício o alinhamento mais natural com o negócio. Se o serviço (ou as capacidades necessárias) já existir em um sistema legado, será necessário procurá-lo e extraí-lo. Se o serviço ainda não existir, é necessário construí-lo.
  • Abordagem bottom-up: serviços (ou capacidades) identificados através dos pontos de integração entre sistemas ou das funcionalidades já disponíveis nos sistemas atuais. Nessa abordagem corre-se o risco de criar serviços que não representam uma função de negócio ou que tenham acoplamento com a implementação. Porém, pode ser uma boa opção quando existem muitos problemas de integração spaghetti ou se deseja preparar para substituição de algum sistema de back-end.

 

Modelagem e projeto de serviços

Na hora de modelar e projetar um serviço, o primeiro passo é ajustar a sua granularidade, adequando-o a um modelo de níveis (camadas) de serviços que tenha sido definido pela sua corporação. Por exemplo:

  • Básicos (acesso a dados, funções mais simples);
  • Serviços compostos (orquestração, funções mais complexas);
  • Processos de negócio, workflows.

Outra possibilidade é classificar os serviços por área ou processo de negócio. De acordo com a granularidade, pode ser necessário quebrar em vários serviços, reunir com outros, reorganizar, etc.

 

Além disso, devem-se identificar as entidades conceituais relevantes para a empresa e suas interrelações, criando um modelo conceitual corporativo, independente das tecnologias ou sistemas já existentes.

São exemplos de entidades conceituais: Cliente, Proposta, Produto, Ordem de Compra, Item de Compra, Nota Fiscal, Centro de Custo, Funcionário.

Sugere-se também a criação de um repositório com esses modelos de dados corporativos e suas respectivas descrições de estruturas XML (esquemas XML), já que o modelo conceitual é a base para o projeto de serviços.

Poderá ocorrer que a aplicação que implementa um serviço já existente não se encaixe no modelo conceitual. Nesse caso, será preciso criar um elemento de adaptação.

 

A seguir deverá ser definido o projeto da interface. É importante salientar que a chave para um projeto duradouro de contrato de serviço é pensar apenas no negócio. A interface sempre deve ser definida antes da implementação do serviço. O nome do serviço, entradas, saídas, exceções e comportamento devem ser descritos somente em função dos termos de negócio, abstraindo implementações. Também, devem ser utilizados os esquemas XML dos tipos de dados do modelo corporativo e a interface do serviço deve ser descrita através de um arquivo no padrão WSDL – Web Services Description Language.

 

Nesse ponto, nos perguntamos: como nomear um serviço? Comprar ou vender? Notificar ou receber notificação?

A regra geral é: identifique o serviço do ponto de vista do consumidor. O consumidor pode ser sua própria empresa (solicitar compra de material) ou uma entidade externa (solicitar proposta). Se possível, utilize um meio-termo (registrar, cadastrar, criar), mas assegure-se de não gerar ambiguidades.

E as entradas e saídas de um serviço, como identificá-las?

Utilizar sempre as entidades do modelo conceitual. Resista à tentação de colocar IDs como parâmetros do serviço. Esta é uma abordagem vinculada à implementação relacional. Ex.: ID requisição → Requisição

 

Muito importante lembrar que, ao expor novas funcionalidades como serviços, serão necessários novos tratamentos de segurança. Não é mais possível contar com a segurança da aplicação, uma vez que o serviço é um ente independente. Será preciso definir:

  • quem pode executar quais serviços;
  • mensagens a serem criptografadas;
  • integração de diretórios de usuários e perfis.

Alguns dos padrões emergentes para segurança de serviços são o WS-Security, WS-Policy e SAML (Security Assertion Markup Language).

 

Existem, ainda, requisitos não-funcionais que devem ser levados em consideração. Embora os acordos de nível de serviço (SLA) sejam um aspecto gerencial, que normalmente devem ser negociados pelo gestor da TI com a área ou entidade cliente, a identificação dos requisitos de qualidade precisa ser feita o quanto antes. Aspectos como desempenho, escalabilidade e disponibilidade devem ser derivados dos requisitos do negócio e podem ser elicitados com as técnicas tradicionais da Engenharia de Requisitos. O projeto da implementação deve prover a capacidade de atender os níveis desejados.

 

Ao final da modelagem, você precisará responder afirmativamente as seguintes perguntas:

  • o serviço provê uma função de negócio?
  • o serviço é auto-condido, independente?
  • o serviço é reutilizável?
  • o serviço pode ser utilizado em uma composição?
  • o serviço esconde todos os detalhes de implementação?
  • o serviço utiliza apenas entidades conceituais na definição?

E por último responda se a interface do serviço teria que sofrer alterações se a implementação mudar. É a garantia que a modelagem do seu serviço foi realizada de maneira correta!

 

Identificando bons serviços candidatos
A definição do portfólio de serviços deve considerar os seguintes pontos:

  • redundância atual da funcionalidade;
  • quantidade de sistemas fortemente acoplados à funcionalidade;
  • volume esperado de modificações na funcionalidade;
  • grau de agilidade necessária na execução das modificações;
  • perspectiva de reutilização do serviço;
  • complexidade de fatorar o serviço dos sistemas atuais (impacto nos sistemas legados).

Uma função que só é chamada uma vez por um único sistema não é candidata e uma função que é chamada por vários sistemas é uma ótima candidata.

 

Mas, então, e na hora de criar um novo software, como identificar o que é candidato para se transformar em um novo serviço? Em primeiro lugar é fundamental entender o processo de negócio no momento de desenhar a solução de software e olhar além das fronteiras do projeto em questão. Tente identificar o que outros consumidores do seu sistema irão precisar.

No caso de softwares já existentes, verifique o que pode virar serviço, olhando para as funcionalidades internas e externas.

 

Dessa maneira será possível ter serviços consistentes e que correspondam às reais necessidades da sua empresa.

SOA – Arquitetura Orientada a Serviços

Esse é o primeiro de uma série de artigos do nosso blog que vão abordar o tema SOA, conceito antigo e moderno que está enraizado nas atividades cotidianas da iProcess.

Nesse primeiro post gostaríamos de responder à simples pergunta: o que é SOA?

 

O que é SOA?

SOA significa Service-Oriented Architecture, ou Arquitetura Orientada a Serviços, numa tradução livre.

O conceito foi proposto pela primeira vez em 1996, no artigo “Service Oriented Architectures” (abril de 1996), escrito pelos pesquisadores Roy Schulte e Yefim Natis do Gartner Group. Eles o apresentaram à partir da análise de experiências de diversos clientes que, na época, utilizavam a tecnologia cliente-servidor (em forte adoção naqueles anos), e que ganhou novamente atenção em virtude das novas possibilidades tecnológicas baseadas em padrões, da demanda crescente por soluções de integração e de relativo insucesso de outras alternativas.

É possível encontrar diferentes e variadas definições de SOA. Eis algumas delas:

Definição do Gartner Group

Definição do OASIS

Definição encontrada na Wikipedia

Depois de alguns anos a iProcess também teve a ousadia de propor uma definição para SOA:

“SOA é uma filosofia de TI que visa facilitar a integração entre sistemas, orientando a criação e a disponibilização de soluções modulares e fracamente acopladas baseadas no conceito de serviços”

À partir dessas definições podemos chegar a algumas conclusões à respeito de SOA.

  • SOA não é uma tecnologia. Há tanto de negócio quanto de tecnologia em SOA. As tecnologias (padrões) que dão suporte a SOA são o que a viabiliza, mas SOA não é uma tecnologia por si só.
  • SOA não é uma metodologia. Há várias metodologias (processos, ferramentas, métodos de trabalho) que podem ser usados para implantar SOA com sucesso. SOA não é e nem define alguma metodologia.
  • SOA pode ser considerada uma filosofia arquitetural. SOA é uma linha de pensamento que permeia a implementação de necessidades de negócio, refletida em diretrizes, políticas e metodologias corporativas, não necessariamente restritas à área de TI.
  • SOA não é algo que se possa comprar ou instalar.
  • SOA não é um webservice.
  • SOA não cria nada. Ela apenas sugere, propõe, define.
  • SOA baseia-se no conceito do uso de serviços atômicos, independentes e com baixo acoplamento.

 

SOA e suas características

Algumas das principais características que podemos encontrar usando SOA são:

Dessas características salientamos o “fraco acoplamento de serviços” que, na prática, significa minimizar o impacto das modificações e das falhas dentro de cenário do sistema como um todo. Sobre esse assunto veja mais nesse artigo.

 

SOA e seus benefícios

São esperados diversos benefícios no uso do SOA. Alguns deles relacionamos abaixo:

  • Facilidade de Manutenção: mudanças na lógica de negócios (implementação) não afetam aplicações existentes;
  • Reuso: novas aplicações e processos (consumidores de serviços) podem reaproveitar mais facilmente as funcionalidades existentes;
  • Flexibilidade: sistemas de back-end e infraestrutura podem ser substituídos com menor impacto;
  • Resultado: agilidade e redução de custos;
  • Qualidade: garantia de homogeneidade de processos;
  • Menor tempo: agilidade na análise de impacto e no desenvolvimento evolutivo de seus sistemas;
  • Menor custo: redução do custo de manutenção das aplicações;
  • Controle: conhecimento dos ativos existentes.
Em breve vamos continuar a tratar desse assunto em outros artigos, trazendo a definição de serviço e como escolher bons serviços candidatos.

Construção de serviços simulados utilizando Java

No desenvolvimento de sistemas com base na arquitetura orientada a serviços (SOA), frequentemente nos deparamos com a necessidade de utilizar serviços já existentes na infraestrutura do cliente, mas que não estão disponíveis no nosso ambiente de desenvolvimento local. Ainda, na maioria das vezes não temos a possibilidade de instalar localmente tais serviços devido a dependências destes com outros serviços, bibliotecas ou outros componentes que somente estão disponibilizados no ambiente integrado do cliente.

Nestes casos, podemos fazer uso de um recurso muito útil: a construção de versões simuladas de serviços, ou mocks como são chamados em inglês. A ideia é podermos disponibilizar no ambiente local um serviço que exponha o mesmo contrato WSDL que o serviço original, ou seja, as mesmas operações e tipos de dados.

Uma das alternativas para a criação de um serviço simulado é implementá-lo observando as operações e os tipos de dados expostos pelo serviço original e recriando-os completamente, por exemplo, utilizando Java e JAX-WS. Porém, para os casos em que temos acesso ao contrato WSDL do serviço original, é mais simples e seguro construirmos o mock diretamente a partir dele.

Vamos então demonstrar como construir um serviço simulado em Java, a partir do contrato de um serviço original, em um passo-a-passo utilizando o Oracle JDeveloper.

Primeiramente, para exemplificar, vamos supor que estamos desenvolvendo um sistema que deverá invocar o serviço de cálculo de prazo e custo dos Correios, mas o serviço real somente deverá ser utilizado quando a solução for integrada no ambiente do cliente. Logo, em tempo de desenvolvimento, devemos construir um mock do mesmo.

1 – Criação da aplicação

Comece criando uma nova aplicação genérica no JDeveloper:2 – Criação de novo projeto

Crie um novo projeto genérico a partir do passo seguinte do wizard de nova aplicação ou a partir da opção de Novo Projeto, se você estiver criando um segundo mock dentro de uma aplicação já existente no JDeveloper.

Não é preciso selecionar nenhuma tecnologia para o projeto, podendo-se encerrar o utilitário de criação do novo projeto clicando no botão Finish.

3 – Criação do webservice

Clique com o botão direito no projeto criado e escolha a opção New. Na janela de opções, selecione no lado esquerdo a categoria “Web Services” e no lado direito “Java Web Service from wsdl”.

No wizard de criação do serviço, escolha como plataforma “Java EE 1.5, with support for JAX-WS RI”:

Clique em Next. Neste momento é preciso abrir o arquivo WSDL do serviço original. No nosso exemplo vamos especificar a URL para o WSDL do serviço original dos correios, que está disponível em http://ws.correios.com.br/calculador/CalcPrecoPrazo.asmx?WSDL (marque para criar cópia local do contrato).

Clique em Next novamente, especifique o nome do pacote Java e finalize o wizard. Pronto! Está criado o novo serviço mock, expondo o mesmo contrato WSDL que o serviço original. Deverão ter sido criadas classes Java para todos os tipos de dados envolvidos nas mensagens de entrada e saída das operações, bem como a implementação do serviço com as devidas anotações.

Como passo final, edite o novo arquivo XXXImpl.java (onde XXX corresponde ao nome do seu serviço simulado) para codificar o retorno de dados de teste nas operações expostas pelo serviço, como no exemplo a seguir:

Agora basta fazer o build do arquivo .war do serviço e disponibilizá-lo em seu servidor de aplicações local. Veja os valores que setamos sendo retornados em um teste de invocação do serviço simulado, depois de disponibilizado em um servidor Weblogic 11g: