Most! by wikipedia!

Service-Oriented Architecture (SOA), pode ser traduzido como arquitetura orientada a serviços, e é um estilo de arquitetura de software cujo princípio fundamental prega que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços.[1][2] Frequentemente estes serviços são conectados através de um "barramento de serviços" (enterprise service bus, em inglês) que disponibiliza interfaces, ou contratos, acessíveis através de web services ou outra forma de comunicação entre aplicações.[2][3][4] A arquitetura SOA é baseada nos princípios da computação distribuída e utiliza o paradigma request/reply para estabelecer a comunicação entre os sistemas clientes e os sistemas que implementam os serviços.[5]
Além da perspectiva estritamente técnica, a arquitetura orientada a serviços também se relaciona com determinadas políticas e conjuntos de "boas práticas" que pretendem criar um processo para facilitar a tarefa de encontrar, definir e gerenciar os serviços disponibilizados.[6][7]
A arquitetura orientada a serviços também se insere em um processo de reorganização dos departamentos de tecnologia da informação das organizações, permitindo um melhor relacionamento entre as áreas que dão suporte tecnológico à empresa e as áreas responsáveis pelo negócio propriamente dito, graças a maior agilidade na implementação de novos serviços e reutilização dos ativos existentes.[8][9]


Cquote1.svg
Cquote1.svg

SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio
interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas.
Cquote2.svg
Cquote2.svg

Gartner Group

Introdução

As implementações SOA dependem de uma rede de serviços de software. Serviços incluem baixo acoplamento de unidades e de funcionalidade. Cada serviço implementa uma ação, como preencher um requerimento on-line para uma conta ou visualizar um banco on-line de instrução, ou colocar uma reserva on-line ou para bilhete de avião. Em vez de serviços de chamadas para encaixar uns aos outros em seu código fonte que eles usam protocolos definidos que descrevem como os serviços de análise e passar mensagens, utilizando metadados descrição.
Desenvolvedor SOA associa objetos individuais usando orquestração. No processo de orquestração que o desenvolvedor associa funcionalidade de software (serviços) em um arranjo não-hierárquica usando uma ferramenta de software que contém uma lista completa de todos os serviços disponíveis, suas características e os meios para criar uma aplicação utilizando essas fontes.
Subjacente e que permite tudo isso requer metadados em detalhes suficientes para descrever não só as características desses serviços, mas também os dados que os impulsiona. Programadores fizeram amplo uso de XML em SOA para estrutura de dados que envolvem quase que em uma exaustiva descrição de contêiner. Analogamente, os Web Services Description Language (WSDL) normalmente descreve os próprios serviços, enquanto o protocolo SOAP descreve os protocolos de comunicação. Se estas linguagens de descrição são as melhores possíveis para o trabalho, e se tornará / permanecem os favoritos no futuro, permanecem questões abertas. A partir de 2008 [update] SOA depende dos dados e serviços que são descritos por metadados que devem satisfazer os seguintes critérios:
1. Os metadados devem vir de uma forma que os sistemas de software pode usar para configurar dinamicamente a descoberta e a incorporação de serviços definidos, e também para manter a coerência e integridade. Por exemplo, os metadados podem ser utilizados por outros aplicativos, como um catálogo, para executar serviços de autodescoberta, sem modificar o contrato de um serviço funcional.
2. Os metadados devem vir de uma forma que os designers de sistema capaz de compreender e gerir com um gasto razoável de custo e esforço.
Para isto funcionar, não deve existir interações entre os pedaços dentro do especificado, ou pedaços de si. Em vez disso, os seres humanos especificar a interação dos serviços (todos eles pares não associados) em uma forma relativamente ad hoc com a intenção impulsionado por exigências de recém-emergente. Assim, a necessidade de serviços como unidades de maior funcionalidade do que as funções tradicionais ou classes, para que a enorme complexidade de milhares de tais objetos granulares sobrecarregar o designer de aplicativo. Os programadores desenvolvem os próprios serviços usando linguagens tradicionais como Java, C, C + +, C # ou COBOL.
A partir de 2008, um número crescente de empresas de software de terceiros oferecem serviços de software para uma taxa. No futuro, sistemas SOA pode consistir de tais serviços de terceiros combinado com outros criados em casa. Este tem o potencial de repartir os custos sobre os clientes e usa muitos dos clientes e promove a normalização, tanto dentro como através das indústrias. Em particular, a indústria do turismo tem agora um bem-definidas e documentadas conjunto de ambos os serviços e dados, suficiente para permitir que qualquer engenheiro de software razoavelmente competente para criar software de agência de viagens que utilizam os serviços totalmente off-the-shelf software.
Outras indústrias, como a indústria financeira, também começaram a fazer progressos significativos nesse sentido.
SOA como uma arquitetura depende de orientação a serviços como o seu princípio fundamental de design. Se um serviço apresenta uma interface simples que abstrai a complexidade subjacente, os usuários podem acessar os serviços independentes, sem conhecimento da execução do serviço de plataforma.
SOA se baseia em serviços expondo suas funcionalidades através de interfaces que outros aplicativos e serviços pode ler para entender como utilizar esses serviços.

Requisitos

A fim de utilizar eficientemente uma SOA, deve-se atender aos seguintes requisitos:
A interoperabilidade entre diferentes sistemas e linguagens de programação fornece a base para a integração entre aplicações em diferentes plataformas, através de um protocolo de comunicação. Um exemplo dessa comunicação depende do conceito de mensagens. Usando mensagens, através de canais de mensagens definidos, diminui a complexidade da aplicação final, permitindo que o desenvolvedor do aplicativo se concentre na funcionalidade do aplicativo de verdade, em vez das necessidades intrincadas de um protocolo de comunicação. O desejo é o de criar um conjunto de recursos a ser compartilhado, bem como estabelecer e manter o fluxo de dados para um sistema de banco de dados compartilhado. Isto permite que novas funcionalidades desenvolvidas para um formato de negócio de referência comum para cada elemento de dados.

Abordagem Serviços Web

Serviços Web podem implementar uma arquitetura orientada a serviços. Serviços Web fazem blocos funcionais de construção acessíveis através de protocolos de Internet padrão independente de plataformas e linguagens de programação. Estes serviços podem representar tanto novas aplicações quanto apenas invólucros em torno dos sistemas legados existentes para torná-los em rede ativada.
Cada bloco de construção SOA pode desempenhar um ou ambos os papéis:
Service Provider - O prestador de serviços cria um serviço Web e, eventualmente, publica sua interface e acesso a informação para o registro de serviços. Cada fornecedor deve decidir quais os serviços irá expor, como fazer trade-offs entre a segurança e a facilidade de acesso, como preço dos serviços, ou (se nenhuma taxa extra), como e se a explorá-los para outro valor. O provedor também tem que decidir em qual categoria os serviços devem ser listados em um dado serviço de broker e que tipo de acordos com parceiros comerciais são obrigados a usar o serviço. Ele registra que os serviços estão disponíveis dentro dele, e as listas de todos os beneficiários potenciais do serviço. O implementador do corretor, então, decide o âmbito do corretor. Corretores públicos estão disponíveis através da Internet, enquanto intermediários privados só são acessíveis a um público limitado, por exemplo, os usuários de uma intranet da empresa. Além disso, a quantidade de informações oferecidas tem de ser decidido. Alguns corretores especializados em muitas listas. Outros oferecem altos níveis de confiança nos serviços listados. Algumas cobrem um amplo panorama de serviços e outros, o foco dentro de uma indústria. Alguns corretores catálogam outros. Dependendo do modelo de negócio, os corretores podem tentar maximizar o look-up dos pedidos, o número de anúncios ou exatidão dos anúncios. O Universal Description Discovery and Integration (UDDI) define uma maneira de publicar e descobrir informações sobre os serviços da Web. Outros serviços incluem (por exemplo) ebXML (Electronic Business utilizando eXtensible Markup Language) e aqueles baseados na ISO / IEC 11179 Metadata Registry (MDR) padrão.
Atendimento ao consumidor - O consumidor de serviços ou cliente do serviço web localiza entradas no registro do corretor para encontrar as operações e, em seguida, liga-se ao prestador do serviço para invocar um de seus serviços de web. Seja qual for o serviço a serviço, os consumidores precisam, eles têm que levá-la para o corretor, em seguida, vinculá-lo com o respectivo serviço e usá-lo. Eles podem acessar vários serviços, se o serviço oferece vários serviços.

Acoplamento

É o nível de interdependência entre os módulos de um sistema. Por outro lado, um módulo é considerado coeso quando possui uma atividade bem definida. Diferentemente do que as pessoas pensam, SOA não se trata de uma simples invenção. A arquitetura orientada a serviços nada mais é que a evolução natural da arquitetura de sistemas tradicional para solucionar as necessidades de desenvolvimento e capacidade de adaptação às novas demandas de mercado, que se faz cada vez mais exigente em qualidade e agilidade.

Serviço

Um serviço, do ponto de vista da arquitetura SOA, é uma função de um sistema computacional que é disponibilizado para outro sistema. Um serviço deve funcionar de forma independente do estado de outros serviços, exceto nos casos de serviços compostos (composite services), e deve possuir uma interface bem definida. Normalmente, a comunicação entre o sistema cliente e aquele que disponibiliza o serviço é realizada através de web services.

Web service é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Os Web services são componentes que permitem às aplicações enviar e receber dados em formato XML. Cada aplicação pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, o formato XML.

Processos

Cquote1.svg
Cquote1.svg

Mais do que uma tecnologia, SOA também influencia regras e processos de negócios,
além de muitas vezes implicar reengenharia de software simultaneamente.
Cquote2.svg
Cquote2.svg

Gartner Group
A Arquitetura Orientada a Serviços pode ser bem representada a partir do seguinte processo, chamado de "find-bind-execute paradigm" o que significa aproximadamente paradigma de "procura-consolida-executa". Tal conceito é análogo a "Ciclo de Deming" aplicado aos serviços, que define o ciclo que envolve o planejamento, a execução, o monitoramento e a tomada de ação pró ativa para a melhoria da qualidade.
external image 350px-Find-bind-execute-pt.PNGexternal image magnify-clip.pngEsquema adaptado do paradigma "find-bind-execute"
Tecnicamente falando, o processo preconiza que os provedores de serviços registrem informações em um registro central, com suas características, indicadores, e aspectos relevantes às tomadas de decisões. O registro é utilizado pelo cliente para determinar as características dos serviços necessários, e se o mesmo estiver disponível no registro central, como por exemplo por um catálogo de serviços, o cliente poderá utilizá-lo, sendo este oficializado através de um contrato que enderece este serviço.

Tecnologia

O termo "Service-Oriented Architecture" (SOA) ou Arquitetura Orientada a Serviços expressa um conceito no qual aplicativos ou rotinas são disponibilizadas como serviços em uma rede de computadores (Internet ou Intranets) de forma independente e se comunicando através de padrões abertos. A maior parte das implementações de SOA se utilizam de Web services (SOAP , REST e WSDL). Entretanto, uma implementação de SOA pode se utilizar de qualquer tecnologia padronizada baseada em web.

Para a representação e estruturação dos dados nas mensagens recebidas/enviadas é utilizado o XML (eXtensible Markup Language). As chamadas às operações, incluindo os parâmetros de entrada/saída, são codificadas no protocolo SOAP (Simple Object Access Protocol, baseado em XML). Os serviços (operações, mensagens, parâmetros, etc.) são descritos usando a linguagem WSDL (Web Services Description Language). O processo de publicação/pesquisa/descoberta de Web Services utiliza o protocolo UDDI (Universal Description, Discovery and Integration).

XML

Extensible Markup Language (XML) é a base em que os Web Services são construídos. O XML fornece a descrição, o armazenamento, o formato da transmissão para trocar os dados através dos Web Services e também para criar tecnologias Web Services para a troca dos dados.
A sintaxe de XML usada nas tecnologias dos Web Services especifica como os dados são representados genericamente, define como e com que qualidades de serviço os dados são transmitidos, pormenoriza como os serviços são publicados e descobertos. Os Web Services decodificam as várias partes de XML para interagir com as várias aplicações.

Soap

O SOAP (Simple Object Access Protocol) baseia-se numa invocação remota de um método e para tal necessita especificar o endereço do componente, o nome do método e os argumentos para esse método. Estes dados são formatados em XML com determinadas regras e enviados normalmente por HTTP para esse componente. Não define ou impõe qualquer semântica, quer seja o modelo de programação, quer seja a semântica específica da implementação. Este aspecto é extremamente importante, pois permite que quer o serviço, quer o cliente que invoca o serviço sejam aplicações desenvolvidas sobre diferentes linguagens de programação. Por esta razão, o SOAP tornou-se uma norma aceita para se utilizar com Web Services, uma tecnologia construída com base em XML e HTTP. Desta forma, pretende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, através da utilização da linguagem XML e do mecanismo de transporte HTTP ou outro como, por exemplo, SMTP. O SOAP permite que os documentos XML de envio e de recepção sobre a Web suportem um protocolo comum de transferência de dados para uma comunicação de rede eficaz, ou seja, o SOAP providencia o transporte de dados para os Web Services.
Em relação a Web, o SOAP é um protocolo de RPC que funciona sobre HTTP (ou SMTP, ou outro) de forma a ultrapassar as restrições de segurança/firewalls normalmente impostas aos sistemas clássicos de RPC (RMI, DCOM, CORBA/IIOP) suportando mensagens XML. Em vez de usar HTTP para pedir uma página HTML para ser visualizada num browser, o SOAP envia uma mensagem de XML através do pedido HTTP e recebe uma resposta, se existir, através da resposta do HTTP. Para assegurar correctamente a transmissão da mensagem de XML, o servidor de HTTP, tais como Apache ou IIS (Microsoft Internet Information Server), recebe mensagens SOAP e deve validar e compreender o formato do documento XML definido na especificação SOAP v1.1.

Wsdl

É a sigla de Web Services Description Language, padrão baseado em XML para descrever o serviço como no COM, onde ele traz os métodos do Web Service. Funciona como uma espécie de "TypeLibrary" do Web Service, além de ser usado para a validação das chamadas dos métodos.
O WSDL (Web Services Description Language) é uma especificação desenvolvida pelo W3C que permite descrever os Web Services segundo um formato XML.
O WSDL é extensível para permitir a descrição dos serviços e suas mensagens, independentemente dos formatos de mensagem e dos protocolos de rede que sejam usados. No entanto, é comum usar-se o MIME (Multipurpose Internet Mail Extensions) e o HTtp://SOAP.
O WSDL descreve os serviços disponibilizados à rede através de uma semântica XML, este providencia a documentação necessária para se chamar um sistema distribuído e o procedimento necessário para que esta comunicação se estabeleça. Enquanto que o SOAP especifica a comunicação entre um cliente e um servidor, o WSDL descreve os serviços oferecidos.

Uddi

Protocolo desenvolvido para a organização e registro de Web Services.
O UDDI (Universal Description Discovery and Integration) é uma iniciativa em desenvolvimento no âmbito do consórcio industrial UDDI promovido originalmente pela IBM, Microsoft e Arriba, com objectivo de acelerar a interoperabilidade e utilização dos Web Services, pela proposta de um serviço de registo de nomes de organizações e de descrição do serviço.
Um registro UDDI contém três tipos de informação:
  • informações gerais de cada organização, tais como o nome, morada, telefone e contactos;
  • informações de organizações e serviços por categorias de negócios;
  • informações técnicas sobre os serviços providenciados pelas organizações.
O UDDI providencia três funções principais, conhecidas como publicação, descoberta e ligação:
1) publicação: permite que uma organização divulgue o(s) seu(s) serviço(s); 2) descoberta: permite que o cliente do serviço, procure e encontre um determinado serviço; 3) ligação (bind): permite que o cliente do serviço, possa estabelecer a ligação e interagir com o serviço.


Definições de SOA

O SOA coloca a prestação de serviço como eixo de todo o negócio, dando destaque à gestão de serviços e ao cliente.
Termo
Definição / Comentário
Serviço
É uma função independente, sem estado (stateless) que aceita uma ou mais requisições e devolve uma ou mais respostas através de uma interface padronizada e bem definida. Serviços podem também realizar partes discretas de um processo tal como editar ou processar uma transação. Serviços não devem depender do estado de outras funções ou processos. A tecnologia utilizada para prover o serviço, tal como uma linguagem de programação, não pode fazer parte da definição do serviço.
Orquestração
Processo de sequenciar serviços e prover uma lógica adicional para processar dados. Não inclui uma representação de dados.
Stateless
Não depende de nenhuma condição pré-existente. Os serviços não devem depender de condições de outros serviços. Eles recebem todas as informações necessárias para prover uma resposta consistente. O objetivo de buscar a característica de stateless dos serviços é possibilitar que o consumidor do serviço possa sequenciá-lo, ou seja, orquestrá-los em vários fluxos (algumas vezes chamados de pipelines) para executar a lógica de uma aplicação.
Provedor
O recurso que executa o serviço em resposta a uma requisição de um consumidor.
Consumidor
É quem consome ou pede o resultado de um serviço fornecido por um provedor.
Descoberta
SOA se baseia na capacidade de identificar serviços e suas características. Conseqüentemente, esta arquitetura depende de um diretório que descreva quais os serviços disponíveis dentro de um domínio.
Binding
A relação entre os serviços do provedor e do consumidor deve ser idealmente dinâmica; ela é estabelecida em tempo de execução através de um mecanismo de binding.

SOA Fundamental

Como serviços encapsulam a lógica
Pode ser em contextos distintos. Estes contextos podem ser específicos para uma tarefa de negócio, entidades de negócio e outros agrupamentos de negócio.
external image 350px-Fig3.1.jpg
Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Na figura, quando construímos uma solução consistente de serviço, cada serviço pode encapsular a tarefa realizada por um passo individual ou um sub-processo composto de um conjunto de passos. Um serviço pode encapsular toda a lógica do processo. O último caso representado pelo serviço pode englobar a lógica encapsulada de outros serviços.
Como serviços são relacionados
external image 350px-Fig3.2.jpg
Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Dentro do SOA serviços podem ser usados por outros serviços ou por outros programas. Independentemente, o relacionamento por trás do serviço é baseado no entendimento que os serviços possam interagir. Eles devem estar atentos ao outro. Esta consciência é obtida através do uso da descrição do serviço.
Como serviços se comunicam
Quando as mensagens são enviadas eles perdem o controle do que acontece depois. Essas mensagens podem ser equipadas com inteligência suficiente para auto-governar as partes lógicas do processamento.
external image 350px-Fig3.3.jpg
Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Esta arquitetura é similar ao passado da arquitetura distribuída que suporta mensagens e separação de interface de processamento lógico. O que distingue é como esses três componentes fundamentais (serviço, descrição e mensagem) são projetados. Onde entra a orientação de serviços.
Como serviços são projetados
external image 350px-Fig3.4.jpg
Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Acoplamento: busca-se um fraco acoplamento. Contrato de serviço: meio de acesso a esse serviço. Autonomia:serviços têm controle sobre a lógica que a encapsulam. Abstração: além do que é descrito no contrato de serviço, serviços escondem a lógica do mundo exterior. Reusabilidade: a lógica é dividida no serviço com a intenção de reuso.Agregabilidade: coleções de serviços podem ser coordenados e montados em forma de serviços compostos.Statelessness: serviços minimizam a retenção da informação em determinada atividade. Descoberta: serviços são projetados para ser exteriormente descrito, para que possam ser encontrados e avaliados através de mecanismos de descobertas disponíveis.
Como serviços são construídos A obtenção do SOA não exige serviço web, mas SOA pode e deve ser realizada através do uso da plataforma de tecnologia de serviço web.

Referências


  1. SOA Working Group of The Open Group. Definition of SOA (em inglês). Página visitada em 4 de junho de 2007.
  2. a b Boris Lublinsky. Defining SOA as an architectural style (em ingles). Página visitada em 4 de junho de 2007.
  3. Dirk Krafzig, Karl Banke, Dirk Slama. Enterprise SOA: Service-Oriented Architecture Best Practices. 1 ed. Estados Unidos da América: Prentice Hall, 2004. ISBN 0131465759
  4. Martin Keen, Susan Bishop, Alan Hopkins, Sven Milinski, Chris Nott, Rick Robinson, Jonathan Adams, Paul Verschueren, Amit Acharya. Patterns: Implementing an SOA using an Enterprise Service Bus (em inglês). Página visitada em 4 de junho de 2007.
  5. Raghu R. Kodali. What is service-oriented architecture? (em inglês). Página visitada em 4 de junho de 2007.
  6. Bobby Woolf. Introduction to SOA governance (em inglês). Página visitada em 4 de junho de 2007.
  7. OASIS. Reference Model for Service Oriented Architecture 1.0 (em inglês). Página visitada em 4 de junho de 2007.
  8. Chris Harding, The Open Group. Achieving Business Agility through Model-Driven SOA. Página visitada em 4 de junho de 2007.
  9. Rich Rogers. Reuse engineering for SOA. Página visitada em 4 de junho de 2007.