dissertacao raimundo araujo de almeida junior
DESCRIPTION
sfsffsTRANSCRIPT
-
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
1 INTRODUO ................................................................................................... 14
1.1 HISTRICO E PROBLEMA.......................................................................... 14
1.2 MOTIVAO ................................................................................................ 16
1.3 OBJETIVO .................................................................................................... 17
1.4 ORGANIZAO ........................................................................................... 17
2 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 Sistemas legados e SOA Solues comerciais ............................ 42
3 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
4 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 ANLISE DOS RESULTADOS ..................................................................... 81
5 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, j 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 o 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 infra-
estrutura 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 e
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 e 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 e