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.

2 ideias sobre “SOA – Escolhendo e definindo bons serviços candidatos

  1. Acredito que hoje o maior problema encontrado durante o processo de arquitetura de software é o desespero do cliente X fornecedores. Uma vez que a modelagem inicial não é planejada e realizada com eficiência, criamos serviços sem reuso e com isso deixamos a arquitetura SOA incorreta, pois elaboramos serviços apenas para necessidade atual sem pensar em novas melhorias.

    Com a alta demanda de SaaS, SOA tem se tornado um elemento fundamental dentro das corporações. Cabe ao time de arquitetura estudar o negócio e o sistema afim de oferecer melhores soluções para a corporação.

    Todo este artigo foi bem elaborado e explicado como devemos seguir os processos para sugerirmos e gerenciarmos uma boa arquitetura.

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

*

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>