Henrique Shoiti Fugita-SOA PDF

SOA
Modelagem, Análise e Design

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
SOA
Modelagem, Análise e Design
Henrique Shoiti Fugita

Kechi Hirama
2012
© 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
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.
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 - Desenvol-

vimento. 4. Projeto de sistemas. I. Hirama, Kechi. I. Título.
12-2643. CDD: 004.22
CDU: 004.2
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
v
Prefácio
O cenário de aplicações de software tem evoluído muito nos últimos anos, acompa-
nhando 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 softwa-
re, 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 conce-
bido 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 desenvol-
vimento 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 ser-
viç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 concei-
tuaçã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, mesmo não experiente em orientação a serviços, possa acompanhar
os conceitos e exemplos do livro.
vii
viii Prefácio
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 mes-
trado 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 Com-
putaçã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, apresenta as 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 can-
didatos, 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 interes-
santes àqueles que queiram se aprofundar no assunto tratado no livro.
Prefácio ix
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.
1
Introdução
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 organi-
zaçõ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.
Conteúdo
1.1 Visão geral 1
1.2 Perguntas mais frequentes 4
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 gerenciar informações sobre o relacionamento com seus clientes, SCM (Sup-
ply 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.
1
2 SOA: Modelagem, Análise e Design
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 Arqui
tetura 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 orien
taçã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 requi
sitos 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 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
1 Introdução 3
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á exis
tentes 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 espe
cificaçã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 basea
do 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).
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 impor
tantes 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).
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).
1 Introdução 5
O que é Arquitetura Orientada a Serviços (SOA – Service Oriented Archi-

tecture)?
É 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).
2
Entendendo SOA
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.
Conteúdo
2.1 Definições 7
2.2 Conceitos relacionados a SOA 17
2.3 Princípios de orientação a serviços 22
2.4 Solução orientada a serviços 25
2.5 Benefícios e desafios 35
2.6 Relação com outros paradigmas 39
2.7 Considerações do capítulo 40
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 compos-
tas por elementos modulares chamados serviços. O paradigma baseia-se nos princípios
de 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
7
executar uma funçã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 carac-
terí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.
Figura 2.1 Serviço “Funcionário” com suas operações.

2 Entendendo SOA 9
As operações são invocadas por meio de mensagens. Um cliente envia uma men-
sagem 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.
Observação:
Alguns autores utilizam o termo “competência” ou “capacidade” para se referir ao conceito de
operação.
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 auto-
matizadas 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
Figura 2.2 Relacionamentos entre os componentes de uma arquitetura SOA (Erl, 2005).
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
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.
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.
Figura 2.3 Infraestrutura geral criada para fornecimento e consumo de serviços.

2 Entendendo SOA 11
Figura 2.4 Agentes de uma arquitetura SOA (Papazoglou, 2003).
Assim, os serviços são oferecidos pelos provedores de serviço, agentes res-

ponsá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.
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,
Figura 2.5 Anatomia de um serviço.
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 pa-
drõ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.
2 Entendendo SOA 13
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, disponibilidade e 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.
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, compo-
nentes 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).
Figura 2.6 Arquitetura de referência SOA (The Open Group, 2009).
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
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 con-
trato. Nesta camada, podemos ter:
● componentes implementados em plataforma compatível com tecnologias de im-
plementação de serviços (por exemplo, plataformas Java e .NET que suportam
Web Services);
2 Entendendo SOA 15
● 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 (prove-
dores 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, 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 tecno-
logia 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 comunica com um Web Service para fazer invocações através de
troca de mensagens, definidas em sua interface, conforme a Figura 2.7.
A tecnologia Web Services é fundamentada na linguagem XML (eXtensible
Markup 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;
Figura 2.7 Web Service (Erl, 2007).

2 Entendendo SOA 17
● 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 In-
teroperability) 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 com-
putaçã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.
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 trans-
formar 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.
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 sub-
camadas 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.
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.
2 Entendendo SOA 19
Figura 2.8 Camadas de uma arquitetura SOA (Erl, 2005).
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. Geral-
mente 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
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 solici
taçã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.
Figura 2.9 Camadas de serviços (Erl, 2005).
Um tipo especí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 orques-
traçã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 com-
posto é 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.
2 Entendendo SOA 21
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 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 serviços que garanta o desempenho e o devido funcionamento de
tal serviço (Marks e Bell, 2006).
2 Entendendo SOA 23
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 pos-
suir 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 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 siste-
mas 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 in-
formaçã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 pu-
blicados 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
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 Entendendo SOA 25
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 des-
criçã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 interopera-
bilidade é 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 solução orientada a serviços distribuem-se nas camadas da arquitetura de
referência SOA, conforme a Figura 2.11.
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 orques-
trados 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.
Figura 2.11 Elementos de uma solução orientada a serviços.
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, per-
tencentes à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 pos
sibilitar 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
2 Entendendo SOA 27
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 outras ferramentas 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.
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.
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.
O ESB permite que um ambiente heterogêneo com diversas tecnologias e proto-
colos 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
Figura 2.13 Plataforma BPMS.

2 Entendendo SOA 29
Figura 2.14 Barramento de serviços.
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.
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.
É 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.
Figura 2.15 Adaptador de integração.
Figura 2.16 Portal.

2 Entendendo SOA 31
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 pai-
né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.
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.
Figura 2.17 Monitor de atividade de negócio.

Figura 2.18 Registro de serviços.
Em implementações de SOA com Web Services, registros de serviços são comu-

mente 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;
Figura 2.19 Repositório de metadados.

2 Entendendo SOA 33
● 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.
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
Figura 2.20 Monitor de atividade de serviços.

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.
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 proces-
sadas 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 go-
vernanç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ífi-
cas. 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;
Figura 2.21 Ferramentas de desenvolvimento e testes.

2 Entendendo SOA 35
● orquestrações de serviços;
● aplicações para Web;
● aplicações de portal;
● modelos de processos e simulações.
Permitem a construção e testes de elementos em todas as camadas funcionais.
Ferramentas de infraestrutura de aplicações

Uma arquitetura SOA pode fazer uso de algumas ferramentas para gerenciar a infra-
estrutura de serviços, provendo desempenho, escalabilidade, confiabilidade e dis-
ponibilidade. 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 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é-in-
tegradas, 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, é desenvol-
vida 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 basea-
dos 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 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 compa-
rado 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 adicio-
nal 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).
2 Entendendo SOA 37
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 in-
teroperabilidade 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 rapidamente às solicitações da área de negócio. Isso promove a agili-
dade 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 cos-
tumam 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 vocabu-
lários das áreas de negócio e de TI dentro de uma organização. Em uma organização
com uma arquitetura SOA, o conceito de serviço pode tornar-se um elemento de

ligação entre os profissionais de TI e os usuários/clientes das áreas de negócio. Com
um termo comum no vocabulário de ambas as áreas, torna-se possível estabelecer
metas de negócio baseadas diretamente no conceito de serviço e tendo em mente os
serviços existentes, além de melhorar a comunicação e o entendimento no relacio-
namento TI-negócio (Marks e Bell, 2006).
Quando o paradigma de orientação a serviços é aplicado para dar suporte aos
processos de negócio, a noção de atividade de processo pode ser mapeada diretamente
à execução de um serviço de negócio orquestrado pelo processo.
Com o surgimento de linguagens para especificação e execução de processos de
negócio como o WS-BPEL, reduziu-se o gap (à distância) que existia entre os modelos
de processos elaborados pelos analistas de negócio e a implementação do fluxo de
trabalho desenvolvida pelos profissionais de TI. Quando um modelo de processo
é elaborado seguindo a sintaxe do WS-BPEL, o próprio modelo torna-se o código
executável que será utilizado na implementação do processo (Erl, 2005).
2.5.6 Requisitos de desempenho

Em uma arquitetura SOA com um grande número de serviços interagindo uns com os
outros, é esperado um aumento no volume de comunicações baseadas em mensagens.
Caso o ambiente de execução destes serviços não esteja preparado para tal demanda,
pode começar a haver latência de processamento e degradação do tempo de resposta
das operações (Erl, 2005).
Como a arquitetura SOA pode ser composta de diversas camadas, com neces-
sidade de processamento nas interações entre elas, é esperado que os requisitos
de desempenho tornem-se maiores. Além disso, o processamento e o transporte
de dados nos formatos e protocolos da tecnologia Web Services, como XML,
XSD e SOAP, tendem a ser custosos para a infraestrutura. Ao adotar o paradigma
de orientação a serviços, as organizações devem atentar para tais requisitos de
desempenho no momento de dimensionar a infraestrutura necessária para seu
ambiente.
2.5.7 Requisitos de segurança

Em um ambiente de serviços autônomos disponíveis para quaisquer potenciais
consumidores, surge a preocupação com a segurança das operações dos serviços.
Alguns tipos de operações mais críticas necessitam meios de garantir que apenas
consumidores autorizados possam utilizá-las. Além disso, como a comunicação entre
provedores e consumidores de serviços é baseada em mensagens, é preciso assegurar
a integridade e confidencialidade de certos tipos de informação (Erl, 2005).
Desse modo, é necessário que a infraestrutura e as ferramentas utilizadas na im-
plantação de uma arquitetura SOA possuam mecanismos e tecnologias que atendam
a tais requisitos de segurança para serviços. O padrão WS-Security busca solucionar
estes requisitos em um ambiente de Web Services.
2 Entendendo SOA 39
2.5.8 Complexidade de análise e design

O desenvolvimento de soluções compostas por diversos serviços independentes e
desacoplados traz um aumento na complexidade da arquitetura e introduz um número
maior de pontos de falha (Bieberstein et al., 2005).
Além disso, é preciso assegurar que os serviços desenvolvidos possuam caracte-
rísticas aderentes aos princípios de orientação a serviços. Sem estas características,
pode-se ter como resultado uma arquitetura de serviços que não traz os benefícios
esperados, como reuso, facilidade de integração e alinhamento com o negócio.
Segundo Papazoglou e Van Den Heuvel (2006), os paradigmas de desenvolvimento
existentes, como a orientação a objetos e o desenvolvimento baseado em componen-
tes, não são diretamente aplicáveis a arquiteturas orientadas a serviços e nem baseadas
em tecnologia Web Services. Desse modo, fazem-se necessárias técnicas e métodos
específicos para análise e design de soluções orientadas a serviços.
2.5.9 Necessidade de governança
Com a existência de um portfólio de serviços disponíveis para toda a organização,
pode haver diversas equipes de projeto desenvolvendo e utilizando serviços deste
portfólio ao mesmo tempo. Um serviço deixa de ser responsabilidade de uma
única equipe de projeto e deixa também de pertencer a um único processo de
negócio.
O paradigma de orientação a serviços exige que seja definida uma estrutura
de governança na organização, de modo a estabelecer papéis, responsabilidades,
processos para organizar os serviços desenvolvidos (Erl, 2007). A governança define
mecanismos para desenvolver, manter e divulgar os serviços do portfólio e garantir
a padronização da arquitetura.
2.6 Relação com outros paradigmas

O paradigma de orientação a serviços não significa uma ruptura com relação a outros
paradigmas de desenvolvimento de software, pois representa uma evolução derivada
da orientação a objetos e do desenvolvimento baseado em componentes e pode, in-
clusive, ser aplicado juntamente com eles. A seguir, é descrita a relação da orientação
a serviços com estes outros paradigmas e suas diferenças.
2.6.1 Orientação a objetos

Conforme citado anteriormente, o paradigma de orientação a serviços tem como ponto
em comum com o paradigma de orientação a objetos o fato de ambas serem maneiras
de se construir software com base na separação de assuntos (Erl, 2005). Princípios
como abstração, encapsulamento e composição de serviços foram formulados a partir
de conceitos de orientação a objetos. Além disso, orientação a objetos é comumente
utilizada para implementar a lógica de aplicação encapsulada em um serviço. En-
tretanto, as duas abordagens possuem algumas diferenças.
A orientação a serviços prega a autonomia entre suas unidades (os serviços).

Apesar de objetos possuírem rotinas desacopladas e até reusáveis, as classes por de-
finição possuem relacionamentos entre si (agregação, herança), o que gera certo grau
de dependência entre os objetos. Além disso, os objetos geralmente são executados
utilizando um mesmo conjunto de recursos compartilhados.
Na orientação a serviços, muito das informações necessárias para o processamento
está contido nas mensagens, de forma que os serviços guardem o mínimo possível
de informação de estado. A orientação a serviços encoraja a amarração da lógica
de processamento com os dados, mantendo mais informação contida nos objetos e
criando uma dependência de estado.
2.6.2 Orientação a componentes

Apesar de serem relacionados, os conceitos de componente e de serviço guardam
diferenças entre si e não devem ser confundidos. Alguns princípios da orientação a
serviço, como a abstração de interface e implementação e a transparência de locali-
zação, são oriundos de boas práticas da orientação a componentes. Porém, o serviço
difere dos componentes ao não se limitar a uma determinada plataforma, linguagem
ou tecnologia de implementação.
Alguns autores afirmam que serviços podem ser implementados utilizando-se
componentes (Endrei et al., 2004), o que pode levar à falsa ideia de que componen-
tes e serviços podem ser mapeados de um para um. Existem dois pontos a serem
considerados que desfazem este tipo de conclusão.
O primeiro é a granularidade de componentes e serviços. As funções oferecidas
por componentes em geral têm granularidade baixa, não possuindo valor direto para
os processos de negócio (Marks e Bell, 2006). Serviços devem possuir granularidade
um pouco mais alta, pois representam atividades de negócio e proveem funções de
utilidade direta para o negócio. Portanto, a implementação de um serviço geralmente
é construída pela composição de mais de um componente de baixa granularidade,
resultando em algo de granularidade um pouco mais alta.
O segundo é o fato de, apesar de possuírem interface e implementação separadas,
assim como os componentes, os serviços operam sob um tipo de contrato que estabe-
lece um acordo e cria expectativas com base em suas características semânticas. Tais
características, pelo fato de serem complexas e de natureza humana, não podem ser
representadas por um simples conjunto de assinaturas de funções, como as descrições
de interface de arcabouços de componentes atuais (Perrey e Lycett, 2003). Mesmo a
tecnologia de Web Services, que é frequentemente empregada na implementação de
SOA, ainda não oferece uma maneira consolidada de representar estas características
semânticas.
2.7 Considerações do Capítulo

Neste capítulo, foi apresentado o conceito de SOA e foram discutidas algumas de suas
definições e características. Tais definições e características deverão ser mantidas em
2 Entendendo SOA 41
mente para se poder acompanhar a descrição da modelagem, da análise ou do design

orientados a serviços e o estudo de caso apresentado no Apêndice B.
O paradigma de orientação a serviços tende a ser cada vez mais adotado pelas
organizações, tendo em vista benefícios que se espera dele. Porém, esta transição
impõe alguns desafios a serem considerados. A modelagem, a análise e o design
orientado a serviços devem buscar resolver de modo direto a complexidade do
paradigma de orientação a serviços, e indiretamente tratar requisitos de desempenho,
segurança e governança.
É especialmente importante focar nos princípios de orientação a serviços e em
conceitos como granularidade e camadas de serviços. São estes os conceitos-chave
que definem as características desejadas nos serviços desenvolvidos no modo como
são tratados neste livro.
3
Ciclo de vida SOA
Objetivo
O objetivo deste capítulo é apresentar um ciclo de vida para o paradigma de orientação
a serviços. São descritas boas práticas do paradigma, assim como atividades, papéis
e artefatos, destacando-se os modelos de negócio e as especificações de serviços.
Este capítulo descreve um ciclo de vida para SOA baseado em boas práticas do paradigma
de orientação a serviços. Destacam-se os papéis ou atores que desempenham as atividades
e artefatos de entrada e saída das atividades do ciclo de vida.
Conteúdo
3.1 Boas práticas 43
3.2 Ciclo de vida SOA 47
3.3 Modelagem, análise e design 50
3.4 Papéis 50
3.5 Artefatos 54
3.6 Ciclo de vida iterativo 58
3.1 Boas Práticas

As boas práticas identificadas na literatura descritas no Capítulo 2 consistem em
soluções propostas pelos métodos mais relevantes para atender às necessidades de
análise e design de serviços.
Nas seções a seguir, serão descritas as boas práticas que são atendidas pelas
atividades de modelagem, análise e design descritas neste livro.
3.1.1 Abordagem meet-in-the-middle
No desenvolvimento de soluções orientadas a serviços, não se pode seguir totalmente
uma abordagem top-down, levando em conta apenas os requisitos e objetivos do
negócio para a identificação e especificação de serviços. Tampouco deve ser adotada
uma abordagem puramente bottom-up, apenas encapsulando a funcionalidade de
aplicações legadas na forma de serviços. Um método deve, de alguma forma, equili-
brar as duas alternativas, resultando em uma abordagem meet-in-the-middle.
43
A identificação de serviços deve ser guiada pelos requisitos e pela modelagem

de negócio, assim como estar alinhada às suas metas e estratégias de negócio. No
entanto, os serviços identificados a partir do negócio devem ser analisados e revisados
de modo a ajustar-se à realidade dos serviços já existentes na organização e das
aplicações legadas. Desta maneira, obtém-se o reuso de recursos existentes e cria-se
valor a partir do investimento já realizado.
3.1.2 Compatibilidade com Business Process Management

A adoção da arquitetura SOA em uma organização pode trazer maiores benefícios
se realizada em conjunto com a adoção de práticas de BPM (Business Process
Management). Com o surgimento do padrão WS-BPEL, a utilização conjunta de
SOA e de BPM foi viabilizada e potencializada. O WS-BPEL permite a composição
e orquestração de serviços a partir de definições de processos, criadas por analistas
de negócio. Desta maneira, aumenta-se o alinhamento dos serviços desenvolvidos
com as metas e estratégias de negócio.
Um método orientado a serviços deve levar em consideração essa sinergia e in-
corporar técnicas de BPM para a análise e o design de serviços (Papazoglou e Van
Den Heuvel, 2006). Nas atividades de análise e design, dois aspectos do BPM são
aplicáveis: a modelagem de processos e a automação de processos.
A técnica de modelagem de processos pode ser empregada para documentar o
modelo de negócio e seus requisitos, que, por sua vez, serão o ponto de partida para
a identificação de serviços.
Já a automação de processos em uma arquitetura SOA pode ser realizada por meio
da orquestração de serviços. Caso os processos sejam modelados em uma notação
como o BPMN, eles poderão ser convertidos para uma linguagem de orquestração
como WS-BPEL e executados em um servidor de aplicações.
Um método deve viabilizar projetos de BPM com SOA, mas não deve limitar-se
a essa abordagem, permitindo também a realização de projetos de SOA somente.
3.1.3 Reuso de recursos existentes

Um dos princípios fundamentais da orientação a serviços é o reuso. Sendo assim,
um método de análise e design orientado a serviços deve procurar maximizar o rea-
proveitamento de lógica já existente, esteja ela na forma de serviços disponíveis no
portfólio da organização ou na forma de aplicações legadas, que ainda teriam de ser
transformadas em serviços.
Segundo esse requisito, durante o processo de análise e design de uma solução
orientada a serviços, os recursos existentes na organização devem ser analisados
como alternativas para identificação ou realização de serviços.
Um método deve abordar atividades com o intuito de avaliar se há algum serviço
ou sistema legado existente que atenda aos requisitos definidos durante a modelagem
dos processos e serviços.
3 Ciclo de vida SOA 45
3.1.4 Especificação de requisitos não funcionais

Um ponto bastante questionado de implementações de arquitetura SOA é o suporte a
requisitos não funcionais dos serviços, também chamados de requisitos de qualidade
de serviço (QoS – Quality of Service). Nesta área, existe uma série de padrões abertos
sendo desenvolvidos no sentido de especificar o tratamento de requisitos como
segurança, desempenho e transações.
Um método proposto deve buscar formas de abordar requisitos não funcionais,
ou seja, incluir em seu fluxo de trabalho atividades em que esses requisitos sejam
definidos e documentados como parte da especificação de um contrato de serviço.
Para tal, o método pode adotar padrões específicos, como WS-Security, WS-Policy
ou WS-AtomicTransaction.
3.1.5 Diferentes fontes para identificação de serviços

Um método de análise e design orientado a serviços deve oferecer flexibilidade aos
analistas no momento de identificar potenciais serviços necessários para a organiza-
ção, a partir da modelagem de negócio. Como fontes para esta identificação, podem
ser utilizados modelos de processos, descrições de casos de uso de negócio e modelos
de dados para a abordagem top-down e, no caso bottom-up, aplicações legadas e
serviços já existentes que possam ser reusados em uma composição.
3.1.6 Diferentes alternativas para realização de serviços

Assim como no caso da identificação, deve existir flexibilidade para a especificação
de serviços, sendo considerados diversos cenários de realização. Um serviço identi-
ficado pode ser especificado como um novo componente a ser desenvolvido, como
uma composição de serviços existentes, na forma de reuso de um serviço já existente
com potenciais ajustes ou na forma de reuso de lógica de alguma aplicação legada,
que pode ser disponibilizada por um serviço encapsulando ou por meio de alguma
API (Application Programming Interface) ou adaptador.
Um método deve levar em conta os diversos cenários possíveis para realização de
um serviço e analisar aspectos como custo, risco, esforço e ROI, o que permitirá ao
analista que estiver criando a especificação decidir qual abordagem adotar.
3.1.7 Conceito de serviço candidato

De acordo com essa prática, o ciclo de vida de um serviço deve possuir um passo
intermediário entre o momento em que é concebido ou identificado e o momento em
que ele é especificado. Neste passo intermediário, o serviço seria classificado como
candidato. Em um método orientado a serviços, o conjunto de serviços de uma solução
concebidos ou identificados não é necessariamente realizado e especificado em seu
estado original. Por este motivo, ele é considerado candidato até passar por análises
e revisões, que podem resultar em mudanças nas operações, no reagrupamento de
operações e na redefinição do escopo funcional de cada serviço.
3.1.8 Aderência aos princípios de orientação a serviços

Um método de análise e design orientado a serviços deve assegurar que os serviços
desenvolvidos sejam aderentes aos princípios de orientação a serviços, como reusa-
bilidade, interoperabilidade, baixo acoplamento e autonomia. Esta aderência pode
ser obtida inserindo-se no fluxo de trabalho do método pontos de verificação em que
um conjunto de serviços é avaliado em relação aos princípios. Outra maneira seria
por meio de orientações sobre como executar uma determinada atividade levando
em conta os princípios.
3.1.9 Uso de padrões abertos

Caso um método utilize de maneira explícita linguagens e notações específicas
para representar seus artefatos, essas linguagens e artefatos devem adotar padrões
abertos e que sejam independentes de plataforma ou de fornecedor de ferramentas
de implementação.
Exemplos de padrões abertos relacionados a análise e design de serviços são o
WSDL para descrição de interfaces de serviço, o XSD para definição de formato
de dados, o WS-BPEL para orquestração de processos de negócio, o BPMN para
modelagem de processos, a UML para documentar requisitos e arquitetura de software
e os diversos padrões WS-* para uso com a tecnologia Web Services.
3.1.10 Uso de técnicas existentes para implementação

Um método de análise e design deve ser estruturado de maneira tal que os seus produ-
tos finais (as especificações de serviços) possam servir como entrada para atividades
de uma metodologia de implementação já existente e consolidada (Papazoglou e
Van Den Heuvel, 2006), como programação orientada a objetos ou desenvolvimento
baseado em componentes (CBD – Component Based Development).
Para que isso seja possível, é necessário que os serviços sejam especificados
em um nível detalhado o suficiente para a realização de modelagem de classes e de
interfaces de componentes.
3.1.11 Conceito de camadas de serviços

Um método de análise e design deve classificar os serviços especificados em camadas,
de acordo com sua função ou nível de granularidade. As camadas de serviços (Erl,
2005) definem uma maneira de se separar os tipos de lógica contidos em serviços
e de se representar os relacionamentos dos serviços com os processos de negócio e
com as aplicações existentes.
Dependendo da camada a que um serviço pertence ou de seu nível de granularida-
de, um método de análise e design deve levar em consideração aspectos específicos,
como o nível de reusabilidade e presença de lógica de processo.
3.1.12 Abordagem “do zero” ou incremental

Um método de análise e design deve permitir a implementação de serviços a partir
“do zero”, desde o início, baseada em necessidades de negócio. Por outro lado, deve
também permitir a implementação de serviços considerando a existência de serviços na
organização e que possam ter a sua funcionalidade acrescida de forma incremental.
Um método de análise e design deve permitir a implementação de serviços seguin-
do uma abordagem sequencial a partir do levantamento das necessidades de negócio,
semelhante ao processo cascata de desenvolvimento de software, ou uma abordagem
incremental a partir de serviços mais críticos para o negócio, semelhante ao processo
RUP ou ágil de desenvolvimento de software.
3.1.13 Suporte a governança de serviços

Um método de análise e design deve possuir pontos de controle que permitam a uma
organização exercer governança sobre os serviços desenvolvidos. Tal governança ou
controle deve ser inerente a todo o ciclo de vida. Este controle é especialmente neces-
sário durante as fases de análise e design, já que é neste ponto do ciclo de vida que
novos serviços são definidos e especificados e serviços existentes são reusados.
3.2 Ciclo de vida SOA

O desenvolvimento de soluções orientadas a serviços deve ser parte de uma boa
abordagem de desenvolvimento. Uma boa maneira de tratar tais soluções é encará-los
dentro de um ciclo de vida semelhante ao de um produto de software, aqui denomi-
nado Ciclo de Vida SOA.
Podemos considerar que desenvolvimento de soluções orientadas a serviços é cí-
clico, começando pela modelagem de negócio e definição dos requisitos, passando por
análise, design e construção, até ser implantada e gerenciada. Uma vez operacional,
pode-se, a partir da observação do desempenho da solução ou em resposta a novos
requisitos de negócio, retornar à modelagem para promover melhorias ou alterações
à solução orientada a serviços. A ideia do ciclo de vida SOA é possibilitar que uma
solução orientada a serviços seja dinâmica, evoluindo de acordo com as necessidades
de negócio e passando por um processo de melhoria contínua.
O ciclo de vida SOA descrito aqui é parcialmente inspirado em metodologias
como o RUP e a abordagem proposta por Papazoglou (2007), podendo ter suas fases
e atividades mapeadas para disciplinas e tarefas do RUP.
Um ciclo de vida SOA pode ser definido através das fases de modelagem,
análise, design, construção, implantação e gerenciamento, conforme pode ser visto
na Figura 3.1.
3.2.1 Modelagem
O objetivo da fase de modelagem é capturar o estado atual do negócio, suas necessi-
dades e objetivos e traduzir para um modelo de processo de negócio e especificação
Figura 3.1 Fases do ciclo de vida SOA.
de requisitos. Nesta fase, são aplicadas as disciplinas de modelagem de negócio e

requisitos.
A modelagem tem como objetivo modelar a estrutura e a dinâmica da organização
onde será implantada a solução. Esta disciplina visa estabelecer um entendimento
sobre os processos, identificando seus problemas, falhas, necessidades e propondo
melhorias. Para tal, são utilizados modelos de processo para representar a lógica
de negócio a ser suportada pela solução. Como resultado, tem-se um modelo de
processo que representa o estado atual (as-is) e um modelo do estado futuro (to-be),
com as melhorias e alterações.
O propósito da disciplina de requisitos é estabelecer um acordo entre desenvol-
vedores e clientes sobre exatamente o que a solução deverá ser capaz de fazer, isto
é, o escopo da solução. As necessidades e os objetivos dos clientes são levantados
e documentados com detalhes, servindo de base à elaboração de uma proposta de
solução. Os resultados obtidos são descritos na forma de casos de uso e uma lista
de requisitos. Os casos de uso servirão para descrever as interações dos usuários
com a solução, e a lista de requisitos descreve demais necessidades funcionais e não
funcionais que deverão ser atendidas pela solução.
3.2.2 Análise
Durante a fase de análise, são definidos os serviços pertencentes à solução, que devem
ser derivados do modelo de processo de negócio to-be e dos requisitos. Nesta fase,
devem ser identificadas as operações e os serviços candidatos necessários para dar
suporte à solução modelada. É feita então uma análise de gap, para determinar quais
dos serviços candidatos já existem no portfólio e quais serviços podem reaproveitar
recursos existentes. Finalmente, a análise de realização define qual será a estratégia
de implementação dos novos serviços.
3.2.3 Design
Em seguida vem a fase de design, quando os serviços candidatos definidos na análise
são transformados em contratos de serviços e especificações de realização. Uma vez
definidos os contratos dos serviços, ocorre também composição destes em processos
de negócio. O design de soluções orientadas a serviços exige que as interfaces sejam
muito bem definidas e documentadas antes de serem implementadas. Além disso,
deve-se garantir que os serviços especificados possuam características aderentes aos
princípios de orientação a serviços.
3.2.4 Construção
Na fase de construção, é desenvolvida a implementação dos serviços de acordo
com as especificações. Estes serviços podem ser implementados através da criação
de novos serviços a partir do zero, da exposição de aplicações existentes ou da
composição de serviços existentes reusáveis.
Nessa fase, ocorrem também os testes, que têm o intuito de validar se os requisitos
foram satisfeitos e se as implementações entregues estão de acordo com os contratos
e especificações definidas nas fases de análise e design. São realizados testes de
unidade, integrados e não funcionais.
3.2.5 Implantação
Na fase de implantação, os processos e serviços implementados são publicados e
expostos para todos os participantes, incluindo organizações, aplicações e outros
processos. Uma vez que a solução publicada é homologada, ela é colocada em
operação.
3.2.6 Gerenciamento
A fase de gerenciamento inicia-se assim que os serviços e processos são postos em
operação.
Nessa fase, ocorre a monitoração da solução, durante a qual é medido o desempe-
nho dos serviços, com o intuito de garantir qualidade na execução e conformidades
com SLAs (Service Level Agreements) e requisitos não funcionais definidos nos
contratos de serviço.
Métricas de negócio e KPIs (Key Performance Indicators) são aferidos para medir
também o desempenho dos processos e detectar pontos em que pode haver melhora.
Trata-se de um processo contínuo de verificação do atendimento dos requisitos e
objetivos de negócio definidos na modelagem.
Os dados obtidos poderão servir como entrada para uma nova iteração do ciclo de
vida, iniciando um novo projeto de desenvolvimento para evoluir a solução orientada
a serviços.
3.3 Modelagem, análise e design

A modelagem, a análise e o design possuem interações entre si e com outras fases
do ciclo de vida SOA, de maneira análoga a um desenvolvimento de software. Foi
descrito um ciclo de vida SOA genérico mostrando o relacionamento das fases que são
realizadas incrementalmente. Para tornar o desenvolvimento de soluções orientadas a
serviços mais prático, destacam-se as fases de entrada (modelagem) e de saída (de-
sign), conforme destacadas na Figura 3.2 em retângulos escuros. Os retângulos claros
correspondem às demais fases do ciclo de vida SOA, não detalhadas neste livro.
O formato do ciclo de vida SOA é apenas ilustrativo, podendo ser seguido na
abordagem sequencial ou incremental.
Na abordagem sequencial, as atividades definidas em cada fase são realizadas
sequencialmente, como no ciclo cascata de software, até chegar aos serviços im-
plementados e testados. Na abordagem incremental, as atividades são realizadas por
incrementos de serviços, ou seja, cada serviço é construído isoladamente e integrado
gradativamente com outros serviços.
No caso da fase de modelagem, caso uma organização já tenha uma própria poderá
usá-la. No entanto, terá de adaptá-la para obter os artefatos necessários para a fase de
análise. No caso da fase de construção, pode-se aplicar as técnicas de implementação
e testes já existentes de desenvolvimento de software.
Nos próximos capítulos, serão descritas as fases de todo o ciclo de vida SOA,
destacando-se a modelagem, a análise e o design. Para cada fase, são explicitadas as
atividades, os papéis das pessoas que a desempenham e os artefatos usados e gerados
durante a sua execução.
3.4 Papéis
Nesta seção descrevem-se as responsabilidades e habilidades necessárias de cada
papel (ou função) de negócio dentro do ciclo de vida SOA.
3.4.1 Analista de processos
O analista de processos é responsável pela elaboração dos modelos de processo
de negócio que serão automatizados por uma solução orientada a serviços. Este
papel deve possuir conhecimentos sobre levantamento de requisitos, modelagem de
processos e elaboração de casos de uso de negócio.
Figura 3.2 Atividades de modelagem, análise e design no ciclo de vida SOA.
É importante que a pessoa que assuma esse papel possua boa capacidade de
comunicação, tanto oral como escrita, pois ela precisará interagir com representantes
de diversas áreas da organização e precisará documentar claramente as necessidades
e requisitos identificados. É essencial que a pessoa possua conhecimento sobre o
domínio de negócio no qual a solução está inserida. Por exemplo, caso a solução
tenha como objetivo automatizar um processo de contratação de apólice de seguros,
o analista deve possuir conhecimento sobre como funciona uma seguradora.
3.4.2 Analista de serviços
O analista de serviços é responsável pela realização da transição dos artefatos
gerados pela modelagem de negócio para uma solução orientada a serviços. Este
papel exige conhecimentos intermediários de modelagem de processo, de forma

que ele seja capaz de orientar tecnicamente o analista de processos e de interpretar
os modelos criados. Além disso, o analista de serviços deve também possuir a
capacidade de analisar especificações de casos de uso para identificar os serviços
candidatos.
É essencial que o analista de serviços possua conhecimentos sólidos sobre os
princípios de orientação a serviços, de modo a aplicá-los durante a identificação e
análise dos serviços.
Experiência em análise de sistemas e conhecimentos básicos sobre tecnologias
de integração e de realização de serviços são necessários principalmente durante a
análise de gap e a análise de realização, para avaliar o reuso de aplicações legadas.
Boa capacidade de comunicação escrita é desejável, pois será preciso descrever
com clareza e precisão os serviços candidatos propostos.
3.4.3 Arquiteto de serviços
O arquiteto de serviços tem como função principal criar as especificações dos servi-
ços a serem implementados, projetando suas interfaces e comportamento funcional.
Assim como o analista de serviços, o arquiteto de serviços também deve possuir
conhecimentos sólidos sobre os princípios de orientação a serviços, de modo a criar
contratos e especificações aderentes ao paradigma.
O arquiteto de serviços deve possuir larga experiência em análise e especificação
de sistemas e conhecimentos avançados sobre tecnologias de integração e de rea-
lização de serviços (XML, Web Services, REST etc.), para definir a arquitetura de
realização de cada serviço e especificar contratos e realizações de serviços tecnica-
mente interoperáveis e aderentes aos princípios.
Conhecimentos sólidos sobre design patterns SOA também são fundamentais na
elaboração dos contratos e especificações de serviços.
Ter capacidade de elaborar modelos em UML é uma competência desejável
quando a linguagem for adotada para representar realizações de serviços.
3.4.4 Arquiteto corporativo
O arquiteto corporativo é responsável pela governança do portfólio de serviços da
organização, definindo uma arquitetura de referência e padrões a serem seguidos nos
projetos. Este papel pode ser exercido por uma equipe, executando algumas funções
de um Centro de Excelência SOA.
São responsabilidades do arquiteto corporativo:
● definir padrões técnicos de design de esquemas e contratos de serviços;
● definir padrões técnicos de design de realização de serviços;
● definir arquitetura de referência, com orientações para reuso e integração;
● validar que os serviços pertencentes ao portfólio sejam aderentes aos princípios
de orientação a serviços;
● validar que os serviços candidatos propostos por analistas e os serviços especifi-

cados por arquitetos de serviços estejam de acordo com os padrões definidos, em
termos de escopo funcional, contrato e realização;
● validar que os serviços sejam implementados de acordo com seus contratos e es-
pecificações.
Devem possuir conhecimentos sólidos nos princípios de orientação a serviços,
governança de serviços, tecnologias de integração e arquitetura de aplicações e design
patterns SOA.
3.4.5 Gerente de projeto

O gerente de projeto é responsável por conduzir o projeto, controlando aspectos
como escopo, prazo, custo e riscos.
Deve possuir conhecimentos em gerência de projetos e experiência em projetos
de desenvolvimento de software, sendo capaz de planejar e conduzir a execução das
atividades realizadas pela equipe. É responsabilidade do gerente de projeto definir
prioridades, de forma que o trabalho a ser realizado seja adequado às limitações de
prazo e custo do projeto.
Boa capacidade de comunicação oral e escrita, negociação, liderança e resolução
de problemas são competências importantes ao gerente de projeto ao exercer suas
funções.
Além disso, são desejáveis conhecimentos básicos sobre orientação a serviços e
tecnologias relacionadas, para que o gerente de projeto consiga dialogar de forma
clara com representantes dos papéis mais técnicos.
3.4.6 Desenvolvedor
O desenvolvedor é responsável pela construção dos serviços especificados. O perfil
necessário é o mesmo de um método de desenvolvimento de software tradicional,
sendo importante ter conhecimentos sobre os princípios de orientação a serviços e
tecnologias de integração e de realização de serviços.
Dependendo do tamanho da equipe e da solução orientada a serviços, pode haver
a separação dos desenvolvedores em perfis especializados em partes específicas da
solução, como desenvolvedores de mediações, desenvolvedores de orquestração de
processo e desenvolvedores Web para a camada de apresentação.
Além de sólidos conhecimentos das tecnologias empregadas na implementação,
os desenvolvedores devem ser capazes de interpretar especificações de serviços,
especificações de casos de uso e modelos UML, quando estes forem utilizados.
3.4.7 Testador
O testador é responsável pelos testes dos serviços especificados. O perfil neces-
sário para este papel é o mesmo de um método de desenvolvimento de software
tradicional, sendo importante ter conhecimentos de orientação a serviços e tecnologias
de integração.
3.4.8 Administrador de serviços
O administrador de serviços é responsável por implantar os serviços em produção
e mantê-los operacionais, monitorando seu desempenho e disponibilidade e as-
segurando-se de que a infraestrutura está bem dimensionada.
3.4.9 Gestor de processos

O gestor de processos geralmente é um gerente, coordenador ou diretor que é res-
ponsável por um determinado processo de negócio ou por todos os processos de
negócio de uma área ou departamento da organização. É o gestor de processos quem
demanda um projeto de automação ou melhoria de processo.
3.4.10 Ator de processos
O ator de processos é um papel que, no contexto do ciclo de vida SOA, representa
todos os colaboradores, funcionários, clientes e parceiros da organização que es-
tão envolvidos na execução de um processo de negócio, seja executando tarefas,
fornecendo ou recebendo informações.
3.5 Artefatos
Nesta seção serão descritos alguns artefatos gerados durante a realização das ativi-
dades do ciclo de vida SOA.
3.5.1 Modelo de processo

O modelo de processo as-is e o modelo de processo to-be correspondem, res-
pectivamente, à representação do estado atual do negócio e dos requisitos da solução
em uma notação como o BPMN.
A Figura 3.3 apresenta um exemplo de um modelo de processo de venda de
produtos.
Esse modelo de processo está representado por um diagrama na notação BPMN.
O processo é representado por um conjunto de participantes (entidades, áreas ou
papéis de negócio) que devem realizar determinadas atividades (retângulo com
cantos arredondados). Estes participantes e atividades estão representados em um
retângulo (pool) identificados à esquerda com o nome do participante e à direita por
um conjunto de atividades em notação específica. O início e o fim de atividades de
um participante são representados por eventos (círculos) distintos. Uma atividade está
ligada à outra por uma sequência de fluxos (linha cheia com seta). Uma atividade pode
se comunicar com outra atividade de outro participante (pools diferentes) através de
fluxo de mensagens (linha tracejada sem seta).
A notação BPMN é muito intuitiva, pois se assemelha ao tradicional fluxo-
grama.
No exemplo da Figura 3, tem-se três participantes: cliente, atendente e expedição.
O processo de venda de produtos é iniciado por um pedido enviado pelo cliente que
Figura 3.3 Exemplo de modelo de processo – venda de produtos.
é recebido pelo atendente. Este, por sua vez, verifica os dados do pedido, e, se es-
tiverem completos, verifica se o produto existe no estoque. Caso não exista, comunica
o cliente. Se existe, o atendente gera a fatura do pedido. A fatura deve ser paga pelo
cliente e, em seguida, a área de expedição prepara o produto para o envio ao cliente.
Por fim, o cliente recebe o produto.
3.5.2 Especificação de processo

A especificação de processo é um documento que pode ser elaborado para com-
plementar o modelo de processos, provendo descrições textuais detalhadas de cada
tarefa, dos dados, papéis, recursos e pontos de decisão do fluxo de trabalho.
Uma descrição de tarefa pode conter as seguintes informações:
● objetivo da tarefa;
● etapas de execução da tarefa;
● dados e informações utilizadas como entrada;
● dados e informações geradas como saída.
A descrição de um ponto de decisão pode ser expressa por uma expressão lógica,
verbalizada em linguagem natural.
Por exemplo, para o ponto de decisão representado na Figura 3.4, a descrição
poderia ser a seguinte:
Figura 3.4 Exemplo de ponto de decisão.
Se o valor do financiamento for menor que R$ 1.000,00, a solicitação é aprovada automatica-

mente. Se o valor do financiamento for maior que R$ 1.000,00, a solicitação deve passar pela
aprovação de um analista de crédito.
3.5.3 Modelo de serviços

O modelo de serviços é utilizado para documentar o processo de análise orientada a
serviços, que dá origem a um conjunto de serviços identificados a partir de um modelo
de negócio, na forma de processo ou caso de uso de negócio. Ele é preenchido ao
longo das seguintes atividades:
● identificação de serviços candidatos;
● análise de gap;
● análise de realização.
A Figura 3.5 apresenta os principais itens contidos no modelo de serviços, abs-

tratamente, e o relacionamento entre eles e as atividades que os definem. Ou seja, a
atividade “Identificação de Serviços Candidatos” define as “Operações Candidatas”
e os “Serviços Candidatos”, a atividade “Análise de Gap” define os “Cenários de
Reuso” e as “Alternativas de Realização” e a atividade “Análise de Realização” define
as “Decisões de Realização”.
3.5.4 Contrato de serviço
O contrato de serviço, conforme descrito no Capítulo 2, é composto pela definição
da interface técnica do serviço, definições das mensagens do serviço e políticas
que definem restrições e requisitos não funcionais, conforme podem ser vistas
na Figura 3.6. Complementando estes artefatos técnicos, pode ser elaborado um
Figura 3.5 Modelo de serviços.
Figura 3.6 Contrato de serviço.
documento em linguagem natural descrevendo semanticamente a lógica executada

pelas operações do serviço, o significado dos campos das mensagens do serviço e o
acordo de serviço estabelecido entre provedor e consumidor de serviço (SLA).
3.5.5 Especificação de serviço

A especificação de serviço fornece a especificação estrutural e comportamental de
um serviço. Esta especificação estabelece um contrato entre provedor e consumidor
do serviço, além de servir como documentação de referência para o desenvolvedor
responsável por implementar o serviço. Contém a descrição da interface do serviço,
a definição das mensagens de entrada e saída, a especificação do comportamento de
cada operação e os requisitos não funcionais envolvidos, além de indicar a camada
a que pertence o serviço.
3.6 Ciclo de vida iterativo

Principalmente em organizações que adotam o RUP, é comum a utilização de uma
abordagem iterativa para o processo de desenvolvimento. No ciclo de vida de soluções
orientadas a serviços, as fases de modelagem, análise e design foram concebidas de
forma a poderem ser executadas em várias iterações antes de passar para a seguinte.
Essa abordagem pode ser utilizada para implementação de diversos processos de
negócio dentro do mesmo projeto. Após a fase de modelagem, para cada processo
de negócio, executa-se uma iteração da fase de análise para se chegar a um conjunto
de serviços (descritos no modelo de serviços). A cada iteração de análise, novos
serviços são identificados e analisados, adicionando e modificando os serviços
previamente definidos no modelo de serviços. Após todas as iterações de análise,
chega-se a um conjunto de serviços coeso capaz de suportar todos os processos de
negócio analisados.
A partir daí, a fase de design também pode ser executada de forma iterativa, sendo
que, a cada iteração, um conjunto de serviços é especificado e verificado.
Essa abordagem pode ser adotada também para se realizar a modelagem, a análise
e o design de todo o portfólio de serviços da organização de uma só vez. Ao invés
de se ter cada projeto contribuindo com alguns serviços ao portfólio, pode-se, em
uma única iniciativa, analisar todos os processos de negócio e casos de uso de uma
organização e aplicar as fases de maneira iterativa de todo o portfólio de serviços da
organização. Neste caso, não é necessário que todos os processos de negócio sejam
automatizados em um único projeto, e nem todos de uma vez. Assim, nem todos
os serviços precisam ser implementados, caso os processos que necessitem deles
não estejam automatizados. Mas o intuito desta abordagem é já possuir definido
um modelo do portfólio de serviços. Desta forma, a cada projeto de automação de
processo, minimiza-se a necessidade de se alterar os serviços existentes e criar novas
versões, uma vez que os serviços já serão concebidos de maneira alinhada a todos
os processos.
3.7 Considerações do capítulo

Neste capítulo é importante notar que modelagem, análise e design seguem boas
práticas identificadas em métodos orientados a serviços encontrados na literatura
recente.
Para um melhor aproveitamento das boas práticas, elas foram organizadas em um
ciclo de vida semelhante ao desenvolvimento de software, que é mais familiar aos
desenvolvedores.
Para uniformizar as atividades, são descritos papéis que são necessários para
melhor divisão das atividades e artefatos, a fim de melhorar a comunicação entre os
envolvidos.
Os próximos capítulos detalharão as fases de modelagem, análise e design que
resultam em contrato de serviço e especificação de serviço a ser desenvolvido. De ma-
neira sucinta as fases de construção, implantação e gerenciamento serão descritas.
4
Modelagem
Objetivo
O objetivo deste capítulo é apresentar a fase de modelagem, onde os modelos de proces-
sos de negócio são obtidos. Estes modelos são essenciais para especificar os requisitos de
serviços.
A fase de modelagem ocorre antes das atividades da fase de análise. Nessa fase, busca-se
um entendimento sobre as necessidades de negócio e levantam-se os seus requisitos. As
atividades de modelagem são executadas por analistas de processos ou da área de processos
da organização.
A Figura 4.1 apresenta as atividades de modelagem de processo as-is, modelagem de processo
to-be e especificação de requisitos da fase de modelagem, descritas a seguir.
Conteúdo
4.1 Modelagem de processo as-is 59
4.2 Modelagem de processo to-be 64
4.3 Especificação de requisitos 70
4.1 Modelagem de Processo as-is

Papel: analista de processos
Artefatos utilizados: necessidades de negócio
Artefatos gerados: modelo de processo as-is
Na modelagem de processo as-is, conforme apresentada na Figura 4.2, é levantado
o estado atual dos processos de negócio envolvidos no projeto, baseado nas necessi-
dades de negócio. Como resultado desta atividade, o analista de processos produzirá
um modelo de processo representando o estado do negócio antes do projeto da solução
59
Figura 4.1 Atividades da fase de modelagem.
Figura 4.2 Modelagem de processo as-is.
Observação:
Esta seção não tem como propósito ser um guia completo de modelagem e otimização de proces-
sos, mas apenas fornecer orientações sobre como processos devem ser modelados considerando
sua automação por uma solução orientada a serviços.
Para que seja possível a identificação de serviços, o modelo de processo deve

conter pelo menos as seguintes informações:
● diagrama representando o fluxo do processo (tarefas, pontos de decisão, loops);
● atores ou papéis que executam tarefas do processo;
● dados ou objetos de negócio envolvidos no processo (definição de objetos e
campos utilizados durante a execução do processo);

● descrição de cada tarefa (detalhamento das ações que são executadas durante a
tarefa, dados de entrada e saída da tarefa);

● detalhamento dos pontos de decisão (condições que determinam qual fluxo deve
ser seguido).
4 Modelagem 61
Na modelagem de processo as-is, o detalhamento do modelo de processo pode ser

escrito em linguagem natural e não estruturada, não necessitando ater-se a aspectos
técnicos de automação do processo.
Para representar as informações levantadas, o analista de processos deve elaborar
um modelo de processo. O modelo pode ser representado por um fluxograma, pre-
ferencialmente utilizando uma notação padrão de processo como BPMN, que pode
ser convertida diretamente para a linguagem WS-BPEL por diversas ferramentas
existentes no mercado.
O analista de processos pode acompanhar os seguintes passos para elaborar o
modelo de processo as-is.
4.1.1 Entrevistar atores do processo

Identifique as pessoas envolvidas no processo, como usuários, gestores e clientes, que
podem ter diferentes cargos e funções e pertencer a diferentes áreas da organização.
Uma vez feita esta identificação, o analista de processos entrevista representantes
de cada função, a fim de obter informações sobre como o processo é executado
atualmente e quais papéis e responsabilidades cada pessoa assume no contexto do
processo.
Nas entrevistas, é importante também captar impressões subjetivas dos diversos
envolvidos, focando em identificar problemas ou pontos de ineficiência no processo
a partir de diversas perspectivas, desde o usuário até o gestor. O objetivo é detectar
gargalos, redundâncias, falhas no processo e pontos que podem ser melhorados.
Além disso, devem ser levantadas métricas e dados quantitativos relacionados ao
desempenho do processo, como tempo médio de duração do processo e de atividades
específicas, custo do processo ou número de execuções realizadas por dia ou por mês.
A partir das entrevistas, é possível identificar necessidades e metas de negócio,
geralmente relacionadas às métricas quantitativas. Alguns exemplos de metas de
negócio são redução de custos, redução de tempo de atendimento ou aumento de re-
ceita gerada.
Dessa maneira, através das entrevistas, devem ser levantadas as seguintes in-
formações:
● informações sobre como o processo é executado;
● problemas e pontos de falha do processo;
● necessidades e metas de negócio associadas ao processo;
● métricas e indicadores de desempenho do processo.
Tais informações, além de servirem de insumo para a elaboração do modelo de
processo as-is, poderão ser utilizadas nas atividades de modelagem de processo to-be
e especificação de requisitos.
4.1.2 Identificar e descrever tarefas

A partir das entrevistas, o analista de processos deve identificar quais tarefas os
participantes do processo executam ao exercerem suas funções. Para representar
o fluxo de tarefas do processo, pode ser elaborado um modelo de processo, re-

presentado por um diagrama de processo em notação BPMN (Business Process
Model Notation) ou por um diagrama de transição de estados da UML (Unified
Modeling Language).
Descreva as tarefas que compõem o fluxo de trabalho do processo de negócio. As
tarefas são as ações executadas pelos envolvidos no processo, por exemplo: “Cadas-
trar Cliente”, “Verificar Crédito” etc.
4.1.3 Identificar e descrever dados

Identifique e descreva os dados que são utilizados durante a execução das tarefas
do processo. Para executar uma determinada tarefa, um ator pode necessitar de
um conjunto de dados de entrada (por exemplo, dados do cliente) e, por sua vez,
pode gerar um conjunto de dados de saída (por exemplo, cadastro do cliente) como
resultado. Ao longo do fluxo de trabalho do processo, os dados podem trafegar de
uma tarefa para outra.
Os dados de uma tarefa podem ser identificados a partir das interações entre os
atores do processo, descobrindo que tipos de informações eles trocam entre si ao
longo do fluxo de trabalho.
4.1.4 Identificar métricas

Identifique por meio de relatórios, registros e evidências de execução de tarefas,
estatísticas e dados quantitativos que permitam mensurar o desempenho e o custo
do processo. Na falta de fontes de dados confiáveis, pode-se recorrer às impres-
sões dos próprios atores do processo para se estimar os valores das métricas de
processo.
Caso seja um processo já automatizado por uma solução orientada a serviços,
esses dados podem ser obtidos por meio da ferramenta de monitoração de atividade
de negócio (BAM).
Alguns exemplos de métricas de processo são:
● tempo de duração de cada tarefa por recurso (cargos, funções, indivíduos, sistemas
e parceiros);
● tempo de espera para execução de cada tarefa;
● número de execuções do processo por hora, por dia ou por mês;
● número de execuções do processo ocorrendo paralelamente;
● custos para execução de uma tarefa (por utilização de algum recurso ou pelo
custo-hora da pessoa envolvida na tarefa);

● receita gerada pela execução de uma tarefa.
É importante entender nesse ponto quais são as métricas críticas para se aferir o
desempenho do processo, na percepção do usuário ou do negócio. Por exemplo, em
um processo de vendas, a receita gerada é uma métrica importante, enquanto em um
processo de atendimento a clientes o tempo de duração torna-se mais crítico.
4 Modelagem 63
Dicas:
● É importante manter consistência na nomenclatura das tarefas e entidades relacionadas. Crie
um vocabulário padronizado e aplique-o no modelo de processo e nas descrições textuais
das tarefas.
● Nesse ponto, o processo deve representar a lógica de negócio e pode ser mantido com nível
alto de granularidade. As tarefas devem representar funções atômicas no nível de negócio. O
detalhamento em etapas técnicas de menor granularidade será feito nas próximas atividades
do ciclo de vida.
● Nomes de tarefas geralmente iniciam-se com verbo, como “analisar crédito” e “cadastrar
aluno”.
Exemplo
Vamos ilustrar a fase de modelagem tomando como exemplo o processo de negócio consulta
médica da clínica médica MEDSOA. Trata-se do processo iniciado quando um paciente agenda
uma consulta na clínica MEDSOA, passando pela realização da consulta até o pagamento,
realizado pelo próprio paciente ou por um convênio médico. A clínica MEDSOA não conta com
nenhuma solução orientada a serviços para automatizar seus processos, possuindo apenas um
aplicativo pacote de CRM para cadastro de pacientes.
Visando automatizar o processo, o analista de processos da clínica MEDSOA modela o
processo atual (as-is) que é executado para a realização de consultas. Para elaborar o modelo de
processo as-is, ele realiza entrevistas com os atendentes da recepção da clínica, com os médicos
e com os funcionários do setor administrativo (os atores do processo), perguntando sobre como
cada um deles executa suas atividades durante o atendimento aos pacientes. Como resultado
destas entrevistas, o analista de processos descobre o fluxo de atividades, a sequência em que
elas são executadas e a lógica envolvida no fluxo.
O processo inicia-se com o paciente entrando em contato por telefone ou pessoalmente
para solicitar uma consulta com um dos médicos da clínica. O atendente da clínica agenda a
consulta com o médico escolhido na data e na hora escolhidas pelo paciente. Na data e na hora
da consulta, o paciente comparece à clínica e é atendido pelo médico. Durante a consulta, o
médico obtém o prontuário do paciente e atualiza as informações de acordo com as observações
provenientes da consulta e eventuais exames e procedimentos. Se for o caso, o médico pode
prescrever um ou mais medicamentos ao paciente e solicitar que ele realize exames diagnósticos
e retorne para uma nova consulta. Após a finalização da consulta, caso o paciente não possua
um convênio médico, deve realizar o pagamento em cheque, dinheiro ou cartão. Caso possua,
o setor administrativo deve gerar uma fatura para ele. Se o médico tiver solicitado retorno, o
paciente deve agendar uma nova consulta, iniciando uma nova iteração do processo. Caso con-
trário, o processo é encerrado.
Baseado nessas informações, o analista de processos elabora o diagrama de processo em
notação BPMN do modelo de processo as-is de consulta médica, conforme a Figura 4.3. Temos
quatro participantes: administração, atendente, paciente e médico.
Além do diagrama de processo, o analista de processos ainda descreve textualmente os
detalhes de cada tarefa, especificando as etapas executadas pelos atores em cada uma delas.
Por exemplo, o detalhamento da tarefa “Agendar Consulta”.
1. Cliente informa o médico de preferência.

2. Atendente consulta a agenda do médico e informa as datas e horários disponíveis.
3. Cliente informa a data e o horário escolhido.
4. Atendente registra na agenda a consulta com o Paciente na data e no horário escolhido.
O modelo de processo as-is elaborado servirá como base para o projeto de automação
do processo de consulta médica.
Figura 4.3 Modelo de processo as-is de consulta médica da clínica MEDSOA.
4.2 Modelagem de processo to-be

Papéis: analista de processos, analista de serviços.
Artefatos utilizados: necessidades de negócio, modelo de processo as-is.
Artefatos gerados: modelo de processo to-be.
Enquanto o modelo de processo as-is representa o estado atual de um processo
de negócio, o objetivo do modelo de processo to-be é representar o estado desejado
do processo, ou seja, descreve os requisitos funcionais a serem atendidos por um
sistema ou solução orientada a serviços.
Na modelagem de processo to-be, conforme pode ser vista na Figura 4.4, o analista
de processos pode realizar avaliações e simulações e propor modificações ao processo
com o intuito de promover melhorias de desempenho ou reduzir custos. Tais modifica-
ções do processo podem ser mudanças em sua própria estrutura (fluxo de trabalho) ou
propostas de automação de parte ou de todo o processo. Como produto desta atividade,
é elaborado um novo modelo de processo alterado com relação ao as-is.
● Deve-se realizar uma análise para detectar gargalos e pontos falhos. Exemplos:
Tarefas que retêm o avanço do processo, por serem complexas ou demoradas, por
indisponibilidade de recursos para serem executadas ou por excesso de trabalho
manual repetitivo.
● Deve-se verificar dados não confiáveis gerados por tarefas (obtidos de fontes
imprecisas, informados manualmente).

4 Modelagem 65
Figura 4.4 Modelagem de processo to-be.
Para resolver tais pontos, além de alterar o fluxo e as tarefas, pode-se propor a
automação de tarefas utilizando serviços. Este tipo de abordagem é o mais indicado
para tarefas manuais demoradas, ou aquelas cujos dados de saída não são confiáveis
por serem informados manualmente.
Os modelos podem ser representados utilizando-se uma notação de processo,
como BPMN, que pode ser convertida diretamente para a linguagem WS-BPEL por
diversas ferramentas existentes no mercado.
A modelagem de processo to-be deve definir e documentar como um processo
será executado dentro de uma organização, identificando papéis, responsabilidades,
atividades e ordens de execução. Feita esta modelagem, é possível realizar uma
análise de negócios e identificar possíveis ganhos e alterações com a execução deste
processo.
Pelo fato de descrever a automação do processo, o modelo to-be deve ser deta-
lhado até um nível mais técnico. Na especificação de processo associada devem ser
descritos os detalhes de execução de cada tarefa.
O analista de processos pode acompanhar os seguintes passos para elaborar o
modelo de processo to-be.
4.2.1 Definir melhorias
A partir do modelo de processo as-is, o analista de processos deve propor melhorias
no processo de modo a solucionar os problemas e atender às necessidades e metas
de negócio levantadas nas entrevistas com os envolvidos. Definir as melhorias que
devem ser implementadas no processo de negócio de acordo com as solicitações dos
usuários, resultados de simulações e regras de negócio.
● automação de tarefas humanas que envolvem trabalhos repetitivos;
● automação de tarefas sujeitas a erros humanos ou fraudes;
● adição de revisões e verificações em pontos sujeitos a erros humanos ou fraudes;
● automação de verificações e validações de regras de negócio;
● aumento no número de recursos para execução de tarefas de longa duração.
4.2.2 Simular processo
A simulação de processos de negócio permite ao analista de processos validar se
as alterações propostas trarão os resultados esperados. Por meio da simulação, é
possível ter uma visão dos ganhos de desempenho do processo antes mesmo de sua
implementação. O uso de ferramentas de simulação auxilia o analista de processos
na tomada de decisões de melhorias, provendo relatórios gerenciais e comparativos
entre cenários.
Com uma modelagem de processo de negócio bem-feita, é possível:
● identificar os gargalos;
● estimar custos e durações;
● identificar os impactos antes da implementação de mudanças em um processo;
● criar novos cenários com a verificação do impacto no desempenho.
Baseado nos resultados das simulações de alguns cenários, o analista de processos
pode definir novos cenários para o processo, por meio de ajustes. Alguns dos possíveis
ajustes são:
● adicionar mais pessoas ou recursos para realizar uma tarefa, medindo o impacto
em termos de duração, custo ou receita;
● automatizar uma tarefa, por exemplo, passando de uma consulta manual para
uma consulta automatizada e verificando se o ganho obtido justifica o custo da

automação;
● eliminar tarefas duplicadas ou que forem julgadas desnecessárias, aferindo o
impacto ao processo;
● transferir a responsabilidade por uma tarefa de um papel para outro.
4.2.3 Detalhar tarefas do processo

Cada tarefa do processo de negócio to-be deve possuir uma descrição textual que
detalha as etapas da execução da atividade e a lógica envolvida. Esta descrição pode
ser um texto corrido ou pode ser estruturada em uma sequência de passos (como
4 Modelagem 67
em uma especificação de caso de uso) ou em um conjunto de frases de requisitos.

Uma forma estruturada facilita a identificação de serviços e a manutenção da ras-
treabilidade entre operações de serviço e processos-pai.
A seguir são apresentados exemplos de formas de descrição das atividades em
texto corrido, sequência de passos como uma especificação de caso de uso e em
frases de requisitos da atividade abrir pedido do modelo de processo de negócio
(Figura 3.3).
Descrição textual: o atendente, ao receber um pedido do cliente, deve primeiro definir o número
do pedido para poder rastrear o produto ao longo do processo de venda. Após definir o número
do pedido, deve verificar se o cliente é cadastrado na empresa, caso contrário, deve solicitar
os dados do cliente. Em seguida, deve verificar se os dados do pedido estão completos, quanto
ao código do produto, à descrição e à quantidade.
Sequência de passos:
1. Cliente envia pedido.
2. Atendente recebe pedido.
3. Atendente define um número do pedido.
4. Atendente verifica se cliente é cadastrado, caso contrário, solicita dados do cliente.
5. Atendente verifica se dados do pedido estão completos.
Frases de requisitos:
● O cliente deve enviar pedido.
● O atendente deve receber o pedido.
● O atendente deve definir número do pedido.
● O atendente deve verificar se cliente é cadastrado, caso contrário, deve solicitar dados do
cliente.
● O atendente deve verificar se os dados do pedido estão completos.
4.2.4 Modelar processo para implementação

Quando um processo de negócio é modelado, algumas de suas características devem
ser ajustadas para que seja possível sua implementação em uma plataforma BPMS.
Caso esses ajustes não sejam feitos, pode ser gerado um desalinhamento entre o
processo modelado pelo analista de processos e o processo executado pela solução
orientada a serviços e implementado nas fases subsequentes.
O analista de serviços pode ser envolvido nessa atividade, suportando o analista de
processos com conhecimentos sobre os serviços existentes que poderiam ser reusados
e sobre que tipo de automação é suportada pela solução orientada a serviços e pelas
ferramentas disponíveis. Este apoio do analista de serviços é importante para garantir
que as propostas de automação definidas pelo analista de processos sejam viáveis
tecnicamente e estejam de acordo com os serviços existentes.
O analista de serviços pode também, acessando um registro de serviços, buscar

serviços existentes e sugerir a utilização deles na automação de tarefas. Entretanto,
neste ponto do ciclo de vida, esta escolha de serviços tem caráter apenas de sugestão
(serviços candidatos). A definição sobre os serviços que serão efetivamente utilizados
na automação do processo ocorrerá durante a fase de análise.
Dica:
O modelo de processo to-be deve possuir um detalhamento técnico maior, podendo contar
com tarefas de menor granularidade ou com detalhamento de uma tarefa em etapas de baixa
granularidade.
Exemplo:
Dando continuidade ao processo de consulta médica da clínica MEDSOA, o analista de pro-
cessos parte para a modelagem de processo “to-be”. Nesta atividade, o analista de processos
deve elaborar uma nova versão do modelo de processo, incorporando melhorias e prevendo
a automação do processo. A clínica MEDSOA visa implementar uma nova versão do processo
automatizada através de um BPMS e serviços compostos.
O analista de processos, então, modifica o modelo de processo, subdividindo-o em três
subprocessos: agendamento, atendimento e pagamento. Além disso, o analista de processos
promoveu automação ao processo, acrescentando tarefas realizadas pelo pool “sistema”.
Durante o agendamento (representado em BPMN na Figura 4.5), foram adicionadas tarefas
sistêmicas para facilitar o trabalho do atendente, como o acesso ao cadastro de pacientes e às
agendas dos médicos.
Para facilitar o trabalho do médico durante o atendimento (Figura 4.6), foram acrescentadas
tarefas sistêmicas na manipulação do prontuário do paciente (agora eletrônico) e na geração
Figura 4.5 Modelo de processo to-be – subprocesso agendamento.

4 Modelagem 69
Figura 4.6 Modelo de processo to-be – Subprocesso atendimento.
de prescrições. Foi acrescentada também uma tarefa automatizada de envio de notificação via
SMS ou e-mail ao paciente um dia antes da consulta, para lembrá-lo de comparecer à clínica,
visando minimizar o número de atrasos e faltas.
Já no pagamento (Figura 4.7), no caso em que o paciente utiliza um convênio médico
em vez de realizar o pagamento direto, foi automatizada a tarefa de geração da fatura para o
convênio.
Além de elaborar os diagramas de processo, o analista de processos ainda deve detalhar as
tarefas, especificando dados de entrada e saída, além de descrever a lógica executada em cada
uma delas, passo a passo.
No exemplo a seguir, é ilustrado o detalhamento da tarefa “Prescrever Medicamentos e
Exames” do subprocesso atendimento.
Objetivo da tarefa: baseado no diagnóstico, o médico utiliza o sistema para gerar uma pres-
crição de medicamentos. Caso ainda sejam necessários exames, o médico gera através do
sistema uma prescrição de exames.
Dados de entrada: nomes dos medicamentos, instruções de administração dos medicamentos,
nomes dos exames.
Dados de saída: prescrição de medicamentos, prescrição de exames.
Detalhamento da tarefa: o médico acessa no sistema a função de “Geração de Prescrição”.
O médico busca e seleciona o medicamento desejado. O sistema adiciona à prescrição as
seguintes informações: nome comercial do medicamento, nome do princípio ativo, frequência
de administração, forma de administração, dose ou quantidade. Para prescrever um exame,
o médico busca e seleciona o exame desejado. O sistema adiciona à prescrição as seguintes
informações: nome do exame, instruções de preparação para o exame. Após adicionados
todos os medicamentos e exames, o médico imprime uma prescrição de medicamentos e
uma prescrição de exames e entrega-as ao paciente.
Figura 4.7 Modelo de processo to-be – Subprocesso pagamento.
4.3 Especificação de Requisitos

Papel: analista de processos
Artefatos utilizados: necessidades de negócio
Artefatos gerados: especificação de requisitos (casos de uso de negócio, regras
de negócio, requisitos não funcionais)
A atividade de especificação de requisitos, conforme apresentada na Figura 4.8,
ocorre paralelamente às atividades de modelagem de processo as-is e to-be. Du-
rante as entrevistas e levantamentos da modelagem as-is, o analista de processos
deve identificar também os objetivos, necessidades e problemas do negócio, isto é,
responder à pergunta: o que se busca melhorar ou solucionar com a automação do
processo?
Já durante a modelagem de processo to-be, conforme o modelo é elaborado, o
analista de processos tem uma visão mais clara de como o processo de negócio deve
se comportar para suportar as metas de negócio e, assim, formular requisitos para
descrever este comportamento.
A ideia da especificação de requisitos é complementar o modelo de processo
to-be gerado com informações sobre as funções que a solução orientada a serviços
deverá executar e como a solução deverá se comportar. Os requisitos provêm
um detalhamento adicional sobre a solução como um todo e servem de base
para atividades como identificação de serviços candidatos e especificação de
serviços.
4 Modelagem 71
Figura 4.8 Especificação de requisitos.
4.3.1 Descrever casos de uso

Casos de uso de negócio podem ser elaborados para descrever a interação dos atores
do processo com o “sistema”, representado pela solução orientada a serviços. Estes
casos de uso, além de potenciais fontes para identificação de serviços candidatos,
servirão como especificação para a implementação da camada de apresentação da
solução.
No desenvolvimento de soluções orientadas a serviços, os casos de uso têm como
objetivo complementar o modelo de processo to-be, provendo uma descrição es
truturada da interação entre um ator de um processo de negócio e a solução orientada
a serviços que automatiza o processo. Um caso de uso pode descrever a interação que
um usuário executa dentro do escopo de uma tarefa do processo ou pode descrever
a interação entre o usuário e a solução ao longo de diversas tarefas.
Por exemplo, na Figura 4.9, o caso de uso 1 descreve a interação do usuário com
a solução orientada a serviço durante a execução da tarefa A, enquanto o caso de
uso 2 descreve a sequência de eventos da interação do usuário durante a Tarefa B e
a Tarefa C.
4.3.2 Descrever regras de negócio

Além dos requisitos não funcionais, o analista de processos pode identificar regras
de negócio que afetam a lógica executada no processo.
Figura 4.9 Casos de uso de um processo.
Uma prática comum na descrição de atividades de processos (utilizada também

na descrição de casos de uso) é a externalização ou abstração de regras de negócio.
Regras de negócio, sejam específicas da empresa ou regulamentações às quais a
organização deve aderir, podem ser descritas em documentos separados das descrições
de processos (ou casos de uso). Neste caso, as descrições de processos devem fazer
referências aos documentos das regras de negócio.
Um exemplo de externalização de regra de negócio é “se o cliente não é cadas-
trado, solicitar dados ao cliente”.
4.3.3 Descrever requisitos não funcionais

A partir de metas de alto nível, podem ser formulados requisitos não funcionais.
Por exemplo, em um processo de atendimento de chamados, o gestor do pro-
cesso pode ter a meta de negócio “melhorar o atendimento”. Após a modelagem
do processo e detalhamento da meta, pode ser especificado o requisito “o tem-
po de duração da abertura do chamado até sua resolução não pode ultrapassar
4 horas”.
Os requisitos não funcionais especificados durante a modelagem estarão relacio-
nados principalmente às métricas do processo.
Exemplo:
Complementando o modelo de processo “to-be”, o analista de processos elabora algumas
especificações de casos de uso, descrevendo as interações dos atores com a camada de
apresentação da solução orientada a serviços. Os seguintes casos de uso são descritos:
agendamento de consulta – este caso de uso representa a interação do atendente com o
sistema, quando o paciente solicita uma consulta; obter prontuário – descreve a interação
do médico com o sistema, ao buscar o prontuário de um paciente;atualizar prontuário –
descreve a interação do médico com o sistema, ao atualizar o prontuário de um paciente;
prescrever medicamentos e exames – descreve a interação do médico com o sistema,
buscando medicamentos e exames e inserindo orientações para gerar uma prescrição para
o paciente.
A seguir, é exemplificada a descrição do caso de uso que detalha uma parte do subprocesso
agendamento. O escopo do caso de uso pode ser visualizado na Figura 4.10.
4 Modelagem 73
Figura 4.10 Escopo do caso de uso.
Objetivo: registrar um paciente para uma consulta com um dos médicos da clínica, em data
e horário de preferência do paciente.
Fluxo básico de eventos:
1. Por telefone, o paciente entra em contato com a clínica e solicita consulta com um
médico, identificando-o pelo nome.
2. Atendente acessa o Sistema e seleciona a opção de menu “Agendar Consulta”.
3. Sistema exibe uma lista com os médicos disponíveis e permite que se realize uma busca
pelo nome do médico.
4. Atendente seleciona o médico indicado e escolhe a opção “Visualizar Agenda”.
5. Sistema exibe em um calendário as próximas datas e horários disponíveis para o médico
selecionado.
6. Atendente informa ao paciente as datas e os horários disponíveis.
7. Paciente informa ao atendente a data e o horário de sua preferência, dentre os disponí-
veis.
8. Atendente seleciona a data e o horário disponíveis no calendário e seleciona a opção
“Nova Consulta”.
9. Atendente preenche no sistema o nome do paciente e confirma o agendamento.
10. Sistema exibe mensagem de sucesso.
11. Atendente informa ao paciente que a consulta foi agendada com sucesso.
Fluxo alternativo:
[Paciente não possui médico de preferência – nesse caso, o paciente seleciona o médico
pela especialidade médica. Ocorre variação nos passos de 1 a 5.]
1. Por telefone, o paciente entra em contato com a clínica e solicita uma consulta, in-
formando a especialidade médica desejada.
2. Atendente acessa o sistema e seleciona a opção de menu “Agendar Consulta”.
3. Atendente seleciona a opção “Busca por especialidade”.
4. Sistema exibe uma lista com as especialidades médicas disponíveis.
5. Atendente seleciona a especialidade informada pelo paciente e seleciona a opção

“Visualizar Agenda”.
6. Sistema exibe em um calendário as próximas datas e horários disponíveis para todos os
médicos da especialidade informada.
7. Atendente acessa o sistema, buscando as datas e horários de todos os médicos da es
pecialidade informada pelo paciente.
8. Sistema exibe em um calendário as próximas datas e horários disponíveis para todos os
médicos da especialidade informada pelo paciente.
Além da especificação de casos de uso, o analista de processos documenta também alguns

requisitos não funcionais levantados a partir das necessidades apontadas pelas pessoas entrevis-
tadas.
● [Segurança de acesso] apenas os médicos cadastrados podem ter acesso a prontuários de
pacientes. Atendentes têm acesso somente a dados cadastrais dos pacientes.
● [Privacidade] dados de prontuários de pacientes devem ser persistidos com criptografia.
● [Desempenho] o tempo de resposta entre a submissão de uma página e a exibição da próxima
não pode ser superior a 2 segundos.
● [Desempenho] a solução deve suportar a realização de pelo menos 10 consultas médicas
simultâneas.
● [Integridade de dados] o registro de consultas nas agendas dos médicos deve ser persistido de
forma transacional, para evitar conflitos e condições de corrida no caso de vários atendentes
agendando consultas simultaneamente.

Neste capítulo foi apresentada em detalhes a modelagem de processo de negócio
como base para a especificação de serviços a serem considerados na fase de análise.
A identificação do modelo de processo as-is é importante para ter uma boa ideia do
processo atual e poder projetar melhorias no modelo de processo to-be. O modelo
de processo to-be é complementado com a especificação de requisitos que define as
funções que deverão ser implementadas como uma solução orientada a serviços.
A fase de modelagem fornece insumos alinhados ao negócio para o detalhamento
dos serviços na fase de análise.
5
Análise
Objetivo
O objetivo deste capítulo é apresentar a fase de análise, onde os serviços são detalhados até
a análise de sua possível realização.
Na fase de análise, são identificados serviços candidatos a partir do modelo de processo
to-be. Ainda nesta fase, decide-se como cada serviço será realizado, analisando-se possibili-
dades de reuso para cada um, chegando a um conjunto de serviços finais.
A Figura 5.1 apresenta as atividades de identificação de serviços candidatos, a análise de gap
e a análise de realização da fase de análise, descritas a seguir.
Conteúdo
5.1 Identificação de serviços candidatos 75
5.2 Análise de gap 84
5.3 Análise de realização 91
&emsp;5.1 Identificação de Serviços Candidatos

Papel: analista de serviços
Artefatos utilizados: modelo de processo to-be, especificação de requisitos (caso
de uso de negócio, regras de negócio, requisitos não funcionais)
Artefatos gerados: modelo de serviços candidatos
A atividade de identificação de serviços candidatos, conforme apresentada na
Figura 5.2, é a primeira atividade de análise, e recebe como entrada um modelo de
processo to-be e a especificação de requisitos (caso de uso de negócio, regras de
negócio e requisitos não funcionais).
A partir do modelo de processo to-be, o analista de serviços deve identificar ativi
dades, passos, funções que podem ser executadas por serviços, mais especificamente,
75
Figura 5.1 Atividades da fase de análise.
Figura 5.2 Identificação de serviços candidatos.
invocando-se operações de serviços. Em outras palavras, são pontos do processo em

que uma operação de um serviço poderia ser invocada para executar determinada lógi
ca. Estas atividades, os passos e as funções serão considerados operações candidatas,
ou seja, porções de lógica que podem ser transformadas em operações de serviços.
Já nos casos de uso de negócio, o analista de serviços deve identificar, dentre os
passos do fluxo de eventos atribuídos ao ator sistema, aqueles que podem vir a ser
executados por operações de serviços, originando mais operações candidatas.
As regras de negócio devem ser analisadas em conjunto com os modelos de pro
cesso to-be e casos de uso, pois estão associadas a eles. Caso uma tarefa de processo
ou evento de caso de uso dê origem a uma operação candidata, as regras de negócio
associadas à tarefa ou evento devem ser associadas também à operação candidata.
5 Análise 77
5.1.1 Decompor processos de negócio

Nessa etapa, o analista de serviços deverá analisar o modelo de processo to-be
e identificar pontos em que serviços poderiam apoiar o processo. São pontos do
processo em que uma operação de um serviço poderia ser invocada para executar
determinada lógica.
Conforme descrito na Seção 4.2, as tarefas podem ser detalhadas por uma des
crição em texto corrido ou por uma sequência de passos. Seja qual for a maneira
adotada, o modelo de processo é decomposto em passos de menor granularidade,
sendo que cada passo representa uma função simples que é executada por um ator
do processo, seja usuário ou sistêmico.
Em uma solução orientada a serviços, as tarefas de um processo poderão ser
automatizadas por operações de serviço sendo executadas.
Desse modo, o analista de serviços deve decompor o modelo de processo to-be em
uma série de passos de baixa granularidade e então analisar cada passo e identificar
quais deles podem ser automatizados por uma invocação de um serviço.
De modo geral, todo passo sistêmico é um candidato a se tornar uma invocação
a um serviço.
Dependendo da forma como o processo é documentado pelos analistas de proces
sos, a descrição de uma mesma atividade pode conter tanto passos manuais executados
por atores humanos quanto passos sistêmicos executados por aplicações existentes
ou a serem desenvolvidas. Mas, geralmente, consegue-se separar claramente tarefas
puramente humanas de tarefas puramente sistêmicas. De qualquer modo, após a
decomposição, cada etapa deve ser avaliada independentemente para se determinar
se é humana ou sistêmica. Nesta atividade de identificação, cada etapa sistêmica é
mapeada para uma operação candidata. Passos e tarefas não computacionais (exe
cução de tarefas humanas) do processo não serão consideradas nesta etapa, pois não
poderão ser executados por operações de serviços.
O analista de serviços deve considerar que o nível de granularidade dessas opera
ções candidatas pode variar, desde tarefas completas do ponto de vista do processo de
negócio até funções atômicas de sistemas. Deste modo, considera-se que as operações
de um serviço podem corresponder diretamente com uma tarefa inteira do processo
ou corresponder a apenas uma etapa da lógica envolvida em uma tarefa identificada
em um modelo de processo de negócio.
Na Figura 5.3, as tarefas A, B e C do modelo de processo foram decompostas em
etapas. Após análise, identificou-se a etapa 3 da Tarefa A como sendo uma etapa sistê
mica, dando origem a uma operação candidata. Já no caso da Tarefa B, verificou-se
ser possível sua automação por uma única operação candidata, porém, de maior granula
ridade. E, finalmente, na Tarefa C, as etapas 8 e 9 foram identificadas como candidatas
a operações de serviços. Pode-se notar a partir deste exemplo que, dependendo do nível
de granularidade das tarefas de um processo e do tipo de lógica executada em cada
etapa, operações candidatas podem ser identificadas de maneiras diferentes.
É importante ressaltar que as operações identificadas nesse ponto do ciclo de vida
não devem necessariamente ser implementadas como descritas no modelo de processo
Figura 5.3 Níveis de granularidade de operações identificadas.
to-be. As operações identificadas nesta atividade são apenas candidatas, uma vez que
ainda serão analisadas e revisadas, antes de sua especificação e implementação.
Alguns exemplos de etapas de processo que podem ser identificadas como ope
rações candidatas são:
● consulta em uma base de dados ou sistema legado;
● processamento sistêmico de informações (envio de e-mails, geração de relatórios
ou massas de dados, manipulação de objetos ou registros);
● aplicação de regras de negócio;
● inserção ou atualização de informações em uma base de dados ou sistema legado;
● resposta a um comando executado por um usuário na interface consumidora;
● busca de dados para popular um formulário exibido para o usuário;
● integração ou troca de informações com outro sistema/domínio/organização;
● validação de dados.
A operação candidata está relacionada a uma operação computacional, portanto, de

ve-se observar se, dentro das formas de descrição das atividades de negócio, as atividades
são passíveis e relevantes para serem automatizadas. Por exemplo, no caso do processo
de venda de produtos (Figura 3.3), na atividade “Abrir Pedido”, as operações de envio de
pedido pelo cliente e de recebimento do pedido pelo atendente podem ser consideradas
como atividades humanas, assim, não precisam necessariamente ser automatizadas.
O analista de serviços deve listar e descrever todas as operações candidatas identi
ficadas. As operações candidatas podem ser documentadas no modelo de serviços.
5.1.2 Decompor casos de uso de negócio

Em um caso de uso de negócio, o analista de serviços analisa as descrições dos fluxos de
eventos, separando os passos executados pelos atores usuários dos passos automatizados,
ou seja, executados pelo ator “Sistema”, representando a solução orientada a serviços.
Geralmente, em uma descrição de fluxo de eventos de um caso de uso, utiliza-se
uma sequência de passos, cada passo executado por um ator. Os atores envolvidos
em um caso de uso podem ser pessoas (usuários de um sistema ou participantes da
lógica de negócio) ou sistemas e aplicações.
5 Análise 79
Uma prática comum ao se escrever esse tipo de caso de uso é referir-se à solução
orientada a serviços como um todo por meio do ator “Sistema”. Assim, eventos do
caso de uso que forem automatizados pela solução serão associados ao ator “Sistema”.
Durante a fase de análise é que será definido qual elemento da solução orientada a
serviços (serviço ou aplicação legada) ficará responsável por executar cada evento.
Na identificação inicial, pode-se criar uma relação direta entre as etapas cujo ator
é o “Sistema” e uma operação de serviço. Neste caso, a solução orientada a serviços
como um todo é representada pelo ator “Sistema”.
Assim, como na decomposição de processo de negócio, o analista de serviços deve
registrar no modelo de serviços as operações candidatas identificadas nessa etapa.
A Figura 5.4 representa o fluxo de eventos de um caso de uso por meio de um
diagrama de sequência. Neste exemplo, temos dois eventos que envolvem a interação
de um dos atores usuários com o ator “Sistema”, sendo portanto identificados como
operações candidatas.
5.1.3 Agrupar operações candidatas

O analista de serviços deve listar os passos que serão automatizados, de modo que
cada um destes passos poderá ser mapeado para uma operação de um serviço sendo
invocada. As operações relacionadas devem ser agrupadas, de modo que cada grupo
de operações pertença a um serviço candidato.
Devem ser agrupadas operações que compartilhem um mesmo contexto lógico (se
mântico) ou que trabalhem com as mesmas entidades de dados (Erl, 2005). Em caso
Figura 5.4 Identificação de operações candidatas a partir de caso de uso.

de operações identificadas a partir de um modelo de processo, podem ser agrupadas

operações executadas por um mesmo papel. Em caso de operações identificadas de
um caso de uso, podem ser agrupadas operações relacionadas a um mesmo ator do
caso de uso.
Ao agruparem-se as operações candidatas, o analista de serviços deve procurar
obter coesão no conjunto de serviços candidatos identificados. Para tal, recomenda-se
aplicar o design pattern Service Normalization (Normalização de Serviços) (Erl,
2009), segundo o qual não pode haver sobreposição de funcionalidade entre serviços.
Cada serviço deve possuir um escopo funcional bem claro e definido, tornando-se o
ponto único de acesso à funcionalidade que ele provê.
Para agrupar as operações candidatas, o analista de serviços pode utilizar os
seguintes critérios:
5.1.3.1 Operações candidatas agrupadas segundo contexto lógico

Um dos critérios mais diretos para se agrupar operações é por semelhança na lógica
executada por cada uma delas. Operações que possuam funções relacionadas podem
ser agrupadas para dar origem a um serviço. Por exemplo, em um processo de negócio
que envolve a geração de notas fiscais, podem ser identificadas diversas operações
candidatas com a função de calcular os impostos a serem recolhidos, sendo uma
operação para cada tipo de imposto (imposto de renda, sobre mercadorias, sobre
serviços, entre outros). Por possuírem funções lógicas semelhantes, estas operações
podem ser agrupadas em um serviço candidato chamado “Cálculo de Imposto” ou
“Calcular Imposto”, conforme a Figura 5.5.
Geralmente, serviços candidatos agrupados segundo esse critério darão origem a
serviços de tarefa ou serviços utilitários, dependendo do nível de granularidade.
5.1.3.2 Operações candidatas agrupadas por entidade de dados

Outro critério para agrupamento de operações candidatas é o tipo de dado que elas
manipulam. Operações candidatas que envolvem acesso a dados persistentes em
algum tipo de base de dados ou sistema operacional podem ser agrupadas de acordo
com as entidades de dados acessadas. Geralmente, são operações análogas a uma
inserção, atualização, exclusão ou busca de dados em uma tabela.
Nesse caso, agrupam-se operações candidatas que manipulem as mesmas enti
dades de dados.
Figura 5.5 Exemplo de serviço candidato agrupado segundo função lógica.

5 Análise 81
Figura 5.6 Exemplo de serviço candidato agrupado por entidade de dados.
O exemplo clássico desse tipo de agrupamento são as operações candidatas que

acessam um cadastro de clientes, presentes em processos de negócio de diferentes
domínios. Operações candidatas que inserem um novo cliente no cadastro ou que
atualizam os dados de um cliente existente podem ser agrupadas em um serviço
chamado “Cliente”, conforme a Figura 5.6.
5.1.4 Descrever serviços candidatos

Nesta etapa, o analista de serviços deve documentar no modelo de serviços os serviços
candidatos criados.
Nesse momento, ainda não estão sendo considerados os requisitos não funcionais
que afetam o tipo de serviço a ser desenvolvido. O importante neste ponto do ciclo de
vida é descrever claramente a função lógica executada por cada operação candidata,
descrever os dados de entrada utilizados para executar a função e os dados de saída
gerados como resultado. Na descrição dos dados, deve-se procurar explicitar os
campos e seus tipos de dados (texto, valor numérico, data, estrutura de dados etc.)
e, se possível, o formato também.
Nas operações identificadas a partir de casos de uso, devem ser descritas as funções
executadas pelo ator “Sistema”, bem como especificar os dados informados pelo usuário
a cada operação e os dados retornados pelo “Sistema” como resultado da execução.
O analista de serviços deve também registrar no modelo de serviços as regras de
negócio associadas às operações candidatas.
Dicas
● Assim como na fase de modelagem, mantenha consistência na nomenclatura dos serviços
e operações candidatas, se possível, mantendo o mesmo vocabulário.
● A decomposição em etapas de baixa granularidade é importante para que as operações
candidatas identificadas representem porções de lógica agnóstica, isto é, sem características
específicas do contexto onde se encontram (processo de negócio ou caso de uso).
Exemplo
Uma vez definido o modelo de processo “to-be” e a especificação de requisitos (casos de uso
de negócio, regras de negócio e requisitos não funcionais) do processo de consulta médica da
clínica MEDSOA, o analista de serviços recebe esses artefatos gerados para realizar a análise
Na análise do modelo de processo “to-be”, algumas operações candidatas podem ser iden-
tificadas diretamente a partir das tarefas associadas ao ator “Sistema”. Neste caso, temos ope-
rações candidatas identificadas no nível de granularidade de tarefas de processo. As operações
identificadas, deste modo, são as seguintes, separadas por subprocesso:
Subprocesso agendamento
obter paciente pelo nome;
inserir paciente;
obter datas disponíveis na agenda;
inserir consulta na agenda.
Subprocesso atendimento
enviar notificação;
obter prontuário de paciente;
gerar prescrição;
atualizar prontuário de paciente.
Subprocesso pagamento
gerar fatura para convênio;
registrar pagamento no caixa.
Para identificação das operações de menor granularidade, é necessário decompor as des-

crições das tarefas. Por exemplo, decompondo-se a descrição da tarefa “Prescrever medicamentos
e exames” descrita anteriormente, poderíamos chegar aos seguintes passos:
1. O médico acessa no sistema a função de “Geração de Prescrição”.

2. O médico busca medicamentos pelo nome.
3. O médico seleciona o medicamento desejado.
4. O sistema adiciona à prescrição as seguintes informações: nome comercial do medica-
mento, nome do princípio ativo, frequência de administração, forma de administração,
dose ou quantidade.
5. O médico busca exames pelo nome.
6. O médico seleciona o exame desejado.
7. O sistema adiciona à prescrição as seguintes informações: nome do exame, instruções
de preparação para o exame.
8. O médico imprime uma prescrição de medicamentos.
9. O médico imprime uma prescrição de exames.
10. O médico imprime entrega prescrições ao paciente.
Observe que a descrição em passos de baixa granularidade é bastante semelhante a um fluxo

de eventos de um caso de uso. Por esse motivo, recomenda-se estruturar a descrição das tarefas
do processo em passos e a especificação de casos de uso para complementar os diagramas do
processo. Partindo-se desses passos, são identificadas as seguintes operações candidatas:
● obter medicamentos pelo nome (passo 2);

● adicionar medicamento à prescrição (passo 4);
● obter exames pelo nome (passo 5);
● adicionar exame à prescrição (passo 7);
● gerar prescrição de medicamentos (passo 8);
● gerar prescrição de exames (passo 9).
Já no caso de uso “Agendar Consulta” (descrito anteriormente), a partir dos eventos

associados ao ator “Sistema”, podem ser identificadas as seguintes operações candidatas:
5 Análise 83
● obter todos os médicos (evento 3);

● obter médico pelo nome (evento 3);
● obter datas disponíveis na agenda (evento 5, já identificada no nível de tarefa);
● inserir consulta na agenda (evento 9, já identificada no nível da tarefa).
Note que temos duas operações que já haviam sido identificadas pela análise inicial, no
nível de granularidade de tarefa, mas há duas outras que só puderam ser identificadas devido
ao detalhamento do caso de uso.
Já no fluxo alternativo do caso de uso, podem ser identificadas mais algumas operações
candidatas:
● obter especialidades médicas (evento 4);

● obter médico por especialidade (evento 5);
● obter datas disponíveis na agenda (evento 6, já identificada anteriormente).
Após identificadas todas as operações candidatas necessárias ao processo, o analista de

serviços realiza o agrupamento das operações candidatas em serviços candidatos (Figura 5.7).
Alguns serviços são agrupados por entidade de dados (paciente, médico, agenda), enquanto
outros são agrupados por função lógica (caixa, prescrição).
Definidos os serviços candidatos, o analista de serviços os documenta e os descreve no
modelo de serviços. A seguir, um exemplo de descrição de um serviço candidato e de uma
de suas operações candidatas.
Serviço “Agenda”
Serviço responsável por gerenciar as agendas de consultas dos médicos da clínica MEDSOA.
Operação: inserir consulta na agenda.
Dados de entrada: identificação de médico, identificação de paciente, data e hora da consulta.
Dados de saída: mensagem de confirmação de agendamento ou erro.
Descrição da lógica: insere na agenda do médico selecionado (pelo identificador) um registro
de consulta para o paciente selecionado (pelo identificador) na data e hora selecionadas.
Caso o registro seja inserido com sucesso, retorna uma mensagem de sucesso. Caso já exista
alguma consulta na data e hora selecionadas, retorna uma mensagem de erro.
Figura 5.7 Serviços candidatos identificados.

5.2 Análise de Gap
Papel: analista de serviços
Artefatos utilizados: modelo de serviços candidatos, documentação de aplicações
legadas e registro de serviços
Artefatos gerados: não aplicável
Um dos principais benefícios buscados com a adoção de SOA é o aumento no
reuso de recursos existentes. Para tal, além de se garantir que os serviços possuam
características de reusabilidade, é essencial que o método de desenvolvimento preveja
a avaliação de serviços ou outros recursos existentes para reuso na construção de
novas soluções orientadas a serviços.
A atividade de análise de gap, conforme pode ser vista na Figura 5.8, tem como
objetivo comparar os serviços candidatos identificados com os recursos já existentes
na infraestrutura de TI da organização e avaliar as possibilidades de reuso (Papazo
glou; Van den Heuvel, 2006).
Para cada operação candidata (pertencente a um serviço candidato), o analista de
serviços deve verificar se já existe algum serviço no portfólio ou aplicação de soft
ware legada que execute total ou parcialmente sua funcionalidade. Para realizar esta
busca, podem ser consultados o registro de serviços da organização, os repositórios
de recursos reusáveis ou as documentações de aplicações legadas. Também podem
ser avaliados para reuso serviços providos por parceiros externos através da nuvem
(cloud services).
Figura 5.8 Análise de gap.

5 Análise 85
Baseado nessa busca, o analista de serviços poderá analisar as possibilidades de

reuso e identificar eventuais gaps para o reaproveitamento de um recurso existente.
Geralmente, pode-se classificar o gap existente em uma das seguintes opções:
● gap de lógica – o recurso existente não realiza todas as etapas de lógica necessárias
para a operação candidata;
● gap de dados – o recurso existente não retorna todos os dados de saída necessários
para a operação candidata;

● gap de formato – o recurso existente trabalha com formato de dados ou esquemas
de mensagens diferente do consumidor de serviço candidato;

● gap de protocolo – o recurso existente é invocado através de um protocolo de
comunicação diferente do utilizado pelo consumidor de serviço candidato.
5.2.1 Identificar cenário de reuso

Ao se analisar o reuso de um recurso existente para uma operação candidata, deve-se
verificar se a operação ou aplicação legada existente executa todas as funções descritas
para a operação candidata, se atende a todos os requisitos funcionais e não funcionais re
lacionados e se entrega todos os dados de saída esperados, ou se há algum tipo de gap.
Assim, dependendo do resultado de tal análise, para cada operação analisada,
pode-se identificar um dos seguintes cenários de reuso descritos a seguir.
5.2.1.1 Operação realizada por um serviço

Nesse cenário de reuso, não há gap, pois a funcionalidade da operação avaliada já
está implementada por um serviço existente no portfólio de serviços da organização
ou provido por um parceiro, que pode então ser reusado. Este cenário ocorre quando a
operação do serviço existente executa exatamente a lógica necessária para a operação
candidata, recebendo os mesmos dados de entrada e retornando os mesmos dados de
saída, conforme a Figura 5.9.
5.2.1.2 Operação realizada parcialmente por um serviço

A funcionalidade da operação avaliada é parcialmente realizada por um serviço
existente. O serviço pode ser reusado, mas será necessário alterar o serviço existente
ou implementar uma mediação para utilizar o serviço. Este cenário ocorre quando o
serviço existente possui uma operação que realiza apenas parte da função necessária
para a operação candidata (gap de lógica) ou retorna apenas parte dos dados de saída
esperados (gap de dados), conforme a Figura 5.10.
5.2.1.3 Operação realizada por uma aplicação legada

A funcionalidade da operação avaliada já está implementada por uma aplicação le
gada. Para poder ser usada pelo processo, esta funcionalidade deverá ser encapsulada
na forma de um serviço. Este cenário ocorre quando a aplicação legada existente
executa exatamente a lógica necessária para a operação candidata, recebendo os
mesmos dados de entrada e retornando os mesmos dados de saída. Considera-se
Figura 5.9 Operação candidata realizada por serviço existente.
Figura 5.10 Operação candidata realizada parcialmente por serviço existente.
aplicação legada qualquer componente de software, função, rotina, aplicação pacote

ou ferramenta que não possua um contrato de serviço e que não faça parte do portfólio
de serviços da organização. Deste modo, mesmo não apresentando gap de lógica ou
de dados, este cenário de reuso é caracterizado por algum tipo de gap de formato ou
protocolo, conforme a Figura 5.11.
5 Análise 87
Figura 5.11 Operação candidata realizada por aplicação legada.
5.2.1.4 Operação realizada parcialmente por uma aplicação legada

A funcionalidade da operação avaliada é parcialmente realizada por uma aplicação
legada. Para poder ser usada pelo processo, esta funcionalidade deverá ser encap
sulada na forma de um serviço e deverá ser implementado algum tipo de lógica de
mediação ou integração. A aplicação legada existente possui alguma rotina que realiza
apenas parte da função necessária para a operação candidata ou retorna apenas parte
dos dados de saída esperados. Sendo assim, além de gaps de formato ou de protocolo
presentes em um cenário de reuso de aplicação legada, este cenário apresenta também
algum gap de lógica ou de dados, conforme a Figura 5.12.
5.2.1.5 Operação não existente

A funcionalidade da operação não existe em nenhum recurso disponível e deve,
portanto, ser realizada por um novo serviço a ser criado ou por uma nova operação
a ser criada para um serviço existente, conforme a Figura 5.13.
Para os casos em que a operação candidata é atendida apenas parcialmente,
devem-se documentar as diferenças (gaps) encontradas. Estas informações serão
importantes para as próximas atividades.
5.2.2 Revisar serviços candidatos

O agrupamento das operações candidatas em serviços pode necessitar ser revisado
em vista do resultado da análise de gap. Serviços candidatos podem ser alterados
Figura 5.12 Operação candidata realizada parcialmente por aplicação legada.
Figura 5.13 Operação candidata não existente.

5 Análise 89
caso haja sobreposição com algum serviço já existente. Por exemplo, uma operação
que já é realizada por um serviço existente passará a pertencer a ele. Ou ainda, uma
nova operação a ser criada pode pertencer ao mesmo contexto lógico de um serviço
existente, sendo, portanto, acrescentada a ele.
Dicas
● Ao revisar o agrupamento, lembre-se do design pattern Service Normalization (Normalização
de Serviços) (Erl, 2009).
● A participação do analista de serviços durante a modelagem de processo to-be visa
maximizar o reuso de serviços existentes e minimizar os gaps. O analista de serviços
pode prover o analista de processos com conhecimento sobre o portfólio de serviços
da organização e aplicações legadas existentes, direcionando a definição do modelo de
processo to-be.
Exemplo
O analista de serviços da clínica MEDSOA inicia uma análise dos recursos já existentes com o
objetivo de localizar alguma função, componente ou provedor de serviço que possa ser reusado
para realizar as operações dos serviços candidatos identificados. Para proceder com a análise
de gap, o analista de serviços consulta a documentação disponível dos programas e aplicações
legadas existentes e faz uma prospecção de provedores de serviços na nuvem. Como a clínica
MEDSOA ainda não possui soluções orientadas a serviços implementadas, não há um portfólio
de serviços a ser consultado. Caso já existisse, o registro de serviços deveria também ser avaliado
para reuso.
Como resultado da análise comparativa entre as funções encontradas nos recursos existentes
e as funções necessárias para os serviços candidatos, identificam-se os gaps a serem resolvidos.
O analista de serviços, então, classifica os gaps em um dos cenários de reuso.
Durante a atividade, o analista de serviços descobre que na clínica MEDSOA já existe um
aplicativo pacote de CRM utilizado para armazenar os dados cadastrais de pacientes. Por traba-
lhar com dados de pacientes, o aplicativo CRM foi avaliado para realização das operações do
serviço candidato “Paciente”. No entanto, o aplicativo CRM não era voltado à área médica e,
por isso, possuía apenas funções de acesso a dados cadastrais dos pacientes, mas não a dados
médicos e prontuários. O aplicativo CRM precisa de uma API para possibilitar a integração
com outros sistemas. Deste modo, o analista de serviços estuda a documentação desta API para
avaliar o reuso.
Para a operação candidata “Obter paciente pelo nome”, a API do aplicativo CRM possui duas
funções semelhantes que poderiam ser reusadas: “buscarClientePorNome” e “buscarClientePorSo-
brenome”. Como o aplicativo CRM armazena o nome e o sobrenome dos clientes em campos
separados, sua API possui funções separadas de busca por nome e por sobrenome. A operação
candidata, no entanto, considera o nome e o sobrenome como um único campo, permitindo
que pacientes sejam encontrados informando o nome ou o sobrenome.
Já para a operação candidata “Inserir paciente”, o aplicativo CRM possuía em sua API a função
“adicionarCliente”, que poderia ser reusada.
As outras operações do serviço candidato não existiam na API, pois o CRM não trabalhava
com dados de prontuário.
Desse modo, foram identificados os seguintes cenários de reuso para as operações do serviço
candidato “Paciente”:
● obter paciente pelo nome — operação realizada parcialmente por aplicação legada (fun-
ções “buscarClientePorNome” e “buscarClientePorSobrenome” do aplicativo CRM);
Tabela 5.1 Cenários de reuso para as operações candidatas
Serviço candidato Operação candidata Cenário de reuso

Paciente Obter paciente pelo nome Operação parcialmente
realizada por aplicação
legada (aplicativo CRM)
Inserir paciente Operação realizada por

aplicação legada (aplicativo
CRM)
Obter prontuário de paciente Operação não existente
Atualizar prontuário de Operação não existente

paciente
Médico Obter todos os médicos Operação não existente
Obter médico pelo nome Operação não existente
Obter todas as especialidades Operação não existente

médicas
Obter médico por Operação não existente

especialidade
Agenda Obter datas disponíveis na Operação não existente

agenda
Inserir consulta na agenda Operação não existente
Prescrição Adicionar medicamento a Operação não existente

prescrição
Gerar prescrição de Operação não existente

medicamento
Medicamento Obter medicamento pelo nome Operação não existente
Exame Obter exame pelo exame Operação não existente
Notificação Enviar notificação Operação realizada por

serviço existente (provedor
de serviço na nuvem)
Caixa Registrar pagamento Operação não existente
Gerar fatura para convênio Operação não existente
● inserir paciente — operação realizada por aplicação legada (função “adicionarCliente”

do aplicativo CRM);
● obter prontuário de paciente — operação não existente;
● atualizar prontuário de paciente — operação não existente.
O analista de serviços documenta no modelo de serviços os cenários de reuso identificados,

junto às descrições de cada operação candidata.
Além do aplicativo CRM, o analista de serviços avaliou também a utilização de provedores
externos para realização do serviço candidato “Notificação”, que deveria enviar mensagens de
5 Análise 91
texto ao telefone celular do paciente para lembrá-lo da consulta. O analista de serviços pesquisa
por provedores de serviços de mensageria na nuvem, obtém informações sobre seus contratos
de serviços e conclui que um serviço na nuvem poderia ser reusado para realizar a operação
candidata “Enviar notificação”.
Já para os demais serviços candidatos, a clínica MEDSOA não possuía nenhuma aplicação
legada para atender, nem foram encontrados provedores de serviços adequados na nuvem.
Portanto, para as operações candidatas restantes, o cenário de reuso identificado foi “Operação
não existente”.
A Tabela 5.1 resume os cenários de reuso identificados para todas as operações candidatas.
5.3 Análise de Realização
Papéis: analista de serviços, gerente de projeto, arquiteto corporativo
Artefatos utilizados: cenários de reuso
Artefatos gerados: modelo de serviços e decisões de realização
Uma vez identificados os cenários de reuso para cada operação candidata em rela
ção aos recursos existentes, devem então ser analisadas as alternativas de realização
possíveis para cada uma delas e decidir qual será adotada para realizar o serviço.
A análise de realização, conforme a Figura 5.14, tem por objetivo avaliar as
alternativas para realização de cada operação candidata em termos de viabilidade
técnica, custos, riscos técnicos e de projeto, esforço e ROI. Para esta tomada de
decisão, o analista de serviços pode contar com o apoio do gerente de projetos e do
arquiteto corporativo.
Figura 5.14 Análise de realização.

5.3.1 Definir realização de serviços

Para cada cenário de reuso identificado, as seguintes considerações devem ser feitas:
5.3.1.1 Operação realizada por um serviço

Não é necessário especificar um novo serviço ou operação, uma vez que o serviço
existente poderá ser utilizado diretamente pelo processo de negócio sem a necessidade de
alteração ou integração. Este é o cenário com menor risco de ser realizado, acarretando
apenas no custo de reuso. É também o cenário que aumenta o retorno sobre o investimen
to já realizado anteriormente. A alternativa de realização neste cenário é a seguinte:
● Reusar serviço existente – deve ser obtido o contrato do serviço existente, para
que o consumidor possa implementar o acesso ao serviço.
Para se manter a governança do ciclo de vida dos serviços, ao se reusar um serviço
existente, é necessário que seja estabelecido um entendimento entre o provedor do
serviço e o novo consumidor. O provedor de serviço deve ser notificado sobre o
incremento no uso do serviço, devendo se assegurar de que possui os recursos com
putacionais para atender à nova demanda com a qualidade de serviço especificada nas
políticas e SLAs do contrato do serviço. Por sua vez, o novo consumidor do serviço
deve estar ciente das políticas e condições de uso do serviço e assegurar conformidade
com elas. Este acordo entre provedor e consumidor deve ser plenamente estabelecido
para que o reuso seja possível.
5.3.1.2 Operação realizada parcialmente por um serviço

Nesse cenário, existe um gap de lógica ou de dados entre o serviço existente e o ser
viço candidato identificado. Dependendo do tipo de gap encontrado entre a operação
candidata e a existente, diferentes opções podem ser analisadas.
Nesse cenário de reuso, as seguintes alternativas de realização podem ser avaliadas
para resolução do gap:
● Alterar o serviço candidato – uma vez identificado um serviço existente, pode-se
alterar a definição da operação candidata identificada para que ela se adeque ao
contrato já definido. No entanto, esta alteração pode afetar o modelo de processo
ou caso de uso a partir do qual a operação candidata foi identificada e exigir uma
revisão. Apesar de representar certo retrabalho sobre o que foi produzido na fase
de modelagem, este tipo de revisão garante um alinhamento maior entre o modelo
de processo e os serviços existentes. Além disso, o custo de uma alteração em um
requisito ou em um modelo de negócio tende a ser menor do que uma alteração
em algo já implementado e em operação.
● Alterar o serviço existente – em caso de gap de lógica ou de dados, pode-se
alterar o serviço existente para que ele se adapte ao serviço candidato. Esta
alternativa traz um risco a ser considerado, pois alterações em um serviço podem
impactar seus consumidores já existentes. Portanto, sempre que se optar pela
alteração do serviço, deve-se analisar os possíveis impactos destas alterações.
Caso a alteração afete o contrato do serviço existente, recomenda-se criar uma
5 Análise 93
nova versão do serviço (Erl, 2008). Neste caso, como a alteração afeta o contrato,
consequentemente atinge consumidores existentes do serviço. Para minimizar
o impacto, pode-se criar uma operação adicional no serviço, que execute toda
a lógica necessária para a operação candidata, ou apenas a lógica faltante.
● Implementar mediação – uma alternativa de realização comum nesse cenário é im
plementar um componente de mediação para reusar o serviço em seu estado atual.

A mediação seria um agente intermediário que encapsularia o acesso ao serviço
existente, resolvendo eventuais gaps. Em caso de gap de lógica, a mediação
poderia implementar as etapas lógicas não realizadas pela operação existente, ou
invocar uma outra operação (do mesmo serviço ou de outro serviço existente) que
implementasse as etapas faltantes. Em caso de gap de dados, a mediação poderia
gerar as informações faltantes ou poderia buscá-las em outra fonte, como outra
operação de serviço ou uma base de dados (aplicação legada).
5.3.1.3 Operação realizada por uma aplicação legada

Esse cenário exige a criação de um serviço que encapsule a funcionalidade da apli
cação legada e resolva os gaps de formato ou protocolo. Algumas alternativas
de realização possíveis neste cenário são:
● Expor aplicação legada como serviço – pode-se propor a criação de um novo
componente de serviço que encapsule o acesso à aplicação legada. Os gaps de
formato e protocolo devem ser resolvidos pelo componente de serviço invocando
o legado através de adaptadores de integração ou APIs. Para tal, estes adaptadores
e APIs devem ser compatíveis com a tecnologia de implementação do componente
de serviço. Caso contrário, devem-se avaliar a viabilidade técnica e o custo de se
implementar este acesso por outros meios.
● Implementar mediação – pode-se utilizar uma mediação para encapsular o acesso
à aplicação legada. Para solucionar gaps de formato ou protocolo, a mediação

tem como objetivo traduzir as mensagens de um formato para outro (através de
mapas de mensagens) ou realizar a conversão de protocolos de comunicação
(através de adaptadores) para que o consumidor possa utilizar o serviço.
● Implementar componente de serviço – pode-se decidir ignorar a aplicação legada
existente e implementar um novo componente de serviço para realizar o serviço

candidato. Esta alternativa geralmente é escolhida quando a aplicação legada está
planejada para descontinuação ou substituição.
5.3.1.4 Operação realizada parcialmente por uma aplicação legada

Nesse cenário, além de gaps de formato e de protocolo decorrentes da integração
com uma aplicação legada, existem gaps de lógica ou de dados a serem resol
vidos.
As alternativas de realização possíveis para este cenário são:
● Expor aplicação legada como serviço – nesse caso, a solução é semelhante à
proposta no cenário de reuso “Operação realizada por aplicação legada”, com a
diferença de que o componente de serviço encapsulador deve ser construído de

modo a resolver os gaps de lógica ou de dados.
● Implementar mediação – em caso de gap de lógica, a mediação poderia im
plementar as etapas lógicas não realizadas pela operação existente, ou invocar
uma outra operação (do mesmo serviço ou de outro serviço existente) que im
plementasse as etapas faltantes. Em caso de gap de dados, a mediação poderia
gerar as informações faltantes ou poderia buscá-las em outra fonte, como outra
operação de serviço ou uma base de dados (aplicação legada). Além disso, a
mediação deve resolver os gaps de formato e protocolo para acesso à aplicação
legada.
● Alterar aplicação legada – uma alternativa possível é alterar a aplicação
legada para solucionar os gaps de lógica ou dados com relação à operação
candidata. Ainda assim, torna-se necessária a criação de um componente de
serviço encapsulador ou de uma mediação para resolver os gaps de formato ou
protocolo. Deve-se avaliar se os custos e os impactos tornariam esta alternativa
viável.
● Implementar componente de serviço – semelhante ao cenário “Operação realizada
por aplicação legada”.
● Alterar serviço candidato – essa alternativa envolve alterar a operação can
didata identificada para se adequar à aplicação legada, eliminando gaps de
lógica e de dados. Ainda assim, os gaps de formato e de protocolo deverão
ser resolvidos criando-se um componente de serviço encapsulador ou uma
mediação. Consequentemente, podem ser necessários ajustes no modelo de
processo ou no caso de uso que originou a operação candidata. Geralmente,
não se recomenda esta alternativa por gerar um acoplamento indesejado entre
o serviço candidato e a aplicação legada, que pode se propagar até o processo
de negócio.
5.3.1.5 Operação não existente

Nesse cenário, como não há nenhum tipo de recurso existente sendo reusado, a opera
ção candidata deve ser criada a partir do zero. A única alternativa de realização é:
● Implementar componente de serviço – a alternativa é implementar um novo
componente de serviço ou uma nova operação em um componente de serviço
já existente. Como a operação deverá ser implementada a partir do zero, o risco
é baixo, pois se tem controle sobre sua especificação e realização. O custo
resume-se ao esforço necessário para se especificar e implementar a nova fun
cionalidade.
Para cada cenário de reuso, ainda podem ser levantadas outras alternativas de
realização específicas de cada caso analisado.
Caso a análise de realização tenha dado origem a novas operações ou serviços,
estes devem ser descritos no modelo de serviços do mesmo modo que os serviços
identificados anteriormente.
5 Análise 95
5.3.2 Analisar viabilidade e arquitetura

Após a análise das alternativas de realização para todas as operações candidatas, o
analista de serviços deve ponderar sobre cada uma delas para tomar as decisões de
como cada serviço será realizado. Para a tomada da decisão final, é importante o
apoio do gerente de projetos, pois são avaliados aspectos como risco, custo e esforço,
e do arquiteto corporativo, pois pode haver alterações em aplicações e serviços
existentes.
O gerente de projeto participa dessas decisões, pois é o responsável por administrar
o escopo, os custos e os prazos do projeto de implementação da solução orientada a
serviços. O gerente de projetos procura viabilizar as decisões dentro das limitações
de custos e prazos do projeto.
Já o arquiteto corporativo deve assegurar que as decisões de realização tomadas
pelo analista de serviços estejam de acordo com os padrões de arquitetura e gover
nança da organização e garantir que os serviços finais definidos possam integrar o
portfólio de serviços da organização de forma consistente.
Caso seja definida uma alternativa de realização viável, a atividade prossegue com
a especificação dos serviços. Caso contrário, os resultados da análise de realização
devem ser passados para o analista de processos para que a modelagem de processo
to-be seja revisada e as atividades de análise repetidas.
5.3.3 Revisar serviços candidatos

Dependendo das alternativas de realização escolhidas, pode ser necessário atualizar
o modelo de serviços para refletir as alterações definidas no conjunto de serviços e
operações candidatos.
Alguns exemplos de alterações ocasionadas pela análise de realização:
● Substituição do serviço candidato proposto pelo serviço existente a ser reusado.
● Criação de novas operações para solucionar gaps de lógica e de dados.
● Criação de novas operações ou serviços para encapsular acesso ao legado.
● Revisão do agrupamento das operações nos serviços devido às decisões de rea
lizações. Por exemplo, podem ser agrupadas operações que são realizadas pela
mesma aplicação legada.
Com as decisões de realização tomadas e as alterações definidas, os serviços
deixam de ser “candidatos” e tornam-se efetivamente serviços que integrarão o
portfólio da organização.
Dicas
● Aplique os design patterns Version Identification (Identificação de Versão) e Canonical
Versioning (Versionamento Canônico) (Erl, 2009), de modo a garantir que todos os contratos
de serviços sejam versionados de acordo com os mesmos padrões.
● O reagrupamento de operações por aplicação legada reusada deve ser aplicado com
parcimônia para evitar que isso gere um acoplamento do serviço com a aplicação
legada.
Exemplo
Na análise de gap, foram identificados recursos reusáveis para realizar os serviços candidatos
“Paciente” e “Notificação”. O analista de serviços, então, avalia as alternativas de realização
para cada um deles.
Para a operação “Obter paciente pelo nome” do serviço “Paciente”, que foi considerada par-
cialmente por uma aplicação legada (as funções “buscarClientePorNome” e “buscarClientePorSo-
brenome” do aplicativo CRM), foram consideradas as seguintes alternativas de realização:
● Expor a aplicação legada como serviço – essa alternativa consistia em implementar um
novo componente de serviço que encapsulasse o acesso às duas operações. Como a pala-
vra digitada pelo usuário para realizar a busca poderia ser tanto o primeiro nome quanto o
sobrenome de um paciente, a palavra informada como dado de entrada deveria ser utilizada
como parâmetro para a invocação das duas funções, e seus resultados seriam retornados pelo
componente de serviço como um conjunto único. No entanto, a API exposta pelo aplicativo
pacote utilizava uma tecnologia de implementação que não a tecnologia padrão adotada
pela clínica MEDSOA. Além disso, o formato dos campos retornados pelo aplicativo CRM
era proprietário e necessitaria ser mapeado pelo componente de serviço.
● Implementar mediação – nessa alternativa, seria utilizada uma mediação do ESB para in-
tegrar com as funções do aplicativo CRM. A mediação seria responsável por coordenar as
chamadas às duas funções do mesmo modo que a alternativa anterior. A diferença é que o
ESB da clínica MEDSOA já possuía um adaptador para acessar a API do aplicativo CRM e
possui facilidades para construção de mapas de dados.
● Alterar aplicação legada – essa alternativa não foi considerada, pois a clínica MEDSOA não
possuía acesso ao código fonte proprietário do aplicativo CRM.
● Implementar componente de serviço – nessa alternativa, os dados contidos no CRM seriam
ignorados e seria criado um novo componente de serviço para realizar a operação candidata.
O analista de serviços, então, discutiu com o gerente de projeto e o arquiteto corporativo para
decidir pela melhor alternativa. A alternativa de expor a aplicação legada como serviço não foi
recomendada pelo arquiteto corporativo por envolver a utilização de tecnologia e linguagem de
programação que não era a adotada por padrão na organização. Já o gerente de projeto conside-
rou que o esforço para utilizar uma tecnologia não familiar e para implementar o mapeamento
de dados seria muito grande.
Já alternativa de criar um novo componente de serviço também foi contraindicada pelo
arquiteto corporativo, pois resultaria em uma nova fonte de dados de pacientes, gerando redun-
dância funcional entre o serviço e o aplicativo CRM. Esta prática iria contra o design pattern
Logic Centralization (Centralização de Lógica).
Desse modo, decidiu-se pela alternativa de implementar a mediação. Além de fazer uso de
uma ferramenta corporativa recomendada pelo arquiteto corporativo (ESB), esta alternativa foi
considerada a mais viável pelo gerente de projeto, pois os requisitos de conectividade com o
aplicativo CRM e o mapeamento de dados poderiam ser atendidos pelo ESB com menor esforço
do que por um componente de serviço.
A mesma análise foi procedida também para a operação candidata “Inserir paciente”, que foi
considerada realizada por aplicação legada. As mesmas alternativas de realização foram elen-
cadas, exceto pela alternativa de se alterar a aplicação legada. Como nesta operação candidata,
os gaps envolvidos eram somente de dados e de protocolo, a decisão de realização tomada foi
a mesma da operação candidata anterior: implementar uma mediação.
Já para a operação candidata “Enviar notificação” do serviço “Enviar Notificação”, cujo
cenário de reuso identificado foi o de operação realizada por serviço existente, foi considerada
apenas a seguinte alternativa de realização:
● Reusar serviço existente – essa alternativa propõe o reuso de um serviço já pronto fornecido
por um provedor na nuvem. Para tal, é necessário obter o contrato de serviço dos possíveis
provedores e avaliar suas condições de uso.
5 Análise 97
O arquiteto corporativo analisa os contratos técnicos de serviços e recomenda a utilização

daqueles que estão definidos segundo os padrões de definição de contrato da clínica MEDSOA.
Já o gerente de projeto busca limitar a escolha dos provedores de serviços cujos custos para
utilização caibam no orçamento do projeto. Baseado nestas restrições, o analista de serviços
seleciona o provedor Cloud Message para o serviço “Enviar Notificação”.
Finalmente, para as demais operações de serviços candidatos, que foram identificadas como
operações não existentes, a única alternativa de realização considerada é a implementação de
novos componentes de serviços.
O analista de serviços atualiza no documento de modelo de serviços as decisões de rea-
lização e as revisões às operações e serviços que, após esta atividade de análise, deixam de
ser considerados candidatos e tornam-se serviços aptos a integrarem o portfólio de serviços da
clínica MEDSOA.
Neste capítulo foram apresentadas a descrição de serviços candidatos, a avaliação
de serviços e os recursos existentes voltados ao seu reuso na construção de soluções
orientadas a serviços. Com os cenários de reuso, as operações foram analisadas quanto
à sua realização e viabilidade. Com o resultado das análises, o modelo de serviços
pode ser revisado.
A fase de análise fornece os serviços analisados que serão mais detalhados na
próxima fase, ou seja, na fase de design.
6
Design
Objetivo
O objetivo deste capítulo é apresentar a fase de design onde os serviços são detalhados
e especificados em nível suficiente para a sua implementação.
Definidos os serviços, inicia-se a fase de design de serviços. O objetivo da fase de design
é criar especificações de serviços que satisfaçam aos requisitos do negócio e sejam aderentes
aos princípios de orientação a serviços (Erl, 2005).
A Figura 6.1 apresenta as atividades de especificação contrato de serviços, especificação
de realização de serviços e verificação de princípios da fase de design, conforme descritas
a seguir.
Conteúdo
6.1 Especificação de contrato de serviços 99
6.2 Especificação de realização de serviços 107
6.3 Verificação de princípios 113
&emsp;6.1 Especificação de Contrato de Serviços

Papel: arquiteto de serviços
Artefatos utilizados: modelo de serviços candidatos
Artefatos gerados: contratos de serviços (esquemas de mensagens e interfaces de
serviço, políticas e SLAs)
A primeira atividade de design é a especificação de contrato de serviços, conforme
pode ser vista na Figura 6.2, na qual as interfaces dos serviços serão formalmente
definidas e suas operações serão especificadas.
Para cada serviço candidato, deverão ser definidas todas as suas operações e
as mensagens de entrada e saída envolvidas em cada operação. Caso a tecnologia
99
Figura 6.1 Atividades da fase de design.
Figura 6.2 Especificação de contrato de serviços.
utilizada seja Web Services, os formatos das mensagens podem ser definidos na forma
de esquemas XSD e as definições de interfaces, representadas na linguagem WSDL.
Para cada serviço, será definido um artefato de contrato de serviços, composto por
definição de interface, esquemas de dados de mensagens, especificação funcional de
cada operação e políticas de serviço.
As mensagens de um serviço serão definidas com base nas informações neces-
sárias como entrada e saída de suas operações e com base em modelos de dados
existentes. Deve-se procurar especificar mensagens padronizadas segundo um modelo
de dados organizacional, para que uma mesma mensagem possa ser utilizada em
diversos serviços.
6 Design 101
Dependendo do cenário, a elaboração da interface do serviço pode ser realizada

de modo top-down, bottom-up ou meet-in-the-middle.
● Operação realizada por um serviço – nesse cenário, o serviço já existe e possui in-
terface definida, não sendo necessário nenhum tipo de especificação adicional.
● Operação realizada parcialmente por um serviço – caso tenha se optado por alterar
o serviço existente, pode ser necessário alterar sua interface e/ou a especificação
funcional da operação a ser chamada. Caso seja utilizada uma mediação, deve-se
definir a interface que será exposta por ela e especificar sua lógica de integração.
Em ambos os casos, a especificação da interface é feita de modo top-down, sendo
realizada a partir do serviço candidato.
● Operação realizada por uma aplicação legada – nesse cenário, a interface é elabo-
rada de maneira bottom-up, tendo suas mensagens e operações definidas a partir

das características da aplicação legada sendo reusada.
● Operação realizada parcialmente por uma aplicação legada – a interface pode ser
elaborada de modo bottom-up como no cenário anterior, ou, caso se tenha optado
por alterar o legado, a interface será derivada de modo bottom-up, mas deverá ser
especificada como o legado deverá ser alterado de modo top-down, caracterizando
uma especificação meet-in-the-middle.
● Operação não existente – nesse cenário, tanto a elaboração da interface quanto a da
especificação funcional das operações são elaboradas de modo totalmente top-down.

As políticas de serviço especificam os requisitos não funcionais relacionados
com o serviço, como segurança, comportamento transacional e registro de auditoria,
e requisitos de nível de serviço, por meio de contratos de SLA. SLAs definirão os
requisitos de desempenho, confiabilidade e disponibilidade acordados entre provedor
e consumidor de serviço.
6.1.1 Projetar esquemas de mensagens dos serviços

Os esquemas de mensagens para comunicação entre serviços e componentes são uma
parte crítica da SOA. Os esquemas de mensagens não apenas definem os dados de
entrada e saída das operações de serviços, como também determinam o formato ou a
sintaxe a ser utilizada para representar estes dados, conforme o fluxo de informações
passa através das camadas da arquitetura do aplicativo.
Quando se utiliza a tecnologia Web Services, o padrão geralmente utilizado para
especificar esquemas de mensagens é a linguagem XSD. Neste caso, cada mensagem
do esquema será definida por um tipo complexo de dados (complexType).
Para a definição das mensagens e de seus atributos, algumas fontes de informação
devem ser consideradas, além das descrições de dados de entrada e saída das opera-
ções documentadas no modelo de serviços:
● modelo de dados corporativo, caso exista;
● modelos de dados lógicos e físico de bases de dados existentes envolvidas na
realização dos serviços;
● definições de dados contidos no modelo de processo de negócio.
As especificações de mensagens e os modelos de dados estão estreitamente

ligados. O modelo de base de dados consiste em entidades e seus relacionamentos,
um subconjunto do qual pode ser enviado como parte de uma mensagem de saída e
recebido como uma entrada de uma mensagem que chega. Deste modo, o mapeamento
entre os formatos de mensagens e o modelo de base de dados é uma consideração
arquitetural importante.
Caso haja um modelo ou arquitetura de dados corporativo, é importante que esse
esteja alinhado aos modelos de mensagens de serviços definidos. O arquiteto de
serviços deve procurar definir os esquemas de mensagens dos serviços de modo que
eles sejam aplicáveis a todo portfólio de serviços, no sentido de procurar representar
as entidades do modelo de dados corporativo.
Dessa forma, os esquemas de mensagens de todos os serviços formam um modelo
de dados único e padronizado, buscando reaproveitar os mesmos esquemas em dife-
rentes serviços. Assim, minimiza-se a necessidade de mapeamento e transformação
de dados na interação e composição de serviços. Esta prática é descrita pelo design
pattern Canonical Schema (Esquema Canônico) (Erl, 2009).
A aplicação desse design pattern exige também que o arquiteto de serviços procure
reusar esquemas de mensagens já existentes, consultando um registro de serviços.
Na elaboração dos esquemas, deve ser descrito com detalhes de nível técnico cada
atributo da mensagem, especificando:
● tipo de dado (numeral, texto, data, hora etc.);
● tamanho mínimo e máximo;
● número mínimo e máximo de ocorrências;
● dependências entre mensagens.
Durante a especificação, é importante ter o conhecimento prévio dos padrões de
arquitetura da organização, como padrões de nomenclatura de dados e padrões de
formatos técnicos para representação dos dados. Estes padrões utilizados no design
dos esquemas de mensagens devem estar alinhados também aos padrões técnicos
suportados pelas ferramentas de infraestrutura da solução orientada a serviços (pla-
taforma BPMS, ESB etc.).
6.1.2 Projetar interfaces dos serviços

Uma vez definidos os esquemas de mensagens, o arquiteto de serviços deve elaborar
as interfaces dos serviços, isto é, definir as assinaturas das operações com seus
parâmetros de entrada e saída.
Para cada serviço, deve-se criar um documento de interface que conterá as de-
finições das operações. Quando se adota a tecnologia Web Services, geralmente
utiliza-se a linguagem WSDL para elaboração dos documentos de interface de
serviço. Neste caso, uma definição de serviço é representada por um tipo de porta
(portType) no documento WSDL, e cada operação é representada por um elemento
do tipo operation.
6 Design 103
Os parâmetros de entrada e saída de cada operação devem também ser indicados

no documento de interface. Para cada parâmetro, deve-se definir seu nome e seu
tipo, que pode ser um tipo de dado simples (numeral, texto etc.) ou uma mensagem
definida em algum esquema.
6.1.3 Especificar políticas dos serviços

Os requisitos não funcionais identificados durante a modelagem de negócio foram
associados às tarefas do processo, que por sua vez são implementadas por operações
de serviços. Nesta etapa, deve-se verificar quais requisitos não funcionais da tarefa
devem ser atendidos pelos serviços associados àquela tarefa.
Desse modo, cada operação de serviço deve possuir listados os requisitos não
funcionais atendidos. Caso necessário, na documentação da operação o requisito não
funcional pode ser detalhado trazendo sua descrição do domínio de negócio para o
domínio de implementação. Devem ser criados documentos de políticas associados
a cada serviço para especificar suas condições de uso.
6.1.4 Descrever comportamento dos serviços

O comportamento do serviço consiste na especificação dos requisitos funcionais de
cada uma de suas operações. Nesta etapa, deve-se descrever, sob o ponto de vista
funcional, a lógica executada por cada operação do serviço. Esta descrição deve ser
inserida na documentação de cada operação da interface do serviço, ou pode ser
criado um documento específico para o contrato de serviço.
A lógica de cada operação deve ser descrita por um texto sucinto do tipo cai-
xa-preta, não incluindo detalhes de implementação do serviço. Para detalhar a lógica
e a troca de mensagens executadas internamente ao serviço, podem ser adicionadas
à especificação diagramas de sequência e de atividades. Caso existam, podem ser
referenciadas especificações de regras de negócio que descrevam a lógica contida
na operação.
Ao serem definidos dessa forma, os serviços podem ser diretamente implemen-
tados utilizando técnicas de orientação a objetos e desenvolvimento baseado em
componentes, caso a alternativa de realização escolhida tenha sido implementar um
novo componente de serviço.
6.1.5 Definir camada de serviço

Dependendo da função executada por um serviço, ele pode ser classificado como
serviço de entidade, de tarefa ou utilitário.
Nessa atividade, o arquiteto de serviços deve determinar a qual camada pertence
cada um dos serviços, dividindo-os entre as camadas de serviços utilitários, de
serviços de entidade e de serviços de tarefa, de acordo com sua lógica e seu nível
de granularidade.
A indicação de camada pode ser registrada no documento de descrição do contrato
de serviço ou como um atributo de metadado no registro de serviços.
Dica:
Ao especificar esquemas de mensagens em linguagem XSD para Web Services, crie os docu-
mentos de esquema de mensagem separados dos documentos de interface do serviço, de modo
que possam ser reusados em mais de uma interface.
Exemplo:
A partir do modelo de serviços elaborado, o arquiteto de serviços da clínica MEDSOA dá início
à fase de design do projeto para especificar os contratos dos serviços que darão suporte ao
processo de negócio “Consulta Médica”.
O arquiteto inicia pela especificação dos esquemas de mensagens dos serviços. São definidas
as seguintes mensagens:
● DadosPaciente – mensagem contendo dados de cadastro do paciente, utilizada pelo serviço
“Paciente”.
● DadosMedico – mensagem contendo dados dos médicos da clínica, utilizada pelo serviço
“Médico”.
● DadosProntuario – mensagem contendo dados do prontuário médico de um paciente,
utilizada pelo serviço “Paciente”. Possui diversos registros do tipo ItemProntuario.
● ItemProntuario – mensagem que representa um registro de consulta feito por um médico,
contendo informações sobre sintomas e diagnóstico, utilizada pelo serviço “Paciente”.
● DadosMedicamento – mensagem contendo dados sobre um medicamento, utilizada pelos
serviços “Prescrição” e “Medicamento”.
● DadosExame – mensagem contendo dados sobre um exame médico, utilizada pelos serviços
“Prescrição” e “Exame”.
Os esquemas de mensagens podem ser visualizados na Figura 6.3.
Como o plano da clínica MEDSOA é implementar os serviços utilizando a tecnologia Web
Services, os esquemas de mensagens são formalmente descritos na forma de esquemas XML
na linguagem XSD. A Figura 6.4 mostra como exemplo o esquema “DadosPaciente” escrito em
linguagem XSD.
Após definidos todos os esquemas de mensagens, o arquiteto de serviços procede com a
especificação das interfaces de serviços, quando são definidas as assinaturas das operações,
com suas mensagens de entrada e saída.
Por exemplo, para o serviço “Paciente”, a interface definida pode ser visualizada na Figura 6.5.
Figura 6.3 Esquemas de mensagens dos serviços da clínica MEDSOA.

6 Design 105
Figura 6.4 Exemplo de esquema escrito em XSD.
Figura 6.5 Interface do serviço “Paciente”.
Como os serviços serão implementados como Web Services, as interfaces são formalmente
descritas na linguagem WSDL. A Figura 6.6 apresenta a interface do serviço “Paciente” em
WSDL.
O arquiteto de serviços define também a qual camada pertence cada um dos serviços
especificados, de acordo com o tipo de função executada por cada um deles. A alocação dos
serviços nas camadas pode ser vista na Figura 6.7.
Figura 6.6 Interface do serviço “paciente” escrita em WSDL.

6 Design 107
Figura 6.7 Distribuição dos serviços entre as camadas.
6.2 Especificação de Realização de Serviços

Papel: arquiteto de serviços
Artefatos utilizados: modelo de serviços candidatos, contratos de serviços e
decisões de realização
Artefatos gerados: especificação de serviços
Na atividade de especificação de realização de serviços, conforme pode ser vista
na Figura 6.8, o arquiteto de serviço deve detalhar a especificação de realização de
cada contrato de serviço, de acordo com as decisões de realização tomadas durante
a fase de análise.
O contrato contém somente as informações que são expostas por um serviço
para os consumidores. No entanto, são necessárias mais informações para que seja
possível construir a realização do serviço. O arquiteto de serviços, nesta atividade,
deverá especificar a estrutura interna do serviço, de modo que ela execute as funções
e atenda às políticas definidas no contrato.
Enquanto as decisões de realização tomadas na fase de análise são apenas orien-
tações sobre quais recursos devem ser reusados e como os eventuais gaps devem
ser resolvidos, as especificações de serviços definem detalhadamente a estrutura
e o comportamento dos componentes de serviços e mediações que realizam cada
operação de serviço. A especificação de serviços deve entrar nos detalhes técnicos
dos componentes e mediações, pois deverá servir como insumo para que os desen-
volvedores implementem os serviços.
6.2.1 Especificar componente de serviço

Definir tecnologia de realização de serviços (geralmente baseada em programação
orientada a objetos).
Caso as decisões de realização para as operações de um mesmo serviço sejam
diferentes, podem ser criados diferentes componentes para cada operação e cria-se
Figura 6.8 Especificação de realização de serviços.
então uma classe de fachada que representa o contrato do serviço (interface) e abstrai
para os consumidores a existência de diversos componentes de implementação. Alter-
nativamente, a função de fachada também pode ser executada por uma mediação.
Ao projetar o componente de serviço, o arquiteto de serviços deve definir a im-
plementação da lógica e dos dados.
Por meio de um diagrama de classes ou de componentes da UML, o arquiteto de
serviços deve definir a estrutura interna do componente de serviço. Deve ser definido
um modelo de classes de negócio para suportar a lógica executada pelo serviço, que
pode incluir os seguintes tipos de classes:
● Classes para representar a interface do serviço (de preferência gerada automati-
camente a partir da interface).
● Classes para processamento de mensagens (serialização e desserialização).
● Classes para conversão de protocolo.
● Classes de mensagem.
● Classes de acesso a dados.
● Classes para executar a lógica de cada operação. Definir modelo de dados.
As especificações funcionais de cada operação podem ser definidas na forma

de casos de uso de sistema do tipo caixa-branca (Cockburn, 2000), que descrevem
um determinado processamento expondo detalhes de sua implementação. Podem-se
6 Design 109
usar diagramas de atividades da UML para detalhar a lógica do serviço e diagramas

de sequência ou de colaboração para representar as interações com outros serviços
(composição) ou aplicações legadas. Por utilizarem casos de uso e diagramas da
UML, os serviços especificados podem ser diretamente implementados utilizando
técnicas de orientação a objetos e desenvolvimento baseado em componentes.
O Arquiteto de Serviços deve definir também os modelos de dados lógico e físico,
no caso de a realização do serviço necessitar de persistência de dados.
Nessa atividade, o Arquiteto de Serviços pode também definir a arquitetura física
do componente de serviço e elaborar Diagramas de Implantação para representar
como o componente deverá ser implantado no ambiente de execução.
6.2.2 Especificar mediação

Para especificar a construção de uma mediação, o arquiteto de serviços deve:
● definir protocolo de comunicação do provedor e do consumidor;
● definir formato de dados do provedor e do consumidor;
● especificar conversões de protocolo;
● especificar mapeamento de formatos (de/para);
● especificar lógica de roteamento.
Do mesmo modo que nos componentes de serviços, devem-se definir dependências
com outros serviços e composições. Podem ser usados diagramas UML (colaboração
ou sequência) para representar as interações entre serviços.
Exemplo:
Uma vez decididas as realizações de cada serviço, o arquiteto de serviços partiu para a elabo-
ração das especificações de como cada serviço deveria ser implementado.
De acordo com as decisões de realização tomadas na fase de análise e com os contratos de
serviço definidos, cada realização deverá ser estruturada e especificada.
Serviço “Paciente”
No caso do serviço “Paciente”, que possui operações realizadas por uma aplicação legada e operações
não existentes, o arquiteto de serviços deve especificar mediações e componentes de serviços.
Para encapsular os componentes de serviços e mediações de cada operação, é criada uma
mediação (PacienteMediation), que implementa a interface de serviço, conforme a Figura 6.9.
Desse modo, quando uma operação do serviço “Paciente” for invocada através de sua interface, a
mensagem será recebida pela mediação “PacienteMediation”, que, por sua vez, roteará a mensagem
para um componente de serviço ou mediação de acordo com a operação que for invocada.
Esse é um caso de aplicação do design pattern Service Façade (Fachada de Serviço) (Erl, 2009)
comumente adotado quando um mesmo serviço possui tipos diferentes de realizações para suas
operações. Além de desacoplar as diferentes realizações do contrato, esta alternativa de design
centraliza no ESB a função de receber e rotear as mensagens de invocação aos serviços.
Para as operações “ObterClientePeloNome” e “InserirCliente”, o arquiteto de serviços es-
pecifica as mediações “ObterClientePeloNome” e “InserirCliente” que acessarão o aplicativo
CRM, por intermédio de um adaptador de integração, que por sua vez se comunicará com o
CRM utilizando sua API nativa.
Na operação “ObterClientePeloNome”, a mediação deverá invocar as funções do CRM
“buscarClientePorNome” e “buscarClientePorSobrenome”, passando como parâmetro a palavra
Figura 6.9 Mediação “Paciente Mediation”.
recebida na mensagem de entrada, e então consolidar os resultados em um único conjunto.

Para retornar aos pacientes encontrados, a mediação deve então mapear os dados retornados
pelo adaptador de integração no formato específico do CRM para o formato definido para a
mensagem “DadosPaciente”. Na Figura 6.10, é possível visualizar o diagrama de sequência da
lógica executada pela mediação.
Figura 6.10 Diagrama de sequência da operação “Obter Paciente Pelo Nome”.

6 Design 111
Figura 6.11 Mapeamento de de/para do formato do CRM para o esquema de mensagem.

O arquiteto de serviços deve definir também o mapeamento dos dados do formato da API do
aplicativo CRM para o esquema de mensagens “DadosPaciente” definido no contrato do serviço.
Para tal, ele define um mapa de de/para, indicando como cada campo da mensagem “ClienteCRM”
deve ser mapeado para a mensagem “DadosPaciente”, conforme a Figura 6.11. As eventuais
diferenças entre os campos podem ser solucionadas com funções de manipulação de texto. Por
exemplo, para transformar os campos “nome” e “sobrenome” da mensagem “ClienteCRM” em um
único campo “nome” na mensagem “DadosPaciente”, é utilizada a função de concatenação.
Na operação “InserirPaciente”, o arquiteto de serviços especifica a mediação para mapear
os dados da mensagem “DadosPaciente” para o formato da mensagem “ClienteCRM” e acessar
a função “adicionarCliente” do aplicativo CRM, conforme a Figura 6.12.
Figura 6.12 Diagrama de sequência da operação “Inserir Cliente”.

Para implementar a lógica das operações “ObterProntuarioPaciente” e “AtualizarProntuario-

Paciente” do serviço “Paciente”, o arquiteto de serviços especificou os componentes de serviço
“ObterProntuarioPacienteImpl” e “AtualizarProntuarioPacienteImpl”.
Para recuperar e alterar dados de prontuário de uma base de dados, os componentes deveriam
acessar a classe de acesso a dados “PacienteDAO”, que segue o design pattern DAO (Data Access
Object). A Figura 6.13 exemplifica as interações para uma das operações.
A Figura 6.14 representa a realização do serviço “Paciente” com todos os componentes e
mediações especificados.
Figura 6.13 Diagrama de sequência da operação “ObterProntuarioPaciente”.
Figura 6.14 Diagrama UML de realização do serviço “Paciente”.

6 Design 113
Além desse diagrama, foi elaborado um modelo de dados para representar as tabelas de banco
de dados persistentes acessadas pela classe DAO, conforme a Figura 6.15.
Figura 6.15 Diagrama de modelo de dados.
Serviço “EnviarNotificacao”
Para o serviço “EnviarNotificacao”, cuja decisão de realização foi utilizar um provedor de serviço
na nuvem, o arquiteto de serviços não especificou nenhuma realização, já que seria reusada uma
realização já existente (fornecida pelo provedor de serviços na nuvem Cloud Message).
Outros serviços
Já os demais serviços, que deveriam ser realizados por novos componentes de serviços, foram
projetados pelo arquiteto de serviços de forma semelhante ao serviço “Paciente”: interface de
serviço, mediação encapsuladora, componentes de serviço para cada operação e classes DAO
para acesso ao banco de dados.
6.3 Verificação de Princípios
Papel: arquiteto corporativo
Artefatos utilizados: especificação de serviços e contratos de serviços
Artefatos gerados: não aplicável
Nesta atividade de verificação de princípios, conforme pode ser visto na Figura 6.16,
uma série de verificações é realizada sobre as especificações de serviços com o intuito
de avaliar sua conformidade com os princípios de orientação a serviços.
Figura 6.16 Verificação de princípios.
6.3.1 Validar aderência aos princípios

Os princípios verificados são:
6.3.1.1 Contrato padronizado

Deve-se garantir que os documentos formais criados para descrever o contrato do
serviço (i.e.: esquemas XML e interfaces WSDL) estão em conformidades com as
boas práticas e padrões adotados pela organização (revisão de governança). Exem-
plos de padrões verificados: sintaxe de representação, padrões de formato, padrões
de nomenclatura, padrões de ferramentas, padrões técnicos de interoperabilidade
(WS-I), design patterns.
6.3.1.2 Reusabilidade
Para garantir a reusabilidade de um serviço, deve-se verificar se não é necessário
adicionar operações ou alterar as já existentes ou especificadas para que o serviço
possa vir a ser útil em outro contexto que não o do processo de negócio sendo
desenvolvido. Mesmo que nem todas as operações não venham a ser implementadas
em um primeiro momento, é recomendável que elas já estejam especificadas para
minimizar a necessidade de mudanças posteriores na interface do serviço. A aplicação
de design patterns como Logic Centralization (Centralização de Lógica) (Erl, 2009)
e Contract Centralization (Centralização de Contrato) (Erl, 2009) deve garantir
que o acesso aos dados ou funcionalidade provida por um serviço sejam acessíveis
somente através de seu contrato.
O serviço deve ser concebido como um produto e não como uma aplicação de
finalidade única. A lógica do serviço deve ser a mais agnóstica possível (Competência
Agnóstica).
6 Design 115
6.3.1.3 Granularidade
Deve-se verificar se o nível de granularidade do serviço (a quantidade de lógica en-
capsulada) está de acordo com a camada a que pertence e com o nível de reusabilidade
esperado. Serviços de aplicação devem possuir nível baixo de granularidade, ou seja,
devem ser genéricos para que possam ter maior reusabilidade. Serviços de negócio
podem ter nível mais alto de granularidade, pois têm necessidade menor de reusabi-
lidade e devem poder ser utilizados diretamente pelos serviços de orquestração.
6.3.1.4 Autonomia
Para se obter autonomia em um serviço, deve-se garantir que a lógica encapsulada
é autocontida, isto é, não possui dependências com relação a outros serviços ou
processos. Um serviço deve possuir controle sobre seu próprio ambiente de execução,
de forma a minimizar impactos causados por fatores externos (outros serviços, outras
aplicações). A autonomia pode ser obtida reduzindo-se o acesso compartilhado aos
recursos de um serviço, aumentando o isolamento físico do ambiente de execução
de um serviço ou reduzindo as dependências externas do ambiente de execução de
um serviço.
6.3.1.5 Abstração
Deve-se verificar se o contrato (interface) do serviço está abstraindo detalhes de im-
plementação, ocultando-os dos potenciais consumidores. O serviço deve funcionar
como uma “caixa-preta”, expondo em seu contrato apenas as informações essenciais
para que possa ser utilizado. Detalhes específicos de design e implementação não
podem estar expostos no contrato do serviço.
6.3.1.6 Baixo acoplamento

Para se garantir o baixo acoplamento dos serviços, deve-se verificar se o contrato do
serviço não está limitado por características específicas de um processo de negócio
ou de sua lógica e tecnologia de implementação. O contrato deve ser o mais desaco-
plado possível de elementos externos. A implementação de um serviço deve ser
acoplada ao contrato, nunca o contrário. Desta forma, características específicas
da implementação do serviço (tecnologia de implementação, plataforma, detalhes
técnicos da implementação, aplicações legadas encapsuladas) não devem estar ex-
postas no contrato.
6.3.1.7 Independência de estado

Para se garantir que os serviços sejam independentes de estado, deve-se procurar mi-
nimizar a quantidade de informação de estado armazenada pelo serviço em memória,
armazenando-a nas mensagens trocadas ou na lógica de orquestração do processo de
negócio. Caso seja imprescindível o armazenamento de algum tipo de informação de
estado, podem-se criar mecanismos para delegar os dados de estado a um repositório
de estado externo ao serviço, como uma base de dados persistente.
6.3.1.8 Visibilidade
O contrato do serviço, suas operações, seus dados, sua funcionalidade e suas políticas
devem ser descritos de forma inteligível para os potenciais usuários e devem ser pu-
blicadas em um registro de serviços ou repositório de metadados. Apenas contratos
devem ser publicados (especificações de realização, artefatos de implementação,
artefatos de testes etc. não necessitam ser expostos para potenciais consumidores).
6.3.1.9 Capacidade de composição

Deve-se assegurar que uma composição de serviços especificada esteja de acordo
com os padrões definidos e seja capaz de cumprir os requisitos não funcionais
especificados.
6.3.1.10 Interoperabilidade
Deve-se verificar se os contratos de serviço foram tecnicamente desenhados para serem
interoperáveis, isto é, suportar a implementação de serviços em diversas plataformas
tecnológicas. Para tal, os artefatos técnicos de interface de serviço e esquemas de
mensagens devem ser elaborados utilizando padrões abertos e evitando o uso de ca-
racterísticas e recursos proprietários ou específicos de uma determinada plataforma.
6.3.2 Revisar serviços
A verificação da aderência aos princípios de orientação a serviços pode demandar
alterações nos serviços especificados. Caso isso seja necessário, executam-se nova-
mente alguns passos da atividade de especificação de serviços para que os contratos
dos serviços sejam reprojetados conforme necessário, para se adequar aos princípios
de orientação a serviços.
Pode ser necessário rever também a alocação dos serviços nas camadas de negócio
e de aplicação, caso tenha havido alteração no escopo funcional ou na granularidade
dos serviços.
Exemplo:
O arquiteto corporativo revisa os contratos e especificações de serviços, verificando a aderência
aos princípios de orientação a serviços e a padrões corporativos de especificação contrato e
realização (nomenclatura e separação de documentos) e o uso de design patterns.
Ao verificar o princípio de baixo acoplamento, o arquiteto corporativo recomenda que
os contratos não sejam acoplados à realização encapsulada. A interface do serviço “Enviar
Notificação” do provedor externo Cloud Message, apesar de estar de acordo com os padrões
técnicos e de nomenclatura da organização, gera acoplamento com relação a características
específicas do provedor. O arquiteto corporativo recomenda definir uma nova interface de
serviço “Enviar Notificação” e encapsular a interface do provedor, utilizando uma mediação para
realizar o mapeamento entre as duas interfaces. Deste modo, o contrato fica desacoplado do
provedor de serviço, possibilitando que o provedor possa ser alterado futuramente sem impacto
aos consumidores do serviço.
Como solução, foi especificada uma mediação simples, apenas para servir como ponto de
acesso ao serviço externo, conforme a Figura 6.17 e a Figura 6.18.
6 Design 117
Figura 6.17 Diagrama de componentes do serviço “Enviar Notificação”.
Figura 6.18 Diagrama de sequência da operação “Enviar Notificação”.
Na verificação do princípio de autonomia, o arquiteto corporativo recomenda reduzir o

acesso compartilhado aos recursos do serviço “Paciente”, nesse caso, as funções do aplicativo
CRM acessadas pelo serviço: “buscarClientePeloNome”, “buscarClientePeloSobrenome” e
“adicionarCliente”. Para tal, deve-se evitar que outros serviços e aplicações acessem diretamente
estas funções e acessem somente o serviço através de seu contrato, aplicando o design pattern
Contract Centralization (Centralização de Contrato) (Erl, 2009).
Além disso, o arquiteto corporativo revisa as especificações de realização dos serviços e faz
recomendações de modo a garantir que as realizações dos novos serviços tenham implementa-
ções independentes, isto é, possuam recursos de infraestrutura próprios.
O arquiteto corporativo analisa a especificação de realização do serviço “Paciente” e avalia
sua granularidade como demasiadamente alta para um serviço de entidade, por encapsular
Figura 6.19 Serviços “Paciente” e “Prontuário” com as operações reagrupadas.
diversas funções de uma aplicação legada além de um conjunto de dados próprio. Desta forma,
o arquiteto corporativo aplica o design pattern Service Decomposition (Descomposição de
Serviço) (Erl, 2009), reagrupando as operações de acordo com a realização e dividindo-as entre
os serviços “Paciente” e “Prontuário”, conforme a Figura 6.19.
Para aumentar a reusabilidade dos serviços de entidade “Paciente”, “Prontuário” e “Médico”,
o arquiteto corporativo propõe a criação de novas operações que possam tornar os serviços reusá-
veis em outros contextos e processos de negócio. As novas operações propostas têm como objetivo
a manipulação dos dados providos pelos serviços de entidade, conforme a Figura 6.20.
Figura 6.20 Serviços com novas operações adicionadas.
Neste capítulo os serviços foram detalhados em nível de contrato de serviços e de
componentes de serviço para sua realização. Os serviços são verificados quanto à
aderência aos princípios de orientação a serviços e são revisados. Com o resultado
da revisão, a especificação de serviços pode ser alterada, se necessário.
Assim, os serviços revisados estão prontos para as próximas fases, ou seja, as
fases de construção e de implantação e gerenciamento.
7
Fases complementares
Objetivo
O objetivo deste capítulo é apresentar as fases de construção e de implantação e gerencia-
mento como complemento às fases anteriores.
Na fase de construção os serviços são implementados, orquestrados e testados. A fase de
implantação e gerenciamento se preocupa em publicar e implantar os serviços e, em seguida,
monitorar a sua operação.
Conteúdo
7.1 Construção 119
7.2 Implantação e gerenciamento 124
7.1 Construção
Na fase de construção, são desempenhadas atividades com o intuito de se obter os
serviços executáveis devidamente integrados e testados, prontos para serem im-
plantados.
A Figura 7.1 apresenta as atividades de implementação, orquestração e teste de
serviços da fase de construção, conforme descritas a seguir.
7.1.1 Implementação de serviços

Papel: desenvolvedor
Artefatos utilizados: contratos de serviços, especificação de serviços
Artefato gerado: componentes de serviço executáveis
A atividade de implementação de serviços tem por objetivo implementar mediação
e componentes de serviço, de acordo com os contratos e especificações de realização
de serviço, conforme pode ser vista na Figura 7.2.
A atividade de implementação de serviços é executada por desenvolvedores, que
receberão as especificações dos serviços e implementarão os componentes e media-
ções necessários. A partir destas atividades, pode ser seguido o ciclo tradicional de
desenvolvimento orientado a objetos e/ou baseado em componentes.
119
Figura 7.1 Atividades da fase de construção.
Figura 7.2 Implementação de serviços.
Dependendo das ferramentas utilizadas, as seguintes etapas podem ser cumpridas

durante a implementação.
Diversos design patterns, ferramentas e frameworks podem ser utilizados para
implementar serviços. Este livro não tem como objetivo recomendar ou avaliar o
uso destas técnicas, mostrando apenas sua relação com as atividades de modelagem,
análise e design.
Nos casos de serviços realizados por novos componentes de serviços a serem
implementados, o desenvolvedor deverá construir a realização conforme especificada
pelo arquiteto de serviços. Quando é utilizada uma plataforma tecnológica orientada
a objetos, o desenvolvedor deverá implementar as classes conforme especificado nos
modelos e diagramas da UML contidos na especificação.
Algumas etapas da implementação de componentes de serviço são:
7 Fases complementares 121
● criação ou geração automática de classes de mensagens a partir dos documentos

de esquemas de mensagens;
● criação ou geração automática de classes de fachada a partir dos documentos de
interface de serviço;
● criação de classes de acesso a dados;
● integração com APIs para acesso a aplicações legadas reusadas;
● criação de classes de negócio para representar e executar a lógica definida para
cada operação de serviço, conforme descrito na especificação de serviços;

● criação ou geração automática de classes de infraestrutura para processamento de
mensagens e comunicação específicas da tecnologia de serviços utilizada (Web

Services, REST etc.).
Nos casos em que a realização de um serviço envolve o reuso de uma aplicação
legada ou serviço existente, o serviço poderá ser realizado por uma mediação no
ESB. O barramento será o responsável por criar o acesso às aplicações legadas e
resolver eventuais gaps existentes. Algumas etapas envolvidas na implementação
de mediações são:
● criação ou importação de definições de mensagens para representar os dados que
serão manipulados pela mediação;
● criação ou importação de definições de interfaces que serão utilizadas para expor
a mediação e para invocar serviços existentes;

● criação de mapas para realizar a conversão entre formatos de mensagens e tipos
de interfaces, conforme necessário;

● implementação da lógica de mediação descrita na especificação de serviços, de
forma a compor um fluxo de dados entre os conectores de exposição da mediação

e os conectores de invocação de serviços existentes.
7.1.2 Orquestração de serviços
Papel: desenvolvedor
Artefatos utilizados: modelo de processo to-be, contratos de serviços e especifi-
cação de serviços
Artefatos gerados: processo orquestrado
Uma vez especificados os serviços e suas interfaces WSDL, é realizada a orques-
tração dos serviços, conforme pode ser vista na Figura 7.3. Se o modelo de processo
to-be estiver representado na notação BPMN, ele pode ser convertido em um modelo
na linguagem WS-BPEL. Caso contrário, a lógica de processo pode ser descrita
manualmente em WS-BPEL ou em outra linguagem. Tal lógica deve ser especificada
de modo que as chamadas dos serviços sejam devidamente orquestradas com as
interfaces de serviços definidas e revisadas.
O objetivo dessa atividade é definir a lógica de orquestração necessária para
executar o processo, como manipulação de variáveis de processo, gerenciamento de
informação de estado, tratamento de exceções e compensação.
Figura 7.3 Orquestração de serviços.
O processo orquestrado deverá ser encapsulado por um serviço da camada de

orquestração composto por serviços das camadas de negócio e aplicação. Por isso,
deverá ser descrito em sua própria especificação de serviços, que conterá a lógica de
orquestração definida.
7.1.3 Testes de serviços
Papel: testador
Artefatos utilizados: contratos de serviços, processo orquestrado e componentes
de serviço executáveis
Artefato gerado: evidências de teste
Sendo uma aplicação SOA uma composição de serviços, deve-se garantir que as ins-
tâncias desses serviços estejam disponíveis aos desenvolvedores para serem testadas.
Também, deve-se garantir uma infraestrutura necessária aos testes em ambientes
distribuídos.
A atividade de testes de serviços, conforme pode ser vista na Figura 7.4, deve
basicamente verificar se os requisitos especificados foram atendidos e se os serviços
se comportam de acordo com as políticas definidas.
Para isso ocorrer, devem-se executar os serviços e comparar os resultados com
seus contratos e especificações.
Figura 7.4 Testes de serviços.
Os objetivos de um teste de serviço devem cobrir os aspectos funcionais e não

funcionais. Como aspecto funcional considera-se a lógica especificada pelo contrato
do serviço. Como aspecto não funcional consideram-se, por exemplo, o desempenho e
a segurança do serviço.
A estratégia de teste deve considerar os serviços individuais e composições de
serviços gradativamente até a solução completa integrada.
Os testes devem ser realizados baseando-se na especificação de serviço e em um
plano de testes, e, como resultado, deve-se gerar um relatório de testes reportando
os casos de teste executados e os resultados obtidos.
Os tipos de teste que podem ser executados são:
a) Testes de unidade
O testador deve executar testes de unidade em cada componente de serviço ou
mediação, testando cada operação de acordo com o contrato e com os requisitos
funcionais e não funcionais.
Os testes de unidade aplicam-se à camada de componentes de serviço da arqui-
tetura de referência.
b) Testes de contrato de serviço

O testador realiza testes verificando se os serviços estão aderentes ao contrato, tan-
to funcionalmente quanto não funcionalmente (políticas do contrato). Teste o serviço
como uma caixa-preta, reproduzindo o ponto de vista do consumidor do serviço.
Os testes de contrato aplicam-se à camada de serviços da arquitetura de referência.
c) Testes de orquestração
O testador valida a execução dos processos de negócio completos, testando a lógica
do processo orquestrado integrado aos serviços, composições e mediações.
Os testes de orquestração aplicam-se à camada de processos de negócio da ar-
quitetura de referência.
d) Testes de usuário
O testador valida a solução como um todo sob o ponto de vista dos usuários, exe-
cutando os testes através das interfaces consumidoras. Serve como teste de aceitação
do usuário sobre toda a solução orientada a serviços.
Os testes de usuário aplicam-se à camada de interfaces consumidoras da arqui-
tetura de referência.
e) Testes não funcionais
Apesar de alguns requisitos não funcionais serem testados em testes de con-
trato de serviço, podem ser necessários outros testes para a validação da solução
orientada a serviços como um todo, frente a necessidades específicas de segurança
e desempenho.
Nessa etapa, faça testes de invasão, testes de carga, testes de tolerância a falhas,
entre outros.
7.2 Implantação e Gerenciamento

Após a fase de construção, o ciclo de vida prossegue com as fases de implantação e
gerenciamento, conforme a Figura 7.5. Estas fases não são abordadas na modelagem,
na análise e no design, pois não são diretamente afetadas por elas. Por estye motivo, as
atividades destas fases são descritas apenas de maneira breve nas próximas seções.
7.2.1 Publicação de serviços
Papel: administrador de serviços
Artefatos utilizados: contratos de serviços e especificação de serviços
Artefato gerado: serviços publicados no registro de serviços e no repositório de
metadados
A atividade de publicação de serviços tem por objetivo a catalogação dos contratos
de serviços no registro de serviços e disponibilização dos metadados e especificações
de serviço no repositório de metadados, conforme a Figura 7.6.
Nessa atividade, o administrador de serviços deve realizar também a definição
da localização física e dos endereços de acesso de cada serviço a ser implantado.
Trata-se da publicação dos endereços físicos no registro de serviços.
Figura 7.5 Atividades da fase de implantação e gerenciamento.
Figura 7.6 Publicação de serviços.
A publicação pode ocorrer mais cedo no ciclo de vida (após as decisões de rea-
lização ou revisão dos contratos), caso o registro de serviços suporte a indicação
do status dos serviços. Nestes casos, o contrato de serviço pode ser publicado, mas
com a indicação de que ele se encontra “Em especificação”, “Em construção” ou
“Em testes”.
7.2.2 Implantação de serviços

Artefatos utilizados: componentes de serviço executáveis e processo orquestrado
Artefato gerado: componentes de serviço implantados
A atividade de implantação de serviços tem por objetivo implantar os módulos
executáveis dos componentes de serviço, mediações, processos de negócio orques-
trados e demais elementos da solução orientada a serviços em seus respectivos
ambientes de execução, conforme a Figura 7.7.
O procedimento de implantação de serviços pode passar por etapas como:
● geração dos pacotes de implantação a partir dos artefatos de implementação;
● implantação dos pacotes de implantação em ambiente de homologação;
● testes de aceitação e homologação da solução orientada a serviços;
● implantação dos pacotes de implantação em ambiente de produção.
7.2.3 Manutenção de serviços
Artefatos utilizados: componentes de serviço implantados e métricas, alertas
e incidentes
Artefatos gerados: componentes de serviço implantados e ações corretivas e pre-
ventivas
Figura 7.7 Implantação de serviços.

Figura 7.8 Manutenção de serviços.
A atividade de manutenção de serviços tem por objetivo manter os serviços em

operação e assegurar que as políticas e SLAs definidas estejam sendo respeitadas,
conforme a Figura 7.8.
Por meio da monitoração de métricas de desempenho dos serviços (por exem-
plo, tempo de resposta, volume de mensagens, tamanho de mensagens e número de
requisições simultâneas), o administrador de serviços pode verificar se as SLAs e os
requisitos não funcionais dos serviços estão sendo atendidos. Algumas ferramentas
de monitoração permitem também que o administrador receba notificações caso
alguma SLA seja violada.
Incidentes ocorridos durante a execução dos serviços, como exceções inesperadas e in-
disponibilidade, devem ser verificados e solucionados pelo administrador de serviços.
O administrador de serviços pode fazer uso dos dados de desempenho e monitorar
o uso de recursos (como capacidade de processamento, memória, armazenamento e
tráfego de rede) para dimensionar a capacidade da infraestrutura de modo a prevenir
a degradação do desempenho em momentos de pico e evitar violações de SLAs. Os
ajustes de infraestrutura podem ir desde mudanças de configuração até a adição de
recursos de hardware.
7.2.4 Monitoração de atividades de negócio

Papel: gestor de processos
Artefatos utilizados: métricas de processo de negócio
Artefatos gerados: necessidades de negócio
Figura 7.9 Monitoração de atividades de negócio.
A atividade de monitoração de atividades de negócio tem por objetivo monitorar o

desempenho dos processos de negócio, avaliando métricas como tempo de execução,
custos, receitas, uso de recursos e indicadores de eficiência (percentual de aprovações,
percentual de solicitações aceitas), conforme a Figura 7.9.
O gestor de processos acompanha o andamento do processo, avalia indicadores
consolidados (KPIs) e analisa relatórios de dados históricos, para ter uma visão
clara sobre o desempenho do processo e validar se as metas de negócio estão sendo
atingidas como resultado da implantação da solução orientada a serviços.
Para tal, o gestor de processo faz uso de ferramentas de monitoração de atividade
de negócio (BAM) e de ferramentas de Business Intelligence e Data Warehousing.
Analisando os dados de negócio, o gestor de processos pode identificar gargalos
e pontos de melhoria nos processos, de modo a dar origem a um novo conjunto de
necessidades e problemas que possibilitarão uma nova iteração no ciclo de vida com o
intuito de trazer melhorias aos processos de negócio automatizados. O modelo de pro-
cesso to-be implementado torna-se o modelo de processo as-is desta nova iteração.
7.3 Considerações do Capítulo

Neste capítulo foram apresentadas as fases de construção e de implantação e ge-
renciamento. A fase de construção se preocupa em implementar a especificação de
serviços da fase de design. Os serviços são orquestrados e testados para verificar se
os requisitos funcionais e não funcionais especificados foram atendidos. A fase de
implantação e gerenciamento se preocupa em criar os registros de serviços para os
consumidores. Uma vez publicados, os serviços são monitorados quanto à qualidade
de serviço (QoS) oferecida e também quanto ao desempenho dos processos de
negócio. Nesta fase, o serviço passa por melhorias dos processos de negócio podendo
retornar à fase de modelagem.
8
Considerações finais
Objetivo
O objetivo deste capítulo é apresentar algumas considerações sobre a modelagem, a análise e
o design discutidas neste livro.
Conteúdo
8.1 Algumas considerações 129
8.1 Algumas Considerações

O paradigma de orientação a serviços tem sido apresentado de forma, às vezes,
confusa e simplificada, com o uso de Web Services. Algumas empresas e desenvolve-
dores de TI consideram a tecnologia de Web Services erroneamente como sinônimo
do paradigma. O paradigma tem origem no negócio em que a organização precisa
ter melhor retorno e preservação de investimentos em Tecnologia da Informação, e
os Web Services se popularizaram como tecnologia de implementação de serviços
interoperáveis de baixo acoplamento dentro de uma arquitetura SOA.
Este livro torna o paradigma mais prático. Para introduzir o paradigma de orien-
tação a serviços de maneira mais precisa, foi apresentado um estudo aprofundado
sobre os conceitos relacionados a SOA, focando em um dos principais desafios en-
frentados pelas organizações na adoção do paradigma de orientação a serviços, que
é a dificuldade da análise e do design de serviços.
Porém, tomou-se o cuidado de definir quais são as entradas e saídas necessárias
para as atividades de modelagem, análise e design, enfatizando os modelos de negócio
como entradas e especificações de serviços como saídas.
A modelagem, a análise e o design baseiam-se nos conceitos de SOA e na análise
dos métodos existentes. A modelagem, a análise e o design foram elaboradas de modo
a unificar os métodos analisados e torná-lo mais práticos. Foram empregadas no livro
boas práticas derivadas de todos os métodos analisados, sendo elas integradas em
um fluxo de trabalho único.
129
Para facilitar o entendimento, foi adotada uma dinâmica de fases sequenciais, como
um processo cascata de software. Porém, as fases discutidas são flexíveis podendo
ser aplicadas de maneira iterativa e incremental como no RUP.
A realização de um caso (Apêndice B) mostra a aplicabilidade da modelagem, da
análise e do design em projetos reais de contextos distintos. As fases foram aplicadas
em um projeto de criação de uma nova solução orientada a serviços, com o uso da
abordagem BPM. Foi empregada a tecnologia Web Services para especificar e im-
plementar os serviços.
A modelagem, a análise e o design são especialmente efetivas na análise de reuso
de recursos existentes e na manutenção da governança de serviços. Tais características
suportam dois pontos críticos da orientação a serviços. Um deles é a redução do custo
de projetos e aumento da agilidade na entrega de soluções, obtidos pelo reuso. E o
outro é a necessidade de governança sobre o portfólio de serviços da organização.
A modelagem, a análise e o design orientados a serviços são muito úteis às
organizações que estão procurando reduzir os custos com TI. E, também, para as
organizações serem mais produtivas e responderem mais rapidamente às necessidades
de negócio.
Referências
BELL, M. Service-Oriented Modeling: Service Analysis, Design, and Architecture. Estados Unidos: Wiley, 2008.
384 p.
BIEBERSTEIN, N. et al. Service-Oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap.
Estados Unidos: IBM Press, 2005. 272 p.
BRAY, T. et al. Extensible Markup Language (XML) 1.1. Second Edition. W3C Recommendation, 2006. Disponível
em: <http://www.w3.org/TR/2006/REC-xml11-20060816/>. Acesso em 27 de março de 2008.
CHRISTENSEN, E. et al. Web Services Description Language (WSDL) 1.1. W3C Note, 2001. Disponível em:
<http://www.w3.org/TR/wsdl>. Acesso em 1º de dezembro de 2008.
COCKBURN, A. Writing Effective Use-Cases. Boston: Addison Wesley, 2000. 304 p.
ENDREI, M. et al. Patterns: Service-Oriented Architectures and Web Services. Estados Unidos: IBM Redbooks,
2004. 348 p.
ERL, T. Service-Oriented Architecture: Concepts. Technology and Design. Estados Unidos: Prentice Hall, 2005.
792 p.
________. ERL,T.SOA: Principles of Service Design. Estados Unidos: Prentice Hall, 2007. 608 p.
________. ERL,T.SOA Design Patterns. Estados Unidos: Prentice Hall, 2009. 800 p.
________. ERL,T.Web Service Contract Design and Versioning for SOA. Estados Unidos: Prentice Hall, 2008. 826 p.
FALLSIDE, D. C.; WALMSLEY, P. XML Schema Part 0: Primer. Second Edition. W3C Recommendation, 2004.
Disponível em: <http://www.w3.org/TR/xmlschema-0/>. Acesso em 1º de dezembro de 2008.
FUGITA, H. S.; HIRAMA, K. MAPOS. Método de Análise e Projeto Orientado a Serviços. In: Anais do Congresso
Internacional de Gestão de Tecnologia e Sistemas de Informação (CONTECSI). 5., São Paulo, 2008(a).
________. Method for Service-Oriented Analysis and Design. In: Proceedings of the International Conference on
Software Engineering Research and Practice (SERP). Las Vegas: CSREA Press, 2008(b).
GORNIK, D. IBM Rational Unified Process: Best Practices for Software Development Teams. IBM Whitepapers,
2003. Disponível em: <ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/rup_bestpractices.
pdf>. Acesso em 27 de maio de 2007.
HUHNS, M. N.; SINGH, M. P. Service-Oriented Computing: Key Concepts and Principles. IEEE Internet Computing,
v. 9, nº 1, p. 75-81, jan.-fev. 2005.
JESTON, J.; NELIS, J. Business Process Management: Practical Guidelines to Successful Implementations. 2. ed.
Estados Unidos: Butterworth-Heinemann, 2008. 504 p.
KEEN, M. et al. Patterns: SOA with an Enterprise Service Bus. Estados Unidos: IBM Redbooks, 2005. 386 p.
KENNEY, L. F.; PLUMMER, D. C. Magic Quadrant for Integrated SOA Governance Technology Sets. Gartner
RAS Core Research Note. Gartner, 2007.
KRAFZIG, D.; BANKE, K.; SLAMA, D. Enterprise SOA. Estados Unidos: Prentice Hall, 2004. 408 p.
KRUTCHEN, P. The Rational Unified Process: An Introduction. 2. ed. Boston: Addison Wesley, 2000. 272 p.
MARKS, E. A.; BELL, M. Service Oriented Architecture: A Planning and Implementation Guide for Business and
Technology. Hoboken, Estados Unidos: John Wiley & Sons, 2006. 384 p.
OASIS SOA REFERENCE MODEL TC. Reference Model for Service Oriented Architecture 1.0. OASIS Open,
2006. 31 p.
OASIS WS-BPEL TC. Web Services Business Process Execution Language, version 2.0. OASIS Open, 2007.
Disponível em: <http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html>. Acesso em 1º de dezembro
de 2008.
THE OPEN GROUP. Definition of SOA, version 1.1. The Open Group, 2006. Disponível em: <http://www.open-
group.org/projects/soa/page.tpl?CALLER=doc.tpl&ggid=1574>. Acesso em 21 de agosto de 2007.
131
________. SOA Reference Architecture, draft version 10. The Open Group, 2009. Disponível em: <http://opengroup.
org/projects/soa-ref-arch/>. Acesso em 0 9 de dezembro de 2011.
PAPAZOGLOU, M. P. Service-Oriented Computing: Concepts, Characteristics and Directions. In: Proceedings of
the International Conference on Web Information Systems Engineering. (WISE), 4., Roma, 2003. Roma: IEEE
Computer Society, 2003. p. 3-12.
PAPAZOGLOU, M. P.; VAN DEN HEUVEL, W. J. Service-Oriented Design and Development Methodology. In:
International Journal of Web Engineering and Technology (IJWET), v. 2, nº 4, p. 412-442, 2006.
PERREY, R.; LYCETT, M. Service-Oriented Architecture. In: Proceedings of the Applications and the Internet
Workshops. Uxbridge, 2003. p. 116-119.
RAMOLLARI, E.; DRANIDIS, D.; SIMONS, A. J. H. A Survey of Service Oriented Development Methodologies.
In: Proceedings of the European Young Researchers Workshop on Service Oriented Computing (YR-SOC),
2., Leicester, 2007. p. 75-80.
RUMBAUGH, J.; JACOBSON, I.; BOOCH, G. The Unified Modeling Language Reference Manual. 2. ed. Estados
Unidos: Addison Wesley, 2004. 752 p.
SHUJA, A. K.; KREBS, J. IBM Rational Unified Process Reference and Certification Guide: Solution Designer.
Estados Unidos: IBM Press, 2007. 307 p.
ZIMMERMANN, O. et al. Analysis and Design Techniques for Service-Oriented Development and Integration.
Stuttgart: IBM Press, 2005.
Bibliografia complementar
BAJWA, I. S.; SAMAD, A.; MUMTAZ, S. et al. BPM Meeting with SOA: A Customized Solution for Small
Business Enterprises. In: International Conference on Information Management and Engineering (ICIME’09).
p. 677-682, 2009.
CHAPIN, N. Software Characteristics of SOA Projects. In: Proceedings of the 11th International Conference on
Product Focused Software (PROFES'10). p. 152-157, 2010.
DAN, A.; JOHNSON, R. D.; CARRATO, T. SOA Service Reuse by Design. In: Proceedings of the 2nd International
Workshop on Systems Development in SOA Environments (SDSOA’08). p. 25-28, May 2008.
EL YAMANY, H. F.; CAPRETZ, M. A. M.; ALLISON, D. S. Quality of Security Service for Web Services within
SOA. In: World Conference on Services – I. p. 653-660, 2009.
EMIG, C.; WEISSER, J.; ABECK, S. Development of SOA-Based Software Systems – An Evolutionary Programming
Approach. In: Proceedings of the Advanced International Conference on Telecommunications and International
Conference on Internet and Web Applications and Services (AICT/ICIW 2006). 2006.
GRONOSKY, A.; ATIGHETCHI, M.; PAL, P. Understanding the Vulnerabilities of a SOA Platform – A Case Study.
In: 9th IEEE International Symposium on Network Computing and Applications (NCA). p. 182-187, 2010.
GU, Q.; VAN VLIET, H. SOA Decision Making – What do We Need to Know. In: Proceedings of the 2009 ICSE
Workshop on Sharing and Reusing Architectural Knowledge (SHARK’09). p. 25-32, May 2009.
GU, Q.; LAGO, P. A Stakeholder-Driven Service Life Cycle Model for SOA. In: 2nd International Workshop on
Service Oriented Software Engineering: In Conjunction with the 6th ESEC/FSE Joint Meeting (IW-SOSWE’07).
p. 1-7, September 2007.
________. SOA Process Decisions: New Challenges in Architectural Knowledge Modeling. In: Proceedings of the 3rd
International Workshop on Sharing and Reusing Architectural Knowledge (SHARK’08). p. 3-10, May 2008.
HAU, T.; EBERT, N.; HOCHSTEIN, A.; BRENNER, W. Where to Start with SOA: Criteria for Selecting SOA Projects.
In: Proceedings of the 41st Annual Hawaii International Conference on System Sciences. p. 1-9, 2008.
KARANDE, A. M.; CHUNEKAR, V. N.; MESHRAM, B. B. Intelligent Database for the SOA using BPEL. In:
Proceedings of the 2011 International Conference on Communication, Computing & Security (ICCCS’11).
p. 281-284, February 2011.
KRÜGER, I. H.; MATHEW, R. Systematic Development and Exploration of Service-Oriented Software Architectures.
In: Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA’04). 2004.
KULKARNI, N.; DWIVEDI, V. The Role of Service Granularity in a Successful SOA Realization: A Case Study.
In: IEEE Congress on Services – Part I. p. 423-430, 2008.
LEE, Y. C.; MA, C. M.; CHOU, S. C. A Service-Oriented Architecture for Design and Development of Middleware.
In: Proceedings of the 12th Asia-Pacific Software Engineering Conference (APSEC’05). 2005.
LI, B. Research on SOA and Component Oriented Technology in Development of Large System. In: International
Symposium on Computational Intelligence and Design (ISCID). v. 1. p. 20-23, 2010.
MULIK, S.; AJGAONKAR, S.; SHARMA, K. Where Do You Want to Go in Your SOA Adoption Journey? IT Pro-
fessional. v.10, I. 3. p. 36-39, 2008.
O'BRIEN, L.; BASS, L.; MERSON, P. Quality Attributes and Service-Oriented Architectures. Technical Note. CMU/
SEI-2005-TN-014. Carnegie Mellon University. September 2005. 30p.
O'BRIEN, L.; BREBNER, P.; GRAY, J. Business Transformation to SOA: Aspects of the Migration and Performance
and QoS Issues. In: Proceedings of the 2nd International Workshop on Systems Development in SOA Environments
(SDSOA’08). p. 35-40, May 2008.
O'BRIEN, L.; GIBSON, J.; GRAY, J. A Method for Selecting SOA Pilot Projects Including a Pilot Metrics Framework.
In: Proceeding of the 33rd International Conference on Software Engineering (ICSE’11). p. 25-32, May 2011.
PAPAZOGLOU, M. P. Web Services: Principles and Technology. September 23, 2007.
133
PEI, S.; CHEN, D. Implementation of Web Services Composition System Based on SOA. In: International Conference
on Uncertainty Reasoning and Knowledge Engineering (URKE). v. 2. p. 82-85, 2001.
SCHEPERS, T. G. J.; IACOB, M. E.; VAN ECK, P. A. T. A Lifecycle Approach to SOA Governance. In: Proceedings
of the 2008 ACM Symposium on Applied Computing (SAC’08). p. 1.055-1.061, March 2008.
SETH, A.; AGARWAL, H.; SINGLA, A. R. Designing a SOA Based Model. SIGSOFT Software Engineering Notes,
v. 36, I. 5, p. 1-7, September 2011.
SNEED, H. M. Integrating Legacy Software into a Service Oriented Architecture. In: Proceedings of the Conference
on Software Maintenance and Reengineering (CSMR’06). 2006.
STAROSTA, B. S.; STIREWALT, R. E. K.; DILLON, L. K. Contracts and Middleware for Safe SOA Applications.
In: Proceedings of the International Workshop on Systems Development in SOA Environments (SDSOA’07).
May 2007.
STOJANOVIC, Z.; DAHANAYAKE, A.; SOL, H. Modeling and Design of Service-Oriented Architecture. In: IEEE
International Conference on Systems, Man and Cybernetics. p. 4147-4152.
WIECZOREK, S.; STEFANESCU, A. Service Integration: A Soft Spot in the SOA Testing Stack. In: 5th Central
and Eastern European Software Engineering Conference in Russia (CEE-SECR). p. 211-216, 2009.
YANG, J. Web Service Componentization. Communication of the ACM. v. 46, nº 10, p. 35-40, October 2003.
YOON, H.; JI, E.; CHOI, B. Building Test Steps for SOA Service Orchestration in Web Service Testing Tools. In:
Proceedings of the 2nd International Conference on Ubiquitous Information Management and Communication
(ICUIMC’08). p. 555-557, January 2008.
YU, W. D.; ONG, C. H. A SOA Based Software Engineering Design Approach in Service Engineering. In: IEEE
International Conference on e-Business Engineering (ICEBE’09). p. 409-416, 2009.
ZHANG, L. J.; ZHANG, J. Componentization of Business Process Layer in the SOA Reference Architecture. In:
IEEE International Conference on Services Computing (SCC’09). p. 316-323, September 2009.
Apêndice A
Elementos gráficos usados no livro
135
Apêndice B
Estudo de caso
Aplicando a modelagem, a análise e o design em uma instituição bancária
B.1 Contexto do estudo de caso

O exemplo de aplicação de modelagem, análise e design descrito a seguir trata da automa-
ção de um processo de negócio da instituição bancária fictícia BANCO SOA. O processo
de negócio em questão é o “Cadastro de Cliente”, que descreve a lógica de negócio para
avaliação e cadastro de um novo cliente da instituição. Trata-se de um processo de pré
-cadastro de pessoas físicas e jurídicas, pelo qual novos clientes em potencial abrirão
uma conta, obterão um financiamento ou solicitarão um cartão de crédito.
No estudo de caso, partimos de uma situação em que o processo é quase intei-
ramente manual, sendo apoiado somente pelo sistema de cadastro de clientes, uma
aplicação legada construída com tecnologia baseada em componentes. A instituição
bancária decide adotar as abordagens SOA em conjunto com uma plataforma de BPM
para realizar a automação do processo de negócio.
B.2 Modelagem
A fase de modelagem tem como objetivo elaborar os modelos de processo de negócio,
isto é, documentar o processo de negócio na sua forma atual (as-is) e o processo
futuro (to-be), contendo as mudanças propostas.
Modelagem de Processo as-is
Essa tarefa tem como objetivo elaborar os modelos de processo de negócio, isto é,
documentar o processo de negócio na sua forma atual (as-is) e o processo futuro
(to-be), contendo as mudanças propostas.
O modelo de processo as-is deve ser levantado por um analista de processos
junto às áreas envolvidas na execução manual do processo atual. Com base neste
levantamento, o analista de processos deve documentar o modelo de processo as-is,
através de diagramas (por exemplo, diagrama de atividades da UML ou notação
BPMN) e descrições textuais.
Na Figura B.1, é apresentado um diagrama do processo as-is de cadastro de cliente
em notação BPMN.
O processo se dedica a cadastrar clientes. Assim, após o cliente preencher a ficha
cadastral, o atendente da agência verifica se o cliente já é ou não cadastrado no sistema.
137
138 Apêndice B
Figura B.1 Diagrama do processo as-is (cadastro de cliente).
Se for, o processo é simplesmente interrompido. Caso contrário, o CPF ou CNPJ

do cliente é verificado. Caso haja algum problema, o cadastro é negado e o cliente
é informado pelo atendente da agência. Caso contrário, uma série de documentos
é determinada pelo back office. Os documentos recebidos são digitalizados pelo
atendente da agência e conferidos pelo back office. Caso haja algum problema com
os documentos, uma nova visita é agendada pelo atendente da agência para sanar os
problemas encontrados. Caso contrário, os dados do cliente são digitados no sistema
e o cliente é informado sobre o sucesso de seu cadastro pelo atendente da agência.
Modelagem de Processo to-be

O analista de processos propõe automatizar parte do processo na plataforma BPMS,
em que o fluxo do processo é orquestrado pela plataforma e apoiado por um conjunto
de serviços.
O diagrama do modelo de processo to-be pode ser visualizado na Figura B.2.
Observe que, nesta proposta, uma parte das tarefas é atribuída ao papel sistema (ver
legenda), que representa a plataforma BPMS que orquestra as chamadas a serviços
e tarefas humanas.
Como pode ser visto, grande parte das tarefas originais do atendente da agência
foi atribuída ao sistema.
Um modelo de negócio pode ser composto por: diagrama do processo de negócio,
documento de especificação (de tarefas e descrição textual de regras de negócio).
Complementando o diagrama do processo, o analista de processos elabora uma
descrição textual de cada tarefa, detalhando os passos envolvidos em sua execução.
A Tabela B.1 apresenta as descrições de cada tarefa do processo to-be.
Apêndice B 139
Figura B.2 Diagrama do processo to-be (cadastro de clientes).
Tabela B.1 Descrição de tarefas do processo to-be (cadastro de clientes)
Tarefa Descrição
Informar dados do O atendente da agência preenche um formulário Web com os dados
cliente cadastrais do cliente (nome, CPF/CNPJ, endereço, telefone, e-mail etc.).
O formulário valida os dados inseridos, como formato de CPF, CNPJ etc.
Verificar existência O sistema verifica no cadastro se o cliente com o CPF ou CNPJ
do cliente informado já existe.
Enviar notificação O sistema envia um e-mail ao cliente informando que seu cadastro já
de cliente existente existe no banco.
Verificar situação O sistema consulta os serviços do Serasa e do SPC para verificar a
do CPF/CNPJ situação de crédito do CPF ou CNPJ do cliente.
Enviar notificação de O sistema envia um e-mail ao cliente informando que seu cadastro foi
negação de cadastro negado, pois sua situação de crédito encontra-se irregular.
Determinar lista O sistema verifica quais documentos devem ser apresentados
de documentos obrigatoriamente pelo cliente de acordo com seu tipo (pessoa física ou
jurídica).
Receber e digitalizar O atendente da agência recebe os documentos físicos do cliente e os
documentos digitaliza, para que o sistema armazene uma cópia eletrônica deles.
Conferir documentos O Back-Office analisa os documentos digitalizados e verifica se todos
os documentos obrigatórios foram entregues e são válidos.
Reagendar visita O atendente da agência telefona para o cliente por telefone e agenda
uma visita para que o cliente traga os documentos necessários à agência.
Gravar dados do cliente O sistema grava no cadastro os dados do novo cliente.
Enviar notificação de O sistema envia um e-mail ao cliente informando que seu cadastro foi
sucesso realizado com sucesso.
140 Apêndice B
Figura B.3 Casos de uso do processo cadastro de cliente.
Especificação de requisitos
Além do modelo de processo to-be, o analista de processos elabora também uma
especificação de requisitos, que provê um detalhamento adicional sobre como o
processo deverá ser automatizado, no aspecto funcional e não funcional.
Além de definir requisitos não funcionais, como tempo de resposta e número
de usuários suportados, o analista de processos elabora especificações de casos de
uso para descrever as interações dos usuários com o sistema nas tarefas humanas. A
Figura B.3 representa os casos de uso elaborados.
B.3 Análise
Na fase de análise, o objetivo é identificar os serviços, analisar gap e verificar se os
serviços são realizáveis.
Identificação de Serviços Candidatos
Após a elaboração do modelo de processo to-be, composto pelo diagrama de processo
mais as descrições de tarefas do processo, o arquiteto de serviços inicia a identificação
de serviços candidatos. Esta atividade recebe como entrada o modelo de processo
to-be e tem como objetivo definir um conjunto inicial de serviços, identificados a
partir do processo.
As operações candidatas devem ser identificadas a partir da análise das descrições
das tarefas, seguindo a sequência das tarefas determinada pelo diagrama de processo.
No texto de descrição de cada tarefa, é possível identificar funções que devem ser
executadas pelo sistema, tanto nas tarefas do sistema quanto nas tarefas humanas.
Em alguns casos, uma tarefa inteira pode ser considerada uma operação candidata,
enquanto, em outros, apenas alguns passos de uma tarefa podem ser considerados
operações candidatas. As operações identificadas nas tarefas do processo são listadas
na Tabela B.2.
Apêndice B 141
Tabela B.2 Operações candidatas do processo
Tarefa Operação Candidata

Informar dados do cliente validar número de CPF
validar número de CNPJ
validar dados do cliente
Verificar existência de cliente verificar existência de cliente
Enviar notificação de cliente existente enviar e-mail
Verificar situação do CPF/CNPJ consultar Serasa

consultar SPC
Enviar notificação de negação de cadastro enviar e-mail
Determinar lista de documentos consultar documentos obrigatórios
Receber e digitalizar documentos armazenar documento
Conferir documentos (nenhuma operação)
Reagendar visita (nenhuma operação)
Gravar dados do cliente gravar dados do cliente
Enviar notificação sucesso enviar e-mail
Após a identificação, as operações candidatas devem ser agrupadas em serviços

candidatos, baseando-se na similaridade e correlação entre eles. Como orientação
geral, procura-se agrupar operações que manipulem os mesmos tipos de dados ou
que executem lógica semelhante.
Para as operações que manipulam dados de cliente, pode-se criar um serviço
“Cliente”. O mesmo critério pode ser utilizado para criar um serviço “Documento”.
Já as consultas ao Serasa e ao SPC, por serem operações de lógica semelhante, podem
ser agrupadas em um serviço “Consulta Crédito”. Para as operações de validação
de CPF e CNPJ, podemos criar um serviço “Validação” e para a operação de envio de
e-mail, um serviço “Email”.
A Figura B.4 mostra os contratos definidos para representar os serviços candidatos
identificados.
Após a definição dos serviços candidatos, devem ser elaboradas descrições tex-
tuais de cada serviço candidato e de cada operação, definindo os dados de entrada e
saída e a lógica executada.
Análise de Gap
Após a identificação dos serviços candidatos, a análise prossegue com a análise de
gap. O objetivo básico desta análise é localizar, nas aplicações existentes (legado),
as funções necessárias aos serviços candidatos, chegando a um cenário de reuso para
cada operação candidata.
Para analisar os cenários de reuso, deve-se consultar um repositório de serviços e
recursos reusáveis ou fontes de documentação das aplicações existentes. O cenário
142 Apêndice B
Figura B.4 Serviços candidatos identificados.
mais comum é encontrar uma arquitetura que ainda não possua um repositório de
serviços reusáveis. Neste caso recorre-se à documentação dos sistemas legados. Es-
pecificamente neste cenário, aplicação legada é o sistema de cadastro de clientes.
Como resultado dessa análise, foram obtidos os cenários de reuso apresentados
na Tabela B.3.
Tabela B.3 Cenários de reuso para as operações candidatas
Serviço Candidato Operação Candidata Cenário de Reuso

Cliente Verificar existência de Operação parcialmente realizada por aplicação
cliente legada (componente GerenciadorPessoa do
sistema de cadastro de clientes)
Validar dados de cliente Operação não existente
Gravar dados de cliente Operação realizada por aplicação legada

(componente GerenciadorPessoa do sistema
de cadastro de clientes)
Documento Consultar documentos Operação não existente

obrigatórios
Armazenar documento Operação não existente
Consulta Crédito Consultar Serasa Operação realizada por serviço existente

(serviço de consulta do Serasa)
Consultar SPC Operação realizada por serviço existente

(serviço de consulta do SPC)
Validação Validar número de CPF Operação realizada por aplicação legada

(biblioteca de classes LibCorporativa)
Validar número de CNPJ Operação realizada por aplicação legada

Email Enviar e-mail Operação realizada por aplicação legada

Apêndice B 143
A lógica necessária para as operações “Gravar dados de cliente” e “Verificar exis

tência de cliente” do serviço “Cliente” já eram realizadas por uma aplicação legada,
neste caso o componente “GerenciadorPessoa” pertencente ao sistema de cadastro de
clientes. Entretanto, a operação “Verificar existência de cliente” era realizada apenas
parcialmente pelo componente “GerenciadorPessoa”, já que este possuía apenas um
método de busca de cliente para realizar esta verificação.
As operações do serviço “Consulta Crédito” já são executadas por serviços ex-
ternos ao Serasa e ao SPC e podem ser reusadas diretamente.
Verificou-se também a existência de uma biblioteca de classes utilitárias
“LibCorporativa” que continha métodos que realizavam as operações “Validar
número de CPF” e “Validar número de CNPJ” do serviço “Validação” e “Enviar
e-mail” do serviço “Email”.
Os cenários de reuso analisados devem ser documentados juntamente com as
descrições das operações.
Análise de Realização
Na análise de realização, cada operação candidata é avaliada quanto ao seu cenário
de reuso identificado anteriormente. Nesta atividade, deve ser decidido como cada
operação de serviço será realizada.
As possibilidades de realização dos serviços candidatos devem ser analisadas pelo
arquiteto de serviços e discutidas com os responsáveis pelo repositório de serviços ou
pela arquitetura corporativa. As decisões de realização resultantes da análise devem
ser registradas nas descrições das operações e serviços candidatos. Para cada contrato
de serviço, deve ser indicado qual será sua realização.
Foram tomadas as seguintes decisões de realização:
Serviço “Cliente”
Para realizar esse serviço, decidiu-se criar um novo Web Service que seria res-
ponsável por invocar os métodos do componente “GerenciadorPessoa” do sistema
de cadastro de clientes e implementar as funções das operações não existentes. No
caso da operação “Verificar existência de cliente”, o Web Service deverá implementar
a lógica necessária para retornar o resultado desejado.
Serviço “Documento”
Como as duas operações desse serviço não existiam, um novo Web Service será
implementado para executar suas funções. Como este serviço armazena algumas
informações persistentes (como os documentos digitalizados), deve ser utilizada uma
base de dados para apoiar o serviço.
Serviço “Consulta Crédito”
Para esse serviço, ambas as operações já são realizadas por um serviço existente,
porém, externo à organização. Para manter a padronização dos serviços, decidiu-se
criar um novo Web Service para encapsular o acesso aos serviços externos, abs-
traindo a localização do serviço original e detalhes específicos. Para tal, o Web
Service deverá executar lógica de mediação, como mapeamento de mensagens e
roteamento.
144 Apêndice B
Serviços “Validação” e “Email”

Operações implementadas por dois novos Web Services responsáveis por encap-
sular as classes da biblioteca utilitária “LibCorporativa”.
B.4 Design
Na fase de design procura-se especificar os serviços definidos em detalhes, verifi-
cando também se os princípios estão sendo atendidos. Os serviços são revisados e
orquestrados.
Especificação de contrato de Serviços

A atividade de especificação de serviços tem como objetivo detalhar as classes de
mensagens e as interfaces de serviços, inclusive com a descrição técnica de cada
operação, para chegar aos artefatos que comporão o contrato do serviço.
Como as operações foram descritas apenas textualmente, neste momento há a
necessidade de se definirem os parâmetros das operações, permitindo a identificação
de algumas mensagens. Por exemplo, para a operação “Gravar dados de cliente” do
serviço “Cliente” definiu-se que um parâmetro de entrada da operação seria uma
mensagem com vários campos representando os dados do cliente e o parâmetro de
saída (ou de retorno) seria um indicador de sucesso da gravação (boolean).
Dessa maneira, devem-se definir as mensagens utilizadas nas operações de servi-
ços a partir das definições do processo. Para a implementação dos Web Services, as
mensagens devem ser formalmente modeladas como esquemas XSD (XML Schema
Definition).
O arquiteto de serviços deve definir também informações adicionais nos contratos
de serviços, tais como:
● especificação do tipo de dado de cada atributo das classes de mensagens;
● especificação do tipo de dados de cada parâmetro de operação;
● seleção dos parâmetros das operações com base na lógica a ser implementada;
● especificação de requisitos não funcionais, como segurança (autenticação e
autorização).
Para a especificação formal dos contratos dos Web Services, são utilizadas in-
terfaces WSDL (Web Service Definition Language).
Além dos contratos formais dos serviços, o arquiteto de serviços define também
a qual camada pertence cada serviço, de acordo com seu nível de granularidade e
relevância para a lógica de negócio. A classificação dos serviços nas camadas pode
ser vista na Figura B.5.
Especificação de componentes de serviço

Após a definição dos contratos de serviços, o arquiteto de serviços cria as especifica-
ções de serviços de acordo com as decisões de realização tomadas na fase de análise.
O arquiteto de serviços, então, define, para cada interface de serviço, um componente
Apêndice B 145
Figura B.5 Camadas de serviços.
de serviço exposto através da tecnologia Web Services. Estes componentes de serviço

serão os responsáveis por encapsular as aplicações legadas e serviços existentes
reusados, ou executar a lógica da operação (no caso de operações não existentes).
A especificação de realização dos serviços pode ser visualizada na Figura B.6.
Verificação de princípios
O objetivo dessa atividade é verificar se cada especificação de serviço criada atende
aos princípios de orientação a serviços e se está adequada a integrar o portfólio de
serviços da organização.
Figura B.6 Realização dos serviços.

146 Apêndice B
A verificação de princípios deve ser realizada em uma reunião envolvendo o

arquiteto de serviços, os responsáveis pelo portfólio de serviços, ou pela arquitetura
corporativa, e o gerente do projeto sendo executado.
A seguir, serão descritos os resultados obtidos da verificação de princípios em
cada um dos serviços projetados.
Serviço “Cliente”
A operação “Validar existência de cliente” pode ser considerada como possuindo
reusabilidade alta, isto é, tem potencial de ser reusada por outros processos de
negócio. Entretanto, para tornar o serviço mais reusável, pode-se adicionar outras
operações à interface, já existentes no componente “GerenciadorPessoa” encapsulado
pelo serviço, como “Remover dados de cliente” e “Obter cliente por nome”.
As operações podem ser especificadas no contrato do serviço, mas não seriam im-
plementadas imediatamente no projeto em questão. As atividades de implementação
do projeto podem focar somente nas operações necessárias para suportar o processo
de negócio “Cadastro de Cliente”, e as outras operações podem ser implementadas
como parte de outro projeto, com esforço e prazo dimensionados para tal.
O nível de granularidade do serviço pode ser considerado adequado. Já a au-
tonomia do serviço pode ser um ponto de atenção, uma vez que os componentes
encapsulados pertencem a um sistema legado e possuem relacionamentos com outros
componentes.
Serviço “Documento”
O serviço foi considerado com nível de granularidade alta por trabalhar com
uma entidade relevante para o processo de negócio – documento. A avaliação do
serviço constatou sua autonomia, pois toda sua lógica estava contida em um novo
Web Service, sem dependência com outros sistemas externos.
Serviço “Consulta Crédito”
O serviço foi considerado com nível de granularidade adequado para reuso,
uma vez que implementa operações de baixa granularidade. Porém, o serviço pode
ter problemas relacionados a autonomia e acoplamento, uma vez que é baseado em
serviços providos por entidades externas.
Serviços “Validação” e “Email”
Esses serviços foram projetados desde o início de forma a possuírem alta reusa-
bilidade, com operações utilitárias de baixa granularidade e aplicáveis a diversos
contextos de negócio. Portanto, eventuais ajustes poderiam incluir apenas a adição
de novas operações, já presentes nas classes da biblioteca “LibCorporativa”.
B.5 Fases complementares

Construção
Implementação de serviços
A partir da especificação dos contratos e realizações de serviços, devem ser con-
duzidas as atividades de implementação dos componentes de serviços e integração
desses ao processo de negócio.
Apêndice B 147
A partir desse ponto podem ser utilizadas tecnologias como Java EE ou Microsoft
.NET para implementação dos Web Services, e plataformas BPM para automação do
processo, como IBM WebSphere Process Server, Oracle BPM Suite ou jBPM.
Orquestração de Serviços
Durante a orquestração de serviços, o modelo de processo to-be elaborado no início
do projeto é convertido em um modelo de implementação, que deve ser trabalhado
para tratar todas as regras de negócio modeladas e adequar-se aos serviços es
pecificados.
O fluxo de trabalho do processo pode ser automatizado na plataforma BPM
utilizando-se a linguagem WS-BPEL (Web Services Business Process Execution
Language). Além da própria estrutura do processo (tarefas, decisões e conexões), é
necessário também implementar no processo os seguintes aspectos:
● variáveis;
● lógica de tratamento de dados;
● lógica de decisão nos nós do tipo “Choice” (if-then-else);
● dados de correlação de instâncias de processo;
● tempo de expiração de atividades com tal requisito;
● mapeamento das interfaces geradas no WS-BPEL para as interfaces WSDL dos
serviços utilizados pelo processo.
Após implementado, o processo em WS-BPEL é encapsulado pelo serviço de
orquestração “Cadastro de Cliente”, que por sua vez será composto pelos outros
serviços. Para tal, foi necessário também definir a interface WSDL e as mensagens
em XSD para o serviço de orquestração. A Figura B.7 mostra a composição do serviço
de orquestração “Cadastro de Cliente”.
Figura B.7 Composição do serviço de orquestração “Cadastro de Cliente”.

148 Apêndice B
Teste de serviços
Uma vez implementados todos os componentes de serviços e a orquestração do
processo, deve ser testada a solução como um todo. São realizados testes unitários
de cada componente de serviço e, então, um teste integrado do processo de negócio
orquestrando a execução dos serviços, para assegurar que a solução está funcionando
corretamente.
Adicionalmente, podem ser realizados testes de carga e desempenho com o intuito
de verificar o atendimento a requisitos não funcionais.
Por fim, são executados testes de aceitação com os usuários do processo, de
forma a homologar a solução para que ela possa passar para as fases seguintes de
implantação e gerenciamento.
Glossário
Abstração Abstração é uma técnica usada na modelagem de entidades complexas, como uma organização
ou um sistema de software, cujo objetivo é obter de maneira concisa os aspectos essenciais da entidade
sem considerar os seus detalhes.
API (Application Programming Interface) API é um conjunto de rotinas, bibliotecas, frameworks, protocolos
e classes independentes de linguagem de programação disponibilizados para apoiar o desenvolvimento
de aplicações de software.
Arquitetura Uma arquitetura representa uma visão dos elementos estruturais e comportamentais do sistema.
Ator Ator é um papel de uma pessoa ou um usuário que inicia e interage com o sistema.
BPM (Business Process Management) BPM é uma abordagem sistemática para identificar, avaliar e melhorar
os processos de negócio tornando-os mais efetivos e capazes de se adaptarem às mudanças do ambiente
e às metas organizacionais.
BPMN (Business Process Modeling Notation) BPMN é uma representação gráfica para especificar fluxos
de processos de negócio e Web Services.
BPMS (Business Process Management System) BPMS é uma ferramenta que permite modelar, analisar,
implementar, integrar, implantar e monitorar atividades e processos de negócio.
Caso de uso Caso de uso é uma técnica para especificar uma função do software do ponto de vista de um
ator (usuário ou outro sistema).
Ciclo de vida Ciclo de vida é 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 uma fase 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.
Cloud Services Cloud Services, no contexto de computação em nuvem, referem-se aos recursos de proces-
samento e armazenamento disponibilizados como serviços, sem que o usuário conheça a localização dos
provedores destes serviços.
Design Pattern Design Pattern é uma solução para problemas comuns que ocorrem em desenvolvimento de
software. No contexto de SOA, é um template que pode ser usado em diversas situações no design de
serviços.
IDE (Integrated Development Environment) IDE é um ambiente de desenvolvimento de software com
recursos integrados para dar maior produtividade aos desenvolvedores. Exemplos: Eclipse, Net Beans,
Microsoft Visual Studio etc.
ESB (Enterprise Service Bus) ESB é um middleware que possibilita a comunicação entre vários componentes
de uma arquitetura SOA.
Ferramenta CASE (Computer Aided Software Engineering) Ferramenta CASE é um programa de compu-
tador usado no desenvolvimento, teste, análise ou manutenção de um programa ou sua documentação.
Framework Framework é um conjunto de suposições, conceitos, valores e práticas que constituem uma
maneira de ver o ambiente atual.
KPIs (Key Performance Indicators) KPIs são indicadores quantitativos que refletem fatores críticos de sucesso
de uma organização. As KPIs são utilizadas por organizações para aferir o progresso do atingimento de
uma determinada meta de negócio.
Mensagem (de serviço) Mensagem é uma tecnologia usada no design de serviços para permitir a interação
entre eles. Esta tecnologia reduz os requisitos de acoplamento e remove a necessidade de conexões
persistentes.
Metadados Metadados são dados que descrevem dados ou informações (dados) que descrevem dados
primários.
149
150 Glossário
Método Método é um padrão que descreve ordenadamente as características de um processo ou procedimento

usado na engenharia de um produto ou realização de um serviço.
Middleware Middleware é uma camada de software que permite conectar diferentes aplicações de software
em sistemas distribuídos.
Modelo de processo Modelo de processo é uma representação que reúne processos, métodos e ferramentas,
e fases genéricas. É uma abstração do processo real que está sendo executado.
Nuvem (computação em nuvem) Nuvem ou computação em nuvem (cloud computing) refere-se à dis-
ponibilização de recursos computacionais através da Internet. No contexto de SOA, estes recursos são
disponibilizados como serviços.
Operação (de serviço) Operação (também chamada de competência ou capacidade) é uma função executada
por um serviço e que pode ser invocada através de mensagens. Um serviço é composto de uma ou mais
operações, que são definidas em seu contrato.
Orquestração de serviços Orquestração de serviços é um procedimento automatizado de composição de
serviços para criar nova funcionalidade.
Processo de negócio É um conjunto de atividades que são aplicadas a todos os projetos de software, sem
considerar o seu tamanho ou complexidade. É uma série de estágios que envolvem atividades, controles
e recursos para produzir uma saída de alguma espécie.
Processo de software Processo de software é um conjunto de atividades voltadas ao desenvolvimento e
evolução de um software. O processo envolve a tradução das necessidades do usuário em requisitos de
software, transformação de requisitos em design, implementação do design em código, teste de código e,
algumas vezes, instalação e verificação de software para uso operacional. Por exemplo, desenvolvimento
incremental, prototipação rápida, modelo espiral, modelo cascata.
Produto de software Produto de software é um conjunto completo de programas de computador, procedimen-
tos e possivelmente documentação associada e dados projetados para serem liberados para um usuário.
Qualidade de serviço (QoS – Quality of Service) Qualidade de serviço refere-se ao atendimento de requisitos
não funcionais, tais como segurança de acesso, desempenho, disponibilidade, confiabilidade, escalabili-
dade, tolerância a falhas, integridade transacional, entre outros.
Requisito Requisito é uma declaração de algo que precisa ser implementado no sistema. Um requisito
funcional é uma característica ou função do software. Um requisito não funcional é uma restrição ou
comportamento esperado que se aplica a todo o sistema.
REST (REpresentational State Transfer) REST define um estilo de arquitetura para a Web, baseado no
protocolo HTTP e é considerado uma alternativa à tecnologia Web Services para implementação de
serviços.
Reuso Reuso é uma tecnologia para aumentar a produtividade com o reuso de sistemas ou componentes
existentes.
ROI (Return on Investment) ROI ou retorno do investimento é uma métrica de desempenho financeiro baseado
no retorno de um dado investimento comparado ao custo deste investimento. No contexto de SOA, o ROI
é afetado principalmente pela capacidade de reuso de serviços e de recursos existentes, pois possibilita a
obtenção de novos retornos sobre um investimento já realizado no passado.
RUP (Rational Unified Process) RUP ou processo unificado da empresa IBM/Rational é um processo de
software iterativo voltado ao desenvolvimento orientado a objetos e usa a UML como linguagem de
modelagem.
SCA (Service Component Architecture) SCA define um conjunto de especificações que descrevem um modelo
para desenvolver aplicações compostas que seguem os princípios do paradigma de orientação a serviços.
A tecnologia SCA permite implementar componentes de serviços em uma variedade de linguagens e
plataformas e integrá-los através de diversos protocolos de comunicação.
Serviço No âmbito de uma arquitetura SOA, serviço é um elemento computacional que tem como propósito
desempenhar uma função específica e que pode ser utilizado por um cliente.
SLA (Service Level Agreement) Um SLA é parte do contrato de serviços entre o provedor e o consumidor de
serviços. O SLA é um acordo firmado entre o provedor e o consumidor para definir a qualidade de serviço
(QoS) a ser fornecido, principalmente abordando requisitos de desempenho e disponibilidade.
Glossário 151
SOA (Service Oriented Architecture) SOA é uma tecnologia que torna possível, além do reuso de aplicações,
o acesso a informações diversas disponíveis em vários computadores ligados na Internet.
SOAP (Simple Object Access Protocol) SOAP é um protocolo baseado em XML que permite às aplicações
trocarem informações estruturadas nas implementações de Web Services.
Stakeholder Stakeholder é uma pessoa, área ou organização que está ativamente envolvida no projeto cujos
interesses podem ser afetados durante a execução do projeto.
Técnica Uma técnica descreve as características acumuladas na aplicação de habilidades e métodos técnicos
e gerenciais na criação de um produto ou realização de um serviço.
UDDI (Universal Description, Discovery, and Integration) UDDI é um registro (catálogo) baseado em XML
usado para que os consumidores de serviços possam descobrir e integrar Web Services publicados por
seus provedores.
UML (Unified Modeling Language) UML é uma linguagem visual resultante de numerosos métodos
orientados a objetos que existiam no início da década de 1990. Fornece diferentes visões de um sistema
por meio de seus diversos tipos de modelos.
Web Service Web Service é uma tecnologia que permite a interoperabilidade de máquinas na Internet.
WS-BPEL (Web Services Business Process Execution Language) WS-BPEL é uma linguagem executável
padrão para especificar processos de negócio com Web Services.
WSDL (Web Services Description Language) WSDL é uma linguagem baseada em XML para descrever as
assinaturas das operações fornecidas por um Web Service e como acessá-lo.
XML (Extensible Markup Language) XML é um formato de texto simples e muito flexível originalmente
projetado para atender aos desafios de publicação eletrônica em larga escala. A XML tem um papel
importante no intercâmbio de uma extensa variedade de dados da Internet. Está presente na norma ISO
8879:1986.
XSD (XML Schema Definition) XSD é uma linguagem formal para especificação de restrições de estrutura
e conteúdo de documentos XML.
Índice Remissivo
A Banke, 131
.NET, 14, 147 Base de dados, 31, 32, 78, 102
Abordagem Bell, 3, 18, 22-24
bottom-up, 43 Bieberstein, 18, 36, 37
"do zero'', 47 Boas práticas, 43
incremental, 21, 47 Booch, 132
iterativa, 58 Bottom-up, 43, 45, 101
meet-in-the-middle, 43 BPM (Business Process Management), 44, 49
top-down, 43, 45 BPMN (Business Process Modeling Notation), 44, 46,
Abstração, 115, 149 54, 62, 63, 149
princípio, 23 BPMS (Business Process Management System), 15,
Adaptador de integração, 30, 109, 110 25, 27, 28, 149
Administrador de serviços, 54 Business intelligence, 16, 31, 128
Alinhamento Business Process Management. Ver BPM
com o negócio, 37
Ambiente de execução, 27, 38 C
Ambiente de TI, 2 Caixa-preta, 12, 103, 115, 124
Análise Camadas de serviços, 18, 20, 46, 145
de fase, 49, 140 Canonical Schema (design pattern), 102
de gap, 141 Canonical Versioning (design pattern), 95
de realização, 91, 143 capacidade de composição, 24
Analista princípio, 116
de processos, 50-51 Caso de uso, 56, 71, 149
de serviços, 51-52 Casos de Uso de Negócio, 45, 50, 71
API – Application Programming Interface, 45, 149 CBD – Component Based Development, 46
Aplicação Cenário de reuso, 85, 142
legada, 87-90 Centro de Excelência SOA, 52
web, 15, 27–29 Christensen, 131
Arquiteto Ciclo de vida, 149
corporativo, 52, 116 de software, 3, 5
de serviços, 52, 102, 140, 143, 144 SOA, 43-58
Arquitetura de Informação, 19, 31, 34 Ciclo de vida iterativo, 58
camada, 15 Ciclo de vida orientado a serviços, 3
Arquitetura Orientada a Serviços, 8-11, 13, 15-19, 23- Cloud computing, 35, 150
28, 31-32, 35-38, 44, 45 Cloud service provider, 26
Arquitetura Cloud service, 84, 149
de referência, 13, 14, 52, 123, 124 Cockburn, 108, 131
de software, 7, 10 Competência agnóstica (design pattern), 114
SOA, 8-11, 13, 15-19, 23-28, 31-32, 35-38, 44, 45 Complextype, 101
Artefatos, 54-57 Component Based Development, 46
Ator de processo, 54 Componente de serviço, 14, 93, 94, 96, 107, 108, 144,
Autonomia, 24, 146 148
princípio, 115 camada, 14
Componentização de software, 12
B Composição, Capacidade de, 24
Baixo acoplamento, 23 princípio, 116
princípio, 115 Composição de serviços, 20, 21
BAM – Business Activity Monitoring, 27, 31, 33, 128 Computação em nuvem. Ver cloud computing
153
154 Índice Remissivo
Confiabilidade, 15, 35, 101 G

Construção, 49, 119 Gap
fase, 49 de dados, 85, 93, 94
Consumidor de serviço, 57, 85, 101 de formato, 85, 86
Contract Centralization (design de lógica, 85-87, 92-94
pattern), 114, 117 de protocolo, 85
Contrato, 11, 12, 22 Gerenciamento, 49
de serviço, 56-57, 99-107 fase, 49
Contrato padronizado, 22 Gerente de projeto, 53, 95
princípio, 114 Gestor de processos, 54, 128
COTS - Commercial Off-The-Shelf, 2 Gornik, 132
CRM – Customer Relationship Management, 1, 89, Governança, 39
90, 96 camada, 16
Granularidade de serviço, 17
D
Dados, 69 H
DAO, 112, 113 Hirama, v, 131
Data warehousing, 31, 128 Huhns, 10, 131
Decisões de Realização, 91, 95, 143, 144
Desempenho, 38 I
Desenvolvedor, 53, 119 IDE – Integrated Development Environment, 34, 149
Design Identificação de Serviços Candidatos, 56, 75, 140
fase, 49, 58, 99, 100 Implantação, 49, 124
pattern, 52, 53, 149 de Serviços, 126
Diagramas de implantação, 109 fase, 49
Disponibilidade, 13, 34 Implementação de Serviços, 119, 146
Dranidis, 3, 132 Independência de estado, 24
princípio, 115
E Informação, 15
Elementos, 25, 26 Infraestrutura de TI, 1, 2, 14, 18, 27, 84
Encapsulamento, 12, 23, 39 Integração
Endrei, 40, 131 camada, 15
Engenharia de Software, 2 Interface de serviço, 12, 102, 109
ERL, 3, 7, 18, 131 Interfaces consumidoras, 15, 78
ERP – Enterprise Resource Planning, 1, 14 camada, 25
ESB – Enterprise Service Bus, 28, 149 Internet, 4, 10
Escalabilidade, 15, 28, 35 Interoperabilidade, 16, 17, 22, 25
Especificação princípio, 116
de contrato de serviços, 99
de processo, 55 J
de realização de serviços, 107 Jacobson, 132
de requisitos, 140 Java, 14, 147
de serviço, 57 Jeston, 131
Esquemas de mensagens, 13, 101
Estilo arquitetural, 5, 10 K
Evidências de teste, 122 Keen, 28, 131
Kenney, 131
F KPIs – Key Performance Indicators, 31, 50, 149
Fallside, 131 Krafzig, 131
Ferramenta CASE – Computer Aided Software Krebs, 132
Engineering, 149 Krutchen, 131
Ferramentas
de Desenvolvimento, 27, 34 L
de Infraestrutura de Aplicações, 27, 35 Logic Centralization (design pattern), 96, 114
Framework, 13, 149 Lógica, 13, 25
Fugita, 131 Lycett, 40, 132
Índice Remissivo 155
M Paradigma
Manutenção de serviços, 126, 127 de desenvolvimento de software, 1, 39
Marks, 131 de orientação a serviços, 18, 39, 41, 129
Mediação, 85, 93, 119 Perrey, 40, 132
Meet-in-the-middle, 43, 101 Plataforma BPMS, 25, 28, 67, 138
Mensagem, 9, 101, 102 Políticas, 13
Metadados, 32, 124, 149 Portal, 29
Método, 43-47 Portfólio de serviços, 21, 22
de análise e design, 13, 44-47 Portlets, 29
de desenvolvimento de serviços, 3 Porttype, 102
Metodologias de desenvolvimento, 3 Princípios da orientação a serviço, 3, 4, 40
Métricas, 62 Processo
de processo de negócio, 127 de Negócio, 9, 10, 150
Middleware, 2, 16, 28, 150 de Software, 150
Modelagem, 50, 59-74, 137 Orquestrado, 121, 122
fase, 47, 59, 63 Processos de desenvolvimento, 3
Modelo de dados, 19, 36, 101, 102, 108, 113 Processos de negócio, 27
Modelo camada, 15
de processo as-is, 59, 137 Produto de software, 5, 47, 150
de processo to-be, 64, 138 Provedores de serviço, 11
de referência, 2 Publicação de serviços, 124, 125
de serviços, 56-58
Monitor de Atividade de Negócio (BAM), 31 Q
Monitor de Atividade de Serviços (SAM), 33 QoS – Quality of Service, 45, 150
Monitoração de Atividade de Negócio, 62, Qualidade de Serviço, 150
127, 128 camada, 15
Monitoração de Serviços, 15
R
N Ramollari, 3, 132
Necessidades de negócio, 2, 5, 47, 64, 70 Realização, 11, 13, 91, 107, 143
Nelis, 131 de serviço, 145
Nuvem. Ver cloud computing Registro de Serviços, 45, 92, 107
Regras de Negócio, 66, 71, 72, 76
O Repositório
Oasis, 2, 5, 131 de serviços, 2, 141-143
Objeto de software, 5 de metadados, 12, 32
OMG – Object Management Group, 16 Requisitos
Open Group, 13, 14, 131 de negócio, 3, 10, 37
Operação funcionais, 64, 85, 103
candidata, 76-78, 81, 86, 87, 92-94, 96, não funcionais, 45, 72, 140, 144
140-143 REST – REpresentational State Transfer, 17, 150
Operation, 102 RESTful – RESTful services ou RESTful web services,
Orientação 17
a componentes, 40 Reusabilidade, 22, 23, 146
a objetos, 39, 40 princípio, 114
a serviços, 4, 22, 36 Reuso, 44, 150
Orquestração de serviços, 121, 147, 150 ROI – Return on Investment, 36, 150
Rumbaugh, 132
P RUP – Rational Unified Process, 3, 150
Pacotes de implantação, 126
Padrões abertos, 12, 16, 45, 46 S
Padronizado SAM – Service Activity Monitoring, 33
contrato, 22 SCA – Service Component Architecture, 150
princípio, 114 SCM – Supply Chain Management, 1
Papazoglou, 12, 13, 132 Segurança, 38
Papéis, 50, 64 Service Decomposition (design pattern), 118
156 Índice Remissivo
Service Façade (design pattern), 109 TI – Tecnologia da Informação, 1, 9, 129

Service Layers (design pattern), 18 Top-down, 43, 45, 101
Service Normalization (design pattern), 80, 89
Serviço U
candidato, 45, 90, 92, 94, 142 UDDI – Universal Description, Discovery
camada, 15, 18 and Integration, 17, 151
de entidade, 103, 117 UML – Unified Modeling Language, 62, 151
de tarefa orquestrada, 20, 25
de tarefa, 19, 20
Serviços utilitários, 18
V
van Den Heuvel, 3, 39, 44, 84, 132
Serviços
Verificação de Princípios, 113, 146
consumidor de, 57, 85, 101
Version Identification (design pattern), 95
contratos de, 56-57, 99-107
Visibilidade, 24
Servidor de aplicação, 27
princípio, 116
Shuja, 132
Simons, 3, 132
Simulação, 66 W
Sistemas de TI, 1, 2 Walmsley, 131
Sistemas Operacionais, 13, 16 WC – World Wide Web Consortium, 16
camada, 14, 26 Web Services, 3, 5, 16, 17, 144, 147, 151
SLA – Service Level Agreement, 13, 49, 150 Workflow, 28
Slama, 131 WS-Addressing, 17
SOA – Service Oriented Architecture, 1, 5, 151 WS-AtomicTransaction, 17, 45
SOAP – Simple Object Access Protocol, 16, 151 WS-BPEL – Web Services Business Process
Solução orientada a serviços, 25 Execution Language, 20, 147, 151
Stakeholder, 151 WS-I Profiles, 17
WS-I, 114
T WS-Notification, 17
Tarefa, 139, 140, 141 WS-Policy, 17, 45
Tecnologia da informação. Ver TI WS-Reliable Messaging, 17
Tecnologia Web, 16, 17, 25, 46, 101, 102 WS-Security, 17, 38, 45
Testador, 53, 122 WSDL – Web Services Description
Testes Language, 22, 151
de aceitação, 126, 148
de contrato de serviço, 124 X
de orquestração, 124 XML – eXtensible Markup Language, 16, 151
de serviços, 122, 123 XSD – XML Schema Definition, 22, 144, 151
de unidade, 123
de usuário, 124 Z
não funcionais, 124 Zimmermann, 132

Henrique Shoiti Fugita-SOA PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Henrique Shoiti Fugita-SOA PDF

Enviado por

Direitos autorais:

Formatos disponíveis

SOA

Modelagem, Análise e Design

Consulte também nosso catálogo completo, últimos lançamentos e

Henrique Shoiti Fugita

Todos os direitos reservados e protegidos pela Lei n° 9.610, de 19/02/1998.

Copidesque: Ana Paula Bezerra

Elsevier Editora Ltda.

Rua Quintana, 753 – 8° andar

Serviço de Atendimento ao Cliente

Fugita, Henrique Shoiti

1. Arquitetura de computador. 2. Tecnologia da informação. 3. Software - Desenvol-

Agradeço à minha esposa, a meus pais e irmãos pelo apoio incondicional.

A modelagem, a análise e o design são frutos de diversas pesquisas acumuladas

Na seção Apêndice, são apresentados o Apêndice A – os elementos gráficos usados

1.1 Visão Geral

Principalmente nas organizações de maior porte, esses sistemas de TI constituem

de ferramentas e notações amplamente conhecidas para a modelagem e representação

adotou-se um ciclo de vida SOA, conforme descrito no Capítulo 3. As atividades

1.2 Perguntas Mais Frequentes

O que é Arquitetura Orientada a Serviços (SOA – Service Oriented Archi-

2.1.1 O que é um serviço?

Figura 2.1 Serviço “Funcionário” com suas operações.

O conceito de serviço é adequado para representar transações que a área de TI

direta com o conceito de processo de negócio, o serviço possibilita uma melhoria

Figura 2.3 Infraestrutura geral criada para fornecimento e consumo de serviços.

Figura 2.4 Agentes de uma arquitetura SOA (Papazoglou, 2003).

Assim, os serviços são oferecidos pelos provedores de serviço, agentes res-

2.1.3 Anatomia de um serviço

Figura 2.5 Anatomia de um serviço.

através do qual o consumidor utiliza este serviço. Assim, os consumidores do serviço

Os esquemas de mensagens descrevem o modelo e o formato dos dados utilizados

2.1.4 Arquitetura de referência

Figura 2.6 Arquitetura de referência SOA (The Open Group, 2009).

A camada de sistemas operacionais representa a infraestrutura de TI existente,

● aplicações-pacote (como ERPs e CRMs).

A camada de componentes de serviço contém componentes de software que

● mediações que encapsulam o acesso a um sistema operacional e o disponibiliza

de negócio e serviços. Nesta camada, atuam tecnologias de business intelligence,

2.1.5 Tecnologias de implementação

de mensagens em formato XML transmitidas via HTTP ou outros protocolos;

Figura 2.7 Web Service (Erl, 2007).

● UDDI (Universal Description, Discovery and Integration) – especificação

distribuídas envolvendo Web Services;

com tolerância a falhas de comunicação;

da notificação de eventos entre Web Services;

Web Services para roteamento de mensagens SOAP;

teroperability) com o intuito de garantir a interoperabilidade entre Web Services

2.2 Conceitos Relacionados a SOA

2.2.1 Granularidade de serviço

um serviço, sendo que, quanto mais funcionalidade, mais abrangente é o escopo

2.2.2 Camadas de serviço

Figura 2.8 Camadas de uma arquitetura SOA (Erl, 2005).

Os serviços de entidade proveem acesso às entidades pertencentes ao modelo

Figura 2.9 Camadas de serviços (Erl, 2005).

Um tipo específico de serviço de tarefa, os serviços de tarefa orquestrada

2.2.3 Composições de serviços

Inclusive, o princípio de orientação a serviços “Facilidade de Composição” orienta

2.2.4 Portfólio de serviços

já existentes no portfólio. Pode exigir um esforço de governança e versionamento

2.3 Princípios de Orientação a Serviços

2.3.1 Contrato padronizado

Os serviços devem ser projetados considerando-se as várias formas de reuso,

2.3.3 Baixo acoplamento