Service-Oriented Architecture ou Arquitetura Orientada a Serviços é uma arquitetura de software que é baseada nos conceitos chaves de Aplicações de Negócio (Frontend Application), Serviços, Repositório de Serviços (Service Repository) e Barramento de serviços (Service Bus). Um serviço consiste de um contrato, uma ou mais interfaces e uma implementação (KRAFZIG,2007). SOA é uma tentativa de se construir informações que forneça uma sensibilidade quase instantânea de mudar as condições de mercado, fechando a lacuna entre ameaças e oportunidades. Seu maior potencial é mudar não só a maneira como os sistemas de informação são construídos, mas também a natureza de como os negócios são feitos (DELPHI GROUP, 2005). Segundo Erl (2006), SOA é um termo que representa um modelo no qual a lógica de automação é decomposta em pedaços menores e distintos de unidades lógicas. Coletivamente, estas unidades abrangem uma grande parte da lógica de automação do negócio. Individualmente estas unidades podem ser distribuídas.
2.5.1. Caracterização de SOA
Segundo Krafzig (2207) SOA é composto dos seguintes elemetos: Aplicações de Negócio (Frontend Application), Serviços, Repositório de Serviços (Service Repository) e Barramento de serviços (Service Bus).
As aplicações são a parte ativa do SOA. Eles iniciam e controlam toda a atividade dos sistemas da empresa. Existem diferentes tipos de aplicações, uma aplicação com interface gráfica como uma aplicação web, por exemplo, ou um cliente que interage diretamente com usuários finais. Contudo As aplicações não precisam interagir necessariamente com o usuário final. Programas batch ou programas longos que chamam funcionalidades periodicamente ou como o resultado de um evento específico também são aplicações de usuário. De qualquer forma é inteiramente possível que uma aplicação delegue muito das suas responsabilidades de um processo de negócio para um ou mais serviços, contudo é sempre uma aplicação que inicia um processo de negócio e recebe os resultados.
Um serviço é um componente de software com um significado funcional distinto que tipicamente encapsula um conceito de negócio em alto nível. Ele consiste das seguintes partes:
Contrato – O contrato de serviço provê uma especificação informal do propósito, funcionalidade, regras e o uso do serviço. A forma destas especificações varia de acordo com o tipo de serviço que podem ser uma interface, uma implementação, uma lógica de negócio ou até mesmo dados.
Repositório de Serviços – O repositório de serviços provê as facilidades para descobrir localização dos serviços, é também onde se adquire todas as informações necessárias para se utilizar os serviços.
Service BUS – o Service BUS conecta todos os participantes do SOA e as aplicações front-ends uns com os outros. Se dois participantes precisam se comunicar, por exemplo, se uma aplicação precisa evocar alguma funcionalidade ou um serviço básico, o Service BUS faz com que as coisas aconteçam. O conceito de Service BUS é similar ao conceito de software BUS como definido no contexto do CORBA, contudo existem diferenças significativas entre os dois conceitos. O mais importante é que o Service BUS não necessariamente é composto por uma tecnologia única, mas ao contrário compreendem uma variedade de produtos e conceitos.
2.5.2. Componentes do SOA
Segundo Broering (2006) nossa indústria reconhece três tipos de componentes atualmente: Modelo Técnico, Modelo de Negócio e Modelo de Aplicação:
Componentes Técnicos - são tecnologias específicas e independentes do negócio principal. Componentes Técnicos são requeridos para desenvolvimento de aplicação, mas não é específico ao modelo de negócio. Exemplos incluem controle de erro, compressão, e segurança. Componentes técnicos são freqüentemente estáticos, auto- suficientes, altamente reutilizáveis, e relativamente baratos. Exemplos incluem controles de ActiveX para Microsoft Visual Basic e controles SWING para o Java.
Componentes de Negócio - manipulam tarefas específicas baseados em regras de negócio. Aprovação de cartão de crédito é um exemplo. Componentes de negócio são atualmente os menos comuns desde que conhecimento vertical do negócio é requerido. O mercado para componentes empresariais pré-construídos, às vezes chamados “application building block”', está crescendo.
Componente de Aplicação - é a agregação de componentes existentes que satisfazem uma porção principal de exigências do negócio. Esta caixa de ferramentas oferece uma alternativa atraente para o desenvolvimento “in-house”'. Modelos de aplicação sólidos permitem assimilação fácil da lógica da aplicação. Eles trazem muitos benefícios e alavancam sistemas existentes.
2.5.3. Benefícios de SOA
Ainda segundo Broering (2006) SOA trás diversos benefícios significantes: Influência no Investimento Inicial – SOA influencia o investimento inicial da organização em hardware, linguagens, recursos de desenvolvimento e arquitetura. Desde que um business service é uma agregação de componentes existentes, a responsabilidade de compatibilidade em torno dos componentes não está no desenvolvedor, isto pertence a estrutura SOA. Usando componentes existentes, apenas requer conhecimento da interface e nome. Os componentes internos são protegidos do mundo exterior. Também estão protegidas as complexidades de infra-estrutura e obtenção dos dados que fluem através dos componentes. Estes componentes influenciam os investimentos das organizações de forma anônima, construindo serviços de um conglomerado de componentes construídos em diferentes máquinas, rodando em diferentes sistemas operacionais, desenvolvidos em diferentes linguagens rodando em diversas arquiteturas.
Menor tempo para o mercado – Como bibliotecas de componentes crescem e o tempo para o mercado diminui exponencialmente. Novas iniciativas suportam desenvolvimento rápido de novos business services via reuso de serviços existentes (serviços podem chamar outros serviços) e componentes quando possível. Reusando componentes existentes, reduzimos tempo de projeto, tempo de desenvolvimento e tempo de teste. Se o componente trabalha neste requisito, simplesmente adiciona-se o componente para o serviço e pode-se continuar trabalhando. Nenhum desenvolvimento ou teste adicional será necessário, apenas teste do business service como um todo. Reduz custos – Como “negócios” demandam desenvolvimento e novos requisitos são introduzidos, o custo de criação de tecnologias que satisfazem estes requisitos é altamente reduzido quando porções destes fluxos de processos existem como componentes em um ambiente.
Redução de Riscos - Por influencia de componentes existentes, torna-se menos propenso a introdução de novas falhas na criação de um business service. A reutilização um componente que funcione, a probabilidade é alta que ele continuará funcionando apropriadamente. Os riscos também são reduzidos permitindo a organização manter integrado seu ambiente de desenvolvimento, linguagem de programação, sistema operacional e base de dados. O aprendizado do desenvolvimento é altamente reduzido se for possível manter estes aspectos.
Ciclo de melhoria contínuo para o processo de negócio - SOA fornece uma clara representação de fluxos de processos identificados em um componente utilizado por um business service. Isto fornece para a análise de negócio, um ambiente ideal para a monitoração das operações de negócio. Modelagem do processo reflete no business service. Manipulações de processos são arquivadas reorganizando as peças em um padrão (componentes em um business service). Isto permite mudanças no processo enquanto os efeitos e facilidades continuam aumentando.
Process-centric processing – A maioria das arquiteturas tende a ser “program- centric”. Aplicações são desenvolvidas por conveniência do programador. Freqüentemente, conhecimento do processo está espalhado entre componentes. A aplicação é como uma caixa preta, sem nenhuma granularidade exterior disponível. Reuso requer aproveitamento de código incorporando aproveitamento de bibliotecas, ou herança de objetos. Em uma arquitetura de processo centralizado, a aplicação é desenvolvida pelo processo. O processo é decomposto em uma série de passos, cada um representando um business service (ou conjunto de componentes). De fato, cada serviço ou funções de componentes como uma sub-aplicação. Estas sub-aplicações são unidas criando um processo capaz de satisfazer os requisitos do negócio. Esta granularidade permite o reuso de cada sub-aplicação por toda a organização.