Professional Documents
Culture Documents
SO PAULO
2009
HENRIQUE SHOITI FUGITA
SO PAULO
2009
FICHA CATALOGRFICA
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.
Fernando Pessoa
RESUMO
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.
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.
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
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.
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.
1.1 Motivao
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.
1.2 Objetivo
1.3 Justificativa
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.
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 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.
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.
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
Figura 2.2: Hierarquia de uma arquitetura SOA (PAPAZOGLOU; VAN DEN HEUVEL, 2006)
2.1.2 Erl
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
2.1.3 IBM
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
2.1.5 OASIS
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
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.2 Servio
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.
2.2.5 Contrato
2.2.6 Implementao
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.
2.2.7 Interface
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.
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).
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.
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).
2.3.4 Abstrao
2.3.6 Autonomia
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.
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).
estabelecer a comunicao entre aplicaes em uma arquitetura SOA, uma vez que
elas j estariam baseadas nos mesmos padres abertos de interao.
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
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.
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.
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.
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.
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.
3.1.4 Papis
3.1.5 Artefatos
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.
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.
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.
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.
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.
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.
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.
3.2.5 Artefatos
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.
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 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.
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
O ciclo de vida descrito pelo autor pode ser visualizado na Figura 3.8.
Este tipo de informao ser til para a identificao dos servios candidatos na
etapa de modelagem.
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
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.
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.
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.
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.
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.3 Papis
3.3.4 Artefatos
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.
3.4.1.1 Motivao
modo que, solucionando-se uma necessidade de TI, contribui-se para resolver uma
necessidade de negcio.
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
3.4.1.3 Modelagem
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.
3.4.1.4 Realizao
3.4.1.5 Gerenciamento
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
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.
sem considerar neste momento o atual ambiente fsico e tecnolgico. Tais aspectos
devem ser levados em conta em uma etapa posterior.
3.4.4 Papis
O mtodo descrito por Marks e Bell no identifica papis para a execuo das
atividades.
3.4.5 Artefatos
O RUP plugin for SOMA tambm possui esta caracterstica, pois procura alinhar os
servios aos requisitos de negcio e aos sistemas existentes.
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.
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.
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.
No RUP plugin for SOMA, uma anlise semelhante ocorre na atividade Decises de
Realizao, no entanto so considerados cenrios de integrao com aplicaes
existentes.
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
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.
com a fase e com o tipo de cada servio, diferentes conjuntos de princpios podem
ser validados.
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.
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.
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.
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.
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 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.
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.
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.
Assim, para cada operao analisada, pode-se identificar um dos seguintes cenrios
de reuso:
Para cada cenrio de reuso, ainda podem ser levantadas outras alternativas de
realizao especficas de cada caso analisado.
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
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.
um modelo de dados organizacional, para que uma mesma mensagem possa ser
utilizada em diversos 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.
dever ser descrito em sua prpria Especificao de Servio, que conter a lgica
de orquestrao definida.
5.6 Papis
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.
5.7 Artefatos
Anlise de Gap
Anlise de Realizao
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.
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
6 ESTUDOS DE CASO
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.
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.
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).
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
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.
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
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.
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.
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.
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
Servio
Operao Candidata Cenrio de Reuso
Candidato
Operao realizada por aplicao legada
(componente GerenciadorPessoa do Sistema
gravarDadosCliente
de Informaes de Cliente implementado em
Java)
validarDadosCliente Operao no existente
SvcClientePF validarDadosIniciais Operao no existente
validarExistenciaCliente Operao realizada por aplicao legada
(componente GerenciadorPessoa do Sistema
de Informaes de Cliente implementado em
Java)
validarSituacaoCPF Operao no existente
Operao parcialmente realizada por aplicao
consultarAgencia legada (dados existentes no sistema
Automao)
Operao realizada por aplicao legada (classe
enviarEmail Util da biblioteca Corporativo implementada em
.NET)
Operao parcialmente realizada por aplicao
listarAgencias legada (dados existentes no sistema
Automao)
listarOcupacoes Operao no existente
SvcCorporativo Operao realizada por aplicao legada
(componente GerenciadorEndereco do
obterEnderecoCEP
Sistema de Informaes de Cliente
implementado em Java)
Operao realizada por aplicao legada (classe
obterProximoDiaUtil RotDias da biblioteca Corporativo implementada
em .NET)
pesquisarEmailGrupo Operao no existente
Operao realizar por aplicao legada (classe
validarCPF Util da biblioteca Corporativo implementada em
.NET)
consultarDocumentosObrigatorios Operao no existente
InfraCliente
listarTiposCliente Operao no existente
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.
Servio SvcCliente
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.
Servio SvcCorporativo
Servio InfraCliente
Durante esta atividade, um dos arquitetos do Banco BES atuou como Projetista de
Servios realizando necessrios ajustes e informaes adicionais nas classes, tais
como:
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.
Servio SvcCliente
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.
Servio SvcAgencia
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:
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.
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.
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.
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.
continuao
Processo de Negcio Operao Candidata
Validar XML do pedido de inutilizao
Validar assinatura da inutilizao
Identificar nmero de CNPJ do emissor na assinatura
Validar autorizao do emissor
Inutilizar Numerao de NF-e 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
Consultar Dados da NF-e
Verificar existncia de NF-e
Validar XML do pedido de consulta de status
Consultar Status do Servio
Consultar status do servio
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
Servio
Operao Candidata Cenrio de Reuso
Candidato
Validar data de emisso da NF-e Operao no existente
Criar protocolo de status Operao no existente
Gravar NF-e Operao no existente
Verificar existncia de
Operao no existente
autorizao de uso para NF-e
Verificar recebimento de NF-e Operao parcialmente realizada por aplicao
pelo destinatrio legada (Sistema de Trnsito de Mercadoria)
Verificar existncia de registro de Operao realizada por aplicao legada
trnsito para a NF-e (Sistema de Trnsito de Mercadoria)
Nota Fiscal
Verificar existncia de NF-e Operao no existente
Cancelar NF-e Operao no existente
Verificar status da NF-e Operao no existente
Verificar existncia de NF-e na
Operao no existente
numerao inutilizada
Validar limite de faixa de
Operao no existente
inutilizao da NF-e
Efetivar inutilizao da
Operao no existente
numerao da NF-e
Regularidade Operao realizada parcialmente pela aplicao
Verificar Regularidade Fiscal
Fiscal Cadastro de Contribuintes
Validar Dgito Verificador do Operao realizada por aplicao legada
Validar nmero de IE (biblioteca Brazil Utils)
IE/CNPJ Validar Dgito Verificador do Operao realizada por aplicao legada
nmero de CNPJ (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.
Servio RegistroTransitoService
Servio RegularidadeFiscalService
Servio IECNPJService
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.
Servio NotaFiscalService
Servio ValidarXML
Servio AssinaturaService
Servio RegularidadeFiscalService
Servio IECNPJ
6.2.3 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.
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.
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.
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
7 CONCLUSO
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.
REFERNCIAS2
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/>
ERL, T. SOA: Principles of Service Design. Estados Unidos: Prentice Hall, 2007. 608
p. ISBN: 0132344823.
2
De acordo com a International Organization for Standardization (ISO).
174
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>
KEEN, M. et al. Patterns: SOA with an Enterprise Service Bus. Estados Unidos: IBM
Redbooks, 2005. 386 p. ISBN: 073849058X.
KRAFZIG, D.; BANKE, K.; SLAMA, D. Enterprise SOA. Estados Unidos: Prentice
Hall, 2004. 408 p. ISBN: 0131465759.
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>
SHUJA, A. K.; KREBS, J. IBM Rational Unified Process Reference and Certification
Guide: Solution Designer. Estados Unidos: IBM Press, 2007. 307 p. ISBN:
0131562924.