Saltar para o conteúdo

Service-oriented architecture

Origem: Wikipédia, a enciclopédia livre.

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]

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. É urgente e necessário que todos os softwares sejam repensados a partir da perspectiva de um conjunto 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 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 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. 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. Uma das características do SOA é o baixo acoplamento. 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 de processos (process 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.

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

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.

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

Ver também

O Wikiquote tem citações relacionadas a 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. ↑ a b Boris Lublinsky. «Defining SOA as an architectural style» (em ingles). Consultado em 4 de junho de 2007 
  3. ↑ Dirk Krafzig, Karl Banke, Dirk Slama (2004). Enterprise SOA. Service-Oriented Architecture Best Practices 1 ed. [S.l.]: Prentice Hall. ISBN 0131465759  Parâmetro desconhecido |Autor= ignorado (|autor=) sugerido (ajuda)
  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» (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». Consultado em 4 de junho de 2007  Texto "ingles" ignorado (ajuda)
  9. ↑ Rich Rogers. «Reuse engineering for SOA». Consultado em 4 de junho de 2007  Texto "ingles" ignorado (ajuda)

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


Obtida de "https://pt.wikipedia.org/w/index.php?title=Service-oriented_architecture&oldid=36693461"