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 – O que é um serviço?

Esse é o segundo 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á nesse segundo gostaríamos de responder outra pergunta: o que é um serviço?

 

O que é um serviço?

O conceito de serviço surge como uma forma de resolver alguns problemas da integração de sistemas. No entanto, agrega a idéia de alinhamento com o negócio.

Assim, podemos dizer que um serviço:

  • é uma unidade de software que executa uma função de negócio;
  • estabelece um contrato bem definido: entradas, saídas, restrições, premissas, comportamento (lógica de negócio);
  • esconde do seu consumidor todos os detalhes de implementação, incluindo infraestrutura e lógica interna;
  • é auto-contido, independente e modular;
  • pode ser reutilizado em outros contextos;
  • realiza uma função de negócio integralmente, de forma consistente;
  • pode ser disponibilizado e administrado individualmente;
  • pode ser combinado com outros serviços para compor um serviço de mais alto nível ou um processo de negócio;

A arquitetura orientada a serviços desenvolveu-se com a idéia de basear a construção de aplicações em torno do conceito de serviços, facilitada pelo amadurecimento de padrões como XML e Web Services.

 

Características de um serviço

Algumas das características de um serviço são:

  • o contato com o serviço é feito exclusivamente através da sua interface;
  • o consumidor do serviço não necessita saber detalhes do funcionamento interno do serviço;
  • podem ser síncronos ou assíncronos;
  • encapsulado, modular e reutilizável;
  • o contrato:
    • descreve o seu objetivo e o seu comportamento;
    • define os parâmetros de nível de serviço (disponibilidade, confiabilidade, etc).

 

Interface do serviço

A interface representa um “contrato” entre o provedor e o consumidor do serviço e deve identificar pelo menos:

  • Nome do serviço
  • Entradas
  • Saídas
  • Comportamento esperado
  • Comportamento em caso de exceções

A interface deve ser projetada de modo independente da implementação. Ou seja, pergunte-se: “se a implementação for alterada, poderei manter a mesma interface?”. E isto é realmente muito importante! Caso contrário, o baixo acoplamento, fundamental para SOA, não existirá.

A composição de um serviço pode ser representada da seguinte maneira:

Modelo de composição de um serviço

Onde:

  • Consumidor: entidade interessada em utilizar o serviço;
  • Interface: acordo para interação entre consumidor e provedor;
  • Provedor do serviço: entidade responsável por oferecer o serviço;
  • Implementação: lógica de negócio que executa os passos para atingir os objetivos do serviço.

 

Exemplos de serviços

Como resultado, podemos citar alguns exemplos de serviços:

Alguns exemplos de serviços

Aprofundando um pouco mais, vamos citar um exemplo de como seria a definição completa de um serviço:

  • Ação: Verificar crédito do cliente
  • Nome do serviço: VerificarCreditoCliente
  • Comportamente Esperado: Receber o CNPJ do requisitante e do Cliente e retornar a situação cadastral e do seu crédito
  • Entrada: CNPJRequisitante (numerico), CNPJCliente (numerico)
  • Saída: CNPJRequisitante (numerico), CNPJCliente (numerico), ClienteAtivo (true/false), ValorCredito (numerico), UltimaAtualizacao (data)
  • Exceções:
    • Negócio: RequisitanteInvalido, ClienteInvalido
    • Técnico: ServicoInativo, TimeOut

Citamos agora o exemplo de um sistema que expõe 2 serviços: RegistroAusencia e ConsultaSalario. Sempre como exemplo, o primeiro serviço é utilizados pelos processos de viagem e licença médica e o segundo pelo sistema de folha de pagamento.

Exemplo de um Sistema de RH

 

No contexto SOA, é muito importante não confundir uma sub-rotina reutilizável de software com um serviço. Para exemplificar isso, citamos um contra-exemplo de serviço: “validar CPF”. A ação não é adequada para ser serviço, já que não é uma função de negócio por si só e sim um algoritmo, uma peça de software.

Uma opção seria essa peça de software fazer parte de um serviço chamado “verificar integridade dos dados cadastrais”. O serviço poderia verificar a validade do CPF, o preenchimento correto de todos os campos, a consistência entre eles, a coerência com outros dados da base, etc.

Outros contra-exemplos de serviço:

  • Gravar registro no sistema XYZ → acoplado à infraestrutura;
  • Preparar dados → não executa uma função completa.

 

Confusões comuns sobre o conceito de serviço

Serviços X WebServices
WebServices é uma tecnologia de comunicação, utilizada para expor as funcionalidades de um componente de software. Serviços beneficiam-se da tecnologia dos WebServices para prover transparência da implementação (baixo acoplamento).

Serviços X componentes de software
Componentes de software são elementos que implementam alguma lógica. Combinados, podem fornecer funções de negócio, mas isolados podem ser apenas funções de infraestrutura, de comunicação, de manipulação de dados, ou até mesmo de negócio.
Um serviço não deve obrigatoriamente ser implementado como uma função única de software. Pelo contrário. As boas práticas de Engenharia de Software, como a componentização e a orientação a objetos, podem e devem ser utilizadas.
Vários componentes de software (como a validação do CPF) podem ser combinados para implementar um serviço de negócio.

 

Em breve vamos continuar a tratar desse assunto, trazendo sugestões para auxiliar a escolha de bons serviços candidatos.

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.