Um SOA pode ser projetado com descanso?

Tenho lido muito sobre SOA ultimamente, mas a maior parte do conteúdo está relacionado com sabão e tem muitas coisas "burocráticas" que pertencem aos sistemas C#/Java. Honestamente, acho que tanta burocracia, especialmente sabão, é uma chatice. Então, estou curioso, uma SOA pode ser desenhada com descanso?

Neste momento, nas aplicações da Ruby, deixo todos os meus controladores descansados. Minha interface web (formulários, etc) faz pedidos de GET/POST/PUT/DELETE para o núcleo, que é um webservice REST. Todos os outros os sistemas que usam o núcleo fazem pedidos RESTful a ele. Isto é um SOA?

Author: vinnylinux, 2012-05-08
Source

3 answers

A um nível elevado, a resposta é sim, mas não completamente.

SOA requer pensar sobre o sistema em termos de

  • Serviços (funcionalidade empresarial bem definida)
  • Componentes (elementos discretos de código e/ou estruturas de dados)
    • Processos (orquestrações de Serviços. Geralmente utilizando BPEL)
Ser capaz de compor novos serviços de nível superior ou processos de negócios é uma característica básica de uma boa SOA. Serviços web baseados em XML e SOAP e relacionados os padrões são adequados para realizar SOA.

Também a SOA tem alguns princípios aceites - http://en.wikipedia.org/wiki/Service-oriented_architecture#Principles

  • contratos de serviços normalizados – os serviços cumprem um acordo de comunicações, tal como definido colectivamente por um ou mais documentos de descrição de serviços.
    • Os Serviços de Acoplamento frouxos de serviço mantêm uma relação que minimiza as dependências e só exige que mantenham a consciência de cada um deles. restante. Abstracção de serviços-para além das descrições do contrato de Serviços, os Serviços escondem a lógica do mundo exterior. [[6]] a lógica de reutilização de Serviços é dividida em serviços com a intenção de promover a reutilização. Autonomia dos Serviços-os Serviços têm controlo sobre a lógica que encapsulam. [[6]] granularidade de serviço-uma consideração de design para fornecer o âmbito ideal e nível granular direito da funcionalidade de negócio em uma operação de serviço.
  • Serviço apátridas-os Serviços minimizam o consumo de recursos adiando a gestão da Informação do estado quando necessário
    • Os Serviços de descoberta de Serviços são complementados com meta-dados comunicativos através dos quais podem ser efectivamente descobertos e interpretados.
  • a compostabilidade dos Serviços – os Serviços são participantes efectivos na composição, independentemente da dimensão e da complexidade da composição.

Espera-se que uma arquitectura baseada em SOA tenha definição de Serviço. Uma vez que os RESTful web services não possuem uma definição definitiva de serviço (semelhante ao wsdl), é difícil para um sistema baseado em repouso cumprir a maioria dos princípios acima.

Para conseguir o mesmo usando o descanso, você precisa ter Serviços Web RESTful + orquestração (possível usando algum ESB leve como MuleESB ou camelo) {[[2]}

Por favor Veja Também este recurso - De SOA a repouso

Adicionando esta parte como esclarecimento para o comentário abaixo -

A orquestração é ... necessário para compor processos. É isso que proporciona o principal benefício da SOA.

Diga que tem uma aplicação de processamento de pedidos com operações como -

  • addItem
  • addTax
  • cálculo total
  • placeOrder

Inicialmente criou um processo (usando BPEL) que usa estas operações em sequência. Você tem clientes que usam este serviço composto. Depois de alguns meses um novo cliente vem que tem isenção fiscal, em seguida, em vez de escrever um novo serviço, você poderia apenas criar um novo processo faltando a operação addTax. Assim, você poderia alcançar uma realização mais rápida da funcionalidade de Negócio apenas reutilizando o serviço existente. Na prática, existem vários serviços deste tipo.

Assim, a tecnologia BPEL ou similar (ESB ou encaminhamento) é essencial para a SOA. Sem uso comercial, uma SOA não é realmente uma SOA.

Cross postado no meu blog pessoal - http://blog.padmarag.com

Verifique também este novo recurso que encontrei - descanso base de dados SOA

 23
Author: Padmarag, 2012-06-02 07:18:57

O serviço em termos de SOA é uma componente que resolve um certo problema de Negócio. SOAP/WCF estão mais relacionados com a interface / parte de entrega da SOA. A abordagem de descanso também pode ser usada. O contrato de serviços, as políticas, a versão e outros recursos de SOA "standard" também podem ser implementados com serviço de repouso.

O principal problema reside no facto de ser um alvo difícil, pelo que não seria a melhor escolha para uma implementação lógica complexa. Mas se a sua lógica de negócio é completamente CRUD (ou converge para CRUD), então deve ficar tudo bem.

[[1] Btw, parece que a Microsoft adicionou operações aos Serviços de dados WCF especialmente para emular sabão com descanso.
 6
Author: mikalai, 2012-05-08 07:36:33

A coisa mais importante sobre SOA são os fatores suaves, por exemplo, fazer com que outras pessoas usem os seus serviços e visa-versa para esse fim ter um link wsdl a partir do qual você pode construir um proxy fácil de usar é quase essencial. Os serviços têm de ser compostáveis .. mas você não precisa de orquestração , BPEL ou um ônibus chique para fazer isso e eu não recomendo quando você começa com SOA. ( na verdade, tendo usado estes eu acho que você pode obter melhores resultados sem eles, mas você precisa de eventos )

Nota produtos como o WCF permitem-lhe criar um serviço que expõe um wsdl , mas para além do SOAP pode também usar o REST/Json ou pontos de fim TCP binários ainda melhores .. Isto é ideal uma vez que você usa sabão para a simplicidade e mudar para binário ( que sopra o descanso fora da água) quando você precisa.

No que diz respeito ao sabão em 8 anos de construção de sistemas de alta performance SOA com WCF, nunca reparei que o sabão estava lá.. isso é porque eu trabalho principalmente em C# e temos um bom sabonete pilho .. a maioria das outras línguas não.
 2
Author: user1496062, 2013-07-09 10:19:15