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.
É 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.
Para obter informações adicionais, consulte o mentor de ferramenta Criando um Modelo de Serviço em RSA.
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.Nome | Tecnologia | Entradas | Saídas | Comentários |
---|---|---|---|---|
sp_get_custlist_by_phone | Procedimento Armazenado SQL Server | phonenum (char 10) | Lista de:
custid (id) |
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 |
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.
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.
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.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.
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.
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.
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.
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.
Para obter informações adicionais, consulte a orientação De Serviços a Componentes de \ Serviço.