Camadas e camadas de SOAP

Question

Camadas e camadas de SOAP

#1 resposta do (2 votos)

5

Estou projetando o back-end para um serviço da web SOAP e tenho uma pergunta sobre como estou pensando em fazê-lo.

Eu vou com um design simples em camadas que consiste em 3 camadas separadas.

Layer 1 -> Layer 2 -> Layer 3

Camada 1: Implementará a interface do esqueleto SOAP, portanto, esse será o principal ponto de entrada do meu aplicativo. Essa camada extrairá dados da solicitação SOAP e a transmitirá para a camada de lógica de negócios como um objeto de negócios. Ele recuperará objetos de negócios da camada de lógica de negócios com a qual preencherá uma resposta SOAP.

Camada 2: Camada de lógica de negócios que implementa a lógica de negócios por trás do serviço da web. Serão passados dados da Camada 1 e interagirão com a Camada 3, a camada DAO.

Camada 3: camada DAO que executará as operações CRUD no meu banco de dados.

Com o preenchimento de objetos de resposta SOAP no meu código, a implementação pode ser um pouco confusa na Camada 1, então eu criei as 3 opções a seguir.

Opção 1 - Três camadas são suficientes, mais camadas seriam exageradas. Os objetos SOAP sempre terão uma aparência bagunçada, apenas superem isso.

Opção 2 - Crie uma camada extra entre as Camadas 1 e 2. Essa camada pegaria dados da solicitação SOAP, preencheria um objeto de negócios que passaria para a camada de lógica de negócios. Isso manteria os métodos da Camada 1 limpos e organizados. Seria algo parecido com isto:

Layer 1  ->  SOAP Request   ->  Layer 1.A  ->  Business Object  ->  Layer 2
Layer 1  <-  SOAP Response  <-  Layer 1.A  <-  Business Object  <-  Layer 2

Opção 3 - Não crie mais camadas. Basta criar um objeto de utilitário com um método que receba uma solicitação SOAP e retorne um objeto de negócios. Eu poderia passar o objeto de negócios para a Camada 2. O mesmo objeto de utilitário poderia ser usado na Camada 2 para passar uma resposta SOAP de volta para a Camada 1. Ou essa abordagem meio que embaça as linhas e torna meu design menos modular?

design design-patterns soap

por T-Pane 25.02.2014 / 16:49

fonte

1 resposta

Tags design design-patterns soap

Eu não sei como entender o tipo de caractere curinga em Java Banco de dados Ruby on Rails usando tabelas de pesquisa estática ou cadeias de caracteres constantes

score 2 · Answer 1

Depende do que você pode potencialmente compartilhar a camada 2 com. Se a maioria dos seus sistemas de back-end operar em objetos de negócios, faz muito mais sentido que os dados sejam convertidos em um objeto de negócios antes de passá-lo para seus outros sistemas. Tanto a conversão quanto a passagem simples funcionarão, mas, na ausência de requisitos estritos, eu sugeriria o que for mais conceitualmente local para seus sistemas atuais. Isso é principalmente por motivos de manutenção.

A inclusão de uma camada extra depende se você espera incluir várias operações / pontos de extremidade em uma única chamada. A camada extra separa a solicitação SOAP das operações, permitindo combinação flexível / correspondência e solicitação de despacho com base na identificação sem colocá-la na camada de serviço da web. Pode ser muito útil se você não puder tratar todas as solicitações da mesma forma, por qualquer motivo (fonte diferente, balanceamento de carga, etc.). Se você não espera nada disso, você deve estar preparado para o caso limitado por chamada e nix a camada extra.

Em ambos os casos, recomendo tornar o processo de transformação em um objeto de utilitário. Isso não "custa" muito, e eu acho / uso nosso front-end para o utilitário xml em todo o lugar. (Temos uma infinidade de formatos / canais front-end que aceitamos, mas consolidamos em um único formato xml para uso interno.)