HENRIQUE SHOITI FUGITA

MAPOS: Mtodo de Anlise e Projeto Orientado a Servios

SO PAULO
2009
 HENRIQUE SHOITI FUGITA

MAPOS: Mtodo de Anlise e Projeto Orientado a Servios

Dissertao apresentada Escola

Politcnica da Universidade de So Paulo
para obteno do ttulo de Mestre em
Engenharia

rea de Concentrao: Sistemas Digitais

Orientador: Prof. Dr. Kechi Hirama

SO PAULO
2009
 FICHA CATALOGRFICA

Fugita, Henrique Shoiti

MAPOS: Mtodo de Anlise e Projeto Orientado a Servios /
H.S. Fugita. -- So Paulo, 2009.
175 p.

Dissertao (Mestrado) - Escola Politcnica da Universidade

de So Paulo. Departamento de Engenharia de Computao e
Sistemas Digitais.

1. Mtodos de desenvolvimento de software 2. Arquitetura de

software 3. Ciclo de vida de desenvolvimento de software I. Uni-
versidade de So Paulo. Escola Politcnica. Departamento de
Engenharia de Computao e Sistemas Digitais II. t.
A Priscila Miyuki Miura, pelo apoio e motivao prestados ao longo de todo o
caminho percorrido para a elaborao deste trabalho.

A meus pais Marina Mariko Nagata Fugita e Dirceu Kasuo Fugita, por serem a minha
principal referncia e por terem tornado possvel a conquista deste objetivo.
 AGRADECIMENTOS

Ao meu orientador Prof. Dr. Kechi Hirama, por todo o conhecimento e experincia
passados durante o processo de elaborao deste trabalho.

Profa. Dra. Selma Melnikoff e ao Prof. Dr. Pedro Corra, por sua participao na
banca de qualificao e pelos comentrios que muito contriburam para o resultado
final desta pesquisa.

Escola Politcnica da Universidade de So Paulo, por ter me dado a oportunidade

de cursar tanto a graduao quanto o mestrado.

IntVision Solutions, por acreditar no resultado deste trabalho e me permitir a

realizao dos estudos de caso em seus projetos.

Aos meus companheiros de projeto, pela colaborao na realizao dos estudos de

caso.

A todos os meus familiares, amigos e colegas de trabalho que contriburam, mesmo

que de forma indireta, para a realizao deste trabalho.
Adoramos a perfeio porque no a podemos ter; repugn-la-amos se a tivssemos. O
perfeito desumano porque o humano imperfeito.

Fernando Pessoa
 RESUMO

FUGITA, H. S. MAPOS: Mtodo de Anlise e Projeto Orientado a Servios. So

Paulo: Escola Politcnica, Universidade de So Paulo, 2009. 175 p. Dissertao de
Mestrado em Engenharia.

Com a crescente adoo do conceito de Arquitetura Orientada a Servios (SOA)

pelas organizaes, torna-se necessrio solucionar um dos principais desafios
trazidos por este estilo arquitetural, que a anlise e projeto de servios. Alguns
mtodos de anlise e projeto de solues orientadas a servios vm sendo
propostos, mas ainda esto longe de convergir em direo a uma padronizao.

Este trabalho realiza uma avaliao crtica dos mtodos existentes e levanta um
conjunto de requisitos de anlise e projeto orientado a servios. Baseado nesta
anlise, proposto um mtodo para unificar as boas prticas dos mtodos
existentes e atender aos requisitos levantados. Para verificar a aplicabilidade do
mtodo, dois estudos de caso foram conduzidos em projetos reais.

Palavras-chave: Engenharia de Software, Arquitetura Orientada a Servios (SOA).

 ABSTRACT

FUGITA, H. S. Service-Oriented Analysis and Design Method. So Paulo: Escola

Politcnica, Universidade de So Paulo, 2009. 175 p. Dissertao de Mestrado em
Engenharia.

With the growing adoption of Service-Oriented Architeture (SOA) by the

organizations, it becomes necessary to address one of the main challenges imposed
by this architetural style, which is services analysis and design. Some service-
oriented applications analysis and design methods have been proposed, but have
not yet converged towards standardization.

This work performs a critical assessment of existing methods and describes a set of
requirements of service-oriented analysis and design. Based on that study, a new
method is proposed to unify the best practices of existing methods and satisfy the
gathered requirements. In order to verify the applicability of the method, two case
studies were conducted in real projects.

Keywords: Software Engineering, Service-Oriented Architecture (SOA).

 LISTA DE FIGURAS

Figura 2.1: Agentes de uma arquitetura SOA (PAPAZOGLOU, 2003) ...................... 20

Figura 2.2: Hierarquia de uma arquitetura SOA (PAPAZOGLOU; VAN DEN
HEUVEL, 2006) ......................................................................................................... 22
Figura 2.3: Relacionamentos entre os componentes de uma arquitetura SOA (ERL,
2005) ......................................................................................................................... 23
Figura 2.4: Elementos de uma arquitetura SOA (MARKS; BELL, 2006) ................... 27
Figura 2.5: Elementos de uma Arquitetura Orientada a Servios (KRAFZIG; BANKE;
SLAMA, 2004) ........................................................................................................... 30
Figura 2.6: Camadas de uma arquitetura SOA (ERL, 2005) ..................................... 39
Figura 2.7: Camadas de servios (ERL, 2005).......................................................... 40
Figura 3.1: Fases do mtodo (PAPAZOGLOU; VAN DEN HEUVEL, 2006) ............. 52
Figura 3.2: Identificao de processo e escopo de processo (PAPAZOGLOU, 2006)
.................................................................................................................................. 55
Figura 3.3: Arquitetura do Rational Unified Process (SHUJA, KREBS, 2007)........... 63
Figura 3.4: Abordagens de Identificao de Servios (IBM, 2007)............................ 67
Figura 3.5: Exemplo de modelo de processo de negcio (IBM, 2007) ...................... 68
Figura 3.6: Mapeamento de casos de uso para servios (IBM, 2007) ...................... 69
Figura 3.7: Disponibilizao de funes legadas como servios (IBM, 2007) ........... 70
Figura 3.8: Ciclo de vida de desenvolvimento SOA (ERL, 2005) .............................. 76
Figura 3.9: Anlise Orientada a Servios (ERL, 2005) .............................................. 78
Figura 3.10: Modelagem de servios candidatos (ERL, 2005) .................................. 80
Figura 3.11: Notao para representar um servio (ERL, 2007) ............................... 82
Figura 3.12: Projeto orientado a servios (ERL, 2005).............................................. 83
Figura 3.13: Ciclo de Vida de Servios (MARKS; BELL, 2006) ................................. 90
Figura 3.14: Processo de identificao e anlise de servios (MARKS; BELL, 2006)
.................................................................................................................................. 93
Figura 3.15: Mapa de granularidade de servios (MARKS; BELL, 2006) .................. 96
Figura 3.16: Processo de projeto de servios (MARKS; BELL, 2006) ....................... 98
Figura 3.17: Mapa de demarcao (MARKS; BELL, 2006) ....................................... 99
Figura 3.18: Tipos de transformao lgico-fsico (MARKS; BELL, 2006) .............. 101
Figura 5.1: Mtodo de Anlise e Projeto Orientado a Servios ............................... 116
Figura 5.2: Modelo de Servios ............................................................................... 129
Figura 6.1: Diagrama do processo "Incluir cliente pessoa fsica" ............................ 137
Figura 6.2: Operaes candidatas identificadas...................................................... 140
Figura 6.3: Servios candidatos identificados ......................................................... 141
Figura 6.4: Exemplos de classes de mensagens .................................................... 142
Figura 6.5: Realizao do servio "SvcClientePF" .................................................. 145
Figura 6.6: Realizao do servio "SvcCorporativo" ............................................... 146
Figura 6.7: Realizao do servio "InfraCliente" ..................................................... 147
Figura 6.8: Diagrama do processo Recepo de Lote de NF-e (ENCONTRO..., 2006)
................................................................................................................................ 156
Figura 6.9: Exemplos de servios especificados ..................................................... 163
 LISTA DE TABELAS

Tabela 4.1: Resumo da aderncia dos mtodos analisados aos requisitos ............ 114
Tabela 6.1: Especificao da tarefa Reagendar Visita ......................................... 138
Tabela 6.2: Operaes candidatas do processo "Incluso de cliente pessoa fsica"
................................................................................................................................ 139
Tabela 6.3: Cenrios de reuso para operaes candidatas .................................... 143
Tabela 6.4: Operaes candidatas identificadas ..................................................... 157
Tabela 6.5: Operaes candidatas agrupadas por servio candidato ..................... 158
Tabela 6.6: Descrio do servio candidata "Regularidade Fiscal" ......................... 159
Tabela 6.7: Descrio da operao candidata "Verificar Regularidade Fiscal" ....... 159
Tabela 6.8: Cenrios de reuso para operaes candidatas .................................... 160
Tabela 6.9: Alocao dos servios em camadas .................................................... 163
 LISTA DE SIGLAS E ABREVIATURAS

API Application Programming Interface

BPM Business Process Management
BPMN Business Process Modeling Notation
CASE Computer-Aided Software Engineering
CBD Component-Based Development
CNPJ Cadastro Nacional da Pessoa Jurdica
COTS Commercial Off-The-Shelf
CPF Cadastro de Pessoas Fsicas
CRM Customer Relationship Management
ENCAT Encontro Nacional de Coordenadores e Administradores Tributrios
Estaduais
ERP Enterprise Resource Planning
ESB Enterprise Service Bus
GUI Graphical User Interface
HTTP Hyper Text Transfer Protocol
IDE Integrated Development Environment
IE Inscrio Estadual
KPI Key Performance Indicator
MAPOS Mtodo de Anlise e Projeto Orientado a Servios
NF-e Nota Fiscal Eletrnica
OASIS Organization for the Advancement of Structured Information Standards
QoS Quality of Service
ROI Return On Investment
RUP Rational Unified Process
SLA Service Level Agreement
SOA Service-Oriented Architecture
SOAP Simple Object Access Protocol
SOC Service-Oriented Computing
SOMA Service-Oriented Modeling and Architecture
TI Tecnologia de Informao
UDDI Universal Description, Discovery and Integration
UML Unified Modeling Language
WS-BPEL Web Services Business Process Execution Language
WSDL Web Services Description Language
XML Extensible Markup Language
XSD XML Schema Definition
 SUMRIO

RESUMO
ABSTRACT
LISTA DE FIGURAS
LISTA DE TABELAS
LISTA DE SIGLAS E ABREVIATURAS
1 INTRODUO ................................................................................................... 14
1.1 Motivao ....................................................................................................... 15
1.2 Objetivo .......................................................................................................... 16
1.3 Justificativa ..................................................................................................... 16
1.4 Organizao ................................................................................................... 18
2 ARQUITETURA ORIENTADA A SERVIOS .................................................... 19
2.1 Definio de Arquitetura Orientada a Servios ............................................... 19
2.2 Elementos de uma Arquitetura Orientada a Servios ..................................... 29
2.3 Princpios de Orientao a Servios ............................................................... 33
2.4 Benefcios e Desafios ..................................................................................... 41
2.5 Relao com outros paradigmas .................................................................... 47
2.6 Consideraes Finais ..................................................................................... 49
3 MTODOS DE ANLISE E PROJETO ORIENTADOS A SERVIOS ............. 50
3.1 Papazoglou e Van Den Heuvel ....................................................................... 51
3.2 RUP plugin for SOMA ..................................................................................... 61
3.3 Erl ................................................................................................................... 75
3.4 Marks e Bell .................................................................................................... 88
3.5 Consideraes Finais ................................................................................... 104
4 REQUISITOS DE UM MTODO DE ANLISE E PROJETO ORIENTADO A
SERVIOS .............................................................................................................. 105
4.1 Descrio dos Requisitos ............................................................................. 105
4.2 Aderncia dos mtodos analisados aos requisitos ....................................... 113
4.3 Consideraes Finais ................................................................................... 114
5 PROPOSTA DE MTODO .............................................................................. 115
5.1 Ciclo de Vida ................................................................................................ 115
5.2 Atividades de Modelagem de Negcio ......................................................... 116
5.3 Atividades de Anlise ................................................................................... 117
5.4 Atividades de Projeto .................................................................................... 122
5.5 Atividades de Construo ............................................................................. 127
5.6 Papis........................................................................................................... 127
5.7 Artefatos ....................................................................................................... 128
5.8 Anlise do Mtodo ........................................................................................ 129
5.9 Consideraes Finais ................................................................................... 130
6 ESTUDOS DE CASO....................................................................................... 132
6.1 Caso Banco BES .......................................................................................... 132
6.2 Caso NF-e .................................................................................................... 152
6.3 Anlise dos Resultados ................................................................................ 167
6.4 Consideraes Finais ................................................................................... 169
7 CONCLUSO .................................................................................................. 170
7.1 Contribuies do Trabalho............................................................................ 170
7.2 Trabalhos Futuros ........................................................................................ 171
REFERNCIAS....................................................................................................... 173
 14

1 INTRODUO

Atualmente, cada vez mais as empresas pertencentes s mais diversas reas fazem
uso da Tecnologia da Informao (TI) para conduzir seus negcios.

Devido ao avano da Internet e das tecnologias de integrao e comunicao,

cada vez mais comum as organizaes fazerem uso do meio eletrnico para realizar
suas interaes com clientes, fornecedores e parceiros.

As empresas vm empregando com cada vez mais intensidade sistemas de

informao no suporte aos seus processos de negcio, com o intuito de automatizar
atividades e aumentar a produtividade. As empresas utilizam sistemas de
informao como ERPs para controlar sua operao, CRMs para gerenciar
informaes sobre o relacionamento com seus clientes, Supply Chain Management
para gerenciar interaes com parceiros, fornecedores e consumidores. Dentro
desta infra-estrutura de TI, cada sistema possui um conjunto de dados e
informaes prprio. Devido ao fato de os processos de negcio envolverem
diversas reas da organizao, eles passam a demandar funes de mais de um
sistema de informao e tornam necessria a troca de informaes entre sistemas.

Principalmente nas organizaes de maior porte, estes sistemas de informao

constituem ambientes extremamente complexos e heterogneos, onde as
aplicaes geralmente fazem uso de diferentes tecnologias, linguagens e protocolos.
comum encontrar em um mesmo ambiente aplicaes desenvolvidas com
tecnologia Web, softwares Commercial Off-The-Shelf (COTS) proprietrios e
aplicaes legadas em mainframe. Para suportar a comunicao entre elas, so
utilizados adaptadores, conectores e middlewares de integrao.

Os negcios tm se tornado mais dinmicos, exigindo mais agilidade por parte das
organizaes e, conseqentemente, de suas reas de TI. necessrio que a
arquitetura de sistemas de informao seja capaz de se adaptar rapidamente s
necessidades de negcio, em constante mudana. No entanto, em um ambiente de
TI heterogneo este tipo de mudana difcil de realizar.

Dentro deste cenrio, vem se desenvolvendo e sendo aceito o conceito de

Arquitetura Orientada a Servios (SOA). O modelo de referncia do OASIS (OASIS
SOA REFERENCE MODEL TC, 2006) define SOA como um paradigma para
 15

organizar e utilizar competncias distribudas entre vrios domnios. Trata-se de um

modo de estruturar as aplicaes de software em elementos chamados servios.

1.1 Motivao

Para se projetar aplicaes que efetivamente sigam a orientao a servios e para

que elas realmente faam uso dos benefcios trazidos pelo paradigma, necessrio
haver uma ateno especial na identificao e especificao dos servios que as
compem.

Os servios que apoiaro os processos de negcio e antedero aos requisitos

devem ser definidos de forma adequada, para que eles apresentem atributos como
reusabilidade e flexibilidade e estejam em alinhamento com as metas de negcio.
Alm disso, os servios devem ser especificados de modo a fazer parte de um
repositrio de servios reusveis, que podem ser ento orquestrados para apoiar os
processos de negcio.

necessrio haver algum tipo de mtodo para, a partir dos requisitos e metas de
negcio, identificar e modelar processos consistentes que faam uso de servios
disponveis na infra-estrutura de TI ou de novos servios a serem desenvolvidos. No
caso de novos servios, o mtodo deve abordar atividades para especific-los de
modo que eles possam ser implementados utilizando mtodos j existentes e
consolidados.

Tal mtodo deve ser previsvel e repetvel, conduzindo de maneira consistente as

atividades de anlise e especificao. De preferncia, deve fazer uso de ferramentas
e notaes amplamente conhecidas para a modelagem e representao das
informaes e para a gerao de artefatos. Desta maneira, a adoo do mtodo
seria facilitada e traria menos impactos aos processos de desenvolvimento j
existente na organizao.
 16

1.2 Objetivo

O objetivo deste trabalho consiste em propor um mtodo de anlise e projeto de

aplicaes orientadas a servios baseado na anlise crtica de mtodos existentes.
Para tal, um conjunto de requisitos de anlise e projeto orientados a servios
definido para guiar a elaborao do mtodo proposto.

O mtodo apresentado tem como propsito disciplinar o procedimento de

identificao, anlise e especificao de um conjunto de servios alinhados aos
requisitos de negcio e aderentes aos princpios de orientao a servios. A
aplicao do mtodo tem como resultado um grupo de especificaes de servios,
que pode ser ento implementados utilizando-se tcnicas de desenvolvimento
convencionais.

A proposta de mtodo tem como ponto de partida a modelagem de negcio, na

forma de casos de uso e modelos de processo de negcio, passa pela identificao
e especificao dos servios que compem a soluo, e tem como produto final os
artefatos que compem a especificao de cada servio, incluindo a interface do
servio, suas operaes e mensagens, e seus requisitos funcionais e no-
funcionais.

Considerando-se o ciclo de vida dos processos de negcio e o ciclo de vida dos

sistemas de informao como dois processos distintos porm interligados, pode-se
dizer que tal mtodo de anlise e projeto orientado a servios serviria como ponte
para chegar-se s especificaes dos sistemas a partir dos processos de negcio
modelados. Os servios seriam os elementos responsveis por realizar esta ligao,
por possurem a caracterstica de serem elementos desenvolvidos pela TI para
prover funes de negcio.

1.3 Justificativa

Existem alguns poucos estudos na rea de metodologias de desenvolvimento

voltadas para SOA. Papazoglou e Van Den Heuvel (2006) descrevem as atividades
do ciclo de vida dos servios, que consiste num processo cclico e iterativo, que
 17

passa pela modelagem de processos, anlise, projeto, implementao e execuo e

monitoria. O mtodo de Papazoglou e Van Den Heuvel utiliza a tecnologia de Web
Services para especificar e implementar os servios.

A empresa IBM (2007) possui uma contribuio, que um plugin a ser aplicado ao
Rational Unified Process (RUP) para o desenvolvimento de aplicaes orientadas a
servios. Este plugin acrescenta uma srie de tarefas, papis e artefatos ao RUP de
modo a adapt-lo para projetos de aplicaes orientadas a servios.

Em seu livro sobre SOA, Erl (2005) descreve um mtodo de anlise e projeto de
servios baseado nos princpios da orientao a servios. Marks e Bell (2006)
tambm propem um mtodo de desenvolvimento de servios, focando nas etapas
de anlise e projeto.

Ainda no existe uma convergncia das diversas propostas em direo a uma

padronizao, o que deixa o terreno aberto para discusso e apresentao de novas
propostas (RAMOLLARI; DRANIDIS; SIMONS, 2007). Torna-se necessria uma
anlise das propostas existentes e dos benefcios que cada uma delas traz. Com
base nesta anlise, pode-se propor e instanciar um mtodo de modo que unifique as
boas prticas existentes.

O trabalho realizado tem como resultado trs contribuies acadmicas principais. A

primeira consiste em uma anlise crtica e comparativa das propostas de mtodo de
desenvolvimento orientado a servios disponveis atualmente. Com a crescente
adoo do conceito de SOA pelas organizaes, torna-se necessria uma discusso
sobre como desenvolver software segundo o paradigma da orientao a servios.
Apesar de existirem diversas propostas de mtodo, ainda no h uma abordagem
predominante ou um consenso sobre o assunto. Por esse motivo, este trabalho
busca contribuir realizando uma anlise desses mtodos, criticando-os e
identificando as boas prticas propostas.

A segunda o levantamento de um conjunto de requisitos de anlise e projeto

orientados a servios. Baseado na anlise dos mtodos e das boas prticas
identificadas, este trabalho levanta requisitos que devem ser atendidos por um
mtodo orientado a servios.

A terceira contribuio o prprio mtodo elaborado a partir do estudo realizado.

Alm de discutir sobre as alternativas existentes, este trabalho ainda procura
 18

contribuir apresentando uma nova proposta de mtodo com o intuito de atender aos
requisitos levantados. O resultado um mtodo de anlise e projeto orientado a
servios com suas atividades, papis e artefatos definidos. Alm da descrio do
mtodo, so apresentados estudos de caso que documentam sua aplicao.

1.4 Organizao

O presente trabalho est organizado em sete captulos, mais a seo de referncias.

O primeiro captulo, a Introduo, apresenta o trabalho descrevendo suas

motivaes, seus objetivos e justificativas.

No segundo captulo, Arquitetura Orientada a Servios, feita uma caracterizao

do conceito de SOA.

O terceiro captulo, Mtodos de Anlise e Projeto Orientados a Servios, contm as

descries e anlises das propostas de mtodos existentes.

O quarto captulo, Requisitos de um Mtodo de Anlise e Projeto Orientado a

Servios, enumera e descreve uma srie de requisitos levantados a partir das
anlises do captulo trs.

O captulo cinco, Proposta de Mtodo, mostra o resultado das anlises dos mtodos
e dos requisitos, na forma de um novo mtodo de anlise e projeto SOA.

O sexto captulo, Estudos de Caso, descreve os casos de aplicao do mtodo a

anlise dos resultados.

Por fim, o captulo Concluso discute as contribuies do trabalho e propes

trabalhos futuros que podero dar continuidade ao mtodo proposto.

Na seo Referncias, so apresentadas as referncias usadas para a elaborao

deste trabalho.
 19

2 ARQUITETURA ORIENTADA A SERVIOS

Para se poder discutir mtodos de anlise e projeto orientados a servios,

necessrio um entendimento claro do paradigma de Arquitetura Orientada a
Servios (SOA) e do prprio conceito de servio em si. Por ser um tema que tem
ganhado relevncia h no muito tempo, no existe ainda um consenso definitivo
sobre tais conceitos. Por meio da anlise das caractersticas do paradigma e das
interpretaes de alguns autores, este captulo busca estabelecer um entendimento
sobre sua definio.

2.1 Definio de Arquitetura Orientada a Servios

Basicamente, Arquitetura Orientada a Servios (SOA) um paradigma de

construo e integrao de software que estrutura aplicaes em elementos
modulares chamados servios. O servio, a unidade fundamental de uma arquitetura
SOA, um elemento computacional que tem como propsito desempenhar uma
funo especfica e que pode ser utilizado por um cliente.

Segundo os conceitos bsicos de SOA, um servio composto por uma interface e

uma implementao. Geralmente, um servio consiste em uma funo de negcio
desempenhada por um mdulo de software (a implementao) e encapsulada por
uma interface bem definida e acessvel queles que desejam utilizar o servio, ou
seja, os potenciais clientes. Os clientes do servio no tm acesso aos detalhes de
como ele foi construdo, mas apenas aos detalhes expostos em sua interface. A
interface define as funes desempenhadas pelo servio e eventuais precondies
para utiliz-lo, mas no revela como estas funes so realizadas. Esta forma de
encapsulamento conhecida como caixa-preta e um princpio caracterstico de
paradigmas como orientao a objetos e componentes de software. Porm,
diferentemente destes, servios representam funes completas de negcio e so
projetados de modo a serem usados no somente no mbito de um programa ou
sistema, mas no mbito da organizao ou at entre organizaes (PAPAZOGLOU,
2003).
 20

Desta maneira, uma arquitetura SOA possibilita uma infra-estrutura para

computao distribuda, por meio de servios que podem ser fornecidos e
consumidos dentro de uma organizao e entre organizaes, por meio de redes de
comunicao como a Internet.

Uma arquitetura SOA bsica caracterizada pelas interaes entre trs tipos de
agentes de software: os Provedores de Servio, os Consumidores (ou Clientes) de
Servio e o Registro de Servio (HUHNS; SINGH, 2005). As interaes entre estes
agentes podem ser visualizadas na Figura 2.1.

Figura 2.1: Agentes de uma arquitetura SOA (PAPAZOGLOU, 2003)

Os servios so oferecidos pelos Provedores de Servio, organizaes responsveis

por desenvolver suas implementaes, fornecer suas descries e prestar suporte
tcnico e de negcio. De modo geral, os Provedores disponibilizam mdulos de
software (as implementaes dos servios) que podem ser acessados atravs de
uma rede e publicam suas descries em um Registro de Servios, agente que
abriga informaes sobre as funes oferecidas, os requisitos para se utilizar o
servio e orientaes sobre como realizar a interao. o Registro de Servios que
torna essas informaes disponveis para serem consultadas por clientes em
potencial. Por sua vez, os Consumidores de Servio so os agentes que necessitam
solicitar a execuo de um Servio. Os Consumidores buscam nos Registros a
descrio de um servio que satisfaa s suas necessidades e, ao encontr-la,
utilizam esta descrio para ligar-se ao Provedor e realizar a invocao do servio.
Note que os papis de Provedor e Consumidor so lgicos, de modo que um mesmo
agente pode exibir caractersticas de ambos dependendo do contexto
(PAPAZOGLOU, 2003).
 21

A palavra servio pode ser definida como a execuo de trabalho ou desempenho

de funes, ordenados por um requisitante. No contexto especfico de sistemas de
software, servio ainda est ligado a conceitos como a capacidade de realizar
trabalho para outro, a especificao do trabalho oferecido e a oferta de realizar
trabalho para outro. No contexto de SOA, um servio tem significado semelhante, j
que consiste em um software capaz de realizar uma funo especfica quando
solicitado por seus consumidores.

Os diversos autores da literatura sobre o assunto citam e descrevem seus prprios

conjuntos de caractersticas de um servio, mas no h um consenso sobre o que
define exatamente um servio, pois cada um foca em aspectos diferentes do
paradigma. Por isso, cada uma destas caractersticas deve ser analisada para
chegar-se a um entendimento do que vem a ser orientao a servios. A seguir so
analisadas as diversas interpretaes do conceito de SOA, em ordem cronolgica de
publicao.

2.1.1 Papazoglou

Papazoglou (2003) discute o assunto SOA sob uma viso mais ampla, fazendo uso
do termo Computao Orientada a Servios (SOC). Papazoglou define SOC como
sendo o paradigma de computao que utiliza servios como elementos
fundamentais para desenvolver solues e aplicaes distribudas. Segundo o autor,
um servio seria um elemento computacional auto-descritivo e independente de
plataforma que possibilita a composio de aplicaes distribudas de maneira
rpida e com baixo custo. Os servios podem executar funes dos mais diversos
nveis de granularidade, representando uma simples resposta a uma requisio ou
at um processo de negcio inteiro. Ainda, segundo Papazoglou, servios so
baseados em padres e protocolos abertos de interao e descrio de interfaces.

Conforme pode ser visto na Figura 2.2, uma arquitetura orientada a servios pode
ser interpretada por uma hierarquia com diversos nveis de abstrao. Segundo esta
hierarquia, a organizao pode ser dividida em domnios de negcio, que agrupam
processos com funes e competncias em comum. Um domnio formado por
processos de negcio, que por sua vez, so composies de diversos servios de
 22

negcio. Estes servios de negcio so construdos sobre uma camada de servios

de infra-estrutura, que so implementados por componentes de software. Dando
suporte a estes componentes, podem existir diversos tipos de sistemas de back-end,
como sistemas de ERP e CRM, bases de dados, aplicaes-pacote e aplicaes
legadas.

Figura 2.2: Hierarquia de uma arquitetura SOA (PAPAZOGLOU; VAN DEN HEUVEL, 2006)

2.1.2 Erl

Thomas Erl (2005) descreve o conceito de SOA discursando sobre suas

caractersticas e possveis benefcios. Erl apia fortemente o uso de padres como o
Extensible Markup Language (XML) (BRAY et al., 2006) para a representao de
dados e a tecnologia Web Services para implementar as interaes entre servios.
Apesar de abordar a implementao de servios atravs do uso de Web Services,
Erl procura esclarecer que uma arquitetura SOA no se limita a um ambiente de
computao distribuda utilizando Web Services, mas tambm deve seguir os
princpios de orientao a servios.
 23

Ao descrever a estrutura de uma arquitetura SOA, Erl faz analogia com a arquitetura
de Web Services e define os componentes lgicos da arquitetura como sendo
mensagem, operao, servio e processo, cujas interaes so exibidas na Figura
2.3. As mensagens so as unidades de comunicao e representam os dados
necessrios para a realizao de uma unidade de trabalho e os dados produzidos
por estas unidades. J as operaes, que por sua vez so unidades de trabalho
executadas, processam os dados recebidos atravs das mensagens. Um servio
composto por um conjunto de operaes relacionadas, constituindo uma unidade de
lgica de processamento. Por fim, um processo uma unidade de lgica de
automao e formado pela agregao de diversas unidades de trabalho
(operaes executadas) coordenadas de acordo com algumas regras de negcio. O
processo representa uma parcela grande de trabalho que executada por uma srie
de unidades menores de trabalho.

Figura 2.3: Relacionamentos entre os componentes de uma arquitetura SOA (ERL, 2005)

Segundo Erl (2005), SOA tem como origem a teoria de engenharia de software
conhecida como separao de assuntos. Segundo esta teoria, deve-se dividir um
problema grande em assuntos menores para que a soluo possa ser decomposta
em vrias partes, sendo que cada parte deve solucionar um assunto. Assim como a
orientao a objetos, a orientao a servios uma maneira de se conseguir essa
separao de assuntos, atravs de princpios como reuso, baixo acoplamento e
abstrao.
 24

Em publicaes posteriores (ERL, 2007), o autor aprofunda a discusso do

paradigma de orientao a servios, descrevendo-o como uma composio de
diversos princpios.

2.1.3 IBM

J a IBM, empresa multinacional de origem norte-americana que atua nas reas de

software, hardware e consultoria, publicou um livro sobre SOA (BIEBERSTEIN et al.,
2005) onde so discutidas vrias definies do termo. Algumas definies de
negcio que citam caractersticas como baixo acoplamento, reuso e
interoperabilidade so mostradas com outras definies mais tcnicas, que citam a
existncia de interfaces invocveis e a utilizao de padres de Web Services. A
partir destas definies, os autores chegam seguinte:

Uma arquitetura orientada a servios um arcabouo para integrar processos de negcio e a

infra-estrutura de TI de suporte na forma de componentes padronizados e seguros servios
que podem ser reusados e combinados para atender prioridades de negcio em mudana
constante.

A IBM ainda destaca o alinhamento entre os processos de negcio e a infra-

estrutura de TI, conceituando servios como elementos que podem ser reusados e
combinados para atender s necessidades de negcio.

2.1.4 Marks e Bell

Segundo a definio de Marks e Bell (2006), SOA uma arquitetura de negcios

conceitual onde as funes de negcio, ou lgica de aplicao, so disponibilizadas
para os consumidores na forma de servios reusveis e compartilhados em uma
rede de TI. Servios so mdulos de funcionalidade de negcio com interfaces
expostas que so invocados por meio de troca de mensagens entre consumidores e
provedores de servios.

Marks e Bell afirmam que o conceito de servio adequado para representar

transaes que a rea de TI oferece para seus clientes e usurios de negcio.
Servio um conceito facilmente compreendido pela perspectiva de TI e pela de
 25

negcio, alm de possuir a granularidade apropriada para ser mapeado para

atividades automatizadas de um processo de negcio.

Segundo os autores, em uma organizao podem existir dois tipos de servios: os

servios de negcio e os servios de tecnologia. Os servios de negcio refletem
conceitos e eventos relativos aos processos de negcio. A execuo de um servio
de negcio pode ser associada realizao de uma funo ou atividade de um
processo. Estes servios possuem alta granularidade e representam conceitos reais
de negcio como abrir nova conta ou obter informaes de cliente. Estes so
exemplos de eventos reais que podem ser executados por uma pessoa (um
atendente, por exemplo), por um sistema ou por um servio de negcio.

J os servios de tecnologia so independentes de reas ou domnios de negcio,

sendo reusveis em diversos processos, podendo ser comuns organizao como
um todo. Eles representam servios de TI, como segurana, auditoria,
transformao de dados, entre outros. Os servios de tecnologia provem a infra-
estrutura de apoio aos servios de negcio.

Devido sua natureza, os servios de negcio estabelecem um termo comum s

linguagens de negcio e de TI, podendo assim, facilitar a comunicao e o
alinhamento entre a rea de TI e os usurios/clientes de negcio durante a anlise e
o projeto de servios. Por ser a unidade fundamental de anlise do SOA e por
possuir correspondncia direta com o conceito de processo de negcio, o servio de
negcio possibilita uma melhoria na identificao de requisitos de negcio e
promove o alinhamento entre as reas de negcio e de TI.

Servios podem servir como abstraes para componentes de tecnologia, processos

de negcio, entidades de dados ou elementos conceituais, encapsulando negcio e
tecnologia. Baseado nisso, Marks e Bell (2006) afirmam que servios podem ser
interpretados por trs diferentes vises: uma viso conceitual, uma viso de
processo de negcio e uma viso tecnolgica. A viso conceitual define um servio
com base em suas caractersticas, seu escopo lgico e o valor que ele agrega ao
negcio. A viso de processo de negcio interpreta servios como uma seqncia
orquestrada de atividades de um processo. J segundo a viso tecnolgica, um
servio uma abstrao de uma soluo tecnolgica, isto , uma interface para uma
 26

implementao especfica, como aplicaes comerciais, sistemas legados ou

plataformas de integrao.

A Figura 2.4 mostra os elementos que formam uma arquitetura SOA segundo Marks
e Bell (2006). A estratgia de SOA composta pelo planejamento e pelas decises
relativas arquitetura orientada a servios da organizao. Esta estratgia direciona
o modelo de governana de SOA (KENNEY; PLUMMER, 2007), isto , o conjunto
de padres e polticas que definem a viso conceitual da arquitetura, ou seu modelo
de arquitetura. A governana abrange processos, papis e responsabilidades que
devem ser seguidos para garantir a conformidade da arquitetura implementada com
o modelo de arquitetura. De acordo com a governana estabelecida, aplicada a
tecnologia de implementao que torna realidade a viso conceitual da arquitetura
SOA. esta tecnologia que possibilita a construo e operao dos servios, que
por sua vez so o ncleo da arquitetura. Eles constituem o principal ativo de uma
arquitetura SOA e, por isso, necessitam de um processo de anlise e projeto bem
definido que garanta que eles possuam as caractersticas de reusabilidade,
interoperabilidade, entre outras. A governana de SOA tambm deve levar em
considerao aspectos de comportamento e cultura da organizao, que podero
sofrer mudanas para adequao ao modelo de arquitetura. Por fim, um conjunto de
mtricas dever ser estabelecido e aferido para verificar os resultados obtidos pela
arquitetura SOA, tanto em termos de desempenho de processos de negcio quanto
de retorno sobre investimento (ROI).
 27

Figura 2.4: Elementos de uma arquitetura SOA (MARKS; BELL, 2006)

2.1.5 OASIS

O OASIS (Organization for the Advancement of Structured Information Standards)

uma organizao sem fins lucrativos que trabalha no desenvolvimento de padres
abertos de Tecnologia de Informao. Dentre os padres desenvolvidos, encontram-
se diversas especificaes e modelos relacionados a Web Services e SOA.

O OASIS elaborou um modelo de referncia de SOA (OASIS SOA REFERENCE

MODEL TC, 2006) com o intuito de definir os conceitos envolvidos em uma
arquitetura SOA e os relacionamentos entre eles. O propsito deste modelo de
referncia estabelecer uma base conceitual que servir de guia para a criao de
padres e arquiteturas de referncia e implementaes. Este modelo aborda a
arquitetura orientada a servios como um modelo abstrato, no focando em
requisitos tcnicos ou especificando mtodos de implementao.

Segundo a definio do OASIS, arquitetura orientada a servios um paradigma

para organizar e utilizar competncias distribudas que podem estar sob o controle
 28

de diferentes domnios. Competncia definida como um elemento criado para

solucionar ou dar suporte para um determinado problema de negcio. E, no cenrio
da computao distribuda, comum os requisitos de uma entidade poderem ser
satisfeitos por uma competncia oferecida por outro domnio.

Neste contexto surgem algumas questes, como a no existncia de uma correlao

exata entre necessidades e competncias, a possibilidade das competncias
possurem diversas granularidades e o fato de certas necessidades exigirem a
combinao de vrias competncias. A arquitetura orientada a servios vem para
servir como um arcabouo para casar necessidades e competncias e combinar
competncias para atende a estas necessidades.

Assim, chega-se definio de servios segundo o OASIS, que o mecanismo que

possibilita que necessidades e competncias sejam combinadas.

O modelo de referncia baseia o paradigma de orientao a servios em trs

conceitos fundamentais: visibilidade, interao e efeito no mundo real. Visibilidade
corresponde possibilidade de as entidades com necessidades e competncias
verem umas s outras, isto , de contatar-se. obtida pela disponibilizao de
descries das funes, dos requisitos tcnicos, restries e polticas e pela
existncia de um meio de conexo entre as entidades. Interao consiste no ato de
se utilizar uma competncia. Geralmente, a interao realizada por meio de troca
de mensagens entre os consumidores e provedores de servio. J o propsito de se
utilizar uma competncia o de obter um ou mais Efeitos no mundo real. Um efeito
o resultado de uma interao e pode ser um retorno de informao ou uma
mudana no estado de uma entidade envolvida na interao. Os efeitos no mundo
real esperados determinam se uma competncia atende aos requisitos de uma dada
necessidade.

2.1.6 Open Group

O Open Group outra organizao que desenvolve padres da rea de TI, que
produziu tambm uma definio do que SOA (THE OPEN GROUP, 2006).
 29

Segundo esta definio, arquitetura orientada a servios um estilo arquitetural que

suporta orientao a servios. Estilo arquitetural definido como a combinao de
caractersticas distintivas sobre a qual uma arquitetura realizada ou expressada.

Ainda segundo o Open Group, um servio:

uma representao lgica de uma atividade de negcio repetvel que possui

um resultado especfico.
auto-contido.
Pode ser composto por outros servios.
uma caixa preta para seus consumidores.

O estilo arquitetural SOA possui as seguintes caractersticas distintivas:

baseado no projeto de servios que representam atividades de negcio

do mundo real compreendendo os processos de negcio da organizao e
entre organizaes.
A representao de servio utiliza descries de negcio para prover contexto
(por exemplo, processo de negcio, meta, regra, poltica, interface de servio
e componente de servio) e implementa servios usando orquestrao de
servios.
Exige requisitos nicos da infra-estrutura recomendado que
implementaes usem padres abertos para realizar interoperabilidade e
transparncia de localizao
Implementaes so especficas de um ambiente elas esto restritas ou
habilitadas por contexto e devem ser descritas dentro deste contexto.
Requer forte padronizao de representao e implementao de servio.
Requer um Teste Litmus1, que determina um bom servio.

2.2 Elementos de uma Arquitetura Orientada a Servios

Segundo Krafzig, Banke e Slama (2004), uma arquitetura orientada a servios

composta por diversos elementos que se relacionam entre si e que, por sua vez,

1
Um teste cujo resultado baseia-se em um nico fator. Neste caso, o Teste Litmus indica se um
servio bom ou no.
 30

podem ser compostos por outros. Sendo assim uma arquitetura SOA pode ser
representada por uma hierarquia de elementos, como na Figura 2.5.

Figura 2.5: Elementos de uma Arquitetura Orientada a Servios (KRAFZIG; BANKE; SLAMA,
2004)

2.2.1 Aplicaes Front-end

Como parte da arquitetura SOA, esto as aplicaes de front-end, que constituem a

camada de apresentao para o usurio final. So aplicaes que possuem algum
tipo de Interface Grfica com o Usurio (GUI), como pginas Web e portais. por
meio destas interfaces que os usurios de negcio executam atividades de um
processo de negcio, monitoram a execuo e o desempenho de servios e
processos.

2.2.2 Servio

Em uma arquitetura SOA, a camada de negcio no formada por aplicaes e

sistemas separados, cada um com seus prprios conjuntos de dados e funes. As
 31

funes so disponibilizadas na forma de servios, que podem ser compostos para

suportar um processo de negcio.

Servios so compostos por um contrato, uma implementao e uma interface.

2.2.3 Repositrio de Servios

Um repositrio de servios uma base de dados que prov informaes sobre os

servios em uma arquitetura SOA. Potenciais consumidores consultam um ou mais
repositrios para obter informaes sobre servios que podem satisfazer suas
necessidades e sobre como acess-los (o contrato do servio). Para isso, um
repositrio pode prover funes de busca de servios.

Demais informaes que podem ser oferecidas por um repositrio so: localizao
fsica do servio, dados do provedor, custos de utilizao, restries de ordem
tcnica, requisitos de segurana e de nvel de servio.

Em implementaes de SOA com Web Services, repositrios so comumente

construdos baseados no padro Universal Description, Discovery and Integration
(UDDI).

2.2.4 Barramento de Servios

O barramento de servios, ou Enterprise Service Bus (ESB), um middleware que

possibilita a comunicao entre vrios componentes de uma arquitetura SOA. O
barramento pode adicionalmente prover funes como segurana, tolerncia a
falhas, transaes distribudas, auditoria, acesso unificado a diferentes modos
sncronos e assncronos, escalabilidade, entre outros (KEEN et al., 2005).

O ESB permite que um ambiente heterogneo com diversas tecnologias e

protocolos de comunicao possam se conectar em uma arquitetura SOA.
 32

2.2.5 Contrato

O contrato oferece uma descrio do servio de maneira independente de

tecnologia, definindo funcionalidade, propsito, modo de utilizao e restries. O
contrato do servio normalmente representado com o uso de uma linguagem, de
preferncia baseada em padres abertos. Os contratos de servios so geralmente
armazenados e disponibilizados nos repositrios de servio.

2.2.6 Implementao

o elemento que efetivamente executa a funcionalidade definida pelo servio.

Pelo fato de no ser acessada diretamente pelo cliente (este tem conhecimento
apenas de sua interface), a implementao pode sofrer modificaes de
manuteno e evoluo, sem que o impacto seja percebido pelo cliente. Uma
implementao pode ser inclusive substituda sem que ocorra tal impacto. Isto se d
devido ao desacoplamento proporcionado pela interface.

Para executar a funcionalidade do servio, a implementao combina lgica de

negcio mais dados.

2.2.7 Interface

A interface a poro do servio exposta pelo Provedor para os Consumidores. Seu

propsito abstrair para os Consumidores os detalhes da implementao, expondo
apenas as informaes necessrias para que o Consumidor seja capaz de utilizar o
servio.

2.2.8 Lgica de Negcio

Corresponde s regras de negcio envolvidas na funcionalidade dos servios e que

so executadas por sua implementao.
 33

2.2.9 Dados

As regras de negcio do servio manipulam dados, que podem ser fornecidos pelos
consumidores ou serem provenientes de aplicaes de back-end, como bases de
dados, sistemas de informao corporativos e at sistemas legados em alta
plataforma.

2.3 Princpios de Orientao a Servios

Segundo Erl (2005), o paradigma de orientao a servios pode ser descrito a partir
de uma srie de princpios, que devem ser seguidos na construo de uma
arquitetura: reuso, contrato padronizado, baixo acoplamento, abstrao, facilidade
de composio, autonomia, independncia de estado, localizao e
interoperabilidade.

2.3.1 Reuso

A orientao a servios visa tornar cada servio reusvel, mesmo que no haja
requisitos especficos para um dado servio no momento em que ele desenvolvido.
(ERL, 2005).

Servios reusveis so aqueles que podem possuir valor em diversos contextos de

processos de negcio e interaes intra e inter-organizacionais e, por isso, devem
suportar diversos padres de consumo. Devido a essa natureza, novos clientes
podem reusar um servio de uma maneira que no foi prevista em seu projeto
original. Nestes casos, deve haver uma infra-estrutura de gerenciamento e
governana de servios que garanta o desempenho e devido funcionamento de tal
servio (MARKS; BELL, 2006).

Os servios devem ser projetados considerando-se as vrias formas de reuso, como

transaes entre aplicaes, composio de servios e processos de negcio e uso
como servios utilitrios. A reusabilidade de um servio relacionada sua
 34

granularidade, sendo que quanto mais alta a granularidade de um servio, menores

so as possibilidades de ele ser usado em mais de um processo de negcio.

2.3.2 Contrato padronizado

Um servio deve possuir um contrato bem definido que descreve para o mundo
externo a funcionalidade por ele exposta e ao mesmo tempo encapsula os detalhes
especficos de sua implementao (MARKS; BELL, 2006). O contrato, ou a interface
do servio, disponibiliza as seguintes informaes para os consumidores: a
localizao do servio, as operaes executadas, as mensagens de entrada e sada
utilizadas pelo servio e regras para sua utilizao (ERL, 2005). Podem conter
tambm detalhes semnticos das operaes do servio.

O contrato representa um acordo firmado entre o Provedor do servio e seus

Consumidores, criando uma relao de dependncia. Por isso, deve haver uma
ateno especial na manuteno e versionamento destes documentos.

Contratos de servio devem ser representados em uma linguagem ou notao bem

definida, seguindo padres abertos que garantam a interoperabilidade do servio.
No contexto de Web Services, contratos de servio so definidos por documentos
em Web Services Description Language (WSDL) (CHISTENSEN et al., 2006),
esquemas na linguagem XML Schema Definition (XSD) (FALLSIDE, 2004) e
polticas. Em um documento WSDL, so especificados os tipos de dados envolvidos,
as mensagens e as operaes do servio. J os esquemas XSD so a especificao
dos tipos de dados e das mensagens XML que sero utilizadas.

2.3.3 Baixo acoplamento

Uma caracterstica importante de servios em uma arquitetura orientada a servios

a de que eles devem possuir baixo acoplamento entre si, ou devem ser fracamente
acoplados. No entanto, na literatura, o termo baixo acoplamento pode possuir vrios
significados prticos.
 35

Um servio fracamente acoplado pode significar um servio cuja implementao

pode ser substituda, modificada ou evoluda ao longo do tempo sem causar
impactos nos Consumidores do servio (MARKS; BELL, 2006). Neste caso, est-se
referindo ao acoplamento entre a implementao do servio e seus Consumidores.

Nesta mesma linha, baixo acoplamento pode ser indicado pela transparncia de
localizao. Um servio 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 condio em que um servio est

ciente da existncia de outros servios mas ainda independente deles (ERL,
2005).

2.3.4 Abstrao

Um princpio importante na orientao a servios a abstrao ou encapsulamento

da lgica interna de um servio por meio de sua interface. Ao separar interface de
implementao, o servio age como uma caixa preta e expe aos seus
Consumidores somente informaes sobre as operaes disponveis.

A granularidade de um servio diretamente relacionada com a quantidade de

funcionalidade que encapsulada pelas operaes de um servio (ERL, 2005).

2.3.5 Facilidade de composio

Servios devem possuir facilidade de composio, isto , devem ser projetados de

forma que possam participar de composies com outros, formando servios
compostos, ou ser orquestrados no contexto de um processo de negcio. Para isso,
devem ser desacoplados e suas operaes devem ser as mais atmicas possveis
(MARKS; BELL, 2006) (ERL, 2005).
 36

2.3.6 Autonomia

Autonomia exige que a lgica de processamento encapsulada por um servio fique

restrita dentro de uma certa fronteira estabelecida, o que evita a dependncia com
relao a outros servios. Isto permite que um servio tenha controle total sobre sua
prpria lgica e possa exercer um tipo de auto-governana.

A autonomia de um servio pode-se dar em dois nveis diferentes (ERL, 2005): no

nvel do servio e autonomia pura.

Na autonomia no nvel do servio, os limites entre os servios so distintos, mas

eles ainda podem compartilhar recursos encapsulados, como bases de dados e
sistemas legados. Este cenrio comum no caso de diversos servios
desenvolvidos a partir de uma mesma aplicao j existente. Neste caso, os
servios compartilham a aplicao, mas fazem uso dela de maneira independente.

Na autonomia pura, a lgica e os dados encapsulados esto sob completo controle

do servio, no sendo compartilhada com outros.

2.3.7 Independncia de Estado

Um servio deve evitar armazenar informaes de estado e contexto ou minimizar o

perodo de tempo que estas informaes so mantidas (ERL, 2005). Isto quer dizer
que a resposta do servio para uma mensagem deve ser independente das
mensagens anteriores processadas pelo servio. Dependncia de contexto ou de
estado diminui o potencial de reuso do servio. Alm disso, enquanto o servio
retiver informaes de estado de um Consumidor, ele se torna indisponvel para
atender chamadas de outros Consumidores.

Para tornar um servio o mais independente possvel de estado, as mensagens

devem ser inteligentes, isto , deve ser adicionado s mensagens o mximo de
informao para que elas se tornem auto-suficientes e possam ser processadas sem
a necessidade de dados de estado.
 37

2.3.8 Localizao

Os servios devem ser localizveis, o que significa que suas interfaces devem ser
de alguma forma publicadas e tornadas visveis para os potenciais Consumidores.
Na arquitetura SOA bsica, essas interfaces so publicadas em um Registro de
Servios, de onde elas podem ser buscadas pelos Consumidores (MARKS; BELL,
2006).

2.3.9 Interoperabilidade

Servios devem ser interoperveis, isto , deve ser possvel interagir com um
servio independentemente da tecnologia empregada em sua implementao.
Quaisquer que sejam a linguagem de programao, a plataforma ou o sistema
operacional utilizados na construo dos Provedores, Clientes e Registros de
Servios, as interaes entre eles devem ser possveis. Para isso, essas interaes
devem ser realizadas utilizando-se padres e protocolos abertos compatveis com
qualquer tecnologia ou plataforma. Por isso, em uma arquitetura orientada a
servios, a proviso e o consumo de servios ocorrem de maneira transparente s
tecnologias e linguagens utilizadas em sua implementao, garantindo a
interoperabilidade entre servios.

Atualmente, os padres relacionados tecnologia Web Services (WSDL, SOAP,

UDDI) permitem a descrio de interfaces, a troca de mensagens e a busca por
servios de maneira neutra s plataformas e linguagens utilizadas. Por basearem-se
em padres abertos como o XML e o protocolo HTTP, que so largamente aceitos e
suportados, a tecnologia Web Services possibilita a obteno desta
interoperabilidade.

2.3.10 Granularidade de Servio

Granularidade um aspecto importante para se determinar o escopo de um servio.

Ao se identificar um servio, deve-se determinar se ele possuir baixa granularidade
 38

(servio tcnico ou de baixo nvel) ou alta granularidade (servio de negcio ou de

alto nvel). A granularidade depende de quanta funcionalidade encapsulada por um
servio, sendo que quanto mais funcionalidade, mais abrangente o escopo do
servio e mais alta sua granularidade. Servios de granularidade mais alta so
utilizados diretamente pelo negcio e podem ser formados pela composio de
servios de granularidade mais baixa.

Segundo a interpretao da empresa IBM (BIEBERSTEIN et al., 2005), os dois tipos

de servios so necessrios. Uma arquitetura SOA deve conter servios diretamente
relacionados e com alto valor para o negcio e servios tcnicos que encapsulam
lgica com alto potencial de reuso. Os servios de granularidade mais alta tero
menos consumidores, mas agregaro mais valor para o negcio. Eles tero tambm
alta dependncia em relao a servios de granularidade baixa, que por sua vez,
tero alto potencial de reuso e tero baixa dependncia com outros servios.

J Marks e Bell afirmam que servios devem possuir alta granularidade e

representar funes, processos e transaes de negcio, encapsulando demais
componentes de baixa granularidade (MARKS; BELL, 2006). Segundo os autores,
servios de baixa granularidade, como componentes de software, teriam pouca
utilidade direta para o negcio. Por isso, eles no compensariam o overhead de se
transformar em um servio e deveriam ser encapsulados por servios maiores.

2.3.11 Camadas de Servio

A orientao a servios pode trazer uma abstrao entre a lgica de negcio e a

infra-estrutura de TI, gerando um desacoplamento entre os modelos de processos
de negcios e a arquitetura de sistemas de informao. Em uma arquitetura
orientada a servios dando suporte tecnolgico aos processos de negcio de uma
empresa, a camada de servios localiza-se exatamente entre a camada de
processos e a infra-estrutura de aplicaes de TI (ERL, 2005). A camada de servios
cria uma abstrao entre os processos de negcio e as aplicaes (BIEBERSTEIN
et al., 2005), conforme mostra a Figura 2.6.
 39

Figura 2.6: Camadas de uma arquitetura SOA (ERL, 2005)

Baseado no princpio de composio, possvel dividir a camada de servios em

mais trs camadas de abstrao que determinam o tipo e a granularidade dos
servios. Assim, temos: a camada de servios de aplicao, a camada de servios
de negcio e a camada de orquestrao de servios. Na Figura 2.7, pode ser
visualizada a hierarquia das camadas de servios.
 40

Figura 2.7: Camadas de servios (ERL, 2005)

Os servios de aplicao possuem menor granularidade e representam os servios

de infra-estrutura de uma arquitetura SOA, oferecendo funes especficas de
tecnologia. O propsito dos servios de aplicao prover funes reusveis e
processar dados contidos em sistemas legados e novas aplicaes desenvolvidas.

Os servios de negcio so os elementos fundamentais da arquitetura SOA, pois

so aqueles que representam a lgica de negcio da organizao. So formados
pela composio de diversos servios de aplicao para implementar a lgica de
negcio. Podem representar tarefas de processo ou entidades de negcio.

Por fim, a camada de orquestrao de servios realiza a ligao entre os modelos

de processos de negcio e os servios da arquitetura SOA. O conceito de
orquestrao baseia-se na construo de processos de negcio a partir da
composio de diversos servios, por exemplo, utilizando uma linguagem de
orquestrao como o Web Services Business Process Execution Language (WS-
BPEL) (OASIS WSBPEL TC, 2007). Trata-se de uma linguagem para se especificar
o fluxo de trabalho e lgica de negcio envolvidos nas chamadas de Web Services.
Nesta camada esto os servios de processo, que possuem alta granularidade e
representam processos de negcio completos, encapsulando a lgica e regras de
negcio envolvidas.
 41

2.4 Benefcios e Desafios

Atingindo-se um entendimento sobre o conceito de SOA, pode-se pensar sobre

quais resultados podem ser obtidos por uma organizao ao adotar a orientao a
servios. Implementar e manter uma arquitetura orientada a servios dentro de uma
organizao uma tarefa custosa, que exige tempo, recursos e esforo, alm de
promover mudanas no comportamento e na cultura da organizao. Os resultados
do SOA devem ser tangveis e devem compensar o investimento realizado.

Desta maneira, so discutidos os benefcios e possveis desafios que podem ser

trazidos pela adoo da orientao a servios nas organizaes.

2.4.1 Facilidade de integrao

Uma arquitetura SOA baseada em servios intrinsecamente interoperveis (ERL,

2005). Devido ao uso de padres abertos de interao, aplicaes estruturadas na
forma de servios inerentemente possuem a capacidade de se comunicarem de
maneira interopervel. como se as aplicaes orientadas a servios j nascessem
pr-integradas, minimizando o esforo de se desenvolver integraes entre
aplicaes.

O modelo de servios tende a facilitar a integrao de aplicaes, uma vez que uma
arquitetura SOA uma maneira de se reorganizar uma infra-estrutura formada de
silos de software em um portflio de servios compartilhados. Em uma arquitetura
SOA, as aplicaes existentes e futuras podem acessar os servios sem a
necessidade de se desenvolver integraes ponto-a-ponto baseadas em protocolos
proprietrios. Assim, esta arquitetura pode ser utilizada em ambientes com mltiplas
aplicaes baseadas em variadas tecnologias e plataformas que necessitam
comunicar-se entre si. Para efetuar transaes entre elas, pode-se conectar e reusar
servios com esforo mnimo de programao e integrao (PAPAZOGLOU, 2003).

Marks e Bell chegam at a chamar este benefcio de integrao de custo zero

(MARKS; BELL, 2006). Tal afirmao baseia-se no fato de que no necessrio
nenhum esforo para realizar a converso entre protocolos e formatos para se
 42

estabelecer a comunicao entre aplicaes em uma arquitetura SOA, uma vez que
elas j estariam baseadas nos mesmos padres abertos de interao.

2.4.2 Padronizao das tecnologias

Como parte da implementao da arquitetura SOA em uma organizao,

desenvolvida toda uma infra-estrutura de comunicaes para viabilizar as interaes
inter e intra-aplicaes seguindo os princpios de orientao a servios. Esta infra-
estrutura de comunicao de servios passa a fazer parte da infra-estrutura de TI e
torna-se o padro de comunicao no mbito da organizao como um todo. Deste
modo, a organizao investe seus recursos focando-se em uma nica plataforma
tecnolgica de comunicao (ERL, 2005).

Alm disso, se forem utilizados a tecnologia de Web Services e os padres

baseados em XML para a implementao da arquitetura SOA, tem-se a
oportunidade de estabelecer o XML como uma plataforma padronizada de
representao de dados na organizao (ERL, 2005). Tendo-se um formato padro
para representar dados pode reduzir a complexidade do ambiente de aplicaes.
Desta maneira, estabelecem-se os documentos XML como o padro para troca de
informaes e os esquemas XML como o padro para representao das entidades
de dados.

A padronizao traz seus benefcios para a organizao, mas sua implementao

torna-se um desafio importante para as organizaes ao adotar o conceito de SOA
(ERL, 2005). necessrio garantir que os esquemas definidos nos vrios projetos
sigam as mesmas diretrizes e padres e formem um modelo de dados
organizacional, ou corre-se o risco de obter uma arquitetura no flexvel e acoplada
a aplicaes existentes.

2.4.3 Maior reuso de recursos

A orientao a servios prega que os servios sejam especificados de forma que

possam suportar o reuso de maneira inerente. O projeto de aplicaes voltadas para
 43

o reuso permite um reaproveitamento imediato de lgica pr-existente, bem como

cria oportunidades futuras de reuso por potenciais clientes (ERL, 2005). No longo
prazo, o reuso de servios tende a reduzir custos, prazos e esforo para
implementao de solues (BIEBERSTEIN et al., 2005).

Apesar de o projeto de servios reusveis exigir um esforo adicional (se comparado

ao esforo de se desenvolver um servio sem suporte a reuso), tal investimento
recompensado quando futuras aplicaes desenvolvidas reaproveitam as funes
existentes. Marks e Bell estimam como algo em torno de 50% o esforo adicional
para tornar um servio reusvel. Portanto, o ROI obtido no primeiro reuso do
servio, se considerarmos que o reuso representa uma economia do custo de se
desenvolver o servio a partir do zero (MARKS; BELL, 2006).

O uso de Web Services permite tambm encapsular funes de ambientes legados

de forma que estes possam fazer parte de uma arquitetura SOA. Isso permite a
interoperabilidade de sistemas legados sem a necessidade de integraes ponto-a-
ponto, que so custosas e inflexveis. Assim, reduz-se o custo de se integrar legados
e novas aplicaes e torna-se possvel que as novas aplicaes reusem funes
existentes no legado dentro do contexto de orientao a servios. Com a
possibilidade de se reusar sistemas legados, a necessidade de se substitu-los
passa a no ser to imediata (ERL, 2005).

2.4.4 Agilidade no negcio

A orientao a servios promove flexibilidade nas solues construdas, uma vez

que so constitudas por servios fracamente acoplados, sendo, portanto,
preparadas para mudanas. O projeto de servios com baixo acoplamento e a
possibilidade de realizar composies entre eles torna a arquitetura SOA um
ambiente mais adaptativo. A estruturao dos servios em camadas de negcio e de
tecnologia tambm gera flexibilidade, pois permite que ambos os domnios evoluam
e sofram alteraes de maneira isolada (ERL, 2005).

A orientao a servios pressupe que as aplicaes construdas tendem a evoluir

com o tempo, conforme os requisitos de negcio se alteram ou novos surgem. Em
uma arquitetura SOA bem estruturada, o impacto dessa evoluo minimizado, uma
 44

vez que propriedades como reuso e interoperabilidade permitem que a rea de TI

responda mais rapidamente s solicitaes da rea de negcio. Isto promove a
agilidade organizacional, que permite organizao responder prontamente aos
eventos do ambiente, reduzir o time-to-market de seus produtos e servios e obter
vantagem competitiva. No somente o tempo para se ter uma soluo pronta
diminudo, como tambm o custo e o esforo (ERL, 2005).

Deste modo, a orientao a servios busca responder aos requisitos de negcio em

prazos mais curtos e oferecer solues mais flexveis. As mudanas, que costumam
ser custosas e danosas em ambientes no flexveis, passam a ser facilitadas
(BIEBERSTEIN et al., 2005).

Para se atingir tal estado, necessrio que a infra-estrutura esteja padronizada e

que os servios efetivamente possuam caractersticas de baixo acoplamento,
reusabilidade e interoperabilidade.

2.4.5 Alinhamento com o negcio

A orientao a servios promove o alinhamento estratgico entre TI e negcio.

Devido ao fato de os servios representarem conceitos de negcio, o vnculo entre
as solues entregues pela rea de TI (os servios) e as metas estratgicas da
organizao (tanto de TI como de negcio) torna-se mais claro. Desta maneira, os
investimentos destinados a TI so justificados devido a essa percepo do valor
agregado (BIEBERSTEIN et al., 2005).

O servio pode ser visto tambm como uma maneira de uniformizar os vocabulrios
das reas de negcio e de TI dentro de uma organizao. Em uma organizao com
uma arquitetura SOA, o conceito de servio pode tornar-se um elemento de ligao
entre os profissionais de TI e os usurios/clientes das reas de negcio. Com um
termo comum no vocabulrio de ambas as reas, torna-se possvel estabelecer
metas de negcio baseadas diretamente no conceito de servio e tendo em mente
os servios existentes, alm de melhorar a comunicao e o entendimento no
relacionamento TI-negcio (MARKS; BELL, 2006).
 45

Quando o paradigma de orientao a servios aplicado para dar suporte aos

processos de negcio, a noo de atividade de processo pode ser mapeada
diretamente execuo de um servio de negcio orquestrado pelo processo.

Com o surgimento de linguagens para especificao e execuo de processos de

negcio como o WS-BPEL, reduziu-se o gap que existia entre os modelos de
processos elaborados pelos analistas de negcio e a implementao do fluxo de
trabalho desenvolvida pelos profissionais de TI. Quando um modelo de processo
elaborado seguindo a sintaxe do WS-BPEL, o prprio modelo torna-se o cdigo
executvel que ser utilizado na implementao do processo (ERL, 2005).

2.4.6 Requisitos de desempenho

Em uma arquitetura com um grande nmero de servios interagindo uns com os

outros, esperado um aumento no volume de comunicaes baseadas em
mensagens. Caso o ambiente de execuo destes servios no esteja preparado
para tal demanda, pode comear a haver latncia de processamento e degradao
do tempo de resposta das operaes (ERL, 2005).

Como a arquitetura orientada a servios pode ser composta de diversas camadas,

com necessidade de processamento nas interaes entre elas, esperado um
aumento nos requisitos de desempenho. Alm, disso o processamento e transporte
de dados nos formatos e protocolos da tecnologia Web Services, como XML, XSD e
SOAP, tende a ser custoso para a infra-estrutura. Ao adotar a orientao a servios,
as organizaes devem atentar para tais requisitos de desempenho no momento de
dimensionar a infra-estrutura necessria para seu ambiente.

2.4.7 Requisitos de segurana

Em um ambiente de servios autnomos disponveis para quaisquer potenciais

consumidores, surge a preocupao com a segurana das operaes dos servios.
Alguns tipos de operaes mais crticas necessitam meios de garantir que apenas
consumidores autorizados possam utiliz-las. Alm disso, como a comunicao
 46

entre provedores e consumidores de servios baseada em mensagens, preciso

assegurar a integridade e confidencialidade de certos tipos de informao (ERL,
2005).

Deste modo, necessrio que a infra-estrutura e as ferramentas utilizadas na

implantao de uma arquitetura SOA possuam suporte a mecanismos e tecnologias
que atendam a tais requisitos de segurana para servios. O padro WS-Security
busca solucionar esses requisitos em um ambiente de Web Services.

2.4.8 Complexidade de anlise e projeto

O desenvolvimento de solues compostas por diversos servios independentes e

desacoplados traz um aumento na complexidade da arquitetura e introduz um
nmero maior de pontos de falha (BIEBERSTEIN et al., 2005).

Alm disto, preciso assegurar que os servios desenvolvidos possuam

caractersticas aderentes aos princpios de orientao a servios. Sem essas
caractersticas, pode-se acabar com uma arquitetura de servios que no trazem os
benefcios esperados, como reuso, facilidade de integrao e alinhamento com o
negcio.

Segundo Papazoglou e Van Den Heuvel (2006), os paradigmas de desenvolvimento

existentes, como a orientao a objetos e o desenvolvimento baseado em
componentes, no so diretamente aplicveis a arquiteturas orientadas a servios e
baseadas em tecnologia Web Services. Deste modo, fazem-se necessrios tcnicas
e mtodos especficos para anlise e projeto de solues orientadas a servios.

2.4.9 Necessidade de governana

Com a existncia de um portflio de servios disponveis para toda a organizao,

pode haver diversas equipes de projeto desenvolvendo e utilizando servios deste
portflio ao mesmo tempo. Um servio deixa de ser responsabilidade de uma nica
equipe de projeto e deixa tambm de pertencer a um nico processo de negcio.
 47

O paradigma de orientao a servios exige que seja definida uma estrutura de

governana na organizao, de modo a estabelecer papis, responsabilidades,
processos para organizar os servios desenvolvidos (ERL, 2007). A governana
define mecanismos para desenvolver, manter e divulgar os servios do portflio e
garantir a padronizao da arquitetura.

2.5 Relao com outros paradigmas

O paradigma de orientao a servios no significa uma ruptura com relao a

outros paradigmas de desenvolvimento de software, pois representa uma evoluo
derivada da orientao a objetos e do desenvolvimento baseado em componentes e
pode inclusive ser aplicado juntamente com eles. A seguir, descrita a relao da
orientao a servios com esses outros paradigmas e suas diferenas.

2.5.1 Orientao a objetos

Conforme citado anteriormente, o paradigma de orientao a servios tem como

ponto em comum com o paradigma de orientao a objetos o fato de ambas serem
maneiras de se construir software com base na separao de assuntos (ERL, 2005).
Princpios como abstrao, encapsulamento e composio de servios foram
formulados a partir de conceitos de orientao a objetos. Alm disso, orientao a
objetos comumente utilizada para implementar a lgica de aplicao encapsulada
em um servio. Entretanto, os dois paradigmas possuem algumas diferenas que
sero discutidas a seguir.

A orientao a servios prega o baixo acoplamento entre suas unidades (os

servios). Apesar de objetos possurem rotinas desacopladas e at reusveis, as
classes por definio possuem relacionamentos entre si (agregao, herana), o que
gera certo grau de dependncia entre os objetos.

Na orientao a servios, muito das informaes necessrias para o processamento

est contido nas mensagens, de forma que os servios guardem o mnimo possvel
de informao de estado. A orientao a servios encoraja a amarrao da lgica de
 48

processamento com dados, mantendo mais informao contida nos objetos e

criando uma dependncia de estado.

2.5.2 Orientao a componentes

Apesar de serem relacionados, os conceitos de componente e de servio guardam

diferenas entre si e no devem ser confundidos. Alguns princpios da orientao a
servio, como a abstrao de interface e implementao e a transparncia de
localizao, so oriundos de boas prticas da orientao a componentes. Porm, o
servio difere dos componentes ao no se limitar a uma determinada plataforma,
linguagem ou tecnologia de implementao.

Algumas fontes afirmam que servios podem ser implementados utilizando-se

componentes (ENDREI et al., 2005), o que pode levar falsa idia de que
componentes e servios podem ser mapeados de um para um. Existem dois pontos
a serem considerados que desfazem esse tipo de concluso.

O primeiro a granularidade de componentes e servios. As funes oferecidas por

componentes em geral possuem granularidade baixa, no possuindo valor direto
para os processos de negcio (MARKS; BELL, 2006). Servios devem possuir
granularidade um pouco mais alta, pois representam atividades de negcio e provm
funes de utilidade direta para o negcio. Portanto, a implementao de um servio
geralmente construda pela composio de mais de um componente de baixa
granularidade, resultando em algo de granularidade um pouco mais alta.

O segundo o fato de, apesar de possurem interface e implementao separados

assim como os componentes, os servios operam sob um tipo de contrato que
estabelece um acordo e cria expectativas com base em suas caractersticas
semnticas. Tais caractersticas, pelo fato de serem complexas e de natureza
humana, no podem ser representadas por um simples conjunto de assinaturas de
funes, como as descries de interface de arcabouos de componentes atuais
(PERREY; LYCETT, 2003). Mesmo a tecnologia de Web Services, que
frequentemente empregada na implementao de SOA, ainda no oferece uma
maneira consolidada de representar estas caractersticas semnticas.
 49

2.6 Consideraes Finais

Neste Captulo 2, foi apresentado o conceito de SOA e foram discutidas algumas de

suas definies e caractersticas. Tais definies e caractersticas devero ser
mantidos em mente para se poder avaliar mtodos de anlise e projeto orientados a
servios e propor melhorias de um novo mtodo.

O paradigma de orientao a servios tende a ser cada vez mais adotado pelas
organizaes, tendo em vista benefcios que se espera que ele traga. Porm, esta
transio impe alguns desafios a serem considerados. Um novo mtodo de anlise
e projeto orientado a servios deve buscar resolver de modo direto a complexidade
de anlise e projeto, e indiretamente tratar requisitos de desempenho, segurana e
governana.

Na elaborao deste mtodo, especialmente importante focar nos princpios de

orientao a servios e em conceitos como granularidade e camadas de servios.
So estes os conceitos-chave que definem as caractersticas desejadas nos
servios desenvolvidos como resultado da aplicao do mtodo.
 50

3 MTODOS DE ANLISE E PROJETO ORIENTADOS A SERVIOS

Como discutido no captulo anterior, a orientao a servios possui uma srie de

caractersticas e princpios peculiares e pode trazer benefcios que motivam sua
adoo dentro das organizaes. Mas para que as promessas de benefcios da
orientao a servios se tornem realidade fundamental que seus elementos
principais os servios apresentem as caractersticas adequadas e sigam os
princpios do paradigma.

Deste modo, um grande desafio implementao de SOA estabelecer um mtodo

para desenvolver os servios que satisfazem as metas do negcio e agregam valor
a ele. necessrio garantir que os servios desenvolvidos na organizao sejam
eficientes e eficazes. Devem ser eficientes no sentido de ser bem projetados e
operar de acordo com os requisitos funcionais, de desempenho e de qualidade. E
tambm devem ser eficazes, atendendo s necessidades crticas para o negcio.

necessrio que a concepo do servio as atividades de anlise e projeto seja

realizada de forma que o produto final seja uma especificao de servio que
possua caractersticas como reusabilidade, baixo acoplamento e granularidade
adequada, alm de oferecer valor direto para o negcio.

A seguir, so descritos alguns mtodos de anlise e projeto orientados a servios

presentes na literatura. A descrio de cada mtodo contm a seguinte estrutura:

Ciclo de Vida: Os mtodos de anlise e projeto analisados fazem parte de um

ciclo de vida completo de desenvolvimento de software, que vai desde a
concepo at a execuo dos servios. Esta seo descreve como as
atividades de anlise e projeto posicionam-se no contexto do ciclo de vida
completo.
Atividades de Anlise: Descreve as atividades da fase de anlise propostas
pelo mtodo.
Atividades de Projeto: Descreve as atividades da fase de projeto propostas
pelo mtodo.
Papis: Descreve os papis, ou seja, os perfis responsveis por executar as
atividades do mtodo.
 51

Artefatos: Descreve os produtos de trabalho gerados, modificados ou

utilizados durante as atividades do mtodo.
Anlise do Mtodo: Anlise crtica do mtodo destacando as boas prticas
propostas e eventuais limitaes.

3.1 Papazoglou e Van Den Heuvel

Os autores Papazoglou e Van Den Heuvel (2006) argumentam que uma arquitetura
SOA consiste de sistemas em mltiplas camadas, com diversas tecnologias de
implementao, o que resulta em um grande leque de requisitos de negcio e de
desempenho, assim como em diferentes contextos de execuo e reuso. Para
realizar a especificao, construo e refinamento de processos de negcio a partir
de servios, necessrio um processo de desenvolvimento baseado em servios.

Em artigo publicado, os autores descrevem o processo Ciclo de Vida de

Desenvolvimento de Web Services, que parcialmente baseado em outros
processos j estabelecidos como o RUP, o desenvolvimento baseado em
componentes e a Modelagem de Processos de Negcio.

Para Papazoglou e Van Den Heuvel (2006), um mtodo de desenvolvimento

orientado a servios deve focar-se nos processos de negcio, que so os elementos
reusveis totalmente independentes de aplicaes e plataformas. Para que os
processos de negcio desenvolvidos a partir da base de servios criados e
existentes sejam realmente teis e confiveis, dois princpios devem ser levados em
conta durante todo o ciclo: baixo acoplamento e alta coeso entre os servios.

3.1.1 Ciclo de Vida

O mtodo de anlise e projeto apresentado faz parte de um processo cclico,

executado em iteraes. Essa abordagem cclica apregoa um processo contnuo de
descoberta, criao e implementao com cada iterao incorporando mais aos
artefatos da soluo, de modo previsvel e repetvel. O processo composto por
uma fase preparatria e mais oito fases principais distintas, conforme a Figura 3.1.
 52

Figura 3.1: Fases do mtodo (PAPAZOGLOU; VAN DEN HEUVEL, 2006)

A fase preparatria, a de Planejamento, consiste na preparao do projeto da

soluo. Nesta etapa, determinada a viabilidade, a natureza e o escopo da
soluo. Deve-se estabelecer uma clara compreenso sobre o ambiente de negcio
em questo e inserir os controles necessrios ao projeto. Algumas atividades desta
fase seriam: anlise das metas de negcio, anlise do ambiente tecnolgico,
concepo em alto nvel dos novos requisitos e o mapeamento destes requisitos
para as alternativas de implementao. A fase de planejamento inclui tambm
atividades gerenciais como anlise de custos, anlise de retorno de investimento e
elaborao do plano de projeto, com tarefas, entregveis e prazos.

O ciclo inicia-se na fase de Anlise, durante a qual so definidos os requisitos da

aplicao, que devem ser derivados das metas de negcio que direcionam o
desenvolvimento dos processos de negcio. Nesta fase, deve ser identificado o
modelo as-is dos processos, que sofrer reengenharia, resultando no modelo to-be.
feita ento uma anlise de gap, para determinar quais dos servios necessrios j
existem no portflio e quais devem ser desenvolvidos. Finalmente, a anlise de
realizao define qual ser a estratgia de implementao dos novos servios.

Em seguida vem a fase de Projeto, quando os processos e servios conceituais

definidos na Anlise so transformados em especificaes de interfaces
 53

independentes de plataforma. Nesta fase, duas atividades paralelas ocorrem: a

produo dos servios reusveis e a composio destes em processos. O projeto de
aplicaes orientadas a servios exige que as interfaces sejam muito bem definidas
e documentadas antes de serem implementadas. Alm disso, deve-se garantir que
os servios projetados possuam as caractersticas adequadas de granularidade,
reusabilidade e facilidade de composio.

Na fase de Construo, desenvolvida a implementao dos servios e a

descrio de suas interfaces e implementaes. Estes servios podem ser
implementados atravs da criao de novos servios a partir do zero, da exposio
de aplicaes existentes ou da composio de servios existentes reusveis. Nesta
fase, so seguidos os cenrios de desenvolvimento definidos durante a Anlise.

A fase seguinte, a de Teste, tem o intuito de validar se os requisitos foram satisfeitos

e se os artefatos entregues esto de acordo com o que foi definido nas fases de
Anlise e Projeto. So realizados testes funcionais, de desempenho, de interface e
de composio.

A fase de Proviso trata dos aspectos organizacionais dos servios, tanto dentro de
uma organizao como nas relaes entre mais de uma. Em caso de servios que
gerem receita, devem ser realizadas atividades para medio de seu uso e a devida
cobrana. So consideradas tambm questes de governana, certificao de
servios e alinhamento estratgico.

Na Implantao, os novos processos so publicados e expostos para todos os

participantes, incluindo organizaes, aplicaes e outros processos. Nesta fase a
interface e a implementao dos servios so publicadas nos repositrios.

A Execuo corresponde fase em que os servios e processos esto em

operao.

Por fim, na fase de Monitorao, medido o nvel de servio dos processos, com o
intuito de garantir qualidade na execuo. Mtricas e Key Performance Indicators
(KPI) so aferidos para determinar e reportar o desempenho dos processos e
detectar pontos em que pode haver melhora. Trata-se de um processo contnuo de
verificao do atendimento das metas de negcio definidas na Anlise. Os dados
obtidos serviro como entrada para uma nova iterao do ciclo de vida, iniciando um
novo projeto.
 54

O mtodo descrito consiste das fases de Anlise e Projeto do ciclo de vida proposto
por Papazoglou e Van Den Heuvel.

3.1.2 Atividades de Anlise

O objetivo da fase de Anlise a definio dos requisitos das novas aplicaes,

incluindo a definio dos processos de negcio envolvidos e seus respectivos
escopos. Para isto, a fase de anlise abrange quatro atividades principais:
identificao de processo, escopo de processo, anlise de gap e anlise de
realizao.

3.1.2.1 Identificao de processos

Nesta atividade estabelecida a compreenso de como a organizao funciona em

termos de processos de negcio e quais os servios demandados por estes
processos.

A partir da anlise da funcionalidade de aplicaes, elaborado um modelo as-is

dos processos de negcio em questo. Em seguida, este modelo analisado para
se determinar quais alteraes podem ser realizadas e quais funes (servios)
podem ser agregadas ao processo. Esta etapa de remodelagem dos processos
pode ser repetida diversas vezes, com vrios candidatos a modelos to-be de
processo sendo gerados e analisados at se chegar a um modelo to-be definitivo,
conforme a Figura 3.2. Este modelo to-be consiste nos processos remodelados com
possveis melhorias e a agregao de novos servios ou servios modificados.
 55

Figura 3.2: Identificao de processo e escopo de processo (PAPAZOGLOU, 2006)

Nesta anlise, pode-se comparar o portflio atual de processos de negcio com

definies padro de processos para a proposio de candidatos a modelo to-be.

3.1.2.2 Escopo de processos

Conforme pode ser visto na Figura 3.2, o Escopo de Processos no se trata de uma
atividade separada da Identificao de Processos, mas uma parte da etapa de
elaborao do modelo as-is. Esta atividade representa um controle que deve existir
para que os processos de negcio identificados no se tornem abrangentes demais,
realizando o papel de uma aplicao inteira.

Deve-se procurar identificar sub-processos que possam ser desacoplados e com

pouca coeso com o processo principal e especific-los como processos separados.
Assim, obtm-se controle sobre o escopo dos processos. Escopo de um processo
de negcio inclui a definio de onde o processo comea e termina, dos usurios do
processo, de suas entradas e sadas, das entidades externas que interagem com o
processo e dos eventos envolvidos.
 56

3.1.2.3 Anlise de gap

Nesta atividade, feita uma comparao entre os candidatos a servios descritos no

modelo to-be e o portflio atual de servios e funes contidas nas aplicaes da
organizao. O resultado da anlise de gap uma recomendao de quais servios
devem ser desenvolvidos, quais podem ser reusados e quais podem ser consumidos
de um provedor externo.

3.1.2.4 Anlise de realizao

Na anlise de realizao, define-se qual abordagem ser adotada para a

implementao dos servios demandados pelo novo modelo de processos de
negcio proposto. Cada cenrio de realizao de processos de negcio avaliado
em termos de custos, riscos, benefcios e retorno de investimento de acordo com os
requisitos de negcio. Os cenrios considerados so os seguintes: green-field, top-
down, bottom-up e meet-in-the-middle.

Green-field: Neste tipo de realizao, novas interfaces de servios so

especificadas a partir de uma nova implementao de servio.
Top-down: No desenvolvimento top-down, uma nova implementao de
servio criada a partir de uma interface existente de servio. Uma vantagem
do top-down a consistncia entre os processos, os servios e a integrao
de aplicaes. Esta alternativa, entretanto, tem um alto custo de
desenvolvimento e estabelecimento de uma arquitetura organizacional.
Bottom-up: Nesta opo, novas interfaces de servio so criadas a partir de
aplicaes j existentes. Sistemas legados e aplicaes corporativas so
expostos na forma de servios, por exemplo, criando-se interfaces Web
Services a partir de suas Application Programming Interfaces (APIs). Esta
alternativa recomendada em ambientes heterogneos com diversas
tecnologias.
Meet-in-the-middle: Esta opo utilizada quando uma interface de servio
existente mapeada parcialmente para uma implementao que tambm j
existe. Esta abordagem pode envolver a criao de um encapsulamento de
 57

servio para uma aplicao existente ou a combinao com interfaces de

servios. O meet-in-the-middle procura unir os benefcios dos outros cenrios,
reduzindo seus riscos.

A escolha entre estas abordagens depender das estimativas de custos de

implementao, de integrao e de ajustes para cada uma delas. Devem ser
desenvolvidas mtricas para avaliar a flexibilidade, facilidade de manuteno,
capacidade de extenso, acoplamento e coeso das abordagens e poder tomar a
deciso por uma delas.

3.1.3 Atividades de Projeto

Aps a fase de Anlise vem a fase de Projeto, durante a qual os processos e

servios conceituais so transformados em um conjunto de especificaes de
interfaces independentes de plataforma. Em um mtodo de desenvolvimento
orientado a servios necessrio que as interfaces sejam muito bem definidas e
documentadas antes da implementao (PAPAZOGLOU; VAN DEN HEUVEL,
2006).

A fase de Projeto composta por duas frentes de desenvolvimento: uma dedicada a

produzir os servios (novas implementaes ou componentes pr-existentes) e outra
dedicada a compor novos servios a partir de um portflio de servios reusveis.

O Projeto orientado a servios deve especificar servios levando em conta os

seguintes aspectos: granularidade, reuso e composio.

3.1.3.1 Especificao de Servios

Uma especificao de servio consiste de trs elementos: estrutura, comportamento

e poltica.

Especificao estrutural: composta por informaes de tipos de dados

envolvidos em um servio, mensagens e operaes.
 58

Especificao de comportamento: Define os efeitos esperados e colaterais da

execuo das operaes de um servio, sejam estes efeitos de carter
tcnico ou semntico.
Especificao de poltica: Consiste nas regras e restries do servio, como
segurana e gerenciamento.

Esta atividade foca em especificar as interfaces identificadas na fase de Anlise,

seguindo os princpios de acoplamento e coeso e os aspectos discutidos
anteriormente. Para tal, a interface de um determinado servio deve somente conter
operaes logicamente relacionadas entre si, para que exista coeso. Alm disso,
as mensagens de uma mesma interface devem possuir coeso de representao
(por exemplo, utilizando os mesmos tipos de dados de esquema XML) e coeso de
comunicao (por exemplo, utilizando os mesmos protocolos, como SOAP e HTTP).
Deve-se procurar minimizar o acoplamento entre diferentes servios, eliminando
interdependncias.

Como os autores descrevem o Projeto baseado na tecnologia Web Services, a

especificao estrutural e de comportamento realizada desenvolvendo interfaces
WSDL. Estes dois aspectos da especificao podem ser devidamente representados
nos tipos de portas, operaes, mensagens e tipos de dados de um WSDL. Assim,
para se produzir um servio, definem-se as operaes que ele prover e, em
seguida, os parmetros destas operaes (mensagens). Por fim, tambm devem ser
definidos no WSDL os protocolos de comunicao utilizados para disponibilizar o
servio.

J a especificao das polticas de um servio leva em conta requisitos no-

funcionais, como segurana, qualidade de servio (desempenho, escalabilidade,
disponibilidade), transaes ou gerenciamento de mudanas (notificaes). Por
exemplo, um servio pode exigir que seus potenciais consumidores utilizem tokens
de segurana, assinaturas digitais ou criptografia de acordo com os padres WS-
Security para invocar suas operaes. Estas informaes devem ser devidamente
documentadas na descrio do servio.
 59

3.1.3.2 Especificao de Processos

A outra atividade de projeto o detalhamento dos processos de negcio

identificados e delimitados durante a Anlise. Deve-se definir a estrutura do
processo, associar os papis envolvidos e especificar seus requisitos no-
funcionais. Para a especificao da estrutura, deve-se escolher entre as abordagens
de orquestrao e coreografia de servios. Devido ao fato de as tecnologias de
orquestrao estarem mais maduras e difundidas quando da publicao do artigo de
Papazoglou e Van Den Heuvel (2006), os autores optaram por utilizar a linguagem
de orquestrao WS-BPEL para especificar a estrutura dos processos de negcio.

A especificao da estrutura de um processo de negcio consiste na definio das

atividades que o compem e das relaes entre elas. Deve-se identificar e descrever
cada uma das atividades para ento decidir como cada uma delas ser
implementada e quais sero executadas por servios. A partir da, so descritas as
dependncias e condies das atividades. Por fim, todas estas informaes so
representadas de maneira formal por meio de uma definio em linguagem WS-
BPEL, que descreve o fluxo das atividades e as mapeia para os servios.

No segundo passo, so identificadas as responsabilidades associadas a cada

atividade e os papis atribudos a cada uma delas so descritos. Cada atividade
deve ser desempenhada por uma entidade (pessoa ou servio) que faa parte de
um papel especfico e que tenha as responsabilidades necessrias. A definio
destes papis poder servir de base tambm para a descrio das polticas, como
de controle de acesso e autorizao.

Por fim, para a especificao de requisitos no-funcionais, os autores recomendam

a elaborao de Service Level Agreements (SLA). SLAs so acordos de nvel de
servio que estabelecem quais so as responsabilidades e expectativas do provedor
e do consumidor de servios em relao um ao outro. Podem abordar questes de
segurana, desempenho e disponibilidade, bem como estipular penalidades e planos
de contingncia caso uma das partes falhe em atender o acordo.
 60

3.1.4 Papis

O processo Ciclo de Vida de Desenvolvimento de Web Services no identifica os

papis associados a cada fase.

3.1.5 Artefatos

Os artefatos produzidos so os modelos de processo as-is e to-be, que representam

respectivamente o estado atual do negcio e a soluo proposta com servios
automatizando tarefas do processo.

A fase de Projeto produz como artefatos as interfaces de servio em WSDL, os

esquemas de dados em XSD, a orquestrao do processo em WS-BPEL e as
especificaes de SLA.

3.1.6 Anlise do Mtodo

O mtodo proposto por Papazoglou e Van Den Heuvel (2006) mostra-se bastante
voltado para a aplicao de SOA junto da abordagem Business Process
Management (BPM) (JESTON; NELIS, 2008), uma vez que toda a definio da
soluo baseia-se nas atividades de modelagem de processos as-is e to-be. No
entanto, os autores no separam a anlise de processo de negcio da anlise
orientada a servios, sendo que a definio dos servios que fazem parte da soluo
ocorre durante a definio do modelo de processo to-be. Como resultado, obtm-se
processos de negcio modelados em um nvel menor de granularidade, uma vez
que atividades dos processos devem ser mapeadas diretamente para operaes de
servios. Conseqentemente, nas atividades de modelagem so utilizados tanto
conhecimentos de anlise de processo de negcio quanto conhecimentos de
orientao a servios, devendo ser executadas por pessoas com este perfil.

Uma caracterstica interessante do mtodo a existncia de uma atividade inteira

(Anlise de Gap) dedicada a avaliar os recursos j existentes na organizao e
detectar oportunidades de reuso. Estas oportunidades, por sua vez, so
 61

consideradas na Anlise de Realizao, quando so avaliadas alternativas de

realizao de servios do tipo top-down, bottom-up e meet-in-the-middle. A Anlise
de Gap e a Anlise de Realizao orientam de forma bastante clara o procedimento
de identificao de oportunidades de reuso e de tomada de decises de realizao.

Durante as atividades de especificao de servios e de processo, os autores

utilizam padres relacionados tecnologia Web Services, pois recomendam que a
estrutura dos servios seja representada nas linguagens XSD e WSDL.

Alm de projetar a estrutura e os requisitos funcionais dos servios, o mtodo

tambm aborda a definio de requisitos no-funcionais, ao serem elaboradas
polticas de servios e acordos de SLA.

Ainda na etapa de Projeto, ocorre uma validao dos servios especificados,

avaliando se as caractersticas dos servios esto em aderncia aos princpios de
SOA coeso e baixo acoplamento.

Na atividade de especificao de processos, o mtodo mostra-se novamente

orientado abordagem BPM, pois utiliza a tcnica de orquestrao de servios e a
linguagem WS-BPEL para representar a lgica de um processo de negcio e sua
interao com os servios.

3.2 RUP plugin for SOMA

O Rational Unified Process (RUP) um processo de Engenharia de Software

desenvolvido e comercializado pela IBM. Trata-se de um mtodo de gerenciamento
de atividades e papis em uma organizao de desenvolvimento de software. O
RUP tem como objetivo principal disciplinar o desenvolvimento de modo a entregar
software de qualidade que atenda aos requisitos do cliente dentro do prazo e
oramento previstos (GORNIK, 2003).

O RUP constitui uma maneira de se implementar uma srie de boas prticas de

projeto de software em uma organizao. Essas boas prticas so resultado de
experincia de muitos projetos de software que serviram de base para a criao do
arcabouo formado pelo RUP (KRUTCHEN, 2000). Entre as boas prticas utilizadas
no RUP, esto o desenvolvimento iterativo de software, o gerenciamento de
 62

requisitos, a arquitetura baseada em componentes, o uso da Unified Modeling

Language (UML) (RUMBAUGH; JACOBSON; BOOCH, 2004), a garantia da
qualidade e o gerenciamento de mudanas.

O RUP no para ser utilizado de maneira literal, pois se trata de um arcabouo a

partir do qual a organizao poder construir seu prprio processo de
desenvolvimento de modo que realmente atenda s suas particularidades de
domnio e cultura. Para a construo deste processo personalizado, a IBM
disponibiliza a ferramenta Rational Method Composer (IBM, 2007).

Outro aspecto relevante alta dependncia do RUP em relao ao uso de

ferramentas para automao e controle do processo. A prpria personalizao do
processo e sua publicao podem ser realizadas por meio de uma ferramenta
especfica, assim como a gerao de artefatos UML, o controle de verso de
documentos e cdigos-fonte e o desenvolvimento em si.

Para a utilizao do RUP em projetos de SOA, a IBM disponibiliza um plugin, o RUP

plugin for Service-Oriented Modeling and Architecture (SOMA) (ZIMMERMANN,
2005) que contm atividades, papis e artefatos relacionados ao desenvolvimento
orientado a servios. Estes elementos devem ser incorporados ao processo
personalizado da organizao que pretende utilizar o RUP para projetos de solues
orientadas a servios.

3.2.1 Ciclo de Vida

O modelo do RUP pode ser descrito em duas dimenses, o contedo do mtodo e o

processo. O contedo do mtodo consiste nas disciplinas, compostas por atividades,
papis e artefatos. J o processo representa o fluxo de trabalho ao longo do tempo,
com suas fases e iteraes (SHUJA, KREBS, 2007). Esta estrutura pode ser
visualizada na Figura 3.3.
 63

Figura 3.3: Arquitetura do Rational Unified Process (SHUJA, KREBS, 2007)

De acordo com o RUP, o ciclo de vida de desenvolvimento de software dividido em

fases, sendo que ao final de cada uma delas, desenvolvida uma nova gerao do
produto. Entre uma fase e outra, definido um milestone, que representa um
instante de tempo no qual as decises devem ter sido tomadas e os objetivos
atingidos. As quatro fases do RUP so: Iniciao, Elaborao, Construo e
Transio.

A Iniciao tem como objetivo acordar entre todas as partes interessadas os

objetivos do projeto. Nesta fase determinado o escopo do projeto,
realizada uma descrio do ambiente e de um esboo da arquitetura
candidata do produto. Tambm so feitas estimativas de custo e prazo do
projeto alm dos riscos, isto , as fontes de imprevisibilidade. Como
resultados desta fase, temos um documento de viso, uma prvia dos casos
de uso, uma avaliao inicial dos riscos do projeto e um plano de projeto.
A Elaborao tem como objetivo analisar o domnio do problema e propor
uma arquitetura. A viso elaborada e so definidos o processo, a infra-
estrutura e o ambiente de desenvolvimento. A arquitetura do software
elaborada de modo a suportar a viso definida anteriormente. Os resultados
 64

desta fase so: o modelo de casos de uso, os requisitos no-funcionais

complementares, um plano detalhado do projeto e um prottipo executvel da
arquitetura.
Na Construo, os componentes da aplicao so desenvolvidos e integrados
e todas as funes so testadas de maneira detalhada. nesta fase que os
requisitos de qualidade da aplicao devem ser atingidos e verificados. Ao
final da Construo, temos como resultado um produto de software
devidamente integrado e pronto para ser entregue, alm da documentao
voltada para os usurios.
A Transio tem o propsito de disponibilizar o produto de software para seus
clientes. As atividades desta fase incluem treinamento dos usurios, tarefas
de implantao em ambiente de produo e distribuio da aplicao
desenvolvida e avaliao para verificar a aceitao do produto em relao
viso especificada.

No RUP, a definio do processo de desenvolvimento estabelece quem faz o qu,

quando e como, por meio de papis, atividades e artefatos. Entretanto, um processo
no constitudo por uma simples enumerao de papis, atividades e artefatos. O
processo constitudo por um conjunto de disciplinas, em que cada uma representa
uma seqncia de atividades que produz algum tipo de valor e mostra as interaes
entre os papis. Pode-se descrever uma disciplina como um fluxo de trabalho, com
vrios papis executando atividades, que possuem relaes de dependncia entre
si. O RUP define nove disciplinas, que so descritas a seguir: Modelagem de
Negcio, Requisitos, Anlise e Projeto, Implementao, Teste, Implantao,
Gerenciamento de Projetos, Gerenciamento de Configurao e Mudanas e
Ambiente.

A Modelagem de Negcio tem como objetivo modelar a estrutura e a

dinmica da organizao onde ser implantada a aplicao. Esta disciplina
visa estabelecer um entendimento comum entre clientes, usurios e
desenvolvedores acerca do problema a ser solucionado, eliminando eventuais
gaps entre a linguagem de negcio e a linguagem de engenharia de software.
Para isto, o RUP faz uso dos chamados casos de uso de negcio para
representar os processos que sero suportados pela soluo.
 65

O propsito da disciplina de Requisitos estabelecer um acordo entre

desenvolvedores e clientes sobre exatamente o que o sistema dever fazer,
isto , o escopo da soluo. As necessidades dos clientes so levantadas e
documentadas com detalhes, servindo de base para a elaborao de uma
proposta de soluo. Os resultados obtidos so descritos na forma de casos
de uso e no chamado documento de viso. O modelo de casos de uso
elaborado aqui orientar todo o ciclo de desenvolvimento, passando por
levantamento de requisitos, anlise, projeto e testes.
A disciplina de Anlise e Projeto visa, a partir dos requisitos, projetar a
soluo de software, de modo que ela atenda a todos os requisitos
especificados pelos casos de uso. Esta disciplina produz um modelo de
projeto, que representa a arquitetura do software a ser desenvolvido. Tal
modelo especifica subsistemas, componentes, classes, suas interfaces e
como todos eles se relacionam para realizar os casos de uso. uma
representao de como o cdigo-fonte ser estruturado e escrito.
Na Implementao, definida a organizao do cdigo, em termos de
subsistemas e camadas de abstrao. Esta disciplina envolve tambm toda a
implementao de classes e componentes, testes unitrios destes
componentes e sua integrao constituindo um sistema executvel.
A disciplina de Teste tem como objetivo verificar e validar a interao entre
objetos e a integrao entre os componentes do software. Os testes
realizados verificam se todos os requisitos foram implementados e atendidos
de forma adequada e identificam e detectam falhas a serem solucionadas
antes da implantao do software.
A disciplina de Implantao composta pelas atividades que visam
disponibilizar o software para seus usurios finais. Entre as atividades desta
disciplina esto: empacotamento, distribuio e instalao do software,
suporte e assistncia aos usurios, testes beta e migrao de dados e de
softwares existentes.
A disciplina de Gerenciamento de Projetos envolve a conduo do projeto,
equilibrando objetivos conflitantes, gerenciando riscos e planejando e
monitorando a execuo das atividades. No RUP, esta disciplina apresenta
 66

boas prticas e diretrizes para auxiliar a produo e entrega de software de

qualidade.
Na disciplina de Gerenciamento de Configurao e Mudanas, descrito
como controlar os diversos artefatos e itens de configurao produzidos pelas
vrias pessoas envolvidas num mesmo projeto. Esta disciplina contm
atividades para lidar com questes como atualizao simultnea de artefatos,
notificao de mudanas e correes e controle de mltiplas verses.
O propsito da disciplina de Ambiente fornecer organizao
desenvolvedora de software o ambiente de desenvolvimento, composto por
processos e ferramentas que apoiaro a equipe de projeto. Esta disciplina
envolve a configurao do processo de desenvolvimento para o contexto
especfico de um projeto.

O RUP plugin for SOMA (IBM, 2007) uma extenso ao contedo original do RUP
que traz modificaes ao ciclo de vida, alm de acrescentar novos conceitos, papis,
atividades e artefatos. A maior parte das adies trazidas pelo plugin aplicada s
primeiras fases (Iniciao e Elaborao) do ciclo e dizem respeito disciplina de
Anlise e Projeto. Trs macroatividades so adicionadas para tratar do
desenvolvimento orientado a servios: Identificao de Servios, Especificao de
Servios e Realizao de Servios. Cada macroatividade pode ser composta por
uma ou mais tarefas.

Para avaliar o RUP plugin for SOMA como mtodo de anlise e projeto, foram
consideradas as macroatividades adicionadas, mais os papis e artefatos
relacionados. Apesar de no haver no RUP uma separao explcita de atividades
de Anlise de atividades de Projeto, so descritas a primeira como Anlise e as duas
ltimas como Projeto, por analogia com outros mtodos.

3.2.2 Atividades de Anlise

A atividade de anlise do RUP adaptado pelo plugin a Identificao de Servios.

Ela tem como objetivo identificar e elaborar a especificao inicial dos servios
candidatos que comporo a soluo a ser desenvolvida.
 67

Dependendo do tipo de projeto e das informaes disponveis, podem-se utilizar

diferentes fontes para identificar os servios candidatos. Estas fontes no se
excluem mutuamente, podendo-se utilizar mais de uma delas em um mesmo projeto.
As fontes para identificao de servios so exibidas na Figura 3.4.

Figura 3.4: Abordagens de Identificao de Servios (IBM, 2007)

Os servios candidatos identificados so documentados no Modelo de Servios. A

seguir so descritas as tarefas correspondentes identificao de servios a partir
de cada tipo de fonte.

3.2.2.1 Anlise de Processo de Negcio

Nesta tarefa, servios so identificados a partir de modelos de processos de

negcio, representados por diagramas em notaes como a Business Process
Modeling Notation (BPMN). Em um modelo de processo, temos um fluxo de tarefas
que so desempenhadas por diferentes papis, como exemplificado na Figura 3.5.
Neste exemplo, cada raia do diagrama contm as tarefas desempenhadas por um
determinado papel.
 68

Figura 3.5: Exemplo de modelo de processo de negcio (IBM, 2007)

Neste caso, cada papel pode ser mapeado para um servio e as tarefas associadas
a este papel podem ser mapeadas para operaes pertencentes ao servio
correspondente. As tarefas em que se pode realizar este tipo de mapeamento so
as automatizadas e as que envolvem interao com algum sistema.

3.2.2.2 Anlise Caso de Uso de Negcio

Quando for utilizado um modelo de casos de uso para representar o negcio, os

casos de uso de negcio podem servir como insumo para a identificao de
servios. A partir de um determinado caso de uso, deve-se representar sua
descrio na forma de diagrama de seqncia de anlise de negcio, conforme
exemplificado na Figura 3.6.
 69

Figura 3.6: Mapeamento de casos de uso para servios (IBM, 2007)

Neste caso, pode-se mapear o ator Sistema de crdito do caso de uso para um
servio e as interaes executadas pelo ator podem ser mapeadas para chamadas
de operaes do servio.

3.2.2.3 Anlise de Modelo de Dados

Em muitas aplicaes, os dados so modelados como Entidades de Negcio

identificadas na Modelagem de Negcio. Assim, estas aplicaes demandaro
servios que manipulem e acessem os dados das Entidades. Os modelos de dados
existentes devero ser analisados e os dados agrupados de forma a constituir um
servio. Este tipo de servio chamado de Servio de Encapsulamento de Dados.

3.2.2.4 Anlise de Regras de Negcio

Nesta tarefa, identificam-se a partir de um modelo de negcio (processo ou caso de

uso) as regras de negcio que podem ser tornadas externas ao restante da soluo,
 70

sendo ento encapsuladas por servios. Geralmente, criam-se servios a partir de

regras de validao com potencial de reuso em diversos contextos.

3.2.2.5 Anlise de Recursos Existentes

Na maior parte das vezes, as solues orientadas a servios devero interagir com
alguma aplicao legada da organizao, reusando funes j existentes. Nesta
abordagem, devem-se identificar as funes legadas que sero necessrias
soluo sendo desenvolvida e disponibiliz-las na forma de servio. Isto pode ser
feito encapsulando a funo com um servio, por meio de adaptadores ou
integrando a funo a um servio, conforme exemplificado na Figura 3.7.

Figura 3.7: Disponibilizao de funes legadas como servios (IBM, 2007)

3.2.3 Atividades de Projeto

Na fase de Projeto, o RUP plugin for SOMA descreve duas macroatividades:

Especificao de Servios e Realizao de Servios.

A Especificao de Servios recebe como entrada o Modelo de Servios candidatos

identificados durante a Anlise e define as especificaes de interface dos servios.
composta pelas tarefas: Teste Litmus de Servio, Projeto de Mensagem e
Especificao de Servio.

J na Realizao de Servios, definido como os servios sero implementados,

passando pelas tarefas: Especificao de Componente e Decises de Realizao.
 71

O RUP plugin for SOMA no determina uma seqncia exata para a execuo
destas tarefas, uma vez que pode haver diversas iteraes de cada uma. Elas so
descritas a seguir na ordem em que aparecem no plugin.

3.2.3.1 Teste Litmus de Servio

Dos servios candidatos identificados e documentados no Modelo de Servios, nem

todos sero efetivamente realizados e expostos no portflio da organizao. Nesta
tarefa executado um Teste Litmus para verificar algumas caractersticas dos
servios candidatos, tais como reusabilidade, alinhamento com os requisitos de
negcio, possibilidade de composio e viabilidade tcnica. O teste realizado para
decidir se um servio candidato ser realmente exposto como um servio ou se
dever ser realizado como um componente no passvel de exposio.

3.2.3.2 Projeto de Mensagem

As mensagens so os dados recebidos e retornados pelas operaes do servio.

Nesta tarefa, devem-se especificar exatamente quais as informaes envolvidas na
execuo de uma operao e definir a relao dessas informaes com modelos de
dados existentes. Devem ser tomadas decises a respeito do mapeamento das
mensagens, seu formato e protocolo de comunicao.

As mensagens podem ser representadas por um modelo de classes ou esquemas

XSD.

3.2.3.3 Especificao de Servio

Cada servio dever ser descrito e especificado levando-se em conta os seguintes

aspectos: colaboraes, polticas, dependncias e composio.

As colaboraes de um servio so seus relacionamentos com outros servios,

possivelmente derivados do modelo de processo de negcio. Os servios so vistos
 72

assumindo um papel em uma determinada colaborao, sendo assim necessrio

especificar as responsabilidades associadas a este papel.

As polticas especificam os requisitos no-funcionais dos servios, como segurana

e QoS. Informaes sobre polticas podem afetar qualquer elemento do servio, seja
uma operao, mensagem ou a colaborao entre servios.

As dependncias do servio podem ser pr e ps-condies de processamento,

relacionamentos com outros servios, relacionamento entre o servio e seu provedor
ou o relacionamento com o canal que o conecta a outros servios.

Por fim, devem ser especificadas as caractersticas de composio do servio, caso

ele seja um servio composto, como um servio de orquestrao implementado em
WS-BPEL. Devem-se indicar quais servios so orquestrados e como so realizadas
as interaes.

Como resultado desta tarefa, obtm-se as especificaes de servio no documento

de Modelo de Servios.

3.2.3.4 Especificao de Componente

Nesta tarefa, so especificados os componentes fsicos que realizaro as

Especificaes de Servio. So especificadas a interface do componente de servio,
seus atributos e estrutura interna.

A interface do componente deve conter as assinaturas das operaes do servio,

sendo que os parmetros dessas operaes devem referenciar as mensagens
definidas anteriormente. As interfaces podem ser representadas por modelos de
classes ou documentos WSDL.

Atributos de um componente a serem descritos nesta tarefa so: propriedades,

dependncias de outros componentes, servios fornecidos pelo componente e
servios utilizados.

Por fim, deve-se modelar a estrutura interna do componente, descrevendo-se as

classes que o compem e os relacionamentos entre elas. Neste ponto, podem ser
aplicados padres de projeto para realizar o comportamento especificado para o
servio.
 73

3.2.3.5 Decises de Realizao

Quando se determinam os servios que devero ser expostos, deve-se determinar a

abordagem de realizao para cada um deles, decidindo por uma das opes a
seguir:

Construir internamente um novo componente de servio

Adquirir um servio que possa ser hospedado internamente
Transformar uma aplicao legada para expor um servio
Integrar uma aplicao legada, encapsulando-a em um servio
Terceirizar, consumindo um servio externo

Para a tomada desta deciso, so analisados recursos existentes que podem ser
reusados.

3.2.4 Papis

O RUP plugin for SOMA traz trs novos papis voltados para atividades
relacionadas ao desenvolvimento orientado a servios: o Arquiteto de Servios, o
Projetista de Servios e o Projetista de Dados de Servios.

O Arquiteto de Servios o responsvel por especificar a arquitetura da aplicao,

tendo como entrada modelos de processos de negcio, modelos de casos de uso,
modelos de dados e a partir da identificando elementos e mecanismos de projeto a
serem incorporados ao projeto. O Arquiteto de Servios tem como principal atividade
a Identificao de Servios candidatos a partir dos modelos mencionados acima,
resultando em um Modelo de Servios parcialmente especificados.

O Projetista de Servios o responsvel por refinar, revisar e detalhar os servios

candidatos descritos pelo Analista de Servios, na execuo das atividades de
Especificao de Servios e Realizao de Servios. O Projetista elabora ainda mais
o Modelo de Servios, especificando informaes sobre mensagens, colaboraes
entre servios e provedores. A partir da o Projetista de Servios pode tambm
especificar Componentes de Servio que implementaro as especificaes contidas
no Modelo de Servio.
 74

J o Projetista de Dados de Servios uma extenso ao papel Projetista de Dados

do RUP convencional, mas com a responsabilidade de tambm projetar bases de
dados a partir da especificao de Componentes de Servio.

3.2.5 Artefatos

Os novos artefatos introduzidos pelo RUP plugin for SOMA so o Modelo de

Servios e os Componentes de Servio.

O Modelo de Servios uma abstrao da especificao tecnolgica de Web

Services e utilizado para elaborar e documentar o projeto de servios em uma
aplicao SOA. Trata-se de um artefato composto que inclui informaes sobre
especificaes de servios, provedores destes servios, mensagens trocadas por
eles e colaboraes entre eles. Pode ser representado em linguagem UML.

O artefato Componente de Servio descreve a realizao de uma especificao de

servio. Trata-se da especificao do componente de software que implementar a
interface de um ou mais servios. Pode-se referir a um novo componente
desenvolvido, um Web Service, uma aplicao existente, uma fonte de dados ou at
uma composio de outros servios. O artefato Componente de Servio utilizado
como especificao por aqueles que iro implement-los.

3.2.6 Anlise do Mtodo

O mtodo caracterizado pelas atividades do RUP plugin for SOMA utiliza alguns
conceitos de BPM, pois permite que servios sejam identificados a partir de modelos
de processo de negcio, porm no aborda de maneira explcita atividades de
orquestrao de servios.

A Identificao de Servios considera o reuso de recursos existentes, pois possibilita

que servios sejam identificados a partir de aplicaes legadas, e oferece diversas
fontes de identificao. Na tarefa de Decises de Realizao, as aplicaes
existentes so novamente avaliadas para se definir como cada servio ser
realizado.
 75

Por estas caractersticas, o RUP plugin for SOMA pode ser classificado como uma
abordagem meet-in-the-middle, pois garante que os servios esto alinhados tanto
com os requisitos de negcio quanto com as restries do ambiente existente.

O mtodo utiliza o conceito de servio candidato, que serve de ponte da

Identificao para a Especificao de Servios.

O RUP plugin for SOMA prope o Teste Litmus de Servio para determinar quais
servios candidatos sero efetivamente realizados. No entanto, esta validao leva
mais em conta motivos prticos e econmicos para expor um servio, mas no
considera a adequao dele ao portflio da organizao e analisa somente a
aderncia dos servios candidatos aos princpios de reusabilidade e facilidade de
composio.

Na atividade de Especificao de Servios, requisitos no-funcionais so tratados na

definio de polticas de servio e na anlise de caractersticas de QoS.

O RUP plugin for SOMA integra-se ao ciclo tradicional de desenvolvimento,

utilizando na implementao tcnicas de desenvolvimento baseado em
componentes e orientao a objetos.

O RUP plugin for SOMA no um mtodo de uso livre. Sua utilizao est atrelada
aquisio de licenas de software da ferramenta Rational Method Composer da
IBM.

3.3 Erl

Thomas Erl um autor de publicaes sobre SOA e membro de organizaes de

padronizao nas reas de XML e Web Services. Em suas publicaes (ERL, 2005.
ERL, 2007), o autor descreve um mtodo para o desenvolvimento de uma
arquitetura SOA e seus servios.

Erl descreve o desenvolvimento de uma arquitetura SOA por meio de um ciclo de

vida de desenvolvimento de servios, focando principalmente nas atividades de
anlise e projeto, que so as etapas em que os servios so identificados e
especificados. O autor destaca o uso dos princpios de orientao a servios durante
estas atividades, para garantir que os servios desenvolvidos sejam efetivos dentro
 76

da arquitetura SOA. Em determinados pontos, tanto da anlise quanto do projeto, a

aderncia aos princpios de orientao a servios verificada.

O autor assume a utilizao da tecnologia Web Services na implementao dos

servios, fazendo uso de artefatos especficos como esquemas XSD e interfaces
WSDL na descrio das atividades de projeto. A verificao dos princpios de
orientao a servios tambm feita levando-se em conta os pontos de aderncia
da tecnologia Web Services aos princpios e os gaps.

3.3.1 Ciclo de Vida

Erl descreve o ciclo de vida de um projeto de solues orientadas a servios,

composto por uma srie de passos a serem seguidos para se construir servios que
compem uma soluo. De maneira geral, o processo para se desenvolver solues
, segundo Erl, bastante semelhante ao desenvolvimento de aplicaes distribudas.
Afinal, servios devem ser projetados, implementados e postos em execuo assim
como outros tipos de componentes convencionais e tecnologias de front-end e back-
end.

O ciclo de vida descrito pelo autor pode ser visualizado na Figura 3.8.

Figura 3.8: Ciclo de vida de desenvolvimento SOA (ERL, 2005)

A fase de Anlise Orientada a Servios o estgio inicial em que determinado o

escopo da arquitetura SOA em desenvolvimento. As camadas de servios
(orquestrao, negcio e aplicao) so mapeadas e servios preliminares so
modelados na forma de servios candidatos.
 77

Na fase seguinte, Projeto Orientado a Servios, os servios que faro parte da

arquitetura SOA j esto definidos, sendo necessrio ento determinar como eles
sero construdos. A atividade de projeto altamente baseada em padres e
influenciada pelos princpios de orientao a servios. Quatro diferentes estratgias
podem ser utilizadas para se projetar um servio: servios baseados em entidades,
servios de aplicao, servios baseados em tarefas e servios de processo.

A fase de Desenvolvimento de Servios o momento em que os servios so

efetivamente construdos. Nesta fase so considerados os aspectos tcnicos e
especificidades da tecnologia de implementao, como linguagens de programao,
ambiente de desenvolvimento e plataformas.

Pelo fato de poderem ser reusados e participar de composies de maneira no

previstas, os servios devem ser rigorosamente testados. Na fase de Teste de
Servios, deve ser verificada uma srie de requisitos dos servios, como aderncia
aos padres, comunicao com diversos tipos de consumidores, aspectos de QoS e
tratamento de excees e compensao.

A fase de Implantao de Servios trata de instalar e configurar os componentes

distribudos que implementam os servios, as interfaces de servios e produtos de
middleware associados em ambiente de produo. Deve-se definir a alocao fsica
de cada componente, avaliar a capacidade da infra-estrutura satisfazer aos
requisitos de desempenho esperados, estabelecer as configuraes de segurana e
verificar as integraes com sistemas e aplicaes.

Finalmente, a fase de Administrao de Servios acompanha a execuo dos

servios, monitorando seu uso e desempenho, realizando o controle de verso dos
artefatos relacionados e dando manuteno para que os servios operem de modo
satisfatrio.

3.3.2 Atividades de Anlise

As atividades de anlise no mtodo proposto por Erl correspondem fase de

Anlise Orientada a Servios do ciclo de vida. O objetivo principal desta fase
determinar quais os servios que devem ser construdos e o escopo de cada um
deles, ou seja, qual a lgica deve ser encapsulada por cada um.
 78

Os passos para a realizao da Anlise Orientada a Servios so exibidos na Figura

3.9 e so descritos a seguir.

Figura 3.9: Anlise Orientada a Servios (ERL, 2005)

3.3.2.1 Definio dos requisitos de negcio

Nesta atividade, os requisitos de negcio relacionados soluo orientada a

servios sendo construda so levantados e documentados. Esta documentao de
requisitos servir como ponto de partida para a Anlise Orientada a Servios.

Os requisitos de negcio devem estar definidos o suficiente para que um processo

de automao possa ser especificado e utilizado no desenvolvimento da soluo
SOA.

3.3.2.2 Identificao de sistemas existentes

O objetivo especfico desta atividade identificar se existe alguma lgica de

aplicao j existente que satisfaa total ou parcialmente a algum dos requisitos
levantados na atividade anterior. Neste momento ainda no necessrio concentrar-
 79

se em como os servios interagiro com as aplicaes legadas, mas apenas realizar

um levantamento de alto nvel para prever quais sistemas podem ser afetados.

Este tipo de informao ser til para a identificao dos servios candidatos na
etapa de modelagem.

3.3.2.3 Modelagem de servios candidatos

A atividade de Modelagem de Servios o principal passo da fase de Anlise

Orientada a Servios proposta por Erl. Nesta fase, so identificadas operaes
candidatas que devem ser agrupadas segundo seu contexto lgico, dando origem a
servios candidatos. Eventualmente, os servios candidatos podem ser combinados
em modelos de composio para formar a soluo orientada a servios.

A Modelagem de Servios compreende uma srie de sub-tarefas, apresentadas na

Figura 3.10.
 80

Figura 3.10: Modelagem de servios candidatos (ERL, 2005)

No primeiro passo, ocorre a decomposio do processo de negcio

documentado em uma srie de passos de baixa granularidade, sendo que
este nvel de granularidade obtido pode diferir do nvel original.
Em seguida, so identificadas as operaes candidatas dos servios de
negcio. Basicamente, os candidatos a operaes sero os passos do
processo identificados na etapa anterior, exceto aquelas atividades que so
tarefas humanas que no devero ser automatizadas e passos que j so
executados por aplicaes legadas que no podem ser encapsuladas por
servios.
Caso a arquitetura SOA em questo possua uma camada de orquestrao de
servios, ento se deve definir que partes da lgica de aplicao sero
abstradas pela lgica de orquestrao. Isto , deve-se definir qual a lgica
estar representada no processo ao invs de ser executada por um servio
de negcio. Regras de negcio, lgica condicional, lgica de exceo e lgica
 81

seqencial so alguns exemplos de lgica que podem ser abstrados pela

camada de orquestrao.
As operaes candidatas devem ento ser analisadas para se criar os
candidatos a servios de negcio. As operaes devero assim ser
agrupadas de acordo com o contexto lgico correspondente. Por exemplo,
servios baseados em tarefas seriam agrupamentos de acordo com processo
ou servios baseados em entidades seriam agrupamentos de operaes
segundo os relacionamentos entre entidades. Operaes podem ser
adicionadas aos servios para aumentar sua reusabilidade.
Definidos os servios candidatos, aplicam-se os princpios de orientao a
servios para garantir que eles realmente atendam aos requisitos de uma
arquitetura SOA. As operaes candidatas devem ter seus escopos e lgica
revisados para que sejam realmente reusveis e autnomas (sem
dependncias entre si).
Para se identificar composies de servios candidatos, devem ser
analisados diversos cenrios de execuo do processo de negcio. Destas
anlises, podem-se inferir possveis composies de servios e concluir se os
agrupamentos de operaes so adequados. Nos cenrios, devem ser
considerados os casos de falha ou exceo.
Baseados nos resultados do passo anterior, revisam-se os agrupamentos
de operaes candidatas em servios.
Por ltimo, opcionalmente, podem-se revisar os requisitos de
processamento dos servios candidatos. Tal reviso tem o propsito de
determinar qual a lgica necessria para executar as operaes candidatas e
se tal lgica j existe ou deve ser desenvolvida.

Para documentar os servios em seu mtodo de anlise de projeto, Erl prope uma
notao semelhante a uma notao de classe da UML, que exibe um servio com
suas operaes. Esta notao utilizada em diagramas que exibem composies
de servios. A notao utilizada por Erl pode ser vista na Figura 3.11.
 82

Figura 3.11: Notao para representar um servio (ERL, 2007)

3.3.2.4 Atividades de Projeto

O mtodo descrito por Erl tem suas atividades de projeto especificadas na fase de
Projeto Orientado a Servios do ciclo de vida. Os principais objetivos desta fase so
definir as interfaces dos servios candidatos modelados na Anlise, garantir a
adequao aos princpios de orientao a servios e definir quais padres sero
suportados e utilizados na implementao dos servios.

Como resultados, temos as especificaes dos servios nas camadas de negcio,

aplicao e orquestrao.

Os passos do Projeto Orientado a Servios podem ser visualizados na Figura 3.12 e

so descritos nas sees seguintes.
 83

Figura 3.12: Projeto orientado a servios (ERL, 2005)

3.3.2.5 Composio da arquitetura orientada a servios

Nesta primeira atividade, so determinadas quais camadas de servios sero

utilizadas na arquitetura sendo construda. Devem-se definir tambm os padres que
sero utilizados na especificao e implementao dos servios. Por exemplo, se for
utilizada a tecnologia Web Services, deve-se estabelecer quais especificaes de
XML e Web Services sero utilizadas e quais extenses (padres WS-*) sero
necessrios.
 84

3.3.2.6 Projeto de servios baseados em entidades

Servios de negcio baseados em entidades representam entidades de dados

definidas no modelo de negcio da organizao. Este tipo de servio
completamente independente de processo de negcio, podendo ser reusado por
qualquer soluo que necessite acessar dados relacionados a uma entidade
particular. Servios baseados em entidades fazem parte da camada de servios de
negcio.

A atividade de projeto de servios baseados em entidade tem como propsito

especificar as interfaces e a lgica encapsulada por cada um deles.

Para a especificao das interfaces, Erl prope o uso de documentos WSDL, que
podem ser utilizados posteriormente para implementao com Web Services. Os
esquemas de dados das entidades tratadas pelo servio so definidos e
representados na forma de esquemas XSD e comporo as mensagens trocadas
pelas operaes do servio.

Princpios de orientao a servios devem ser tambm aplicados aos servios.

Servios baseados em entidades so intrinsecamente autnomos pelo fato de cada
um ser responsvel por manipular uma entidade ou grupo de entidades especfico.
Tambm no preservam informao de estado, uma vez que possuem pouca lgica
de fluxo de trabalho encapsulada. Deve-se atentar para a reusabilidade do servio,
possivelmente adicionando operaes que podem ser teis em outros contextos
alm do considerado para uma soluo em particular.

3.3.2.7 Projeto de servios de aplicao

Os servios da camada de aplicao so a principal fora de trabalho da arquitetura

SOA, executando funes demandadas pelas camadas de orquestrao e de
servios de negcio. So abstraes orientadas a servio do ambiente tecnolgico
da organizao, no sendo por isso necessrio considerar aspectos de negcio em
seu projeto.
 85

A atividade de projeto de servios de aplicao inicia-se com a anlise das

operaes candidatas propostas, para verificar se possuem o nvel de granularidade
e reusabildade adequados. Devem ento ser definidos os dados de entrada e sada
para cada uma das operaes, possivelmente na forma de esquemas XSD.
Finalmente, a definio da interface WSDL deve ser completada com as operaes
correspondentes.

Como servios de aplicao devem poder ser utilizados por diversos tipos de
servios de negcio, os dados de entrada e sada definidos para as operaes
devem ser definidos de modo simples e genrico.

Ao aplicarem-se os princpios de orientao a servios, deve-se atentar para que

eles se mantenham autnomos sem dependncias entre sua lgica de negcio.

Por fim, devem ser identificadas as possveis restries de ordem tcnica que se
aplicam ao servio de aplicao, como componentes, APIs e adaptadores
necessrios para a realizao de conexes, restries de segurana e possveis
requisitos de SLA.

3.3.2.8 Projeto de servios baseados em tarefas

Servios baseados em tarefas pertencem camada de servios de negcio e

geralmente tm seu projeto simplificado por possurem pouca necessidade de serem
reusveis. Tipicamente encapsulam lgica de fluxo de trabalho e realizam a
orquestrao de servios de aplicao.

A lgica de fluxo de trabalho deve ser especificada, podendo ser representada por
diagramas de atividades. Esta lgica especificada pode auxiliar na descoberta de
novas operaes necessrias. As operaes candidatas tm suas entradas e sadas
mapeadas e so representadas por meio de documentos XSD e WSDL.

3.3.2.9 Projeto de processo orientado a servios

Os processos de negcio orientados a servios correspondem camada de

orquestrao da arquitetura SOA. O processo corresponde ao fluxo de execuo de
 86

servios de negcio, com suas regras e lgica, descrevendo o que chamado de

orquestrao de servios. No mtodo proposto por Erl, a linguagem WS-BPEL
utilizada para representar as definies dos processos de negcio.

Enquanto o projeto de servios baseados em tarefas e em entidades concentrava-se

em definir as interfaces dos servios e as mensagens das operaes, o projeto de
processos de negcio busca criar um fluxo WS-BPEL que implemente a lgica de
negcio relegada camada de orquestrao durante a Anlise Orientada a
Servios. Tal lgica que foi deixada de fora dos servios especificados abstrada
em um processo de negcio separado.

O primeiro passo do projeto de processos recebe como entrada a descrio da

lgica de fluxo de trabalho a ser abstrada pela orquestrao, o servio de processo
candidato e os servios de negcio projetados nas atividades de projeto anteriores.
Devem-se levantar quais os tipos de dados e informaes sero necessrios para
executar a lgica e invocar os servios de negcio. Com base neste levantamento,
devem-se especificar os esquemas de dados das mensagens utilizadas no processo
e a interface do servio de processo. Neste ponto muitos esquemas definidos para
os servios de negcio podero ser reaproveitados.

Definidas a interface e as mensagens, parte-se para o desenvolvimento da

especificao WS-BPEL do processo. Neste passo, ser especificado como os
servios sero orquestrados. Devem-se definir quais servios sero invocados, criar
as regras de negcio envolvidas nas invocaes e o tratamento dos dados trocados
com os servios.

Com os processos WS-BPEL especificados, deve-se analisar a lgica de fluxo de

trabalho criada frente aos cenrios de execuo discutidos anteriormente. Neste
passo, pode ocorrer um refinamento do processo e dos servios de negcio, dando
origem a algumas alteraes necessrias de acordo com os cenrios.

3.3.3 Papis

O mtodo proposto por Erl no especifica papis para a realizao de suas

atividades.
 87

3.3.4 Artefatos

A documentao dos requisitos de negcio um artefato utilizado na fase inicial de

Anlise Orientada a Servios e especifica os requisitos relacionados soluo em
desenvolvimento. Estes requisitos podem ser obtidos por meio de tcnicas
convencionais de levantamento utilizadas em mtodos de desenvolvimento de
software distribudo.

A documentao dos servios candidatos o resultado da Anlise Orientada a

Servios e consiste em uma descrio em alto nvel dos servios criados a partir do
agrupamento de operaes candidatas identificadas. Este artefato descreve a lgica
de negcio executada por cada operao candidata do servio.

Durante o Projeto Orientado a Servios, as mensagens trocadas pelas operaes

so definidas na forma de esquemas XSD e a descrio das interfaces realizada
por meio da linguagem de definio de interfaces WSDL. Os servios de processo
desenvolvidos para a camada de orquestrao so especificados utilizando-se a
linguagem de definio de processos WS-BPEL.

3.3.5 Anlise do Mtodo

O mtodo proposto por Erl consiste em uma abordagem puramente top-down para
identificao e especificao de servios. Na atividade de modelagem de servios
candidatos, Erl descreve de forma detalhada os passos a serem executados para
identificar operaes candidatas e descrever os servios candidatos resultantes.

O autor coloca a modelagem de processo como parte da atividade de definio de

requisitos de negcio, separando-a das atividades de identificao e descrio dos
servios que ocorrem durante a modelagem de servios candidatos. Apesar de no
serem especificados os papis associados s atividades, esta separao permite
que cada atividade seja executada por pessoas com conhecimentos especficos.

Apesar de os recursos existentes serem identificados durante a Anlise Orientada a

Servios, o reuso destes recursos no considerado para compor os servios
descritos na modelagem de servios candidatos. Tal identificao servir para definir
 88

se um passo do processo ser executado por um servio ou por uma aplicao

legada, sendo que no segundo caso no considerado como uma execuo de
servio. Conseqentemente, no h descrita no mtodo nenhuma atividade para
definio de como cada servio ser realizado.

O conceito de servios candidatos utilizado pelo mtodo de Erl como transio da

Anlise para o Projeto. Os servios so considerados candidatos desde sua
modelagem at o momento em que tm sua especificao definida.

Trata-se de uma proposta bastante alinhada ao conceito de BPM, que aplicado

tanto durante a decomposio de processos de negcio em servios quanto no
projeto de processo de negcio orientado a servio, atividade em que aplicada a
orquestrao de processos em WS-BPEL.

Na fase de Projeto, o mtodo leva em considerao as camadas de servios, ao

descrever atividades de projeto voltadas para cada tipo de servio: entidade, tarefa e
aplicao. Cada uma destas atividades tem como objetivo especificar servios
focando nas particularidades de um determinado tipo de servio.

Erl d bastante nfase aos princpios de orientao a servios, incluindo atividades

especficas para validao tanto na Anlise quanto no Projeto (ERL, 2007). Na
atividade de modelagem de servios candidatos, realiza-se uma avaliao para
verificar se os servios candidatos modelados possuem caractersticas de
reusabilidade e autonomia. J durante as atividades de projeto de servios, so
verificados os princpios de reusabilidade, autonomia, independncia de estado e
baixo acoplamento, dependendo do tipo de servio sendo projetado. Como o mtodo
adota a tecnologia Web Services para a realizao dos servios, so utilizados os
padres XSD e WSDL para especificar os contratos de servios.

3.4 Marks e Bell

Marks e Bell argumentam que a unidade fundamental de uma arquitetura SOA o

servio. Sem que existam os servios e os consumidores destes servios, no se
tem uma arquitetura SOA (MARKS; BELL, 2006). Estes servios devem ser
reusveis, interoperveis e devem possuir o nvel adequado de granularidade.
 89

Deste modo, um grande desafio implementao de SOA estabelecer um

processo para identificar e construir os servios que satisfaam as metas do negcio
e agreguem valor a ele. necessrio garantir que os servios desenvolvidos na
organizao sejam eficientes e eficazes. Devem ser eficientes no sentido de ser bem
projetados e operar de acordo com os requisitos funcionais, de desempenho e de
qualidade. E tambm devem ser eficazes, atendendo a necessidades crticas para o
negcio.

Marks e Bell (2006) apresentam uma abordagem para a adoo da orientao a

servios em uma organizao, que parte das necessidades de negcio e metas
estratgicas at chegar aos projetos de implementao da arquitetura e ao
desenvolvimento dos servios em si. Os autores descrevem o ciclo de vida dos
servios em uma arquitetura SOA e detalham um mtodo de identificao, anlise e
projeto de servios.

3.4.1 Ciclo de Vida

O ciclo de vida de servios reflete o processo que vai desde a identificao e

descoberta, anlise e projeto de servios at sua implementao e gerenciamento.
Este processo compreende a evoluo dos servios desde sua concepo at sua
maturidade, passando pela execuo.

As fases do ciclo de vida dividem-se em dois domnios: o domnio do problema e o

domnio da soluo. O domnio do problema formado pelas atividades do ciclo de
vida que resultam na identificao e anlise dos servios da organizao, tendo
como produto um conjunto de servios candidatos. J o domnio da soluo envolve
o projeto dos servios candidatos, a implementao e integrao, resultando nos
servios de soluo construdos.

As fases do ciclo de vida so: Motivao, Conceituao, Modelagem, Realizao e

Gerenciamento. As fases do ciclo de vida e suas atividades so exibidas na Figura
3.13 e descritas nas sees seguintes.
 90

Figura 3.13: Ciclo de Vida de Servios (MARKS; BELL, 2006)

3.4.1.1 Motivao

A fase de Motivao consiste nas foras motivadoras, como eventos, necessidades

de negcio e de TI e problemas, influenciando a criao de novos servios.

Eventos podem ser tendncias de mercado, ameaas competitivas,

regulamentaes ou ocorrncias tecnolgicas que criam oportunidades e demandam
algum tipo de resposta por parte da organizao.

Necessidades de negcio so questes como baixa satisfao dos clientes,

aumento na competio ou um longo time-to-market, isto , questes relativas ao
modelo de negcio da organizao. J as necessidades de TI so as questes do
domnio da tecnologia, como custos excessivos de integrao, dificuldade de
suportar mudanas no negcio ou atrasos crnicos na entrega de projetos. So
necessidades que devem ser resolvidas, ou a organizao ter conseqncias
negativas. Geralmente as necessidades de TI e de negcio esto relacionadas, de
 91

modo que, solucionando-se uma necessidade de TI, contribui-se para resolver uma
necessidade de negcio.

Por fim, podem ocorrer problemas quando no se possui um conjunto de medidas

preventivas para tratar os impactos causados por eventos. Problemas ocorridos
devem ser identificados e estudados, de modo a determinar sua severidade,
conseqncias e possveis causas.

Todas estas informaes serviro como motivao para a criao de novos servios,
que tero o objetivo de tratar eventos e resolver necessidades e problemas da
organizao.

3.4.1.2 Conceituao

Na fase de Conceituao, so levantadas idias e so definidos conceitos que sero

posteriormente utilizadas na modelagem dos servios.

As idias consistem em alternativas de soluo para as necessidades e problemas

identificados na fase anterior, enquanto os conceitos so os termos de negcio,
como processos e entidades, envolvidos na soluo a ser proposta. Essas idias e
conceitos devem ser bem definidos neste momento, pois daro origem aos servios
de negcio candidatos.

3.4.1.3 Modelagem

A fase de Modelagem recebe como entrada os servios candidatos identificados nas

fases anteriores e formada pelas atividades de anlise e projeto.

Para os autores, esta fase fundamental para identificar, projetar e implementar os

servios crticos para a organizao. Os servios desenvolvidos devem ser
mapeados para as necessidades de TI e de negcio da organizao e suportar suas
metas estratgicas.

Na anlise, so realizadas operaes lgicas de modelagem sobre os servios

candidatos para compreender melhor os candidatos e seus relacionamentos. Estes
 92

candidatos podem ser decompostos ou agregados e so tambm priorizados e

detalhados, o que resulta em um conjunto de servios de negcio.

J a atividade de projeto define o escopo dos servios de soluo, que sero criados
a partir dos servios de negcio. Os servios de negcio recebidos tm sua
granularidade mapeada e so ento agrupados de modo a suportar domnios de
negcio especficos.

Esta a fase analisada como mtodo de anlise e projeto orientado a servios de

Marks e Bell.

3.4.1.4 Realizao

A fase de Realizao recebe como entrada as especificaes dos servios de

negcio finais e compreende as atividades de realizao, implementao e
integrao.

Na realizao, as especificaes dos servios de negcio finais so traduzidas em

especificaes tcnicas de como as funes dos servios sero executadas, seja
por componentes de software a serem desenvolvidos ou por adaptao de funes
j existentes no legado.

Na atividade de implementao, ocorrem o desenvolvimento e os testes dos

componentes de acordo com a especificao do servio, enquanto que na
integrao, so realizadas as interaes com aplicaes e servios j existentes na
arquitetura.

3.4.1.5 Gerenciamento

Por fim, na fase de Gerenciamento so executadas diversas atividades para garantir

que os servios operem adequadamente e atendam aos seus requisitos funcionais e
no-funcionais (gerenciamento da operao, monitorao de QoS).

Esta fase engloba tambm atividades para manter a arquitetura SOA, como o
gerenciamento do portflio de servios e do seu ciclo de vida, alm do
 93

estabelecimento de polticas e processos de governana, que garantiro o controle

sobre os servios.

3.4.2 Atividades de Anlise

O mtodo proposto por Marks e Bell aborda a anlise pelos modos top-down e
bottom-up em ciclos iterativos. Por um lado, a perspectiva bottom-up pode deixar os
servios presos a seu ambiente tecnolgico de origem, gerando alto acoplamento e
potencial limitado de reuso. Por outro lado, a perspectiva top-down pode facilitar o
reuso e o alinhamento, mas os servios resultantes podem ser difceis de
implementar devido falta de tcnicas de projeto mais concretas do ponto de vista
da tecnologia. Por isso, os autores propem o uso dos dois modos de maneira
iterativa. A anlise top-down usada para identificar conceitualmente os servios
candidatos e analis-los antes de se prosseguir com o projeto. Ento, o mtodo
segue com o projeto sendo realizado por uma perspectiva bottom-up, quando os
servios candidatos so traduzidos em servios de soluo fsicos.

Os passos do processo de identificao e anlise de servios segundo Marks e Bell

podem ser resumidos na Figura 3.14.

Figura 3.14: Processo de identificao e anlise de servios (MARKS; BELL, 2006)

3.4.2.1 Identificao de Servios Candidatos

O processo de identificao de servios deve ser conduzido de maneira top-down,

com foco em obter servios de negcio candidatos. Isto , deve-se preocupar em
identificar servios potenciais que suportem o modelo de negcio da organizao,
 94

sem considerar neste momento o atual ambiente fsico e tecnolgico. Tais aspectos
devem ser levados em conta em uma etapa posterior.

Os autores propem alguns modos de se identificar servios de negcio candidatos:

anlise de processo de negcio, anlise de entidades, experincia de domnio de
negcio, servios pr-existentes e aplicaes existentes. Na maior parte dos casos,
todos os modos podem e devem ser utilizados para identificar potenciais servios de
negcio da organizao.

A anlise de processo de negcio indicada para organizaes que j faam uso

de modelagem de processos, j possuindo uma base de documentao com
detalhes dos principais processos de seu modelo de negcio. Neste caso,
analisando-se o mapa de processos da organizao, possvel identificar possveis
servios de negcio a partir de atividades do processo que possam fazer uso da
infra-estrutura de TI.

Pode-se abordar a identificao de servios pela anlise de entidades, que uma

perspectiva mais orientada a modelagem de dados. Nesta abordagem, servios
candidatos de negcio so identificados a partir de modelos de dados
documentados e diagramas entidade-relacionamento. Primeiro, determinam-se as
entidades centrais da organizao, ou seja, as entidades com maior importncia do
ponto de vista do negcio (cliente, produtos, eventos, etc.). A seguir, deve ser feito
um processo de brainstorming para identificar os processos e eventos relacionados
a estas entidades, isto , quais so os verbos que atuam sobre os substantivos
(entidades) identificados. Tais verbos so candidatos a se tornar servios de
negcio.

Para auxiliar na identificao dos servios, os autores propem o uso da

experincia no domnio de negcio, que pode ser representada por um indivduo
especfico especialista no assunto ou pelo conhecimento da organizao como um
todo. A experincia e conhecimento sobre problemas e dificuldades mais comuns,
pontos crticos do negcio e influncias externas podem ser utilizados durante a
anlise de processo de negcio ou de entidade para guiar a identificao de servios
mais eficazes para a organizao.

A organizao pode j possuir um conjunto de servios pr-existentes

provenientes de projetos anteriores, projetos-piloto ou at mesmo servios
 95

desenvolvidos independentemente sem o conhecimento da organizao. Estes

servios devem ser levados em considerao para otimizar investimentos passados.
Servios independentes devem ser publicados para toda a organizao em um
registro ou repositrio. Deste modo, os servios j existentes podem ser reusados,
compostos e reprojetados de acordo com os requisitos do negcio.

Por fim, outra possvel fonte de servios candidatos a ser considerada so as

aplicaes existentes (sistemas de informao corporativos, aplicaes legadas e
bases de dados). Funes existentes nestas aplicaes podem ser aproveitadas,
agregadas ou fragmentadas para dar origem a servios utilizveis pelo negcio.

3.4.2.2 Anlise de Servios Candidatos

Uma vez identificados os servios de negcio candidatos, estes devem ser

analisados e projetados para implementao. A anlise de servios candidatos
proposta por Marks e Bell consiste de operaes lgicas de transformao sobre os
candidatos para a formao de servios de negcio finais. O foco principal desta
atividade controlar a granularidade e o potencial de reuso dos servios
desenvolvidos.

O primeiro passo a anlise de granularidade dos servios de negcio candidatos.

Cada candidato identificado na etapa anterior deve ter sua funcionalidade avaliada
para a determinao de sua granularidade esperada. Como resultado, obtm-se um
mapa de granularidade, exemplificado na Figura 3.15. Este mapa categoriza os
servios de negcio candidatos por nvel de granularidade, posicionando os servios
com granularidade mais alta acima dos de granularidade mais baixa, formando uma
hierarquia.
 96

Figura 3.15: Mapa de granularidade de servios (MARKS; BELL, 2006)

A partir da, o segundo passo a aplicao de uma srie de operaes lgicas

sobre os servios de negcio candidatos de acordo com suas funes e nveis de
granularidade. Tais operaes so transformaes baseadas na teoria de conjuntos,
a saber: unio, interseo, decomposio, subconjunto e subtrao. Estas
operaes lgicas so aplicadas de modo a agregar e fragmentar os servios de
negcio candidatos, reorganizando suas operaes e dando origem aos servios de
negcio finais.

Na operao de unio, dois ou mais servios relacionados so agrupados e tm

suas funes consolidadas para dar origem a um nico servio resultante. Esta
operao no elimina nenhuma funo existente, mas apenas agrupa as funes de
servios baseada em suas similaridades. Deve-se reavaliar a granularidade do
servio resultante, que tender a ser maior que a dos servios unificados.

A operao de interseo aplicada quando so identificadas funes comuns em

dois ou mais servios. As funes que se sobrepem em vrios servios so
retiradas dos servios originais e agrupadas para dar origem a um novo servio.
Uma caracterstica importante deste servio gerado a reuso, uma vez que ele j
nasce com mais de um consumidor. Deve-se apenas atentar para no utilizar a
interseo em servios de granularidade muito baixa.
 97

Alguns servios de negcio candidatos podem possuir granularidade alta demais, o

que dificultaria sua implementao e gerenciamento. Para estes casos, pode-se
utilizar a operao de decomposio, que fragmenta o servio inicial em diversos
servios desacoplados com menor granularidade. Deve-se tomar cuidado para que
os servios resultantes no apresentem interdependncias entre si.

Na operao de subconjunto, um ou mais servios de negcio candidatos so

agregados a outro servio de negcio candidato j previamente identificado. Esta
operao trata servios individuais como subconjuntos de um servio maior. Esta
agregao baseia-se no princpio de composio, por meio de tcnicas de
orquestrao ou coreografia, onde os servios menores suportam a operao
interna do servio de maior granularidade.

Por fim, a operao de subtrao aplicada no caso de servios de negcio

candidatos que possuem funes desnecessrias que podem dificultar sua
implementao, reuso ou gerenciamento. A subtrao remove funo e lgica de
negcio desnecessrias, para que o servio final possa focar somente em funes
mais relevantes. Em alguns casos, as funes removidas podem dar origem a um
novo servio se ainda possurem valor para a organizao. Caso contrrio, elas so
eliminadas completamente da arquitetura.

Aps a aplicao das operaes lgicas, analisa-se seu impacto sobre a

granularidade dos servios resultantes, atualizando o mapa de granularidade com os
servios de negcio finais.

3.4.3 Atividades de Projeto

Na fase de projeto de servios, so criados os servios fsicos a partir dos servios

de negcio obtidos na fase de identificao e anlise. O projeto comea com um
mapa de granularidade contendo os servios de negcio finais.

importante ressaltar que as atividades de projeto no so focadas em detalhes da

tecnologia de implementao. Em vez disto, o projeto preocupa-se com
composies de servios, lgica de negcio encapsulada por eles e reusabilidade de
servios.
 98

Os passos da fase de projeto segundo o mtodo proposto podem ser visualizados

na Figura 3.16.

Figura 3.16: Processo de projeto de servios (MARKS; BELL, 2006)

No primeiro passo, os servios de negcio resultantes da fase de anlise devem ser

examinados sob o ponto de vista da viabilidade e da aderncia estratgia de SOA
da organizao. Assim, deve-se criar uma escala de prioridade dos servios
baseados em seus aspectos tcnicos e de negcio e nos nveis de granularidade j
estabelecidos. Esta escala de priorizao servir de base para selecionar os
servios que sero implementados como servios fsicos de soluo.

A partir deste mapa de granularidade de servios selecionados de acordo com a

escala de prioridade, so construdos os mapas de demarcao, exemplificados na
Figura 3.17. Neste mapa, so indicados grupos de servios que sero transformados
em servios de soluo fsicos. O processo de demarcao conceitual e agrupa
servios baseado em seu contexto comum, ou seja, domnio de negcio, padres de
consumo, requisitos de SLA ou ambiente de execuo. Tal agrupamento deve iniciar
pelos servios de granularidade mais alta para os de mais baixa. Deste modo,
servios com potencial de reuso so detectados atravs da sobreposio de grupos
de demarcao.
 99

Figura 3.17: Mapa de demarcao (MARKS; BELL, 2006)

3.4.3.1 Projeto de Servios Fsicos

Com a elaborao dos mapas de demarcao de servios, pode-se iniciar o projeto

dos servios de soluo, que so os servios fsicos, tangveis que executam suas
funes estabelecidas e resolvem problemas e questes do negcio.

Na atividade de projeto so realizadas algumas operaes sobre os servios de

negcio representados e agrupados no mapa de demarcao, com o intuito de
estabilizar os nveis de granularidade, generalizar servios para uma granularidade
mais alta ou demov-los para um nvel de granularidade mais baixo. Estas
operaes focam em direcionar o atendimento das metas de negcio e de TI atravs
da manipulao de grupos de servios, em vez de servios individuais. As
operaes possveis de serem aplicadas so: promoo, demoo, importao,
exportao, criao e remoo.

A promoo eleva o nvel de granularidade de um servio e utilizada para

aumentar o escopo de um determinado servio e permitir que ele contenha outros
servios de granularidade mais baixa. J a demoo tem efeito contrrio e diminui o
nvel de granularidade de um servio. utilizada no caso de servios que possuem
 100

escopo muito pequeno para serem mantidos em um nvel alto de granularidade, ou

quando um servio pode ser encapsulado por outro mais genrico.

A importao de servios permite a expanso do escopo de um determinado grupo

de servios de maneira horizontal, isto , sem elevar ou reduzir seu nvel de
granularidade. A importao aplicada quando se pretende adicionar a um
determinado grupo de servios uma funo representada por um servio
pertencente a outro grupo. A importao pode ser exclusiva, movendo-se o servio
de um grupo para outro, ou compartilhada, mantendo o servio como parte dos dois
grupos. A exportao a operao anloga, que representa o ponto de vista do
grupo de onde um servio pode ser retirado para compor outro grupo. Tambm pode
ser exclusiva ou compartilhada.

J a criao e a remoo flexibilizam o projeto permitindo, respectivamente, que se

incluam e excluam servios do mapa de demarcao conforme a necessidade.

3.4.3.2 Realizao de Servios de Soluo

O passo final do processo de projeto consiste na atividade de realizao dos

servios, obtendo-se os servios fsicos de soluo. Nesta atividade, o foco passa a
ser na modelagem fsica dos servios e em sua arquitetura. Os servios de negcio
representados nos mapas de granularidade e de demarcao elaborados nas etapas
anteriores so transformados em elementos concretos, que podem ser servios de
soluo, componentes fsicos ou processos de servio. Os trs tipos de
transformao so representados na Figura 3.18.
 101

Figura 3.18: Tipos de transformao lgico-fsico (MARKS; BELL, 2006)

A transformao de servios de negcio para servios de soluo direta,

somente passando do campo conceitual para o concreto, no sendo
necessria nenhuma mudana de nvel de granularidade. Este tipo de
transformao geralmente utilizado nos servios de negcio de
granularidade mais alta.
A transformao de servios de negcio para componentes fsicos
geralmente aplicada em servios de menor granularidade, ou pode demover
servios para um nvel mais baixo.
J a transformao para processos de servio usada quando a funo
encapsulada possui um escopo realmente pequeno, sendo mapeada para um
processo pertencente a um servio de soluo.

Estas decises de transformao de lgico para fsico devem ser baseadas em

aspectos de negcio, tecnolgicos e organizacionais. Diferentes diretrizes para a
definio de granularidade e particularidades do ambiente tecnolgico podem
produzir diferentes tipos de cenrios de transformao.
 102

3.4.4 Papis

O mtodo descrito por Marks e Bell no identifica papis para a execuo das
atividades.

3.4.5 Artefatos

O mapa de granularidade o diagrama produzido durante a atividade de anlise do

mtodo proposto por Marks e Bell. Neste diagrama, os servios so divididos em
nveis de granularidade, representando-se os nveis mais altos de granularidade na
parte de cima e os nveis mais baixos na parte de baixo. O mapa de granularidade
permite uma visualizao grfica das relaes de granularidade dos servios e
possibilita estabelecer-se uma hierarquia de prioridade entre eles.

J o mapa de demarcao, utilizado nas atividades de projeto, obtido a partir do

mapa de granularidade e representa agrupamentos lgicos de servios por meio de
demarcaes. Servios com similaridades no contexto do negcio e da tecnologia
so considerados como parte de um mesmo grupo e so representados dentro da
mesma linha de fronteira.

3.4.6 Anlise do Mtodo

O mtodo de Marks e Bell procura aliar a abordagem top-down de identificao de

servios com a abordagem bottom-up para a realizao do servio. No entanto, no
so descritas explicitamente atividades para analisar alternativas de realizao para
cada servio.

So oferecidas diversas fontes para identificao de servios, sendo uma delas a

anlise de processo de negcio, o que permite a sua aplicao em um cenrio com
modelagem de processos. Porm, outros aspectos do BPM, como a orquestrao de
servios, no so considerados.

Na proposta, possvel tambm identificar servios candidatos a partir de

aplicaes e servios pr-existentes. Tal caracterstica possibilita o
 103

reaproveitamento de investimento j realizado, atravs do reuso de recursos

existentes. Mas como no h uma atividade para a tomada de decises de
realizao, este reuso no se torna possvel para servios identificados a partir de
outras fontes.

O conceito de servio candidato utilizado como parte do ciclo de vida de servios

definido pelo mtodo. So definidos trs estados para um servio durante este ciclo
de vida: servio de negcio candidato, servio de negcio final e servio de soluo
(fsico). No momento em que identificado, um servio de negcio considerado
candidato. Aps a anlise de granularidade e aplicao das operaes lgicas, os
servios de negcio so classificados como finais. Finalmente, aps as atividades de
projeto e realizao, obtm-se os servios finais que sero implementados.

Marks e Bell do bastante nfase ao controle da granularidade dos servios a serem

desenvolvidos. Na anlise de servios candidatos, o mtodo prope o uso dos
mapas de granularidade para classificar os servios candidatos de acordo com seu
nvel de granularidade. No passo seguinte, so utilizadas operaes lgicas
derivadas da teoria dos conjuntos (unio, interseo, decomposio, subconjunto e
subtrao) para manipular os servios de forma que eles tenham nveis adequados
de granularidade.

Alm da granularidade dos servios, o mtodo considera tambm os princpios de

reusabilidade e composio. A reusabilidade levada em conta durante as
operaes lgicas na anlise de servios candidatos, enquanto o princpio da
composio exercitado durante a realizao dos servios de soluo.

O mtodo no descreve alternativas concretas para especificao dos contratos dos

servios, de seu comportamento funcional ou de seus requisitos no funcionais.

O mtodo de Marks e Bell consiste em uma alternativa mais abstrata de

desenvolvimento orientado a servios, pois no se prende a uma abordagem
especfica como o BPM nem a uma tecnologia especfica, como Web Services.
 104

3.5 Consideraes Finais

O Captulo 3 apresentou uma descrio e anlise dos mtodos existentes para

desenvolvimento orientado a servios. Foram analisadas as boas prticas utilizadas
em cada mtodo. Alm disso, solues que cada mtodo adota para solucionar cada
requisito podem ser levadas em conta na proposio de uma nova abordagem.

Pode-se constatar pela anlise que Business Process Management e a tecnologia

Web Services so aplicados em conjunto com SOA com tanta freqncia que alguns
mtodos tomam como premissa o uso dessas abordagens, como as propostas de
Erl e Papazoglou e Van Den Heuvel.

Outra caracterstica predominante nos mtodos a anlise de recursos existentes,

seja para a identificao ou para a realizao dos servios. Sendo o reuso um dos
principais benefcios esperados da orientao a servios, fundamental considerar
os ativos existentes na organizao.

Os mtodos analisados so as principais referncias para a elaborao de uma

nova proposta de mtodo. O mtodo proposto deve procurar unificar as abordagens
analisadas contemplando boas prticas encontradas em cada uma delas. A partir da
anlise das propostas, possvel tambm levantar os requisitos de anlise e projeto
de servios.
 105

4 REQUISITOS DE UM MTODO DE ANLISE E PROJETO ORIENTADO A

SERVIOS

A partir da anlise dos mtodos da literatura, foram identificadas boas prticas a

partir das quais possvel inferir um conjunto de requisitos que um mtodo de
anlise e projeto orientado a servios deveria satisfazer. Estas boas prticas
consistem em solues propostas pelos mtodos para atender s necessidades de
anlise e projeto de servios.

4.1 Descrio dos Requisitos

Nas sees a seguir, so descritos os requisitos levantados. Os requisitos so

identificados com cdigos R1, R2, R3, etc. para referncia ao longo do texto.

4.1.1 Abordagem meet-in-the-middle (R1)

Um mtodo de anlise e projeto orientado a servios no pode limitar-se a propor

somente uma abordagem top-down, levando em conta apenas os requisitos e
objetivos do negcio para a identificao e especificao de servios. Tampouco
deve ser uma abordagem puramente bottom-up, apenas encapsulando
funcionalidade de aplicaes legadas na forma de servios. Um mtodo deve de
alguma forma equilibrar as duas alternativas, resultando em uma abordagem meet-
in-the-middle.

A identificao de servios deve ser guiada pelos requisitos e pela modelagem de

negcio, assim como estar alinhada s suas metas e estratgias de negcio. No
entanto, os servios identificados a partir do negcio devem ser analisados e
revisados de modo a ajustar-se realidade dos servios j existentes na
organizao e das aplicaes legadas. Desta maneira, obtm-se o reuso de
recursos existentes e cria-se valor a partir do investimento j realizado.
 106

O mtodo de Papazoglou e Van Den Heuvel atende a este requisito, pois os

servios so propostos como parte do processo de negcio, mas so comparados
com os recursos existentes na anlise de gap.

O RUP plugin for SOMA tambm possui esta caracterstica, pois procura alinhar os
servios aos requisitos de negcio e aos sistemas existentes.

4.1.2 Compatibilidade com Business Process Management (R2)

A adoo da arquitetura orientada a servios em uma organizao pode trazer

maiores benefcios se realizada em conjunto com a adoo de prticas de Business
Process Management (BPM). Com o surgimento do padro WS-BPEL, a utilizao
conjunta de SOA e de BPM foi viabilizada e potencializada. O WS-BPEL permite a
composio e orquestrao de servios a partir de definies de processos, criadas
por analistas de negcio. Desta maneira, aumenta-se o alinhamento dos servios
desenvolvidos com as metas e estratgias de negcio.

Um mtodo orientado a servios deve levar em considerao esta sinergia e

incorporar tcnicas de BPM para a anlise e o projeto de servios (PAPAZOGLOU;
VAN DEN HEUVEL, 2006). Nas atividades de anlise e projeto, dois aspectos do
BPM so aplicveis: a modelagem de processos e a automao de processos.

A tcnica de modelagem de processos pode ser empregada para documentar o

modelo de negcio e seus requisitos, que por sua vez, sero o ponto de partida para
a identificao de servios.

J a automao de processos em uma arquitetura SOA pode ser realizada por meio
da orquestrao de servios. Caso os processos sejam modelados em uma notao
como o BPMN, eles podero ser convertidos para uma linguagem de orquestrao
como WS-BPEL e executados em um servidor de aplicaes.

Um mtodo deve viabilizar projetos de BPM com SOA, mas no deve limitar-se a
esta abordagem, permitindo tambm a realizao de projetos de SOA somente.

Os mtodos de Papazoglou e Van Den Heuvel e de Erl contemplam ambos os

aspectos de BPM. J o RUP plugin for SOMA e o mtodo de Marks e Bell
 107

descrevem somente a elaborao de modelos de processos e a identificao de

servios a partir deles, no abordando a orquestrao de servios.

4.1.3 Reuso de recursos existentes (R3)

Um dos princpios fundamentais da orientao a servios o reuso. Sendo assim,

um mtodo de anlise e projeto orientado a servios deve procurar maximizar o
reaproveitamento de lgica j existente, esteja ela na forma de servios disponveis
no portflio da organizao ou na forma de aplicaes legadas, que ainda teriam
que ser transformadas em servios.

Segundo este requisito, durante o processo de anlise e projeto de uma soluo

orientada a servios, os recursos existentes na organizao devem ser analisados
como alternativas para identificao ou realizao de servios.

O mtodo de Papazoglou e Van Den Heuvel oferece uma soluo interessante para
este requisito, que a incluso da atividade de anlise de gap. Esta uma atividade
que possui exatamente o intuito de avaliar se h algum servio ou sistema legado
existente que atenda aos requisitos definidos durante a modelagem dos processos e
servios.

J o RUP plugin for SOMA e o mtodo de Marks e Bell analisam os recursos

existentes como uma alternativa de identificao de servios do tipo bottom-up.

A proposta de Erl no atende a este requisito, pois apesar de as aplicaes legadas

existentes serem identificadas, elas no so consideradas como alternativas para
realizao de servios. Pelo contrrio, tal identificao tem como propsito detectar
as tarefas de um processo de negcio em que no sero utilizados servios.

4.1.4 Especificao de requisitos no-funcionais (R4)

Um ponto bastante questionado de implementaes de arquitetura SOA o suporte

a requisitos no-funcionais dos servios, tambm chamados de requisitos de
qualidade de servio (QoS). Nesta rea, existe uma srie de padres abertos sendo
 108

desenvolvidos no sentido de especificar o tratamento de requisitos como segurana,

desempenho e transaes.

Um mtodo proposto deve buscar formas de abordar requisitos no-funcionais, ou

seja, incluir em seu fluxo de trabalho atividades em estes requisitos so definidos e
documentados como parte da especificao de um contrato de servio. Para tal, o
mtodo pode adotar padres especficos, como WS-Security, WS-Policy ou WS-
AtomicTransaction.

Dos mtodos analisados, apenas o RUP plugin for SOMA e a abordagem de

Papazoglou e Van Den Heuvel descrevem de maneira explcita a definio dos
requisitos no-funcionais, em suas respectivas atividades de especificao de
servios.

4.1.5 Diferentes alternativas para identificao de servios (R5)

Um mtodo de anlise e projeto orientado a servios deve oferecer flexibilidade aos

analistas no momento de identificar potenciais servios necessrios para a
organizao a partir da modelagem de negcio. Como ponto de partida para esta
identificao, podem ser utilizados modelos de processos, descries de casos de
uso de negcio e modelos de dados para a abordagem top-down e, no caso bottom-
up, aplicaes legadas e servios j existentes que podem ser reusados em uma
composio.

O RUP plugin for SOMA permite identificar novos servios a partir de diversas
fontes, como processos de negcio, casos de uso de negcio, aplicaes existentes,
regras de negcio e modelos de dados.

J no mtodo de Marks e Bell, podem ser utilizadas as seguintes fontes: processos

de negcio, entidades de dados, requisitos de negcio e aplicaes existentes.

Os mtodos de Erl e de Papazoglou e Van Den Heuvel permitem apenas a

identificao de servios a partir de processos de negcio.
 109

4.1.6 Diferentes alternativas para realizao de servios (R6)

Assim como no caso da identificao, deve existir flexibilidade para a especificao

de servios, sendo considerados diversos cenrios de realizao. Um servio
identificado pode ser especificado como um novo componente a ser desenvolvido,
como uma composio de servios existentes, na forma de reuso de um servio j
existente com potenciais ajustes ou na forma de reuso de lgica de alguma
aplicao legada, que pode ser disponibilizada por um servio encapsulando ou por
meio de alguma API ou adaptador.

Um mtodo deve levar em conta os diversos cenrios possveis para realizao de

um servio e analisar aspectos como custo, risco, esforo e ROI, o que permitir ao
analista que estiver criando a especificao decidir qual abordagem adotar.

A proposta de Papazoglou e Van Den Heuvel descreve a atividade de Anlise de

Realizao, em que decide-se como cada servio ser desenvolvido com base nas
alternativas disponveis: green-field, top-down, bottom-up e meet-in-the-middle.

No RUP plugin for SOMA, uma anlise semelhante ocorre na atividade Decises de
Realizao, no entanto so considerados cenrios de integrao com aplicaes
existentes.

4.1.7 Conceito de servio candidato (R7)

De acordo com este requisito, o ciclo de vida de um servio deve possuir um passo
intermedirio entre o momento em que concebido ou identificado e o momento em
que ele especificado. Neste passo intermedirio, o servio seria classificado como
candidato. Em um mtodo orientado a servios, o conjunto de servios de uma
soluo concebidos ou identificados no necessariamente realizado e especificado
em seu estado original. Por este motivo, ele considerado candidato at ser passar
por anlises e revises, que podem resultar em mudanas nas operaes,
reagrupamento de operaes e redefinio do escopo funcional de cada servio.

No RUP plugin for SOMA, o uso deste conceito viabiliza a abordagem meet-in-the-
middle, pois os servios identificados a partir da modelagem de negcio so
 110

candidatos at serem revisados durante o Teste Litmus de Servio, considerando

possveis restries do ambiente tecnolgico existente na organizao ou outras
limitaes externas.

J o mtodo de Erl utiliza o conceito de servio candidato durante toda a anlise e

projeto orientado a servios. Desde sua identificao, os servios so classificados
como candidatos, deixando de ser candidatos apenas aps sua especificao.

No mtodo de Marks e Bell, a classificao de candidato um dos vrios passos do

ciclo de vida de um servio utilizados durante a anlise e projeto. Segundo este ciclo
de vida, a identificao d origem a servios de negcio candidatos. Estes por sua
vez, passam a ser servios de negcio finais aps a anlise de granularidade e a
aplicao de operaes lgicas, tornando-se servios de soluo aps a
especificao.

4.1.8 Aderncia aos princpios de orientao a servios (R8)

Um mtodo de anlise e projeto orientado a servios deve assegurar que os

servios desenvolvidos sejam aderentes aos princpios de orientao a servios,
como reusabilidade, interoperabilidade, baixo acoplamento e autonomia. Esta
aderncia pode ser obtida inserindo-se no fluxo de trabalho do mtodo pontos de
verificao em que um conjunto de servios avaliado em relao aos princpios.
Outra maneira seria por meio de orientaes sobre como executar uma determinada
atividade levando em conta os princpios.

O mtodo proposto por Papazoglou e Van Den Heuvel inclui orientaes na

atividade de Especificao de Servios sobre como projetar contratos de servios de
acordo com os princpios de alta coeso e baixo acoplamento.

O RUP plugin for SOMA possui uma atividade de verificao dos servios, que o
Teste Litmus de Servio. Nesta atividade, porm, so validados somente os
princpios de reusabilidade e facilidade de composio.

No mtodo de Erl, existem atividades para validao dos princpios de orientao a

servios tanto na fase de anlise quanto na de projeto. Os princpios verificados so
reusabilidade, autonomia, independncia de estado e baixo acoplamento. De acordo
 111

com a fase e com o tipo de cada servio, diferentes conjuntos de princpios podem
ser validados.

O mtodo de Marks e Bell leva em conta a reusabilidade durante a anlise de

servios candidatos e a facilidade de composio durante a realizao dos servios
de soluo. Alm disso, o mtodo d nfase ao controle da granularidade dos
servios.

4.1.9 Uso de padres abertos (R9)

Caso um mtodo utilize de maneira explcita linguagens e notaes especficas para

representar seus artefatos, estas linguagens e artefatos devem adotar padres
abertos e que sejam independentes de plataforma ou de fornecedor de ferramentas
de implementao.

Exemplos de padres abertos relacionados a analise e projeto de servios so: o

WSDL para descrio de interfaces de servio, o XSD para definio de formato de
dados, o WS-BPEL para orquestrao de processos de negcio, o BPMN para
modelagem de processos, o UML para documentar requisitos e arquitetura de
software e os diversos padres WS-* para uso com a tecnologia Web Services.

Os mtodos de Erl e de Papazoglou e Van Den Heuvel, por serem alinhados

tecnologia Web Services, adotam de maneira explcita os padres WSDL, XSD e
WS-BPEL. Papazoglou e Van Den Heuvel citam ainda o uso do padro WS-Policy
para especificar requisitos no-funcionais de servios. Para representar os servios,
Erl faz uso de uma notao prpria e no-padronizada.

O RUP plugin for SOMA adota o UML como principal forma de documentar os
artefatos elaborados, como modelos de casos de uso para representar o negcio,
modelos de classe para representar contratos de servios e mensagens e diagramas
de seqncia para representar interaes entre servios.

J o mtodo de Marks e Bell no aborda tcnicas especficas de implementao dos

servios, alm de utilizar diagramas prprios e no padronizados, como os mapas
de granularidade e demarcao, durante as atividades de anlise e projeto.
 112

4.1.10 Uso de tcnicas existentes para implementao (R10)

Um mtodo de anlise e projeto deve ser estruturado de maneira tal que os seus
produtos finais (as especificaes de servios) possam servir como entrada para
atividades de uma metodologia de implementao j existente e consolidada
(PAPAZOGLOU; VAN DEN HEUVEL, 2006), como programao orientada a objetos
ou desenvolvimento baseado em componentes (CBD).

Para que isto seja possvel, necessrio que os servios sejam especificados em
um nvel detalhado o suficiente para a realizao de modelagem de classes e de
interfaces de componentes.

Dos mtodos analisados, apenas o RUP aborda explicitamente a passagem para

atividades aps a anlise e projeto. Para representar os requisitos dos servios
especificados, o RUP plugin for SOMA utiliza diagramas em UML de classes, de
seqncia, de componentes, entre outros.

4.1.11 Conceito de camadas de servios (R11)

Um mtodo de anlise e projeto deve classificar os servios especificados em

camadas, de acordo com sua funo ou nvel de granularidade. As camadas de
servios (ERL, 2005) definem uma maneira de se separar os tipos de lgica contidos
em servios e de se representar os relacionamentos dos servios com os processos
de negcio e com as aplicaes existentes.

Dependendo da camada a que um servio pertence ou de seu nvel de

granularidade, a anlise e projeto devem ser levar em considerao aspectos
especficos, como o nvel de reusabilidade e presena de lgica de processo.

O mtodo de Erl utiliza o conceito de camadas de servio, separando os servios

nas camadas de orquestrao, negcio e aplicao. Na fase de Projeto, so
descritas atividades especficas para especificar servios de cada camada.

O mtodo de Marks e Bell no utiliza explicitamente o conceito de camadas, porm

classifica os servios de acordo com o nvel de granularidade, definindo abordagens
de realizao especficas para cada nvel.
 113

4.1.12 Uso livre (R12)

O mtodo deve ser livre, isto , ser no-proprietrio. O acesso sua descrio e o
seu uso devem ser livres, para que possa ser revisado e adaptado livremente por
qualquer organizao.

Todos os mtodos analisados podem ser considerados de uso livre, com exceo do
RUP plugin for SOMA, cuja utilizao plena est vinculada aquisio de licenas
da ferramenta Rational Method Composer da IBM.

4.2 Aderncia dos mtodos analisados aos requisitos

Pode-se notar pela anlise dos mtodos existentes que nenhum deles atende por
completo a todos os requisitos levantados, como pode ser visto na Tabela 4.1. Esta
tabela resume a aderncia dos mtodos analisados aos requisitos descritos,
permitindo a identificao da origem de cada requisito. A notao X significa que o
requisito plenamente atendido pelo mtodo analisado, enquanto que a indicao
Parcial denota um atendimento parcial do requisito. Quando a correspondncia
entre mtodo e requisito estiver em branco, significa que o requisito no atendido
pelo mtodo.

Como boas prticas a serem destacadas no mtodo de Papazoglou e Van Den

Heuvel esto a compatibilidade com BPM, abordando a modelagem de processos
tanto para identificao de servios quanto para a orquestrao de processos, e as
anlise de gap e de realizao, que possibilitam o reuso de recursos existentes.

J o RUP plugin for SOMA possui maior flexibilidade para identificao e realizao
de servios, descrevendo diversas abordagens para ambas as atividades, alm de j
ser integrado a tcnicas de implementao orientadas a objetos e componentes.

O mtodo proposto por Erl bastante detalhado na validao dos princpios da

orientao a servios, possuindo atividades especficas para sua verificao, sendo
tambm alinhado abordagem BPM.

No mtodo de Marks e Bell, podem ser destacadas a flexibilidade para identificao

de servios e as diversas etapas definidas para o ciclo de vida dos servios.
 114

Tabela 4.1: Resumo da aderncia dos mtodos analisados aos requisitos

Papazoglou & RUP Plugin for Marks &

Requisito Erl
Van Den Heuvel SOMA Bell
Abordagem meet-in-the-
(R1) X X Parcial
middle
(R2) Compatibilidade com BPM X Parcial X Parcial

(R3) Reuso de recursos existentes X X Parcial X

Especificao de requisitos
(R4) X X
no-funcionais
Diferentes abordagens de
(R5) X X
identificao de servios
Diferentes abordagens de
(R6) X Parcial
realizao servios
Conceito de servio
(R7) X X X
candidato
Aderncia aos princpios de
(R8) Parcial Parcial X Parcial
orientao a servios
(R9) Uso de padres abertos X Parcial X
Uso de tcnicas existentes
(R10) X
para implementao
Conceito de camadas de
(R11) X Parcial
servios
(R12) Uso livre X X X

4.3 Consideraes Finais

No Captulo 4, foram apresentados os requisitos levantados para um mtodo de

anlise e projeto orientado a servios. Tais requisitos foram determinados a partir
das caractersticas dos mtodos estudados.

No h como afirmar que o conjunto de requisitos levantado seja um conjunto

completo, contemplando todos os requisitos possveis para anlise e projeto de
servios, mas apenas aborda os requisitos identificados como boas prticas nos
mtodos analisados.

O mtodo proposto por este trabalho deve conter atividades e solues para atender
a cada um dos requisitos levantados, de modo a unificar os mtodos existentes.
 115

5 PROPOSTA DE MTODO

Como se pode inferir a partir da anlise das propostas existentes em relao aos
requisitos, torna-se necessrio consolidar os mtodos analisados em um mtodo
que unifique as boas prticas de cada um e que atenda aos requisitos de anlise e
projeto orientados a servios.

Este captulo descreve o Mtodo de Anlise e Projeto Orientado a Servios

(MAPOS) (FUGITA; HIRAMA, 2008a) (FUGITA; HIRAMA, 2008b), uma proposta de
mtodo elaborada a partir do estudo e anlise dos mtodos existentes e dos
princpios de orientao a servio.

A descrio do mtodo segue a mesma estrutura das descries do Captulo 3, com

a adio de algumas atividades que antecedem e sucedem o mtodo no ciclo de
vida.

5.1 Ciclo de Vida

O mtodo procura oferecer flexibilidade em sua aplicao por meio de iteraes

durante a fase de Anlise e de Projeto. O ciclo de vida descrito inicia-se com a
Modelagem de Negcio, passa pelas fases de Anlise e Projeto (abrangidas pelo
mtodo), seguindo adiante com atividades de Construo, como Implementao e
Testes, conforme pode ser visualizado na Figura 5.1.
 116

Figura 5.1: Mtodo de Anlise e Projeto Orientado a Servios

A seguir so descritas as atividades de todo o ciclo de vida, a partir da fase de

Modelagem de Negcio que precede a Anlise e o Projeto Orientados a Servios,
at a fase de Construo subseqente. Para cada atividade, so explicitados o
papel da pessoa que a desempenha, os artefatos utilizados em sua execuo e os
gerados.

5.2 Atividades de Modelagem de Negcio

A Modelagem de Negcio ocorre antes das atividades de anlise do mtodo

propriamente dito. Nesta fase, busca-se um entendimento sobre as necessidades de
negcio e levantam-se os requisitos. As atividades de Modelagem de Negcio so
executadas por pessoas da rea de negcio ou da rea de processos da
organizao.
 117

5.2.1 Modelagem de Processo as-is e to-be

Na Modelagem de Processo as-is, levantado o estado atual dos processos de

negcio envolvidos no projeto. elaborado um modelo representando o estado do
negcio antes do projeto da soluo orientada a servios.

Na Modelagem de Processo to-be, o analista de processos pode realizar avaliaes

e simulaes e propor modificaes ao processo com o intuito de promover
melhorias de desempenho ou reduzir custos. Tais modificaes do processo podem
ser mudanas em sua prpria estrutura (fluxo de trabalho) ou propostas de
automatizao de parte ou de todo o processo. Como produto desta atividade,
elaborado um novo modelo de processo alterado com relao ao as-is.

Os modelos podem ser representados na forma de casos de uso de negcio ou

preferencialmente utilizando uma notao de processo, como BPMN, que pode ser
convertida diretamente para a linguagem WS-BPEL por diversas ferramentas
existentes no mercado.

O uso de notaes baseadas em padres abertos, como casos de uso e BPMN,

atende ao requisito R9.

Papis: Analista de Processo

Artefato utilizado: Requisitos de Negcio

Artefatos gerados: Modelo de Processo as-is, Modelo de Processo to-be

5.3 Atividades de Anlise

Na fase de Anlise, so identificados servios candidatos a partir dos modelos de

negcio fornecidos. Ainda nesta fase, decide-se como cada servio ser realizado,
analisando-se possibilidades de reuso para cada um, chegando a um conjunto de
servios finais.
 118

5.3.1 Identificao de Servios Candidatos

A atividade de identificao de servios candidatos a primeira atividade de Anlise

e recebe como entrada um modelo de processo to-be ou modelo de casos de uso de
negcio produzido durante a Modelagem de Negcio.

O modelo de processo to-be deve ser decomposto em uma srie de passos de baixa
granularidade e ento devem ser identificados quais os passos podero ser
automatizados. Passos no computacionais (execuo de tarefas humanas) do
processo no sero considerados nesta etapa, pois no podero ser executados por
operaes de servios.

Em um modelo de casos de uso, deve-se analisar as descries dos fluxos de

trabalho de cada caso de uso, separando os passos executados pelo ator usurios
dos passos automatizados, ou seja, executados por algum sistema ou aplicao.

O Analista de Servios deve listar os passos que sero automatizados, de modo que
cada um destes passos poder ser mapeado para uma operao de um servio
sendo invocada. As operaes relacionadas devem ento ser agrupadas, de modo
que cada grupo de operaes pertena a um servio candidato.

Devem ser agrupadas operaes que compartilhem um mesmo contexto lgico

(semntico) ou que trabalhem com as mesmas entidades de dados (ERL, 2005). Em
caso de operaes identificadas a partir de um modelo de processo, podem ser
agrupadas operaes executadas por um mesmo papel. Em caso de operaes
identificadas de um caso de uso, podem ser agrupadas operaes relacionadas a
um mesmo ator do caso de uso.

Por utilizar um modelo de processo como fonte para identificao de servios, o

mtodo procura atender ao requisito R2, ou seja, ser compatvel com a abordagem
BPM. E o requisito R5 tambm atendido, pois possvel identificar servios a partir
de processos ou casos de uso. Ao utilizar o conceito de servios e operaes
candidatos, o mtodo proposto atende ao requisito R7.

Papel: Analista de Servios

Artefato utilizado: Modelo de Processo to-be

Artefato gerado: Modelo de servios candidatos

 119

5.3.2 Anlise de Gap

A Anlise de Gap tem como objetivo comparar os servios candidatos identificados

com os recursos j existentes na infra-estrutura de TI da organizao e avaliar as
possibilidades de reuso (PAPAZOGLOU; VAN DEN HEUVEL, 2006). Para cada
operao candidata (pertencente a um servio candidato), deve-se verificar se j
existe algum servio ou aplicao de software legada que execute total ou
parcialmente sua funcionalidade. Para realizar esta busca, pode ser consultado um
repositrio de servios e recursos reusveis ou documentaes de aplicaes
existentes.

Assim, para cada operao analisada, pode-se identificar um dos seguintes cenrios
de reuso:

Operao realizada por um servio: A funcionalidade da operao avaliada j

est implementada por um servio existente no repositrio de servios da
organizao, que pode ento ser reusado.
Operao realizada parcialmente por um servio: A funcionalidade da
operao avaliada parcialmente realizada por um servio existente. O
servio pode ser reusado, mas ser necessrio alterar o servio existente ou
implementar uma mediao para utilizar o servio.
Operao realizada por uma aplicao legada: A funcionalidade da operao
avaliada j est implementada por uma aplicao legada. Para poder ser
usada pelo processo, esta funcionalidade dever ser encapsulada na forma
de um servio.
Operao realizada parcialmente por uma aplicao legada: A funcionalidade
da operao avaliada parcialmente realizada por uma aplicao legada.
Para poder ser usada pelo processo, esta funcionalidade dever ser
encapsulada na forma de um servio e dever ser implementado algum tipo
de lgica de mediao ou integrao.
Operao no existente: A funcionalidade da operao no existe em
nenhum recurso existente e deve, portanto, ser realizada por um novo servio
a ser criado ou por uma nova operao a ser criada para um servio
existente.
 120

O agrupamento das operaes candidatas em servios pode necessitar ser revisado

em vista do resultado da Anlise de Gap. Servios candidatos podem ser alterados
caso haja sobreposio com algum servio j existente. Por exemplo, uma operao
que j realizada por um servio existente passar a pertencer a ele. Ou ainda, uma
nova operao a ser criada pode pertencer ao mesmo contexto lgico de um servio
existente, sendo portanto acrescentada a ele.

Esta atividade busca atender ao requisito R3 ao considerar os recursos existentes

para a realizao das operaes dos servios candidatos. Por confrontar os servios
candidatos identificados de modo top-down com os recursos existentes levantados
de modo bottom-up, a atividade caracteriza uma abordagem meet-in-the-middle,
atendendo ao requisito R1. Juntamente com a atividade de Identificao de Servios
Candidatos, atende ao requisito R5 permitindo que servios sejam identificados a
partir de modelos de processos e aplicaes existentes.

Papel: Analista de Servios

Artefatos utilizados: Modelo de servios candidatos, Documentao de aplicaes

existentes

Artefato gerado: No aplicvel

5.3.3 Anlise de Realizao

Uma vez identificados os cenrios de reuso para cada operao candidata em

relao aos recursos existentes, devem ento ser analisadas as alternativas de
realizao possveis para cada uma delas e decidir qual ser adotada para realizar o
servio.

A Anlise de Realizao tem por objetivo avaliar as alternativas para realizao de

cada operao candidata em termos de viabilidade tcnica, custos, riscos tcnicos e
de projeto, esforo e retorno de investimento. Para cada cenrio de reuso
identificado, as seguintes consideraes devem ser feitas:

Operao realizada por um servio: No necessrio especificar o servio,

uma vez que ele poder ser utilizado diretamente pelo processo de negcio
sem a necessidade alterao ou integrao. Este o cenrio com menor
 121

risco de ser realizado, acarretando apenas no custo de reuso. o cenrio que

aumenta o retorno sobre o investimento j realizado anteriormente.
Operao realizada parcialmente por um servio: Neste cenrio, duas opes
devem ser analisadas. Pode-se alterar o servio existente, o que traz um risco
a ser considerado (impacto em outros processos e servios existentes), ou
implementar uma lgica de mediao para reusar o servio em seu estado
atual.
Operao realizada por uma aplicao legada: Este cenrio exige a criao
de um servio que encapsule a funcionalidade da aplicao legada. Para tal,
necessrio verificar a existncia de APIs ou adaptadores para acessar o
legado e, caso contrrio, avaliar a viabilidade e o custo de se implementar
este acesso.
Operao realizada parcialmente por uma aplicao legada: Este cenrio
levanta as mesmas questes que o cenrio anterior, mas tambm oferece a
possibilidade de se alterar o legado para corresponder operao candidata,
sendo necessria apenas a criao do servio encapsulador. Deve-se avaliar
se os custos e o risco tornariam esta alternativa vivel.
Operao no existente: Como a operao dever ser implementada a partir
do zero, o risco baixo, pois se tem controle sobre sua especificao e
realizao. O custo resume-se ao esforo necessrio para se especificar e
implementar a nova funcionalidade.

Para cada cenrio de reuso, ainda podem ser levantadas outras alternativas de
realizao especficas de cada caso analisado.

Aps a anlise de todas as operaes candidatas, o Analista de Servios deve

decidir se ser vivel a realizao dos servios candidatos conforme as
consideraes feitas. Para a tomada da deciso final, pode ser necessrio o apoio
do Gerente de Projeto, pois so avaliados aspectos como risco, custo e esforo, e
do Arquiteto Corporativo, pois pode haver alteraes em aplicaes e servios
existentes.

Caso seja definida uma alternativa de realizao vivel, o mtodo prossegue com a
especificao dos servios. Caso contrrio, os resultados da Anlise de Realizao
devem ser passados para o Analista de Processos para que a modelagem de
processo to-be seja revisada e as atividades de Anlise repetidas.
 122

Esta atividade busca atender ao requisito R6 ao oferecer diversos cenrios de

realizao de servios, dependendo da disponibilidade de recursos reusveis.

Papis: Analista de Servios, Gerente de Projeto, Arquiteto Corporativo

Artefatos utilizados: Modelo de servios candidatos, Documentao de aplicaes

existentes

Artefato gerado: No aplicvel

5.4 Atividades de Projeto

Definidos os servios, inicia-se a fase de Projeto de servios. O objetivo da fase de

Projeto criar especificaes de servios que satisfaam aos requisitos do negcio
e sejam aderentes aos princpios de orientao a servios (ERL, 2005). Como
produtos desta fase, temos a orquestrao dos servios e especificaes tcnicas
de servios que servem como base para a Construo.

5.4.1 Especificao de Servios

A primeira atividade de Projeto a Especificao de Servios, na qual as interfaces

dos servios sero definidas e suas operaes (ou sua lgica) sero especificadas.

Para cada servio candidato, devero ser definidas todas as suas operaes e as
mensagens de entrada e sada envolvidas em cada operao. Caso a tecnologia
utilizada seja Web Services, os formatos das mensagens podem ser definidos na
forma de esquemas XSD e as definies de interfaces, representadas na linguagem
WSDL, atendendo ao requisito R9.

Para cada servio, ser definido um artefato de Especificao de Servio, composto

por definio de interface, esquemas de dados de mensagens, especificao
funcional de cada operao e polticas de servio.

As mensagens de um servio sero definidas com base nas informaes

necessrias como entrada e sada de suas operaes e com base em modelos de
dados existentes. Deve-se procurar especificar mensagens padronizadas segundo
 123

um modelo de dados organizacional, para que uma mesma mensagem possa ser
utilizada em diversos servios.

Dependendo do cenrio, a elaborao da interface do servio pode ser realizada de

modo top-down, bottom-up ou meet-in-the-middle.

Operao realizada por um servio: Neste cenrio, o servio j existe e

possui interface definida, no sendo necessrio nenhum tipo de especificao
adicional.
Operao realizada parcialmente por um servio: Caso tenha se optado por
alterar o servio existente, pode ser necessrio alterar sua interface e/ou a
especificao funcional da operao a ser chamada. Caso seja utilizada uma
mediao, deve-se definir a interface que ser exposta por ela e especificar
sua lgica de integrao. Em ambos os casos, a especificao da interface
feita de modo top-down, sendo realizada a partir do servio candidato.
Operao realizada por uma aplicao legada: Neste cenrio, a interface
elaborada de maneira bottom-up, tendo suas mensagens e operaes
definidas a partir das caractersticas da aplicao legada sendo reusada.
Operao realizada parcialmente por uma aplicao legada: A interface pode
ser elaborada de modo bottom-up como no cenrio 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 especificao meet-in-the-middle.
Operao no existente: Neste cenrio, tanto a elaborao da interface
quanto da especificao funcional das operaes so elaboradas de modo
totalmente top-down.

As especificaes funcionais de cada operao 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 implementao. Podem-
se usar diagramas de atividades para detalhar a lgica do servio e diagramas de
seqncia ou de colaborao para representar as interaes com outros servios ou
aplicaes legadas. Por utilizarem casos de uso e diagramas da UML, os servios
especificados podem ser diretamente implementados utilizando tcnicas de
orientao a objetos e desenvolvimento baseado em componentes, atendendo ao
requisito R10.
 124

As polticas de servio especificam os requisitos no-funcionais relacionados com o

servio, como segurana, comportamento transacional e registro de auditoria, e
requisitos de nvel de servio, por meio de contratos de SLA. SLAs definiro os
requisitos de desempenho, confiabilidade e disponibilidade acordados entre
provedor e consumidor de servio. A documentao de especificaes de requisitos
no-funcionais visa suprir o requisito R4 de um mtodo orientado a servios.

Nesta atividade, o Projetista de Servios deve determinar tambm a qual camada

pertence cada um dos servios, dividindo-os entre a camada de servios de negcio
e a camada de servios de aplicao de acordo com seu nvel de granularidade.
Separam-se os servios com nvel alto e baixo de granularidade.

Os servios de negcio so aqueles com nvel mais alto de granularidade.

Geralmente, suas funes representam entidades do modelo de negcio ou tarefas
que podem ser mapeadas diretamente para um processo de negcio. Servios de
negcio podem ser compostos por servios de aplicao.

Os servios de aplicao possuem nvel mais baixo de granularidade e representam

funes de infra-estrutura ou funes de aplicaes legadas. Devem ser os mais
genricos possveis, no contendo lgica especfica de um processo ou domnio de
negcio, para que possam ser utilizados por diversos servios de negcio e de
orquestrao.

A classificao em camadas atende ao requisito R11.

Papel: Projetista de Servios

Artefato utilizado: Modelo de servios candidatos

Artefato gerado: Especificao de servio

5.4.2 Verificao dos Princpios

Nesta atividade, uma srie de verificaes realizada sobre as especificaes de

servios com o intuito de avaliar sua conformidade com os princpios de orientao a
servios e atender ao requisito R8.
 125

Para garantir a reusabilidade de um servio, deve-se verificar se no necessrio

adicionar operaes ou alterar as j existentes ou especificadas para que o servio
possa a vir a ser til em outro contexto que no o do processo de negcio sendo
desenvolvido (ERL, 2005). Mesmo que nem todas as operaes no venham a ser
implementadas em um primeiro momento, recomendvel que elas j estejam
especificadas para minimizar a necessidade de mudanas posteriores na interface
do servio.

Deve-se verificar se o nvel de granularidade do servio (a quantidade de lgica

encapsulada) est de acordo com a camada a que pertence e com nvel de
reusabilidade esperado. Servios de aplicao devem possuir nvel baixo de
granularidade, ou seja, devem ser genricos para que possam ter maior
reusabilidade. Servios de negcio podem ter nvel mais alto de granularidade, pois
tm necessidade menor de reusabilidade e devem poder ser utilizados diretamente
pelos servios de orquestrao.

Para se obter autonomia em um servio, deve-se garantir que a lgica encapsulada

auto-contida, isto , no possui dependncias com relao a outros servios ou
processos.

Deve-se verificar se o contrato (interface) do servio est abstraindo detalhes de

implementao, ocultando-os dos potenciais consumidores. O servio deve
funcionar como uma caixa-preta, expondo em seu contrato apenas as informaes
essenciais para que possa ser utilizado.

Para se garantir o baixo acoplamento dos servios, deve-se verificar se o contrato

do servio no est limitado por caractersticas especficas de um processo de
negcio ou de sua lgica e tecnologia de implementao. O contrato deve ser o mais
desacoplado possvel de elementos externos.

E para se garantir que os servios sejam independentes de estado, deve-se procurar

minimizar a quantidade de informao de estado armazenada pelo servio,
armazenando-a nas mensagens trocadas ou na lgica de orquestrao do processo
de negcio.

Papel: Arquiteto Corporativo

Artefato utilizado: Especificao de Servio

 126

Artefato gerado: No aplicvel

5.4.3 Reviso dos Servios

A verificao da aderncia aos princpios de orientao a servios pode demandar

alteraes nos servios especificados. Caso isto seja necessrio, executam-se
novamente alguns passos da atividade de Especificao de Servios para que os
contratos dos servios sejam reprojetados conforme necessrio para se adequar aos
princpios de orientao a servios.

Pode ser necessrio rever tambm a alocao dos servios nas camadas de
negcio e de aplicao, caso tenha havido alterao no escopo funcional ou na
granularidade dos servios.

Papel: Projetista de Servios

Artefato utilizado: Especificaes de Servio

Artefato gerado: No aplicvel

5.4.4 Orquestrao de Servios

Uma vez especificados os servios e suas interfaces WSDL, realizada a

orquestrao dos servios. Se o Modelo de Processo to-be estiver representado na
notao BPMN, ele pode ser convertido em um modelo na linguagem WS-BPEL.
Caso contrrio, a lgica de processo pode ser descrita manualmente em WS-BPEL
ou em outra linguagem. Tal lgica deve ser especificada de modo que as chamadas
dos servios sejam devidamente orquestradas com as interfaces de servios
definidas e revisadas.

O objetivo desta atividade definir a lgica de orquestrao necessria para

executar o processo, como manipulao de variveis de processo, gerenciamento
de informao de estado, tratamento de excees e compensao.

O processo orquestrado dever ser encapsulado por um servio da camada de

orquestrao composto por servios das camadas de negcio e aplicao. Por isto,
 127

dever ser descrito em sua prpria Especificao de Servio, que conter a lgica
de orquestrao definida.

Esta atividade atende aos requisitos R2 ao viabilizar a abordagem de BPM e R9 ao

utilizar o padro WS-BPEL.

Papel: Projetista de Servios

Artefatos utilizados: Modelo de Processo to-be, Especificaes de Servio

Artefato gerado: Especificao de Servio de orquestrao

5.5 Atividades de Construo

Aps a Anlise e o Projeto, o ciclo de vida prossegue com atividades de Construo

e posteriormente de Implantao. Na fase de Construo, so desempenhadas
atividades com o intuito de se obter os servios executveis devidamente integrados
e testados, prontos para serem implantados.

5.5.1 Implementao e Teste

As fases de Implementao e Teste so executadas por Desenvolvedores, que

recebero as especificaes dos servios e implementaro os Web Services e
componentes necessrios. A partir destas fases, pode ser seguido o ciclo tradicional
de desenvolvimento orientado a objetos e/ou baseado em componentes.

Papis: Desenvolvedor, Testador

Artefatos utilizados: Especificaes de Servio

Artefato gerado: Componentes de servio executveis

5.6 Papis

O Analista de Processo o responsvel pela elaborao dos modelos de processo

de negcio que sero implementados ou automatizados em um projeto. Este papel
 128

deve possuir conhecimentos sobre levantamento de requisitos, modelagem de

processos ou elaborao de casos de uso de negcio.

O Analista de Servios o papel que realiza a transio dos artefatos gerados pela
modelagem de negcio para uma soluo orientada a servios. Este papel exige
conhecimentos nos princpios de orientao a servios e anlise de sistemas.

O Projetista de Servios tem como funo principal criar as especificaes dos

servios a serem implementados, projetando suas interfaces e comportamento
funcional. Para tal, so necessrios conhecimentos em orientao a servios,
integrao de aplicaes e padres de projeto.

O Arquiteto Corporativo o responsvel pelo portflio de servios da organizao,

definindo uma arquitetura de referncia e padres a serem seguidos nos projetos.
Deve possuir conhecimentos em orientao a servios, governana, integrao e
arquitetura de aplicaes e padres de projeto.

O Gerente de Projeto o responsvel por conduzir o projeto, controlando aspectos

como escopo, prazo, custo e riscos.

Os papis de Desenvolvedor e Testador so os responsveis pela construo dos

servios especificados. O perfil necessrio para estes papis o mesmo de um
mtodo de desenvolvimento tradicional.

5.7 Artefatos

O Modelo de Processo as-is e o Modelo de Processo to-be correspondem,

respectivamente, representao do estado atual do negcio e dos requisitos da
soluo em uma notao como o BPMN. No mtodo, possvel utilizar um modelo
de casos de uso ao invs dos modelos de processo, ou mesmo as duas formas
associadas.

O Modelo de Servios utilizado para documentar o processo de anlise orientada

a servios, que d origem a um conjunto de servios identificados a partir de um
modelo de negcio, na forma de processo ou caso de uso. Ele preenchido ao
longo das seguintes atividades:

Identificao de Servios Candidatos

 129

Anlise de Gap
Anlise de Realizao

A Figura 5.2 apresenta os principais aspectos contidos no modelo de servios,

abstratamente, e o relacionamento entre eles e as atividades que os definem.

Figura 5.2: Modelo de Servios

A Especificao de Servio fornece a especificao estrutural e comportamental

de um servio. Esta especificao estabelece um contrato entre provedor e
consumidor do servio, alm de servir como documentao de referncia para o
desenvolvedor responsvel por implementar o servio. Contm a descrio da
interface do servio, a definio das mensagens de entrada e sada, a especificao
do comportamento de cada operao e os requisitos no-funcionais envolvidos,
alm de indicar a camada a que pertence o servio.

5.8 Anlise do Mtodo

Trata-se de um mtodo desenvolvido para ser de uso livre, satisfazendo ao requisito

R12 descrito anteriormente.

O mtodo foi elaborado de modo a conter atividades e orientaes que atendessem

a todos os requisitos de anlise e projeto orientados a servios levantados
anteriormente.
 130

Alm de atender aos requisitos, a definio do MAPOS procurou unificar as boas

prticas identificadas nos mtodos existentes.

Do mtodo de Papazoglou e Van Den Heuvel, o MAPOS tomou como referncia as

atividades de Anlise de Gap e Anlise de Realizao que tratavam do reuso de
recursos existentes.

Do RUP plugin for SOMA, foram usadas as prticas de identificao de servios a

partir de casos de uso e o artefato Modelo de Servios, alm da definio de alguns
papis que serviram como referncia para definir os papis do MAPOS.

O MAPOS baseou a atividade de Identificao de Servios Candidatos nas tcnicas

de identificao do mtodo de Erl. Ainda do mtodo de Erl, foi adotada a prtica de
verificao dos princpios de orientao a servios.

A incluso da atividade Orquestrao de Servios na fase de Projeto tomou como

referncia as atividades Especificao de Processos de Papazoglou e Van Den
Heuvel e Projeto de Processo de Negcio Orientado a Servios de Erl.

Por fim, a classificao de servios em camadas (na atividade Especificao de

Servios) foi baseada na anlise de granularidade de Marks e Bell e nas camadas
definidas por Erl.

Alm destas boas prticas, o MAPOS introduz o conceito de cenrios de reuso, que
permite orienta a identificao de oportunidades de reuso de recursos existentes a
tomada de decises de realizao.

O mtodo proposto contm recomendaes e prticas que o tornam compatvel com

BPM e a utilizao da tecnologia Web Services, mas no limitado a estas
abordagens. Tais prticas e recomendaes no so obrigatrias de modo a permitir
que o mtodo seja aplicado a cenrios sem BPM e com utilizao de outras
tecnologias de implementao.

5.9 Consideraes Finais

Neste Captulo 5, foi apresentada a proposta de mtodo elaborada por este trabalho
de pesquisa, o MAPOS. O MAPOS foi elaborado de modo a atender aos requisitos
 131

levantados no Captulo 4 e tomando como referncia os mtodos estudados no

Captulo 3.

O mtodo proposto emprega tcnicas e boas prticas utilizadas em cada um dos

mtodos estudados. Alm disso, foi definido de modo a ser compatvel com a
abordagem BPM e com a tecnologia Web Services, como parte dos mtodos
analisados. No entanto, sua aplicabilidade no deve ser restrita a projetos com
essas caractersticas.

Torna-se necessria ento a realizao de estudos de caso aplicando o mtodo no

intuito verificar sua aplicabilidade e avaliar a eficincia das boas prticas propostas.
 132

6 ESTUDOS DE CASO

Para avaliar o mtodo proposto e verificar o atendimento aos requisitos levantados,

foram realizados estudos de caso aplicando o mtodo em uma empresa de
consultoria denominada IVS, especializada na implantao de arquitetura SOA com
abordagem BPM utilizando ferramentas de software WebSphere da IBM.

O mtodo proposto foi aplicado em projetos envolvendo SOA e opcionalmente a

abordagem BPM, no qual um modelo de negcio elaborado para ento ser
automatizado na forma de uma soluo orientada a servios. O MAPOS foi aplicado
para, a partir do modelo de negcio, realizar a anlise e o projeto dos servios que
do apoio aos processos de negcio automatizados.

Tais estudos de caso levaram em conta os requisitos de negcio reais da

organizao, assim como a infra-estrutura existente de servios e aplicaes
legadas. Foi avaliado como o mtodo proposto trata esses aspectos de um projeto
orientado a servios.

Por meio destes estudos de caso foi possvel realizar uma anlise crtica do mtodo
proposto e avaliar sua aderncia aos requisitos de anlise e projeto orientados a
servios.

6.1 Caso Banco BES

6.1.1 Contexto do Estudo

O primeiro estudo de caso realizado consiste no projeto executado pela empresa

IVS no Banco BES.

O Banco BES, procurando suprir as necessidades de informao e o aumento da

demanda de seus servios e produtos, busca modernizar sua rea de TI adotando
novas prticas e tecnologias. O banco recentemente adotou a prtica da modelagem
de processos devido a exigncias internas e externas de conformidade e
necessidade de documentao das regras de negcio.
 133

H, portanto, um direcionamento para a cultura de gerenciamento de processos de

negcios (BPM), porm ainda no generalizado. Vale ressaltar que focado mais o
aspecto de modelagem, mesmo porque ainda no h infra-estrutura para suportar
outros aspectos do BPM, como simulao de processos, automao de fluxo de
trabalho e monitorao de processos.

Neste cenrio, surgiu no Banco BES um projeto para implantar uma infra-estrutura
de BPM apoiada por uma arquitetura SOA, automatizando processos atravs da
composio de servios integrados em um barramento (ESB). Com a adoo de
SOA e BPM, o Banco BES pretende obter maior reuso e flexibilidade, reduzindo
custos e ganhando mais velocidade nas idas/respostas ao mercado.

Para fornecer a soluo de SOA e BPM, o Banco BES selecionou as ferramentas da

IBM e algumas empresas de consultoria para executar o projeto de desenvolvimento
e implantao. As ferramentas selecionadas abrangiam desde o ambiente de
execuo de servios e processos de negcio at as ferramentas de Computer-
Aided Software Engineering (CASE) para o desenvolvimento e integrao de
aplicaes, passando por ferramentas de gerncia de requisitos e gerncia de
configurao.

Os objetivos deste projeto so:

Implantao das ferramentas.

Definio de um processo de desenvolvimento de software de acordo com a
nova arquitetura.
Desenvolvimento um projeto piloto.

Tal projeto foi executado pela IVS em conjunto com outras empresas de consultoria,
sendo cada consultoria responsvel por uma parte do escopo do projeto. A parte de
responsabilidade da IVS foi a implantao das ferramentas de SOA e BPM, a
definio do processo de desenvolvimento de software (em conjunto com a empresa
QSP).

As empresas IVS e QSP foram incumbidas de auxiliar o banco a definir o novo

Processo de Desenvolvimento de Software do Banco BES, baseado no arcabouo
do RUP. A QSP contribuiu com o conhecimento sobre o arcabouo e as disciplinas
do RUP, enquanto a IVS contribuiu com o conhecimento na abordagem BPM com
arquitetura SOA, definindo as atividades de Modelagem de Negcio (processos) e
 134

de Anlise e Projeto orientados a servios, contexto em que foi aplicado o MAPOS.

Ao Banco BES foi incumbida a definio da disciplina de Gerenciamento de
Projetos. Foi formada uma equipe com profissionais da IVS, da QSP e do Banco
BES com o intuito de combinar os materiais elaborados por cada uma em um
processo de desenvolvimento integrado para guiar o desenvolvimento de software
dentro do Banco BES seguindo a nova arquitetura corporativa, orientada a servios.

Com o propsito de validar o processo elaborado, as ferramentas implantadas e a

arquitetura proposta, o Banco BES organizou um projeto piloto. Neste projeto piloto,
profissionais do Banco BES seriam responsveis por executar as tarefas do
processo, seguindo a documentao publicada, apoiados pelos consultores da IVS e
da QSP. Neste contexto, o autor deste trabalho foi responsvel por acompanhar e
orientar a execuo das atividades de anlise e projeto e validar os artefatos
produzidos, de modo a documentar o estudo de caso. As atividades
correspondentes ao MAPOS foram realizadas no perodo de outubro a dezembro de
2008.

6.1.1.1 Empresas Envolvidas

A IVS uma empresa, especializada na prestao de servios de consultoria em

arquitetura SOA, abordagem BPM, integrao de sistemas e desenvolvimento de
software. Nas atividades descritas do projeto, foram alocados os seguintes recursos
humanos da IVS:

Um especialista em SOA (o autor deste trabalho), que atuou na definio do

processo de desenvolvimento e orientou a execuo do MAPOS.
Um analista de processos, que auxiliou os analistas do Banco BES durante as
atividades de modelagem de processo.
Um especialista nas ferramentas da plataforma de BPM, que apoiou a equipe
do Banco BES no uso das ferramentas.
Um gerente de projetos.

A QSP uma empresa que presta servios de fbrica de software, fbrica de testes,
consultoria em Engenharia de Software e implantao de metodologia e ferramentas
de desenvolvimento de software. Participaram as seguintes pessoas da QSP:
 135

Um especialista em metodologias de desenvolvimento de software e no RUP,

que atuou na definio do processo de desenvolvimento.
Trs especialistas nas ferramentas CASE, que implantaram as ferramentas e
apoiaram a equipe do Banco BES no seu uso.
Um gerente de projetos.

J o Banco BES contou com os seguintes recursos:

Dois analistas de processos, responsveis pela modelagem.

Dois arquitetos, que atuaram como Analistas de Servios, Projetistas de
Servios, Arquitetos Corporativos e realizaram atividades de implementao.
Dois desenvolvedores, que tambm realizaram atividades de implementao.

6.1.1.2 Ferramentas Utilizadas

O processo de desenvolvimento do Banco BES foi documentado com a ferramenta

Rational Method Composer da empresa IBM. A ferramenta permitiu tambm a
publicao do material produzido para a organizao.

Para a representao dos artefatos produzidos nas atividades de anlise e projeto,

foi utilizada a ferramenta de modelagem UML Rational Software Architect da IBM.

O IBM WebSphere Business Modeler foi a ferramenta usada para modelagem,

simulao e publicao de modelos de processo de negcio. A ferramenta suporta o
desenho dos diagramas de processos seguindo uma notao prpria ou a notao
BPMN e permite exportar o modelo de processo desenvolvido na linguagem WS-
BPEL.

Descries dos processos e dos requisitos foram documentadas na ferramenta de

gerenciamento de requisitos da IBM, o Rational RequisitePro.

Para implementar a orquestrao do processo em WS-BPEL, foi utilizado o IBM

WebSphere Integration Developer. Com o uso desta ferramenta, foi possvel
tambm integrar o processo aos servios e componentes desenvolvidos.
 136

Para os servios desenvolvidos em Java, foi utilizado o Rational Application

Developer da IBM, enquanto os servios em .NET foram implementados no
Microsoft Visual Studio.

O ambiente de execuo era composto por:

IBM WebSphere Process Server, para execuo dos processos de negcio

em WS-BPEL
IBM WebSphere Message Broker, como barramento de integrao (ESB)
JBoss Application Server, para execuo dos servios implementados em
Java
Microsoft Internet Information Services, para execuo dos servios
implementados em .NET

6.1.2 Aplicao do Mtodo

Esta seo relata a execuo de cada atividade do mtodo MAPOS, descrevendo os

produtos gerados.

6.1.2.1 Modelagem de Processo as-is e to-be

Esta tarefa teve como objetivo elaborar os modelos de processo de negcio, isto ,
representar na forma de uma notao o processo de negcio na sua forma atual (as-
is) e o processo futuro (to-be), contendo as mudanas propostas.

No projeto piloto, o processo de negcio escolhido para modelagem e automao foi

o processo Incluso de cliente pessoa fsica. Trata-se de um processo de pr-
cadastro de pessoas fsicas, pelo qual potenciais novos clientes devem passar para
abrir uma conta, obter um financiamento ou solicitar um carto de crdito.

O modelo de processo as-is foi levantado por meio de entrevistas com os usurios
de negcio e de aplicao de questionrios. Um consultor da IVS atuou junto a
profissionais do Banco BES, todos exercendo o papel de Analistas de Processo. O
diagrama do processo foi produzido utilizando-se o WebSphere Business Modeler.
 137

As necessidades dos usurios de negcio foram registradas na forma de requisitos,

utilizando-se o Rational RequisitePro.

Aps o levantamento do processo atual, foram detectados pontos de melhoria e

oportunidades de automao em algumas atividades. Desta maneira, foi proposto
um modelo de processo to-be, contendo as melhorias e tarefas automatizadas que
visaram o atendimento s necessidades de negcio levantadas. Para se chegar
verso final do modelo de processo to-be, foi novamente utilizado o WebSphere
Business Modeler para a criao do diagrama do processo e execuo de
simulaes. O diagrama do processo to-be pode ser visualizado na Figura 6.1.

Figura 6.1: Diagrama do processo "Incluir cliente pessoa fsica"

No processo desenvolvido, foi utilizado somente o formato de processos para a

modelagem de negcio, no sendo utilizada a abordagem de casos de uso de
 138

negcio. Sendo assim, o modelo de negcio era composto por: diagrama do

processo de negcio, documento de Especificao de Tarefas e descrio textual de
regras de negcio.

O documento de Especificao de Tarefas tem como propsito complementar o

diagrama do processo elaborado na ferramenta. Tal documento foi criado contendo
a descrio detalhada de cada tarefa do processo de Incluso de cliente pessoa
fsica. A descrio de cada tarefa continha as seguintes informaes:

Objetivo da tarefa.
Tipo da tarefa: tarefa totalmente automatizada ou tarefa que envolve
interao com o usurio.
Fluxo de trabalho da tarefa: Para descrever o fluxo de trabalho executado em
cada tarefa do processo, foi utilizada uma estrutura de passos, semelhante
descrio de um caso de uso.
Regras de negcio envolvidas na execuo da tarefa.
Fluxos de trabalho alternativos e de exceo.

O documento de Especificao de Tarefas, bem como os documentos das regras de

negcio, foi armazenado no Rational RequisitePro, de modo que cada tarefa e regra
de negcio pudessem ser referenciadas como requisitos. A Tabela 6.1 apresenta um
exemplo de especificao de tarefa criada durante esta modelagem.

Tabela 6.1: Especificao da tarefa Reagendar Visita

Tipo de informao Descrio

O objetivo dessa tarefa registrar o reagendamento da visita do cliente
agncia. Esse reagedamento necessrio, a partir do momento no
Objetivo
qual identificada alguma pendncia, o que impede a continuidade do
processo.
Tipo de tarefa Tarefa com interao humana
1. A tarefa iniciada quando identificado que h pendncias que
impedem a continuidade do processo
2. O ator informa dados de contato e data na qual o cliente pode
Fluxo de trabalho comparecer agncia [FE001] [FE002] [FA001]
3. O sistema apresenta a seguinte mensagem Formulrio enviado
com sucesso.
4. A tarefa finalizada
1. Caso a data informada no esteja em conformidade com a RNV29
Fluxo de exceo FE001
2. Sistema retorna ao passo 2 do fluxo de trabalho
1. Caso os dados de e-mail no sejam vlidos
Fluxo de exceo FE002 2. Caso os dados de telefone no sejam vlidos
3. Sistema retorna ao passo 2 do fluxo de trabalho
continua
 139

continuao
Tipo de informao Descrio
1. Caso o ator no informe o reagendamento da visita no prazo de um
dia aps a data previamente agendada
Fluxo alternativo FA001
2. Sistema prorroga a data do reagendamento automaticamente para
o prximo dia til
1. A qualquer momento, enquanto o processo est parado nessa
Fluxo alternativo FA002 tarefa aguardando o reagendamento, o gerente de agncia pode
informar que deseja encerrar o processo.

6.1.2.2 Identificao de Servios Candidatos

Aps a elaborao do modelo de processo to-be, composto pelo diagrama do

processo mais as descries das tarefas, foi iniciada a identificao de servios
candidatos. Esta atividade recebe como entrada o modelo de processo to-be e tem
como objetivo definir um conjunto inicial de servios, identificados a partir do
processo.

Esta atividade foi executada por um profissional do Banco BES designado como
Analista de Servios, suportado por um consultor da IVS e um da QSP, sendo o
consultor da IVS responsvel por auxiliar no processo de identificao e o da QSP,
responsvel por auxiliar no uso da ferramenta Rational Software Architect. O
Rational Software Architect foi utilizado para documentar os servios candidatos.

As operaes candidatas foram identificadas a partir da anlise do documento de

Especificao de Tarefas, seguindo a seqncia das tarefas determinada pelo
diagrama do processo. No texto de descrio de cada tarefa do processo, era
possvel separar os passos em passos executados pelo ator e passos
automatizados, ou seja, executados pelo sistema. Em alguns casos, a tarefa inteira
foi considerada uma operao candidata, enquanto em outros, apenas alguns
passos de uma tarefa foram considerados operaes candidatas. As operaes
identificadas nas tarefas do processo so listadas na Tabela 6.2.

Tabela 6.2: Operaes candidatas do processo "Incluso de cliente pessoa fsica"

Tarefa Operao Candidata

Validar nmero de CPF
Consultar CPF
Validar existncia do cliente
Consultar agncia
Preencher Dados Validar dados iniciais do cliente
Validar existncia do cliente
continua
 140

continuao
Tarefa Operao Candidata
Listar agncias
Consultar agncia
Preencher Dados Internet
Validar dados iniciais do cliente
Validar existncia do cliente
Pesquisar e-mail por grupo
Conferir Documentos
Enviar e-mail
Consultar Situao do CPF Validar situao do CPF
Gerar Pendncia Consultar documentos obrigatrios
Reagendar Visita Obter prximo dia til
Listar ocupaes
Listar tipos de cliente
Complementar Dados
Obter endereo a partir do CEP
Validar dados do cliente
Registrar Dados no SIC Gravar dados do cliente
Enviar Notificao Cliente Potencial Enviar e-mail

Operaes registradas usando a ferramenta Rational Software Architect, na forma

de uma classe OperacoesCandidatas, que pode ser vista na Figura 6.2.

Figura 6.2: Operaes candidatas identificadas

Aps a identificao, as operaes foram agrupadas em servios candidatos, que

por sua vez foram representados como interfaces em um diagrama de classes.

No entanto, para o Analista de Servios do Banco BES, houve dvida no momento

de definir o agrupamento das operaes candidatas em servios candidatos.
Segundo ele, na descrio do mtodo poderia haver diretrizes mais claras para o
agrupamento de operaes em servios.

Decidiu-se criar um servio com as operaes utilitrias chamado SvcCorporativo.

J as operaes relacionadas a cliente foram separadas em um servio
 141

SvcClientePF, com operaes de manipulao de informaes de clientes do tipo

pessoa fsica, e um servio InfraCliente, com operaes utilitrias comuns a todos
os tipos de cliente.

A Figura 6.3 mostra as interfaces modeladas para representar os servios

candidatos identificados.

Figura 6.3: Servios candidatos identificados

Como as operaes foram registradas como mtodos de uma classe, percebeu-se a

necessidade de se definirem neste momento os parmetros das operaes,
permitindo a identificao de algumas mensagens. Por exemplo, para a operao
consultarCliente do servio SvcCliente, definiu-se que um parmetro de entrada
da operao seria o nmero de CPF do cliente e o parmetro de sada (ou de
retorno) seria uma mensagem do tipo Cliente, contendo em seus atributos
informaes sobre o cliente consultado.

Desta maneira, decidiu-se registrar as mensagens utilizadas nas operaes de

servios na forma de classes com o esteretipo message. As classes de
mensagens documentadas foram definidas a partir dos objetos de negcio
modelados juntamente com o fluxo de trabalho do processo. A Figura 6.4 mostra
alguns exemplos de classes de mensagens definidas neste momento.
 142

Figura 6.4: Exemplos de classes de mensagens

Aps a definio dos servios candidatos, foram elaboradas as descries de cada

operao e servio, sendo que os textos descritivos foram registrados utilizando-se a
prpria ferramenta de modelagem UML, na seo de documentao das classes
candidatas.

6.1.2.3 Anlise de Gap

Aps a identificao dos servios candidatos, o mtodo prosseguiu com a Anlise de

Gap, quando se buscaram nas aplicaes existentes as funes necessrias para
os servios candidatos, chegando a um cenrio de reuso para cada operao
candidata. A atividade foi conduzida pelo Arquiteto Corporativo do Banco BES, que
por sua vez foi auxiliado pelo consultor da IVS.

Para analisar os cenrios de reuso, o mtodo orienta a consultar um repositrio de

servios e recursos reusveis ou fontes de documentao das aplicaes existentes.
Como o repositrio de servios ainda no estava implantado durante a execuo
desta atividade, foi necessrio recorrer documentao do legado, que era escassa
e se mostrou incompleta para a anlise de gap. Deste modo, foi necessrio contatar
 143

os analistas e desenvolvedores responsveis pelas aplicaes legadas para obter as

informaes necessrias para anlise.

Como resultado desta anlise, foram obtidos os seguintes apresentados na Tabela

6.3.

Tabela 6.3: Cenrios de reuso para operaes candidatas

Servio
Operao Candidata
Candidato
gravarDadosCliente
validarDadosCliente
SvcClientePF validarDadosIniciais
validarExistenciaCliente
validarSituacaoCPF
consultarAgencia
enviarEmail
listarAgencias
listarOcupacoes
SvcCorporativo
obterEnderecoCEP
obterProximoDiaUtil
pesquisarEmailGrupo
validarCPF
consultarDocumentosObrigatorios Operao no existente
InfraCliente
listarTiposCliente
Cenrio de Reuso
Operao realizada por aplicao legada
(componente GerenciadorPessoa do Sistema
de Informaes de Cliente implementado em
Java)
Operao no existente
Operao no existente
Operao realizada por aplicao legada
(componente GerenciadorPessoa do Sistema
de Informaes de Cliente implementado em
Java)
Operao no existente
Operao parcialmente realizada por aplicao
legada (dados existentes no sistema
Automao)
Operao realizada por aplicao legada (classe
Util da biblioteca Corporativo implementada em
.NET)
Operao parcialmente realizada por aplicao
legada (dados existentes no sistema
Automao)
Operao no existente
Operao realizada por aplicao legada
(componente GerenciadorEndereco do
Sistema de Informaes de Cliente
implementado em Java)
Operao realizada por aplicao legada (classe
RotDias da biblioteca Corporativo implementada
em .NET)
Operao no existente
Operao realizar por aplicao legada (classe
Util da biblioteca Corporativo implementada em
.NET)
Operao no existente

A lgica necessria para as operaes gravarDadosCliente e

validarExistenciaCliente do servio SvcClientePF j eram realizadas por uma
aplicao legada, neste caso um componente Java GerenciadorPessoa
 144

pertencente ao Sistema de Informaes de Clientes (SIC). O componente em

questo era um Enterprise Java Bean do tipo Session.

As classes utilitrias Util e RotDias da biblioteca corporativo, implementada em

.NET, continham as funes necessrias para as operaes enviarEmail,
validarCPF e obterProximoDiaUtil do servio SvcCorporativo.

J a funcionalidade da operao obterEnderecoCEP do servio SvcCorporativo

foi encontrada no componente Java GerenciadorEndereco do SIC.

Para as operaes consultarAgencia e listarAgencias do servio

SvcCorporativo, foi identificados os dados de agncia necessrios j existiam no
sistema Automao, mas no havia no sistema a lgica para buscar as informaes
necessrias.

Para retratar de modo mais claro este tipo de caso, notou-se que o MAPOS, ao
analisar o reuso de recursos existentes, poderia verificar separadamente a
existncia da lgica e dos dados necessrios para cada operao candidata. Para
esta operao, poderia ser considerado que os dados existissem, mas a lgica no.

Os cenrios de reuso analisados foram documentados na mesma ferramenta de

modelagem UML, na seo de documentao das classes candidatas, juntamente
com as descries das operaes.

6.1.2.4 Anlise de Realizao

Na Anlise de Realizao, cada operao candidata avaliada quanto ao seu

cenrio de reuso identificado anteriormente. Nesta etapa, deve ser decidido como
cada operao de servio ser realizada.

As possibilidades de realizao dos servios candidatos foram discutidas pelo

Analista de Servios responsvel pelas anlises, o consultor da IVS e os analistas
responsveis pelas aplicaes. As decises de realizao resultantes da anlise
foram registradas no diagrama de classes de servios. Para cada interface de
servio, foi indicada na forma de uma classe qual seria sua realizao.

Foram obtidas as seguintes decises de realizao.

 145

Servio SvcCliente

Como o GerenciadorEndereco pertencia ao mesmo sistema que o

GerenciadorPessoa, decidiu-se mover a operao obterEnderecoCEP do
servio SvcCorporativo para o servio SvcClientePF. Deste modo, seria
possvel manter as implementaes dos servios em plataformas separadas e
a coeso seria mantida, uma vez que as informaes de clientes possuam
relacionamento com informaes de endereo.

Para realizar este servio, seria ento criado o novo Web Service SvcCliente
em Java, que seria responsvel por acessar os Enterprise Java Beans
GerenciadorPessoa e GerenciadorEndereco do SIC e implementar as
funes das operaes no existentes. A plataforma Java permite a criao
deste Web Service sem a necessidade de adaptadores.

A realizao do servio SvcClientePF pode ser visualizada na Figura 6.5.

Figura 6.5: Realizao do servio "SvcClientePF"

Servio SvcCorporativo

Operaes implementadas por um novo Web Service SvcInfraestrutura na

plataforma .NET responsvel por encapsular as classes Util e RotDias e
 146

acessar os dados do sistema Automao. Como o arcabouo .NET tambm

possui suporte nativo a Web Services, no seria necessrio utilizar nenhuma
mediao ou adaptador.

A realizao do servio SvcCorporativo pode ser visualizada na Figura 6.6.

Figura 6.6: Realizao do servio "SvcCorporativo"

Servio InfraCliente

Como as operaes deste servio no existiam nas aplicaes legadas, seria

implementado um novo Web Service em Java que acessaria uma nova base
de dados e executaria a consulta de dados conforme lgica necessria.

A realizao do servio SvcCorporativo pode ser visualizada na Figura 6.7.

 147

Figura 6.7: Realizao do servio "InfraCliente"

6.1.2.5 Especificao de Servios

A atividade de especificao de servios tem como objetivo detalhar as classes de

mensagens e as interfaces de servios, inclusive com a descrio tcnica de cada
operao, para chegar aos artefatos que comporo o contrato do servio.

Durante esta atividade, um dos arquitetos do Banco BES atuou como Projetista de
Servios realizando necessrios ajustes e informaes adicionais nas classes, tais
como:

Especificao do tipo de dado de cada atributo das classes de mensagens.

Especificao do tipo de dados de cada parmetro de operao.
Seleo dos parmetros das operaes com base na lgica a ser
implementada.
Especificao de requisitos no-funcionais, como segurana (autenticao e
autorizao).

Uma vez especificadas as classes, foram gerados esquemas XSD e interfaces

WSDL, utilizando a ferramenta Rational Software Architect. A ferramenta possui uma
funo de transformao de classes em WSDL e XSD, sendo que as classes ou
interfaces com o esteretipo serviceSpecification so convertidas em interfaces
WSDL e classes com esteretipo message so convertidas em esquemas XSD.

O servio SvcClientePF foi classificado como pertencente camada de servios de

negcio por possuir maior granularidade e representar uma entidade de negcio,
enquanto SvcCorporativo e InfraCliente foram classificados como servios de
aplicao por proverem funes tcnicas de menor granularidade.
 148

6.1.2.6 Verificao dos Princpios

O objetivo desta atividade verificar se cada especificao de servio criada atende

aos princpios de orientao a servios e se esto adequados a integrarem o
portflio de servios da organizao.

A verificao dos princpios foi realizada em uma reunio envolvendo o Analista de

Servios responsvel por identificar e especificar os servios, o segundo arquiteto do
Banco BES atuando como Arquiteto Corporativo, o consultor da IVS e o gerente do
projeto do Banco BES.

A presena do gerente foi importante para obter o aval gerencial sobre as decises
de novas implementaes, que poderiam demandar um esforo alm do planejado
para o projeto.

Abaixo, so descritos os resultados obtidos da verificao de cada um dos servios

projetados.

Servio SvcCliente

A operao validarExistenciaCliente foi considerada como possuindo alto

potencial de reuso pelos Arquitetos, que citaram a existncia de diversos
processos de negcio que poderiam vir a utiliz-la. Entretanto, para tornar o
servio mais reusvel, foi recomendada a adio de outras operaes
interface, j existentes no componente GerenciadorPessoa encapsulado
pelo servio, como removerPessoa, obterPessoaPorNome,
consultarRiscoCliente, obterSituacaoCredito e alterarSituacaoCredito.

Decidiu-se que as operaes seriam especificadas na interface do servio,

mas que no seriam implementadas imediatamente no projeto piloto. As
atividades de implementao do projeto piloto teria como foco somente as
operaes necessrias para suportar o processo de negcio Incluso de
Cliente Pessoa Fsica.

O nvel de granularidade do servio foi considerado adequado. J a

autonomia do servio foi considerada um ponto de ateno, uma vez que os
componentes encapsulados pertencem a um sistema externo e possuem
relacionamentos com outros componentes.
 149

Servio SvcCorporativo

Este servio foi projetado desde o incio de forma a ser altamente reusvel,
com operaes utilitrias de baixa granularidade, aplicveis a diversos
contextos de negcio. Portanto, eventuais ajustes poderiam incluir apenas a
adio de novas operaes, j presentes nas classes encapsuladas Util e
RotDias.

Devido ao fato de os dados acessados por este servio pertencerem a uma

aplicao externa (Automao), a autonomia do servio poderia estar
comprometida. A recomendao foi analisar o relacionamento destes dados
com outros componentes do sistema para verificar possveis impactos com
relao autonomia.

Servio SvcAgencia

O servio foi considerado com nvel de granularidade adequado para reuso. A

avaliao do servio constatou sua autonomia, pois toda sua lgica estava
contida em um novo componente de servio, sem dependncia com outros
sistemas externos.

Alm da validao dos princpios, foi verificada a aderncia dos servios

especificados arquitetura de referncia definida para o Banco BES. A arquitetura
de referncia determina diversos padres a serem aplicados s novas aplicaes
desenvolvidas no banco, incluindo padres de nomenclatura e de projeto.

6.1.2.7 Reviso dos Servios

Na reviso, quaisquer no conformidades detectadas durante a verificao dos

princpios devem ser corrigidas nos artefatos que compem a especificao dos
servios.

A reviso consistiu apenas na realizao de ajustes nas interfaces de servios

especificadas, adicionando-se as operaes recomendadas durante a Verificao
dos Princpios. Esta atividade foi executada pelo Projetista de Servios do Banco
BES.
 150

6.1.2.8 Orquestrao de Servios

Durante a orquestrao de servios, o modelo de processo to-be elaborado no incio

do projeto convertido em um modelo de implementao, que deve ser trabalhado
para tratar todas as regras de negcio modeladas e adequar-se aos servios
especificados.

Para executar esta atividade, foi designado o Projetista de Servios do Banco BES,
auxiliado mais uma vez pelo consultor da IVS. Antes de ser exportado em formato
WS-BPEL, o modelo de processo criado na ferramenta WebSphere Business
Modeler passou por uma modelagem tcnica. A modelagem tcnica consistiu na
realizao de ajustes e adio de informaes necessrias para que o processo
pudesse ser convertido de maneira adequada para WS-BPEL. Aps os ajustes, o
processo foi exportado em formato WS-BPEL para a ferramenta de integrao de
processos WebSphere Integration Developer.

A partir da, foi realizada implementao do processo em WS-BPEL. Uma vez que a
estrutura principal do fluxo de trabalho e as variveis de processo j vieram prontas
da exportao, foi necessrio implementar no processo os seguintes aspectos:

Lgica de tratamento de dados

Lgica de deciso nos ns do tipo Choice (if-then-else) e nos loops do tipo
While
Dados de correlao de instncias de processo
Tempo de expirao de atividades com tal requisito
Mapeamento das interfaces geradas no WS-BPEL para as interfaces WSDL
dos servios utilizados pelo processo

Aps implementado, o processo em WS-BPEL foi encapsulado pelo servio de

orquestrao InclusaoClientePF. Para tal, foi necessrio tambm definir a interface
WSDL e as mensagens em XSD para o servio de orquestrao.
 151

6.1.2.9 Implementao e Teste

A partir da construo da lgica de orquestrao do processo em WS-BPEL, foram

conduzidas as atividades de implementao dos servios, integrao dos servios
ao processo e testes de todos os elementos desenvolvidos.

O estudo de caso no contemplou o acompanhamento de todas as atividades de

implementao, mas somente o incio da implementao dos servios, segundo as
definies de realizao especificadas durante a Anlise e Projeto.

Os testes foram especificados por um analista do Banco BES, com o auxlio de um

consultor da QSP. As especificaes abrangiam desde testes unitrios das
operaes dos servios at testes integrados dos vrios cenrios de negcio
possveis para o processo.

6.1.3 Resultados

A aplicao do mtodo no projeto piloto do Banco BES pde ser considerada bem-
sucedida, pois permitiu identificar, definir e implementar um conjunto de servios
seguindo uma seqncia lgica de atividades. At o fim do estudo de caso, a
soluo no havia sido implantada em ambiente de produo, mas encontrava-se
em fase de testes de homologao.

Durante a Anlise de Gap, observou-se que neste momento possvel identificar

novas operaes candidatas para os servios analisados. So operaes que
podem ser levantadas principalmente nas aplicaes legadas examinadas,
permitindo a identificao bottom-up de novas operaes para o servio. Pelo fato
de terem sido identificadas de modo bottom-up, baixa a probabilidade de estas
operaes serem utilizadas pelos processos de negcio ou casos de uso sendo
analisados. Entretanto, a identificao delas neste momento evitaria uma reviso
aps a Verificao dos Princpios, como de fato ocorreu no projeto piloto do Banco
BES.

Devido a mudanas ocorridas durante a execuo do projeto piloto, o mtodo foi

aplicado com diversas iteraes da fase de Anlise. Aps a execuo da Anlise de
 152

Realizao, apesar de as decises de realizao terem sido aprovadas, foi

necessrio voltar atividade de Modelagem de Processo to-be para efetuar
mudanas no modelo de processo de negcio, a pedido dos usurios de negcios.
Com isso, houve uma nova iterao das atividades Identificao de Servios
Candidatos, da Anlise de Gap e da Anlise de Realizao. Nesta nova iterao, o
modelo de processo alterado foi revisto para possivelmente identificar novas
operaes e servios candidatos e posteriormente analis-los. Pelo menos duas
mudanas deste tipo ocorreram durante a execuo do projeto, gerando novas
iteraes. Esta experincia durante o projeto piloto permitiu verificar a aplicabilidade
da abordagem iterativa da fase de Anlise do MAPOS. Originalmente, as iteraes
haviam sido propostas para resolver restries de realizao, porm constatou-se
que elas podem ser executadas para suportar mudanas nos requisitos de negcio.

Pela realizao do estudo de caso, verificou-se que a conduo do desenvolvimento

de uma soluo baseada em SOA e BPM torna-se eficiente com o uso de uma
plataforma integrada de ferramentas. Tal integrao facilitou a transio da fase de
Modelagem de Negcio e para a Anlise e a transio da fase de Projeto para a
Construo.

O estudo de caso permitiu constatar que possvel adaptar o MAPOS para aplic-lo
junto a um processo completo de desenvolvimento, como o RUP. No caso do Banco
BES, as atividades do MAPOS foram includas no incio do fluxo de trabalho da
disciplina de Anlise e Projeto, seguidas pelas atividades de anlise e projeto de
classes e componentes.

6.2 Caso NF-e

6.2.1 Contexto do Estudo

O Projeto Nota Fiscal eletrnica (NF-e) uma iniciativa da Secretaria da Receita

Federal brasileira em conjunto com as Secretarias da Fazenda estaduais, que visa
substituir o atual documento fiscal emitido em papel por um equivalente em formato
eletrnico. Segundo o projeto, a nota fiscal passa a ser um documento emitido e
armazenado digitalmente, que documenta uma operao de comercializao de
 153

mercadorias ou prestao de servios. Sua validade jurdica e fiscal obtida atravs

de um processo de assinatura digital do emitente e da Autorizao de Uso dada pela
Secretaria da Fazenda (ENCONTRO..., 2006).

O projeto NF-e prev a implantao, em cada Secretaria da Fazenda estadual, de

uma aplicao para gerenciar o ciclo de vida das notas fiscais eletrnicas, desde seu
recebimento a partir do contribuinte, passando por sua validao, armazenamento e
disponibilizao para consultas. Por sua vez, os contribuintes emissores de notas
fiscais devero ser capazes de acessar o sistema da Secretaria da Fazenda de seu
estado e enviar suas notas fiscais.

A arquitetura composta de um lado servidor e um lado cliente. O lado servidor,

implementado pela Secretaria da Fazenda de cada estado, deve disponibilizar
servios da forma de Web Services para que as empresas sejam capazes de
registrar suas notas fiscais eletrnicas. Os sistemas das Secretarias da Fazenda
devero disponibilizar os seguintes servios para os contribuintes:

Recepo de lote de NF-e

Consulta de processamento de lote
Cancelamento de NF-e
Inutilizao de numerao de NF-e
Consulta de situao atual de NF-e
Consulta do status do servio
Consulta cadastro de contribuintes

Os requisitos foram definidos pelo Encontro Nacional de Coordenadores e

Administradores Tributrios Estaduais (ENCAT), composto por membros das
Secretarias da Fazenda Estaduais e da Secretaria da Receita Federal, e publicados
no Manual de Integrao do Contribuinte (ENCONTRO..., 2006). Com base nos
requisitos deste manual, a IVS desenvolveu a aplicao que implementa o lado
servidor, de responsabilidade da Secretaria da Fazenda estadual. O Servidor NF-e
foi estruturado em servios integrados por uma ferramenta de ESB. Para atender a
suas necessidades decorrentes do Projeto NF-e, uma Secretaria da Fazenda
estadual, denominada SEFAZ, adquiriu o Servidor NF-e da IVS juntamente com a
ferramenta de ESB, que serviria de infra-estrutura para futuras solues orientadas a
servios.
 154

Os servios da aplicao original foram definidos sem o uso de um mtodo bem

definido, que garantisse a aderncia aos princpios de orientao a servios. Deste
modo, foi proposta a aplicao do MAPOS para realizar a reengenharia dos
servios. Para tal, dois profissionais foram treinados no MAPOS e responsabilizados
por aplicar o mtodo para identificar e especificar os servios que compem a
aplicao a partir de seus requisitos originais. Para garantir validade deste estudo de
caso, foram selecionados para executar o mtodo dois profissionais sem qualquer
conhecimento prvio sobre a verso original do Servidor NF-e. Deste modo, os
servios resultantes formariam um conjunto totalmente novo, definido somente de
acordo com os requisitos e com o mtodo aplicado. As atividades deste estudo de
caso foram executadas entre maro e abril de 2009.

6.2.1.1 Empresas Envolvidas

A IVS foi a empresa responsvel por desenvolver o Servidor NF-e e realizar a

posterior reviso de sua arquitetura. Nas atividades deste estudo de caso,
participaram os seguintes recursos humanos da IVS:

Um especialista em SOA (o autor deste trabalho), que orientou a execuo do

MAPOS e atuou como arquiteto corporativo.
Um analista de sistemas, que atuou como analista de processos e analista de
servios.
Um arquiteto de software, que atuou como analista de servios e projetista de
servios.

O cliente que adquiriu o Servidor NF-e da IVS foi a SEFAZ, uma Secretaria de
Fazenda estadual que buscava uma soluo para o Projeto NF-e e uma infra-
estrutura para iniciar a adoo de arquitetura orientada a servios.

6.2.1.2 Ferramentas Utilizadas

O Rational Method Composer da IBM foi empregado para documentar o mtodo e

disponibiliz-lo para os profissionais, tanto para treinamento quanto para referncia.
 155

Para edio de documentos de texto, como o Modelo de Servios, foi usado o

Microsoft Word.

O IBM Rational Software Architect foi utilizado para criar os documentos de

mensagens e de interface dos servios, bem como os diagramas UML que
representavam sua estrutura e comportamento.

O Enterprise Architect da Sparx Systems foi usado para modelar os processos na

notao BPMN e gerenciar os requisitos.

O ambiente de execuo do Servidor NF-e utilizado foi o IBM WebSphere Enterprise

Service Bus, ferramenta com as funes de barramento ESB e servidor de
aplicaes. Como IDE de desenvolvimento, foi usado o IBM WebSphere Integration
Developer.

6.2.2 Aplicao do Mtodo

Para redefinir os servios que compem o Servidor NF-e, os profissionais da IVS

empregaram o MAPOS.

6.2.2.1 Modelagem de Processo as-is e to-be

Esta tarefa teve como objetivo elaborar os modelos de processo de negcio, isto ,
representar na forma de uma notao o processo de negcio na sua forma atual (as-
is) e o processo futuro (to-be), contendo as mudanas propostas.

Os requisitos para o projeto NF-e esto definidos e documentados no Manual de

Integrao do Contribuinte, sendo que cada um dos servios a serem providos pela
Secretaria da Fazenda esto especificados com suas mensagens, interfaces e
comportamento funcional. O comportamento de cada servio est descrito na forma
de processo to-be ilustrado por um diagrama de atividade, exemplificado na Figura
6.8.
 156

Figura 6.8: Diagrama do processo Recepo de Lote de NF-e (ENCONTRO..., 2006)

Por possurem alta granularidade e j estarem modelados em uma notao de

processo, tais servios (Recepo de Lote de NF-e, Processamento de Lote de NF-
e, Retorno de Recepo de Lote de NF-e, Consulta de NF-e, Cancelamento de NF-
e, Inutilizao de Numerao de NF-e e Consulta de Status de Servio) foram
classificados como servios de orquestrao. Pertenceriam camada de servios de
orquestrao, sendo que cada um encapsularia a lgica de um processo de negcio.
O objetivo do estudo de caso seria ento a anlise e projeto dos servios de negcio
e de aplicao que comporiam os servios de orquestrao j definidos.

Como os processos to-be j estavam definidos, esta atividade consistiu somente na

criao dos diagramas em BPMN representando a lgica especificada na
documentao.
 157

6.2.2.2 Identificao de Servios Candidatos

Recebendo como entrada os modelos to-be dos processos de negcio

(encapsulados pelos servios de orquestrao), esta atividade teve como objetivo
identificar um conjunto inicial de servios candidatos de negcio e de aplicao.

Nesta atividade, tanto o analista de sistemas quanto o arquiteto de software atuaram

como analistas de servios, enquanto o autor deste trabalho forneceu orientaes
sobre o mtodo. Analisando-se a documentao de cada processo de negcio,
foram identificados os servios exibidos na Tabela 6.4.

Tabela 6.4: Operaes candidatas identificadas

Processo de Negcio Operao Candidata

Recepo de Lote de NF-e
Processamento de NF-e
Retorno de Recepo de Lote de NF-e
Cancelar NF-e
Identificar nmero de CNPJ do transmissor
Validar tamanho do lote
Gerar nmero de recibo para o lote
Obter tempo mdio de resposta
Gravar lote
Gerar recibo
Enviar lote para fila de entrada
Validar XML do lote
Validar assinatura e integridade de cada NF-e
Validar autorizao do emissor
Identificar nmero de CNPJ do emissor na assinatura
Validar dgito verificador do nmero de CNPJ
Validar dgito verificador do nmero de IE
Validar data de emisso de NF-e
Validar existncia de NF-e
Verificar regularidade fiscal do Emissor
Verificar regularidade fiscal do Destinatrio
Gravar NF-e
Criar protocolo de status
Enviar lote para fila de sada
Validar XML do recibo
Verificar existncia de lote na fila de sada
Verificar existncia de lote na fila de entrada
Validar XML do pedido de cancelamento de NF-e
Validar assinatura do cancelamento
Identificar nmero de CNPJ do emissor na assinatura
Validar autorizao do emissor
Verificar existncia de NF-e
Verificar existncia de autorizao de uso para NF-e
Verificar recebimento de NF-e pelo destinatrio
Verificar existncia de registro de trnsito para a NF-e
Verificar status da NF-e
Cancelar NF-e
Criar protocolo de status
continua
 158

Processo de Negcio
Inutilizar Numerao de NF-e
Consultar Dados da NF-e
Consultar Status do Servio
continuao
Operao Candidata
Validar XML do pedido de inutilizao
Validar assinatura da inutilizao
Identificar nmero de CNPJ do emissor na assinatura
Validar autorizao do emissor
Verificar regularidade fiscal do Emissor
Validar limite de faixa de inutilizao da NF-e
Verificar existncia de NF-e na numerao inutilizada
Efetivar inutilizao da numerao da NF-e
Criar protocolo de status
Validar XML do pedido de consulta de NF-e
Verificar existncia de NF-e
Validar XML do pedido de consulta de status
Consultar status do servio

Uma vez identificadas as operaes candidatas, foi realizado o agrupamento delas

em servios candidatos. As operaes candidatas foram agrupadas por similaridade
quanto ao tipo de lgica executada e quanto ao tipo de informao manipulada.
Durante o agrupamento, foi detectado que algumas operaes poderiam ser
eliminadas, uma vez que executavam a mesma lgica que outra operao
identificada. Por exemplo, contatou-se que as operaes Verificar regularidade
fiscal do Emissor e Verificar regularidade fiscal do Destinatrio executavam
exatamente o mesmo tipo de validao, no havendo diferena para emissores ou
destinatrios de NF-e. Portanto, foram substitudas por uma nica operao
chamada Verificar regularidade fiscal.

O resultado deste agrupamento pode ser visualizado na Tabela 6.5.

Tabela 6.5: Operaes candidatas agrupadas por servio candidato

Servio Candidato Operao Candidata

Validar tamanho do lote
Gerar nmero de recibo de lote
Lote Obter tempo mdio de resposta
Gravar lote
Gerar recibo
Validar XML do lote
Validar XML do recibo
Validar XML do pedido de cancelamento de NF-e
Validar XML
Validar XML do pedido de inutilizao
Validar XML do pedido de consulta de NF-e
Validar XML do pedido de consulta de servio
continua
 159

continuao
Servio Candidato Operao Candidata
Validar data de emisso da NF-e
Criar protocolo de status
Gravar NF-e
Verificar existncia de autorizao de uso para NF-e
Verificar recebimento de NF-e pelo destinatrio
Verificar existncia de registro de trnsito para a NF-e
Nota Fiscal
Verificar existncia de NF-e
Cancelar NF-e
Verificar status da NF-e
Verificar existncia de NF-e na numerao inutilizada
Validar limite de faixa de inutilizao da NF-e
Efetivar inutilizao da numerao da NF-e
Validar assinatura e integridade de cada NF-e
Validar assinatura do cancelamento
Assinatura
Validar assinatura da inutilizao
Identificar nmero de CNPJ do certificado
Autorizao Validar autorizao do emissor
Regularidade Fiscal Verificar Regularidade Fiscal
Validar Dgito Verificador do nmero de IE
IE/CNPJ
Validar Dgito Verificador do nmero de CNPJ
Verificar Status Consultar status do servio
Enviar lote para a fila de entrada
Enviar lote para a fila de sada
Fila
Verificar existncia de lote na fila de entrada
Verificar existncia de lote na fila de sada

Aps a definio do agrupamento, cada servio com suas operaes candidatas

foram descritos no documento de Modelo de Servios. Exemplos de descrio de
servio candidato e operao candidata podem ser vistos na Tabela 6.6 e na Tabela
6.7, respectivamente.

Tabela 6.6: Descrio do servio candidata "Regularidade Fiscal"

Tipo de Informao Descrio

Nome Regularidade Fiscal
Servio responsvel manter informaes sobre a regularidade fiscal dos
Descrio
contribuintes emissores e destinatrios de notas fiscais eletrnicas (NF-e).

Tabela 6.7: Descrio da operao candidata "Verificar Regularidade Fiscal"

Tipo de Informao Descrio

Nome Verificar Regularidade Fiscal
Verificao a situao de regularidade fiscal de um contribuinte, podendo
Descrio
consultar rgos responsveis.
Dados de Entrada Nmero de CNPJ do contribuinte a ser verificado
Indicador de situao fiscal vlida para o contribuinte com o nmero de
CNPJ informado, considerando o domnio a seguir:
Dados de Sada
True (caso regular)
False (caso irregular)
 160

6.2.2.3 Anlise de Gap

Aps a identificao dos servios candidatos, o mtodo prosseguiu com a anlise de

gap, quando se buscaram nas aplicaes existentes as funes necessrias para os
servios candidatos, chegando a um cenrio de reuso para cada operao
candidata.

Os profissionais foram responsveis por realizar a anlise baseada em informaes

fornecidas pelo autor a respeito da infra-estrutura existente na SEFAZ. Para no
comprometer o estudo de caso, no foi considerado o reuso de nenhum recurso
existente no Servidor NF-e, mas somente nos sistemas existentes na SEFAZ antes
do Projeto NF-e. A Tabela 6.8 exibe os servios em que foi possvel detectar
oportunidades de reuso nos recursos j existentes. Nos outros servios analisados,
o cenrio de reuso obtido foi Operao no existente.

Tabela 6.8: Cenrios de reuso para operaes candidatas

Servio
Operao Candidata
Candidato
Validar data de emisso da NF-e
Criar protocolo de status
Gravar NF-e
Verificar existncia de
autorizao de uso para NF-e
Verificar recebimento de NF-e
pelo destinatrio
Verificar existncia de registro de
trnsito para a NF-e
Nota Fiscal
Verificar existncia de NF-e
Cancelar NF-e
Verificar status da NF-e
Verificar existncia de NF-e na
numerao inutilizada
Validar limite de faixa de
inutilizao da NF-e
Efetivar inutilizao da
numerao da NF-e
Regularidade
Verificar Regularidade Fiscal
Fiscal
Validar Dgito Verificador do
Validar nmero de IE
IE/CNPJ Validar Dgito Verificador do
nmero de CNPJ
Cenrio de Reuso
Operao no existente
Operao no existente
Operao no existente
Operao no existente
Operao parcialmente realizada por aplicao
legada (Sistema de Trnsito de Mercadoria)
Operao realizada por aplicao legada
(Sistema de Trnsito de Mercadoria)
Operao no existente
Operao no existente
Operao no existente
Operao no existente
Operao no existente
Operao no existente
Operao realizada parcialmente pela aplicao
Cadastro de Contribuintes
Operao realizada por aplicao legada
(biblioteca Brazil Utils)
Operao realizada por aplicao legada
(biblioteca Brazil Utils)
 161

Para o servio Nota Fiscal, devido aos cenrios de reuso identificados, decidiu-se
separar as duas operaes realizadas pela aplicao legada Sistema de Trnsito de
Mercadoria (Verificar recebimento de NF-e pelo destinatrio e Verificar existncia
de registro de trnsito para a NF-e) em um novo servio chamado Registro de
Trnsito. Entendeu-se que as informaes sobre o trnsito de mercadorias so
independentes das informaes de notas fiscais, possibilitando a criao de servios
separados para lidar com cada tipo de informao. A separao foi realizada
tambm para facilitar as decises de realizao.

Os cenrios de reuso analisados foram documentados no Modelo de Servios,

assim como as alteraes no agrupamento dos servios candidatos.

6.2.2.4 Anlise de Realizao

Na anlise de realizao, cada operao candidata avaliada quanto ao seu cenrio

de reuso identificado anteriormente. Nesta etapa, deve ser decidido como cada
operao de servio ser realizada.

Nesta atividade, todos atuaram como analistas de servios e arquitetos corporativos,

discutindo as alternativas de realizao para os servios candidatos.

Para os servios candidatos com operaes no existentes, decidiu-se que seriam

realizados por componentes Java expostos na forma de Web Services executando
no servidor de aplicaes do WebSphere Enterprise Service Bus.

Para os outros servios, foram tomadas as seguintes decises de realizao:

Servio RegistroTransitoService

Os dados necessrios para as operaes deste servio j existiam no

Sistema de Trnsito de Mercadorias. Como o sistema implementado em
Java, optou-se por expor as funes correspondentes s operaes na forma
de Web Services.

Servio RegularidadeFiscalService

O sistema de Cadastro de Contribuintes implementado em tecnologia

proprietria sem suporte a Web Services. No entanto, como h na Secretaria
 162

da Fazenda a necessidade de expor outras funes deste sistema como

servios, alm da regularidade, optou-se por implementar um conector no
ESB que acessasse a base de dados do sistema para prover a operao.
Futuramente, esse conector poderia ser expandido para prover outras
operaes relacionadas.

Servio IECNPJService

A lgica necessria para as operaes deste servio j estava implementada

na biblioteca Java Brazil Utils. Portanto, decidiu-se por criar um novo Web
Service em Java que utilizasse a biblioteca para realizar as operaes.

As decises de realizao foram documentadas no Modelo de Servios.

6.2.2.5 Especificao de Servios

A atividade de especificao de servios tem como objetivo detalhar as classes de

mensagens e as interfaces de servios, inclusive com a descrio tcnica de cada
operao, para chegar aos artefatos que comporo o contrato do servio.

Os esquemas XSD e interfaces WSDL dos servios foram criados utilizando a

ferramenta Rational Software Architect. As mensagens e interfaces foram definidas
na forma de um modelo de classes, que foi ento convertido em documentos WSDL
e XSD.

A Figura 6.9 mostra alguns exemplos de interfaces de servio modeladas na

ferramenta.
 163

Figura 6.9: Exemplos de servios especificados

Os diagramas de classe foram complementados por descries textuais de cada

servios e de cada operao de servio. A descrio de cada operao detalhava a
lgica de processamento a ser executada por ela e descrevia os requisitos no-
funcionais aplicveis.

Os servios foram classificados de acordo com seu nvel de granularidade, sendo

separados nas camadas de servios de negcio e de servios de aplicao. A
alocao dos servios nas camadas pode ser resumida na Tabela 6.9.

Tabela 6.9: Alocao dos servios em camadas

Servio Camada
LoteService Servio de negcio
ValidacaoXMLService Servio de aplicao
NotaFiscalService Servio de negcio
RegistroTransitoService Servio de negcio
AssinaturaService Servio de aplicao
AutorizacaoEmissorService Servio de negcio
RegularidadeFiscalService Servio de negcio
IECNPJService Servio de aplicao
VerificarStatusService Servio de aplicao
FilaService Servio de aplicao
 164

Esta atividade foi realizada pelo arquiteto de software, que atuou como projetista de
servios.

6.2.2.6 Verificao dos Princpios

O objetivo desta atividade verificar se cada especificao de servio criada atende

aos princpios de orientao a servios e se esto adequados a integrarem o
portflio de servios da organizao.

Esta atividade foi realizada pelo arquiteto de software exercendo o papel de

Arquiteto Corporativo, orientado pelo autor deste trabalho.

A seguir so descritas recomendaes resultantes desta verificao.

Servio NotaFiscalService

Verificou-se que as operaes validarDuplicidadeNfe, validarExistenciaNfe

e obterStatusNfe possuam funes parecidas, sendo mantida apenas a
operao obterStatusNfe.

Servio ValidarXML

Este servio continha seis operaes de validao de XML, sendo um para

cada tipo de mensagem, que correspondiam s mensagens de entrada dos
servios de orquestrao do Projeto NF-e. Como esta caracterstica geraria
um acoplamento entre o servio ValidacaoXMLService e os servios de
orquestrao, decidiu-se criar uma nica operao genrica
validarXMLMensagem capaz de validar qualquer tipo de mensagem,
dependendo do parmetro passado. Alm de reduzir o acoplamento, tal
modificao aumentaria a reusabilidade do servio.

Servio AssinaturaService

Pelo mesmo motivo do servio ValidarXMLService, foi decidido substituir as

operaes de validao de assinatura para mensagens especficas
(validarAssinaturaNfe, validarAssinaturaCancelamento e
validarAssinaturaInutilizacao) por uma nica operao genrica
validarAssinaturaMensagem.
 165

Servio RegularidadeFiscalService

Para promover a reusabilidade deste servio, recomendou-se a alterao do

escopo funcional do servio para que ele passasse a validar a regularidade
fiscal tanto de pessoas jurdicas quanto de fsicas. Portanto, as operaes
deste servio passariam a ser verificarRegularidadeFiscalPJ e
verificarRegularidadeFiscalPF.

Servio IECNPJ

Para tornar o servio, mais reusvel decidiu-se acrescentar a operao

validarCPF, alterando seu nome para ValidarIdentificadorService.

6.2.2.7 Reviso dos Servios

Na reviso, quaisquer no conformidades detectadas durante a verificao dos

princpios devem ser corrigidas nos artefatos que compem a especificao dos
servios.

A reviso consistiu apenas na realizao de ajustes nas interfaces de servios

especificadas, adicionando-se ou alterando-se as operaes conforme determinado
durante a Verificao dos Princpios. Esta atividade foi executada pelo arquiteto de
software atuando como Projetista de Servios.

6.2.2.8 Orquestrao de Servios

Durante a orquestrao de servios, o modelo de processo to-be elaborado no incio

do projeto convertido em um modelo de implementao, que devem se trabalhado
para tratar todas as regras de negcio modeladas e adequar-se aos servios
especificados.

A lgica de orquestrao de servios j estava implementada na verso original do

Servidor NF-e em cdigo Java. Para o projeto de reengenharia de servios, seria
necessrio somente substituir as invocaes s antigas interfaces de servios por
 166

invocaes s novas interfaces modeladas. No entanto, o estudo de caso no

acompanhou a execuo desta atividade.

6.2.2.9 Implementao e Teste

A partir da construo da lgica de orquestrao de servios, devem ser conduzidas

as atividades de implementao dos servios, integrao dos servios e testes de
todos os elementos desenvolvidos.

Apesar de todas as especificaes de servios estarem definidas e revisadas, a

execuo destas atividades no foi provisionada at o fim da realizao deste
estudo de caso.

6.2.3 Resultados

Neste segundo estudo de caso, o mtodo mostrou-se eficaz ao guiar o procedimento

de identificao, anlise e especificao de servios. Por se tratar de um projeto de
reengenharia, foi possvel notar que a execuo do MAPOS resultou em um
conjunto de servios mais coeso e aderente aos princpios de orientao a servios
que os servios originais, que possuam nvel mais baixo de granularidade e menor
autonomia, sendo mais semelhantes a componentes.

Como os processos foram modelados em um nvel menor de granularidade, a

identificao de operaes candidatas deu-se de maneira bastante direta. Na
maioria dos casos, podia-se estabelecer uma relao de uma tarefa de processo
para uma operao de servio. Entretanto, nem todas as tarefas do processo
deveriam ser executadas por servios. Para resolver esta questo, foi constatado
que poderia haver no mtodo alguma verificao sobre as operaes candidatas
identificadas, de modo a descartar tarefas com nvel muito baixo de granularidade e
complexidade, principalmente no caso de regras de validao.

Mais uma vez, os participantes do estudo de caso manifestaram dvidas no

momento de agrupar as operaes candidatas em servios candidatos. Notou-se
que um dos profissionais realizou o agrupamento mais orientado a tarefas, enquanto
 167

o outro profissional procurou agrupar as operaes de acordo com as entidades de

dados manipuladas. Foram necessrias explicaes por parte do autor, em
complemento ao material de referncia.

6.3 Anlise dos Resultados

O fluxo de trabalho definido pelo mtodo mostrou ser uma seqncia lgica de
atividades eficiente como abordagem para anlise e projeto orientados a servios.
Foi possvel constatar que os passos a serem seguidos e a ordem proposta
permitem a obteno de um conjunto de especificaes de servios a partir de
modelos e requisitos de negcio.

Verificou-se que a abordagem iterativa proposta pelo mtodo durante a fase de

Anlise aplicvel. No caso de serem executadas vrias iteraes para atender a
novos requisitos e processos, aps a atividaxde de Anlise de Realizao, os
servios poderiam ser registrados em um repositrio com status em especificao,
por exemplo. Deste modo, na atividade de Anlise de Gap, os servios identificados
em iteraes anteriores seriam considerados como servios j existentes no portflio
da organizao que poderiam ser reusados.

A abordagem de cenrios de reuso, utilizada nas atividades de Anlise de Gap e

Anlise de Realizao, foi bem sucedida em seu propsito de guiar a identificao
de oportunidades de reuso e tomada de decises de como cada servio ser
realizado. Os cenrios de reuso propostos permitiram classificar as situaes
encontradas durante a Anlise de Gap, com uma nica ressalva da possibilidade de
separar cenrios de reuso para funcionalidade e dados de cada operao candidata.

Apesar de o fluxo de trabalho e definio das atividades estarem adequados, um

possvel ponto de melhoria seria um aprofundamento das diretrizes sobre como
identificar operaes candidatas, agrupar as operaes em servios candidatos e
verificar os princpios de orientao a servios. Foram estes os pontos em que os
participantes mostraram mais dvidas e em que foram necessrias mais orientaes
por parte do autor. Um fator que pode ser levado em conta que em ambos os
estudos de casos, os participantes estavam aplicando o mtodo pela primeira vez.
 168

No caso do Banco BES, os modelos de processo foram elaborados com um nvel

mais alto de granularidade e por isso tornou-se necessrio um detalhamento textual
das tarefas. Deste modo, as operaes candidatas poderiam ser identificadas a
partir do diagrama de processo e das descries textuais de cada tarefa.

Em nenhum dos dois estudos de caso realizados foi possvel realizar a identificao
a partir de casos de uso, porm o formato utilizado pelo Banco BES para descrever
as tarefas bastante semelhante a um fluxo de caso de uso. Sendo assim, pode-se
afirmar que a identificao de servios a partir de descries textuais (como um caso
de uso) foi exercitada no caso do Banco BES.

J no caso NF-e, os processos estavam definidos em um nvel mais baixo de

granularidade, o que permite um mapeamento mais direto das tarefas do processo
para operaes de servios.

Portanto, o mtodo mostra que pode ser aplicado mesmo em casos em que os
modelos de processo no chegam ao nvel de granularidade de chamadas de
servios. Nestes casos, uma das duas alternativas pode ser escolhida: decompor o
modelo de processo em tarefas de menor granularidade ou elaborar descries
textuais detalhadas de cada tarefa.

No caso do Banco BES, foi possvel constatar que a incluso de um ponto de

verificao no mtodo (a atividade de Verificao dos Princpios) pode funcionar
como um instrumento para assegurar a governana dos servios. Neste caso, alm
da validao dos princpios de orientao a servios, foi realizada uma validao da
aderncia dos servios aos padres e arquitetura de referncia da organizao.

Uma das caractersticas verificadas a aderncia do MAPOS abordagem BPM,

que foi verificada no caso do Banco BES. Este caso envolvia o projeto de uma
soluo completa de BPM com SOA. Entretanto, a aplicabilidade do mtodo no se
limitou a projetos desta natureza, pois foi verificada tambm em um projeto no
baseado na abordagem BPM, o caso NF-e.

Um resultado obtido foi a verificao de que o MAPOS aplicvel tanto em projetos

de desenvolvimento de novos servios e processos, como o caso do Banco BES,
quanto em projetos de reengenharia de servios, como o caso NF-e.

Uma situao no testada pelos estudos de caso foi a aplicao do mtodo sem a
presena do autor. Como as equipes envolvidas no possuam experincia em
 169

mtodos de anlise e projeto de servios e, no caso do Banco BES, no eram to

familiares com os conceitos de SOA, esta presena tornou-se necessria para a
conduo das atividades. No entanto, tal participao limitou-se a orientaes sobre
como executar as atividades, buscando no influenciar no conjunto de servios
resultantes.

6.4 Consideraes Finais

Os estudos de caso documentados neste Captulo 6 permitiram avaliar a

aplicabilidade do MAPOS em dois contextos distintos.

Os estudos de caso permitiram verificar a aplicabilidade do MAPOS em um projeto

de BPM com SOA e em um projeto de reengenharia de uma soluo contemplando
apenas orientao a servios.

De forma geral, o mtodo mostrou-se efetivo em seu propsito, orientando seus

usurios durante as etapas de anlise e projeto de servios.
 170

7 CONCLUSO

Este captulo contm as consideraes finais sobre o presente trabalho. So

apresentadas as contribuies geradas pelo trabalho e sugestes para trabalhos
futuros.

7.1 Contribuies do Trabalho

Este trabalho baseou-se em um estudo aprofundado sobre os conceitos

relacionados a SOA, focando em um dos principais desafios enfrentados pelas
organizaes na adoo da orientao a servios, que a complexidade da anlise
e projeto dos servios.

Um estudo de diversos mtodos propostos para resolver tal desafio foi realizado,
resultando em uma anlise crtica e comparativa das abordagens. Para cada
mtodo, foi apresentado seu posicionamento dentro de um ciclo de vida de
desenvolvimento e foram descritas suas atividades de anlise e projeto, papis e
artefatos. Este estudo permitiu identificar pontos em comum nos mtodos, as boas
prticas propostas em cada um e suas eventuais limitaes. Foi comparada tambm
a maneira como cada mtodo procura solucionar questes especficas de anlise e
projeto, como o reuso de recursos existentes e a aderncia aos princpios de
orientao a servios.

A anlise dos mtodos traz como contribuio uma viso sobre o estado da arte em
anlise e projeto orientados a servios. Mesmo mtodos propostos aps a
publicao deste trabalho poderiam ser analisados seguindo o mesmo formato
descrito e avaliando-se critrios semelhantes.

As boas prticas identificadas neste estudo serviram como base para definir um
conjunto de requisitos demandados pelo paradigma orientao a servios para as
atividades de anlise e projeto.

O conjunto de requisitos levantados no pode ser classificado como completo, isto ,

no h como afirmar que so os nicos requisitos necessrios para anlise e projeto
de servios. possvel que, se fossem analisados mais mtodos existentes,
 171

identificassem-se requisitos adicionais. No entanto, esse conjunto de requisitos pode

ser considerado uma contribuio vlida por estabelecerem parmetros para
comparar mtodos existentes e por terem guiado a elaborao de uma nova
proposta de mtodo.

A principal contribuio trazida pelo trabalho o mtodo proposto com base no

estudo dos conceitos de SOA e na anlise dos mtodos existentes, o Mtodo de
Anlise e Projeto Orientado a Servios (MAPOS). O MAPOS foi elaborado de modo
a unificar os mtodos analisados e atender ao conjunto de requisitos levantado.
Foram empregadas no mtodo proposto boas prticas derivadas de todos os
mtodos analisados, sendo elas integradas em um fluxo de trabalho nico.

A realizao de dois estudos de caso permitiu verificar a aplicabilidade do MAPOS

em projetos reais de contextos distintos. O mtodo foi aplicado em um projeto de
criao de uma nova soluo orientada a servios, com o uso da abordagem BPM, e
em um projeto de reengenharia de servios de uma soluo sem BPM. Em ambos
os projetos, foi empregada a tecnologia Web Services para especificar e
implementar os servios.

O MAPOS foi considerado eficiente como fluxo de trabalho para execuo de

anlise e projeto de servio, inclusive com a abordagem iterativa para as atividades
de anlise. Foi constatado apenas que poderiam haver mais diretrizes e orientaes
sobre como executar algumas atividades.

O mtodo proposto mostrou-se especialmente efetivo na anlise de reuso de

recursos existentes e na manuteno da governana de servios. Tais
caractersticas suportam dois pontos crticos da orientao a servios. Um deles a
reduo do custo de projetos e aumento da agilidade na entrega de solues,
obtidos pelo reuso. E o outro a necessidade de governana sobre o portflio de
servios da organizao, suprida pelas atividades de validao do mtodo.

7.2 Trabalhos Futuros

O mtodo proposto uma verso inicial de uma abordagem de anlise e projeto

orientados a servios. Possveis complementaes ao trabalho apresentado
poderiam ser trazidas no intuito de evoluir o mtodo.
 172

Trabalhos futuros poderiam envolver novas aplicaes do mtodo em diversos tipos

de cenrios e projetos. Por exemplo, o MAPOS poderia ser aplicado em projetos que
utilizassem somente casos de uso para a modelagem de negcio, projetos que
utilizassem outras tecnologias de implementao de servios alm de Web Services
ou projetos que utilizassem plataformas e ferramentas diferentes daquelas utilizadas
neste trabalho. Novos estudos de caso contribuiriam para obter uma verso mais
refinada e madura do MAPOS, inclusive adicionando novas orientaes sobre como
executar as atividades.

Melhorias ao mtodo proposto poderiam ser sugeridas com base na anlise de

outros mtodos de anlise e projeto orientados a servios que possam ter surgido
posteriormente elaborao deste trabalho. Este tipo de anlise poderia inclusive
dar origem a novos requisitos a serem atendidos pelo mtodo.

Outra possibilidade de trabalho futuro seria estender a definio do mtodo proposto

de forma a constituir um ciclo completo de desenvolvimento de servios, desde
concepo do projeto at a implantao e gerenciamento dos servios em produo.
 173

REFERNCIAS2

BIEBERSTEIN, N. et al. Service-Oriented Architecture Compass: Business Value,

Planning, and Enterprise Roadmap. Estados Unidos: IBM Press, 2005. 272 p. ISBN:
0131870025.

BRAY, T. et al. Extensible Markup Language (XML) 1.1, Second Edition. W3C
Recommendation, 2006. [acesso em 27 de maro de 2008]. Disponvel em: <
http://www.w3.org/TR/2006/REC-xml11-20060816/>

CHRISTENSEN, E. et al. Web Services Description Language (WSDL) 1.1. W3C

Note, 2001. [acesso em 1 de dezembro de 2008]. Disponvel em:
<http://www.w3.org/TR/wsdl>

COCKBURN, A. Writing Effective Use-Cases. Boston: Addison Wesley, 2000. 304 p.

ISBN: 0201702258.

ENCONTRO NACIONAL DE COORDENADORES E ADMINISTRADORES

TRIBUTRIOS ESTADUAIS. Projeto Nota Fiscal Eletrnica: Manual de Integrao
Contribuinte, verso 1.1.1. Brasil, 2006. [acesso em 6 de abril de 2009]. Disponvel
em: <http://www.nfe.fazenda.gov.br/portal/integracao.aspx>

ENDREI, M. et al. Patterns: Service-Oriented Architectures and Web Services.

Estados Unidos: IBM Redbooks, 2004. 348 p. ISBN: 073845317X.

ERL, T. Service-Oriented Architecture: Concepts, Technology and Design. Estados

Unidos: Prentice Hall, 2005. 792 p. ISBN: 0131858580.

ERL, T. SOA: Principles of Service Design. Estados Unidos: Prentice Hall, 2007. 608
p. ISBN: 0132344823.

FALLSIDE, D. C.; WALMSLEY, P. XML Schema Part 0: Primer, Second Edition.

W3C Recommendation, 2004. [acesso em 1 de dezembro de 2008]. Disponvel em:
<http://www.w3.org/TR/xmlschema-0/>.

2
De acordo com a International Organization for Standardization (ISO).
 174

FUGITA, H. S.; HIRAMA, K. MAPOS: Mtodo de Anlise e Projeto Orientado a

Servios. In Anais do Congresso Internacional de Gesto de Tecnologia e Sistemas
de Informao (CONTECSI), 5., So Paulo, 2008 (a).

FUGITA, H. S.; HIRAMA, K. Method for Service-Oriented Analysis and Design. In

Proceedings of the International Conference on Software Engineering Research and
Practice (SERP), Las Vegas, 2008. Las Vegas: CSREA Press, 2008 (b).

GORNIK, D. IBM Rational Unified Process: Best Practices for Software Development
Teams. IBM Whitepapers, 2003. [acesso em 27 de maio de 2007]. Disponvel em:
<ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/rup_bestpractice
s.pdf>

HUHNS, M. N.; SINGH, M. P. Service-Oriented Computing: Key Concepts and

Principles, IEEE Internet Computing, v. 9, no. 1, pp. 75-81, jan-fev. 2005.

IBM. Rational Method Composer, version 7.2. IBM Rational, 2007.

JESTON, J.; NELIS, J. Business Process Management: Practical Guidelines to

Successful Implementations (2nd Edition). Estados Unidos: Butterworth-Heinemann,
2008. 504 p. ISBN: 0750686561.

KEEN, M. et al. Patterns: SOA with an Enterprise Service Bus. Estados Unidos: IBM
Redbooks, 2005. 386 p. ISBN: 073849058X.

KENNEY, L. F.; PLUMMER, D. C. Magic Quadrant for Integrated SOA Governance

Technology Sets, 2007. Gartner RAS Core Research Note. Gartner, 2007.

KRAFZIG, D.; BANKE, K.; SLAMA, D. Enterprise SOA. Estados Unidos: Prentice
Hall, 2004. 408 p. ISBN: 0131465759.

KRUTCHEN, P. The Rational Unified Process: An Introduction (2nd Edition). Boston,

Estados Unidos: Addison Wesley, 2000. 272 p. ISBN: 0201707101.

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. ISBN: 0471768944.
 175

OASIS SOA REFERENCE MODEL TC. Reference Model for Service Oriented
Architecture 1.0. OASIS Open, 2006. 31 p.

OASIS WSBPEL TC. Web Services Business Process Execution Language, version
2.0. OASIS Open, 2007. [acesso em 1 de dezembro de 2008]. Disponvel em:
<http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html>

THE OPEN GROUP. Definition of SOA, version 1.1. The Open Group, 2006. [acesso
em 21 de agosto de 2007]. Disponvel em:
<http://opengroup.org/projects/soa/doc.tpl?gdid=10632>

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.
pp. 3-12.

PAPAZOGLOU, M. P.; VAN DEN HEUVEL, W. J. Service-Oriented Design and

Development Methodology. International Journal of Web Engineering and
Technology (IJWET), v. 2, no. 4, pp. 412-442, 2006.

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. pp. 75-80.

RUMBAUGH, J.; JACOBSON, I.; BOOCH, G. The Unified Modeling Language

Reference Manual (2nd Edition). Estados Unidos: Addison Wesley, 2004. 752 p.
ISBN: 0-32124562-8.

PERREY, R.; LYCETT, M. Service-Oriented Architecture. In Proceedings of the

Applications and the Internet Workshops, Uxbridge, 2003. pp. 116-119.

SHUJA, A. K.; KREBS, J. IBM Rational Unified Process Reference and Certification
Guide: Solution Designer. Estados Unidos: IBM Press, 2007. 307 p. ISBN:
0131562924.

ZIMMERMANN, O. et al. Analysis and Design Techniques for Service-Oriented

Development and Integration. Stuttgart: IBM Press, 2005.