FUGITA Soa - Modelagem, Análise e Design

Prévia do material em texto

SOA — Modelagem,
Análise e Design
Henrique Shoiti Fugita
Kechi Hirama
2012
2
Sumário
Capa
Folha de rosto
Cadastro
Copyright
Agradecimentos
Prefácio
Público-Alvo
Organização Do Livro
Recomendações Ao Leitor
1. Introdução
Objetivo
1.1 Visão Geral
1.2 Perguntas Mais Frequentes
2. Entendendo SOA
Objetivo
2.1 Definições
2.2 Conceitos Relacionados A SOA
2.3 Princípios De Orientação A Serviços
3
2.4 Solução Orientada A Serviços
2.5 Benefícios E Desafios
2.6 Relação Com Outros Paradigmas
2.7 Considerações Do Capítulo
3. Ciclo de vida SOA
Objetivo
3.1 Boas Práticas
3.2 Ciclo De Vida SOA
3.3 Modelagem, Análise E Design
3.4 Papéis
3.5 Artefatos
3.6 Ciclo De Vida Iterativo
3.7 Considerações Do Capítulo
4. Modelagem
Objetivo
4.1 Modelagem De Processo As-Is
4.2 Modelagem De Processo To-Be
4.3 Especificação De Requisitos
4.4 Considerações Do Capítulo
5. Análise
Objetivo
5.1 Identificação De Serviços Candidatos
5.2 Análise De Gap
5.3 Análise De Realização
5.4 Considerações Do Capítulo
6. Design
Objetivo
6.1 Especificação De Contrato De Serviços
4
6.2 Especificação De Realização De Serviços
6.3 Verificação De Princípios
6.4 Considerações Do Capítulo
7. Fases complementares
Objetivo
7.1 Construção
7.2 Implantação E Gerenciamento
7.3 Considerações Do Capítulo
8. Considerações finais
Objetivo
8.1 Algumas Considerações
Referências
Bibliografia complementar
Apêndice A. Elementos gráficos usados no livro
Apêndice B. Estudo de caso
B.1 Contexto Do Estudo De Caso
B.2 Modelagem
B.3 Análise
B.4 Design
B.5 Fases Complementares
Glossário
Índice Remissivo
5
Cadastro
Preencha a ficha de cadastro no final deste livro E receba gratuitamente
informações sobre os lançamentos e as promoções da Elsevier.
Consulte também nosso catálogo completo, últimos lançamentos e serviços
exclusivos no site www.elsevier.com.br
6
http://www.elsevier.com.br
Copyright
© 2012, Elsevier Editora Ltda.
Todos os direitos reservados e protegidos pela Lei n° 9.610, de 19/02/1998.
Nenhuma parte deste livro, sem autorização prévia por escrito da editora, poderá ser
reproduzida ou transmitida sejam quais forem os meios empregados: eletrônicos,
mecânicos, fotográficos, gravação ou quaisquer outros.
Copidesque: Ana Paula Bezerra
Preparação: Pamela Andrade
Revisão: Lara Alves
Editoração Eletrônica: Thomson Digital
Elsevier Editora Ltda.
Conhecimento sem Fronteiras
Rua Sete de Setembro, 111 – 16° andar
20050-006 – Centro – Rio de Janeiro – RJ – Brasil
Rua Quintana, 753 – 8° andar
04569-011 – Brooklin – São Paulo – SP
Serviço de Atendimento ao Cliente
0800-0265340
sac@elsevier.com.br
ISBN: 978-85-352-5340-5
ISBN (versão eletrônica): 978-85-352-5460-0
Nota: Muito zelo e técnica foram empregados na edição desta obra. No entanto, podem
ocorrer erros de digitação, impressão ou dúvida conceitual. Em qualquer das hipóteses,
solicitamos a comunicação ao nosso Serviço de Atendimento ao Cliente, para que
possamos esclarecer ou encaminhar a questão.
Nem a editora nem o autor assumem qualquer responsabilidade por eventuais danos ou
perdas a pessoas ou bens originados do uso desta publicação.
7
mailto:sac@elsevier.com.br
CIP-BRASIL. CATALOGAÇÃO-NA-FONTE
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
F969s
Fugita, Henrique Shoiti
SOA : modelagem, análise e design / Henrique Shoiti Fugita, Kechi
Hirama. - Rio de Janeiro : Elsevier, 2012.
Apêndices
Inclui bibliografia e índice
Contém glossário
ISBN 978-85-352-5340-5
1. Arquitetura de computador. 2. Tecnologia da informação. 3. Software -
Desenvolvimento. 4. Projeto de sistemas. I. Hirama, Kechi. I. Título.
12-2643. CDD: 004.22
 CDU: 004.2
8
Agradecimentos
Agradeço à minha esposa, a meus pais e irmãos pelo apoio incondicional.
Henrique Shoiti Fugita
Agradeço aos meus pais (in memoriam), filhos, irmãos, cunhados e sobrinhos pelas alegrias
vividas.
Kechi Hirama
9
Prefácio
O cenário de aplicações de software tem evoluído muito nos últimos anos,
acompanhando a crescente necessidade de novas aplicações e de manutenção de soluções
existentes. Porém, isso tem exigido novas abordagens de desenvolvimento de software,
deixando os paradigmas tradicionais, como a orientação a objetos, insuficientes em
entregar soluções adequadas no contexto atual.
O que se observa claramente é que cada vez mais o software precisa ser concebido em
alto nível de abstração para dar conta de inúmeros requisitos que devem ser atendidos.
Se observarmos também a evolução do software juntamente com as abordagens de seu
desenvolvimento, poderemos verificar que, no início, nas décadas de 1960 e 1970, o
software era apenas uma ferramenta para apoiar alguma rotina de atividade do dia a dia,
por exemplo, emissão de relatórios.
Visto apenas como uma ferramenta, o software estava desacoplado de uma visão mais
ampla da organização. E, assim, progressivamente foi sendo desenvolvido e se
proliferando, gerando altos custos de manutenção. Os paradigmas de desenvolvimento
de software, notadamente a estruturada e orientação a objetos, surgiram para disciplinar
e minimizar seus impactos na organização, ao longo de seu ciclo de vida.
Porém, a distância entre as necessidades da organização, ou de negócio, ainda mais
exigentes, e as soluções propostas se tornavam maiores. Isto levou à discussão de novas
abordagens de desenvolvimento de software.
Atualmente fala-se muito em necessidade de alinhamento da Tecnologia da Informação
(TI) com as estratégias de negócio, e o paradigma de orientação a serviços tornou-se a
forma mais adequada e aceita para esse alinhamento, preservando investimentos através
de reuso de aplicações de software.
Este livro trata basicamente de tornar esse alinhamento mais simples e produtivo.
Para isso, adotou-se uma forma didática para abordar o assunto, desde a conceituação
básica de serviço até a sua implementação como um software.
O livro traz como tema central a modelagem, a análise e o design, provendo um
caminho completo desde a modelagem de negócio até a especificação de serviços,
complementado por construção, implantação e gerenciamento de serviços. Esse caminho
é um diferencial deste livro em relação às outras publicações semelhantes. Além disso,
como o paradigma de orientação a serviços carece de uma padronização, pensamos em
prover uma maneira bem embasada e enriquecida de ilustrações para que um leitor,
10
mesmo não experiente em orientação a serviços, possa acompanhar os conceitos e
exemplos do livro.
A modelagem, a análise e o design são frutos de diversas pesquisas acumuladas em
engenharia de software e, mais especificamente, pesquisas que foram feitas ao longo de
três anos em orientação a serviços até resultar em uma dissertação de mestrado e dois
artigos publicados, sendo um deles publicado em evento nos Estados Unidos (Fugita e
Hirama, 2008a e 2008b).
Público-alvo
Este livro é destinado a estudantes de graduação dos cursos de Engenharia de
Computação, Ciência de Computação, Tecnologia de Informação, Sistemas de
Informação e outros cursos similares.
Para os docentes destes cursos, o livro pode ser usado para aulas teóricas e práticas
aproveitando os exemplos ou adaptando os casos desenvolvidos.
Outro público que também pode se beneficiar do livro é constituído de gerentes e
desenvolvedores de software de empresas de software, que estão realizando projetos com
Arquitetura Orientada a Serviços (SOA – Service Oriented Architecture).
Organização do livro
Este livro está organizado em oito capítulos, mais referências, apêndices e glossário.
O Capítulo 1, Introdução, apresenta uma contextualização da modelagem, da análise e
do design, e perguntas mais frequentes.
No Capítulo 2, Entendendo SOA, é feita uma caracterização do conceito de SOA,
necessária para o bom entendimento das fases de modelagem, análise e design.
O Capítulo 3, Ciclo de vida SOA, apresenta boas práticas em modelagem, análise e
design e uma descrição de ciclo de vida e papéis e artefatos envolvidos.
O Capítulo 4, Modelagem, apresentaas atividades de modelagem de processo as-is e to-
be e especificação de requisitos de serviços.
O Capítulo 5, Análise, apresenta as atividades de identificação de serviços candidatos,
análise de gap e análise de realização de serviços.
O Capítulo 6, Design, apresenta a especificação de contrato, especificação de
realização, verificação dos princípios e revisão dos serviços.
O Capítulo 7, Fases complementares, apresenta uma descrição complementar do ciclo
de vida SOA para as fases de construção e de implantação e gerenciamento de serviços.
O Capítulo 8, Considerações finais, apresenta algumas considerações quanto aos
aspectos importantes do livro.
Na seção Referências, são apresentadas as referências usadas para a elaboração do
livro.
Na seção Bibliografia complementar, são apresentadas fontes de leitura interessantes
11
àqueles que queiram se aprofundar no assunto tratado no livro.
Na seção Apêndice, são apresentados o Apêndice A – os elementos gráficos usados no
livro, e o Apêndice B – um estudo de caso referente a uma instituição bancária, em que as
fases descritas no livro podem ser acompanhadas.
Na seção Glossário, é apresentada uma lista de termos que são familiares ao assunto do
livro.
Recomendações ao leitor
O livro está organizado de maneira a atender aos diversos tipos de leitores. No entanto, a
leitura ficará mais acessível àqueles que tenham noções de orientação a objetos e que
tenham alguma familiaridade com o processo de desenvolvimento de software. Aos
iniciantes, recomendamos fortemente a leitura desde o início, sem alternar os capítulos.
Àqueles que já dominam os conceitos básicos de orientação a serviços, pode-se iniciar pelo
Capítulo 3, no qual o ciclo de vida SOA é descrito. À medida que os conceitos estejam
bem assimilados, o estudo de caso do Apêndice B pode ser usado para orientar um
projeto real de software orientado a serviços em que você esteja envolvido.
12
1
Introdução
CONTEÚDO
1.1 Visão geral
1.2 Perguntas mais frequentes
Objetivo
O objetivo deste capítulo é apresentar uma visão geral sobre o novo paradigma de
desenvolvimento de software baseado no conceito de SOA (Service Oriented Architecture)
para atender às demandas atuais de novas soluções de forma flexível e com reuso de
capacidades de sistemas existentes. Além disso, algumas perguntas mais frequentes da
área são respondidas.
A TI (Tecnologia da Informação) é a área mais impactante na vida das pessoas e das
organizações. O sucesso e o bem-estar de todos dependem das soluções providas pela TI.
Então, conhecê-la é importante para estarmos preparados para as novas necessidades que
surgem a cada dia. Velhos conceitos e técnicas podem não ser suficientes em face deste
cenário. No estágio atual, o paradigma de orientação a serviços traz muitos benefícios e
desafios.
1.1 Visão geral
Atualmente, cada vez mais as empresas pertencentes às diversas áreas fazem uso da TI
para conduzir seus negócios.
Por outro lado, devido ao avanço da Internet e das tecnologias de integração e
comunicação, é comum as organizações fazerem uso do meio eletrônico para realizar
seus negócios com clientes, fornecedores e parceiros.
As empresas vêm empregando com mais frequência sistemas de TI no suporte aos seus
processos de negócio, com o intuito de automatizar atividades e aumentar a
produtividade. As empresas utilizam sistemas de TI como ERP (Enterprise Resource
Planning) para controlar sua operação, CRM (Customer Relationship Management) para
13
gerenciar informações sobre o relacionamento com seus clientes, SCM (Supply Chain
Management) para gerenciar interações com parceiros, fornecedores e consumidores.
Dentro desta infraestrutura de TI, cada sistema possui um conjunto de dados e
informações próprio. Devido ao fato de os processos de negócio envolverem diversas áreas
da organização, eles passam a demandar funções de mais de um sistema e tornam
necessária a troca de informações entre estes sistemas.
Principalmente nas organizações de maior porte, esses sistemas de TI constituem
ambientes extremamente complexos e heterogêneos, onde as aplicações geralmente
fazem uso de diferentes tecnologias, linguagens e protocolos. É comum encontrar em um
mesmo ambiente aplicações desenvolvidas com tecnologia Web, softwares de prateleira
(COTS – Commercial Off-The-Shelf), proprietários e aplicações legadas em mainframes.
Para suportar a comunicação entre elas, são utilizados adaptadores, conectores e
middlewares de integração.
Os negócios têm se tornado mais dinâmicos, exigindo mais agilidade por parte das
organizações e, consequentemente, de suas áreas de TI. É necessário que os sistemas
sejam capazes de se adaptar rapidamente às necessidades de negócio, em constante
mudança. No entanto, em um ambiente de TI heterogêneo este tipo de mudança é difícil
de realizar.
Dentro desse cenário, vem se desenvolvendo e sendo aceito o conceito de Arquitetura
Orientada a Serviços (SOA). O modelo de referência do OASIS (OASIS, 2006) define
SOA como um paradigma para organizar e utilizar competências distribuídas entre
vários domínios. Trata-se de um modo de estruturar as aplicações de software em
elementos chamados serviços.
Com SOA, os sistemas podem ser vistos de forma mais próxima ao negócio da
organização. Isto facilita o modo como os sistemas são desenvolvidos e mantidos. A
linguagem passa a ser menos técnica, sendo o termo “serviço” a ponte entre os processos
de negócio e as funções do sistema de software.
Para se trabalhar com SOA não bastam ter conceitos, boas práticas e ferramentas, mas
estes devem ser orientados por métodos que permitam atender eficazmente às
necessidades da organização. Por outro lado, seguindo os fundamentos de Engenharia de
Software, para se desenvolver um serviço, antes de tudo, deve-se fazer uma análise de o
quê realmente se pretende automatizar no âmbito do negócio.
Assim, para se projetar aplicações que efetivamente sigam o paradigma de orientação a
serviços, e para que elas realmente façam uso dos benefícios trazidos pelo paradigma, é
necessário haver uma atenção especial na identificação e especificação dos serviços que as
compõem.
Os serviços que apoiarão os processos de negócio e atenderão aos seus requisitos devem
ser definidos de forma adequada, para que apresentem atributos como reusabilidade e
flexibilidade e estejam alinhados com as metas de negócio. Além disso, os serviços devem
ser especificados de modo a fazer parte de um repositório de serviços reusáveis, que
possam ser orquestrados (compostos) em sistemas para apoiar os processos de negócio.
Assim, é necessário haver alguma abordagem para, a partir dos requisitos e metas de
14
negócio, identificar e modelar processos relevantes que façam uso de serviços disponíveis
na infraestrutura de TI ou de novos serviços a serem desenvolvidos. No caso de novos
serviços, esta abordagem deve ser feita por meio de atividades para especificá-los de
modo que eles possam ser implementados utilizando técnicas existentes e consolidadas.
Tal abordagem deve ser previsível e repetível, conduzindo de maneira consistente as
atividades de análise e especificação. De preferência, esse método deve fazer uso de
ferramentas e notações amplamente conhecidas para a modelagem e representação das
informações e para a geração de artefatos. Assim, a adoção desta abordagem seria
facilitada e traria menos impactos aos processos de desenvolvimento já existentes na
organização.
Portanto, o objetivo deste livro é apresentar a modelagem, a análise e o design de
aplicações orientadas a serviços.
Tem como propósito disciplinar o procedimento de identificação, análise e especificação
de um conjunto de serviços alinhados aos requisitos de negócio e aderentes aos princípios
de orientação a serviços. A aplicação destas atividades tem como resultado um grupo de
especificações de serviços, que pode ser então implementado utilizando-se técnicas de
desenvolvimento convencionais.
Tem como atividades a modelagem de negócio, na forma de casos de uso ou modelos
de processo de negócio,passando pela identificação e especificação dos serviços que
compõem a solução, e tem como produto final os artefatos que compõem a especificação
de cada serviço, incluindo sua interface, suas operações e mensagens, e seus requisitos
funcionais e não funcionais.
Considerando-se o ciclo de vida dos processos de negócio e o ciclo de vida dos sistemas
como dois processos distintos, geram-se especificações de serviços a partir dos processos
de negócio modelados. Os serviços seriam os elementos responsáveis por realizar a
ligação entre negócio e TI, por possuírem características de elementos desenvolvidos pela
TI para prover funções de negócio.
Há alguns poucos estudos na área de metodologias de desenvolvimento voltados para
SOA. Papazoglou e Van Den Heuvel (2006) descrevem as atividades do ciclo de vida dos
serviços, que consiste num processo cíclico e iterativo, que passa por modelagem de
processos, análise, design, implementação e execução e monitoria. Papazoglou e Van Den
Heuvel utilizam a tecnologia de Web Services para especificar e implementar os serviços.
A empresa IBM (2007) possui uma contribuição, que é um plugin a ser aplicado ao
RUP (Rational Unified Process) para o desenvolvimento de aplicações orientadas a
serviços. Este plugin acrescenta uma série de tarefas, papéis e artefatos ao RUP, de modo
a adaptá-lo para projetos de aplicações orientadas a serviços.
Erl (2005), por sua vez, descreve um método de análise e design de serviços baseado
nos princípios da orientação a serviços. Marks e Bell (2006) também propõem um método
de desenvolvimento de serviços, focando nas etapas de análise e design.
Ainda não existe uma convergência das diversas propostas de métodos em direção a
uma padronização, o que deixa o terreno aberto para discussão e apresentação de novas
propostas (Ramollari, Dranidis e Simons, 2007).
15
A modelagem, a análise e o design apresentados aqui contêm atividades, papéis e
artefatos definidos. Além da descrição das atividades, são apresentados exemplos que
auxiliam na sua aplicação.
As atividades são apoiadas em ciclo de vida orientado a serviços similar ao de um ciclo
de vida de software. Assim, as atividades são inspiradas nas disciplinas de um ciclo de
vida de software como o RUP, ou seja, modelagem de negócio, requisitos, análise &
design, implementação, testes e implantação. Para isso, adotou-se um ciclo de vida SOA,
conforme descrito no Capítulo 3. As atividades de modelagem, análise e design estão
embutidas neste ciclo e usam o termo “fase”, que engloba um conjunto de atividades em
vez de “disciplina”. As atividades podem ser aplicadas de forma iterativa como no RUP.
É importante destacarmos por que modelagem, análise e design são tão importantes
em SOA. No ciclo de vida de uma solução orientada a serviços, tudo começa na
modelagem de negócio, seja na forma de processos ou mesmo em casos de uso.
Modelagem de processos, modelagem de casos de uso e elicitação de requisitos são áreas
amplamente exploradas na literatura. Já existem diversas abordagens e técnicas
desenvolvidas, mas certas particularidades devem ser consideradas no contexto do ciclo
de vida SOA. O mesmo vale para implementação, testes e implantação. No caso de testes,
ela requer novas abordagens e técnicas. Atualmente, já existem diversas tecnologias (Web
Services, REST, SCA) que orientam a implementação de serviços e ferramentas que
tratam da complexidade destas tecnologias. Plataformas e ferramentas atuais permitem,
a partir de um contrato formal de serviço, gerar automaticamente um “esqueleto” de
código fonte, resumindo a implementação de um serviço à “clássica” codificação da
lógica de negócio, podendo ser empregadas técnicas amplamente conhecidas.
Diante disso, pode-se dizer que modelar processos e casos de uso é conhecido. O
mesmo pode-se dizer também quanto a como implementar serviços a partir de
especificações. Porém, resta um “gap” a ser resolvido, que pode ser resumido na seguinte
questão:
“Como um modelo de negócio deve ser definido e como, a partir dele, chegar a um
conjunto de especificações de serviços coeso que seja aderente aos princípios da orientação
a serviços?”
A resposta está nas fases de modelagem, análise e design, que devem levar em conta
que uma solução orientada a serviços exige considerações específicas. Por este motivo,
este livro foca nestas fases, apresentando a modelagem, a análise e o design de serviços
que partem de um modelo de negócios e entrega como resultado um conjunto de
especificações de serviços.
1.2 Perguntas mais frequentes
O que é Serviço?
É um mecanismo que possibilita o acesso a uma ou mais capacidades de um sistema,
onde este acesso é fornecido usando uma interface definida e exercitada de acordo com
restrições e políticas, conforme especificado pela descrição do serviço (OASIS, 2006).
16
O que é Orientação a Serviços?
É um paradigma de desenvolvimento de sistemas de software que permite o acesso a
diversas informações disponíveis em computadores ligados na Internet (Sommerville,
2011).
O que é Arquitetura Orientada a Serviços (SOA – Service Oriented Architecture)?
É um paradigma para organizar e usar competências distribuídas que podem estar sob
controle de domínios diferentes (OASIS, 2006).
O que é ciclo de vida de software?
É o período de tempo que inicia quando um produto de software é concebido e termina
quando o software não é mais disponível para o uso. O ciclo de vida de software
tipicamente inclui as fases de concepção, requisitos, design, implementação, teste,
instalação e verificação, operação e manutenção e, algumas vezes, retirada de operação
(IEEE, 1994).
Qual é a diferença entre serviço e objeto de software?
Tanto o serviço como o objeto tem propósitos semelhantes. Ambos podem ser
acionados para obter dados. Ambos podem ser integrados para compor uma função ou
sistema de software. O que difere um do outro é a sua abrangência. O serviço está mais
próximo das necessidades de negócio e lida com sistemas de grande porte. O serviço pode
ser implementado por objetos ou componentes de software (OASIS, 2006).
Qual é a diferença entre SOA e Web Services?
SOA é um estilo arquitetural em que sistemas consistem de usuários e provedores de
serviços, e Web Services é uma tecnologia que pode ser usada para implementar SOA
(Bianco, Kotermanski e Merson, 2007).
17
2
Entendendo SOA
CONTEÚDO
2.1 Definições
2.2 Conceitos relacionados a SOA
2.3 Princípios de orientação a serviços
2.4 Solução orientada a serviços
2.5 Benefícios e desafios
2.6 Relação com outros paradigmas
2.7 Considerações do capítulo
Objetivo
O objetivo deste capítulo é apresentar uma visão geral sobre SOA, as suas características
e a visão de alguns autores importantes. São apresentados alguns princípios, solução e
benefícios e desafios para trabalhar com este paradigma. Também é apresentada a
relação do SOA com outras abordagens.
Para falar sobre o paradigma de orientação a serviços, é necessário um entendimento
claro do que é SOA e do próprio conceito de serviço em si. Por ser um tema novo que tem
ganhado relevância recentemente, não existe ainda um consenso definitivo sobre tais
conceitos. Por meio da análise das características do paradigma e das interpretações de
alguns autores, este capítulo busca estabelecer um entendimento sobre sua definição.
2.1 Definições
Antes de discutirmos a definição de SOA, ou Arquitetura Orientada a Serviços, é
necessário compreender o que é a orientação a serviços. Basicamente, a orientação a
serviços é um paradigma de construção e integração de soluções de software compostas
por elementos modulares chamados serviços. O paradigma baseia-se nos princípios de
18
orientação a serviços, que serão descritos nas próximas seções (Erl, 2007).
2.1.1 O Que É Um Serviço?
A palavra serviço pode ser definida como a execução de um trabalho ou realização de
uma função de um prestador para um requisitante. No contexto específico de arquitetura
de software, o conceito de serviço está ligado à capacidade de um sistema executar umafunção para outro. No contexto de SOA, um serviço tem significado semelhante, já que
consiste em um módulo de software capaz de realizar uma função específica quando
solicitado por seus consumidores.
O serviço, unidade fundamental de uma arquitetura SOA, é uma unidade de software
que tem como propósito desempenhar uma função específica e que pode ser fornecido
por um provedor e utilizado por um consumidor.
Para ser considerado um serviço, uma unidade de software deve apresentar
características de design aderentes ao paradigma de orientação a serviços. Um exemplo
de serviço é o controle de crédito disponibilizado por uma entidade do tipo SERASA e
SPC. Ela pode fornecer informações sobre crédito de pessoas físicas e jurídicas a clientes
do tipo bancos. Os bancos podem implementar aplicações de concessões de crédito
somente chamando o serviço para receber estas informações.
Um serviço é composto por diversas operações. Fazendo uma analogia com a
orientação a objetos, as operações estão para um serviço assim como os métodos estão
para uma classe. Um exemplo de serviço com suas operações e respectivas entradas
(inputs) e saídas (outputs) pode ser visto na Figura 2.1.
As operações são invocadas por meio de mensagens. Um cliente envia uma
mensagem como parâmetro de entrada para uma operação, a fim de invocá-la. O
serviço (por meio de seu provedor/realização) executa a lógica definida em seu contrato e
retorna ao cliente uma mensagem de saída com o resultado da lógica executada.
Assim, um processo de negócio é um agregado de diversos serviços, conforme pode
ser visto na Figura 2.2. As instâncias de um processo executam uma série de operações.
Um serviço é composto de um conjunto de operações relacionadas. Uma operação
processa os dados recebidos. As mensagens são responsáveis por conduzir os dados
necessários de (e para) operações.
19
FIGURA 2.1 Serviço “Funcionário” com suas operações.
Observação:
Alguns autores utilizam o termo “competência” ou “capacidade” para se
referir ao conceito de operação.
20
FIGURA 2.2 Relacionamentos entre os componentes de uma arquitetura SOA. (Erl,
2005)
O conceito de serviço é adequado para representar transações que a área de TI
(Tecnologia da Informação) oferece para seus clientes e usuários de negócio. Serviço é um
conceito facilmente compreendido pela perspectiva de TI e pela de negócio, além de
possuir a granularidade apropriada para ser mapeado para atividades automatizadas de
um processo de negócio (Marks e Bell, 2005).
Devido à sua natureza, os serviços estabelecem um termo comum às linguagens de
negócio e de TI, podendo, assim, facilitar a comunicação e o alinhamento entre a área de
TI e os usuários/clientes de negócio durante a análise e o design de serviços. Por ser a
unidade fundamental de análise do SOA e por possuir correspondência direta com o
conceito de processo de negócio, o serviço possibilita uma melhoria na identificação de
requisitos de negócio e promove o alinhamento entre as áreas de negócio e de TI.
2.1.2 SOA: Estilo Arquitetural E Arquitetura
Já o termo SOA pode ser definido como um estilo arquitetural de software que se baseia
no paradigma de orientação a serviços. Segundo esta definição, SOA é um estilo
arquitetural que suporta o paradigma de orientação a serviços. Estilo arquitetural é
definido como a combinação de características distintas sobre a qual uma arquitetura é
realizada ou expressada.
Comumente, utiliza-se também o termo arquitetura SOA para designar uma
arquitetura de software que segue o estilo arquitetural SOA.
Dessa maneira, uma arquitetura SOA possibilita a obtenção de uma infraestrutura
para computação distribuída, por meio de serviços que podem ser fornecidos e
21
consumidos dentro de uma organização e entre organizações, por meio de redes de
comunicação como a Internet, conforme pode ser visto na Figura 2.3.
FIGURA 2.3 Infraestrutura geral criada para fornecimento e consumo de serviços.
Para que essa infraestrutura funcione, se existem provedores e clientes de serviços, deve
haver uma maneira padronizada para que estes se conheçam. Uma arquitetura SOA é
caracterizada pelas interações entre três tipos de agentes de software: os provedores de
serviço, os consumidores (ou clientes) de serviço e o registro de serviço (Huhns e Singh,
2005). As interações entre estes agentes podem ser visualizadas na Figura 2.4.
22
FIGURA 2.4 Agentes de uma arquitetura SOA. (Papazoglou, 2003)
Assim, os serviços são oferecidos pelos provedores de serviço, agentes responsáveis
por desenvolver suas implementações, fornecer suas descrições e prestar suporte técnico e
de negócio. De modo geral, os provedores disponibilizam módulos de software (as
implementações dos serviços) que podem ser acessados através de uma rede e que
publicam suas descrições em um registro de serviços – agente que abriga informações
sobre as funções oferecidas, os requisitos para se utilizar o serviço e orientações sobre
como realizar a interação com o provedor de serviço. É o registro de serviços que torna
estas informações disponíveis para serem consultadas por consumidores em potencial.
Por sua vez, os consumidores de serviço são os agentes que necessitam solicitar a
execução de um serviço. Os consumidores buscam nos registros a descrição de um serviço
que satisfaça às suas necessidades e, ao encontrá-la, utilizam esta descrição para ligar-se
ao provedor e realizar a invocação do serviço. Note que os papéis de provedor e
consumidor são lógicos, de modo que um mesmo agente pode exibir características de
ambos dependendo do contexto (Papazoglou, 2003).
Desse modo, uma arquitetura SOA funciona como, por exemplo, uma biblioteca
virtual. Alguém (provedor) anuncia que possui determinados livros. Estas informações
são catalogadas em uma estante virtual (registro). Um leitor (cliente) procura por um
livro fornecendo os seus dados ao registrador. Ao encontrar o livro procurado, descobre
que alguém (provedor) possui este livro e se conecta ao provedor para obter o seu
conteúdo.
2.1.3 Anatomia De Um Serviço
A Figura 2.5 apresenta a estrutura que compõe um serviço.
23
FIGURA 2.5 Anatomia de um serviço.
Um serviço é composto por um contrato e uma realização, ou seja, geralmente, um
serviço consiste em uma função de negócio desempenhada por um módulo de software (a
realização) que é descrito e encapsulado por um contrato bem definido, através do qual o
consumidor utiliza este serviço. Assim, os consumidores do serviço não têm acesso aos
detalhes de como ele foi construído, mas apenas aos detalhes expostos em seu contrato. O
contrato define as funções desempenhadas pelo serviço e eventuais pré-condições para
utilizá-lo, mas não revela como estas funções são realizadas. Esta forma de
encapsulamento é conhecida como caixa-preta, e é um princípio característico de
paradigmas como orientação a objetos e componentização de software. Porém,
diferentemente destes, serviços representam funções completas de negócio e são
projetados de modo a serem utilizados não somente no âmbito de um programa ou
sistema, mas no âmbito da organização ou até entre organizações (Papazoglou, 2003).
O contrato de serviço é complementado por uma descrição independente de
tecnologia, definindo funcionalidade, propósito, modo de utilização e restrições. As
descrições são geralmente armazenadas e disponibilizadas nos repositórios de metadados.
A interface de serviço é a definição técnica do contrato. A interface normalmente é
representada com o uso de uma linguagem formal, de preferência baseada em padrões
abertos. A interface contém as assinaturas das operações do serviço, com seus parâmetros
de entrada, de saída e exceções.
24
Os esquemas de mensagens descrevem o modelo e o formato dos dados utilizados
como entrada e saída das operações definidas na interface do serviço.
As políticas definem os requisitos não funcionais do serviço e restrições de uso. Já os
SLAs (Service Level Agreements), ou acordos de nível de serviço, especificam os níveis de
desempenho, disponibilidadee capacidade oferecidos pelo provedor aos consumidores do
serviço.
A realização é a parte que efetivamente executa a funcionalidade definida pelo
contrato de serviço. Pelo fato de não ser acessada diretamente pelo cliente (este tem
conhecimento apenas de sua interface), a realização pode sofrer modificações de
manutenção e evolução, sem que o impacto seja percebido pelo cliente. Uma realização
pode ser inclusive substituída sem que ocorra tal impacto. Isto se dá devido ao
desacoplamento proporcionado pela interface.
Para executar a funcionalidade do serviço, a realização combina lógica e dados. A
lógica corresponde às regras de negócio envolvidas na funcionalidade dos serviços e que
são executadas pela realização. A lógica, por sua vez, manipula dados, que podem ser
fornecidos pelos consumidores (nas mensagens de entrada) ou ser provenientes de
aplicações de back-end, como bases de dados e aplicações legadas.
2.1.4 Arquitetura De Referência
No contexto de SOA, uma arquitetura de referência é um framework abstrato que
permite o entendimento das entidades e relacionamentos significativos entre eles em um
ambiente orientado a serviços e para o desenvolvimento de arquiteturas concretas ou de
referência, usando padrões ou especificações consistentes que apoiam este ambiente. Tal
arquitetura de referência é baseada em conceitos unificados de SOA e pode ser usada por
arquitetos que estejam desenvolvendo arquiteturas específicas orientadas a serviços ou
treinando ou explicando SOA. A arquitetura de referência não está diretamente associada
a quaisquer padrões, tecnologias ou outros detalhes concretos de implementação (The
Open Group, 2009).
O Open Group é uma organização mundial que desenvolve padrões da área de TI, que
produziu uma definição do que é SOA (The Open Group, 2006) e também uma
arquitetura de referência para o estilo arquitetural SOA.
Conforme a Figura 2.6, segundo a arquitetura de referência, uma arquitetura SOA
pode ser interpretada por uma hierarquia com diversos níveis de abstração. Segundo esta
hierarquia, uma arquitetura SOA pode ser dividida em diversas camadas, cada qual com
sua função e relacionamentos com outras camadas.
25
FIGURA 2.6 Arquitetura de referência SOA. (The Open Group, 2009)
A arquitetura de referência é composta por nove camadas, sendo divididas em cinco
camadas funcionais que representam os elementos de uma solução orientada a serviços
(representadas pelas camadas horizontais: sistemas operacionais, componentes de serviço,
serviços, processos de negócio e interfaces consumidoras) e quatro camadas não
funcionais que representam aspectos transversais que se aplicam a todas as camadas
funcionais (representadas pelas camadas verticais: integração, qualidade de serviço,
informação e governança).
A camada de sistemas operacionais representa a infraestrutura de TI existente,
composta por sistemas e aplicações não orientadas a serviços. De modo geral, esta
camada fornece recursos que podem ser reusados por provedores de serviços para
implementar contratos de serviços. Nesta camada estão:
• aplicações orientadas a objetos (implementadas, por exemplo, em Java e Microsoft
.NET);
• aplicações implementadas com tecnologias legadas (como cliente-servidor e alta
plataforma);
• sistemas transacionais;
• bases de dados;
• aplicações-pacote (como ERPs e CRMs).
A camada de componentes de serviço contém componentes de software que
proveem as realizações dos serviços, implementando as definições dos contratos e
servindo como ponte para os sistemas operacionais. Um componente de serviço pode
26
realizar sozinho um contrato de serviço, ou pode encapsular o acesso a uma aplicação
legada (localizada na camada de sistemas operacionais) reusada para realizar o contrato.
Nesta camada, podemos ter:
• componentes implementados em plataforma compatível com tecnologias de
implementação de serviços (por exemplo, plataformas Java e .NET que suportam Web
Services);
• mediações que encapsulam o acesso a um sistema operacional e o disponibiliza por
uma interface de serviço.
A camada de serviços representa todos os serviços definidos em uma arquitetura SOA
e contém os contratos dos serviços e os metadados que os descrevem. É esta a camada
que provê a interface entre provedores e consumidores de serviço, pois fornece uma
abstração dos contratos publicados pelos provedores que podem ser descobertos pelos
consumidores e possibilita a interação entre eles.
A camada de processos de negócio contém a lógica de negócio, que é realizada por
meio de processos de negócio. Os processos de negócio, por sua vez, podem ser realizados
por serviços compostos que orquestram a execução de outros serviços ou por plataformas
BPMS (Business Process Management Systems) que executam fluxos de processo. Esta
camada é responsável por gerenciar e executar os fluxos de trabalho de cada processo de
negócio e possibilitar a participação de pessoas na execução de tarefas humanas.
A camada de interfaces consumidoras representa os canais através dos quais a
funcionalidade dos serviços e processos de negócio é disponibilizada para os usuários
finais. Esta camada contém interfaces e aplicações de front-end, como:
• plataformas de portal e mashups;
• formulários eletrônicos;
• aplicações Web;
• aplicativos desktop;
• aplicativos móveis.
Através das interfaces consumidoras, os usuários poderão:
• iniciar instâncias de processos de negócio;
• executar tarefas humanas dos processos de negócio;
• acompanhar o andamento de uma instância de processo de negócio;
• invocar operações de serviços;
• executar casos de uso que envolvem tarefas de processos e operações de serviços.
A camada de integração é fundamental para uma arquitetura SOA, pois é a que
possibilita a comunicação entre os elementos nas cinco camadas funcionais (provedores e
consumidores de serviços). Esta camada contém componentes capazes de executar
funções de mediação, como roteamento de mensagens, transformação de formato de
dados e conversão de protocolos de comunicação.
A camada de qualidade de serviço é a responsável por assegurar aderência a
políticas, SLAs e requisitos não funcionais definidos nos contratos de serviços. E contém
ferramentas e agentes que permitem a monitoração dos serviços e a captura de métricas e
eventos. Por meio destes, a camada de qualidade de serviço provê desempenho,
27
confiabilidade, disponibilidade, escalabilidade e segurança às camadas funcionais da
arquitetura de referência.
A camada de informação representa a arquitetura de informação da organização,
provendo aos usuários e gestores do processo acesso e análise dos dados dos processos de
negócio e serviços. Nesta camada, atuam tecnologias de business intelligence,
monitoração e análise de dados de processo.
A camada de governança tem o objetivo de garantir que os serviços e elementos das
demais camadas funcionais sejam aderentes aos padrões, modelos e orientações da
organização. Esta camada provê o gerenciamento do ciclo de vida dos serviços e pontos
de controle para verificação de conformidade com os padrões.
2.1.5 Tecnologias De Implementação
Para implementar uma arquitetura SOA, diversas plataformas tecnológicas podem ser
utilizadas. Uma das mais difundidas para implementação de serviços é a tecnologia Web
Services. A tecnologia Web Services consiste em um conjunto de padrões abertos que
possibilita a comunicação entre duas aplicações através da Web. Por ser baseada em
padrões abertos, que são amplamente aceitos e suportados por entidades internacionais
como o OMG (Object Management Group) e a W3C (World Wide Web Consortium), a
tecnologia Web Services promove a interoperabilidade, pois permite a interação entre
aplicações desenvolvidas em diferentes linguagens de programação, plataformas de
middleware e sistemas operacionais.
Um Web Service pode ser definido como um componente de software que possui uma
interface separada de sua implementação, expondo para seus consumidores somente sua
interface e abstraindo detalhes de implementação.
Um cliente se comunicacom um Web Service para fazer invocações através de troca de
mensagens, definidas em sua interface, conforme a Figura 2.7.
FIGURA 2.7 Web Service. (Erl, 2007)
A tecnologia Web Services é fundamentada na linguagem XML (eXtensible Markup
28
Language) (Bray et al., 2006), utilizada para a representação dos dados e como base para
os outros padrões. Os padrões fundamentais da tecnologia Web Services são:
• WSDL (Web Service Definition Language) – linguagem baseada em XML para
definição formal de interfaces de serviços;
• SOAP (Simple Object Access Protocol) – protocolo de comunicação baseado na troca
de mensagens em formato XML transmitidas via HTTP ou outros protocolos;
• UDDI (Universal Description, Discovery and Integration) – especificação de registro de
serviços publicados e descoberta de interfaces de serviços em WSDL.
Além dos padrões fundamentais, uma série de outros padrões foram definidos com o
objetivo de prover qualidade de serviço às interações com Web Services:
• WS-Policy – padrão para definição formal de políticas de serviços;
• WS-Security – permite a aplicação de mecanismos de segurança a mensagens SOAP,
como autenticação, assinatura digital e criptografia;
• WS-AtomicTransaction – padrão que possibilita a coordenação de transações
distribuídas envolvendo Web Services;
• WS-ReliableMessaging – protocolo para assegurar a entrega de mensagens SOAP
com tolerância a falhas de comunicação;
• WS-Notification – possibilita implementar soluções orientadas a eventos, através da
notificação de eventos entre Web Services;
• WS-Addressing – padrão para a especificação de dados de endereços físicos de Web
Services para roteamento de mensagens SOAP;
• WS-I Profiles – orientações definidas pela organização WS-I (Web Services
Interoperability) com o intuito de garantir a interoperabilidade entre Web Services
implementados em diversas plataformas.
Apesar de ser comum a implementação de serviços através do uso de Web Services, é
importante ressaltar que uma arquitetura SOA não se limita a um ambiente de
computação distribuída utilizando Web Services, mas também deve seguir os princípios
de orientação a serviços (veja mais detalhes na Seção 2.3).
Além da tecnologia Web Services, vem ganhando espaço o uso da tecnologia REST
(REpresentational State Transfer) na implementação de serviços. Serviços implementados
na tecnologia REST são chamados de serviços RESTful (RESTful services ou RESTful web
services). Apesar de ser considerada uma tecnologia mais simples do que Web Services
para implementação de serviços, ainda não há um consenso sobre como se realizar
completamente os princípios de orientação a serviços utilizando as tecnologias
relacionadas ao REST.
2.2 Conceitos relacionados a SOA
Nesta seção, são descritos alguns conceitos importantes relacionados ao paradigma de
orientação a serviços: a granularidade de serviço, as camadas de serviços, as composições
de serviços e o portfólio de serviços.
29
2.2.1 Granularidade De Serviço
Granularidade é um aspecto importante para se determinar o escopo de um serviço. Ao
se identificar um serviço, deve-se determinar se ele possuirá baixa granularidade (serviço
técnico ou de baixo nível) ou alta granularidade (serviço de negócio ou de alto nível). A
granularidade depende de quanta funcionalidade é encapsulada por um serviço, sendo
que, quanto mais funcionalidade, mais abrangente é o escopo do serviço e mais alta é sua
granularidade. Serviços de granularidade mais alta são utilizados diretamente pelo
negócio e podem ser formados pela composição de serviços de granularidade mais baixa.
Segundo a interpretação da empresa IBM (Bieberstein et al., 2005), os dois tipos de
serviços são necessários. Uma arquitetura SOA deve conter serviços diretamente
relacionados e com alto valor para o negócio e serviços técnicos que encapsulam lógica
com alto potencial de reuso. Os serviços de granularidade mais alta terão menos
consumidores, mas agregarão mais valor para o negócio. Eles terão também alta
dependência em relação a serviços de granularidade baixa, que, por sua vez, terão alto
potencial de reuso e terão baixa dependência com outros serviços.
Já Marks e Bell (2006) afirmam que serviços devem possuir alta granularidade e
representar funções, processos e transações de negócio, encapsulando demais
componentes de baixa granularidade. Segundo estes autores, serviços de baixa
granularidade, como componentes de software, teriam pouca utilidade direta para o
negócio. Por isso, eles não compensariam o overhead (custos adicionais) de se transformar
em um serviço e deveriam ser encapsulados por serviços maiores.
2.2.2 Camadas De Serviço
O paradigma de orientação a serviços pode trazer uma abstração entre a lógica de
negócio e a infraestrutura de TI, gerando um desacoplamento entre os processos de
negócios e a arquitetura de sistemas de informação. De acordo com a arquitetura de
referência, em uma arquitetura SOA, a camada de serviços dá suporte tecnológico aos
processos de negócio de uma organização, e localiza-se exatamente entre a camada de
processos de negócio e a infraestrutura de aplicações de TI, representada pelas camadas
de componentes de serviço e de sistemas operacionais (Erl, 2005). A camada de serviços
cria uma abstração entre os requisitos do negócio e as soluções providas pela TI
(Bieberstein et al., 2005), conforme mostra a Figura 2.8.
30
FIGURA 2.8 Camadas de uma arquitetura SOA. (Erl, 2005)
Baseado no princípio de composição e no Design Pattern Service Layers (Camadas de
Serviços) (Erl, 2009), é possível dividir a camada de serviços em mais três subcamadas de
abstração que determinam o tipo e a granularidade dos serviços. Assim, temos: a
subcamada de serviços de tarefa, a subcamada de serviços de entidade e a subcamada de
serviços utilitários. Na Figura 2.9, pode ser visualizada a hierarquia das subcamadas de
serviços.
31
FIGURA 2.9 Camadas de serviços. (Erl, 2005)
Os serviços utilitários possuem menor granularidade e representam os serviços de
infraestrutura de uma arquitetura SOA, oferecendo funções específicas de tecnologia. O
propósito dos serviços utilitários é prover funções reusáveis e processar dados contidos em
sistemas legados e novas aplicações desenvolvidas.
Serviços utilitários são agnósticos, ou seja, independentes de áreas ou domínios de
negócio. Por esse motivo, são reusáveis em diversos processos, podendo ser comuns à
organização como um todo. Eles representam serviços de TI, como segurança, auditoria,
notificação, transformação de dados, entre outros. Os serviços utilitários proveem a
infraestrutura de apoio aos outros serviços.
Os serviços de entidade proveem acesso às entidades pertencentes ao modelo de
dados da organização, por exemplo, cliente, pedido de venda, produto etc. Geralmente
suas operações representam funções de acesso a dados, como busca, inserção, atualização
e deleção. Serviços de entidade são considerados agnósticos, pois não são vinculados a
nenhuma aplicação ou processo específico. Por consequência, possuem alto potencial de
reuso, uma vez que proveem funções aplicáveis a diversos contextos. É importante que os
serviços de entidade estejam alinhados ao modelo de dados corporativo ou à arquitetura
de informação da organização.
Os serviços de tarefa representam a lógica contida em uma tarefa de processo de
negócio. Geralmente, possuem granularidade mais alta e atuam como controladores de
composições de serviços de entidade, utilitários ou outros serviços de tarefa para
32
implementar a lógica de negócio.
Os serviços de tarefa refletem eventos relativos aos processos de negócio. A execução de
um serviço de tarefa pode ser associada à realização de uma função ou atividade de um
processo. Estes serviços possuem alta granularidade e representam conceitos reais de
negócio, como abrir nova conta, analisar crédito ou aprovar solicitação. Estes são
exemplos de eventos reais que podem ser executados por uma pessoa (um atendente, por
exemplo), por um sistema ou por um serviço de tarefa.
Um tipoespecífico de serviço de tarefa, os serviços de tarefa orquestrada realizam a
ligação entre os processos de negócio e outras camadas de serviço. O conceito de
orquestração baseia-se na construção de processos de negócio a partir da composição de
diversos serviços, por exemplo, utilizando uma linguagem de orquestração como o WS-
BPEL (Web Services Business Process Execution Language) (OASIS WS-BPEL TC, 2007).
Trata-se de uma linguagem para se especificar o fluxo de trabalho e lógica de negócio
envolvidos nas chamadas Web Services. Nesta camada estão os serviços de processo, que
possuem alta granularidade e representam processos de negócio completos,
encapsulando a lógica de processamento necessária para coordenar a execução de
diversos serviços.
2.2.3 Composições De Serviços
Uma composição de serviços é um conjunto de serviços agregados com o intuito de
automatizar uma determinada tarefa complexa ou processo de negócio. Um serviço
composto é aquele que possui, pelo menos, uma operação composta, sendo uma
operação composta aquela cuja lógica inclui invocações a outras operações de outros
serviços.
No exemplo da Figura 2.10, o Serviço A é um serviço composto, pois sua Operação A
forma uma composição das operações Operação B do Serviço B e Operação C do Serviço
C.
33
FIGURA 2.10 Exemplo de composição de serviços (Serviço A composto pelos
Serviços B e C).
Inclusive, o princípio de orientação a serviços “Facilidade de Composição” orienta que
os serviços devem ser projetados e construídos de forma que possam participar de
composições (Erl, 2007).
2.2.4 Portfólio De Serviços
Um portfólio de serviços consiste em um conjunto de serviços que, de forma coletiva,
representam funções lógicas de uma organização ou domínio. Serviços pertencentes a um
mesmo portfólio devem formar um conjunto coeso onde as funções de um serviço
complementam os demais e todos os serviços seguem os mesmos padrões de design,
realização e implementação.
Uma organização pode possuir um único portfólio de serviços compartilhados entre
todas as áreas, ou pode possuir diversos portfólios de serviços de domínio para cada área
(Erl, 2007).
Um portfólio de serviços pode ser definido em uma única iniciativa, ou pode ser
desenvolvido incrementalmente através de diversos projetos de soluções orientadas a
serviços. Na definição “do zero”, o portfólio de aplicações e processos de negócio da
organização é analisado de modo a se identificar os serviços. Atividades de modelagem,
análise e design orientados a serviços são conduzidas de forma a se obter um portfólio de
serviços aderente aos princípios do paradigma de orientação a serviços. Esta abordagem
garante um conjunto inicial de serviços coeso e aderente ao paradigma, que pode
necessitar modificações conforme os requisitos de negócio sofram mudanças. No entanto,
esta abordagem pode mostrar-se inviável em muitos casos por exigir um alto
investimento inicial.
Na abordagem incremental, a cada projeto de implementação de aplicações ou
automação de processos, novos serviços podem ser adicionados ao portfólio, ou serviços já
existentes podem ser modificados. É uma abordagem com menor custo inicial, já que o
esforço é diluído ao longo dos vários projetos. Não exige a execução de um projeto
exclusivo de modelagem, análise e design de serviços. Porém, pode impor um custo
34
adicional relacionado ao impacto de eventuais mudanças em serviços já existentes no
portfólio. Pode exigir um esforço de governança e versionamento para gerenciar tais
mudanças.
2.3 Princípios de orientação a serviços
Segundo Erl (2005), o paradigma de orientação a serviços pode ser descrito a partir de
uma série de princípios que devem ser seguidos na construção de uma arquitetura:
contrato padronizado, reusabilidade, baixo acoplamento, abstração, capacidade de
composição, autonomia, independência de estado, visibilidade, capacidade de
composição e interoperabilidade. A seguir, estes princípios serão descritos com mais
detalhes.
2.3.1 Contrato Padronizado
Um serviço deve possuir um contrato bem definido que descreva para o mundo externo a
funcionalidade por ele exposta e ao mesmo tempo encapsule os detalhes específicos de
sua implementação (Marks e Bell, 2006).
O contrato representa um acordo formal firmado entre o provedor do serviço e seus
consumidores, criando uma relação de dependência. Por isso, deve haver uma atenção
especial na manutenção e versionamento destes contratos.
O contrato do serviço disponibiliza as seguintes informações aos consumidores: a
localização do serviço, as operações executadas, as mensagens de entrada e saída
utilizadas pelo serviço e as regras para sua utilização (Erl, 2005). Podem conter também
detalhes semânticos (significados) das operações do serviço.
Contratos de serviço devem ser representados em uma linguagem ou notação bem
definida, seguindo padrões abertos que garantam a interoperabilidade do serviço. Por
exemplo, no contexto de Web Services, contratos de serviço são definidos por interfaces de
serviço em WSDL (Web Services Description Language), esquemas de mensagens na
linguagem XSD (XML Schema Definition) e políticas. Em um documento WSDL, são
especificados os tipos de dados envolvidos, as mensagens e as operações do serviço. Já os
esquemas XSD são a especificação dos tipos de dados e das mensagens XML que serão
utilizadas.
2.3.2 Reusabilidade
A orientação a serviços visa tornar cada serviço reusável, mesmo que não haja requisitos
específicos para um dado serviço no momento em que ele é desenvolvido (Erl, 2005).
Serviços reusáveis são aqueles que podem possuir valor em diversos contextos de
processos de negócio e em interações intra e interorganizacionais e, por isso, devem
suportar diversos padrões de consumo destes serviços. Devido a esta natureza, novos
clientes podem reusar um serviço de uma maneira que não foi prevista em seu projeto
original. Nestes casos, deve haver uma infraestrutura de gerenciamento e governança de
35
serviços que garanta o desempenho e o devido funcionamento de tal serviço (Marks e
Bell, 2006).
Os serviços devem ser projetados considerando-se as várias formas de reuso, como
transações entre aplicações, composição de serviços e processos de negócio e uso como
serviços utilitários.
A reusabilidade de um serviço é relacionada à sua granularidade, sendo que, quanto
mais alta a granularidade de um serviço menores são as possibilidades de ele ser usado
em mais de um processo de negócio. Por exemplo, um serviço de gerenciar contas de
clientes possui uma granularidade mais alta do que o serviço cadastrar clientes. As
possibilidades de reuso do segundo serviço são maiores do que o primeiro, que pode
implementar especificidades de uma organização.
Além da granularidade, outro fator que afeta a reusabilidade de um serviço é a lógica
que ele executa. Quanto mais agnóstica for a lógica de um serviço, isto é, quanto menos
específica ela for com relação a um determinado contexto de aplicação, maior será sua
reusabilidade. Caso um serviço possua características específicas de um processo de
negócio ou contexto de aplicação, sua utilização em outras situações ou por outros
consumidores fica limitada.
2.3.3 Baixo Acoplamento
Uma característica importante de serviços em uma arquitetura SOA é a de que eles
devem possuir baixo acoplamento entre si, ou seja, devem ser fracamente acoplados
(baixa dependência). No entanto, na literatura, o termo baixo acoplamento pode possuir
vários significados práticos.
Um serviço fracamente acoplado pode significar um serviço cuja implementação pode
ser substituída, modificada ou evoluída ao longo do tempo sem causar impactos aos
consumidores do serviço (Marks e Bell, 2006). Nesse caso, está-se referindo ao
acoplamento entre a implementação do serviço e seus Consumidores.
Nessa mesma linha, baixo acoplamento pode ser indicado pela transparência de
localização. Por exemplo, um serviço pode ser consumido independentemente de onde
seu provedor está fisicamente localizado, criando um desacoplamento entre consumidor e
provedor(Papazoglou, 2003).
De maneira geral, o baixo acoplamento é uma condição em que um serviço está ciente
da existência de outros serviços, mas ainda é independente deles (Erl, 2005).
2.3.4 Abstração
Um princípio importante na orientação a serviços é a abstração ou encapsulamento da
lógica interna de um serviço por meio de sua interface. Ao separar interface de
implementação, o serviço age como uma caixa preta e expõe aos seus consumidores
somente informações sobre as operações disponíveis.
A granularidade de um serviço está diretamente relacionada com a quantidade de
funcionalidade que é encapsulada pelas operações de um serviço (Erl, 2005). Quanto
36
mais funcionalidade é encapsulada em um serviço, mais alta a granularidade deste
serviço.
2.3.5 Autonomia
Autonomia exige que a lógica de processamento encapsulada por um serviço fique
restrita dentro de certa fronteira estabelecida, o que evita a dependência com relação a
outros serviços. Isto permite que um serviço tenha controle total sobre sua própria lógica e
possa exercer um tipo de autogovernança (autocontrole).
A autonomia de um serviço pode ocorrer em dois níveis diferentes (Erl, 2005): no nível
do serviço e autonomia pura.
Na autonomia no nível do serviço, os limites entre os serviços são distintos, mas eles
ainda podem compartilhar recursos encapsulados, como bases de dados e sistemas
legados. Este cenário é comum, por exemplo, em diversos serviços desenvolvidos a partir
de uma mesma aplicação já existente. Neste caso, os serviços compartilham a aplicação,
mas fazem uso dela de maneira independente.
Na autonomia pura, a lógica e os dados encapsulados estão sob completo controle do
serviço, não sendo compartilhados com outros.
2.3.6 Independência De Estado
Um serviço deve evitar armazenar informações de estado e contexto ou minimizar o
período de tempo que estas informações serão mantidas (Erl, 2005). Isso quer dizer que a
resposta do serviço para uma mensagem deve ser independente das mensagens
anteriores processadas pelo serviço. Dependência de contexto ou de estado diminui o
potencial de reuso do serviço. Além disso, enquanto o serviço retiver informações de
estado de um consumidor, ele se torna indisponível para atender chamadas de outros
consumidores.
Para tornar um serviço o mais independente possível de estado, as mensagens devem
ser inteligentes, isto é, deve ser adicionado às mensagens o máximo de informação para
que elas se tornem autossuficientes e possam ser processadas sem a necessidade de dados
de estado.
2.3.7 Visibilidade
Os serviços devem ser visíveis, o que significa que seus contratos devem ser publicados e
disponibilizados de modo que possam ser descobertos e acessados pelos potenciais
consumidores. Na arquitetura SOA básica, estas interfaces são publicadas em um registro
de serviços, de onde elas podem ser buscadas pelos consumidores (Marks e Bell, 2006).
2.3.8 Capacidade De Composição
Serviços devem possuir capacidade de composição, isto é, devem ser projetados de forma
que possam participar de composições com outros serviços, formando serviços
37
compostos, ou ser orquestrados (compostos) no contexto de um processo de negócio. Para
isso, os serviços devem ser os mais desacoplados possíveis e suas operações devem ser as
mais atômicas possíveis (Marks e Bell, 2006; Erl, 2005).
2.3.9 Interoperabilidade
Serviços devem ser interoperáveis, isto é, deve ser possível interagir com um serviço
independentemente da tecnologia empregada em sua implementação. Quaisquer que
sejam a linguagem de programação, a plataforma ou o sistema operacional utilizado na
construção dos provedores, clientes e registros de serviços, as interações entre eles devem
ser possíveis. Para isso, estas interações devem ser realizadas utilizando-se padrões e
protocolos abertos compatíveis com qualquer tecnologia ou plataforma. Por isso, em uma
arquitetura SOA, a provisão e o consumo de serviços ocorrem de maneira transparente às
tecnologias e linguagens utilizadas em sua implementação, garantindo a
interoperabilidade entre serviços.
Atualmente, os padrões relacionados à tecnologia Web Services permitem a descrição
de interfaces, a troca de mensagens e a busca por serviços de maneira neutra com relação
às plataformas e linguagens utilizadas.
Observação:
Apesar de não ser considerada por alguns autores um princípio
propriamente dito, a interoperabilidade é listada nesta seção, pois descreve
uma característica de design que os serviços devem possuir e que é
fundamental para o paradigma de orientação a serviços.
2.4 Solução orientada a serviços
Em essência, toda solução de software é concebida para realizar algum tipo de
automação. No contexto de SOA, uma solução de software orientada a serviços consiste
em um conjunto de serviços e composições de serviços que automatizam um processo de
negócio. A lógica de um processo de negócio é encapsulada em um serviço de
orquestração, que, por sua vez, é composto por outros serviços de tarefa, entidade e
utilitários. Além dos serviços em si, uma solução orientada a serviços é composta por
elementos que dão suporte à automação do processo de negócio.
2.4.1 Elementos
Uma solução orientada a serviços consiste em uma aplicação composta por diversos
elementos que, integrados, automatizam um processo de negócio. Os elementos de uma
38
solução orientada a serviços distribuem-se nas camadas da arquitetura de referência
SOA, conforme a Figura 2.11.
FIGURA 2.11 Elementos de uma solução orientada a serviços.
Na camada de interfaces consumidoras, temos as interfaces através das quais os
usuários poderão interagir com os processos de negócio e com os serviços da solução
orientada a serviços.
Na camada de processos de negócio, temos os fluxos de processo sendo orquestrados
por uma plataforma BPMS ou por um serviço de tarefa orquestrada, que encapsula a
lógica do processo e é composto por outros serviços. Um processo de negócio de lógica
complexa pode ser dividido em subprocessos.
Na camada de serviços, a solução conta com um conjunto de serviços identificados a
partir do portfólio para suportar os processos de negócio e interfaces consumidoras. Em
uma solução orientada a serviços, pode haver serviços simples e compostos, pertencentes
às camadas de serviços de tarefa, de entidade e utilitários.
Os serviços são realizados por elementos contidos na camada de componentes de
serviço. Para realizar um serviço, podem ser utilizados componentes de serviço
desenvolvidos sob medida para implementar seu contrato, ou mediações para possibilitar
39
o reuso de recursos existentes.
Na camada de sistemas operacionais, temos os recursos existentes, que podem ser
bases de dados ou aplicações legadas acessadas por componentes de serviços e mediações.
Nesta camada podem ser incluídos também os provedores de serviços externos (cloud
service providers) da organização.
2.4.2 Ferramentas
Ao se implementar uma arquitetura SOA, torna-se necessária uma infraestrutura
tecnológica para dar suporte aos diversos tipos de elementos que compõem uma solução
orientada a serviços e atender aos requisitos de cada camada da arquitetura de referência.
As ferramentas utilizadas para suportar cada elemento da solução são:
• interfaces consumidoras – servidores de aplicação (com suporte a aplicações Web),
servidores de portais, ferramentas de desenvolvimento (com suporte a aplicações Web
e aplicações de portal);
• processos de negócio – plataformas BPMS, barramentos de serviços, ferramentas de
desenvolvimento (com suporte a modelagem de processos e orquestração de serviços);
• mediações – barramentos de serviços, adaptadores de integração, ferramentas de
desenvolvimento (com suporte a implementação de mediações);
• componentes de serviços – servidores de aplicação (com suporte a tecnologias de
serviços), ferramentas de desenvolvimento (com suporte a implementação de
componentes de serviço).
Além das ferramentas que dão suporte aos elementos funcionais de uma solução
orientada a serviços, a infraestrutura de TI pode contar com outrasferramentas para
atender à arquitetura SOA como um todo: monitores de atividade de negócio (BAM),
monitores de serviços, registros de serviços, repositórios de metadados e ferramentas de
infraestrutura de aplicações.
Servidor de aplicação
O servidor de aplicação é o ambiente de execução responsável por executar os
componentes de serviço e alguns tipos de interfaces consumidoras (aplicações Web),
conforme pode ser visto na Figura 2.12. Deve suportar tecnologias de implementação de
serviços, como Web Services ou REST.
40
FIGURA 2.12 Servidor de aplicação.
Para abrigar interfaces consumidoras, o servidor de aplicações deve suportar a
execução de aplicações Web.
Atua nas camadas de serviços, componentes de serviço, sistemas operacionais e
interfaces consumidoras.
Plataforma BPMS
Uma plataforma BPMS (Business Process Management System), ou plataforma de
orquestração de processos, é um container capaz de executar processos de negócio
definidos na forma de modelos de processo, conforme a Figura 2.13. Uma plataforma
BPMS pode suportar a composição de serviços na execução das tarefas do processo.
41
FIGURA 2.13 Plataforma BPMS.
A plataforma pode suportar também a orquestração de tarefas humanas (como os
sistemas de workflow), isto é, gerenciar a participação de pessoas na execução de tarefas
de um processo de negócio.
Atua nas camadas de processo e integração.
Barramento de serviços (ESB)
O barramento de serviços, ou ESB (Enterprise Service Bus), é um middleware que
possibilita a comunicação entre vários elementos de uma solução orientada a serviços,
conforme pode ser visto na Figura 2.14. O objetivo principal do ESB é permitir a
construção de serviços a partir de aplicações legadas, através das mediações.
42
FIGURA 2.14 Barramento de serviços.
O ESB permite que um ambiente heterogêneo com diversas tecnologias e protocolos de
comunicação possam se conectar em uma arquitetura SOA.
O barramento pode adicionalmente prover funções como segurança, tolerância a
falhas, transações distribuídas, auditoria, acesso unificado a diferentes modos síncronos e
assíncronos, escalabilidade, entre outros (Keen et al., 2005). Atua nas camadas de serviço,
componente de serviço, integração e qualidade de serviço.
Adaptadores de integração
Adaptadores de integração são ferramentas que possibilitam a comunicação com
aplicações legadas ou sistemas proprietários por meio de protocolos de comunicação e
formatos de dados que não são abertos nem padronizados, conforme a Figura 2.15. Os
adaptadores facilitam a construção de serviços a partir de aplicações legadas, pois
abstraem a complexidade de se lidar com protocolos e interfaces de programação (APIs –
Application Programming Interfaces) proprietárias.
43
FIGURA 2.15 Adaptador de integração.
Atua nas camadas de componentes de serviço e integração.
Portal
Um portal é um container de aplicações Web baseadas em páginas e aplicativos Web
chamados portlets, conforme pode ser visto na Figura 2.16. Sua principal função é prover
uma interface entre os usuários e os processos de negócio e serviços.
44
FIGURA 2.16 Portal.
É através do portal que os usuários poderão verificar suas caixas de entrada de tarefas,
executar as tarefas humanas de processos, preencher e visualizar formulários, monitorar
as métricas e indicadores do processo e acessar aplicações Web que utilizam serviços.
Atua na camada de interfaces consumidoras.
Monitor de atividade de negócio (BAM)
É uma ferramenta responsável por capturar eventos dos processos de negócio e coletar
valores de métricas que permitam aos usuários e gestores monitorar em tempo real o
desempenho dos processos de negócio, implementando o conceito de BAM – Business
Activity Monitoring, conforme a Figura 2.17. Geralmente, os monitores proveem painéis
para exibição de métricas e indicadores de desempenho (KPIs – Key Performance
Indicators). Podem também fazer uso de tecnologias de Business Intelligence e Data
Warehousing para possibilitar a geração de relatórios e a realização de análises baseadas
em dados de histórico e predições. Atua na camada de arquitetura de informação.
45
FIGURA 2.17 Monitor de atividade de negócio.
Registro de serviços
Um registro de serviços é uma base de dados que provê informações sobre os serviços em
uma arquitetura SOA, conforme a Figura 2.18. O registro de serviços contém
informações como:
• descrições de serviços e suas operações;
• interfaces de serviços e esquemas de mensagens;
• especificações de políticas de serviços e SLAs;
• endereços físicos de serviços.
46
FIGURA 2.18 Registro de serviços.
Em implementações de SOA com Web Services, registros de serviços são comumente
construídos baseados no padrão UDDI, de modo a funcionar como um catálogo de
endereços físicos de serviços. Um barramento de serviços pode consultar um registro de
serviços em tempo de execução, para obter os endereços físicos e realizar o roteamento
dinâmico de mensagens de serviços.
Atua nas camadas de serviços, integração e governança.
Repositórios de metadados
Em uma arquitetura SOA, um repositório de metadados é uma base de dados utilizada
para armazenar metadados de serviços e artefatos relacionados, conforme a Figura 2.19.
Alguns exemplos de metadados e artefatos armazenados por um repositório são:
• versão do serviço;
• status do ciclo de vida;
• descrições de contratos de serviços;
• especificações de realização de serviços;
• especificações de SLA;
• código fonte;
• modelos de análise e design;
• relacionamentos e dependências entre os serviços.
47
FIGURA 2.19 Repositório de metadados.
Potenciais consumidores consultam um ou mais repositórios para obter informações
sobre serviços, que podem satisfazer suas necessidades, e sobre como acessá-los (o
contrato do serviço). Para isso, um repositório pode prover funções de busca de serviços.
Alguns registros são capazes de gerenciar o ciclo de vida dos serviços, servindo como
ferramenta de governança.
Atua nas camadas de serviços e governança.
Monitor de atividade de serviços (SAM)
É uma ferramenta responsável por coletar valores de métricas operacionais dos serviços,
implementando o conceito de SAM – Service Activity Monitoring, conforme pode ser
visto na Figura 2.20. O monitor SAM diferencia-se do monitor BAM por focar em
aspectos operacionais dos serviços e ser voltado para administradores de serviços e
operadores, enquanto o BAM é voltado para monitoração de dados de negócio e é
destinado a usuários finais dos processos de negócio.
48
FIGURA 2.20 Monitor de atividade de serviços.
O monitor de serviços deve registrar valores de métricas como tempo de resposta de
operações, tamanho e quantidade de mensagens, número de mensagens processadas por
período de tempo e disponibilidade, exibindo tais dados em painéis para os
administradores de serviços. Monitores de serviços proveem mecanismos para assegurar
o desempenho dos serviços e o cumprimento de SLAs, possibilitando a geração de alertas
e automação de ações corretivas.
Além disso, os monitores de serviços podem prover informações sobre o uso dos
serviços e da capacidade dos recursos, apoiando a governança dos serviços.
Atua nas camadas de qualidade de serviço, arquitetura de informação e governança.
Ferramentas de desenvolvimento e testes
A construção de uma solução orientada a serviços, com diferentes tipos de elementos que
devem ser integrados, geralmente demanda a utilização de ferramentas específicas.
Existem atualmente diferentes ambientes de desenvolvimento integrados (IDEs –
Integrated Development Environments), conforme a Figura 2.21, específicos para
implementar e testar:
• componentes de serviços (com suporte a diferentes linguagens de programação e
tecnologias);
• mediações;
• orquestrações de serviços;
49
• aplicações para Web;
• aplicações de portal;
• modelos de processos e simulações.
FIGURA 2.21 Ferramentas de desenvolvimento e testes.
Permitem a construção e testes de elementos em todas as camadas funcionais.
Ferramentas de infraestrutura de aplicaçõesUma arquitetura SOA pode fazer uso de algumas ferramentas para gerenciar a
infraestrutura de serviços, provendo desempenho, escalabilidade, confiabilidade e
disponibilidade. Alguns exemplos de tais ferramentas são:
• ambientes de grid computing;
• soluções de gerenciamento de carga (workload management);
• soluções de virtualização;
• soluções de computação em nuvem (cloud computing).
Atuam nas camadas de integração e qualidade de serviço.
2.5 Benefícios e desafios
Uma vez entendido o conceito de SOA, pode-se pensar sobre quais resultados podem ser
obtidos por uma organização ao adotar o paradigma de orientação a serviços.
Implementar e manter uma arquitetura SOA dentro de uma organização é uma tarefa
50
custosa, que exige tempo, recursos e esforço, além de promover mudanças no
comportamento e na cultura da organização. Os resultados de uma arquitetura SOA
devem ser tangíveis e devem compensar o investimento realizado.
Dessa maneira, são discutidos os benefícios e possíveis desafios que podem ser trazidos
pela adoção do paradigma de orientação a serviços nas organizações.
2.5.1 Facilidade De Integração
Uma arquitetura SOA é baseada em serviços intrinsecamente interoperáveis (Erl, 2005).
Devido ao uso de padrões abertos de interação, aplicações estruturadas na forma de
serviços possuem uma capacidade inerente de se comunicarem de maneira interoperável.
É como se as aplicações orientadas a serviços já nascessem pré-integradas, minimizando
o esforço de se desenvolver integrações entre aplicações.
A estrutura de serviços tende a facilitar a integração de aplicações, uma vez que uma
arquitetura SOA é uma maneira de se reorganizar uma infraestrutura formada de silos
de software em um portfólio de serviços compartilhados. Em uma arquitetura SOA, as
aplicações existentes e futuras podem acessar os serviços sem a necessidade de se
desenvolver integrações ponto a ponto baseadas em protocolos proprietários. Assim, esta
arquitetura pode ser utilizada em ambientes com múltiplas aplicações baseadas em
variadas tecnologias e plataformas que necessitam se comunicar. Para efetuar transações
entre elas, pode-se conectar e reusar serviços com esforço mínimo de programação e
integração (Papazoglou, 2003).
Marks e Bell (2006) chegam até a chamar esse benefício de integração de custo zero.
Tal afirmação baseia-se no fato de que não é necessário nenhum esforço para realizar a
conversão entre protocolos e formatos, para se estabelecer a comunicação entre aplicações
em uma arquitetura SOA, uma vez que elas já estariam baseadas nos mesmos padrões
abertos de interação.
2.5.2 Padronização De Tecnologias
Como parte da implementação da arquitetura SOA em uma organização, é desenvolvida
toda uma infraestrutura de comunicações para viabilizar as interações inter e intra-
aplicações seguindo os princípios de orientação a serviços. Esta infraestrutura de
comunicação de serviços passa a fazer parte da infraestrutura de TI e torna-se o padrão
de comunicação no âmbito da organização como um todo. Deste modo, a organização
deve investir seus recursos focando-se em uma única plataforma tecnológica de
comunicação (Erl, 2005).
Além disso, se forem utilizados a tecnologia de Web Services e os padrões baseados em
XML para a implementação da arquitetura SOA, tem-se a oportunidade de estabelecer o
XML como uma plataforma padronizada de representação de dados na organização (Erl,
2005). Tendo-se um formato padrão para representar dados pode reduzir a complexidade
do ambiente de aplicações. Dessa maneira, estabelecem-se os documentos XML como o
padrão para troca de informações e os esquemas XML como o padrão para representação
51
das entidades de dados.
A padronização traz seus benefícios para a organização, mas sua implementação
torna-se um desafio importante para as organizações ao adotar o conceito de SOA (Erl,
2005). É necessário garantir que os esquemas definidos nos vários projetos sigam as
mesmas diretrizes e padrões e formem um modelo de dados organizacional, ou corre-se o
risco de obter uma arquitetura não flexível e acoplada a aplicações existentes.
2.5.3 Maior Reuso De Recursos
A orientação a serviços prega que os serviços sejam especificados de forma que possam
suportar o reuso de maneira inerente. O projeto de aplicações voltadas para o reuso
permite um reaproveitamento imediato de lógica pré-existente, bem como cria
oportunidades futuras de reuso por potenciais clientes (Erl, 2005). A longo prazo, o reuso
de serviços tende a reduzir custos, prazos e esforço para implementação de soluções
(Bieberstein et al., 2005).
Apesar de o projeto de serviços reusáveis exigir um esforço adicional (se comparado ao
esforço de se desenvolver um serviço sem suporte a reuso), tal investimento é
recompensado quando futuras aplicações desenvolvidas reaproveitarem as funções
existentes. Marks e Bell (2006) estimam como algo em torno de 50% o esforço adicional
para tornar um serviço reusável. Portanto, o ROI (Return on Investment) é obtido no
primeiro reuso do serviço, se considerarmos que o reuso representa uma economia do
custo de se desenvolver o serviço a partir do zero (Marks e Bell, 2006).
O uso de Web Services permite também encapsular funções de ambientes legados de
forma que estes possam fazer parte de uma arquitetura SOA. Isso permite a
interoperabilidade de sistemas legados sem a necessidade de integrações ponto a ponto,
que são custosas e inflexíveis. Assim, reduz-se o custo de se integrar legados e novas
aplicações e torna-se possível que as novas aplicações reusem funções existentes no legado
dentro do contexto de orientação a serviços. Com a possibilidade de se reusar sistemas
legados, a necessidade de se substituí-los passa a não ser tão imediata (Erl, 2005).
2.5.4 Agilidade No Negócio
A orientação a serviços promove flexibilidade nas soluções construídas, uma vez que são
constituídas por serviços fracamente acoplados, sendo, portanto, preparadas para
mudanças. O projeto de serviços com baixo acoplamento e a possibilidade de realizar
composições entre eles torna a arquitetura SOA um ambiente mais adaptativo. A
estruturação dos serviços em camadas de negócio e de tecnologia também gera
flexibilidade, pois permite que ambos os domínios evoluam e sofram alterações de
maneira isolada (Erl, 2005).
A orientação a serviços pressupõe que as aplicações construídas tendem a evoluir com o
tempo, conforme os requisitos de negócio se alterem ou novos surjam. Em uma
arquitetura SOA bem estruturada, o impacto desta evolução é minimizado, uma vez que
propriedades como reuso e interoperabilidade permitam que a área de TI responda mais
52
rapidamente às solicitações da área de negócio. Isso promove a agilidade organizacional,
que permite à organização responder prontamente aos eventos do ambiente, reduzir o
time-to-market de seus produtos e serviços e obter vantagem competitiva. Não somente o
tempo para se ter uma solução pronta é diminuído como também o custo e o esforço (Erl,
2005).
Desse modo, a orientação a serviços busca responder aos requisitos de negócio em
prazos mais curtos e oferecer soluções mais flexíveis. As mudanças, que costumam ser
custosas e danosas em ambientes não flexíveis, passam a ser facilitadas (Bieberstein et al.,
2005).
Para se atingir tal estado, é necessário que a infraestrutura esteja padronizada e que os
serviços efetivamente possuam características de baixo acoplamento, reusabilidade e
interoperabilidade.
2.5.5 Alinhamento Com O Negócio
A orientação a serviços promove o alinhamento estratégico entre TI e negócio. Devido ao
fato de os serviços representarem conceitos de negócio, o vínculo entre as soluções
entregues pela área de TI (os serviços) e as metas estratégicas da organização (tanto de TI
como de negócio) torna-se mais claro. Desta maneira, os investimentos destinados a TI
são justificados devido a esta percepção do valor agregado (Bieberstein et al., 2005).
O serviço pode ser visto também como uma maneira de uniformizar os vocabulários
das áreas de negócio e de TI dentro de uma organização.