𝖂𝖎ƙ𝖎𝖊

Service-oriented architecture

Predefinição:Multitag

SOA é o acrônimo de Service-Oriented Architecture (em português: Arquitetura Orientada a Serviços) é um padrão de projeto de software, ou padrão de arquitetura de software de baixo acoplamento, onde as funcionalidades implementadas nas aplicações devem ser disponibilizadas na forma de serviços,[1][2] acessíveis normalmente via web services,[2][3][4] é baseada nos princípios da computação distribuída, que utiliza o paradigma request/reply para estabelecer a comunicação entre os sistemas clientes e os sistemas dos serviços.[5]

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]

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]

Introdução

Parece provável supor que a maioria das funcionalidades de um software sejam entregues e consumidas como serviços. Devido à maturidade dos protocolos Web Services e outras tecnologias, o mais provável é que tudo seja realmente implementado através de serviços.

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 formulário on-line de uma aplicação ou visualizar um extrato bancário de uma conta, ou realizar uma reserva on-line para bilhete de avião. Ao invés de realizar de chamadas diretas para o código fonte, os serviços definem protocolos que descrevem como enviar e receber as mensagens, utilizando descrições em metadados.

Por exemplo, os principais sites da Internet criaram e ainda estão criando formas de interação entre estes sites e o seu blog ou sua página na rede social. Estas interações e trocas de informação serão aprofundadas ainda mais e disponibilizadas através de serviços, facilitando a troca de informações entre duas entidades diferentes. Sendo assim, a interação de uma página na Internet com outra página ou mesmo um software corporativo, ou ainda um aparelho de telefone celular serão muito mais fáceis. O desenho e projeto de novos softwares precisam levar esta ideia em consideração. Já não existem aplicações isoladas. Todas elas acabam trocando informação com outras aplicações.

Os desenvolvedores SOA associam funcionalidades de software (os serviços) aos objetos de forma não-hierárquica. Durante o processo eles utilizam uma ferramenta de software que contém a lista completa de todos serviços disponíveis, suas características e seus significados, com o objetivo de construir uma aplicação utilizando esses recursos.

Programadores fazem amplo uso da linguagem XML para descrição dos tipos e estruturas de dados em SOA. Também baseada em XML, a Web Services Description Language (WSDL) normalmente descreve os serviços, enquanto o protocolo SOAP descreve os protocolos de comunicação, além de outros padrões alternativos, como WADL e REST. 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 podem 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 o designer de sistema seja capaz de compreender e gerir com um gasto razoável de custo e esforço.

SOA tem como objetivo permitir que usuários agrupem funcionalidades de forma a obter aplicações dedicadas que serão construídas quase inteiramente a partir de serviços de software pré-existentes. Quanto maior o agrupamento, menor a quantidade de interface necessária para implementar qualquer conjunto de funcionalidade; no entanto, agrupamentos muito grandes são mais difíceis de reutilizar. Cada interface tem uma quantidade de processamento, portanto há que se considerar a performance e a granularidade dos serviços. A grande promessa de SOA sugere que a criação da n-ésima aplicação é baixa, pois todos os serviços necessários para satisfazer aos requisitos da aplicação já existem. No mundo ideal, bastaria coordenar os serviços para produzir uma nova aplicação.

Mas, para SOA operar, nenhuma interação deve existir entre as funcionalidades ou dentro delas. Ao contrário, usuários especificam a interação dos serviços de forma pré-definida com o objetivo de atender aos novos requisistos. Por isso, a necessidade de implementar serviços com mais funcionalidades que funções ou classes tradicionais, e para que o designer da aplicação não se sobrecarregue ao tratar a complexidade de milhares de objetos com granularidade menor.

Os programadores desenvolvem os próprios serviços usando linguagens tradicionais como Java, C, C++, C# ou COBOL. Serviços também podem ser usados como interfaces para sistemas legados, permitindo a mudança de layout de sistemas antigos.

Os serviços SOA são menos acoplados que as funções de bibliotecas de um programa executável. Serviços SOA também rodam sobre ambientes seguros (como Java e .Net) e com outras linguagens de programação que podem gerenciar alocação de memória e exceção, permitir late binding e certo nível de abstração de tipos de dados.

A partir de 2008, um número crescente de empresas de software começaram a oferecer serviços de software para terceiros por uma taxa pré-definida. No futuro, sistemas SOA podem consistir de tais serviços combinados com outros criados de forma personalizada. Essa ação tem o potencial de reduzir os custos sobre os clientes e promover a padronização na indústria de software. Em particular, a indústria do turismo tem agora um conjunto bem-definido e documentado de serviços e dados, o suficiente para permitir que qualquer engenheiro de software razoavelmente competente possa criar software de agência de viagens utilizando os serviços totalmente off-the-shelf.

A arquitetura SOA se apoia na orientação a serviços como princípio fundamental de design. Se um serviço apresenta uma interface simples que abstrai a complexidade envolvida nela, usuários podem utilizar esses serviços sem necessitar de conhecimentos de sua implementação.

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 concema de banco de dados compartilhado. Isto permite que novas funcionalidades sejam desenvolvidas para um formato de negócio de referência comum para cada elemento de dados.

Abordagem de Web Services

Web Services (Serviços Web) podem implementar uma arquitetura orientada a serviços. Web Services 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 (provedor) cria um Web Service e, eventualmente publica sua interface e acesso à 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 irá explorá-los de outra forma. 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 Broker, então, decide o âmbito do Broker. Brokers 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 Brokers são especializados em muitas listas. Outros oferecem altos níveis de confiança nos serviços listados. Alguns cobrem um amplo panorama de serviços e outros tem foco dentro de uma indústria específica. Alguns Brokers catalogam outros. Dependendo do modelo de negócio, os Brokers 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.

Consumer - O consumidor de serviços (consumer) ou cliente do serviço web localiza entradas no registro do broker para encontrar as operações e em seguida, liga-se ao prestador do serviço para invocar um de seus web services. Seja qual for o serviço que os consumers precisam, eles têm que levá-la para o broker e em seguida, conectar com o respectivo serviço e usá-lo. Consumers podem acessar vários serviços, se estiverem disponíveis.

Acoplamento

É o nível de interdependência entre os módulos de um sistema. Uma das características do SOA é o baixo acoplamento. Um módulo é considerado coeso quando possui uma atividade bem definida e um baixo acoplamento. 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 de processos (process services)[10], 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.

Processos

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.

Esquema adaptado do paradigma "find-bind-execute"

Tecnicamente falando, o processo recomenda 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.

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. Consequentemente, 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.

Fundamentos de SOA

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.

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

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.

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

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. Stateless: 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.

Abordagens

  • Abordagem top-down: Essa abordagem identifica a necessidade de um serviço através da análise de processos de negócio ou das interações com entidades externas. Ela normalmente é realizada pelo analista de negócio em conjunto com arquiteto de sistemas e tem como principal benefício o alinhamento mais natural com o negócio. Se o serviço (ou as capacidades necessárias) já existir em um sistema legado, será necessário procurá-lo e extraí-lo. Se o serviço ainda não existir, é necessário construí-lo.
  • Abordagem bottom-up: serviços (ou capacidades) identificados através dos pontos de integração entre sistemas ou das funcionalidades já disponíveis nos sistemas atuais. Nessa abordagem corre-se o risco de criar serviços que não representam uma função de negócio ou que tenham acoplamento com a implementação. Porém, pode ser uma boa opção quando existem muitos problemas de integração spaghetti ou se deseja preparar para substituição de algum sistema de back-end.

Ver também

Wikiquote
O Wikiquote possui citações de ou sobre: SOA

Referências

  1. ↑ SOA Working Group of The Open Group. «Definition of SOA» (em inglês). Consultado em 4 de junho de 2007 
  2. ↑ 2,0 2,1 2,2 Boris Lublinsky. «Defining SOA as an architectural style» (em ingles). Consultado em 4 de junho de 2007 
  3. ↑ 3,0 3,1 Dirk Krafzig, Karl Banke, Dirk Slama (2004). Enterprise SOA. Service-Oriented Architecture Best Practices 1 ed. Estados Unidos da América: Prentice Hall. ISBN 0131465759 
  4. ↑ 4,0 4,1 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» (PDF) (em inglês). Consultado em 4 de junho de 2007 
  5. ↑ Raghu R. Kodali. «What is service-oriented architecture?» (em inglês). Consultado em 4 de junho de 2007 
  6. ↑ Bobby Woolf. «Introduction to SOA governance» (em inglês). Consultado em 4 de junho de 2007 
  7. ↑ OASIS. «Reference Model for Service Oriented Architecture 1.0» (PDF) (em inglês). Consultado em 4 de junho de 2007 
  8. ↑ Chris Harding, The Open Group. «Achieving Business Agility through Model-Driven SOA» (em English). Consultado em 4 de junho de 2007 
  9. ↑ Rich Rogers. «Reuse engineering for SOA» (em English). Consultado em 4 de junho de 2007 
  10. ↑ Nicolai M. Josuttis, SOA in Practice The Art of Distributed System Design.

Ligações externas


Outros projetos Wikimedia também contêm material sobre este tema:
Wikcionário Definições no Wikcionário
Wikiquote Citações no Wikiquote


Predefinição:Engenharia de software

talvez você goste

Permaneça conectado

Parceiros

Dieta Cetogenica | NutriPro Saúde