Exemplo: Exemplo de Modelo SOA

Descrição do Problema Início da página

Nesse exemplo, consideramos os problemas de um varejista que foi escolhido para reimplementar determinadas funções utilizadas pelos aplicativos em seus terminais PoS (Point-of-Sale) como serviços. Hoje em dia o aplicativo de comércio é desenvolvido como um aplicativo monolítico com muitos componentes livremente acoplados, mas com alguns componentes residindo no ISS (In-Store Servers) e alguns pedidos são enviados pelo ISS para os servidores centralmente localizados na empresa. O problema é que a infra-estrutura de armazenamento em geral e o aplicativo de comércio podem especificamente serem difíceis de manter, em decorrência de acoplamento firme de componentes e o uso de protocolos de proprietários e tecnologia no desenvolvimento de, e conexão entre, componentes.

Em gerações anteriores do proprietário de sistemas de armazenamento e máquinas de baixa capacidade foram utilizados para os terminais PoS e houve restrições no armazenamento interno da largura da banda, bem como no armazenamento externo - essas restrições são amplamente realizadas agora. Considerando-se isso, e a mudança existente para a service-oriented architecture dentro de sistemas backend corporativos, foi decidido que algumas das capacidades fornecidas pelo ISS e servidores centrais deveriam ser expostas para o aplicativo de comércio como serviços.

Escopo do Projeto e Metas Início da página

Inicialmente, as capacidades a serem consideradas foram escolhidas porque elas compartilham um padrão comum no qual, atualmente, requerem lógica no aplicativo de comércio para consultar mais de um data store para informações. Desta forma, os serviços propostos não apenas fornecem uma interface comum, mas também separam o aplicativo de comércio de conhecimento explícito do local de dados e de precisar tratar de múltiplos protocolos. Esses serviços serão acessados sobre RMI a partir do aplicativo de comércio, para o serviço ISS e utilizando SOAP sobre JMS a partir do ISS para o serviço central.

Identificação de Serviço Início da página

O itens a seguir destaca as etapas tentadas pela equipe de arquitetura que consistem em membros da própria organização IT dos varejistas e consultores externos apresentados como especialistas no desenvolvimento de service-oriented solutions. Observe que as etapas a seguir não são planejadas para representar uma série recomendada de atividades do RUP, elas apenas catalogam as atividades de um projeto real.

É importante observar que esse projeto serve para aprimorar a implementação técnica de funções atualmente existentes e, portanto, não incluem uma grande quantidade de tempo gasto na modelagem de negócio ou análise, conforme podemos reutilizar os modelos criados para o aplicativo de comércio original. O conjunto atual de modelos (à esquerda no diagrama a seguir) segue a estrutura mostrada abaixo, mostrando um Modelo de Caso de Uso do RUP, um Modelo de Análise para os componentes comuns do aplicativo de comércio seguido pelo Modelo de Design detalhado e, finalmente, um conjunto de Modelos de Implementação para as equipes de desenvolvimento Java.

O diagrama é descrito no conteúdo textual.

O Modelo de Serviço foi apresentado (à direita no diagrama a seguir) como um refinamento do Modelo de Análise em um conjunto de serviços com seus próprios Modelos de Implementação. O design do aplicativo de comércio pode agora ser modificado para mostrar o uso desses serviços comuns e o relacionamento entre o aplicativo de comércio e os modelos Java de serviço também são mostrados.

Criação do Modelo de Serviço

O Store Support Service Model foi criado de acordo com o Perfil UML para Software Services e o modelo de gabarito (incluído no Rational Software Architect), como descrito no diagrama a seguir. O modelo foi identificado como um refinamento do Modelo de Análise, como mostrado acima. Como você pode ver, a estrutura é apresentada em um diagrama de visão geral que demonstra as dependências entre as visualizações recomendadas pelo gabarito.

O diagrama é descrito no conteúdo textual.

Os links de diagramas próximos aos pacotes de visualização permitem a navegação rápida do modelo e serão concluídos nas seções a seguir.

Para obter informações adicionais, consulte o mentor de ferramenta Criando um Modelo de Serviço em RSA.

Identificar Partições de Serviços (Localidade)

É clara a descrição do problema acima, há várias formas de procurar o particionamento do sistema, por exemplo, podemos apresentar as partições que representam o gerenciamento de inventário, gerenciamento de serviço/garantia, operações de ponto de venda (procura por preço, cliente, etc.) No entanto, esses não são interesses principais do arquiteto e as partições incluídas no modelo representam localidades lógicas para os serviços fornecidos na loja ou no nível corporativo.

O diagrama é descrito no conteúdo textual.

Quando dizemos que essas são partições lógicas identificadas, estamos identificando que a partição Serviços da Loja contém um conjunto de serviços instanciados no nível da loja, nada é dito sobre a implementação física desses serviços (servidor único, cluster, etc.). Essas partições lógicas são fornecidas para o arquiteto, a fim de representar os aspectos significativos da solução.

Além disso, observe que na figura acima o arquiteto apresentou um elemento adicional, o próprio aplicativo de comércio, para permitir descrições de comunicação entre o aplicativo e os serviços. O aplicativo de comércio é um componente UML 2.0 com o estereótipo Consumidor de Serviço.

Para obter informações adicionais, consulte o conceito Particionamento de Solução.

Analisar Funções Existentes

A próxima etapa é analisar a implementação atual do aplicativo de comércio, procurar os detalhes do acesso ao banco de dados identificado na instrução do problema acima. A tabela a seguir foi, em seguida, desenvolvida (observe que ela contém apenas detalhes para as consultas do cliente e do inventário).
 
Nome Tecnologia Entradas Saídas Comentários
sp_get_custlist_by_phone Procedimento Armazenado SQL Server phonenum (char 10) Lista de:
custid (id)
custname (char 40)
Esse procedimento armazenado retorna uma lista de detalhes do cliente pelo número de telefone, a lista pode ser apresentada para o cliente para seleção. A chamada sp_get_cust_details é utilizada para retornar um único registro do cliente.
sp_get_cust_details Procedimento Armazenado SQL Server custid (id) Registro do cliente Os detalhes de um cliente são retornados, seu nome, endereço, informações de contato e assim por diante.
CUST_QUERY IBM MQSeries phonenum (char 10)
return-queue-name (char 120)
correlation-id (char 120)
N/D Nesta fila o aplicativo coloca os detalhes dos clientes para consulta, a mensagem é entregue para o centro, onde o servidor envia a mensagem de resposta para a fila de retorno identificada.
<return-queue-name> IBM MQSeries N/D correlation-id (char 120)
Lista de Registros do Cliente
Quando retornar os registros do cliente, a mensagem de retorno também contém o ID de correlação, para garantir que a resposta possa ser associada a um determinado pedido. Isso permite que o servidor na loja tenha uma única fila de retorno para todos os terminais, o terminal consulta a fila para uma mensagem de resposta com seu ID de correlação.
sp_get_invstate_for_sku Procedimento Armazenado SQL Server sku (char 13) registro do Inventory
INVENTORY_QUERY IBM MQSeries sku (char 13)
return-queue-name (char 120)
correlation-id (char 120)
N/D
<return-queue-name> IBM MQSeries N/D registro do Inventory

Como é possível ver, essas entradas representam a implementação existente, as quais serão substituídas por uma nova implementação, ainda a finalidade e a função serão mantidas.

Desenvolvimento de Especificação de Serviço Inicial

A atividade Identificação de Serviço apresenta várias técnicas para identificação dos serviços, e operações em serviços, necessárias para suportar uma solução. No caso desse exemplo, estmos procurando um formulário de renovação legado, a transformação da funcionalidade existente para um modelo de serviços e, especialmente, serviços de tecnologia de implementação. Fazendo isso, o primeiro aspecto é desenvolver o conjunto de Especificações de Serviços que fornecerão os contratos para os serviços implementando as funções descritas acima. O diagrama a seguir mostra as três especificações de serviços atualmente vazias criadas neste estágio, uma para cada um dos serviços discutidos na introdução.

O diagrama está descrito no conteúdo textual.

Em seguida, são analisados os padrões de utilização possíveis para os serviços, por exemplo, poderíamos na verdade, ter dois serviços, um na loja e um corporativo, onde a lógica para o acesso ao banco de dados e o acesso corporativo são encapsulados no serviço na loja. Alternativamente, é possível optar por ter um serviço de fachada na loja que encapsula a lógica e chama dois serviços idênticos, um que encapsula o acesso ao banco de dados e outro na empresa. A segunda opção inclui a flexibilidade na alteração da lógica acessar as duas lojas, ainda inclui código extra e custos de comunicação para uma função relativamente simples. Portanto, para a consulta do cliente e a procura do inventário a primeira opção foi escolhida. Até agora os detalhes da distribuição de serviços e os fornecedores de serviços não são decididos, a identificação de serviço é muito mais efetiva, se focalizada apenas em especificações de serviços.

Para identificar as funções e as responsabilidades desses serviços, utilizamos uma Colaboração de Serviços e, especialmente, um diagrama UML 2.0 Composite Structure representando a configuração dos serviços para procura do cliente. O diagrama de estrutura é mostrado a seguir e podemos ver o UML 2.0 Parts representando cada elemento na colaboração. Note, os conectores entre o Aplicativo de Comércio e o serviço em loja e entre os serviços em loja e corporativos são estereotipados como Canais de Serviços e denotam as ligações a serem utilizadas (RMI ou JMS como identificado acima). A ligação para o conector entre o serviço na loja e o componente do banco de dados local (mais tarde) é indefinida.

O diagrama é descrito no conteúdo textual.

Um elemento chave a ser observado aqui, é que o LocalCustomerLookupProvider é um serviço gerado, ele é um serviço wrapper thin ao redor de uma consulta do banco de dados, há uma única operação que representa um SQL select. Essa abordagem foi escolhida em acesso direto ao banco de dados pelo serviço de procura do cliente em loja, a fim de permitir que o serviço local inclua regras de negócios adicionais ou mesmo torne-se um serviço mais completo em alguma data posterior.

No entanto, esse diagrama mostra apenas a estrutura da colaboração, o diagrama de interação a seguir (UML 2.0 Sequence Diagram) representa as comunicações entre os serviços. Observe que a operação getCustomerByPhone foi incluída na especificação do serviço. Além disso, observe que o UML 2.0 permite a especificação de "fragmento" adicional de um diagrama de seqüência, nesse caso denotando que a comunicação com o serviço corporativo será feita, se a consulta local falhar.

O diagrama é descrito no conteúdo textual.

A combinação de diagramas de estrutura estática e de comunicação nos permite documentar a composição e a colaboração de serviços, e ter nesse caso, apenas identificada a necessidade de uma única operação a especificação do serviço.

Para obter informações adicionais, consulte a atividade Identificação de Serviço.

Design de Serviço Início da página

Considerando modelo da atividade de Identificação de Serviço, é feita a transição da identificação de um conjunto de serviços candidatos no design detalhado dos serviços projetados para construção. A primeira etapa é mapear as especificações de serviços qthat ue realizam as especificações acima; as you can imagine there are decisions to be made in how services realize the service specifications from the model above. Nesse exemplo, é apresentada uma estrutura razoavelmente simples,mas aquele que provavelmente será comum a muitos projetos. Nesse caso, é apresentado um único Fornecedor de Serviços mostrando um único serviço, o qual é a realização de uma única especificação. É certamente possível ter mais de um serviço por provedor. É preciso observar que alguns relacionamento de uso entre os serviços nesse modelo, essas dependências são importante no entendimento de como os serviços podem ser desenvolvidos ao longo do tempo.

O diagrama é descrito no conteúdo textual.

Essa estrutura permite agora se deslocar mais no espaço de distribuição, enquanto o modelo ainda é uma visualização lógica dos serviços, conforme os fornecedores de serviços representam as unidades de implementação para o modelo de serviço. Os fornecedores de serviços também são requeridos para a definição de serviços compostos como um próprio serviço (uma Porta UML 2.0) não consegue pertencer à estrutura requerida para descrever a composição.

Design de Mensagem

Nada foi dito anteriormente, na atividade de identificação de serviço, sobre as mensagens reais trocadas entre as operações descritas nas especificações de serviços. Essa pode ser uma abordagem totalmente comum, para capturar as responsabilidades dos serviços em termos de operações que adiam o design detalhado das mensagens até mais tarde - em alguns casos, essa abordagem é invertida, onde as estruturas de mensagens são conhecidas mais adiante e, em seguida, agregadas a um conjunto de operações.

Nesse caso, conseguiremos atuar sobre um modelo de domínio desenvolvido como parte do modelo de análise de componente (recurso anterior desenvolvido) e, assim, o modelo de mensagem não é construído do nada, mas identifica um subconjunto do modelo de domínio a ser reutilizado. O exemplo a seguir demonstra esse relacionamento, as classes de domínio são completamente tecnologia e plataforma inconsistente, por outro lado, supõe-se que sejam objetos de transferência de dados, estruturas transmitidas entre os serviços. Portanto, em vez de alterar o modelo de domínio, serão criadas mensagens no "lado de fora" da estrutura de classe, composta de elementos no interior.

O diagrama é descrito no conteúdo textual.

Para obter informações adicionais, consulte o conceito Design de Mensagem.

Realização de Serviço Início da página

Nesse caso, será focalizada a realização do serviço de consulta do cliente na loja; esse serviço é típico na transformação do modelo de serviço para o modelo de design. A própria transformação é documentada em uma diretriz e resulta na estrutura de modelo a seguir.

O diagrama é descrito no conteúdo textual.

Enquanto isso ainda é um modelo de design, é possível, utilizando as ferramentas, transformar esse modelo ainda mais tarde na implementação mostrada a seguir. Basicamente, essa implementação é transformada a partir da classe CustomerByPhone acima e as mensagens que detalham o cliente são transformadas no bean de entidade utilizado para consultar o banco de dados.

O diagrama é descrito no conteúdo textual.

Para obter informações adicionais, consulte a orientação De Serviços a Componentes de \ Serviço.