O que é SOA “em inglês simples”? [fechadas]

Alguém pode explicar em inglês simples do que se trata SOA ? Eu ouço SOA aqui, SOA ali, mas não consigo entender exatamente o que é e para que é usado. Era um conceito simples e depois evoluiu para algo enorme ou o quê?

Todos os documentos, incluindo wiki, são um pouco abstratos ou talvez eu seja um idiota e não entendo. Existe um guia idiota sobre isso?

O que exatamente há por trás dessas três letras?

Você pode achar este artigo (O que é SOA? - SOA e serviços da Web explicados) útil.

Um pequeno teaser:

• SOA é um estilo de arquitetar aplicativos de forma que sejam compostos de agentes de software discretos que possuem interfaces simples e bem definidas e são orquestrados por meio de um acoplamento flexível para executar uma função necessária.

• Existem 2 funções em SOA - um provedor de serviços e um consumidor de serviços. Um agente de software pode desempenhar ambas as funções. SOA não é um conceito totalmente novo - no entanto, este artigo se concentra principalmente em SOA implementado com serviços da web.

SOA é um novo emblema para algumas ideias muito antigas:

• Divida seu código em módulos reutilizáveis.

• Encapsule em um módulo qualquer decisão de projeto que possa mudar.

• Projete seus módulos de forma que possam ser combinados de diferentes maneiras úteis (às vezes chamados de "família" ou "linha de produtos").

Todos esses são princípios básicos de desenvolvimento de software, muitos deles articulados pela primeira vez por David Parnas.

O que há de novo em SOA é

• Você está fazendo isso em uma rede.

• Os módulos se comunicam enviando mensagens entre si pela rede, em vez de por mecanismos de linguagem de programação mais tradicionais, como chamadas de procedimento. Em particular, em uma arquitetura orientada a serviços, as partes geralmente não compartilham o estado mutável (variáveis ​​globais em um programa tradicional). Ou se eles compartilham o estado, esse estado é cuidadosamente bloqueado em um banco de dados que é um agente e que pode gerenciar facilmente vários clientes simultâneos.

Vejo muitas respostas explicando uma Arquitetura Orientada a Serviços (SOA) usando palavras e termos técnicos ainda mais avançados. Eu gostaria de explicar isso para o leigo, usando uma analogia em inglês simples.

Mas, primeiro, uma descrição de um SOA
SOA poderia ser descrita em três camadas, conforme mostrado na imagem abaixo. De um lado temos o Provedor e do outro temos o Consumidor , separados por uma Ponte onde os dois lados se comunicam.

O consumidor usa uma série de Aplicativos necessários para seus negócios e o provedor usa Componentes que fornecem informações a esses aplicativos. Eles se comunicam por meio de um conjunto de serviços usando uma arquitetura comum.

A analogia
Imagine uma casa no campo, que em muitos aspectos faz parte de uma comunidade maior, como uma cidade ou vila. A cidade possui seus próprios sistemas complexos de fornecimento de água e eletricidade, tratamento de saneamento, transporte e outras utilidades. A Casa é a consumidora neste modelo, a Cidade (ou comunidade) é a provedora e os encanamentos, esgotos, linhas de alta tensão, fibras óticas etc. é a Infraestrutura na qual se comunicam.

Este modelo pode ser vagamente comparado a um SOA. As pessoas da casa usam uma série de "aplicações" diferentes como radiadores, computadores, banheiros, lâmpadas, piso aquecido, banheiras, etc. Essas aplicações não se importam como a cidade gera a água, cria a eletricidade ou lida com o lixo enquanto como funciona. Os componentes da cidade são geradores, bombas d'água e áreas de saneamento. Ele fornece à casa todas essas necessidades, mas cabe à casa usá-lo da maneira que achar melhor.

Espero que isso tenha dado a pelo menos alguém uma imagem melhor de SOA.

Vamos supor que você tenha quatro cozinheiros. Em SOA, você presume que eles se odeiam, então se esforça para que eles falem o menos possível.

Como você faz isso? Bem, primeiro você definirá os papéis e a interface - o cozinheiro 1 fará a salada, o cozinheiro 2 fará a sopa, o cozinheiro 3 fará o bife, etc. Em seguida, você colocará os pratos bem organizados na mesa (então estes são os interfaces) e diga: "Todos, por favor, coloquem sua criação em seus pratos atribuídos. Não se importem com mais ninguém.".

Dessa forma, os quatro cozinheiros têm que conversar o menos possível, o que é muito bom no desenvolvimento de software - não necessariamente por se odiarem, mas por outros motivos como localização física, eficiência na tomada de decisões etc.

Isso também significa que você pode recombinar os pratos (serviços) como quiser. Por exemplo, você pode apenas usar a sobremesa para servir um café, ou apenas pegar a sopa e combiná-la com um pão que você comprou de outra empresa para fornecer um menu mais barato, ou permitir que outros restaurantes usem suas saladas para combinar com seus pratos, etc. .

Uma das implementações mais bem-sucedidas de SOA foi na Amazon. Por causa de seu design, eles puderam reempacotar toda a sua infraestrutura e vendê-la como Amazon Web Service.

* Este é apenas um aspecto do SOA.

SOA é um estilo de arquitetura, mas também uma visão de como aplicativos heterogêneos devem ser desenvolvidos e integrados. O objetivo principal do SOA é deixar de lado os aplicativos monolíticos e ter, em vez disso, um conjunto de serviços reutilizáveis que podem ser compostos para construir aplicativos.

IMHO, SOA faz sentido apenas no nível empresarial e não significa nada para um único aplicativo.

Em muitas empresas, cada departamento tinha seu próprio conjunto de aplicativos empresariais, o que implicava

1. Recurso semelhante foi implementado várias vezes

2. Os dados (por exemplo, dados de clientes ou funcionários) precisam ser compartilhados entre vários aplicativos

3. As inscrições eram centradas no departamento.

Com SOA, a ideia é que os serviços reutilizáveis ​​sejam disponibilizados em toda a empresa, para que a aplicação possa ser construída e composta a partir deles. A promessa de SOA é

1. Não há necessidade de reimplementar recursos semelhantes repetidamente (por exemplo, fornecer um serviço ao cliente ou funcionário)

2. Facilita a integração de aplicativos e o acesso a dados ou recursos comuns

3. Esforço de desenvolvimento centrado na empresa.

A visão SOA requer uma mudança tecnológica , bem como uma mudança organizacional . Embora resolva alguns problemas, também introduz outros, por exemplo, a segurança é muito mais difícil com SOA do que com a aplicação monolítica. Portanto, SOA está sujeito a discussão sobre se funciona ou não.

Esta é a visão de 1000 pés de SOA. No entanto, não para por aqui. Existem outros conceitos que complementam a SOA, como orquestração de processos de negócios (BPM), barramento de serviço corporativo (ESB), processamento de eventos complexos (CEP), etc. Todos eles abordam o problema de alinhamento de TI / negócios , ou seja, como ter a TI ser capaz de apoiar o negócio de forma eficaz.

SOA é a sigla para Service Oriented Architecture.

SOA está projetando e escrevendo aplicativos de software de tal forma que módulos de software distintos podem ser integrados perfeitamente com alto grau de reutilização.

A maioria das pessoas restringe SOA ao escrever serviços da Web de software cliente / servidor. Mas é um contexto muito pequeno de SOA. SOA é muito maior do que isso e nos últimos anos os serviços da web têm sido o meio principal de comunicação, o que é provavelmente a razão pela qual as pessoas pensam em SOA como serviços da web em geral que restringem os limites e o significado de SOA.

Você pode pensar em escrever um módulo de acesso ao banco de dados que seja tão independente que possa funcionar por conta própria sem quaisquer dependências. Este módulo pode expor classes que podem ser usadas por qualquer software host que precise de acesso ao banco de dados. Não há configuração de inicialização no aplicativo host. O que quer que seja necessário ou exigido é comunicado por meio de exposições de classes por módulo de acesso ao banco de dados. Podemos chamar essas classes de serviços e considerar o módulo como habilitado para serviços.

Praticar SOA oferece alto grau de reutilização ao impor o DRY [Não se repita], o que resulta em um software de alta manutenção. A capacidade de manutenção é a primeira coisa em que qualquer arquitetura de software pensa - SOA oferece isso.

Pelo que eu entendi, o conceito básico é que você cria pequenos "serviços" que fornecem algo útil para outros sistemas e evita construir grandes sistemas que tendem a fazer tudo dentro do sistema.

Portanto, você define um protocolo que usará para interação (digamos, pode ser serviços da web SOAP) e permite que seu "sistema que faz algum negócio" interaja com os pequenos serviços para atingir seu "grande objetivo" .

Eu sugiro que você leia os artigos de Thomas Erl e Roger Sessions. Isso lhe dará uma ideia firme do que é SOA. Esses também são bons recursos, veja o SOA explicado para seu chefe, um para uma explicação leiga

Construindo um SOA

Padrão de Design SOA

Alcançando integridade em um SOA

Por que seu SOA deve ser como um fusca

SOA explicado para seu chefe

Desempenho do serviço WCF

o que tende a acontecer em grandes organizações é que, com o tempo, tudo se torna monolítico ou sistemas díspares em todos os lugares ou um pouco de ambos. Alguém finalmente chega e diz que estamos bagunçados. Agora, você quer redesenhar (dinheiro para alguém) tudo para ser orientado em uma espécie de paradigma monotlítico, depende de quem você paga paradigma, mas ao mesmo tempo ser capaz de adicionar peças e peças independentemente do mestre / monólito.

Então você compra o SOA da Oracle e a Oracle se torna o chefe de todas as suas partes. Todos os outros participantes precisam trabalhar com SOA por meio de um serviço (serviço da Web ou o que quer que ele tenha). O monólito Oracle cuida de tudo (monolito não significa depreciativo). Sim, você tem ASP.NET MVC na frente ou algo mais.

o principal é mover as coisas para dentro e para fora do sistema sem impacto e manter o fornecedor Oracle SOA, Microsoft WCF, como o cérebro de tudo. tudo é tudo oop / ood like, fluido, coisas entrando e saindo com pouco ou nenhum impacto, até mesmo serviços humanos, não apenas computadores.

Para mim, significa apenas um monte de serviços da web (ou como vamos chamá-los no futuro) com um bom front-end. E se você possui o banco de dados, basta acessar o banco de dados e parar de se preocupar com as palavras da moda. está bem.

Apenas uma sugestão: -

Leia Conceitos, tecnologia e design de SOA por Thomas Erl.

Ele forneceu detalhes sobre SOA em um inglês simples e com estudos de caso de maneira muito bonita.

Bem, você vê ... SOA significa Arquitetura Orientada a Serviços ... Em palavras mais simples, você escreve um pedaço de código que é muito genérico, ou seja, ele faz algo que pode ser usado em muitos aplicativos ... pode ser algo como um catálogo de endereços ou pode ser uma calculadora. e você inicia este código no IIS. Então você fornece um serviço por meio do seu código. Então você é um provedor de serviços. Agora, alguém deseja usar um código semelhante e não precisa escrever o código novamente. Ele simplesmente usa seu código, talvez por meio de um serviço da web. Portanto, ele se torna um consumidor de serviço. Portanto, fazer um programa usando esses serviços é chamado de SOA. E o acoplamento fraco existe, já que o provedor de serviços e o consumidor podem interagir, mesmo que estejam usando linguagens de programação diff. Eu espero que você entenda.

de blogs ittoolbox.

O seguinte descreve as semelhanças e diferenças com as técnicas de design anteriores:

• SOA versus programação estruturada o Semelhanças: mais semelhantes a chamadas de sub-rotina onde parâmetros são passados ​​e a operação da função é abstraída do chamador - por exemplo, link e execução do CICS e a palavra reservada COBOL CALL. Os copybooks são usados ​​para definir a estrutura de dados que normalmente é definida como um esquema XML para serviços. o Diferenças: SOA é fracamente acoplado, o que significa que as alterações em um serviço têm menos impacto para o consumidor (o programa de "chamada") e os serviços são interoperáveis ​​entre linguagens e plataformas.

• SOA versus OOA / OOD o Semelhanças: Encapsulamento, Abstração e Interfaces Definidas o Diferenças: SOA é fracamente acoplado sem hierarquia de classe ou herança, abstrações de baixo nível - nível de classe versus serviço de negócios

• SOA versus desenvolvimento baseado em componentes (CBD) legado - por exemplo, CORBA, DCOM, EJB o Semelhanças: Reutilização por meio da montagem de componentes, interfaces, chamadas remotas o Diferenças: ampla adoção de padrões, Esquemas XML versus objetos empacotados, Orquestração de serviço, Design para reutilização é mais fácil, os serviços são focados nos negócios vs. focados em TI, os serviços empresariais são granulados (amplo em escopo)

• SOA (para integração) versus Enterprise Application Integration (EAI) o Semelhanças: Melhores práticas (interfaces bem definidas, esquemas padronizados, arquitetura orientada a eventos), interfaces reutilizáveis, esquemas comuns o Diferenças: Padrões, adoção e ferramentas aprimoradas

Lendo as respostas acima, parece-me que SOA é o que os desenvolvedores (bons, pelo menos) têm feito desde o primeiro dia.

Também pode significar "Struct of Arrays" (em oposição a "Array of Structs"), que é um tópico comum na programação paralela (especialmente SIMD), mas acho que não é isso que você quer dizer aqui!

SOA é uma palavra da moda que foi inventada por fornecedores de tecnologia para ajudar a vender suas tecnologias relacionadas ao Enterprise Service Bus. A ideia é que você torne seus pequenos aplicativos insulares na empresa (por exemplo: sistema de contabilidade, sistema de controle de estoque, etc) todos os serviços expostos, de modo que possam ser orquestrados de forma flexível em "aplicativos", ou melhor, se tornarem partes de negócios agregados com escopo empresarial lógica.

Basicamente, uma carga de besteiras que quase nunca funciona, porque perde o ponto de que as razões pelas quais a tecnologia é do jeito que é em uma organização se devem à cultura, evolução, história da empresa, e o aprisionamento é tão alto que qualquer tentativa de reestruturar a tecnologia está fadada ao fracasso.

Ouça a edição desta semana do podcast Floss Weekly , que cobre SOA. As descrições são de alto nível e não se aprofundam em muitos detalhes técnicos (embora exemplos mais concretos e reconhecíveis de projetos SOA teriam sido úteis.

Uma arquitetura de aplicativo tradicional é:

• Uma interface de usuário
• Coisas indefinidas (implementação) que estão encapsuladas / escondidas atrás da interface do usuário

Se você deseja acessar os dados de forma programática, pode ser necessário recorrer à captura de tela.

SOA me parece ser uma arquitetura que se concentra em expor dados legíveis por máquina e / ou APIs, em vez de expor UIs.

SOA ou Arquitetura Orientada a Serviços é um padrão de arquitetura de software em que aplicativos ou sistemas são construídos a partir de serviços de software subjacentes (e geralmente distribuídos) que estão em conformidade com um conjunto específico de características, a saber:

1. Interface, política e contrato com base
2. Transparência de localização
3. Autônomo
4. Resumo
5. Reutilizável
6. Composable
7. Sem estado
8. Detectável
9. Extensível
10. Fracamente acoplada

O principal objetivo da SOA é a agilidade de desenvolvimento de software, ou seja, a capacidade de responder às mudanças com facilidade e baixo custo, permitindo assim que as empresas respondam rapidamente aos mercados em constante mudança.

Os serviços são tipicamente (mas de forma alguma exclusivamente) implementados como serviços da web, ou seja, operam sobre o onipresente protocolo HTTP da web e são implementados usando SOAP baseado em XML ou o paradigma REST leve (e mais popular).

Depende de quem você é!

Se você é proprietário de uma empresa, SOA é uma solução para aumentar sua receita e agilidade de negócios. Se você é um arquiteto empresarial, SOA é uma maneira de desenhar um software limpo e agradável em uma tela em branco. Se você é um arquiteto, SOA é a solução para projetar serviços fracamente acoplados em uma plataforma de integração, para simplesmente conectar os serviços nas tomadas. Se você for um desenvolvedor, SOA é um paradigma de programação em que um serviço está no centro do design e do código.

Você deve ler 100-SOA-Questions [pdf]

Felicidades

Arquitetura Orientada a Serviços (SOA) é um estilo de arquitetura de software que cria aplicativos como uma coleção de partes conectáveis, cada uma das quais pode ser reutilizada por outros aplicativos.