UNIVERSIDADE SALVADOR - UNIFACS

PROGRAMA DE PS-GRADUAO EM SISTEMAS E

COMPUTAO
MESTRADO PROFISSIONAL EM SISTEMAS E COMPUTAO

RAIMUNDO ARAUJO DE ALMEIDA JUNIOR

INTEGRAO DE SISTEMAS EM EMPRESAS

CORPORATIVAS DO SETOR PBLICO: UM ESTUDO DE
CASO NA SECRETARIA DE EDUCAO DO ESTADO DA BAHIA

Salvador
2009

RAIMUNDO ARAUJO DE ALMEIDA JUNIOR

INTEGRAO DE SISTEMAS EM EMPRESAS

CORPORATIVAS DO SETOR PBLICO: UM ESTUDO DE
CASO NA SECRETARIA DE EDUCAO DO ESTADO DA BAHIA

Dissertao apresentada ao Curso de

Mestrado Profissional em Sistemas e
Computao, Universidade Salvador UNIFACS, como requisito parcial para
obteno do grau de Mestre.
Orientadora: Prof Dr Las do Nascimento
Salvador.

Salvador
2009

FICHA CATALOGRFICA
(Elaborada pelo Sistema de Bibliotecas da Universidade Salvador - UNIFACS)

Almeida Junior, Raimundo Araujo de

Integrao de sistemas em empresas corporativas do setor
pblico: um estudo de caso na Secretaria de Educao do
Estado da Bahia/ Raimundo Araujo de Almeida Junior. - 2009.
98 f. : il.
Dissertao (Mestrado) - Universidade Salvador
UNIFACS.Mestrado em Sistemas de Computao, 2007.
Orientadora: Prof. Dr. Las do Nascimento Salvador.
1. Arquitetura de redes de computadores. I. Salvador, Las
do Nascimento, orient. II. Ttulo.
CDD: 004.65

INTEGRAO DE SISTEMAS EM EMPRESAS

CORPORATIVAS DO SETOR PBLICO: UM ESTUDO DE
CASO NA SECRETARIA DE EDUCAO DO ESTADO DA BAHIA

Dissertao de Mestrado apresentada ao programa de Ps-graduao da

Universidade Salvador - UNIFACS como requisito parcial para a obteno do ttulo
de Mestre em Sistemas e Computao.

Las do Nascimento Salvador Orientadora ________________________

Doutorado em Engenharia Eltrica, pela Poli/USP
Universidade Salvador - UNIFACS

Jos Maria Nazar David ____________________________

Doutorado em Engenharia de Sistemas e Computao pela UFRJ
Universidade Salvador - UNIFACS
Vaninha Vieira dos Santos ______________________________
Doutorado em Cincias da Computao pela UFPE
Universidade Federal da Bahia - UFBA

30 de setembro de 2009.

Por mais que na batalha se vena a um ou

mais inimigos, a vitria sobre a si mesmo a
maior de todas as vitrias.
Sakyamuni

AGRADECIMENTOS
Em primeiro lugar, eu agradeo a Deus por fazer parte da minha vida e viabilizar a
concluso deste trabalho. Em segundo lugar, agradeo aos meus pais que sempre
deram uma enorme fora durante a caminhada rdua para a concepo desde
estudo. E terceiro, a todos os meus familiares e amigos que colaboraram
diretamente ou indiretamente.
Aos colegas de trabalho que colaboram muito para a escolha dos servios a serem
expostos com base da arquitetura proposta.
Agradeo muito a minha orientadora, Prof Dr Las do Nascimento Salvador, que
teve muita pacincia nas idas e vindas durante as correes do trabalho. Tenho que
agradecer tambm, todos os professores que durante as aulas, tiveram sua parte de
colaborao. Vale tambm ressaltar a importante colaborao do coordenador do
curso, Prof. Dr. Jos Augusto Suruagy Monteiro, e os demais funcionrios da
UNIFACS.

RESUMO
Ao longo do tempo, as organizaes pblicas vm gradativamente fazendo uso da
Tecnologia da Informao (TI), informatizando os servios prestados comunidade.
Atualmente, a TI corresponde a um dos principais pilares das organizaes pblicas.
Com o intuito de melhor prover, controlar e flexibilizar a informao, a integrao
entre os diversos sistemas e/ou arquiteturas diferentes uma das grandes
prioridades organizacionais. Alm disso, para as instituies pblicas, ou at mesmo
privadas, a integrao entre Sistemas de Informao (SI), vem tornando-se um dos
grandes desafios em virtude dos legados que se encontram em produo utilizando
tecnologias e/ou arquiteturas que permitem baixssima taxa de reuso. A organizao
que foi utilizada como base para esse estudo, Secretaria da Educao do Estado da
Bahia (SEC) vem, com o passar dos anos, informatizando seus servios. Porm,
esse processo foi gradativo e, inicialmente, descentralizado, resultando em um
ambiente computacional corporativo muito heterogneo. muito comum encontrar
em instituies como a utilizada neste trabalho o uso conjunto de diversos sistemas
com problemas de integrao e de integridade das informaes. Na atual situao
da SEC, a atualizao e incluso de novos sistemas e tecnologias uma constante,
tornando vital a integrao dos novos sistemas com legado existente, seja,
compartilhando dados, processos ou funcionalidades/requisitos. Por isso, esse
trabalho vem propor uma soluo/padro para o desenvolvimento de novos
sistemas, viabilizando a integrao com os legados, aplicando a componentizao
dos requisitos, atravs da Arquitetura Orientada a Servios (SOA - Service Oriented
Architecture).
Palavras-chave: Arquitetura Legada. Integrao. Arquitetura Orientada a Servios.
Web Service.

ABSTRACT
Over time, public organizations are increasingly making use of Information
Technology (IT), computerizing services to the community. Today, TI is one of the
main pillars of public organizations. As the aim of providing better, more flexible and
control the information, the integration between different systems and / or different
architectures is a major organizational priorities. In addition, for public institutions, or
even private, the integration of Information Systems (IS), has become a major
challenge because of the legacy that is in production technologies and / or
architectures that allow low rate for reuse. The organization was used as the basis
for this study, the Education Department of the State of Bahia (SEC) has over the
years its computer services. However, this process was gradual and, initially,
decentralized, resulting in a very heterogeneous enterprise computing environment.
It is very common to find in institutions such as used in this study the combined use
of various systems with problems of integration and integrity of information. In the
current situation of the SEC, the update and inclusion of new systems and
technologies is a constant, making it vital to integrate the new systems with existing
legacy, either, sharing data, processes or functions / requirements. Therefore, this
work proposes a solution / standard for the development of new systems, allowing
integration with legacy componentization of applying the requirements, through a
Services Oriented Architecture (SOA - Service Oriented Architecture).
Keywords: Legacy Architecture. Integration. Service Oriented Architecture. Web
Service.

LISTA DE FIGURAS
Figura 1 Exemplo de Acoplamento fraco e forte. ..................................... 20
Figura 2 Principais elementos de um WSDL. ............................................ 22
Figura 3 Utilizao dos protocolos SOAP, WSDL e UDDI......................... 25
Figura 4 Exemplo da forma de uma mensagem SOAP. ........................... 25
Figura 5 Princpio bsico da SOA. ............................................................ 26
Figura 6 Sistema composto por legos. ................................................... 27
Figura 7 Conexo dos componentes atravs do ESB. ............................. 30
Figura 8 Conexo entre componentes. .................................................... 38
Figura 9 Processo de Desenvolvimento de Sistemas. ............................. 48
Figura 10 Aplicaes Legadas na SEC. ................................................... 49
Figura 11 Reuso dos componentes pelas aplicaes. ............................. 52
Figura 12 Viso Geral. .............................................................................. 54
Figura 13 Localizao de servio. ............................................................ 55
Figura 14 Arquitetura de uma nova aplicao. ......................................... 57
Figura 15 Arquitetura das aplicaes Legadas. ....................................... 58
Figura 16 Aplicaes Ligadas pelos servios. .......................................... 59
Figura 17 Flexibilidade do protocolo SOAP. ............................................. 60
Figura 18 Barramento de servio proposto. ............................................. 61
Figura 19 Interao das aplicaes com os componentes. ...................... 66
Figura 20 O diagrama de classes de Unidade Geogrfica. ...................... 67
Figura 20b O diagrama de classes de Pessoa. ........................................ 69
Figura 21 Relao do G-SEC com Unidade Geogrfica e Pessoa. ......... 70
Figura 22 Parte dos casos de uso do projeto Contratos e Convnios. ..... 71
Figura 23 Entidade de Contratos e Convnios destacada em relao ao

servio Unidade Geogrfica. ....................................................................... 72

Figura 23b Entidade de Contratos e Convnios destacada em relao
ao servio Pessoa. ...................................................................................... 72
Figura 24 Parte dos casos de uso do projeto Almoxarifado do servio
Pessoa. ....................................................................................................... 74
Figura 24b Parte dos casos de uso do projeto Almoxarifado do servio
Unidade Geogrfica. .................................................................................... 74
Figura 25 Entidades de Almoxarifado em relao ao servio
Unidade Geogrfica. .................................................................................... 75
Figura 25b Entidades de Almoxarifado em relao ao servio
Pessoa. ....................................................................................................... 75
Figura 26 Caso de uso do Gesto TOPA x Servio Exposto. .................. 76
Figura 27 Entidade do Gesto TOPA X Servio Unidade Geogrfica. ..... 77
Figura 28 - Casos de usos do SIAT X Servio Pessoa. .............................. 78
Figura 28b - Casos de usos do SIAT X Servio Unidade Geogrfica. ........ 79
Figura 29 - Entidade do SIAT X Servio Unidade Geogrfica. .................... 80
Figura 30 - Comparativo entre as aplicaes com base nas horas trabalhadas. 81
Figura 31 - Antes e depois da implantao dos servios. ........................... 81

SUMRIO

INTRODUO ................................................................................................... 14
1.1

HISTRICO E PROBLEMA.......................................................................... 14

1.2

MOTIVAO ................................................................................................ 16

1.3

OBJETIVO .................................................................................................... 17

1.4

ORGANIZAO ........................................................................................... 17

ARQUITETURA ORIENTADA A SERVIOS .................................................... 18

2.1

ACOPLAMENTO FRACO ............................................................................. 19

2.2

WEB SERVICE ............................................................................................. 20

2.3

WEBSERVICE DESCRIPTION LANGUAGE................................................ 21

2.4

UNIVERSAL DISCOVERY, DESCRIPTION AND INTEGRATION ............... 23

2.5

SIMPLE OBJECT ACCESS PROTOCOL ..................................................... 24

2.6

DEFININDO SOA ......................................................................................... 26

2.6.1

Servio ................................................................................................ 28

2.6.2

Barramento de Servios Corporativos ............................................. 29

2.6.3

Relao entre WS e SOA ................................................................... 30

2.6.4

Integrao de Aplicaes Corporativas com SOA .......................... 31

2.6.5

Segurana na SOA ............................................................................. 32

2.6.6

Vantagens x Desvantagens da SOA ................................................. 35

2.7

TENDNCIAS DE MERCADO PARA SERVIOS ....................................... 36

2.8

TRABALHOS RELACIONADOS ................................................................... 39

2.8.1

Migrao de sistemas legados para SOA ........................................ 39

2.8.2

Encapsulando sistemas legados para reuso em SOA .................... 40

2.8.3
Uma arquitetura para gerao de servios a partir de um sistemas
legados de forma intrusiva .............................................................................. 41
2.8.4
3

Sistemas legados e SOA Solues comerciais ............................ 42

UMA ARQUITETURA PARA INTEGRAO DE SISTEMAS ........................... 44

3.1

A SECRETARIA DA EDUCAO DO ESTADO DA BAHIA......................... 44

3.2

ARQUITETURA LEGADA............................................................................. 48

3.3

ENTERPRISE APPLICATION INTEGRATION (EAI) .................................... 50

3.4

DESENVOLVIMENTO ORIENTADO A COMPONENTES ........................... 50

3.5

FATOR MOTIVACIONAL.............................................................................. 52

3.6

DETALHES DA ARQUITETURA PARA INTEGRAO DE SISTEMAS ...... 53

3.6.1

Servios Expostos atravs de Web Services .................................. 54

3.6.2

Aplicaes Novas............................................................................... 55

3.6.3

Aplicaes Legadas ........................................................................... 57

3.6.4

Protocolos utilizados ......................................................................... 58

3.6.5

Barramento de Servios Corporativos ............................................. 59

3.6.6

Segurana na Arquitetura Proposta ................................................. 60

3.6.7

Gerenciamento de mudanas ........................................................... 61

3.6.8

Mapeamento dos requisitos .............................................................. 62

CASES NA ORGANIZAO ............................................................................. 63

4.1

IMPLEMENTAO DA ARQUITETURA ...................................................... 63

4.2

CASES E SERVIOS ................................................................................... 64

4.2.1

Unidade Geogrfica ........................................................................... 65

4.2.2

Pessoa................................................................................................. 67

4.2.3

G-SEC .................................................................................................. 67

4.2.4

Contratos e Convnios ...................................................................... 69

4.2.5

Almoxarifado ...................................................................................... 72

4.2.6

Gesto TOPA ...................................................................................... 75

4.2.7

SIAT ..................................................................................................... 77

4.3
5

ANLISE DOS RESULTADOS ..................................................................... 81

CONCLUSO ..................................................................................................... 83
5.1

O PROBLEMA .............................................................................................. 83

5.2

A SOLUO ................................................................................................. 84

5.3

DIFICULDADES DE IMPLANTAO DA ARQUITETURA .......................... 85

5.4

IMPLANTAO GRADATIVA DA SOA ........................................................ 85

5.5

VANTAGENS E DESVANTAGENS DE SOA ............................................... 86

5.6

TRABALHOS FUTUROS .............................................................................. 86

APNDICE A Cdigos dos Servios ................................................................... 92

14

CAPTULO 1
1 INTRODUO
As tecnologias voltadas para software e hardware so alvos de um forte
processo evolutivo, proporcionando ao mercado diferentes maneiras e opes de
processar informaes e arquitetar novos modelos de negcios. De forma geral,
esse mercado o grande beneficirio com esse processo evolutivo. Ele tambm o
responsvel por impulsionar a indstria a desenvolver novas tecnologias. A
organizao que foi estudada para construir este trabalho vivenciou este mesmo
processo evolutivo, no qual ser detalhado na prxima seo.

1.1 HISTRICO E PROBLEMA

Com o passar do tempo, a Secretaria da Educao do Estado da Bahia (SEC)
foi percebendo o importante papel da informatizao de seus servios. No decorrer
deste perodo a revoluo tecnolgica mudou muito os paradigmas de gesto
empresarial. A acelerao, inovao e automao dos processos, associada com a
velocidade das informaes so fatores que esto impulsionando essa revoluo.
Com isso, surgiram diversas arquiteturas e tecnologias dentro da instituio
estudada neste trabalho.
Na dcada de 80, surgiram os sistemas utilizando mainframe, computadores
de grande porte, dedicado normalmente ao processamento de um volume grande de
informaes. Eles tm a capacidade de oferecer servios de processamento a
muitos usurios atravs de milhares de terminais atravs de uma rede ou
conectados diretamente (FONTANETTE, 2005). Nesse perodo a organizao
apenas fazia uso desse tipo de aplicao.
Em seguida, veio a arquitetura Cliente-Servidor Desktop, onde nela fica bem
clara a diviso em duas camadas, ou seja, duas aplicaes se comunicando atravs
de uma rede. Uma camada o servidor na qual so processadas as requisies
feitas pela outra camada, que so os clientes. Geralmente, eles possuem algumas
regras de negcio (BECKER, 2002, p. 8). As aplicaes clientes e os servidores so

15

executveis que rodam na memria. Nessa arquitetura foram utilizadas as

linguagens Visual Basic e Delphi para o desenvolvimento dos sistemas, sem seguir
qualquer padro. Com isso, a diversidade de arquitetura dos legados foi surgindo e o
problema de integrao das informaes comeou

a aparecer. A produo de

software era feita por equipes distintas e sem ocorrer a devida comunicao entre
elas.
Logo em seguida, surgiu o desenvolvimento voltado para WEB, onde seu
funcionamento semelhante arquitetura Cliente-Servior Desktop, porm, a sua
diferenciao diz respeito ao fato de que no existe uma aplicao na memria do
cliente e sim um interpretador das requisies respondidas pelo servidor, atravs do
protocolo hypertext transmission protocol (HTTP) (CUMMINS, 2002, p. 156). No
desenvolvimento das aplicaes voltadas para essa arquitetura foram utilizados o
ASP 2.0 nativo e a combinao deste com Microsoft Transacion Server (MTS). Com
isso, podemos perceber o inicio no desenvolvimento baseado em componentes,
porm, sem padronizao e com muito pouco reuso. Dentro dessa diversidade,
surgiu o embrio da padronizao no desenvolvimento de sistemas que se tornar o
futuro Processo de Desenvolvimento de Sistemas (PDS), que ser detralhado mais
adiante.
Recentemente, optamos por utilizar a Arquitetura Orientada por Modelos
Model Driven Architecture (MDA). Segundo Maia (2006) e Gomes e outros autores
(2006) MDA uma proposta que enfatiza a transformao entre os modelos
Computacional Independent Model (CIM), ou Modelo Independente de Computao
(MIC), Platform Independent Model (PIM), ou Modelo Independente de Plataforma
(MIP) e Platform Specific Model (PSM), ou Modelo para Plataforma Especfica (MPE)
representados atravs da Unified Modeling Language (UML). Essa experincia no
foi muito bem sucedida. A equipe de desenvolvimento teve srios problemas de
produtividade durante a experincia com MDA, por isso, optamos por abortar a
utilizao dela sem a implantao de qualquer aplicao com o uso dessa
arquitetura.

Nesse

perodo,

tinhamos

as

equipes

de

desenvolvimento

centralizadas e com a devida comunicao entre elas.

Hoje, a SEC adotou uma arquitetura voltada para o desenvolvimento em
vrias camadas utilizando a tecnologia Jboss Seam (FARLEY, 2008) com a

16

definio e o planejamento adequado de cada componente baseado nas regras de

negcio da organizao. O Jboss Seam gestor da integrao entre os
frameworks responsveis pelas camadas de apresentao, negcio e persistncia
(FARLEY, 2008; TAIT, 2001;

PACHECO, 2000). Com isso, os arquitetos de

software da SEC ficam mais focados nas integraes das informaes referentes s
regras de negcio e no nos frameworks das camadas de integrao, entre as
camadas desta arquitetura. Todos os sistemas que so produzidos atualmente
seguem essa aquitetura e um processo de desenvolvimento denominado Processo
de Desenvolvimento de Sistemas (PDS), que foi concebido com base no Melhoria de
Processo do Software Brasileiro (MPS-BR), Capability Maturity Model Integration
(CMMI) e Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos
(PMBOK) com as equipes trabalhando de forma centralizada.
Como podemos observar, no decorrer do tempo, a organizao estudada
passou por diversas arquiteturas de sofwares. Como isso, os softwares legados
passaram a ser um grande problema no mbito da integridade das informaes.
Muitas vezes, para prover uma informao concisa necessrio um dispendioso
trabalho.
A convivncia dos sistemas novos que esto surgindo com o parque dos
legados muitas vezes de custo muito alto, porque em muitos casos existem
redundncia das informaes e uma grande dificuldade para integrar os dados
existentes com os novos. Esse quadro acaba acarretando um maior tempo de
desenvolvimento das novas aplicaes, maior custo durante a execuo do projeto,
alto grau de divergncia do planejado para o executado e um nivel elevado de
manutenibilidade.

1.2 MOTIVAO
A SEC vem sofrendo com um forte processo evolutivo das tecnologias. Com o
passar do tempo, Ela passou a conviver com muitas arquiteturas de software bem
heterogeneas, fragilizando a informao fornecida pela instituio. Com passar do
tempo essas arquiteturas legadas esto se tornando muito complexas e robustas
dificultado a manuteno das mesmas.

17

As aplicaes com compe os legados atuais de software da SEC foram

construidas de forma independente e isolada, ou seja, as aplicaes eram
idealizadas sem a preocupao do reuso da informao produzida, resultando em
alguns casos em redundncia no controlada. Porm, ao mesmo tempo e aspecto a
organizao necessita fornecer respostas geis e disponibilizar informaes
consistente para a sociedade, seu cliente. Por isso, h uma forte necessidade de
integrao entre as diversas aplicaes legadas. A motivao para elaborar este
trabalho surgiu para atender essa necessidade de integrao entre as diversas
arquiteturas heterogneas.

1.3 OBJETIVO
A evoluo dos processos e negcios das organizaes, privadas ou
pblicas, requer uma evoluo das suas aplicaes legadas, mas nem sempre
existe essa possibilidade. Isso em virtude da baixa qualidade desses softwares
conforme dito por Fontanette (2005, p. 70). A instituio estudada, Secretaria da
Educao do Estado da Bahia (SEC), sofre desse mal.
Para oferecer melhor qualidade nas informaes educacionais para a
comunidade do Estado da Bahia, atravs dos sistemas desenvolvidos pela
instituio estudada, que nasceu o fator motivacional com o intuito de propor uma
soluo que melhor atenda a esse tipo de problema. Portanto, este trabalho tem
como objetivo propor uma arquitetura de software para melhorar o quadro atual de
integrao das informaes entre as aplicaes novas que sero construdas e os
legados atravs da Arquitetura Orientada a Servios, bem como, propiciar a troca de
informaes entre as organizaes, utilizando-se da mesma arquitetura proposta por
este trabalho.

1.4 ORGANIZAO
O presente trabalho possui cinco capitulos. O segundo mostra a Arquitetura
Orientada a Servios (SOA). No terceiro apresentada a arquitetura proposta para
melhorar a integrao entre os sistemas. No quarto so apresentados os cases com
o uso da arquitetura proposta por este trabalho. E para fechar este estudo as
consideres finais e os trabalhos futuros.

18

CAPTULO 2
2 ARQUITETURA ORIENTADA A SERVIOS
Os sistemas de informao, com o passar do tempo, vm crescendo
exponencialmente, as organizaes vm projetando arquiteturas gradativamente
muito mais robustas e complexas, onde as respostas a serem dadas pela instituio
devem ser geis em relao evoluo dos negcios da mesma, procurando reduzir
gradativamente seus custos e ao mesmo tempo integrar nos processos de negcio
que iro surgir.
Segundo Santos Junior (2007, p. 55) e Larentis (2007, p. 59) o surgimento da
Arquitetura Orientada a Servio (SOA) dada pelo processo evolutivo da tecnologia
de software e hardware. A alta capacidade e o grande poder de processamento dos
dados, aliados velocidade com que as informaes so intercambiadas, o alto
grau de padronizao dos protocolos, a abrangente infra-estrutura disponibilizada
com o advento, principalmente, da internet que propiciou um momento para a
difuso dos conceitos e prticas da arquitetura SOA.
A SOA um novo paradigma de desenvolvimento de aplicaes cujo objetivo
criar mdulos funcionais chamados de servios, com baixo acoplamento e
permitindo a reutilizao de cdigo. Essa arquitetura vem se tornando muito
difundida, em virtude das possibilidades de arquitetar e desenvolver novas
aplicaes e processo de negcios, reaproveitando principalmente cdigos
existentes e plataformas heterogneas, como tambm estratgias proporcionadas
pela arquitetura.
Segundo Santos Junior (2007, p. 62) e Larentis (2007, p. 75) a SOA tem
como seu foco prover e consumir servios, principalmente expor servios para
aplicaes web.
No decorer deste captulo sero abordados os principais conceitos que a SOA
utiliza para fazer uso de sua arquitetura. Acoplamento fraco, Web Service,
Webservice Description Language (WSDL), Universal Discovery Description and
Integration (UDDI), Servios, Barramento de Servios Corporativos e Simple Object
Acess Protocol (SOA) sero detalhados mais a frente.

19

2.1 ACOPLAMENTO FRACO

O acoplamento fraco ou Loose coupling tem como objetivo a reduo da
interdependncia e possveis riscos de conflitos entre as entidades. Existe uma
crescente tendncia de projetar interfaces provedoras de servios com esse tipo de
acoplamento. A razo de projetar interfaces com o mnimo de acoplamento possvel
(Loose coupling) viabilizar maior flexibilidade, podendo adicionar e modificar as
interfaces com um mnimo ou nenhum impacto na interoperabilidade entre as
interfaces j existentes, como foi dito por (COSTA; CARVALHO, 2007).
Com o advento da Internet, que caracterizada por ser uma rede muito
grande de computadores que so conectados uns aos outros, atravs de protocolos
de comunicao e transmisso de dados comuns. Atravs da Internet surgiram
condies

para

surgimento

de

padres

verdadeiramente

abertos

para

interoperabilidade de computadores em ambientes distribudos. Com isso,

fortalecendo o uso do conceito de acoplamento fraco nas aplicaes da internet
atravs de padres abertos.
Segundo Sampaio (2006, p. 42) o grau de acoplamento entre dois mdulos
ou aplicaes tambm determina o grau de dificuldade de manutenibilidade dos
mesmos. A Figura 1 ilustra a diferena entre um acoplamento forte e um franco.
Caso o acoplamento seja alto, mudanas em um dos mdulos, onde existe um
acoplamento entre eles, pode afetar o outro tambm. Isto indica o grau de
manuteno do sistema no qual os mdulos so envolvidos. Estes graus de
acoplamento so classificados da seguinte forma: Dados ocorre quando dois
mdulos se comunicam apenas por meio dos parmetros trocados. Imagem
quando dois ou mais mdulos compartilham uma determinada rea comum.
Controle pssimo e ocorre quando um mdulo controla a lgica do outro.
Comum semelhante ao de imagem, porm todos compartilham a mesma rea de
dados. Contedo no muito adequado, porque est ligado ao uso de desvios
incondicionais.
Com o passar do tempo, vrias tentativas foram feitas para resolver os
problemas da computao distribuda e orientada a objetos, mas falharam devido
falta de suporte entre os grandes fornecedores da indstria de TI e a preponderncia

20

de padres proprietrios que permeavam esses esforos, com isso, facilitando o

aumento de acoplamento entre as diversas aplicaes dentro e fora das
organizaes. A rede aberta da Internet e a necessidade de propiciar a reduo dos
acoplamentos entre os mdulos das aplicaes corporativas propiciou o surgimento
dos Web Services, que so componentes de software capazes de se comunicar uns
com os outros sobre diversas redes utilizando padres abertos aceitos
universalmente e no proprietrio. A concordncia dos grandes players da indstria
de TI em adotar os padres de web services (ser mais detalhado no item a seguir)
emergentes criou condies para a revoluo na computao, conforme dito por
Pulier; Taylor; Gaffney (2008, p. 23).

Figura 1 Exemplo de Acoplamento fraco e forte

2.2 WEB SERVICE

A evoluo tecnolgica viabilizou para as instituies, pblicas ou privadas, a
possibilidade de enxergar seus sistemas de forma componentizada com os quais se
podem integrar e interagir em um processo estruturado e organizado. Por exemplo,
possvel criar softwares que possibilitam iniciar um processo estruturado de validar
a transao em outra organizao, planejar a entrega dos bens e ter um suporte
ps-venda interno. Os Web Services (WS) so caracterizados por um conjunto
estruturado de definies para a integrao de diferentes tecnologias, viabilizando a
componentizao dos processos de negcio da organizao, desde o nvel dos
sistemas corporativos, at aos processos organizacionais. Segundo Martins (2005,

21

p. 27) os WS compatibilizam as diversas tecnologias e suas solues no

integrveis, utilizando formatos comuns de trocas de informao atravs de um
padro aberto, o Extensible Markup Language (XML), e aplicando regras de
interao. Atravs disso, possvel evitar um retrabalho de desenvolvimento
obtendo a sua reutilizao e a respectiva integrao.
Um Web Service um aplicativo Servidor que disponibiliza um ou mais servios
para seus clientes, de maneira fracamente acoplada. Geralmente, o protocolo de
troca de mensagem o SOAP. Ele expe sua interface para os usurios usando um
documento XML, conhecido como Web Services Description Language (WSDL).
Com o uso de um WSDL podemos descobrir quais so os tipos de dados, formatos
de mensagens e servios que esto disponveis atravs de um Web Service. Os
clientes das aplicaes que consomem os servios expostos atravs de Web
Services podem procurar um determinado servio de duas maneiras distintas:
quando eles tm acesso direto ao WSDL e nesse documento definido como ser
criado o Web Services, ou utilizando o servio via interface Universal Discovery
Description and Integration (UDDI), conforme descrito em (SAMPAIO, 2006, p. 47).

2.3 WEBSERVICE DESCRIPTION LANGUAGE

WebService Description Language (WSDL) um padro baseado em XML
para descrever os servios expostos e a localizao dos mtodos do WebService.
Ele funciona como um tipo de TypeLibrary do Web Service, ou seja, uma biblioteca
das interfaces do WS. Ele tambm pode ser usado para a validao das chamadas
dos mtodos. Na figura 2 so ilustrados os principais elementos que compem o
WSDL.
O WSDL um documento XML, projetado de acordo com os padres
especificados pela W3C, que descreve exatamente como um determinado Web
Services funciona. Um documento WSDL muito mais do que um mero manual de
instrues de como se deve utilizar um determinado Web Services. Aplicaes de
software que criam Web Services podem processar o documento WSDL e gerar as
mensagens Simple Object Access Protocol (SOAP) necessrias para invocar um
servio especfico automaticamente (PULIER; TAYLOR; GAFFNEY, 2008, p. 58).

22

Figura 2 Principais elementos de um WSDL

Fonte: Maciel (2007, p. 25).

O WSDL tem um conceito muito poderoso e por causa das suas capacidades,
web services so conhecidos como elementos de softwares auto-descritivo. Web
Services podem no somente inter-operar universalmente atravs do SOAP, como
tambm serem descritos universalmente usando-se WSDL, conforme dito por
(PULIER; TAYLOR; GAFFNEY, 2008, p. 68). Por exemplo, um desenvolvedor no
Brasil pode implementar um software para acessar um determinado Web Service
que est localizado em Tkio no Japo apenas lendo e processando o documento
WSDL. Para o desenvolvedor realizar essa tarefa, ele no necessita entrar em
contato com os demais desenvolvedores nas outras localidades, ler um manual
particular ou comprar um software proprietrio; teoricamente, o desenvolvedor
precisa apenas estar ciente dos padres a serem seguidos. Porm, neste simples
exemplo no estamos levando em considerao as questes de segurana que

23

sero abordadas posteriormente neste trabalho. O importante a simplicidade e

portabilidade com que feita esse tipo de troca de informao.

2.4 UNIVERSAL DISCOVERY, DESCRIPTION AND INTEGRATION

Universal Discovery, Dercription and Integration (UDDI) o protocolo
desenvolvido para a organizao e registro de Web Services. Embora existam vrios
tipos de registros de Web Services disponveis, o UDDI identificado como sendo
um padro geral muito utilizado para esse tipo de servio em uma rede especfica. O
registro de servios deve fornecer algum mecanismo de localizao dos servios
expostos para a entidade consumidora baseando-se em critrios de localizao dos
servios (ROCHA, 2006, p. 24).
Os servios expostos com a utilizao do protocolo UDDI podem estar em
qualquer lugar e serem chamados a qualquer momento e, de fato, a mesma funo
pode ser executada por um servio diferente independentemente dos critrios de
disponibilidade e preo. Nesse ambiente, operar sem um diretrio com o protocolo
UDDI para encontrar os servios, obrigaria a fixar a localizao dos servios na
aplicao consumidora, quebrando assim, uma das grandes vantagens da utilizao
de Web Service que a transparncia da localizao dos servios expostos.
Os Web Services possuem endereos Internet Uniform Resource Locator
(URL). Para o computador requisitante, um Web Service simplesmente uma URL.
Uma vez que os Web Services usam protocolos Internet, podem ser acessados
enviando-se uma mensagem SOAP de requisio ao endereo do Web Service. As
URLs deles so a base de sua universalidade e transparncia de rede, onde essa
universalidade vem da forma padro com que so descritos e a transparncia vem
da possibilidade de se utilizar um nome lgico na sua aplicao consumidora, que
o UDDI pode converter para uma URL apropriada. Dessa maneira, caso a
localizao de um determinado servio venha a ser alterado, o software consumidor
no sofrer impacto, independente de onde esteja localizado o servio. Criar esses
tipos de mscaras para as aplicaes consumidoras fortalece a agilidade proposta
pela tecnologia de Web Service (SAMPAIO, 2006; PULIER; TAYLOR; GAFFNEY,
2008).

24

2.5 SIMPLE OBJECT ACCESS PROTOCOL

Simple Object Access Protocol (SOAP) um protocolo para troca de
informaes estruturadas em uma plataforma descentralizada e distribuda,
utilizando tecnologias baseadas em XML (PULIER; TAYLOR; GAFFNEY, 2008, p.
71). O que torna o SOAP especial e diferente de XML puro que cada mensagem
segue um modelo que foi especificado pelos padres W3C. Ele foi criado,
inicialmente, para posssibilitar a invocao remota de mtodos atravs da Internet.
O SOAP surgiu numa poca em que as poucas alternativas para troca de
mensagens eram as tecnologias DCOM, CORBA ou RMI. Os criadores do SOAP
usaram um protocolo bem simples e difundido, o HTTP, e o XML como uma forma
de comunicao mais padronizada e flexivel. Por esta razo ele no apresenta
problemas quando encontra um firewall, j que no apresenta risco de segurana,
tornando o uso de componentes remotos mais viveis (SAMPAIO , 2006, p. 16).
Uma das mais importantes caractersticas do protocolo SOAP a separao
entre o formato do dado a ser transmitido e o mecanismo de nvel inferior que ir
transportar o dado. H uma garantia da independncia de plataforma e linguagem,
pois se faz o uso de XML com HTTP que so protocolos abertos e bem difundidos
na internet. Na maioria das vezes, os dados que so transportados em uma
mensagem SOAP formam chamadas remotas de procedimentos Remote Procedure
Call (RPC) que invocam procedimentos especficos em um provedor de servios
(MACIEL, 2007, p. 22).
Juntos os trs padres, SOAP, WSDL e UDDI, so combinados para dar a um
Web Service as possibilidades de funcionar, autodescrever-se e ser encontrado
dentro de uma rede. Na teoria, um Web Service no necessita de todos os trs
protocolos para funcionar, ele pode ser utilizado apenas com o SOAP, mas como
mostrado na figura 3, para trabalhar mais eficazmente necessrio usar os trs
protocolos (PULIER; TAYLOR; GAFFNEY, 2008, p. 81).

25

Figura 3 Utilizao dos protocolos SOAP, WSDL e UDDI

Fonte: Pulier, Taylor e Gaffney (2008, p. 82).

Segundo Rocha (2006, p. 35) uma mensagem SOAP constituida por um

envelope de cdigo em XML onde definido seu incio e seu fim da mensagem. O
cabealho (header) descreve de onde a mensagem foi enviada, para onde vai e
como chegar no seu destino. O corpo (body) da mensagem SOAP possui os
dados relevantes ou instrues sobre os procedimentos da requisio ou resposta
da mensagem SOAP. A figura 4 ilustra uma mensage SOAP completa com
envelope e corpo, viajando por uma rede de um consumidor (computador B) de
web service para um provedor (computador A), neste exemplo um mainframe.

Figura 4 Exemplo da forma de uma mensagem SOAP

Fonte: Pulier, Taylor e Gaffney (2008, p. 86).

26

2.6 DEFININDO SOA

A Arquitetura Orientada a Servio (SOA) composta por um conjunto de
regras e conceitos que viabilizam a estrutura para arquitetar, desenvolver sistemas e
aplicaes orientadas a servios, com o objetivo de obter o mximo de acoplamento
fraco entre os servios que so expostos. Muitas dessas regras e conceitos
existentes na Arquitetura SOA, foram baseados em modelos j existentes, como por
exemplo o CORBA e DCOM, conforme descrito por Rocha (2006, p. 33).
Larentis (2007), relataram que a arquitetura SOA pode ser composta por
vrios servios que atuam como consumidores e/ou provedores. De forma genrica
esses tipos de servios ficam expostos para que aplicaes e/ou outros servios os
acessem, fortalecendo a idia de consumidores e provedores. A SOA tambm
permite que haja a composio entre servios, ou seja, provedores podem consumir
servios de outros provedores tornando-se consumidores, e vice-versa com os
consumidores. Teoricamente, a composio muito utilizada neste tipo de
arquitetura, porm, os mecanismos de segurana devem ser adequados para este
novo modelo de negcio. A arquitetura SOA resumida como um conjunto de
componentes que podem ser acessados e cujas interfaces podem ser divulgadas e
pesquisadas, conforme figura 5.

Figura 5 Princpio bsico da SOA

Um outro aspecto muito importante que a arquitetura SOA no somente
construda sobre um conjunto de Web Services na Internet. Ela um modelo
conceitual, e no apenas um produto, aplicao ou mdulo de um sistema a ser

27

implementado. primordial ficar claro que a SOA fundamentada em protocolos,

conceitos, regras, padres e acordos contratuais para a realizao de trafego de
informaes e dados atravs de servios expostos, e que Web Service est
caminhando para se tornar de fato a plataforma preferida para implementar uma
arquitetura SOA por ser independente de tecnologia.
O Web Service no o nico que pode ser usado para criar servios
expostos em uma arquitetura de software. Os Entreprise JavaBeans (EJB) podem
ser utilizados na exposio de servios. Porm, o EJB basicamente um
componente gerenciado que criado, controlado e destrudo pelo continer J2EE
em que vive baseado em uma tecnologia proprietria, diferentemente, do Web
Service (BOND e outros, 2003) que baseado em padro aberto.
A SOA proporciona uma transformao nos sistemas das organizaes onde
ela implantada. Essa modificao refe-se ao fato de que os softwares passam a
ser vistos como componentes e/ou servios de uma aplicao, como exemplificado
na figura 6. Neste aspecto, voc pode mov-los e reconfigur-los quando achar
necessrio. Com uma SOA, os arquitetos de softwares ficam livres da construo
com tijolos e pedras que so geralmente solicitadas pelas arquiteturas
corporatativas tradicionais (PULIER; TAYLOR; GAFFNEY, 2008, p. 70).

Figura 6 Sistema composto por legos

28

A SOA pode ser considerada uma abordagem para EAI onde cada elemento
importante exposto como um servio. Ela oferece um ambiente computacional
distribudo com alto nvel de interoperabilidade entre os sistemas. A SOA d
permisso ao arquiteto de software corporativo combinar elementos de software sem
ter custos elevados de tempo e dinheiro, assumindo que os servios expostos
tenham sido implementados de forma inteligente. Em resumo, os princpios da SOA
so o de no ser necessrio ter o conhecimento especfico e nem entender os
detalhes para utiliz-los, basta combinar o que deve ser feito e a interferncia do
codificador ser mnima ou nenhuma, usada uma composio de diversos servios
para um objetivo maior, os fornecedores de servios prestam um servio muito
melhor do que uma aplicao isolada e a localizao dos servios so armazenadas
em um repositrio que podem ser encontrados atravs de uma consulta .

2.6.1 Servio
Um servio um componente que procurar atender a uma funo de negcio
especfica de seus clientes. Ele recebe requisies e as responde ocultando todo o
detalhamento do seu processamento. Como isso, podemos obervar que um servio
exposto encapsulado em relao ao seu cliente, ou seja, quaisquer outras
aplicaes ou componentes que auxiliam o servio em questo devem ser utilizados
somente dentro do cdigo privado do servio, no possibilitando a exposio das
regras de negcio para seus clientes (LARENTIS, 2007, p. 37).
Segundo Sampaio (2006, p. 14) um servio deve executar unidades
complementares de trabalho, no dependendo do estado de outros componentes
externos. Sendo assim, outro aspecto muito importante que esses tipos de
servios devem ser Stateless, ou seja, eles no possuem armazenamento de
estado de conversao, com isso elevando o grau de reutilizao. Outro aspecto diz
respeito granularidade dos servios, que quanto maior ela for, mais adequado ser
o servio. Logo um componente que atua como servio no deve ter operaes
muito complexas. Resumindo, um servio executa uma funo atmica (ou
transao) e todas a operaes intermedirias devem ser realizadas apenas pelo
servio, e no pelo cliente consumidor.

29

2.6.2 Barramento de Servios Corporativos

Um barramento de servios corporativos Enterprise Service Bus (ESB) no
considerado um produto, mas sim um padro de arquitetura. Sua funo atuar
como um intermedirio entre a implementao de um servio e a forma como ele
exposto para seus consumidores. Por esta razo o barramento deve ser robusto e
possuir recursos para viabilizar a exposio e composio de servios, roteamento
de mensagens, transformao e enriquecimento de dados, segurana, dentre outros
aspectos, sempre utilizando padres abertos para viabiliar esses aspectos (CUNHA,
2008; GOMES e outros, 2007, p. 4).
O ESB representa um pilar dos servios, mensagens, comunicaes,
transformaes e de segurana sobre o qual se pode acoplar sistemas ou
simplesmente interoperar entre eles. Eles seguem os princpios da SOA,
possibilitando a integrao com diferentes tipos de servios, e incluem de forma
geral as seguintes reas funcionais: Standard-based Communication Infrastructure,
Standard-based Connectivity,

Standard-based Transformation Engines, Service

Oriented Architecture (SOA) for application deployment e Standards-based Security

CUNHA, 2008; GOMES e outros, 2007, p. 5; MARTINS, 2005, p. 67).
O uso do ESB permite uma melhor gesto do conjunto de componentes e/ou
servios, de forma que ele ser responsvel por redirecionar as conexes dos
servios solicitantes para as novas localizaes dos fornecedores. Na figura 7
ilustrado o uso do ESB, de maneira que os diversos servios expostos
(componentes) das referidas aplicaes so integrados atravs dele.
Na arquitetura SOA um erro comum dizer que um ESB implementa a SOA
ou o fato de se utilzar um ESB j caracteriza a arquitetura com sendo uma SOA. Um
ESB responsvel por grande parte dos requisitos que a SOA estabelece, mas no
todos. No correto afirmar que Implementar um barramento de servios h uma
aderncia automtica SOA. Para ter isso vai depender da forma como so
modelados e concebidos os sistemas. No h como ter SOA somente tendo um
ESB. Porm, o ESB um componente importante em uma soluo SOA, tendo em
vista que toda a integrao de sistemas acontece atravs dele (COSTA;
CARVALHO, 2007, p. 3).

30

Figura 7 Conexo dos componentes atravs do ESB

Fonte: Martins ( 2005, p. 66).

2.6.3 Relao entre WS e SOA

Os Web Services no so resquisitos promordiais para se obter, implementar
ou estabelecer uma arquitetura SOA. Segundo Natis (2003) Web services so
baseados em especificaes tecnolgicas, enquanto a arquitetura SOA baseado
em princpios de desenvolvimento de software. De forma notvel, Web Services
Description Language (WSDL) utilizado por Web Services o padro que define
interfaces para arquitetura SOA, este o momento que Web Services e a arquitetura
SOA fundamentalmente se conectam.
Por outro lado, Rocha (2006) afirma que os Web Services so considerados
componentes que posssibilitam s aplicaes receber e enviar informaes
descritas no formato XML. Cada aplicao tem seu formato proprietrio para
descrever as suas informaes, porm, ocorre uma traduo para uma liguagem
universal, o formato XML. As instituies W3C e OASIS so as responsveis pela
padronizao dos Web Services (OASIS, 2006; W3C, 2008).
Em adio s discusses levantadas por Bertoni (2006), relevante ressaltar
que os Web Services so aplicaes fracamente acopladas que interagem
dinamicamente atravs de redes TCP/IP (Internet e/ou Intranets), atravs da

31

publicao, localizao e invocao destes pela Web. Assim, os servios disponveis

podem ser descobertos pelos consumidores, possibilitando transaes empresariais
e comerciais pela rede, sendo este o princpio bsico da arquitetura SOA (BERTONI,
2006, p. 23).
Em suma, a arquitetura SOA considerada um padro para se projetar
sistemas, enquanto que os Web Services so servios implementados atravs da
utilizao de padres. Os Web Services possibilitam a implementao da arquitetura
SOA e os benefcios do uso de uma arquitetura baseada em SOA atravs de
implementaes com Web Services propiciam o acesso a servios expostos
independentemente de plataforma e interoperabilidade entre os diversos fabricantes
da industria de TI.

2.6.4 Integrao de Aplicaes Corporativas com SOA

Com projetos de EAI sofrendo altos custos, ciclos de vida longos e uma alta
taxa de fracasso, como j foi mencionado no captulo 2, a questo de integrao
vem se caracterizando como uma enorme fonte de preocupao para os gestores de
TI. Pulier, Taylor e Gaffney (2008, p. 67) assim como Cummins (2002, p. 93) relatam
que os projetos de EAI geralmente so iniciados com boas intenes e inteligentes.
Entretanto, polticas corporativas e mudanas no planejadas nos processos de
negcios acabam resultando em projetos EAI presos em linhas ilhas de integrao
incompatveis, ou seja, projetos com baixa integrao entre eles. Com isso,
aumentando os obstculos para a integrao entre os diversos sistemas utilizados
pela organizao.
Como j foi dito anteriormente neste trabalho, os Web Services tm um
grande potencial para reduzir as necessidades de custo, de tempo e a complexidade
de EAI ao possibilitar que aplicaes interajam utilizando padres universais como
SOA, WDSL e UDDI. O fato dos Web Services serem baseados em padres abertos
aumenta o grau de independncia em relao ao fornecedor. Porm, as questes de
segurana, assim como consideraes polticas e organizacionais, os caracterizam
como uma soluo em potencial nas situaes de EAI (PULIER; TAYLOR;
GAFFNEY, 2008, p. 73). Baseando-se nisso, Garcia (2001, p. 18) e Cummins (2002,
p. 102) relataram que os pacotes de EAI existentes, provavelmente iro perdurar

32

durante muito tempo, devido sua capacidade de

gerenciar o volume de

transaes no nvel corporativo e fornecer garantia de desempenho dos sistemas

legados. Porm, eles tambm descreveram que h uma grande probabilidade de
que estes pacotes de EAI sejam gradativamente substitudos pelos padres de Web
Services.
Resumindo, a EAI a forma com que algumas empresas, pblicas ou
privadas, adotam para prover e consumir seus servios entre parceiros de negcios
ou mesmo expor servios dentro da sua prpria infra-estrutura de TI, entre sistemas
com arquiteturas e tecnologias diferentes. A SOA tambm tem esse fundamento
como seu princpio. Na maioria das arquiteturas EAI tratada tambm
separadamente pelas organizaes, que, inicialmente, expem seus Web Services,
e, em segundo lugar, tentam acoplar os mecanismos de segurana mediante as
exigncias do negcio (ROCHA, 2006, p. 41).

2.6.5 Segurana na SOA

Os problemas de segurana inerentes SOA so derivados das formas com
que os parmetros de segurana utilizam os padres abertos. Existem dois lados em
relao ao problema de segurana na arquitetura SOA, pois alm dos padres no
terem um proprietrio, eles foram desenvolvidos sem ter segurana em mente. Os
Web Services foram criados por um consenso da indstria de TI, como uma forma
de desenvolver software, dentre outras coisas, permitir a criao de cdigo
reutilizvel, tornar o desenvolvimento mais simples e facilitar a interoperabilidade
entre aplicaes mais heterogneas. Embora seus objetivos tenham sido
alcanados com o surgimento de padres abertos, os mesmos no se preocupam
com a segurana das informaes trocadas. Eles por s s no tratam as questes
de segurana, sozinhos so completamentes inseguros. Os Web Services foram
criados para quebrar a barreira imposta por firewalls, da, a grande importncia do
assunto Segurana no mundo da Arquitetura Orientada a Servios (DEGAN, 2005,
p. 45).
A segurana outro aspecto na adeso da arquitetura SOA para fins de EAI.
Embora arquiteturas complexas que usam SOA pareceram impressionantes, em
relao a sua complexidade, elas podem ser totalmente inseguras. Uma vez que os

33

Web Services utilizam protocolos de Internet para mensagens e esse tipo de

mensagem projetada para passar pelo firewall. Como isso, os Web Services so
expostos a brechas de segurana.
Segundo Cummins (2002, p. 110) importante compreender que a maioria
das infra-estruturas de segurana gerada para interaes homem-mquina,
enquanto que os Web Services trabalham com a interao mquina-mquina. At
recentemente, a maior parte da ateno e do desenvolvimento de aplicaes estava
voltada para o ambiente muito conhecido de acesso homem-mquina, incluindo
solues que fornecem gerenciamento de identidade e solues de single-sign-on
(SSO) para usurios que acessam aplicaes atravs de browsers.
Na arquitetura convencional, a tecnologia de segurana do sistema, como por
exemplo o firewall, evita que usurios no autorizados tenham acesso s
informaes restritas da organizao. Entretanto, na arquitetura SOA ela prega
flexibilidade e abertura para que seja acessada por diversos sistemas, fortalecendo
a reutilizao e composio de novas aplicaes. Nesse ambiente as aplicaes so
expostas como servios, mas um novo mecanismo de segurana no imposto,
deixando-as bem frgeis. Em virtude

da natureza grosseira do mecanismo de

segurana, no temos como identificar se a mquina que est solicitando a

utilizao do servio exposto est autorizada ou autenticada (ROCHA, 2006, p. 23).
Apesar desses problemas h solues para melhorar a segurana em uma
Arquitetura Orientada a Servios. Uma soluo completa pode ser composta por
diversas subsolues, cada uma lidando com certo aspecto de segurana de SOA.
Dependendo das suas necessidades e infra-estrutura de segurana existente,
haver uma necessdade de optar por solues que podem diferir umas das outras.
Pulier, Taylor e Gaffney (2008, p. 73) destacam os seguintes produtos de segurana
de SOA:
a) Monitoramento de mensagens SOAP - baseado em interceptao de
mensagens SOAP, sendo uma maneira de construir o alicerce de uma
soluo de segurana SOA. A interceptao de SOAP pr um
componente chamado Interceptador SOAP, no caminho das mensagens
SOAP, que trafegam entre os provedores e consumidores de servios

34

expostos. Ele analisa as identidades dos usurios contidas nos

cabealhos das mensagens que monitora e as compara com os nomes
armazenados na infra-estrutura de segurana existente. O resultado a
autenticao e autorizao de remetentes e destinatrios de mensagens;
b) Autenticao federada - autenticao federada um processo no qual
diversos parceiros entram em acordo que um determinado grupo de
usurios pode ser autenticado por um dado conjunto de critrios. Para
utilizar

uma

autenticao

federada

em uma

segurana

SOA, o

interceptador de SOAP encaminha uma mensagem que chega para uma

soluo de segurana, que compara a identidade do usurio contida no
cabealho da mensagem com os usurios listados no banco de dados de
autenticao federada. Uma vez aprovado, a soluo de segurana de
SOA informa que o usurio foi autenticado;
c) Proxy de aplicao - uma forma altamente eficaz de melhorar a
segurana de sistemas centrais no permitir que qualquer um alcance a
plataforma que hospeda o servio. Isso pode ser feito instalando um proxy
para Web Services dentro da arquitetura SOA. Uma vantagem adicional
da utilizao de proxy a sua capacidade de reduzir a carga na infraestrutura de segurana da organizao.
d) Gerenciamento de contrato - um contrato um grupo de regras que
governa o uso de um determinado Web Service. Como por exemplo, um
contrato pode estipular que quantidade e/ou tempo de acessos um usurio
pode ter por dia a um Web Service ou a quantidade (MBytes) de
informao que pode ser acessada. Essas medidas podem aumentar a
segurana, pois os contratos so teis para determinar se a SOA est
funcionando adequadamente ou sendo mal utilizada devido s falhas de
segurana;
e) Certificados, chaves e criptografia - nos ultimos anos, a TI apoiou
diversas tcnicas e tecnologias de segurana em criptografica. Na SOA
podemos fazer uso desses mesmos algoritmos j existentes. Esses
processos, seja, certificado, chaves e criptografia, podem desempenhar
um papel muito importante na busca de uma maior segurana para os
servios expostos na sua arquitetura SOA;

35

f) Criptografia de XML - neste caso para se manter o conceito de uso dos

padres abertos na arquitetura SOA, as mensagens no formato XML so
encriptadas, porm, o contedo s poder ser entendido por quem possuir
a chave para quebrar o cdigo;
g) Assinaturas digitais - baseada em chaves, a assinatura digital um
nmero que captura unicamente sua identidade e o contedo da
mensagem, passando os dois conjuntos de informaes (chave e
mensagens) por um algoritmo com esse fim. A diferena entre assinatura
digital e o processo de criptografia, dito anteriomente, que na assinatura
digital a mensagem no totalmente criptografada;
h) Proteo de ataque duplicado e auditoria - a soluo de segurana
SOA idendifica a mensagem SOAP com um nmero nico, e configura a
soluo para bloquear mensagens duplicadas, evitando que a mesma
mensagem seja enviada duas vezes. J auditoria um uso avanado das
funcionalidades de rastreamento das mensagens.

2.6.6 Vantagens x Desvantagens da SOA

A Arquitetura Orientada a Servio tambm possui suas desvantagens e
vantagens como qualquer outra tecnologia. As organizaes adotam a SOA com o
objetivo de alcanar aumento da competitividade, melhorar a eficincia dos sistemas
legados, ganhar dinamismo nos processos para melhor aproveitar as novas
oportunidades de negcios, utilizar a infra-estrutura existente dos sistemas legados,
reutilizao dos cdigos dos legados, reduzir custos, aumentar a flexibilidade dos
novos sistemas, potencializar a portabilidade, dentre outras.
Por outro lado, uma das possveis desvantagens da arquitetura SOA
relatadas por Rocha (2006, p. 31) o gerenciamento dos mecanismos de segurana
dessa arquitetura. A complexidade na interoperabilidade dos mecanismos de
segurana que so solicitados pelos novos processos de negcio, inevitavelmente,
ser um fator que constribui fortemente para dificultar a evoluo da arquitetura
SOA. A imaturidade dos mecanismos de segurana fornecidos pela indstria de TI,
para as aplicaes baseadas no padro XML ou uso inadequado dos mecanismos
de segurana citados anteriomentes neste trabalho na arquitetura SOA, podem levar
as organizaes a rever a aplicabilidade da SOA. Resumidamente, os mecanismos

36

de segurana na arquitetura SOA em relao aos processos de negcios so

considerados fatores crticos na Arquitetura Orientada a Servios.
Um outro aspecto o gerenciamento de mudanas como uma rea
problemtica para arquiteturas distribudas. Se no for trata corretamente em uma
SOA, pode ser to problemtica quanto em arquiteturas antigas. Mudanas so um
fator cosntantes em gerenciamento de TI, e a SOA no exceo. Conforme os
requisitos e os processos de mudam, tambm mudam os sistemas que os suportam.
Embora a SOA alivie muitos dos estresses que acompanham o gerenciamento de
mudanas no modelo tradicional, ainda um rea que requer ateno de perto e
gerenciamento adequado para funcionar eficazmente.
O gerenciamento de mudanas da SOA traz desafios equivalentes queles do
modelo tradicional. Quando um Web Service muda, tanto os aspectos da invocao
quanto da resposta do novo Web Service devem ter um desempenho conforme
prometido ou haver um problema. Se organizao substituir o Web Service de
aluno, por exemplo, por um novo o administrador da SOA deve ser capaz de garantir
aos usurios que cada sistema que invoca o novo Web Service obter os resultados
de que precisa.
E por fim, o fator de mapeamento dos requisitos na SOA. A transformao
dos requisitos de negcio da organizao durante o processo de implantao de
uma SOA no uma tarefa to simples. Por exemplo, temos uma determinado
requisito de negcio que possui cinco regras especficas, quando houver a migrao
das funcionalidades para servios podem haver reduo dessas regras. Essa tarefa
de determinar quais as referidas regras sero excluidas no novo servio depende de
um acordo com os gestores do respectivo servio. Em resumo, no pedemos
simplesmente mudar de funcionalidade para servio uma determinada aplicao,
deve haver um estudo e negociao junto aos gestores.

2.7 TENDNCIAS DE MERCADO PARA SERVIOS

Nas atuais organizaes, pblicas ou privadas, viver uma poca muito
empolgante para o envolvimento com tecnologia da informao corporativa. A
arquitetura Orientada a Servios, um sonho muito antigo na indstria de TI, est se

37

tornando uma realidade em um ritmo que poucos antecipavam h pouqussimos

anos. Os organismos de padronizao continuam lutando com os conflitos sobre
padres e o movimento bem sutil de padres proprietrios sempre parece estar se
esgueirando pelas sombras, ameaando prejudicar a essncia verdadeira que a
SOA est tentando alcanar (PULIER; TAYLOR; GAFFNEY, 2008, p. 68).
Uma das caractersticas do servio a intangibilidade. Para amenizar esse
tipo de problema, a indstria de TI, com especialidade em servio, contar com o
apio de vrios modelos, com o intuito de serem intermediadores entre os
provedores e consumidores dos servios expostos. Tomando como exemplo o
padro Infrastructure Resource Management (IRM), que fornecem diversos servios
para melhor gerir a infraestrutura de TI, como por exemplo o gerenciamento de
mudanas, problemas e incidentes, com o objetivo de prever os desvios no ambiente
de TI, de forma a reduzir os seus efeitos e impactos (COSTA; CARVALHO, 2007, p.
4).
Segundo Rocha (2006, p. 30) a utilizao da arquitetura SOA nas
organizaes deve estar intimamente ligada a um processo de gesto do
conhecimento em relao aos componentes reusveis da mesma. O funcionamento
adequado desse tipo de gesto est associado ao uso de uma biblioteca central com
os artefatos organizados de maneira que a pesquisa possa ser feita por diversas
categorias de informao, fortalecendo o reuso dos componentes de software.
Um dos fatores benficos do uso da SOA que ele utiliza a arquitetura
centrada no cliente, modificando o paradigma dos modelos e prticas que tendem a
ser centradas na aplicao. A arquitetura focada no cliente prov uma abordagem
de configurao em relao ao usurio, ao invs de focar em um nico modelo para
todos os usurios ou onde h workflows pr empacotados (NATIS, 2003, p. 14).
A Arquitetura Orientada a Servios uma nova oportunidade, mas um
conceito antigo to antigo quanto software em si: construir uma vez e reutilizar
muitas vezes, seja dentro da prpria organizao ou entre parceiros (PULIER;
TAYLOR; GAFFNEY, 2008, p. 73).

38

Segundo Costa e Carvalho (2007, p. 5) o UDDI embora seja projetado para se

tornar um repositrio de componentes de servios, geralmente no utilizado com a
aderncia com qual foi planejado. Uma vez os projetistas desvendando os servios
que sero expostos, eles tendem a fazer uma conexo mesmo flexvel entre os
componentes de servios fazendo ligaes diretas entre os componentes, conforme
figura 8. E logo o uso da SOA interessante, pois resolve esse problema com o
acoplamento franco entre os componentes e a independncia de tecnologia.
O uso do Enterprise Service Bus (ESB), ou simplesmente Barramento de
Servios, permite s organizaes gerir melhor os seus conjuntos de componentes,
de maneira que eles mesmos sejam responsveis e capazes de redirecionar as
conexes dos servios consumidores para as novas localizaes dos provedores.
Com isso, qualquer que seja a alterao no ambiente, ou na localizao dos
servios expostos, no haver impacto no componente consumidor, pois sua
interao realizada apenas com o ESB (MACHADO, 2004, p. 44).

Figura 8 Conexo entre componentes.

Fonte: Costa e Carvalho (2007, p. 7).

A tecnologia de Web Services, embora j seja amplamente difundida, ainda

tem que percorrer muito o caminho da evoluo. Esta tecnologia, comparada a
outras j consolidadas na indstria da TI, como manuteno do estado transacional
e composio dos servios, ainda no est bem resolvida. A indstria da TI tem
procurado trabalhar em novas especificaes para tentar resolver essas questes.
Como WS-Transaction e WS-Coordination (COSTA; CARVALHO, 2007, p. 8).

39

2.8 TRABALHOS RELACIONADOS

A exposio de servios atravs de Web Service fazendo uso da SOA no
algo muito novo, visto que sua utilizao possui diversas referncias para
implementao. Esta seo busca os principais trabalhos relacionados a esse tema
e que trazem contruies para solucionar alguns problemas j encontrados, alm de
servirem para posiocionar o presente trabalho em relao a outros na mesma rea.
A seo apresenta uma soluo de migrao de sistemas legados para SOA
denominada SMART, que no contempla aspectos de codificao. Em seguida,
apresentada uma tcnica para encapsulamento de sistemas legados para reuso em
SOA. Logo aps, apresentada uma arquitetura denomidada ARUBA que permite a
gerao de servios a partir de sistemas legados. Por fim, apresenta duas
ferramentas comerciais que permite gerao de servios.

2.8.1 Migrao de sistemas legados para SOA

Segundo Lewis, Morris e Smith (2005), torna possvel que um sistema legado
trabalhe com Web Service as vezes algo relativamente simples. Os Web Services
so baseados em padres abertos e so configurados para receber mensagens,
transformar seu contedo, fazer uso de cdigo legado, e opcionalmente alterar os
resultados das mensagens retornadas ao fornecedor (LEWIS; MORRIS;, SMITH,
2005). Porm, segundo Larentis, existem caractersticas de sistemas legados que
podem tornar o processo de criao de Web Service uma tarefa complicada, por
exemplo:
a) Tempo de existncia;
b) Linguagem de programao;
c) Arquitetura;
d) Estado futuro baseado em servio;
A tcnica SMART (Service-Oriented Migration and Reuse Technique) foi
derivada do modelo Options Analysis for Reengineering (OAR) desenvolvido pelo
Software Engineering Institute (SEI) utilizado para suporte na anlise de reuso de
sistemas legados (BERGEY, 2002). A SMART est dividida em cinco atividades
descritas a seguir:

40

a) Estabelecer o contexto com os stakehouders - identifica caractersticas

sobre o sistema legado, seu objetivo atual, e o que dever ser migrado
para servio;
b) Descrever as capacidades existentes - obter dados descritivos sobre os
componentes do sistema legado;
c) Descrever o estado fututo baseado em servios - obter evidncia sobre
os servios potencias que podem ser criados a partir dos legados;
d) Analisar as difernas entre o estado baseado em servio e as
capacidades existentes - Identificar a diferena entre o estado existente
e o futuro e determinar o nvel de esforo e custo necessrios para
converter os componentes legados;
e) Desenvolver uma estratgia para migrao de servio - Identificar os
componentes especficos para migrar, planejar e ordenar os esforos para
a migrao.
Resumidamente, a tcnica SMART props um modelo para expor as
funcionalidades de sistemas legados como servios, porm, esta tecnica muito
direcionada em gerar informaes que justifiquem a viabilidade deste objetivo.
2.8.2 Encapsulando sistemas legados para reuso em SOA
Em Sneed (2006) apresentado um modelo que ajuda na identificao de
quais partes de um sistema legado poderiam ser expostos com Web Services e uma
tcnica de como fazer essa transformao. Esta soluo

est baseada

num

mtodo disponibilizado por uma ferramenta, que permite integrar o cdigo legado
dentro de uma interface XML em funes separadas, para serem oferecidas como
Web Services para outro usurio externo. O foco deste mtodo consiste de trs
passos bsicos para a criao de Web Services a partir de um sistema legado:
a) Preservando o cdigo legado - neste primeiro momento, sugerido que
seja realizada uma anlise do cdigo legado existente para identificar qual
parte do cdigo agrega valor para ser reutilizado;
b) Encapsulando o cdigo legado - neste passo, fornecer uma
componente extrado do cdigo legado atravs de uma interface WSDL;

41

c) Tornar o cdigo disponvel como um Web Service - o ltimo passo

desta soluo diz respeito a fazer um link do Web Services com o
processo do negcio. Isto feito por um componente proxy.
Resumidamente, este trabalho tem como proposta um mtodo para identificar
quais funes sero disponibilizadas como Web Services. O cdigo legado
preservado, porm a lgica de negcios que ser disponibilizada deve ser extrada
e salva em outro arquivo, de forma que todas as funes dependentes sejam
juntamente agrupadas em uma nica funo sequencialmente. Aps isso, so
identificados os parmetros de entrada e sada, gerendo uma XML capaz de fazer a
traduo destes parmetros e por fim, utilizado um proxy para fazer a
comunicao entre o cliente e o cdigo legado alterado.
2.8.3 Uma arquitetura para gerao de servios a partir de um sistemas
legados de forma intrusiva
A construo de sistemas baseados no conceito de servios estabelece uma
abstrao entre os processos de negcios e as aplicaes existentes nas
organizaes, porm, constitui uma atividade que requer alguns esforos e que pode
ser realizada de diversas maneiras. Muitos so os padres de tecnologia que podem
ser utilizados para a gerao desses servios, cujo o principal objetivo contribuir
para a integrao de diferentes aplicaes (LARENTIS, 2007).
A arquitetura para gerao de servios a partir de uma sistema legado de
forma intrusiva (ARUBA) uma arquitetura que atravs de uma interface permite o
mapeamento das regras de negcios para a exposio como servios. Assim,
integrando as tecnologias, WSDL, SOPA e UDDI, ao conceitos de sistemas legados
no desenvolvidos sob a forma de Web Services, possvel reutilizar este cdigo
sem que haja necessidade de alter-lo, mapeando as funcionalidades e gerar os
servios como Web Services, para reuso em outra tecnologia, como SOA
(LARENTIS, 2007).
Uma das preocupaes da arquitetura ARUBA evitar que sistemas legados
estveis necessitem ser alterados para que possam ser utilizados na SOA.
Buscando otimizar este cenrio. Um mapeamento do cdigo feito incialmente,

42

aps isso, ocorre a gerao do Web Services por um mtodo da arquitetura, assim
como a gerao de arquivos de configurao (LARENTIS, 2007).
2.8.4 Sistemas legados e SOA Solues comerciais
Durante a contruo deste trabalho foram encontradas ferramentas
comerciais que fazem uso de Web Services para expor as funcionalidades dos
sistemas legados ou novos para uso em SOA, entre eles so: IBM SOA Foundation
e Microsoft Biztalk Server. Cada uma destas solues apresenta uma abordagem
diferente ou proprietria para gerao de Web Services, possuem diferentes
mecanismos para desen volvimento SOA e fornecem solues desde integrao
com sistemas legados at a disponibilidade dos servios de novas aplicaes para
uso por outras.
2.8.4.1 IBM SOA Foundation
Segundo a IBM, a SOA fornece flexibilidade e reuso dos processos

de

negcios ou recursos de uma empresa. A SOA prope uma arquitetura que combina
conexes adaptveis com relaes bem definidas, baseadas em tecnologias padro
para ajudar a flexibilizar infraestruturas existentes (IBM CORPORATION, 2005).
Os servios de SOA so extensveis, baseados na implementao de novos
servios ou recursos de TI existentes. Assim, o desenvolvimento de uma SOA
comea com uma infraestrutura flexvel, robusta que pode ser utilizada em conjunto
com outra infraestrutura existente e recursos de TI para proporcionar mais valor ao
negcio.
A plataforma IBM SOA Foundation foi densenvolvida para atender todas as
camadas de arquitetura de referencia SOA da IBM, na qual define servios de TI
requeridos para fornecer suporte a cada um dos estgios do cliclo de vida de SOA
(Modelo, Construo, Implantao, Controle e Governana/Processos). A arquitetura
de referncia SOA inclui um ambiente de desenvolvimento, gerenciamento de
servios, integrao de aplicaes e processos de servios em tempo de execuo
(IBM CORPORATION, 2005).

43

2.8.4.2 Microsoft
A Microsoft disse que a orientao a servios uma abordagem para
organizar recursos distribuidos de TI em uma soluo integrada que desmembra
grupos de informao e maximiza a organizao na agilidade dos negcios. Os
servios de comunicam entre si por meio de formatos de mensagens bem definidos;
isso significa que a confiabilidade do aplicativo de sistemas conectados sofrer uma
grande influncia da confiabilidade da infraestrutura de mensagens que ela usa para
fazer a comunicao entre os servios. A orientao a servios une fonte de
informaes autnomas construido um pacote em grande escala de sistemas
operacionais, tecnologias, e protocolos de comunicaes (MICROSOFT, 2006a).
O Microsoft Biz Talk Server o aplicativo de destaque na colaborao no
desenvolvimento de aplicaes voltadas para SOA (MICROSOFT, 2006b). Ele
denominado um ambiente para desenvolver SOA. um servidor da Microsoft que
permite que os clientes integrem sistemas, funcionrios e parceiros comerciais e
rene as funcionalidades de integrao de aplicativos e automao de processos
das tecnologias XML e Web Services. O Biz Talk Server funciona como um
mecanismo de execuo de processo e como um hub de sistema de mensagens,
fornece um suporte ao consumo de servios Web como parte do processo
comercial, expondo os processos e aplicativos de linha de negcio como servios
Web. Ele fornece suporte SOAP, UDDI, WSDL entre outros, utilizando adaptadores
ASMX e Web Services Enhancements (WSE). Ele tambm acrescenta a capacidade
de chamar servios da Web por meio de servios de mensagens pblicas/subestilo e
fornece um adaptador Windows Communication Foundation (WCF) para incorporar
servios da Web WCF a processos comerciais.

44

CAPTULO 3
3 UMA ARQUITETURA PARA INTEGRAO DE SISTEMAS
Neste captulo abordaremos a instituio estudada e uma soluo proposta
com base na Arquitetura Orientada a Servios para ambientes com sistemas
heterogneos. Para isso, apresentaremos um breve histrico da organizao, os
objetivos desta arquitetura, os legados encontrados na organizao estudada, uma
proposta de componentizao dos requisitos de negcio da instituio e alguns
cases de aplicaes que esto fazendo uso da arquitetura proposta por este
trabalho.

3.1 A SECRETARIA DA EDUCAO DO ESTADO DA BAHIA

A informtica na Secretaria da Educao do Estado da Bahia (SEC) tem
como rgo central a CMO Coordenao de Modernizao, unidade administrativa
da Diretoria Geral. O papel da CMO de planejar, coordenar, avaliar e controlar a
execuo de atividades de informao e informtica, bem como as atividades de
organizao e modernizao administrativa, atravs de solues sistmicas, com
base em recursos metodolgicos e tecnolgicos avanados. A CMO se estrutura da
seguinte forma:
a) Suporte Tcnico de Informtica - tem o papel de Gerenciamento e
Manuteno de Rede, Hospedagem de Sites e Sistemas, Suporte ao
Usurio e Manuteno de Equipamentos;
b) rea de Sistemas - abrange as funes de Anlise de Sistemas,
Programao,

Design,

Administrao

de

Banco

de

Dados

Manuteno de Sistemas de Informao;

c) Modernizao Administrativa - implementa novas tcnicas de
procedimentos, da desburocratizao e do melhoramento dos servios
oferecidos pelas unidades da SEC, apoiando-se no uso eficiente de
novas tecnologias.

45

Com o passar do tempo a revoluo tecnolgica mudou muito os paradigmas

de gesto empresarial. A acelerao, inovao, automao dos processos e a
velocidade das informaes so fatores que esto impulsionando essa revoluo. O
novo desafio descobrir o que as organizaes devem fazer para potencializar seus
recursos na nova sociedade da informao. Dessa forma, as organizaes
necessitam investir em meios que garantam a diferenciao no mercado, resolvendo
e qualificando aes que resultaro na integrao e comprometimento de todos os
seus componentes, a fim de se obter a melhoria contnua. Dessa forma, aes
foram planejadas e executadas pela SEC.
A SEC vem avanando no contexto tecnolgico e procurando responder com
presteza ao desafio de universalizar o atendimento aos seus usurios com efetiva
melhoria na quantidade e na qualidade de servios. Tem implantado nos diversos
setores modernos equipamentos e desenvolvido sistemas que atendam s
exigncias da nova Administrao Pblica, que prima por uma disponibilizao mais
efetiva de servios ao cidado, como tambm, por ferramentas de controle de aes
e de gastos governamentais mais eficazes, conforme dito por Almeida Junior (2005,
p. 4).
Nos ltimos anos, foram muitas as aes voltadas para implementao de
sistemas, com o objetivo de otimizar e modernizar os seus procedimentos
administrativos. Exemplificando algumas aes, a Organizao estudada implantou
o Sistema de Programao de Carga Horria, que informatiza e padroniza as
prticas de execuo, acompanhamento, avaliao e controle de folha de
pagamento da Programao Escolar. Tambm implantou o Sistema de Controle de
Processos, que informatiza as atividades de tramitao de Processos, desde a sua
entrada, no protocolo at o seu trmino e arquivamento, o qual permite que o
servidor acompanhe o seu processo atravs de consulta atualizada atravs da
Internet. Alm de ter desenvolvido o Sistema de Controle e Acompanhamento de
Dirias e Adiantamento, o qual torna o gerenciamento do processo mais eficiente.
A SEC implementou o Projeto SECONLINE que consiste no sistema
automatizado de administrao de pessoal. Atravs do SECONLINE, o servidor
poder consultar seu histrico funcional, assim como, a administrao de pessoal
poder conceder, de forma automtica, sem a necessidade de volumosos

46

processos, direitos e vantagens dos servidores ativos do seu quadro efetivo, tais
como:

substituio,

freqncia,

gratificaes,

funes,

licenas,

adicionais,

afastamentos, remoo, certides, carga horria, ascenses e outros servios.

Tambm foi implementado o sistema de publicao, ferramenta que auxilia as
unidades administrativas na publicao dos seus Atos. De forma padronizada, os
atos so gerados e publicados automaticamente no Dirio Oficial. As informaes
publicadas alimentam o banco de dados da SEC promovendo maior confiabilidade e
integridade das informaes.
J h alguns anos que a matrcula da rede estadual tem sido um grande
sucesso, devido ao Sistema de Matrcula (SOMAR). Ele vem dando a possibilidade
de que a matrcula dos alunos seja feita nos postos, facilitando o processo de
matrcula para a rede estadual.
No ano passado foi implantando o sistema Transparncia da Escola, que veio
para informar como esto sendo gastos os recursos disponibilizados para as escolas
pelo diretor. Ele fornece um extrato disponibilizado no site da SEC com as receitas e
despesas realizadas pela unidade escolar.
Preocupando-se com o crescimento das atividades, a CMO est implantando
uma Metodologia de Desenvolvimento de Sistemas (MDS), a qual ir orientar a SEC,
parceiros e terceiros a desenvolver sistemas dentro de determinados padres.
Assim,

buscando

meios

mais

eficazes de

gerenciar

manter

sistemas

desenvolvidos na organizao, aumentando assim, a qualidade e reduzindo os

custos de desenvolvimento. Essa metodologia vem com o passar do tempo sofrendo
melhorias continuas. Hoje ela conhecida como Processo de Desenvolvimento de
Sistemas (PDS), com aplicao de alguns dos conceitos de CMMI, MPS-BR e
PMBOK. Conforme a figura 9 a atual metodologia formada por oito etapas:
a) Iniciao - que tem por objetivo descrever a solicitao de projeto e
selecionar o projeto que dever ser iniciado;
b) Planejamento do Projeto - que tem como objetivo descrever as
atividades necessrias para a realizao de um bom planejamento de
projeto e deve ser elaborado de forma rpida, objetiva e completa, onde

47

uma boa prtica para a execuo do planejamento do projeto e seu

acompanhamento seguir o Project Management Institute (PMI, 2004);
c) Anlise de Processo de Negcio - que consiste em levantar a lgica dos
processos atuais, alm de formulrios, relatrios, documentos, volumes,
formas de clculo, dentre outros, ou seja, tudo que esclarea o
funcionamento dos processos de trabalho;
d) Anlise e Projeto de Sistemas - a fase em que o sistema passa a ser
modelado e projetado;
e) Construo - que tem a finalidade de codificar o sistema atravs dos
artefatos gerados na fase anterior;
f) Homologao - que tem o objetivo de fornecer o aceite do produto
construdo, onde so feitos testes para garantir que os processos de
negcio e o sistema funcionem de acordo com o que foi requisitado pelo
cliente;
g) Implantao - que tem como objetivo preparar a infra-estrutura e os
treinamentos necessrios para implantar o produto;
h) Encerramento - que tem como finalidade avaliar, medir e dar por
encerrado o projeto.
Atualmente, a CMO se lanou na tarefa de revitalizar e fortalecer a rea de
Modernizao Administrativa, com o objetivo de promover novas tcnicas de
procedimentos, desburocratizao, otimizao de processos e o melhoramento dos
servios oferecidos pelas unidades da Organizao, apoiando-se no redesenho de
processos, trabalhos de conscientizao e treinamento de pessoal e no uso eficiente
de novas tecnologias. A equipe de desenvolvimento de projetos vem trabalhando
nos seguintes projetos: Sistema do IAT, que tem a finalidade de gerenciar a logstica
dos eventos realizados pelo Instituto Ansio Teixeira. Gesto TOPA, que tem o
objetivo de gerir os dados do Todos pela Alfabetizao (TOPA). Gesto da
Matrcula, com a finalidade de fornecer os requisitos para possibilitar a realizao da
matrcula informatizada. Almoxarifado, cujo foco gerenciar o almoxarifado da SEC.
Contratos e Convnios, cujo escopo controlar e acompanhar os convnios e
contratos firmados entre a SEC e os partcipes; bem como a implantao da nova
arquitetura padronizada, a qual ser mais detalhada na seo 4.6.

48

Figura 9 Processo de Desenvolvimento de Sistemas

3.2 ARQUITETURA LEGADA

Os sistemas legados no podem ser meramente considerados como
sistemas antigos. Eles incluem software, hardware, dados e processos corporativos
e qualquer alterao em uma parte do sistema, provavelmente, envolve
modificaes em outras partes ou componentes.
No captulo 1 foram abordadas as diversas arquiteturas que compe os
parques tecnolgicos dos sistemas da organizao estudada. A figura 10 mostra o
atual panorama complexo e custoso para integrar as informaes solicitadas pelos
processos de negcio. Em alguns casos existem at redundncia de funcionalidade
no gerenciada, dificuldando as respostas geis que as organizaes necessitam
para aumentar sua competitividade ou melhorar o atendimento sociedade como a
instituio base para este trabalho.
Como podemos observar tambm na figura 10, os bancos de dados no
esto integrados e os requisitos de negcio e/ou funcionalidades esto espalhados
com suas informaes distribuidas. Com isso, o problema de integridade, associado
falta de gerncia e redundncia dos dados, cresce exponencialmente medida
que surgiram novas aplicaes.
A industria de TI, com o passar do anos, vem procurando evoluir novos
padres de integrao entre as diversas funcionalidades das aplicaes e as

49

organizaes. Porm, essas instituies envolvidas no podem abandonar seus

investimentos em tecnologia e nos seus atuais sistemas. A necessidade de integrar
os softwares legados com as novas aplicaes que surgem tem levado criao de
novos produtos e padres com o intuito de permitir que aplicaes existentes
trabalhem juntas com as novas de uma forma fracamente acoplada. Para possibilitar
essa flexibilidade entre a troca de dados das aplicaes necessrio a criao de
um padro independente de plataforma (BECKER; CLARO; SOBRAL, 2002, p. 6);
(MARTINS, 2005, p. 69). A arquitetura proposta viabiliza essa integrao atravs
dos Web Services dentro da arquitetura SOA, que ser mais detalhada neste
captulo.

Figura 10 Aplicaes Legadas na SEC

Atualmente, a equipe que desenvolve os software da SEC trabalha em alguns

projetos com funcionalidades que podem ser caracterizadas como requisitos
compartilhados, ou seja, houve necessidade de troca de informaes entre eles e
com os legados existentes, como j foi relatado no captulo 1. Com isso, fica cada
vez mais evidente a necessidade de viabilizar uma nova arquitetura integrada para
manter e desenvolver os sistemas da organizao estudada.

50

3.3 ENTERPRISE APPLICATION INTEGRATION (EAI)

No passado foi cogitada a possibilidade de fazer uso da soluo de Enterprise
Application Integration (EAI) na SEC. Porm, aps um estudo sobre essa arquitetura
ficou evidenciado que os projetos de EAI sofrem com seus altos custos, ciclos de
vida longos e uma alta taxa de fracasso, conforme dito por Pulier, Taylor, Gaffney
(2008, p. 67) e Cummins (2002, p. 93). Os padres de EAI so bastante abstratos
para serem aplicados com a maioria das tecnologias de integrao, mas especficos
o suficiente para prover um guia ou catlogo para projetistas e arquitetos de
softwares. Porm, as solues tradicionais propostas pela EAI focam em uma
mquina de integrao centralizada e monoltica, que usa tecnologias proprietrias
para integrar sistemas, e adaptadores especializados para conectar fontes de dados
e sistemas legados. Outro aspecto so os altos investimentos iniciais solicitados por
essas solues tradicionais de EAI e a forte dependncia dos fornecedores.
Por outro lado, Cunha (2002),

Gomes e outros (2007, p. 4) disse que a

abordagem tradicional de EAI no leva em considerao o atual dinamismo que a

internet submete s organizaes, na qual os sistemas de uma organizao no
podem ser isolados do resto do mundo. Neste mbito, os requisitos de integrao se
modificam constantimente. As solues tradicionais e proprietrias se tornam pouco
geis e flexiveis e altamente custosas mediante qualquer alterao da demanda.
Em suma, pelo alto custo, ciclos de vida longos e dependncia de
fornecedores a Enterprise Application Integration (EAI) no funciona de maneira
adequada para a SEC.

3.4 DESENVOLVIMENTO ORIENTADO A COMPONENTES

Nas organizaes at pouco tempo os sistemas eram projetados de maneira
isolada, tipicamente fechada, e, caso houvesse a necessidade de alguma extenso
era preciso criar uma outra aplicao e comp-la de maneira que ficasse
transparente para os usurios. Esta outra aplicao realmente um software de fato
independente. Um conjunto de aplicaes independentes pode ser visto como uma
nica aplicao, onde o elo entre elas geralmente feito pelo menu (COSTA;
CARVALHO, 2007, p. 4).

51

O desenvolvimento orientado a componentes disponibiliza uma maior

flexibilidade, fortalecendo a separao bem definida de algumas partes da aplicao,
componentes, atravs de interfaces bem definidas. As principais barreiras para essa
flexibilidade corporativa so o tempo e o custo para desenvolver aplicaes de
negcio ou modificar as j existentes. As aplicaes tradicionais tendem a ser
enormes

monoliticas,

dificultando

sua

adaptao

novos

requisitos,

especialmente quando h modificaes nos processos de negcios da organizao

(CUMMINS, 2002, p. 278).
Os componentes foram uma estrutura de sistema bem-organizada. Dentro
de um nico sistema, muito provavelmente a funcionalidade comum ser
consolidade e encapsulada para que seja mais simples implementar as modificaes
exigidas pelos processo de negcios da organizao. Com a reusabilidade proposta
pelo desenvolvimento orientado a componentes pode-se obter uma melhor
economia e maior flexibilidade.
Na figura 11 ilustrado um exemplo nos quais alguns componentes so
reutilizados por diversas aplicaes corporativas. Como por exemplo, o componente
Pessoa reusado por trs aplicaes (G-SEC, SIAT e SIESC). J a aplicao
SIESC consome os componentes Aluno e Pessoa.

Figura 11 Reuso dos componentes pelas aplicaes

52

Anteriormente, neste captulo foi relatado a variedade de arquiteturas de

softwares que compem parte de sistemas da organizao estudada. Para
minimizar esse quadro a equipe de desenvolvimento vem propondo que as novas
aplicaes sejam desenvolvidas com uma nica arquitetura e nela sejam aplicados
os conceitos de desenvolvimento baseados em componentes, como mostrado pela
figura 11, onde as aplicaes so separadas por regras de negcios com o foco dos
objetivos

organizacionais

da

instituio.

Com

isso,

poderemos

reduzir

espalhamento dos requisitos que o atual parque de sistemas da organizao

evidencia.

3.5 FATOR MOTIVACIONAL

Na organizao pesquisada para a realizao deste trabalho, Secretaria da
Educao do Estado da Bahia, com o passar do tempo o Sistema de Informao foi
crescendo vertiginosamente, trazendo arquiteturas de sistemas cada vez mais
complexas, robustas e bem heterogneas. E ao mesmo tempo, um aumento da
necessidade de fornecer respostas geis em relao a evoluo dos seus negcios.
Segundo Pulier, Taylor e Gaffney (2008, p. 18) dentro de uma instituio
pblica ou privada, geralmente, as aplicaes de softwares especializados so
introduzidas por meio de esforos feitos na prpria organizao, da introduo de
pacotes de software de terceiros, ou ambos. Essas aplicaes rapidamente se
tornam independentes, necessitando umas das outras para completar processos de
negcios bsicos, tais como, matricular um aluno na rede estadual de ensino. De
fato, a otimizao dos processos de negcio das organizaes pblicas ou privadas
demandam rapidamente interao no somente entre os sistemas da prpria
organizao, mas tambm com sistemas de outras instituies. Embora esse tipo de
integrao tenha sido desejada h muito tempo pela industria de TI, os custos e
complexidades envolvidos resultam em dados armazenados de forma isolados e em
alguns casos surgem redundncias no controladas. Com isso, os dados s podem
ser conectados por meio de um custos e esforos enormes.
Atualmente, a SEC est enfrentando exatamente o problema de integrao
das informaes entre as diversas arquiteturas legadas. Com o intuito de tentar
amenizar o atual quadro em que a organizao em questo se encontra, surgiu o

53

fator que motivou a propor uma arquitetura para solucionar esse tipo de problema
atravs da Arquitetura Orientada a Servio (SOA) com a exposio dos servios
com a tecnologia Web Services.

3.6 DETALHES DA ARQUITETURA PARA INTEGRAO DE

SISTEMAS
O presente estudo prope viabilizar a implantao de modelo uma arquitetura de
software em organizaes pblicas cujo existem diversos tipos de arquitetura em
seus sistemas. Esse modelo proposto baseado em SOA com o uso de Web
Services para integrar os sistemas legados com as novas aplicaes atravs da
exposio de servios.

Figura 12 Viso Geral

A arquitetura proposta foi idealizada para possibilitar a integrao entre as
diversas arquiteturas encontradas na TI da organizao estudada. Na figura 12
ilustrada essa arquitetura que composta por diversos tipos de servidores de
aplicao com seus respectivos bancos de dados, onde so oferecidos servicos
atravs de Web Services e as trocas de mensagens entre os consumidores e

54

provedores de servios so realizadas utilizando padro SOAP com XML. Por fim,
os padres WSDL e UDDI serviro para possibilitar a descrio e localizao dos
servios que so expostos pelas aplicaes e/ou componentes atravs de um
barramento de servio.
Na figura 13 ilustrado a localizao de servios. A Aplicao Nova possui
um Web Service Consumidor que solicita informaes ao Web Service Provedor,
onde para saber a localizao e a descrio do provedor o consumidor deve solicitar
essa informao para o servidor de UDDI. Aps saber a localizao e a descrio, o
consumidor, troca informaes com o provedor atravs de SOAP baseado em XML.

Figura 13 Localizao de servio

Nos prximos tens sero detalhados os aspetos da nova arquitetura proposta

por este trabalho.

3.6.1 Servios Expostos atravs de Web Services

As organizaes esto gradativamente adotando a SOA com a finalidade de
suportar suas aplicaes legadas mais crticas. A SOA considerada por Maciel

55

(2007, p. 24) como um paradigma computacional que surgiu para suprir a

necessidade

de

colaborao

integrao

de

componentes

funcionais,

disponibilizados nesse contexto como servios, entre organizaes ou dentro da

prpria instituio que expe os servios, de forma interopervel e com fraco
acoplamento, como j foi mencionado no captulo 3.
J Barbieri (2001, p. 211) afirma que os Web Services so uma poderosa
implementao da SOA, que podem ser basicamente definidos como interface para
recursos computacionais, acessveis atravs da troca de mensagens baseadas em
XML e construdas com a utilizao de padres muito utilizados na internet. Em
virtude disso e do que j foi relatado anteriormente sobre fraco acoplamento,
viabilizao de componentizao dos processos de negcio da organizao e
compatibilizao das diversas tecnologias e suas solues no integrveis; os Web
Services foram adotados como parte da arquitetura proposta para possibilitar uma
melhora na integrao entre as diversas arquiteturas do parque de sistemas
encontradas durante este estudo.

3.6.2 Aplicaes Novas

Atualmente, o setor responsvel pela TI da SEC vem buscando fortalecer a
utilizao de uma nica arquitetura para o desenvolvimento de sistemas. Portanto,
seguindo essa premissa, foi proposta a utilizao de uma nica linguagem de
programao, o JAVA. Seguindo com padronizao no desenvolvimento de
sistemas foi selecionado o framework Jboss Seam, que defende o conceito de
integrao entre vrios frameworks especficos (FARLEY, 2008, p. 56).
As novas aplicaes devem preferencialmente nascer utilizando o framework
Jboss Seam. Porm, esses novos softwares produzidos sero, no futuro,
considerados como aplicaes legadas. Por isso, estamos propondo uma arquitetura
para esses novos sistemas pensando nas possveis integraes com outras
aplicaes legadas e novas tambm. Na figura 14 mostrada a arquitetura proposta
para o desenvolvimento de novas aplicaes, dividida em trs camadas:

56

a) Apresentao - nesta camada a camada responsvel pela interface com

o usurio, e tem o papel de expor os servios das aplicaes novas,
criando os Web Services para esta finalidade;
b) Negcio - j nesta camada tem como foco a implementao das regras de
negcio da aplicao;
c) Persistncia - e por fim, a camada de persistncia que tem a finalidade
de persistir as informaes no banco de dados e criar os Web Services
para consumir os servios expostos por outras aplicaes.

Figura 14 Arquitetura de uma nova aplicao

O modelo em camadas proposto acima no uma grande novidade no

mundo da TI. Estas camadas j so bem conhecidas, o importante a integrao
que ocorre atravs das camadas de apresentao e persistncia. Na camada de
apresentao residem os servios expostos atravs de Web Services, ou seja, os
provedores de servios que sero consumidos por outras aplicaes. J na camada
de persistncia residem os consumidores dos servios expostos por outras
aplicaes.

57

3.6.3 Aplicaes Legadas

Nas aplicaes novas podem haver consumidores e/ou provedores de
servios. J para as aplicaes legadas inicialmente sero criados apenas os
servios expostos (provedores). Porm, no futuro pode haver a necessidade de uma
aplicao legada consumir um servio exposto pela nova arquitetura proposta, em
decorrncia de um custo muito mais baixo para

novas implementaes de

funcionalidades. Em virtude disso, podemos destacar a importncia da flexibilide

deste tipo de arquitetura e j podemos tanto criar um servio exposto nas aplicaes
legadas, como nas novas que podem surgir, caracterizando o acoplamento fraco,
conforme j relatado no captulo 3 com base nos trabalhos de Sampaio (2006, p. 29)
e Dantas (2008) Gomes e outros (2002, p. 2).

Figura 15 Arquitetura das aplicaes Legadas

Na organizao estudada para a realizao deste trabalho, as aplicaes

legadas possuem uma grande gama de funcionalidades j implementadas e em uso.

58

Na figura 15 podemos observar que nas aplicaes legadas sero apenas

implementados os servios, sendo consumidor ou provedor. Com isso, geralmente,
reduzimos os custos, que muitas vezes so onerosos e tornam as implementaes
das novas funcionalidades inviveis.
No futuro, com o andamento da implantao e uso da arquitetura orientada a
servios iremos obter um conjunto de aplicaes que sero interligadas atravs de
seus servios expostos, como mostrado na figura 16.

Figura 16 Aplicaes Ligadas pelos servios

3.6.4 Protocolos utilizados

Anteriormente, no captulo 3, foi relatado com base em Barbieri (2001, p. 189)
que os Web Services, na teoria, podem funcionar apenas com o protocolo SOAP.
Porm, os Web Servies trabalham mais eficazmente com o uso em conjunto dos
protocolos WSDL, UDDI e SOAP. Em virtude da natureza aberta dos Web Services,
possvel para muitos consumidores acessar o mesmo servio exposto,
independente do sistema operacional ou linguagem de programao, desde que o
consumidor faa requisio de informao com a utilizao do protoloco SOAP em
um padro adequado. Na figura 17 mostrada a flexibilidade do uso do protocolo
SOAP. Com base nesses aspectos, que esses protocolos foram escolhidos para faz

59

parte da arquitetura proposta por este trabalho com o intuito de viabilizar uma melhor
integrao entre as aplicaes legadas e as novas.

Figura 17 Flexibilidade do protocolo SOAP.

Fonte: Martins (2005, p. 97).

3.6.5 Barramento de Servios Corporativos

O uso do barramento de servios corporativos (Enterprise Service Bus - ESB)
facilita o gerenciamento do conjunto dos componentes coordenados que so
expostos, de forma que ele tem a responsabilidade de gerenciar as conexes entre
os servios consumidores e provedores (COSTA; CARVALHO, 2007, p. 8). Dessa
forma, em qualquer alterao na localizao dos componentes provedores, os
consumidores no sofrero impacto, pois a interao no se d entre os prprios
componentes, e sim, atravs dos barramentos de servios.
O ESB caracterizado por ser a base dos servios, mensagens,
comunicaes, tranformaes e de segurana sobre a qual se pode plugar
aplicaes ou simplesmente interagir com elas. Ele segue os princpios de uma
arquitetura orientada a servios (SOA), possibilitando uma integrao com diferentes
tipos de servios, fortalecendo a flexibilidade que a soluo prope (MARTINS,
2005, p. 98).

60

Figura 18 Barramento de servio proposto

Na figura 18 ilustrado o ESB proposto pela arquitetura deste trabalho. Ele

pode simplificar as integraes entre as diversas aplicaes, onde antes era
necessrio conhecer a interface de cada diferente servio exposto na sua
arquitetura. Sendo assim, numa alterao em um servio nas arquiteturas que no
utilizam ESB, o impacto fortemente encontrado em vrios componentes. Com o
advento do ESB, as aplicaes s precisam conhecer uma interface (a do ESB).
Todo conhecimento necessrio dos padres e tecnologias so de responsabilidade
do ESB. H um isolamento das aplicaes e uma simplificao nas mudanas.

3.6.6 Segurana na Arquitetura Proposta

As tecnologias da arquitetura orientada a servios ainda esto em fase de
evoluo. Elas promovem atravs de suas diretrizes a facilidade de comunicao
entre servios de diferentes aquiteturas, interligados por uma rede como a Internet.
Considerando essa facilidade e as inovaes nos processo de negcios, Rocha
(2006, p. 42) afirmou que solues de segurana so extremamente necessrias
para atender os novos requisitos de segurana que surgem em virtude da
arquitetura SOA.
Segundo Rocha (2006, p. 44), no momento em que os conceitos de SOA
forem utilizados para expor servios com base em Web Services via Internet,

61

utilizando os padres abertos (XML, SOAP, WSDL, UDDI, etc), certamente ser
necessrio prover novos mecanismos de segurana. Em Web Services podemos
implementar a segurana com esses padres abertos em dois nveis: mecanismos
de segurana para o nvel de transporte e mecanismos de segurana voltados para
as mensagens. Cada um desses nveis de mecanismos de segurao dispe de
padres e protocolos especficos com o objetivo de atender aos diferentes tipos de
requisitos de segurana de cada negcio que a arquitetura SOA prope e esses
mecanismos podem ser implementados em conjunto ou separadamente.
Por outro lado, Rocha (2006, p. 49) e Pacheco (2000, p. 10) afirmaram que a
segurana na arquitetura SOA complexa e que grande parte das organizaes que
implementam a arquitetura orientada a servios deixam para segundo plano os
aspectos de segurana. A arquitetura proposta por este trabalho tambm deixou a
segurana para um segundo passo. E tambm, inicialmente, os servios sero
expostos apenas dentro da prpria instituio. Porm, os aspectos de segurana
ficaram para ser viabilizados no futuro, como tambm, a exposio de servios na
internet.
3.6.7 Gerenciamento de mudanas
Durante o planejamento de um sistema acordado o escopo do projeto.
Porm, durante a sua execuo podem ocorrer alteraes de escopo. O cliente deve
ficar ciente dos impactos da solicitao de mudana de requistitos. H tambm, a
possibilidade de alteraes de requisitos que j estejam em produo. Na
arquitetura proposta os servios que j esto em uso pelos usurios ou j
codificados e no implantados devem passar pelo procedimento de solicitao de
mudanas. Esse procedimento retratado pelos seguintes passos:
a) Abrir a solicitao, o usurio ou arquiteto responsvel pelo servio que
ser alterado solicita uma alterao atravs de um formulrio que deve ser
encaminhado para o grupo de arquitetos da instituio;
b) Avaliao da solicitao, o grupo de arquitetos recebe a solicitao e d
um parecer de atendimento da solicitao.

62

Execuo e notificao da solicitao, o arquiteto executa a alterao do

servio e aps a concluso notifica ao usurio sobre a implantao do servio
alterado;
3.6.8 Mapeamento dos requisitos
Durante a implantao dos cases foi observado que podem ocorrer
divergncias entre os requisitos dos servios e as funcionalidades legadas. Para
resolver esse problema a equipe de arquitetos executa um questionrio junto aos
clientes dos servios conflitantes com os questionamentos sobre a quantidade de
requisitos atendidos pela funcionalidade legada e tambm a quantidade atendida
pelo novo servio. Aps o resultado do questionrio o grupo de arquitetos da
organizao faz uma avaliao e fornece ao analista de sistemas responsvel pelo
projeto um parecer sobre os requisitos que sero atendidos pelo novo servio em
relao aos requisitos que eram pela funcionalidade legada.

63

CAPTULO 4
4 CASES NA ORGANIZAO
Neste

captulo

sero

apresentados

alguns

exemplos

que

foram

implementados fazendo uso da arquitetura proposta por este trabalho e os passos

para a implementao da arquitetura proposta por este trabalho. Salientamos que os
cases foram escolhidos pela equipe de desenvolvimento de sistemas da instituio
estudada.

4.1 IMPLEMENTAO DA ARQUITETURA

Nos captulos anteriores foram apresentados os conceitos e modelos
relacionados as tecnologias e a arquitetura de integrao proposta por este trabalho.
Na organizao estudada o ambiente arquitetural de softwware muito
heterogneo, como j foi relatado anteriormente. Para a implementao dessa
arquitetura devemos seguir os seguintes passos:
a) Selecionar os primerios servios - incialmente, a equipe de arquitetos
da organizao seleciona as funcionalidades em comuns nas aplicaes
legadas e novas que so candidatas a servio para criar um nico ponto
de entrada da informao;
b) Mapear as funcionalidades - logo aps, realizamos o mapeamento das
funcionalidades junto ao usurio responsvel pelos dados, e realizamos o
processo de transformao das regras de negcios em servios;
c) Codificar os provedores de servios - em seguida, os projetistas da
organizao inciam a codificao dos Web Services

que sero os

servios mapeados anteriormente pelos arquitetos;

d) Criar os WSDL - o prximo passo, criar o WSDL que servir de guia
referencial para os consumidores, em relao aos consumidores. Nele
necessrio descrever todos os mtodos que o servio realizar;
e) Implementar o ESB - neste passo, devemos viabilizar o barramento de
servio corporativo atravs de alguma ferramenta, que tem a finalizade de
gerenciar as conexes entre os servios consumidores e provedores;

64

f)

Codificar os consumidores de servios - logo aps, os projetistas

implementam os consumidores

g) Registrar os servios - em seguida, necessrio registrar os servios

criados no servidor de UDDI;
h) Disponibilizar os servios no ESB - e por fim, disponibilizar os
provedores e consumidores no barramento de servios corporativo.

4.2 CASES E SERVIOS

Os servios expostos foram projetados com o objetivo de minimizar os altos
custos de manutenibilidade com as aplicaes legadas, aumentar o reuso das
informaes corporativas e viabilizar uma melhora na integrao entre as diversas
aplicaes com suas arquiteturas proprietrias.
Um dos grandes desafios encontrados durante o desenvolvimento de
sistemas com base em componentes justamente identificar que trechos de cdigo
podero vir a ser componentizados. Possivelmente, os padres de componentizao
podem facilitar a obteno de uma uniformidade na construo dos componentes,
facilitando assim, a integrao e a manuteno. Na figura 19 est ilustrada a
interao entre as aplicaes e os componentes com seus servios expostos. Nessa
figura observado o reuso da informao de Unidade Geogrfica e Pessoa pelas
aplicaes G-SEC, Gesto TOPA, Almoxarifado e SIAT.
O servio Unidade Geogrfica fornece os dados geogrficos com base nas
regras e conceitos da organizao estudada atravs do ESB. Por exemplo, a diviso
geogrfica dos municpios por DIREC (Diretoria Regional de Educao) e os dados
de municpios da Bahia. Os dados de DIREC so consumidos pelo mdulo de
Contratos e Convnios da aplicao G-SEC. J os dados de Municpios so
consumidos pelos mdulos Contratos e Convnios, Gesto TOPA e Almoxarifado da
aplicao G-SEC e o mdulo de Logstica da aplicao SIAT. J o servio Pessoa
que centraliza os dados dos servidores da SEC consumido pelo mdulo de
Contratos e Convnios e Almoxarifado da aplicao G-SEC e o mdulo de Logstica
da aplicao SIAT.

65

Figura 19 interao das aplicaes com os componentes

4.2.1 Unidade Geogrfica

Com o passar do tempo e com a passagem de diversas empresas
tercerizadas na SEC foram surgindo uma variedades de arquiteturas de softwares.
Com isso, gerando uma srie de problemas, como por exemplo, o espalhamento das
informaes de forma no controlada, que resultou no clssico problema de
inconsistncia dos dados, quando os mesmos eram solicitados pelos gestores. Um
exemplo desse tipo de informao a diviso geogrfica do Estado da Bahia em
relao organizao. Existem hoje diversos sistemas com as informaes sobre
Estado, Municpio, Territrio e Direc.
O servio exposto de Unidade Geogrfica veio para unificar as informaes
de Estado, Municpio, Territrio e Direc. Na figura 20 mostrado o diagrama de
classes de Unidade Geogrfica.

66

Figura 20 O diagrama de classes de Unidade Geogrfica

67

Atualmente,

todos

os

sistemas

em

desenvolvimento

ou

serem

desenvolvidos, que necessitarem dessas informaes, iro consumir o Web Service

de Unidade Geogrfica. Com isso, reduziremos o espelhamento das informaes. J
as aplicaes legadas que tambm necessitam fazer uso dessas informaes sero
gradativamente alteradas para consumir este servio.

4.2.2 Pessoa
Outro servio exposto o Pessoa, cujo principal papel fornecer informaes
sobre os servidores estatais. Atualmente, no parque computacional dos sistemas
legados existe uma aplicao que gera todas as informaes de recursos humanos
dos servidores da SEC. Para uma melhor integrao entre essa aplicao e as
demais que esto sendo construdas foi selecionado esse servio com o objetivo de
fornecer tais informaes atravs de Web Services. Por exemplo, uma aplicao
necessita das informaes de endereo, situao funcional, cargo, o valor de uma
determinada gratificao, dentre outros, dos servidores estatais. Esse servio
responsvel por disponibilizar esse tipo de informao.
Na figura 20b ilustrado o digrama de classes do servio pessoa. Nesse
modelo podemos observar que existe uma entidade denominada Pessoa, que
representa

generializao

de

Pessoa

as entidades

PessoaFisica

PessoaJuridica que represento as especializaes de Pessoa.

4.2.3 G-SEC
J mencionamos alguns dos cases que esto expondo servios, como
Unidade Geogrfica e Pessoa. Hoje a aplicao G-SEC a grande consumidora dos
atuais servios que esto sendo expostos com a adoo da arquitetura SOA. Essa
aplicao est sendo concebida com base no conceito de componentizao, onde a
cada nova funcionalidade idealizada pelos usurios, analisada pela equipe de
desenvolvimento para deterninar a possibilidade de reusar algum componente. Hoje
ela j possui os mdulos de Almoxarifado, Contratos e Convnios e Pessoa. Ela j
est consumindo os servios de Unidade Geogrfica e Pessoa mencionados neste
captulo.

68

Figura 20b O diagrama de classes de Pessoa

69

Figura 21 Relao do G-SEC com Unidade Geogrfica e Pessoa

Na figura 21 ilustrada a relao da aplicao G-SEC com os componentes
Unidade Geogrfica e Pessoa. Nela os componentes fornecem dados para

aplicao G-SEC atravs de um Web Service.

Com o passar do tempo a aplicao corporativa G-SEC tende a crescer
bastante e fortalecer o reuso das informaes atravs dos servios expostos. Segue
a descrio dos mdulos do G-SEC que fazem uso dos servios pela arquitetura
proposta.

4.2.4 Contratos e Convnios

O sistema Contratos e Convnios mais um mdulo do G-SEC, com a
finalidade bsica de gerir os contratos e convnios firmados entre SEC e os demais
participantes, projetos e/ou programas solicitados pelo governo. Ele nasceu para
suprir a necessidade da SEC de ter uma ferramenta e processos adequados para

70

um eficiente gerenciamento dos seus contratos e convnios, objetivando melhor

acompanhamento

dos

mesmos.

Anteriormente,

SEC

encontrava-se

em

dificuldades para fazer a gesto dos seus contratos e convnios em virtude do

volume de dados a serem controlados e da carncia de uma ferramenta
adequadamente informatizada, para apoio gesto e processos adequados para
melhor controle dos dados. Ele tem como requisitos principais o registro do
contrato/convnio,

acompanhamento

fsico

financeiro,

alterao

do

contrato/convnio (aditamento, prorrogao, renovao e apostila), administrao

dos tipos de contrato/convnio e relatrios e distrato (quebra de um contrato) dos
mesmos. Na figura 22 ilustra uma parte do diagrama de caso de uso da referida
aplicao com um destaque aos relacionados com os servios expostos. No caso de
uso Cadastrar Unidade Oramentria tem uma regra que descreve a relao com o
servios de Unidade Geogrfica. J no caso de Cadastrar Dados Participe faz
referncia ao servios exposto Pessoa.

Figura 22 Parte dos casos de uso do projeto Contratos e Convnios

Os servios expostos atravs de Web Services, como proposto neste

trabalho, podem ser consumidos por qualquer aplicao que faa parte da

71

arquitetura na organizao. Na figura 23 tambm foi destacada a classe que

consome o servio exposto pelo componente de Unidade Geogrfica. J na figura
23b ilustrada a

Figura 23 Entidade de Contratos e Convnios destacada em relao ao servio Unidade

Geogrfica

Figura 23b Entidade de Contratos e Convnios destacada em relao ao servio Pessoa

72

4.2.5 Almoxarifado
O mdulo de Almoxarifado tem como finalidade gerenciar o almoxarifado
escolar da SUPEC/DISUP integrando Coordenao de Suprimento Escolar (CSE)
com seus almoxarifados ou centros de distribuio (CD). Ele veio para melhorar
seus controles e processos do almoxarifado. O sistema est disponvel para outros
setores da SEC que tenham interesse em sua adoo levando em considerao o
fato de que o sistema contempla apenas as regras de negcio para atendimento das
necessidades do almoxarifado da Ribeira, CD, recebimento e expedio de
materiais dos mesmos.
O referido sistema/mdulo acaba atingindo os processos de recebimento,
expedio, devoluo de itens, auditoria, inventrio, cadastro de famlia de itens,
cadastro e fragmentao de itens, cadastro de fabricantes, cadastro de
fornecedores, cadastros de destino, movimentao de itens dentro e entre
almoxarifados e centros de distribuio. Ele integrado com os demais mdulos do
sistema da SEC, compartilhando informaes e processos de gesto de cadastros.
O componente de Unidade Geogrfica tambm faz integrao com o mdulo
de Almoxarifado do G-SEC. Nas figuras 24 e 24b so ilustrados trechos dos casos
de uso com destaque aos relacionamentos entre o servio expostos e as regras de
negcio deste mdulo dos casos de uso Cadastrar Conferente, Cadastrar
Almoxarifado e Cadastrar Estrutura Fsica do Almoxarifado respectivamente.
Na figura 25b destacada a entidade do diagrama de classes que faz
referncia ao servio exposto de Unidade Geogrfica nas entidades LoteDirec e
AloxarifadoMunicipio com o objetivo de realizar o caso de uso Cadastrar
Almoxarifado e Cadastrar Estrutura Fsica do Almoxarifado. J a entidade
Conferente, fez uso do servio exposto do componente Pessoa, para tambm
realizar o caso de uso Cadastrar Conferente, que tambm ilustrado na figura 25.

73

Figura 24 Parte dos casos de uso do projeto Almoxarifado do servio Pessoa

Figura 24b Parte dos casos de uso do projeto Almoxarifado do servio Unidade Geogrfica

74

Figura 25 Entidades de Almoxarifado em relao ao servio Unidade Geogrfica

Figura 25b Entidades de Almoxarifado em relao ao servio Pessoa

75

4.2.6 Gesto TOPA

O mdulo de Gesto TOPA baseado no programa de governo Todos pela
Alfabetizao (TOPA), com a finalidade de gerir as informaes extras que no so
contempladas pelo sistema SBA do MEC. Este mdulo possui uma integrao com o
SBA atravs de impostaes peridicas.
Todos os dados do SBA devem ser importados semanalmente, exceto a
taxa de analfabetismo que importada do Censo, dos municpios da Jurisdio da
DIREC e da distribuio por territrios de identidade. Isso no impede que, quando
necessrio, ocorram importaes fora desse prazo em carter de urgncia.
O Gesto TOPA possui a integrao de informaes com o componente
Unidade Geogrfica. Na figura 26 mostrada uma parte dos casos de uso deste
mdulo, onde destacado o caso de uso que faz referncia ao servio exposto pelo
componente. J na figura 27 ilustrada a entidade do diagrama de classes que
tambm faz referncia ao referido componente.

76

Figura 26 Caso de uso do Gesto TOPA X Servio Exposto

77

Figura 27 Entidade do Gesto TOPA X Servio Unidade Geogrfica

4.2.7 SIAT
No Instituto Ansio Teixeira (IAT) h tambm a composio do quadro
heterogneo de arquiteturas de software. Com o objetivo de atender s
necessidades de gerenciamento dos eventos, a SEC propiciou uma a soluo com
base nos novos moldes de desenvolvimento. O outro grande consumidor dos
servios o Sistema de Gerenciamento de eventos do IAT, que tem a finalidade de
gerir os eventos (cursos, palestra, reunio, etc) realizados. Essa aplicao est
atualmente consumindo os servios expostos de Unidade Geogrfica e Pessoa.

78

O IAT um rgo em regime especial de administrao direta da SEC, que

tem como finalidade planejar, coordenar, acompanhar e executar as aes de
formao dos profissionais da educao de todo o Estado. O processo de Logstica
dos Eventos, que o maior da instituio, no contava com qualquer ferramenta
informatizada para apoi-lo. Todas as atividades eram realizadas manualmente e a
documentao gerada era arquivada em meio fsico, o que faz com que o manuseio
da informao e extrao de relatrios se torne deficiente. Isso gerava dificuldade
em atender as requisies no somente de clientes internos da Secretaria, que
planejam os eventos, como tambm aos clientes externos a exemplo do Tribunal de
Contas do Estado.
O SIAT necessita intercambiar informaes de municpios e de pessoas. Por
isso, houve a necessidade de consumir os servios expostos pelos componentes de
Unidade Geogrfica e Pessoa. Na figura 28 est em destaque o caso de uso, que se
relaciona com o servio expostos de Unidade Geogrfica.

Figura 28 - Casos de usos do SIAT X Servio Pessoa

79

Na figura 28b temos a relao entre o caso de uso Confirmar Inscrio com
o servio Pessoa, que faz relao com a entidade Incricao do diagrama de classes
ilustrado na figura 29.

Figura 28b - Casos de usos do SIAT X Servio Unidade Geogrfica

80

Figura 29 - Entidade do SIAT X Servio Unidade Geogrfica

81

4.3 ANLISE DOS RESULTADOS

Os cases que foram implementados durante a elaborao deste trabalho
deram origem a alguns dados importantes. Essas informaes obtidas aps uma
anlise de comparao entre os sistemas novos e legados com base nas horas
trabalhadas em cada sistema resultaram nos seguintes dados nas figuras 30 e 31:

Figura 30 Comparativo entre as aplicaes com base nas horas trabalhadas

Figura 31 Antes e depois da implantao dos servios

82

Na figura 31 ilustrado um comparativo entre trs aplicaes com base nos

FPs (Function Point) e nas horas gastas para construir esses pontos dos sistemas.
Fica evidente que as aplicaes, Gesto TOPA e SIAT Logstica, que foram
construdas com o reuso dos servios gastaram um menor valor de horas em
relao aplicao legada Gesto Municipalizao. J na figura 32 mostrado
outro comparativo com base nas horas gastas para manter as aplicaes legadas,
antes e depois de reusar os servios da arquitetura proposta por este trabalho. Com
base nos dados levantados e analisados antes e depois dos reusos pelas aplicaes
dos servios Unidade Geogrfica e Pessoa foi evidenciado que h um ganho real na
produtividade com a manuteno e o desenvolvimento das aplicaes.

83

CAPTULO 5
5 CONCLUSO
Este captulo apresenta as consideraes finais sobre o uso da SOA na
integrao entre s aplicaes legadas e as novas utilizando a SEC como case. Ele
est dividido O PROBLEMA, A SOLUO, DIFICULDADES DE IMPLANTAO DA
ARQUITETURA,

IMPLANTAO

GRADATIVA

DA

SOA,

VANTAGENS

DESVANTAGENS DE SOA e TRABALHOS FUTUROS.

5.1 O PROBLEMA
A SEC, ao longo do tempo vem terceirizando sua TI. Essa estratgia adotada,
com o passar do tempo, por causa dos processos licitatrios, j que se trata de uma
organizao pblica, possibilitou o surgimento de diversas empresas de TI no setor
de informtica dentro da SEC. Essa diversidade foi um dos fatores que marcaram o
surgimento de diversas arquiteturas de softwares.
Todas as organizaes pblicas ou privadas acabam vendo o importante
papel da informatizao de seus servios. No decorrer do tempo a revoluo
tecnolgica mudou muito os paradigmas de gesto empresarial. O crescimento
exponencial, inovao e automao dos processos da organizao associada com a
velocidade das informaes so tambm fatores que esto acelerando essa
revoluo e o surgimento de diversas arquiteturas e tecnologias dentro da SEC.
Atualmente, com o mercado de TI voltado para fornecer informaes cada vez
mais rpidas e confiveis, mesmo que seja em uma instituio pblica, onde seu
objetivo prestar servios sociedade gratuitamente, Ela tambm deve pensar em
fornec-los da melhor forma. Com o surgimento de uma variedade de arquiteturas
de softwares, como j foi relatado no captulo 1, algumas informaes acabaram
ficando redundantes de forma no controlada.
Com um parque de sistemas bastante heterogneos em relao arquitetura
de software, a integrao entre esses diversos ambientes muito custosa. Em
alguns casos, quando uma nova funcionalidade requisitada, de custo muito alto, a
organizao opta por no implement-la. Em virtude dos aspectos at aqui

84

apresentados foi que surgiu a motivao para propor uma nova arquitetura para
melhorar a integrao entre os sistemas legados e as novas aplicaes que estaro
por vir.

5.2 A SOLUO
Com o quadro de uma variedade de arquiteturas de softwares encontrado na
SEC, propomos uma soluo para melhorar a integrao entre as aplicaes
legadas e as novas. Essa soluo baseada na adoo da arquitetura orientada a
servios.
A arquitetura proposta foi idealizada com o intuito de oferecer servios atravs
de Web Services, onde o intercmbio entre as aplicaes, troca de mensagens entre
os consumidores e provedores de servios, so realizadas utilizando padro SOAP
com XML. E os padres WSDL e UDDI do suporte com o intuito de possibilitar a
descrio e localizao dos servios que so expostos.
Um dos fatores relatados por vrios autores, como por exemplo, Pulier;
Taylor; Gaffney (2008, p. 83) e Rocha (2006, p. 28) que h um ganho na
reusabilidade das funcionalidades atravs dos servios expostos. Na organizao
estudada foi tambm observado esse ganho, onde o reuso das funcionalidades,
principalmente das aplicaes legadas, elevou a produtividade no desenvolvimento
e manuteno das aplicaes e uma considervel melhora no espalhamento das
informaes, conforme analise relatada no captulo anterior.
Outro aspecto defendido pelos adeptos de SOA a portabilidade das
arquiteturas, ou seja, caso no futuro a instituio deseje mudar a tecnologia de seus
servios expostos, Web Services, as aplicaes legadas no sofrero grandes
impactos, j que a troca de mensagens entre elas realizada atravs de padres
abertos. Mesmo sendo esse aspecto um fator muito positivo, ele no foi detectado,
j que durante a elaborao deste trabalho no houve alterao na tecnologia
adotada para expor os servios escolhidos, e, inicialmente, os mesmos sero
expostos apenas na intranet da prpria organizao.
A flexibilidade que a SOA prega fica muito mais forte e evidenciada com o uso
de ESB. Os componentes so interligados atravs desse barramento. Com isso,

85

facilita a manutenibilidade dos servios desde que suas interfaces no sejam

alteradas, ou seja, quando um servio sofrer alterao de sua localizao, os
servios que o esto consumindo no necessitaro sofrer alterao. O uso de um
ESB na arquitetura fornece todo esse poder de flexibilidade, mas temos que levar
em considerao os custos e a quebra de paradigma quando estivermos fazendo o
planejamento de sua implementao. Em algumas organizaes pode no dar muito
certo.

5.3 DIFICULDADES DE IMPLANTAO DA ARQUITETURA

A engenharia de software vem buscando, fortemente, maneiras otimizadas
para o desenvolvimento de novas aplicaes. Porm, o que encontramos nas
organizaes, como na SEC, uma diversidade de softwares que no foram
implementados com essa viso. A arquitetura orientada a servios vem com a
proposta de integrar esses softwares antigos com os novos atravs da exposio
de servios.
Para uma implantao bem sucedida temos que enfrentar alguns obstculos.
A quebra de paradigma um desses aspectos, onde o desenvolvimento de software
em muitos casos era departamentalizado, ou seja, a equipe de desenvolvimento no
pensava em componentes corporativos. Como j relatado anteriormente, com a SOA
devemos pensar nos servios corporativos. Outro fator importante a resistncia de
aquisio dos novos conhecimentos pelos colaboradores dentro da organizao. A
SOA vem com propostas novas, por isso, devemos ter uma preocupao em
socializar o conhecimento dentro da instituio para que possamos obter o sucesso
na implantao dessa nova arquitetura.

5.4 IMPLANTAO GRADATIVA DA SOA

Para propiciar um melhor sucesso na implantao da SOA dentro das
organizaes com o mesmo perfil da SEC, durante a realizao deste trabalho foi
necessrio realizar a implementao dessa arquitetura de maneira gradativa, para
enfrentarmos as dificuldades mencionadas anteriormente. Inicialmente, devemos
definir as funcionalidades que sero os servios. Em uma segunda etapa, devem
ocorrer s implementaes dos servios escolhidos anteriormente. Logo em

86

seguida, devemos implementar os consumidores. E por fim, no quarto passo,

devemos criar o barramento de servios corporativos. Seguindo essas diretrizes na
ordem, a implantao da arquitetura orientada a servios tem uma forte
possibilidade de chegar ao sucesso.

5.5 VANTAGENS E DESVANTAGENS DE SOA

As organizaes adotam a arquitetura orientada a servios para fazer uso das
vantagens que ela proporciona, tornando a instituio uma fornecedora de servios
com uma melhor qualidade para a sociedade. A SOA viabiliza um aumento na
produtividade, eleva o reuso das aplicaes legadas, propicia uma reduo nos
custos de manutenibilidade, d uma maior flexibilidade s novas aplicaes e
potencializa a portabilidade de funes de negcio da organizao.
Como nem tudo puramente positivo, temos na SOA o problema de
gerenciamento de segurana. Segundo Rocha (2006, p. 35) a complexidade na
interoperabilidade dos mecanismos de segurana que surgem atravs dos novos
processos de negcio pode contribuir para dificultar a implantao desta arquitetura.
Os mecanismos de segurana esto em evoluo como a prpria SOA, mas eles
ainda no esto solidificados para garantir uma segurana dos dados da
organizao. Por isso, ao optarmos pelo uso da arquitetura orientada a servios
temos que destacar um estudo de como ser a segurana adotada.

5.6 TRABALHOS FUTUROS

Uma sugesto para um trabalho futuro a realizao de um estudo focado
nos mecanismos de segurana que devem ser adotados em organizaes com as
mesmas caractersticas da que foi estudada com o objetivo de fortalecer esses
mecanismos no mundo da SOA.
Outra possibilidade realizar um estudo sobre o gerenciamento de Rede de
SOA, descrevendo o quo complexo ele pode ser. Seu objetivo seria estudar o
gerenciamento, transporte, roteamento e segurana de mensagens para viabilizar
uma rede de SOA confivel.

87

E por fim, pode ser feito um estudo de uma metodologia bem definida para
realizar os mapeamentos de maneira adequada das funcionalidades e/ou requisitos
para os servios.

88

REFERNCIAS
ARANTES, Juliana Amaral; WESTPHALL, Carlos Becker; CUSTDIO, Ricardo
Felipe. Modelo analtico para avaliar plataformas cliente/servidor e agentes
mveis aplicado gerncia de redes. Santa Catarina, 2003. Disponvel em:
<http://www.lbd.dcc.ufmg.br:8080/colecoes/sbrc/2002/027.pdf>. Acesso em: 19 jul.
2008.
ALMEIDA JUNIOR, Raimundo Araujo de. Alinhamento estratgico entre os objetivos
organizacionais e sistemas de informao da secretaria da educao do estado da
bahia. Revista de Tecnologia Empresarial (rte), Salvador, p.1-15, 10 set. 2005.
Semestral.
AZEVEDO, Leonardo Guerreiro et al. Desenvolvimento baseado em
componentes experincias de sucesso. 2002. Disponvel em:
<http://www2.dc.ufscar.br/~valdirene/Publications/CLEI2002.pdf>. Acesso em: 29 jul.
2008.
BARBIERI, Carlos. BI-business intelligence: modelagem & tecnologia. Rio de
Janeiro: Axcel Books do Brasil, 2001.
BECKER, Aleksader Knabben; CLARO, Daniela Barreiro; SOBRAL, Joo Bosco.
Web services e XML um novo paradigma da computao distribuda.
Florianpolis, 2002. Disponvel em:
<http://www.inf.ufsc.br/~danclaro/download/ArtigoWebServices.pdf>. Acesso em: 12
jul. 2008.
BERGEY, Jony; BRIEN, Lenthi; SMITH, Douglas. Using the optins analysis for
reengineering (OAR) method for mining components for a product line. In:
PROCEEDINGS OF THE SECOND SOFTWARE PRODUCT LINE CONFERENCE,
2., 2002, San Diego. Software Produc Lines. Berlin: Splc2, 2002. p. 1 - 147.
BERTONI, Guilherme Machado. Uma arquitetura baseada em web services com
diferenciao de servios para integrao de sistemas embutidos a outros
sistemas. 2006. 131 f. Dissertao (Mestrado) - Universidade Federal de Santa
Catarina, Florianpolis, 2006.
BOND, Martins et al. Aprenda J2EE com EJB, JSP, servilets, JNDI, JDBC e XML.
So Paulo: Makron Books, 2003.
BRAGA, Luciano Rogrio Perdigo. Curso bsico de programao natural.
Disponvel em: <http://www.geocities.com/guia_rapido/natural_basico.pdf>. Acesso
em: 21 jul. 2008.

89

PMI - PROJECT MANAGEMENT INSTITUTE. Um guia do conjunto de

conhecimentos em gerenciamento de projetos: PMBOK. So Paulo, 2004.
COSTA, Ivanir; CARVALHO, Antonio Rodrigues. Tendncias sobre a arquitetura
orientada a servios - SOA. Disponvel em:
<http://www.abepro.org.br/biblioteca/ENEGEP2007_TR670485_9968.pdf>. Acesso
em: 11 ago. 2008..
CUNHA, Mnica. Desafios de integrao de sistemas: roadmap, evoluo
tecnolgica e impactos organizacionais. Disponvel em:
<http://www.redenet.edu.br/publicacoes/arquivos/20071227_151130_GEST013.pdf>. Acesso em: 03 ago. 2008.
CUMMINS, Fred A.. Integrao de sistemas EAI (enterprise application
integration). Rio de Janeiro: Campus, 2002.
DEGAN, Joecy Otsuka Corts. Integrao de dados corporativos: uma proposta
de arquitetura baseada em servios de dados. 2005. 115 f. Dissertao (Mestrado) Universidade Estadual de Campinas, Campinas, 2005.
DANTAS, Alexandre. Suporte a padres no projeto de software. Disponvel em:
<://www.lbd.dcc.ufmg.br:8080/colecoes/sbes/2002/038.pdf>. Acesso em: 17 ago.
2008.
FARLEY, Jim. Projetos prticos com JBoss Seam. Rio de Janeiro: Cincia
Moderna, 2008.
FONTANETTE, Valdirene. AMGraA: uma abordagem para migrao gradativa de
aplicaes legadas. 2005. 144 f. Dissertao (Mestrado) - Universidade Federal de
So Carlos, So Carlos, 2005.
GARCIA, Simone de Souza; SHINOTSUKA, Tania Hiromi. EAI - enterprise
application integration. Disponvel em:
<http://www.bax.com.br/Bax/orientacao/alunos/PSI/EAI1.pdf>. Acesso em: 29 jul.
2008.
GOMES, Maria Cristina F. et al. Certificao da utilizao de padres de projeto
no desenvolvimento orientado a modelos. Disponvel em:
<http://www.lbd.dcc.ufmg.br:8080/colecoes/sbes/2006/005.pdf>. Acesso em: 20 ago.
2008.
IANSITI, Marco; CLARK, Kim Brith. Integration and dynamic capability: evidence
from product development in automobiles and mainframe computers. Disponvel em:
<http://icc.oxfordjournals.org/cgi/content/abstract/3/3/557>. Acesso em: 17 ago.
2008.
IBM CORPORATION.IBM SOA Foundation: providing what you need to get started
with SOA. New York: Ibm Corporation, 2005.

90

LARENTIS, Andresa Vargas. Aruba: uma arquitetura para gerao de servios a

partir de sistemas legados de forma intrusiva. 2007. 104 f. Dissertao (Mestrado) Universidade do Vale do Rio Dos Sinos, So Leopoldo, 2007.
LEWIS, Ghonn; MORRIS, Elton; SMITH, Douglas. Migration of lagacy components to
service-oriented architectures. The Dod Software Tech, New York, v. 8, n. 3, p.1-7,
03 out. 2005. Semestral.
MACHADO, Janes Countis. Um estudo sobre o desenvolvimento orientado a
servios. 2004. 125 f. Dissertao (Mestrado) - Pontifcia Universidade Catlica, Rio
de Janeiro, 2004.
MACIEL, Diego Rabelo. Implementao de um disco virtual seguro baseado em
Web Services. 2007. 74 f. Monografia (Graduao) - Universidade Federal do
Maranho, So Lus, 2007.
MARTINS, Victor Manuel Moreira. Integrao de sistemas de informao:
perspectivas, normas e abordagens. 2005. 218 f. Dissertao (Mestrado) Universidade do Minho, Lisboa - Portugual, 2005.
MICROSOFT. Learn about service oriented architecture (SOA). New York:
Microsoft Corporation, 2006a.
MICROSOFT. Web services and the microsoft. New York: Microsoft Corporation,
2006b.
NATIS, Yefim Verbes. Service-oriented architecture scenario. Disponvel em:
<http://www.g2r.com/DisplayDocument?doc_cd=114358>. Acesso em: 05 ago. 2008.
MAIA, Natanael Elias Nascimento. ODYSSEY-MDA: uma abordagem para
transformao de modelos. Disponvel em:
<http://reuse.cos.ufrj.br/prometeus/publicacoes/DissertacaoMScNatanaelMaia.pdf>.
Acesso em: 15 ago. 2008.
OASIS. Reference Model for Service Oriented Architeture V 1.0. Disponvel em:
<http://www.fapepi.pi.gov.br/novafapepi/ciencia/documentos/REFRAT%D4METRO.P
DF>. Acesso em: 20 jul. 2008.
PACHECO, Viviane. EAI: a sigla da integrao dos sistemas internos e externos.
2000. Disponvel em:
<http://www.neogrid.com.br/portugue/imprensa/imprensa/surftrade/25.../Surftrade_Br
asil.html>. Acesso em: 15 jul. 2008.
PULIER, Eric; TAYLOR, Hugh; GAFFNEY, Paul. Compreendendo SOA
Corporativa. Rio de Janeiro: Cincia Moderna, 2008.
ROCHA, Claudio Aparecido. Um estudo sobre os desafios de segurana na
adoo da Arquitetura Orientada a Servios. 2006. 147 f. Dissertao (Mestrado)
- Universidade Estadual de Campinas, Campinas, 2006.

91

SAMPAIO, Cleuton. SOA e Web Service em Java. Rio de Janeiro: Brasport, 2006.
SANTOS JUNIOR, Alfredo Luiz Dos. Integrao de sistemas com Java. Rio de
Janeiro: Brasport, 2007.
SOMMERVILLE, Ivan. Engenharia de software. So Paulo: Engenharia de
Software, 2005.
STEFANI, Eduardo; SEKI, Yuri. Engenharia de software cliente/servidor.
Disponvel em: <http://www.eduardostefani.eti.br/bennett/engsoftware/clienteservidor.pdf>. Acesso em: 01 jul. 2008.
TAIT, Tania Fatima Calvi; PACHECO, Roberto Carlos Dos Santos. Proposio de
um modelo de arquitetura de sistemas de informao para o setor pblico.
Disponvel em:
<http://periodicos.uem.br/ojs/index.php/ActaSciTechnol/article/viewFile/2783/1841>.
Acesso em: 07 jul. 2008.
W3C. Web Service Architecture: W3C working group. Disponvel em:
<http://www.w3.org/TR/ws-addr-arch/>. Acesso em: 13 jul. 2008.

92

APNDICE A Cdigos dos Servios

UNIDADE GEOGRFICA
/*
* UnidGeograficaService.java
*
*/
package br.gov.ba.sec.unidgeografica.ws;
import br.gov.ba.sec.unidgeografica.dao.UnidGeograficaDao;
import br.gov.ba.sec.unidgeografica.service.UnidGeograficaService;
import br.gov.ba.sec.unidgeografica.type.EstadoType;
import br.gov.ba.sec.unidgeografica.type.MunicipioType;
import java.util.List;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.jws.WebService;
import javax.persistence.PersistenceContext;
import javax.annotation.PostConstruct;
import javax.jws.WebMethod;
import javax.jws.WebParam;
/**
*
* @author fcsilva
*/
@Stateless
@WebService(name="UnidGeograficaWebService", portName="UnidGeograficaServicePort")
public class UnidGeograficaWebService implements UnidGeograficaService {
@PersistenceContext
private EntityManager em;
private UnidGeograficaDao unidGeograficaDao;
@PostConstruct
public void carregaEscola() {
unidGeograficaDao = new UnidGeograficaDao(em);
}
@WebMethod
public List<EstadoType> obterEstados() {
return unidGeograficaDao.obterEstados();
}
@WebMethod
public List<MunicipioType> obterPorCodigoIbge(@WebParam(name = "estado") String estado) {
return unidGeograficaDao.obterPorCodigoIbgeEstado(estado);
}
@WebMethod
public List<MunicipioType> obterPorNomeEstado(@WebParam(name = "estado") String estado) {
return unidGeograficaDao.obterPorNomeEstado(estado);
}
}
*

93

* To change this template, choose Tools | Templates

* and open the template in the editor.
*/
package br.gov.ba.sec.unidgeografica.service;
import br.gov.ba.sec.unidgeografica.type.EstadoType;
import br.gov.ba.sec.unidgeografica.type.MunicipioType;
import java.io.Serializable;
import java.util.List;
public interface UnidGeograficaService extends Serializable{
/**
* Obtm uma lista de estados
* @param escola
* @return
*/
List<EstadoType> obterEstados();
/**
* Obtm uma lista de municpios de acordo com o estado
* @param escola
* @return
*/
List<MunicipioType> obterPorCodigoIbge(String estado);
/**
* Obtm uma lista de municpios de acordo com o estado
* @param escola
* @return
*/
List<MunicipioType> obterPorNomeEstado(String estado);
}

*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package br.gov.ba.sec.unidgeografica.dao;
import br.gov.ba.sec.unidgeografica.type.EstadoType;
import br.gov.ba.sec.unidgeografica.type.MunicipioType;
import java.util.List;
import javax.persistence.EntityManager;
import javax.persistence.NoResultException;
import javax.persistence.Query;
public class UnidGeograficaDao {
private EntityManager em;
public UnidGeograficaDao(EntityManager em) {
this.em = em;
}
public List<MunicipioType> obterPorCodigoIbgeEstado(String codigoIbge) {

94

if (codigoIbge == null) {
return null;
}
try {
Query query = em.createQuery("select new " +
"br.gov.ba.sec.unidgeografica.type.MunicipioType(m.nome, m.codigoIbge, m.pai.nome,
m.pai.codigoIbge) " +
"from Municipio m where m.pai.codigoIbge=:codigoIbge and m.ativo = 1");
query.setParameter("codigoIbge", codigoIbge);
return query.getResultList();
} catch (NoResultException e) {
return null;
}
}
public List<MunicipioType> obterPorNomeEstado(String estado) {
if (estado == null) {
return null;
}
try {
Query query = em.createQuery("select new " +
"br.gov.ba.sec.unidgeografica.type.MunicipioType(m.nome, m.codigoIbge, " +
"m.pai.nome, m.pai.codigoIbge) from Municipio m where upper(trim(m.pai.nome))=
upper(:estado) " +
"and m.ativo = 1");
query.setParameter("estado", estado);
return query.getResultList();
} catch (NoResultException e) {
return null;
}
}
public List<EstadoType> obterEstados() {
try {
Query query = em.createQuery("select br.gov.ba.sec.unidgeografica.type.EstadoType(e.nome,
e.codigoIbge) " +
"from Estado e where e.ativo = 1");
return query.getResultList();
} catch (NoResultException e) {
return null;
}
}
}

PESSOA

package br.gov.ba.sec.pessoa.ws;
import java.text.ParseException;
import java.util.List;
import javax.annotation.PostConstruct;
import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebParam;

95

import javax.jws.WebService;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import br.gov.ba.sec.pessoa.dao.pessoaDao;
import br.gov.ba.sec.pessoa.entity.pessoa;
import br.gov.ba.sec.pessoa.service.pessoaService;
import br.gov.ba.sec.pessoa.util.DateUtil;
@Stateless
@WebService(serviceName = "pessoaWS", portName = "pessoaPort")
public class pessoaWebService implements pessoaService {
@PersistenceContext(unitName = "pessoaPU")
private EntityManager entityManager;
private pessoaDao pessoaDao;
@PostConstruct
public void CarregarEntityManegerpessoa() {
pessoaDao = new pessoaDao(entityManager);
}
@WebMethod
public Boolean isDiretor(@WebParam(name = "cadastro") Long cadastro) {
return pessoaDao.isDiretor(cadastro);
}
@WebMethod
public Boolean isProfessor(@WebParam(name = "cadastro") Long cadastro) {
return pessoaDao.isProfessor(cadastro);
}
@WebMethod
public List<pessoa> obterpessoaAtivo(@WebParam(name = "cpf") Long cpf,
@WebParam(name = "sexo") String sexo,
@WebParam(name = "dataNascimento") String dataNascimento) throws ParseException {
return pessoaDao.obterpessoaAtivo(cpf, sexo, DateUtil.toDate(dataNascimento));
}
@WebMethod
public pessoa obterpessoaAtivoPorCadastro(
@WebParam(name = "cadastro") Long cadastro) {
return pessoaDao.obterpessoaAtivoPorCadastro(cadastro);
}
}

package br.gov.ba.sec.pessoa.service;
import br.gov.ba.sec.pessoa.entity.pessoa;
import java.util.List;

import java.text.ParseException;
public interface pessoaService {

96

List<pessoa> obterpessoaAtivo (Long cpf, String sexo, String dataNascimento) throws

ParseException;
pessoa obterpessoaAtivoPorCadastro (Long cadastro);
Boolean isProfessor (Long cadastro);
Boolean isDiretor (Long cadastro);
}

package br.gov.ba.sec.pessoa.dao;
import br.gov.ba.sec.pessoa.entity.pessoa;
import java.util.Date;
import java.util.List;
import javax.persistence.EntityManager;
import javax.persistence.NoResultException;
import javax.persistence.Query;

public class pessoaDao {

private EntityManager entityManager;
public pessoaDao(EntityManager entityManeger) {
this.entityManager = entityManeger;
}
public pessoa obterpessoaAtivoPorCadastro(Long cadastro) {
String hql = "select s from pessoa s " +
"join fetch s.dadosPessoais join fetch s.planoCargo join fetch s.funcao " +
"join fetch s.orgao join fetch s.instrucao " +
"where s.cadastro = :cadastro and upper(s.situacao.ativo) = 'S'";
Query query = entityManager.createQuery(hql);
query.setParameter("cadastro", cadastro);
try {
return (pessoa) query.getSingleResult();
} catch (NoResultException cause) {
return null;
}
}
@SuppressWarnings("unchecked")
public List<pessoa> obterpessoaAtivo(Long cpf, String sexo,
Date dataNascimento) {
String hql = "select s from pessoa s " +
"join fetch s.dadosPessoais join fetch s.planoCargo join fetch s.funcao " +
"join fetch s.orgao join fetch s.instrucao " +
"where s.dadosPessoais.dadosPessoaisPK.cpf = :cpf " +
"and s.dadosPessoais.dadosPessoaisPK.sexo = :sexo " +
"and s.dadosPessoais.dataNascimento = :dataNascimento " +
"and upper(s.situacao.ativo) = 'S'";

97

Query query = entityManager.createQuery(hql);

query.setParameter("cpf", cpf);
query.setParameter("sexo", sexo);
query.setParameter("dataNascimento", dataNascimento);
try {
return query.getResultList();
} catch (NoResultException cause) {
return null;
}
}
public Boolean isProfessor(Long cadastro) {
String hql = "select s from pessoa s where s.cadastro = :cadastro " + " and
upper(s.situacao.ativo) = 'S' " + " and upper(s.planoCargo.cargo.cargo) like 'PROFESSOR%' " + " and
upper(s.planoCargo.cargo.ativo) = 'S' ";
Query query = entityManager.createQuery(hql);
query.setParameter("cadastro", cadastro);
try {
if (query.getSingleResult() != null) {
return true;
}
return false;
} catch (NoResultException cause) {
return false;
}
}
public Boolean isDiretor(Long cadastro) {
String hql = "select s from pessoa s where s.cadastro = :cadastro " + " and
upper(s.situacao.ativo) = 'S' " + " and upper(s.funcao.funcao) like 'DIRETOR%' ";
Query query = entityManager.createQuery(hql);
query.setParameter("cadastro", cadastro);
try {
if (query.getSingleResult() != null) {
return true;
}
return false;
} catch (NoResultException cause) {
return false;
}
}
}