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:

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:

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.