ii
Agradecimentos
Aos meus pais e ao meu irmo pelos constantes incentivos, e em especial minha esposa Cristina, pelo apoio e motivao que sempre manifestou.
Ao meu orientador, Professor Doutor Joo lvaro Carvalho, pelos seus comentrios, crticas e sugestes e pela disponibilidade sempre demonstrada.
Oracle Portugal que me proporcionou as condies necessrias para poder realizar este trabalho.
iii
Resumo
As Tecnologias da Informao (TI) permitem definir vrias arquitecturas de integrao e possibilitam diferentes abordagens para um mesmo problema. uma realidade confusa onde existe uma forte competitividade tecnolgica que influencia a adopo de diferentes solues. Neste mbito, as TI suportam e controlam a comunicao entre sistemas heterogneos permitindo a sua compatibilidade e integrao. Algumas solues seguem normas definidas e actualizadas por empresas ou organismos credenciados o que vem facilitar a integrao dos Sistemas de Informao (SI).
primeira vista, a classificao das diferentes solues para a integrao de SI no se revela fcil ou evidente. No entanto as abordagens podem centrar-se quer na informao quer nas aplicaes ou nos processos organizacionais. Estas trs reas correspondem a uma qualificao que serve de ponto de partida para a ordenao de ideias neste trabalho. Reala-se tambm que a integrao orientada aos processos organizacionais fundamental para a real adequao da soluo organizao. Esta perspectiva tem influenciado o aparecimento de novas normas tcnicas como por exemplo o Business Process Execution Language (BPEL). Com a evoluo das tecnologias, h uma crescente complementaridade das abordagens existentes o que leva definio de novas arquitecturas como por exemplo o Service Oriented Architecture (SOA). Na implementao do SOA, a norma BPEL permite especificar uma lgica processual de integrao de sistemas, disponibilizados como servios (Web Services), e integrveis de acordo com as especificaes tcnicas correspondentes.
Como ilustrao de conceitos, e com objectivo experimental, exemplifica-se uma implementao tcnica baseada em algumas das tecnologias e normas descritas neste trabalho. O objectivo deste exemplo o de mostrar na prtica diferentes perspectivas tecnolgicas para a integrao de SI, implementando duas alternativas diferentes. O BPEL e os Web Services so utilizados na segunda alternativa de forma a mostrar as vantagens da sua utilizao. No final so tecidas algumas concluses acerca da catalogao encontrada, do exemplo criado e da evoluo tecnolgica nesta rea de actuao. iv
Abstract
Information Technologies (IT) allow to define various integration
architectures and permit different approaches to the same problem. This is a confusing reality where there is a lot of competitive technologies that influences the adoption of different solutions. In that scope IT supports and controls the comunication between heterogeneous systems allowing their compatibility and integration. Some solutions follow standards defined by credited enterprises or organizations facilitating Information Systems (IS) integration.
The classification of the different solutions for IS integration is not easy or evident at the beginning. However the approaches can centralize whether into information, into applications or into business processes. Those three areas correspond to a way of classification that serves as a start to put in order the ideas in this work. There is an emphasis in the process centric integration because of his importance to make the integration solution suitable to the business. This specific view of the IS integration influences the appearance of new standards like, for instance, the Business Process Execution Language (BPEL) standard. With the technology evolution there is growing complementarity and convergence of the approaches, and this allows new architecture definitions as for example the Service Oriented Architecture (SOA). In that particular case the BPEL standard permits a procedural way of specificying IS integration. Systems are acessible through Web Services and can be integrated based on technical specifications defined by the corresponding standards.
To illustrate those concepts, and also as an experimental objective, an IS integration example is created. It is based on some technologies and standards described in this work. In that case, the main objective is to show in a practical way different technological perspectives for IS integration implementing two alternatives. Web Services and BPEL are used in the second approach to show their advantages. In the final some conclusions are expressed about the classification, the integration example and the technology evolution in this area.
It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change. Charles Darwin
vi
ndice
Agradecimentos................................................................................................... iii Resumo .....................................................................................................................iv Abstract .....................................................................................................................v Lista de figuras .....................................................................................................ix Lista de tabelas ..................................................................................................xvii 1. Introduo ...........................................................................................................1
1.1 Objectivos da dissertao.....................................................................................3 1.2 Conceitos e pressupostos .....................................................................................4 1.3 Organizao dos captulos ...................................................................................5 2. A integrao de Sistemas de Informao ............................................7 2.1 A necessidade de integrao de SI.......................................................................8 2.2 As formas e perspectivas de integrao de SI....................................................10 2.2.1 Integrao da informao............................................................................15 2.2.2 Integrao aplicacional ...............................................................................18 2.2.3 Integrao de processos ..............................................................................23 2.2.4 Integrao inter-organizacional ..................................................................26 2.3 Os Web Services na integrao de SI ................................................................27 2.4 As camadas tecnolgicas e a sua distribuio....................................................28 2.5 Papel das normas para a integrao de SI..........................................................33 2.6 Condicionantes da integrao de SI ...................................................................36 2.7 Concluso...........................................................................................................38 3. Abordagens para a integrao de SI ....................................................40 3.1 A Integrao da informao...............................................................................41 3.1.1 Ficheiros, SGBD e Replicao de Informao ...........................................42 3.1.2 ETL, TPM, EII, ECM e XML.....................................................................45 3.2 A Integrao aplicacional ..................................................................................51 3.2.1 Integrao aplicacional dentro da organizao ...........................................53 3.2.1.1 Plataformas aplicacionais: .NET e J2EE ....................................58 3.2.1.2 Servidores aplicacionais e Integration Brokers............................61 3.2.2 Integrao aplicacional entre organizaes ................................................64 3.3 A Integrao dos processos organizacionais......................................................67 3.3.1 Workflow e Business Process Management ................................................68 3.3.2 Business Process Execution Language .......................................................71 3.4 Web Services e a arquitectura Service Oriented Arquitecture...........................75 3.5 Web Services versus abordagens tradicionais para a integrao de SI..............81 3.6 Relacionamento das perspectivas para a integrao de SI.................................82 4. Solues para a integrao de Sistemas de Informao ............89 4.1 O Extended Markup Language (XML)..............................................................91 4.2 Solues para a integrao aplicacional dentro da organizao ........................96 4.2.1 Transaction Processing Monitors ...............................................................96 4.2.2 Remote Procedure Call ...............................................................................97 4.2.3 Componentes COM e JavaBeans................................................................98
vii
4.2.4 Objectos distribudos CORBA, DCOM e Java RMI ................................100 4.2.5 Messaging (MOM e Message Brokers) ....................................................101 4.3 Solues para a integrao inter-organizacional..............................................105 4.3.1 EDI............................................................................................................105 4.3.2 ebXML......................................................................................................106 4.4 Business Process Execution Language (BPEL)...............................................108 4.5 Os Web Services ..............................................................................................111 4.5.1 SOAP ........................................................................................................112 4.5.2 WSDL .......................................................................................................114 4.5.3 UDDI.........................................................................................................116 4.6 Smula .............................................................................................................117
7. Apndices ........................................................................................................173
7.1 Criao dos utilizadores de base de dados Oracle ...........................................173 7.2 Comandos para a criao das tabelas e registos na base de dados...................174 7.3 Database Links.................................................................................................177 7.4 Cdigo para integrao do Messaging.............................................................177 7.5 Integrao com Messaging e integrao com email da aplicao de Stocks ...182 7.6 Cdigo PL/SQL para Web Service de Insero de Requisies......................183 7.7 Cdigo PL/SQL para Web Service de Workflow............................................184 7.8 Cdigo de workflow para a integrao com Requisies e Messaging...........185 7.9 Classe Java para integrao com aplicao de RH ..........................................188 7.10 Definio BPEL .............................................................................................190 Referncias bibliogrficas ............................................................................193
viii
Lista de figuras
Figura 1.1: Evoluo e convergncia tecnolgica ....................................................... 2 Figura 2.1: Principais reas organizacionais para a integrao de SI .......................... 7 Figura 2.2: Evoluo da integrao de SI .................................................................... 8 Figura 2.3: Custo da integrao de SI versus n de aplicaes ................................... 9 Figura 2.4: Evoluo da integrao de SI e o BPM ................................................... 12 Figura 2.5: Valor da integrao de SI versus complexidade organizacional ............. 12 Figura 2.6: Vises da Integrao ................................................................................ 13 Figura 2.7: Pontos de partida para a integrao de SI ................................................ 14 Figura 2.8: Estudo Delphi Group Questo: Dificuldade em encontrar a informao? .............................................................................................................. 15 Figura 2.9: Estudo Delphi Group Questo: Factores que dificultam o acesso informao? .............................................................................................................. 16 Figura 2.10: Camadas de uma aplicao .................................................................... 19 Figura 2.11: Integrao ao nvel da camada de apresentao .................................... 19 Figura 2.12: Integrao ao nvel da lgica aplicacional ............................................. 20 Figura 2.13: Lgica aplicacional de suporte a processos organizacionais ................. 21 Figura 2.14: Integrao ao nvel do acesso e armazenamento da informao ........... 22 Figura 2.15: Middleware de Integrao ..................................................................... 22 Figura 2.16: Integrao de SI com foco no processo organizacional ........................ 24 Figura 2.17: Business Activity Monitoring na gesto e optimizao de processos organizacionais ........................................................................................................... 25 Figura 2.18: Web Services ......................................................................................... 27 Figura 2.19: Camadas tecnolgicas ............................................................................ 28 Figura 2.20: Camada do Software .............................................................................. 28 Figura 2.21: Middleware para a integrao ................................................................ 29
ix
Figura 2.22: As 7 camadas da pilha OSI .................................................................... 30 Figura 2.23: Arquitectura Cliente/Servidor ................................................................ 31 Figura 2.24: Arquitecttura two-tier ............................................................................. 31 Figura 2.25: Arquitectura 3-tier .................................................................................. 32 Figura 2.26: Benefcios no uso das normas ................................................................ 34 Figura 2.27: Normas exigidas aos fornecedores de TI ............................................... 35 Figura 3.1: Sistema de Gesto de Base de Dados ...................................................... 41 Figura 3.2: Envio de dados em ficheiro ..................................................................... 42 Figura 3.3: Partilha de repositrio de informao ...................................................... 43 Figura 3.4: Customer Data Hub. ................................................................................ 43 Figura 3.5: Replicao de informao (adaptado de Oracle Streams 10g) ................ 44 Figura 3.6: ETL (adaptado de ETL study Marc Songini - Computerworld) .......... 45 Figura 3.7: Integrao da informao na camada de apresentao com Middleware.47 Figura 3.8: Enterprise Content Management(ECM) .................................................. 48 Figura 3.9: Enterprise Information Integration (EII) .................................................. 49 Figura 3.10: Panorama da integrao da informao ................................................. 50 Figura 3.11: Integrao aplicacional directa .............................................................. 53 Figura 3.12: Modelos aplicacionais (adapatado de [Lewis 2000]) ............................ 54 Figura 3.13: Interface Aplicacional ........................................................................... 55 Figura 3.14: Message Broker .................................................................................... 56 Figura 3.15: Comunicao point to point .................................................................. 57 Figura 3.16: Comunicao hub and spoke ................................................................ 58 Figura 3.17: Comunicao do tipo Bus .................................................................... 58 Figura 3.18: Plataforma Microsoft .NET .................................................................. 59 Figura 3.19: Plataforma J2EE ................................................................................... 59
Figura 3.20: Funcionalidades do Oracle Application Server baseado em J2EE ........ 62 Figura 3.21: Deployment de cdigo num Application Server ................................... 62 Figura 3.22: Acessos diferenciados s aplicaes ...................................................... 63 Figura 3.23: Exemplo de um documento EDIFACT .................................................. 66 Figura 3.24: Caracterizao das categorias de processos de Workflow ..................... 69 Figura 3.25: BPM para a integrao de SI ................................................................. 70 Figura 3.26: Enquadramento das normas BPMN, BPML, BPEL e web services .... 71 Figura 3.27: Cronologia das normas de orquestrao de web services ..................... 72 Figura 3.28: Diagrama de normas da WfMC e BPMI.org ........................................ 73 Figura 3.29: Stack tecnolgica do BPEL ................................................................... 74 Figura 3.30: BPEL ...................................................................................................... 74 Figura 3.31: SOAP, UDDI e WSDL .......................................................................... 76 Figura 3.32: web services stack (Gottschalk et al., 2002) .......................................... 77 Figura 3.33: Arquitectura 3-tier .................................................................................. 78 Figura 3.34: Arquitectura SOA .................................................................................. 78 Figura 3.35: Camadas complementares do SOA ........................................................ 79 Figura 3.36: ESB (adaptado de Fiorano) .................................................................... 80 Figura 3.37: Perspectivas complementares da integrao de SI ................................. 82 Figura 3.38: Perspectiva da integrao inter-organizacional ..................................... 84 Figura 3.39: Famlias tecnolgicas e normas ............................................................. 87 Figura 3.40: mbito geral das normas e tecnologias por perspectivas ...................... 88 Figura 4.1: Principais solues e normas por perspectivas da integrao de SI ........ 89 Figura 4.2: XML Estruturao em rvore ............................................................... 91 Figura 4.3: XML Estruturao em rvore ............................................................... 92 Figura 4.4: DTD ......................................................................................................... 93
xi
Figura 4.5: XSL ........................................................................................................ 94 Figura 4.6: Namespaces ............................................................................................ 95 Figura 4.7: Monitor Transaccional ............................................................................ 96 Figura 4.8: Remote Procedure Call ........................................................................... 97 Figura 4.9: Arquitectura DCE ................................................................................... 98 Figura 4.10: Aplicao que integra um objecto COM .............................................. 99 Figura 4.11: Object Request Broker ......................................................................... 100 Figura 4.12: Messaging ............................................................................................ 102 Figura 4.13: Comunicao point to point ................................................................. 103 Figura 4.14: Comunicao hub and spoke ............................................................... 103 Figura 4.15: Comunicao do tipo Bus .................................................................... 104 Figura 4.16: Electronic Data Interchange (EDI) ...................................................... 106 Figura 4.17: Orquestrao ........................................................................................ 109 Figura 4.18: Coreografia .......................................................................................... 110 Figura 4.19: Estrutura SOAP ................................................................................... 112 Figura 4.20: Mensagem SOAP Request .................................................................. 113 Figura 4.21: Mensagem SOAP Response ................................................................ 113 Figura 4.22: Estrutura Lgica WSDL ...................................................................... 114 Figura 4.23: Estrutura fsica WSDL ......................................................................... 115 Figura 4.24: WSDL do tipo Request-Response ....................................................... 115 Figura 4.25: UDDI e WSDL .................................................................................... 116 Figura 4.26: Invocao de um Web Service ............................................................ 116 Figura 5.1: Integrao das 3 aplicaes ................................................................... 120 Figura 5.2: Aplicao de Requisies em 3 nveis .................................................. 121 Figura 5.3: Esquema de integrao da primeira abordagem .................................... 122
xii
Figura 5.4: Definio do processo de Workflow para suportar aprovao de requisies ................................................................................................................ 123 Figura 5.5: Informao contida na tabela FUNCIONARIOS da base de dados BD_RH ................................................................................................................................... 124 Figura 5.6: Classe Java Valida_BD_RH ............................................................... 125 Figura 5.7: Informao contida na tabela de ITEMS ............................................... 126 Figura 5.8: Descrio dos pontos de integrao ....................................................... 126 Figura 5.9: Modelo E-R do exemplo ........................................................................ 128 Figura 5.10: cran de introduo da requisio da aplicao de Requisies ......... 130 Figura 5.11: Integrao de cdigo Java na aplicao de Requisies ...................... 130 Figura 5.12: Integrao de informao via Database Link na aplicao de Requisies ................................................................................................................................... 131 Figura 5.13: Acesso via Web Browser aplicao de Requisies com utilizador VICTOR ................................................................................................................... 132 Figura 5.14: cran de insero e submisso das requisies ................................... 132 Figura 5.15: Informao da integrao da aplicao de RH na aplicao de Requisies com Java ............................................................................................... 133 Figura 5.16: Consulta de informao da aplicao de Stocks na aplicao de Requisies ............................................................................................................... 133 Figura 5.17: Submisso da requisio n 10 do item n1 para Workflow com sucesso. ................................................................................................................................... 134 Figura 5.18: Processo de aprovao de requisio n 10 iniciado ............................ 135 Figura 5.19: Requisio de item n 1 recusada automaticamente (Victor do departamento de Vendas) ......................................................................................... 135 Figura 5.20: Processo de requisio n 10 recusado ................................................ 136 Figura 5.21: Regra de negcio aplicada no workflow ............................................. 136 Figura 5.22: Submisso da requisio n 11 para item n2 ...................................... 137 Figura 5.23: Requisio n 11 em aprovao no workflow ..................................... 137 Figura 5.24: Notificao para pedido de aprovao de requisio n11 .................. 138
xiii
Figura 5.25: Aprovao da requisio n11 no workflow ........................................ 138 Figura 5.26: Trmino de processo de aprovao no workflow da requisio n 11 ..139 Figura 5.27: Trmino de processo de aprovao no workflow da requisio n 11 . 140 Figura 5.28: Integrao com Messaging .................................................................. 141 Figura 5.29: Envio de mensagem no Messaging ...................................................... 141 Figura 5.30: Recepo da mensagem na aplicao de Stocks com operao de DEQUEUE ............................................................................................................... 142 Figura 5.31: Envio de email ..................................................................................... 142 Figura 5.32: Recepo de email ............................................................................... 143 Figura 5.33: Integrao com BPEL .......................................................................... 144 Figura 5.34: Criao do Web Service para a aplicao de Requisies ................... 145 Figura 5.35: Especificao WSDL do Web Service para a aplicao de Requisies ................................................................................................................................... 146 Figura 5.36: Deployment do Web Service no OC4J ................................................ 146 Figura 5.37: OC4J para disponibilizar os Web Services baseado na plataforma J2EE ................................................................................................................................... 147 Figura 5.38: Web Service para a criao das requisies com operao inserirRequisicao ................................................................................................... 147 Figura 5.39: WSDL do Web Service ........................................................................ 148 Figura 5.40: cran de teste para a operao de inserirRequisicao da requisio n33 ................................................................................................................................... 148 Figura 5.41: Resposta do Web Service aps a sua invocao .................................. 149 Figura 5.42: Query sobre tabela Requisies com registo da requisio n33 subemtido por Web Service ...................................................................................... 149 Figura 5.43: WSDL do Web Service do sistema de workflow ................................ 150 Figura 5.44: Web Service para invocao do sistema de workflow de aprovao de requisies ................................................................................................................ 151 Figura 5.45: cran de teste para a operao de chamaWorkflow da requisicao n44 ................................................................................................................................... 151
xiv
Figura 5.46: Resposta do Web Service aps a sua invocao .................................. 152 Figura 5.47: Requisio n44 submetida por Web Service sujeita a aprovao no sistema de workflow ................................................................................................. 152 Figura 5.48: Requisio n44 submetida por Web Wervice ..................................... 153 Figura 5.49: Criao do projecto BPEL sncrono REQUISICOES_BPEL no BPEL Designer .................................................................................................................... 154 Figura 5.50: BPEL Designer Concepo grfica e deployment do processo BPEL ................................................................................................................................... 155 Figura 5.51: Diagrama BPEL do processo REQUISICOES_BPEL ..................... 156 Figura 5.52: Associao e passagem de valores entre parmetros do BPEL e dos Web Services .................................................................................................................... 157 Figura 5.53: Alterao da resposta do Web Service da aplicao de Requisies que retorna nome de requisitante .................................................................................... 158 Figura 5.54: Passagem do valor retornado pelo Web Service alterado no ponto anterior ...................................................................................................................... 158 Figura 5.55: Deployment do processo BPEL para o BPEL Process Manager ......... 159 Figura 5.56: BPEL Console Administrao e teste dos processos de BPEL via Web. ................................................................................................................................... 159 Figura 5.57: Submisso de um formulrio em HTML para o processo REQUISICOES_BPEL ......................................................................................... 160 Figura 5.58: Processo BPEL sncrono executado com sucesso para a requisio n 100 ................................................................................................................................... 160 Figura 5.59: Monitorizao on-line via Web do processo BPEL para a requisio n 100 ............................................................................................................................ 161 Figura 5.60: XML na etapa receiveInput do BPEL com a requisio n100 ........ 161 Figura 5.61: XML na invocao do Web Service Inserir_Requisicao para a requisio n100 ....................................................................................................... 162 Figura 5.62: Verificao da criao da requisio n 100 na base de dados via BPEL + Web Service ............................................................................................................. 162 Figura 5.63: XML na etapa Chama_Workflow do BPEL com a requisio n100 ................................................................................................................................... 163
xv
Figura 5.64: Requisio n100 submetida ao sistema de workflow via BPEL + Web Service ...................................................................................................................... 163 Figura 5.75: Requisio n100 submetida ao sistema de workflow via BPEL + Web Service ...................................................................................................................... 163 Figura 5.76: Recepo de email para a requisio n 100 ........................................ 164 Figura 5.77: Requisio n 103 em XML ................................................................. 165 Figura 5.78: Submisso directa de XML para o processo REQUISICOES_BPEL ................................................................................................................................... 165 Figura 5.79: Processo BPEL para a requisio n103 submetida em XML finalizado ................................................................................................................................... 166
xvi
Lista de tabelas
Tabela 3.1: Solues para os modelos aplicacionais .................................................. 55 Tabela 3.2: Comparao simples .NET e J2EE .......................................................... 61 Tabela 3.3: Categorias de processos de Workflow .................................................... 68 Tabela 3.44: Interaco com Web Services ............................................................... 76 Tabela 3.5: Descrio das reas comuns das perspectivas ......................................... 83 Tabela 3.6: Nvel de integrao de SI versus Perspectivas (adaptado de [Schmidt 2000]) ......................................................................................................................... 85 Tabela 3.7: Formatos e protocolos numa arquitectura SOA ...................................... 86 Tabela 4.1: Exemplo de transaction set e de message ............................................. 106 Tabela 5.1: Caracterizao resumida das abordagens para a implementao do exemplo. ................................................................................................................... 167
xvii
1. Introduo
As Tecnologias da Informao (TI) correspondem hoje em dia a um dos principais pilares das organizaes [Earl 1989]. A procura do controlo da informao e da flexibilizao tornou a integrao de sistemas informticos uma das grandes prioridades organizacionais [Edwards e Newing 2000]. Por seu turno, a constante evoluo das TI criou realidades tecnolgicas dspares fomentando a necessidade de partilhar informao e funcionalidades entre sistemas [Houston 1998]. Para as organizaes, a questo tecnolgica da integrao de Sistemas de Informao (SI) tornou-se cada vez mais complexa e hoje um autntico desafio quanto sua flexibilidade, adaptabilidade, implementao, manuteno e gesto.
comum encontrar organizaes cujos Sistemas de Informao (SI) so compostos por diversos sistemas, processos e informao cuja interaco suportada por canais de comunicao e ligaes especficas. A crescente necessidade de integrao de SI deriva de factores relacionados com a evoluo das organizaes, dos mercados e da tecnologia [Carvalho 2001]. Por exemplo, a necessidade de expor na Internet informao residente nos sistemas informticos internos, a necessidade de partilhar informao entre sistemas heterogneos ou a automatizao de processos organizacionais so algumas das situaes que necessitam de solues especficas. Estas necessidades surgem normalmente no dia-a-dia das organizaes devido sua dinmica e constante evoluo tecnolgica. Esta uma realidade complexa, onde existe uma forte competitividade ao nvel das solues, e onde as organizaes facilmente no encontram as respostas mais adequadas s suas reais necessidades [Allen 2001].
Nas ltimas dcadas, as empresas seguiram diferentes abordagens com o objectivo de integrar sistemas, quer para partilhar informao residente em diferentes nichos, quer para aproveitar funcionalidades existentes nesses mesmos sistemas. Inicialmente, um dos problemas mais comuns era o facto das aplicaes no terem sido concebidas para ser integradas com outras aplicaes. Neste sentido, foram encontradas solues de integrao cujas primeiras abordagens no seguiram normas tcnicas especficas dada a sua inexistncia. com a crescente necessidade de solues nesta rea, e com a prpria evoluo tecnolgica, que estas especificaes foram criadas e aperfeioadas 1
at aos nossos dias. Estas normas vieram facilitar a concepo de solues, mas h hoje uma realidade tecnolgica repleta de alternativas viveis. A maioria das solues existentes baseiam-se em normas tcnicas o que facilita a sua classificao. No entanto, cada norma tem a sua especificidade e pode, ou no, ser adoptada de acordo com a sua adequao, utilidade e enquadramento nas diversas arquitecturas tecnolgicas. Por fora da evoluo do mercado tecnolgico, certas normas sobrepoem-se em algumas reas, ou so incompatveis, o que aumenta a dificuldade no entendimento e na escolha da soluo mais adequada. Elas so no entanto incontornveis para se obter solues certificadas e abertas.
A integrao de SI est normalmente associada aos termos Enterprise Application Integration (EAI) [William 2000, Serain 2002] ou Business Process Management (BPM) [Hollingsworth 2004] que tm pontos em comum e que so por vezes complementares. Estas so duas correntes influenciadoras que determinaram diferentes vises e solues para a integrao de SI. Por seu turno, o mercado das tecnologias mudou significativamente nos ltimos anos dada a crescente competitividade entre as empresas e os mercados das TI. O mbito da integrao de SI deixou de estar exclusivamente na estrutura das aplicaes informticas para se alargar a toda a organizao. Para alm disso, assistiu-se nos ltimos anos a uma convergncia e sobreposio de tecnologias que tornou a sua classificao mais difcil (Figura 1.1). Neste sentido, o recente surgimento dos Web Services (WS) [Cerami 2002] e da arquitectura Service Oriented Architecture (SOA) [Newcomer e Lomow 2004] criou novas alternativas s abordagens mais tradicionais. Neste campo, surgem
novas respostas, que so por vezes complementares s solues j existentes, e que permitem igualmente suportar este tipo de integrao de SI. Hoje em dia, para a rea da integrao de SI, possvel encontrar diferentes solues para um mesmo problema, sendo todas elas vlidas [Wrazen 2000]. Nestes casos, so as prprias necessidades e os objectivos das organizaes que vo determinar a sua real adequao.
Todos estes factores tornaram as abordagens para a integrao de SI difceis de escolher. Neste mbito, qualquer situao requer uma anlise exaustiva, quer ao nvel das necessidades da organizao, quer ao nvel das solues a adoptar. Para alm disso, existe nesta rea uma enorme quantidade de informao com diferentes perspectivas e definies, por vezes ambguas ou desactualizadas, o que dificulta a sua compreenso. Este trabalho pretende contribuir para um melhor entendimento desta complexidade fazendo uma descrio e catalogao das possveis abordagens e solues mais adequadas s necessidades existentes nas organizaes. Neste trabalho, feito um enquadramento do tema da integrao de SI, uma classificao das abordagens mais comuns, um levantamento das principais normas tcnicas relacionadas com cada abordagem e a implementao de um exemplo prtico de integrao de SI, realando e comparando duas abordagens.
complexas foram directamente includas neste trabalho, pelo receio de no conseguir recri-las fidedignamente em portugus.
O tema da integrao de SI refere-se problemtica de integrar sistemas informticos dspares de forma a poder partilhar os seus recursos, sejam eles dados sejam elas funcionalidades. A natureza de cada sistema vai ditar a abordagem de integrao mais adequada. O conceito de integrao corresponde, neste caso, ao acto de integrar dois ou mais sistemas que podem estar dentro ou fora de uma organizao. A integrao pode ser feita em vrios nveis, como por exemplo, entre diferentes repositrios de informao, dentro de uma mesma aplicao informtica e entre duas aplicaes. O tema da integrao de SI contempla a interoperabilidade entre sistemas no sentido em que so colocados a comunicar e a interagir, independentemente da abordagem tecnolgica de suporte.
Considera-se um sistema informtico uma soluo informatizada, ou um software, que permite a gesto e a explorao de informao dentro de uma organizao. Um sistema informtico pode ser tambm referido neste trabalho como um sistema, um aplicativo, uma aplicao, um pacote aplicacional, uma soluo informtica, um mdulo aplicacional ou uma soluo aplicacional.
Uma arquitectura corresponde a um padro de combinao de componentes que est na base de uma soluo tecnolgica com um determinado fim. Este conceito 4
identifica que uma determinada soluo tcnica, ou uma abordagem de integrao, tem vrias camadas estruturantes e complementares. Essas camadas podem ser lgicas ou fsicas e do corpo a uma ideia ou permitem descrever uma tecnologia. Por exemplo, a arquitectura do tipo cliente/servidor, abordada neste trabalho, define duas camadas complementares.
O conceito de plataforma referencia uma base tecnolgica que suporta e disponibiliza funcionalidades para a concepo de solues aplicacionais ou para a integrao de SI. Por exemplo, a plataforma Java 2 Platform Enterprise Edition (J2EE) uma plataforma de desenvolvimento aplicacional com um conjunto de interfaces programticas estruturadas em diferentes camadas complementares.
O conceito de processo aqui entendido como um processo organizacional composto por uma sequncia de tarefas que podem envolver pessoas, aplicaes e/ou documentos. Neste mbito, o processo tambm pode representar uma base estruturante para a integrao de SI, quando este informatizado e automatizado, permitindo a interligao de vrias aplicaes informticas.
O conceito de Middleware corresponde a uma arquitectura tecnolgica que concentra num software centralizado um conjunto de informao, procedimentos e aplicaes. Este permite interligar sistemas, disponibilizar informao, transportar dados entre sistemas e fornecer canais de comunicao entre diversas aplicaes informticas.
1. Enquadramento do tema e dos conceitos associados que servem de base para esta explanao. 2. Identificao de diferentes perspectivas para a integrao de SI, suas condicionantes, tecnologias de base e o papel das normas tcnicas.
3. Detalhe e relacionamento das perspectivas, arquitecturas e normas mais importantes. 4. Descrio das principais normas e tecnologias identificadas em cada perspectiva descrita. 5. Apresentao detalhada da implementao de um exemplo de integrao de SI utilizando tecnologias e normas apresentadas neste trabalho. 6. Concluses e sugestes.
A informao, os sistemas informticos e os processos organizacionais so trs reas complementares que devem ser coordenadas e ajustadas sob pena de no se adequarem dinmica da organizao (Figura 2.1). Neste mbito os processos correspondem combinao das actividades necessrias e suficientes para o funcionamento da organizao. Qualquer estratgia para a integrao de SI tem de ter em conta cada uma destas realidades, quer em termos de anlise e estratgia quer em termos de implementao, para obter a soluo mais adequada.
As solues para a integrao de SI determinaram vrias fases na sua evoluo (Figura 2.2) que passaram pela criao de teias de sistemas interligados, seguida pela adopo de pacotes de software integrado, como so os Enterprise Resource Planning (ERP) [Summer 2004], que entretanto foram complementados com a integrao de outros sistemas do tipo Client Relationship Management (CRM) [Reynolds 2002], Supply Chain Management (SCM) [Chopra e Meindl 2000] e outras aplicaes j existentes na organizao [Cherry 2000]. Este tipo de solues garantiram uma gesto mais eficiente da informao e dos processos das respectivas organizaes. Com a crescente necessidade de integrao de SI, surgiram solues especficas, e normalmente denominadas por Enterprise Application Integration (EAI), que 8
Com o aparecimento da Internet a necessidade de interligar sistemas tornou-se cada vez mais premente. Neste sentido, os responsveis pelas TI comearam a concluir que era necessrio adoptar uma estratgia global [Ulrich 2002] para a integrao de todos os seus SI e escolher solues especficas para o efeito. A empresa consultora Gartner Group demonstrou recentemente que mais de 35% dos investimentos feitos em TI so aplicados na integrao de sistemas. Os custos para a integrao de SI so normalmente proporcionais quantidade de sistemas que se quer interligar e ao nvel de integrao desejado (Figura 2.3). Hoje em dia existem solues completas que permitem responder a diferentes problemas e seguir diferentes abordagens. Estas solues especficas so normalmente denominadas de Integration Middleware [Serain 2002], ou Integration Hubs, e tm um conjunto de funcionalidades que permitem integrar diferentes nveis tecnolgicos abordados neste trabalho.
Com a evoluo dos mercados e das tecnologias, foram surgindo novas formas de abordar a integrao de SI. Existem hoje em dia correntes tecnolgicas que defendem diferentes perspectivas e abordagens para a integrao de SI. Cada uma delas tem solues vocacionadas para a sua rea chegando por vezes a partilhar funcionalidades das restantes. Esta realidade dificulta a escolha das solues mais adequadas s necessidades organizacionais e complica o entendimento das tecnologias existentes nesta rea.
As formas de integrao de SI podem ser catalogadas de vrias maneiras consoante diferentes critrios. Por exemplo, possvel catalogar genrica e tecnologicamente a integrao de SI consoante o seu nvel de implementao:
Sistemas Integrados de Gesto: Sistemas aplicacionais fechados e compostos por mdulos internos totalmente integrados e autnomos. Informao centralizada: Diferentes aplicaes acedem a repositrios de informao centralizados partilhando o seu contedo. Normalmente nestes casos existe um metamodelo de dados comum.
Aplicaes compostas: Aplicaes que esto integradas atravs das suas interfaces de programao (Application Programming Interface) [Hines 1996]. Estas invocam, ou incorporam, entre si funes, mtodos ou procedimentos partilhando lgica aplicacional de forma directa.
Sistemas Transaccionais: Sistemas que coordenam entre si as suas transaces operacionais garantindo a actualizao com sucesso e sincronizada da informao em cada sistema interligado.
Sistemas Distribudos: Sistemas autnomos integrados atravs de servios aplicacionais que disponibilizam partes de lgica aplicacional. Os servios aplicacionais esto identificados e catalogados num repositrio especfico e a sua invocao feita dinamicamente.
10
Esta catalogao est centrada nas abordagens tcnicas para a integrao de aplicaes e permite ter uma primeira viso de algumas alternativas subjacentes. Tendo em conta a perspectiva dos processos e da prpria organizao pode-se por exemplo catalogar da seguinte forma a integrao de SI [Hohpe et al. 2003]:
Information Portals: Integrao de aplicaes ao nvel da interface grfica e da camada de apresentao. Data Replication: Integrao ao nvel da informao, actualizando e sincronizando os diferentes repositrios existentes na organizao. A informao no est centralizada mas distribuda.
Shared Business Functions: Lgica aplicacional partilhada entre aplicaes informticas que invocam, ou incorporam, procedimentos existentes na camada aplicacional dessas aplicaes.
Service-Oriented Architectures: Arquitectura distribuda onde cada sistema aplicacional disponibiliza funes ou procedimentos como servios
disponveis para serem identificados e chamados. Distributed Business Processes: A integrao aplicacional feita numa lgica processual. Os processos organizacionais so automatizados e cujas partes so executadas em diferentes aplicaes. Os processos representam o eixo da integrao de SI. Business-to-Business Integration: A integrao de SI est aqui centrada na organizao. O objectivo permitir a colaborao entre diferentes organizaes de forma a partilhar processos e informao de forma automtica.
11
Para alm das diferentes perspectivas e catalogaes existentes, a evoluo das TI na rea da integrao tem revelado que os processos organizacionais so cada vez mais o centro das atenes. Isto deve-se importncia que os processos tm numa organizao pela sua natureza estruturante [Alves 1995]. As solues de BPM mais recentes incluem praticamente todas as tecnologias e conceitos de integrao de SI que foram aparecendo ao longo dos tempos (Figura 2.4).
12
Quanto mais complexa uma organizao mais valor tero os projectos de integrao de SI. Neste mbito, pode-se identificar pelo menos trs reas complementares e com crescente nvel de importncia para as organizaes (Figura 2.5): a integrao da informao, a integrao aplicacional e a integrao de processos.
Existem outras possveis classificaes determinadas pelos nveis tcnicos ou conceptuais diferenciados. De qualquer forma o objectivo principal da integrao de SI sempre a obteno de sistemas que facilitam o acesso a dados e procedimentos sem qualquer barreira funcional. Em consequncia, as aplicaes resultantes podem corresponder a combinaes de componentes de diferentes reas tecnolgicas. Neste mbito, identificam-se as quatro perspectivas tecnolgicas mais comuns e abrangentes (Figura 2.6):
perspectiva a informao, a sua gesto e disponibilizao. Integrao Aplicacional (IA): as aplicaes so aqui o principal
13
centro das atenes nesta perspectiva, sendo a integrao de SI feita numa lgica processual. Integrao Inter-Organizacional (IO): a informao e a sua
Cada perspectiva permite planear e iniciar os projectos para a integrao de SI em pontos de partida diferentes (Figura 2.7). possvel comear pela integrao ao nvel da informao ou dos procedimentos, e optar por uma abordagem bottom-up, ou pela situao inversa que centra a sua ateno nos processos das organizaes e segue uma abordagem top-down.
Em qualquer dos casos procura-se a integrao entre sistemas dspares que precisam de partilhar informao e funcionalidades. Com a evoluo das TI, surgiram recentemente normas tcnicas como os Web Services [Cerami 2002], e arquitecturas como o Service Oriented Architecture (SOA) [Newcomer e Lomow 2004], que permitem encapsular funcionalidades e disponibilizar novas camadas de acesso. Os Web Services podem ser utilizados em qualquer uma das perspectivas para a integrao de SI aqui identificadas. Cada abordagem tem vantagens e desvantagens que devem ser ponderadas sob pena de condicionar as capacidades de gesto e 14
adaptao das organizaes [Levine 2005]. Os pontos seguintes deste captulo descrevem sumariamente o mbito de cada uma das quatro principais perspectivas identificadas.
Um estudo do Delphi Group [Delphi 2002] relacionado com os problemas da informao excessiva ou no estruturada nas empresas, revela que 68% dos inquiridos concordam que a informao difcil de encontrar (Figura 2.8), que 35% no conseguem encontrar a informao vlida pelo facto de estar em constante alterao
15
(Figura 2.9) e que 11% no encontra informao porque simplesmente esta no est disponvel. Embora o estudo esteja centrado na informao no estruturada, este revela que a informao vital para a dinmica das organizaes e que fundamental t-la acessvel e vlida para as pessoas que dela necessitam. A integrao de SI ao nvel da informao tem precisamente o mesmo objectivo.
Figura 2.9: Estudo do Delphi Group Questo: Factores que dificultam o acesso informao?
Uma gesto eficiente da informao torna as organizaes mais flexveis para se adaptarem s mudanas do seu meio circundante, e com isso serem mais competitivas. A forma como elas processam e armazenam este recurso cria necessidades de integrao a vrios nveis e com diferentes tipos de problemas. Neste mbito existem solues que permitem organizar, consolidar e gerir a informao com diferentes propsitos e que correspondem a 2 reas de interveno:
Actualizao diria da informao operacional com recurso a solues transaccionais do tipo On-Line Transaction Processing (OLTP) [Claybrook 1992].
Consolidao dos repositrios de informao para fins de anlise e gesto empresarial. Esta a rea dos Datawarehouses, dos EIS (Executive Information Systems), das solues multi-dimensionais Multidimensional On-Line Analytical Processing (MOLAP)
16
As necessidades de integrao de informao esto normalmente mais associadas s solues do tipo OLTP e natureza operacional do contedo dos seus repositrios. Neste mbito distinguem-se duas situaes problemticas:
A disperso da informao engloba situaes onde se verifica que esta no est centralizada, conduzindo por vezes existncia de ilhas de informao. Neste caso, a integrao de duas ou mais aplicaes, que precisam de partilhar informao, pode revelar-se complexa dado que esta pode estar repetida e desactualizada. No segundo caso, a heterogeneidade da informao dificulta a interligao entre mdulos aplicacionais autnomos [Papakonstantinou et al.1995]. Aqui, cada aplicao estrutura a mesma informao de forma diferente o que obriga sua interpretao, ou traduo, para conseguir uma integrao efectiva [Ullman 1997]. Esta situao tem a ver com a modelao lgica da informao, que pode criar estruturas de armazenamento diferentes dificultando a sua partilha.
A integrao de SI orientada informao tem pelo menos trs reas de interveno possveis:
1. O armazenamento da informao: permite a integrao de SI atravs da centralizao do seu armazenamento. 2. O transporte e troca de informao: permite uma integrao de SI ao nvel do controlo do seu transporte e da sua troca entre sistemas. 3. A disponibilizao e apresentao da informao: permite uma integrao de SI com a sua apresentao centralizada num determinado contexto como por exemplo uma pgina de uma intranet, ou um relatrio que agrega vrias fontes de informao.
17
Neste mbito, a integrao de SI orientada informao pode ser realizada em diferentes reas que pode passar pela utilizao de sistemas de gesto de bases de dados, pela troca de informao entre aplicaes, pela criao de repositrios centralizados de informao para efeitos analticos ou pela apresentao centralizada de informao dispersa numa intranet e acessvel com um web browser. Os principais benefcios associados a esta abordagem centrada na informao so essencialmente:
Partilha da informao entre sistemas. Consolidao a informao na organizao. Os repositrios de informao podem manter-se distribudos e heterogneos. Controlo da integridade e correco da informao. Acesso controlado e centralizado informao. Relatrios de gesto fiveis, e correspondente viso da organizao fidedigna.
As principais dificuldades para a integrao da informao esto directamente relacionadas com os sistemas de armazenamento, as formas de acesso, os tipos de comunicao e a segurana.
Independentemente da soluo tecnolgica utilizada, a integrao de SI centrada na informao tem como principal preocupao garantir que esta esteja sempre disponvel, correcta e vlida para as aplicaes ou pessoas que dela necessitam.
18
O principal alvo de interveno desta rea a prpria aplicao. Ao nvel da integrao directa de aplicaes encontram-se diferentes solues consoante o nvel de ligao necessrio. Uma aplicao pode conter funcionalidades correspondentes a diferentes estratos tecnolgicos complementares. Neste sentido, possvel descrever uma aplicao pelas suas trs principais camadas estruturantes (Figura 2.10). Estas correspondem camada de armazenamento da informao, camada da lgica aplicacional e camada de apresentao [Wong 2001]. A camada da lgica funcional de uma aplicao faz a gesto das regras, requisitos e funcionalidades desse sistema, podendo inclusivamente automatizar alguns processos da organizao.
19
De acordo com estas camadas, e centrando o mbito nas aplicaes informticas, pode-se identificar trs grupos de solues:
O principal objectivo da integrao da camada de apresentao a centralizao do acesso informao e s aplicaes numa nica interface (Figura 2.11). Neste caso, a integrao feita ao nvel do que as pessoas visualizam correspondendo a uma nova camada de apresentao que integra toda a informao e aplicaes num nico cran. Geralmente a ferramenta mais utilizada para aceder a essa nova camada o web browser. Este tipo de integrao pode ser feita de forma simples e directamente ao nvel do cran ou de forma mais complexa criando uma camada especfica de interaco para apresentar somente a informao e as funcionalidades necessrias.
A integrao ao nvel da lgica aplicacional corresponde integrao directa entre duas ou mais aplicaes. Nesta rea procura-se interligar aplicaes para partilhar funcionalidades e complementar caractersticas (Figura 2.12). Existem tecnologias que permitem este tipo de integrao e que variam de uma simples invocao de cdigo, incluso directa de partes de uma aplicao ou troca de mensagens estruturadas entre aplicaes. Este tipo de integrao requer canais de comunicao especficos que suportam os diferentes tipos de interaco. Esta abordagem enquadra
20
tambm a integrao da lgica aplicacional que implementa regras para a automatizao de processos organizacionais. Dentro de uma aplicao, possvel criar funcionalidades com esse propsito, suportando assim os processos, a respectiva sequncia de actividades e as regras da prpria organizao (Figura 2.13). A grande maioria da informao, processos e regras da organizao gerida neste nvel aplicacional.
Figura 2.13: Lgica aplicacional de suporte a processos organizacionais (adaptado de [Wong 2001])
A integrao de SI centrada na camada da informao das aplicaes procura partilhar informao entre cada sistema (Figura 2.14). O principal objectivo a troca de informao entre sistemas de forma a que cada um tenha acesso mesma informao e com o mesmo significado. Para isso existem vrias tecnologias que garantem a correco, a integridade, a segurana, a veracidade e a disponibilidade da informao. Um dos problemas mais comuns nesta rea tem a ver com a gesto das transaces aplicacionais que determinam a actualizao e integridade da informao. Quando esta gesto feita ao nvel da camada da lgica aplicacional pode gerar conflitos no acesso e na partilha da mesma informao em simultneo. Para isso os SGBD tm funcionalidades especficas ou ento existem solues transaccionais prprias para estas situaes. Esta abordagem comum perspectiva da integrao de SI centrada na informao, no que diz respeito ao seu armazenamento e sua troca.
21
Figura 2.14: Integrao ao nvel do acesso e armazenamento da informao (adaptado de [Wong 2001])
Ainda neste mbito, existem solues que abrangem de forma combinada e centralizada todos os tipos de integrao aqui referidos. na rea do Middleware [Watt 2002] que se encontram estas alternativas que suportam a integrao de sistemas dentro e fora das organizaes (Figura 2.15).
As solues de Middleware permitem normalmente os trs tipos de integrao aqui referidos ao nvel da estrutura das aplicaes. Os principais benefcios associados a esta abordagem de integrao de SI orientada s aplicaes so essencialmente:
22
Tirar melhor partido das funcionalidades dos sistemas existentes Reutilizao das regras da organizao j implementadas nos sistemas Tornar os actuais sistemas como fornecedores de servios para outros sistemas Melhora o acesso directo e indirecto s aplicaes distribudas Reaproveita sistemas antigos que possam ainda dar o seu contributo Facilita futuras integraes de sistemas entre organizaes
A optimizao dos processos organizacionais e o controlo do fluxo de informao fundamental para a integrao de sistemas. Pode-se identificar trs tipos diferentes de processos organizacionais [Delphi 2002]:
O primeiro tipo engloba os processos que envolvem transferncia de informao entre um conjunto de aplicaes que podem incluir vrias etapas sequenciais. No segundo caso, encontram-se processos que envolvem pessoas que colaboram para
23
completar tarefas ou processos da organizao. O ltimo tipo caracteriza os casos que envolvem pessoas que do incio a processos organizacionais ou participam neles num determinado ponto.
Neste mbito, o processo organizacional pode ser o foco para uma estratgia de integrao de SI. As solues informticas do tipo Workflow [Georgakopoulos 1995, Fischer 2003] ou da rea do Business Process Management (BPM) [Hollingsworth 2004] permitem automatizar este tipo de processos e integrar diferentes aplicaes (Figura 2.16). A lgica de integrao tem a ver com a sequncia de tarefas associadas a um processo que determina a interaco ordenada com as diversas aplicaes. Esta viso da integrao de SI permite definir uma arquitectura orientada aos processos (Process Oriented Architecture - POA) [CSC 2003]. comum as solues do tipo Integration Middleware fornecerem tambm estas funcionalidades.
Em qualquer abordagem para a integrao de SI orientada aos processos a monitorizao da execuo dos processos fundamental. Esta rea crucial quer para obter informao de gesto quer para verificar a real adequao da tecnologia. Neste campo surge o conceito de BAM (Business Activity Monitoring) [McKie 2003, Kochar 2005] no qual se encontra um conjunto de solues que permitem este tipo de funcionalidades. O BAM (Figura 2.17) disponibiliza informao detalhada acerca de cada passo existente em cada processo e permite diagnosticar em cada momento o
24
Business Process Optimization: Baseado na informao obtida da camada inferior possvel optimizar os processos da organizao. Business Activity Monitoring: Informao relativa ao desempenho de cada actividade existente na organizao. Business Process Management: Automatizao e gesto dos processos organizacionais.
Automatizao e execuo dos processos organizacionais Viso processual da organizao e dos seus sistemas Melhora e optimiza a dinmica de processos da organizao Melhor monitorizao dos processos Mudanas ou alteraes facilitadas de processos Relatrios de gesto mais completos e fidedignos Feedback para a optimizao de processos Reaproveitamento e integrao de sistemas existentes Preparao para futuras integraes entre organizaes
25
Uma arquitectura para B2B permite resolver problemas de integrao entre diferentes organizaes que colaboram e participam num mesmo processo. Esta abordagem permite a reduo de custos e tempo numa cadeia de fornecimentos de bens ou servios entre organizaes. A tecnologia de suporte ao B2B permite um maior controlo dos processos e das interaces entre uma organizao e os seus parceiros de negcio. Nesta rea existem normas que regulam a estruturao dos documentos de negcio e a forma como so feitas as transaces electrnicas. Tratase do intercmbio de informao entre organizaes e da definio dos documentos que vo trocar electronicamente de acordo com as respectivas normas e eventuais outros pressupostos.
Normalizao da informao e documentao trocadas Sinergias organizacionais Definio de transaces comerciais e operacionais comuns Reaproveitamento e integrao com sistemas existentes Melhoramento e integrao das cadeias de valores Automatizao e coordenao das dinmicas organizacionais.
26
O uso de WS pode fazer sentido em diferentes reas tecnolgicas e conceptuais permitindo compatibilizar solues dspares, utilizando formatos comuns de troca de informao suportados na norma Extended Markup Language (XML) [Ramalho 2002]. Os WS definem regras de interaco e comunicao com cada servio de forma a obter uma camada de abstraco, suficientemente completa, para poder interagir com o que est encapsulado. Estes funcionam com uma interface baseada em normas tcnicas para facilitar a integrao de SI.
Os Web Services podem ser utilizados em qualquer uma das perspectivas da integrao mencionadas nos pontos anteriores tirando partido de todas as vantagens de cada uma delas. Estes criam uma nova camada de acesso aberta sobre cada tecnologia, permitindo tirar partido da sua informao ou dos seus procedimentos.
27
De forma geral, pode-se visualizar a tecnologia estruturada por camadas complementares. Numa viso tcnica simplista identifica-se as camadas bsicas do hardware e do software (Figura 2.19). Por sua vez, a camada base de software pode ser decomposta pelo nvel dos sistemas operativos e por todo um conjunto de aplicaes, ou solues informticas, com diferentes fins. Neste mbito, um sistema de gesto de base de dados (Database Management System - DBMS) ou um Servidor Aplicacional (Application Server - AS) fazem parte desta segunda decomposio (Figura 2.20).
essencialmente dentro da camada de software que se enquadram as solues para a integrao de SI. Estas assentam em protocolos de comunicao, outros componentes de software e normas tecnolgicas. Se identificarmos a integrao de SI
28
como uma camada conceptual esta tem uma relao directa com os protocolos de comunicao das camadas das redes e do middleware (Figura 2.21), herdando muitas das suas caractersticas tecnolgicas [Silva 2003]. Considera-se o middleware um conjunto de software com funcionalidades que permitem a interaco entre vrios sistemas ou aplicaes que residem em diferentes mquinas.
Como se detalha nos captulos seguintes a camada do middleware uma pea fundamental para a computao distribuda e para potenciar a comunicao entre sistemas e a sua integrao. Esta pode ter vrias implementaes sendo o seu principal propsito a integrao entre componentes de software, garantindo o seu acesso e a sua disponibilizao. Esta camada permite reduzir o impacto da interligao de diferentes tecnologias de comunicao, sistemas operativos, aplicaes e linguagens de programao.
O Middleware tem um conjunto de servios, normalmente assentes em normas tcnicas, que suportam por exemplo a execuo de cdigo, transaces distribudas, segurana, balanceamentos de carga, clustering, backups, comunicaes, etc. Nesta camada, pode-se encontrar solues do tipo Transaction Processing Monitors (TPM), Application Servers (AS), Message Brokers (MB), Web Server (WES), Workflow Server (WFS) e Object Request Broker (ORB) entre outros.
29
A camada de middleware [Schreiber 1995, Bernstein 1996] suporta vrias formas de comunicao entre sistemas e componentes. Para que a integrao de sistemas de informao seja possvel so necessrios canais de comunicao que permitem o intercmbio de informao. Neste mbito, a tecnologia fornece vrias alternativas para a troca de dados entre mdulos aplicacionais. Estes canais de comunicao assentam nas redes estruturadas que interligam esses sistemas e que permitem estabelecer ligaes via protocolos como por exemplo o TCP/IP, o IPX ou NetBEUI. Sobre estas camadas so usados outros protocolos como o HTTP ou o RPC [Gunter 1995] entre outros. O modelo OSI (Open System Interconnection Model) ilustra cada uma das camadas de suporte s comunicaes e troca de informao entre aplicaes distribudas (Figura 2.22). Acima destas camadas podem identificar-se mais quatro camadas para suportar os processos organizacionais e a integrao de SI [Carroll 2000]:
Business Processes (Company-specific Business Processes) Business Semantics (Company-specific data definitions and structures) Interface Syntax (API, DCOM, CORBA, etc...) Integration Middleware (Event-Driven ou Data-Driven)
Numa viso conceptual, pode-se identificar camadas lgicas dentro da camada de software. A primeira abordagem corresponde arquitectura Cliente/Servidor [Schussel 1996, Edelstein 1994, Zahavi 1999] (Figura 2.23). A camada do cliente 30
invoca servios ou procedimentos fornecidos pela camada do servidor. seguida uma configurao do tipo Master/Slave em que o sistema cliente procura recursos existentes no servidor que est totalmente dedicado a este tipo de funes. Os servidores de ficheiros ou de impressoras so exemplos deste tipo de partilha de recursos e informao.
Neste tipo de arquitectura surge o conceito de Application Programming Interface (API) que representa uma interface aplicacional para facilitar a integrao e troca de informao entre duas ou mais aplicaes [Hines 1996] numa configurao do tipo Cliente/Servidor. Neste mbito surge tambm o conceito de Remote Procedure Call (RPC) que permite a invocao de procedimentos remotos [Rao 1995, Birrell e Nelson 1984] [Gunter 1995] entre aplicaes.
A abordagem das duas camadas [Schussel 1996, Edelstein 1994], tambm denominado de two-tier, enquadra-se no mbito do Cliente/Servidor mas com uma
31
diferena na distribuio da lgica aplicacional em duas camadas complementares. Uma parte da programao reside do lado do cliente em conjunto com a camada de apresentao e outra parte est do lado do servidor em conjunto com a camada da informao (Figura 2.24). Como j foi referido, as aplicaes so comummente divididas em trs camadas lgicas [Eckerson 1995 e Wong 2001] (Figura 2.25):
1. Camada cliente ou de apresentao (client-tier) 2. Camada de business logic ou processamento (middle-tier) 3. Camada da informao ou de base de dados (information-tier)
A camada cliente ou front-end corresponde rea de apresentao das aplicaes e da informao. Por exemplo, numa Intranet o portal empresarial acedido atravs de um web-browser o que corresponde a esta camada aplicacional.
A camada intermdia do middle-tier incorpora a lgica aplicacional com as suas regras e procedimentos. Esta camada tira partido do middleware e potencia a comunicao entre sistemas permitindo vrios nveis de integrao. O prprio middletier pode estar repartido por vrios estratos ou sub-camadas tecnolgicas.
A camada da informao contempla todas as solues de armazenamento e gesto de informao. Aqui encontram-se normalmente os SGBD (Sistemas de Gesto de Bases de Dados) que funcionam como repositrios de informao.
Seguindo esta lgica de camadas, esta arquitectura pode ser subdividida em n camadas complementares, tambm denominada por arquitectura n-tier [Chartier 2004, Carnegie 1997]. Esta arquitectura, tambm designada por multi-tiered, permite identificar diferentes camadas complementares, como por exemplo: a camada de 32
apresentao, a camada web server e a camada de informao onde normalmente esto as bases de dados. A camada lgica do middleware referida acima pode ela prpria estar repartida por n camadas intermdias neste tipo de abordagem. Uma estrutura n-tier engloba todos estes conceitos e fornece uma plataforma que permite simplificar e unificar diferentes tipos de aplicaes e interfaces.
Cada camada pode estar fisicamente distribuda, ou logicamente integrada numa aplicao. Cada uma delas permite diferentes tipos de integrao desde o nvel da gesto da informao at ao nvel da sua apresentao. Em cada nvel poder-se- encontrar funcionalidades complexas e diferentes para a integrao de aplicaes, processos e informao. Esta viso conceptual importante para se entender a abrangncia tecnolgica da integrao de SI que permite abordagens diferentes mas igualmente vlidas.
Pode-se definir uma norma como sendo uma categoria especfica de tecnologia de informao definida por uma especificao pblica ou controlada por uma organizao independente ou que esteja em uso h pelo menos um ano por mais de 50% das aplicaes na sua classe1. Neste sentido, a criao de normas tcnicas tem
33
dois caminhos paralelos e por vezes concorrentes. Existem as normas de facto que no so mais do que a adopo generalizada de uma especificao tecnolgica, pertencente a um ou mais fornecedores, mas que no est sujeita a um organismo regulador oficial. Por outro lado, as normas denominadas de jure, ou formais, so especificadas por organizaes credenciadas para o efeito garantindo a sua independncia e a evoluo de cada especificao. Em paralelo h esforos de cooperao entre empresas que se unem na criao de uma norma que ser posteriormente submetida a um organismo credenciado para a tornar formal.
A adopo de normas especficas na integrao de SI tem sido estimulada por um conjunto de factores especficos [Craggs 2003], nomeadamente:
Integrar processos dentro e entre organizaes Capacidade de interligar sistemas internos e aplicativos Suportar processamento de transaces existentes nos sistemas Disponibilizao de servios para fora da organizao Crescente complexidade das tecnologias para a integrao de SI Diminuio de custos de integrao de SI
Existem diversas normas de mercado que permitem disciplinar a evoluo tecnolgica e documentar cada arquitectura com as suas respectivas funcionalidades. 34
Um estudo recente do Delphi Group2, denominado de The Value of Standards, reala vrias vantagens na especificao de normas de mercado onde cerca de 31% das empresas afirmam que as normas aumentam o valor dos actuais e futuros investimentos em SI, e 29% destas valorizam a portabilidade dos dados (Figura 2.26). Ainda no mesmo estudo, foi perguntado aos inquiridos quais eram as normas que deveriam estar garantidas nas solues apresentadas pelos seus fornecedores (Figura 2.27). Destaca-se claramente o XML como norma para a estruturao e portabilidade da informao em vrios domnios. Logo a seguir surgem duas normas relativas a plataformas de desenvolvimento de aplicaes: o J2EE da SUN com 44% e o .Net da Microsoft com 36%. O protocolo SOAP surge com 35% e est relacionado com os Web Services e a troca de informao baseada em XML.
No caso da integrao de SI, a identificao das normas a adoptar pode revelarse difcil e confusa visto que existem vrios organismos e empresas, com diferentes interesses, que participam nestas especificaes. Geralmente, a evoluo do mercado e das prprias tecnologias que dita a actualidade e a adopo de cada uma das normas que vo surgindo. Estas so normalmente identificadas pelo nome de standard e so os alicerces para a construo de solues integradoras abertas e certificadas.
http://www.delphigroup.com/research/whitepapers.htm
35
A implementao mais complexa do que o esperado. Falta de comunicao na organizao. Falta de metodologias normalizadas e abragentes para a integrao de SI. Problemas com a integridade de informao e as transaes associadas. Modelos de dados heterogneos. Diferenas entre a implementao de uma aplicao e a integrao de SI. Tecnologias incompatveis. Falta de estratgia na gesto e planeamento dos SI. Escolha de solues menos adequadas. Desconhecimento ou falta de documentao da estrutura dos SI em uso.
Os projectos para a integrao de SI beneficiam a organizao como um todo permitindo melhorar o seu desempenho e dinmica a todos os nveis [Kelly 2003]. Neste mbito, existem abordagens na definio de padres conceptuais para representar tecnologias e aces na fase de anlise de um projecto de integrao de SI [Yee 2001, Hohpe et al. 2003]. A criao de modelos conceptuais para a integrao de SI tem sido uma das abordagens para a modelao deste tipo de sistemas complexos. O EAI Industry Consortium tem desenvolvido esforos para a definio de uma metodologia para a integrao de SI, e defende que qualquer metodologia potencial nesta rea tem de ter em conta cinco diferenas de base face s metodologias tradicionais que abarcam o ciclo de vida de um projecto de desenvolvimento de SI:
O todo maior que a soma das partes. Projectos em constante mutao. No h normas universais e o leque de escolha alargado. Contexto da informao dinmico com interpretaes diversas.
36
Independentemente das formas de representao ou das metodologias, para que um projecto desta natureza tenha sucesso tem de se garantir algumas condies fundamentais sob pena de no se obter os resultados desejados:
Apoio e envolvimento da Direco da organizao Anlise custo/benefcio do investimento a mdio e longo prazo Gesto de processos organizacionais Abordagem e planeamento estruturado para o projecto e sua equipa Normas e arquitecturas tcnolgicas certificadas Potenciar investimentos em SI j existentes
Nesta rea, h claramente duas alternativas para a obteno da soluo. A primeira constru-la medida, e a outra comprar um sistema especfico. Em qualquer dos casos, imperativo analisar a adequao, o impacto e o retorno de tal investimento para a organizao.
Todas as solues para a integrao de SI suportam e controlam a comunicao entre sistemas heterogneos permitindo a sua compatibilidade. Em cada uma delas encontram-se diferentes funcionalidades que devem geralmente ter em conta quatro desafios fundamentais [Hohpe et al. 2003]:
Troca de dados entre sistemas: As solues para a integrao de SI tm de transportar dados entre computadores atravs de redes de comunicao.
Utilizao de redes de computadores: A computao distribuda tem de lidar com um grande nmero de problemas que podem gerar atrasos ou interrupes. O envio de dados atravs de uma rede normalmente muito mais lento do que a invocao local de um mtodo ou procedimento remoto.
37
Heterogeneidade dos sistemas interligados: As solues de integrao de SI precisam de transmitir informao entre sistemas que usam diferentes linguagens de programao, plataformas operacionais e formatos de dados. Estas solues devem permitir interligar estas diferentes tecnologias.
Impacto das mudanas dos sistemas interligados: Estas solues devem tambm garantir que as mudanas nas aplicaces informticas interligadas no tenham grande impacto na soluo integradora encontrada. Para isso devem minimizar as dependncias entre sistemas usando a filosofia de loose coupling que permite proteger os sistemas das mudanas efectuadas nos outros sistemas com os quais tm ligaes.
Para alm destas situaes, as solues para a integrao de SI devem fornecer documentao clara e inequvoca das suas funcionalidades e das suas bases tecnolgicas. Estas devem tambm seguir as normas de mercado para garantir a sua abertura, adaptabilidade e certificao. Desta forma reforada a garantia de independncia e credibilidade, protegendo as organizaes de dependncias tecnolgicas ou da inadequao das solues encontradas [Allen 2001]. A integrao de SI , para alm de complexa, uma rea cada vez mais estratgica para as organizaes no sentido em que pode pr em causa o seu bom funcionamento e desempenho.
2.7 Concluso
A integrao de sistemas pode revelar-se complexa no seu entendimento e na sua implementao. Os Sistemas de Gesto de Bases de Dados (SGBD), os Remote Procedure Calls (RPC), os Integration Brokers (IB) ou os Messaging-Oriented Middlewares (MOM) so alguns exemplos de solues tecnolgicas abrangentes que permitem integrar aplicaes informticas, directamente ao nvel dos seus dados ou dos seus procedimentos. Existem perspectivas mais especficas, como a integrao de aplicaes, que fornecem um conjunto de funcionalidades para troca de informao sncrona ou assncrona, garantindo a capacidade de resposta dos sistemas heterogneos. Por seu turno, a perspectiva da integrao de processos d maior
38
importncia aos processos organizacionais permitindo automatiz-los integrando diferentes tipos de aplicaes informticas. J a um nvel externo, a perspectiva da integrao inter-organizacional centra-se na informao e nos processos partilhados entre diferentes organizaes. Face a todos estes factores, pode-se definir diferentes abordagens, ou vises, para a integrao de SI de acordo com perspectivas tecnolgicas e funcionais abrangentes. O nvel da complexidade organizacional vai determinar o tipo de abordagem a seguir face a cada perspectiva. Neste sentido so identificadas, e detalhadas, neste trabalho trs orientaes para integrao de SI que se centram nos seguintes pontos: A informao. As aplicaes informticas. Os processos organizacionais. Cada viso da integrao de SI tem solues enquadradas em vrias arquitecturas tecnolgicas e em diversas normas de mercado. Cada uma pode partilhar conceitos e tecnologias semelhantes e chegam mesmo a ser complementares. O surgimento dos Web Services criou uma nova viso desta problemtica permitindo novas abordagens para as diversas formas de integrao de SI. Esta tecnologia possibilita definir uma Arquitectura Orientada aos Servios (Service Oriented Architecture - SOA) que suporta diferentes tipos de integrao de sistemas baseandose nas especificaes tcnicas e normalizadas dos Web Services.
39
1. Perspectiva da integrao da informao. 2. Perspectiva da integrao aplicacional. 3. Perspectiva da integrao dos processos.
Como tambm foi referido, a evoluo das TI potencia novas arquitecturas que permitem criar camadas tecnolgicas integradoras para os sistemas de informao existentes. Neste mbito, os Web Services permitem isolar uma aplicao, ou um sistema, e disponibiliz-los como um servio. possvel desta forma equacionar a integrao dos sistemas de informao numa quarta perspectiva mais abrangente:
Cada uma destas perspectivas tem partes comuns e pode resolver problemas idnticos. A escolha da soluo depender da realidade da organizao, das suas necessidades, dos seus processos, das TI existentes e da estratgia de integrao encontrada
Neste captulo descreve-se cada uma das perspectivas de forma a poder diferenci-las e enquadr-las com o tema da integrao. Em complemento, e para cada uma delas, feita uma associao com as respectivas normas e tecnologias mais comuns existentes no mercado. No final so apresentados alguns quadros que permitem relacionar perspectivas, normas e tecnologias.
40
Devido importncia da informao dentro das organizaes foram surgindo tecnologias para o seu armazenamento e explorao. Em primeiro lugar, apareceram os sistemas de gesto de ficheiros [Pereira 1998] associados linguagem de programao COBOL (COmmon Business Oriented Language) que tiveram uma grande difuso no mercado. Para colmatar as lacunas existentes, surgiram os Sistemas de Gesto de Base de Dados (SGBD) que permitiram centralizar o acesso informao e criar repositrios estruturados de informao e cdigo aplicacional (Figura 3.1). Este tipo de soluo tambm permite transportar e replicar informao
41
entre repositrios afim de sincronizar o seu contedo ou obter um novo repositrio com informao estruturada. Estas operaes so por exemplo efectuadas atravs de funcionalidades de ETL (Extraction-Transformation-Loading), Data Replication e outras formas de troca de informao. Nos pontos seguintes deste captulo detalha-se algumas das solues mais comuns para a perspectiva da integrao da informao.
Com o objectivo de partilhar informao entre duas aplicaes informticas, existem solues tecnolgicas que permitem enviar dados de uma aplicao para outra, com suporte em diferentes plataformas e mtodos. Por exemplo, atravs de uma rede de computadores, uma aplicao pode enviar informao armazenada num ficheiro de texto electrnico para outra aplicao, que o recebe e interpreta o seu contedo (Figura 3.2). A informao contida no ficheiro est estruturada de forma a que ambas as aplicaes entendam o seu contedo e possam dar-lhe a mesma interpretao. Este exemplo centra-se no envio de informao num nico sentido, mas existem solues mais complexas que permitem gerir a troca de ficheiros nos dois sentidos, e que requerem algoritmos especficos para controlar a integridade e consistncia da informao.
comum integrar duas ou mais aplicaes atravs da informao que manuseiam, centralizando-a num nico repositrio. Neste caso, so normalmente usados Sistemas de Gesto de Base de Dados (SGBD) com diferentes formas de armazenar e disponibilizar a informao (Figura 3.3). Esta abordagem permite controlar
42
eficazmente a integridade e actualidade do seu contedo. Para alm da informao estruturada, a grande maioria dos SGBD permite tambm armazenar e partilhar ficheiros e cdigo aplicacional.
Os SGBD funcionam como repositrios de informao seguindo um modelo de dados nico e comum a todas as aplicaes existentes. Os SGBD seguiram entre outros os modelos hierrquicos, relacionais e object-oriented [Pereira 1998]. Neste mbito, a forma mais comum de acesso informao usa a linguagem de interrogao SQL (Structured Query Language) [Date 2003]. Neste mbito, a modelao mais comum a criao de diagramas do tipo Entity-Relationship Model (E-R) [Thalheim 2000] que permitem documentar modelos relacionais de dados que so implementados e geridos num motor de base de dados relacional (SGBDR - Sistema de Gesto de Base de dados Relacional). Esta abordagem garante a qualquer sistema que a informao est actualizada e homognea, sem estar repetida nem dispersa.
43
Com base nos SGBD surgem solues do tipo Data Hub (DH) cujo objectivo fornecer repositrios genricos, com modelos de dados genricos, abrangentes e previamente definidos, para servir qualquer aplicao dentro de uma organizao (Figura 3.4). O exemplo mais comum o repositrio nico de clientes de uma empresa, no DH, sobre o qual so feitas todas as actualizaes por parte de cada sistema informtico.
Apesar da proliferao dos SGDB como primeiro nvel de integrao da informao, as organizaes podem necessitar de consolidar diversas fontes de informao. Existem vrios mecanismos de sincronizao de informao entre bases de dados. O mais comum centra-se na replicao de dados (Data Replication) de forma sncrona ou assncrona. Este tipo de software encarrega-se de actualizar as vrias bases de dados para garantir a consistncia e a integridade da totalidade da informao. Com diferentes periodicidades, cada base de dados ter uma rplica fiel da informao existente nas restantes (Figura 3.5). A abordagem mais comum encontra-se nas empresas que tm colaboradores cujo trabalho andar pelo pas a vender ou entregar mercadorias. Cada um deles pode ter uma pequena base de dados instalada num computador porttil que lhe permite ir actualizando informao. Os diversos mecanismos de replicao encarregam-se de actualizar a informao entre as n pequenas bases de dados e a base de dados central da organizao. Estes mecanismos asseguram a resoluo de eventuais conflitos.
44
As solues do tipo ETL (Extraction-Transformation-Loading) permitem actualizar de forma assncrona diferentes fontes de informao. Enquanto a replicao entre bases de dados abrange toda a informao existente, o ETL centra-se em conjuntos de informao identificados. Esta abordagem normalmente seguida para obter repositrios de informao reorganizados, sobre os quais se efectuam operaes analticas e no transaccionais. As operaes de ETL esto normalmente relacionadas com a rea dos Datawarehouses, ou de DataMining, mas podem ser utilizadas para replicao de informao entre repositrios, assumindo neste caso um papel de integrao de informao. Para isso, as solues de ETL evoluram para permitir um acesso online a um conjunto de informao agregada, aproximando-se das funcionalidades de ECM e EII descritas a seguir.
Os procedimentos de ETL executados em modo batch permitem extrair e mover dados a partir de diferentes fontes, format-los, filtr-los e carreg-los para outros repositrios de forma a fornecer uma base de informao de gesto (Figura 3.6). Uma das etapas mais importantes tem a ver com a operao de filtragem de dados, ou depurao, que tambm designada por cleansing. As solues ETL so teis para produzir repositrios que sero utilizados em tarefas de anlise histrica de informao e suportar decises de gesto.
45
A frequncia com que se fazem operaes de ETL, e pela sua orientao informao, pode no se revelar suficientemente rpida para a dinmica da organizao, e pode no suportar as reais necessidades de integrao. No caso dos sistemas transaccionais do tipo OLTP, tem de haver uma frequncia elevada de sincronizao da informao entre repositrios. Nestes casos, os SGBD fornecem solues de replicao, assim como as solues do tipo Gateways de integrao ou pode-se tambm utilizar solues do tipo TPM (Transaction Processing Monitors) [Dickman 1995] que controlam a actualizao da informao em diversos repositrios, garantindo a sua integridade, sincronismo e actualidade. Os TPM garantem a consistncia da informao distribuda controlando a execuo das transaces entre sistemas e garantindo a partilha de informao [Hudson e Johnson 1994]. Este tipo de funcionalidade encontra-se na rea das solues de Middleware, em particular nas tecnologias de Message Queueing em que se baseiam os Integration Brokers. Encontram-se aqui diversas alternativas para troca e partilha de informao.
Os diferentes sistemas envolvidos no interpretam nem gerem forosamente a informao da mesma forma. Neste sentido, as solues integradoras de informao devem ter funcionalidades que garantam o sucesso quer do envio quer da recepo da informao. Estas caractersticas centram-se no tratamento dos dados veculados de forma a que cada sistema interveniente entenda o seu contudo e lhe d uma correcta interpretao. As principais funes para o controlo da integrao da informao ao nvel do Middleware so:
Data Mapping: Tratamento da correspondncia correcta dos dados entre sistemas. Data Translation: Traduo do significado da informao entre sistemas. Data Transformation: Transformao de dados entre sistemas. Data Validation: Validao da correco dos dados. Data Routing: Correcto encaminhamento de dados entre sistemas. Data Common view: Estrutura de dados comum entre os sistemas.
46
Estas funes validam, traduzem, transformam e encaminham os dados com o objectivo de garantir que estes so sempre entendveis e interpretados correctamente pelos sistemas receptores.
Com o objectivo de centralizar o acesso informao, possvel integrar informao de diversas fontes ao nvel da sua apresentao ao utilizador (User Interface - UI) (Figura 3.7). Por exemplo, atravs de um web browser, um utilizador poder aceder, atravs de um nico cran, a informao diversa para a qual tem autorizao.
Dentro das solues de Middleware, a maioria dos Application Servers (AS) disponibilizam funcionalidades, na rea dos Web Servers, designadas por Portal e que incluem esta finalidade. Este tipo de integrao da informao est tambm relacionado
com as reas de ECM (Enterprise Content Management) [Jenkins et al. 2004] e de EII
47
As abordagens do tipo ECM (Enterprise Content Management) tem como objectivo integrar a informao ao nvel da camada de apresentao (Figura 3.8). O ECM teve origem em primeiro lugar na gesto documental e depois na gesto de contedos para a Web. Na rea do ECM encontram-se essencialmente os portais empresariais que consolidam informao no estruturada de diversas origens. Considera-se por exemplo como informao no-estruturada os ficheiros de texto ou de imagem. Embora a rea do ECM esteja fortemente conotada com a gesto de contedos, esta j comea a englobar integrao de informao estruturada normalmente armazenada em bases de dados. No ECM encontram-se solues do tipo portal que servem de pea integradora para diferentes fontes de informao, quer sejam aplicaes acessveis via web, quer sejam documentos ou outro tipo de informao no estruturada. O objectivo mais comum de uma soluo de ECM a gesto centralizada de contedos informativos para dentro de uma organizao. O ECM pode ser considerado como um subconjunto do EII (Enterprise Information Integration).
48
As solues de EII (Enterprise Information Integration) so mais abragentes do que o ECM. Estas permitem agregar informao de vrias fontes, interagir com ela, como se estivesse num nico repositrio centralizado, mantendo a sua disperso e controlando as diferentes operaes feitas sobre ela (Figura 3.9). Estas solues so por vezes designadas de ECM mas tm um leque de funcionalidades e objectivos muito mais abragentes. O EII fornece um acesso normalizado informao integrada, com diferentes origens, permitindo ter uma viso lgica e nica de toda a informao que est fisicamente armazenada em sistemas heterogneos. disponibilizada uma fonte de informao virtual e centralizada fornecendo s aplicaes uma nica camada de informao e eliminando a complexidade da gesto de diferentes conexes a diferentes fontes de informao. O EII abrange as funcionalidades de ETL, ECM e TPM que permitem a agregao da informao num repositrio dinmico.
Na rea do EII surgem tambm funcionalidades analticas complementares de Business Intelligence (BI) [Vitt et al 2002], onde se incluem as solues de Business Activity Monitoring (BAM) [McKie 2003], que permitem obter em tempo real informao de gesto acerca da organizao em causa, e disponibiliz-la de forma legvel e estruturada aos respectivos gestores. As aplicaes do tipo Client Relationship Management (CRM) [Reynolds 2002] tiram partido das solues de ECM/EII para obter informao consolidada dos clientes da organizao em questo.
49
Por seu turno, muitas das estratgias empresariais para o Knowledge Management (KM) [Serrano e Fialho 2003] tiram tambm partido das tecnologias de ECM/EII para partilhar informao. Cada abordagem vai depender do tipo de informao e do processo de integrao pretendido (Figura 3.10).
Praticamente todas as solues referidas neste captulo tiram partido do XML (eXtended Markup Language), quer para o armazenamento, quer para a troca de informao. Esta norma define uma linguagem padro para a representao e troca de informao independentemente das tecnologias. O XML permite obter um grau elevado de portabilidade da informao e claramente uma norma incontornvel para qualquer abordagem na integrao de SI.
Salienta-se que a maioria das solues que integram a informao, quer com ETL, quer com ECM/EII, no tm funcionalidades de automatizao de processos tipicamente existentes nas reas do Enterprise Application Integration (EAI) ou do Business Process Management (BPM). O contrrio j no acontece dado que existem solues de EAI e BPM que permitem integrar informao numa lgica de replicao, de ETL ou mesmo de ECM/EII.
50
A integrao da informao mais complexa do que simplesmente juntar ou interligar fontes de informao. Trata-se por um lado de aceder aos repositrios certos nos momentos certos, e por outro lado, armazenar e sincronizar de forma correcta todas as fontes de informao existentes. Todos os esforos de consolidao e integrao nesta rea implicam uma procura de consistncia e de qualidade da informao. Esta integrao tem muitas abordagens vlidas que por vezes se sobrepem. Existem neste sentido diferentes mtodos ou solues para a integrao de informao consoante o objectivo pretendido. Cada soluo complementa-se com funcionalidades normalmente existentes noutras abordagens, por exemplo, as solues de ECM e de EII partilham caractersticas idnticas e tendem a confundir-se.
Qualquer um dos caminhos referidos neste captulo permitir obter uma viso consolidada da informao, quer ao nvel do seu armazenamento, quer do seu acesso ou disponibilizao. Ainda neste mbito, comeam a surgir normas de mercado como so, por exemplo, o Web Services for Remote Portlets (WSRP) especificada pela
Organization for the Advancement of Structured Information Standards (OASIS), ou o Java Specification Request (JSR) 168 definida pelo Java Community Process (JCP) que permitem a interoperabilidade de componentes do tipo portlet [Hepper 2003] entre diferentes plataformas. Nesta rea, o XML claramente a norma mais presente quer para estruturar a informao no seu armazenamento, quer para a sua troca, distribuio e apresentao.
51
Uma aplicao pode ser vista como uma combinao de componentes complementares e para cada uma delas existem diferentes formas de integrao. Neste caso, o mbito centra-se na prpria estrutura das aplicaes onde se pode identificar 3 reas passveis de interveno:
Em cada um destes pontos as aplicaes podem necessitar de integrao para comunicarem, partilharem e integrarem funcionalidades de outros sistemas aplicacionais. Neste sentido, qualquer abordagem para a integrao de SI vai depender da forma como as aplicaes esto construdas e em que plataformas esto baseadas. Ao longo dos tempos, passou-se de um desenvolvimento em linguagens, por exemplo com o COBOL, para o paradigma dos objectos dominado pela linguagem C++ e as normas CORBA (Common Object Request Broker Architecture) [Zahavi 1999, Serain 2002] e COM (Component Object Model) [Serain 2002]. Com o surgimento das arquitecturas em n camadas, e da Internet, outras solues de computao distribuda [Coulouris et al. 2000] dominaram a forma de implementao das aplicaes. Resumindo as abordagens mais comuns para este tipo de integrao pode-se identificar as seguintes reas:
Codificao especfica (ex: COBOL, C++ ou Java) Application Program Interface (API) Remote Procedure Calls Transaces distribudas: TP monitors CORBA, Java RMI e DCOM Messaging Middleware Web Services
Com a evoluo das normas e da tecnologia surgiram duas correntes paralelas onde se especificaram plataformas completas de desenvolvimento e disponibilizao de aplicaes: o J2EE e o .NET. Nelas existem funcionalidades para a integrao de aplicaes para cada uma das camadas estruturantes. A viso deste tipo de integrao
52
pode ainda mais ser mais alargada, quer no tipo de solues, quer no seu mbito, e neste sentido possvel distinguir a integrao de aplicaes dentro de uma organizao e aquela que implementada entre duas ou mais organizaes. Neste ltimo caso, est-se no mbito das solues do tipo Business-to-Business Integration (B2Bi) que permitem definir formas de comunicao partilhando informao e aplicaes.
A integrao aplicacional centra-se nas solues que permitem a interligao de aplicaes para poder partilhar informao e a sua lgica aplicacional. No mercado das TI existem vrias ofertas tecnolgicas que permitem centralizar a integrao de SI nas suas diversas facetas.
Uma primeira abordagem para integrar dois sistemas heterogneos a sua integrao directa (Figura 3.11). Esta soluo resolve um problema especfico mas pode ter custos elevados e no se revelar suficientemente flexvel e adaptvel no futuro. No entanto uma alternativa til quando se procura aproveitar, de forma simples e directa, as potencialidades de determinadas funcionalidades incorporando-as numa aplicao. Este tipo de interligao pode ser implementado de vrias formas que passam pela simples troca assncrona de ficheiros, pela criao de um canal de comunicao sncrono e dedicado com sockets e respectivo cdigo at incorporao directa de lgica aplicacional externa. Esta ltima situao pode ser conseguida com os JavaBeans, CORBA ou mdulos aplicacionais. Neste caso, o objectivo o de
53
Mas a forma de conceber aplicaes evoluiu com os tempos e criou modelos aplicacionais diferentes. Cada adordagem vai influenciar a proximidade das aplicaes determinando diferentes caminhos para a sua interligao. Pode-se identificar pelo menos trs situaes [Lewis 2000] (Figura 3.12): 1. Cliente/Servidor 2. Transaces distribudas 3. Messaging
A variao depende do nvel de proximidade, ou acoplamento, que vai desde as situaes de acoplamento forte (tight coupling) at s de acoplamento fraco (loose coupling). Em cada uma das situaes haver tecnologias e abordagens diferentes no que diz respeito integrao aplicacional. Para cada caso existem alternativas de comunicao e partilha de informao e procedimentos (Quadro 3.1).
54
No caso da arquitectura Cliente/Servidor possvel colocar dois sistemas a comunicar directamente com a invocao de funes ou procedimentos remotos (RPC) [Rao 1995, Serain 2002] disponibilizados por interfaces aplicacionais (API) [Hines 1996]. Trata-se de um canal de comunicao sncrono e directo onde cada invocao espera uma resposta. Esta realidade assume que existem sistemas servidores dedicados a responder s solicitaes dos sistemas clientes. Este tipo de integrao est no nvel da lgica funcional das aplicaes (Figura 3.13). Para alm dos RPC e das API pode-se tirar partido da tecnologia dos objectos distribudos (DCOM, CORBA, EJB e JavaRMI) que se enquadram geralmente neste tipo de abordagem.
55
Nos casos em que necessrio controlar transaces aplicacionais, que actualizam informao operacional, pode-se recorrer aos SGBD ou a solues especficas como so por exemplo os monitores transaccionais. Os SGBD suportam a partilha assncrona de informao, o acesso a procedimentos armazenados contendo lgica aplicacional. Por seu turno, os monitores transaccionais controlam a execuo de transaces aplicacionais permitindo uma integrao efectiva entre aplicaes. Este tipo de gesto de transaces permite, por exemplo, executar lgica aplicacional remota, controlar transaces distribudas entre sistemas heterogneos, tratar eventos despoletando a respectiva sequncia de tarefas associadas, aceder e actualizar informao nos SGBD ou controlar a comunicao com as camadas de apresentao das aplicaes.
As situaes em que as aplicaes esto num ambiente loose coupling a integrao pode ter como base a tecnolgica o Messaging que se encontra nas solues do tipo Message-Oriented Middleware (MOM) ou nas solues proprietrias do tipo Message Broker (MB) (Figura 3.14). Os MB comerciais disponibilizam normalmente um conjunto de adaptadores especficos para aplicaes e protocolos de comunicao. Estas solues operam como uma plataforma de troca de mensagens entre aplicaes e so elas prprias denominadas de plataformas EAI. Os MOM gerem as filas de mensagens (Message Queues) para a troca e o transporte de informao entre as aplicaes. As plataformas MOM recebem as diferentes mensagens de diferentes aplicaes, transformando o seu contedo e mandando-as para as aplicaes de destino. Estas solues tm trs tipos de intuitos:
Desenvolvimento e disponibilizao de adaptadores aplicacionais. MOM para propagao de mensagens e informao. Gesto de regras de encaminhamento e transformao da informao.
56
Baseado em protocolos de comunicao em rede, as solues do tipo MOM permitem diferentes formas de comunicao baseadas em mensagens. A informao encapsulada em mensagens estruturadas que so enviadas de duas formas: sncrona ou assncrona [Steinke 1995]. Neste mbito pode-se identificar pelo menos trs padres de comunicao [Hohpe et al. 2003]:
1. Peer to peer ou Point to point 2. Hub and Spoke 3. Bus ou Pipeline ou Publish and Subscribe
A comunicao Point to Point permite cria um canal de comunicao assncrono e especfico entre duas aplicaes para a troca de mensagens (Figura 3.15).
A topologia Hub and spoke centraliza a comunicao num canal de comunicao assncrono e comum (Hub) para troca de informao (Figura 3.16). Esta soluo tambm frequentemente designada por EAI Middleware.
57
Na comunicao do tipo Publish/Subscribe so difundidas mensagens para um ou mais destinos que as reconhecem subscrevendo a sua recepo (Figura 3.17). A canal de comunicao denominado de Bus permitindo uma comunicao assncrona de sistemas federados.
Ao longo dos tempos o desenvolvimento de aplicaes foi acompanhando a tecnologia e a sua evoluo. Qualquer aplicao est normalmente alicerada numa base tecnolgica que suporta e executa o seu cdigo. Neste sentido existem plataformas aplicacionais que fornecem um conjunto de especificaes, directrizes, suporte tecnolgico e ferramentas de anlise e de desenvolvimento. Estes ambientes 58
permitem seguir todo o ciclo de vida de desenvolvimento aplicacional nas suas fases de anlise, concepo, implementao e disponibilizao. Em complemento, so disponibilizadas funcionalidades de segurana, integrao, performance e fiabilidade que garantem o bom funcionamento de aplicaes distribudas e assentes em n camadas.
Neste mbito as duas plataformas aplicacionais mais comuns so: .NET e J2EE. A primeira assenta numa norma da Microsoft e a segunda numa norma da SUN baseada na linguagem Java. Cada uma est organizada por camadas tecnolgicas (Figuras 3.18 e 3.19) que garantem toda o conjunto de funcionalidades desde a gesto do acesso informao, passando pelas comunicaes at camada de apresentao das aplicaes. Cada camada permite vrias formas de integrao, referidas nos pontos anteriores, disponibilizando-as em pleno ambiente de desenvolvimento aplicacional. Estas plataformas permitem suportar arquitecturas do tipo
59
A plataforma .NET fornece um conjunto de bibliotecas de software, ferramentas de desenvolvimento, especificaes para codificao, uma rea comum de execuo de cdigo e vrias alternativas de linguagens de programao. A plataforma J2EE fornece um conjunto completo de especificaes que ilustra como se deve implementar cada tipo de funcionalidade com a tecnologia Java. Esta plataforma fornece uma rea de trabalho completa que abrange as reas de concepo, desenvolvimento, assemblagem, execuo e disponibilizao aplicacional. As aplicaes resultantes, concebidas em Java, esto baseadas num modelo aplicacional distribudo por n camadas.
Segurana e Autenticao Capacidade de crescimento e tolerncia a falhas Gesto de transaces Servios de directrio e gesto de sesses Integrao aplicacional Administrao Execuo aplicacional (Runtime) Messaging Gesto de conexes e comunicaes Reporting e Business Intelligence Desenvolvimento, disponibilizao e execuo aplicacional Web Services Business Process Management e Workflow Acessos diferenciados (Web Browser, Wireless, etc..)
Como se pode ver no quadro comparativo (Quadro 3.2), possvel fazer algumas comparaes simples entre o .NET e o J2EE de forma ter uma viso mais clara sobre algumas diferenas bsicas entre estas duas normas.
60
J2EE
Ferramentas de desenvolvimento - Vrias no mercado compatveis
.NET
- Visual Studio.NET
Servidores Aplicacionais
- Microsoft
Sistemas Operativos
- Windows
- XML Messaging (JAXM) - XML Processing (JAXP) - XML Registries (JAXR) - XML based RPC (JAX-RPC) - XML Data Binding (JAXB) - SAAJ Java SOAP API - JSR 109 WS Deployment Model
A grande maioria dos servidores aplicacionais do mercado, assim como aplicaes comerciais, esto baseados numa destas duas plataformas.
Muitas organizaes adoptaram solues classificadas como Application Servers (AS) que incorporaram a grande maioria das alternativas de integrao referidas neste captulo. Um AS um software baseado em componentes, que se situa conceptualmente na camada de middle-tier da arquitectura n-tier ilustrada no captulo anterior. Os AS incorporam funcionalidades da camada de Middleware (Figura 3.20) e permitem suportar aplicaes, disponibiliz-las para a camada cliente, trocar informao entre elas, partilhar lgica aplicacional e integrar funcionalidades.
61
Os AS fornecem uma plataforma de desenvolvimento e disponibilizao de servios que permite aos programadores concentrar-se nas regras da organizao, em vez de investir tempo na codificao de funcionalidades bsicas e complexas para a camada de middleware. Estas solues disponibilizam normalmente ferramentas de desenvolvimento, servios de execuo e disponibilizao de aplicaes,
funcionalidades para integrao de SI e de autenticao e segurana. Os AS tm normalmente trs grupos de funcionalidades (Figura 3.21) para o desenvolvimento aplicacional:
1. Ferramentas integradas de desenvolvimento de cdigo. 2. Plataforma de suporte, interpretao, validao e execuo do cdigo. 3. Ambiente de deployment que armazena, executa e disponibiliza aplicaes.
62
Os AS permitem suportar plataformas aplicacionais com capacidades de resposta e de crescimento fiveis, permitindo disponibilizar diferentes pontos de acesso para as aplicaes. Para alm destas caractersticas, estes sistemas incorporam funcionalidades de acesso a diferentes fontes de informao, gesto de segurana e de integrao baseadas num canal de comunicao central chamado Hub, ou Bus, que suportam a tecnologia de Messaging j referida.
Alguns servidores aplicacionais disponibilizam componentes de ligao a aplicaes especficas denominados por adaptadores ou conectores. Este tipo de software normalmente proprietrio e especfico, mas surgem tambm componentes baseados em normas de mercado como so os Web Services. Para alm dos adaptadores so tambm disponibilizadas funcionalidades de automatizao de processos organizacionais. Estas solues so tambm denominadas por Integration Brokers (IB) ou por Integration Middleware. Ainda neste mbito existem solues isoladas classificadas como Gateways, com vrias configuraes, e que servem exclusivamente para a integrao aplicacional ao nvel das suas transaces. Estas solues funcionam como uma ponte, entre dois ou mais sistemas, proporcionandolhes o controlo da interaco ao nvel da informao e dos procedimentos. Atravs deste tipo software centralizado as aplicaes conseguem trocar informao e invocar procedimentos entre elas.
Os AS normalmente tambm permitem a integrao de SI ao nvel do User Interface. Dentro de uma organizao, as Intranets permitem incorporar informao e aplicaes para as disponibilizar atravs de um nico ponto de acesso atravs, por
63
exemplo, de um web browser. Alguns AS podem ser utilizados como servidores Web tendo mesmo funcionalidades para a criao de portais internos, ou externos, que possibilitam a gesto de contedos do tipo ECM ou EII j referidos. Este tipo de integrao recorre a componentes do tipo portlet [Hepper 2003] que funcionam como pequenos contentores dinmicos de informao, lgica aplicacional ou aplicaes. Muitos destes AS j esto preparados para permitir acessos diferenciados mesma fonte de informao (Figura 3.22). Com a evoluo da tecnologia, os fornecedores de AS incorporaram tambm funcionalidades de gesto processual que permitem automatizar processos organizacionais mais complexos.
Os AS so hoje uma excelente soluo para a integrao de aplicaes devido ao conjunto rico de funcionalidades que oferecem. A adopo de servidores aplicacionais permite criar uma infraestrutura de integrao completa onde se pode criar regras de transformao e troca de informao, integrar aplicaes e centralizar o seu acesso.
Este tipo de integrao normalmente designado por Business-to-Business Integration (B2Bi) [Bussler 2003]. Trata-se de coordenar a comunicao entre duas ou mais organizaes ao nvel dos seus SI para que esta seja efectiva e segura. Este tipo de coordenao faz sentido nos relacionamentos existentes entre parceiros comerciais ou do tipo cliente/fornecedor. Este tipo de soluo enquadra-se ao nvel da dinmica organizacional no que diz respeito s trocas comerciais, coordenao processual e suporte cadeia de valor associada s organizaes envolvidas. Desta forma possvel aumentar a eficincia dos processos organizacionais, reduzir custos operacionais, optimizar e automatizar a troca de informao.
As solues do tipo B2Bi devem garantir um conjunto de funcionalidades bsicas como so:
Garantir o suporte s transaces especficas entre as organizaes Automatizar a troca de dados entre sistemas heterogneos 64
Manter informao histrica dos processos efectuados Segurana na troca de dados Suportar diferentes conjuntos de formatos de ficheiros, normas e protocolos de comunicao e segurana Capacidade de crescimento, balanceamento de carga e tolerncia a falhas Disponibilizar reporting para informao de gesto
A primeira abordagem para o B2B foi a soluo EDI (Electronic Data InterChange) que se caracteriza por um conjunto de formatos de mensagens estruturadas e a especificao dos seus elementos para permitir a troca electrnica de informao entre empresas ou organizaes. Trata-se do intercmbio de informao entre parceiros autnomos que se associam e definem todos os tipos de documentos que vo trocar electronicamente e formatados segundo normas previamente acordadas. Reconhecido pela ANSI (American National Standards Institute), o comit ASCX12 (Accredited Standards Committee X12) especificou desde os anos 70 mais de 315 conjuntos de transaces EDI para as diversas situaes de troca de documentos entre organizaes. Na Europa o directrio de transaes EDI UN/EDIFACT (Figura 3.23) abrange as reas dos transportes, comrcio e administrao. Com o aparecimento da Internet surge o conceito de EDIINT (EDIInternet Integration) que abrange as especificaes para usar EDI sobre a Internet. Neste sentido a comunidade tcnica IETF (Internet Engineering Task Force) desenvolve esforos onde por exemplo foi definido o RFC 1767 que especifica uma forma de encapsulamento de mensagens EDI para ser enviadas atravs dos protocolos SMTP e HTTP.
65
Aps um primeiro esforo para juntar o EDI e o XML com a definio XML/EDI, o comit tcnico OASIS (Organization for the Advancement of Structured Information Systems) e a United Nations/ECE agency apresentaram o ebXML (ebusiness XML). Trata-se de um mtodo normalizado em XML para registar e implementar a integrao de processos organizacionais, a troca de mensagens e a comunicao de informao entre organizaes.
O consrcio RosettaNet promove e implementa um conjunto de especificaes para suportar o B2B designado por RNIF (RosettaNet Implementation Framework). Este pacote de normas especifica a forma de transporte, encaminhamento e estruturao de mensagens PIP (Partner Interface Processes) e eventos de negcio. O nome RosettaNet deriva da conhecida Pedra de Rosetta que tem gravada a mesma mensagem em trs lnguas e permitiu decifrar os hieroglifos egpcios. Tal como a
66
pedra esta organizao definiu um conjunto de mensagens e procedimentos que permitem s empresas automatizar os seus processos e integrar os seus negcios.
A normalizao da troca electrnica de dados entre organizaes claramente uma rea que requer solues para a integrao dos SI envolvidos. Existem vrias abordagens que se suportam em tecnologias e normas especficas referidas nos pontos anteriores. O XML e os Web Services permitem disponibilizar um novo nvel de integrao nesta rea e so hoje em dia normas incontornveis.
A rea da integrao de aplicao, dentro e fora das organizaes, tem vrias solues que dependem da natureza da construo dos sistemas aplicacionais e das prprias organizaes. A evoluo das TI e das normas acompanham este tipo de necessidades e tem vindo a reforar as ofertas de alternativas em cada uma das reas e camadas tecnolgicas. Existem plataformas aplicacionais completas e com provas dadas no mercado que asseguram o suporte a qualquer tipo de integrao necessrio. As normas que permitem a portabilidade da informao e uma independncia tecnolgica, como so os Web Services e o XML, tm tido um papel cada vez mais preponderante.
67
organizao e facilitar a obteno de informao de gesto que permite suportar as tomadas de deciso ao nvel da administrao.
Processos repetitivos Produo - Aplicaes do negcio - Aplicaes para Seguros - Gesto de crditos bancrios - Administrativo - Aprovao de relatrios de despesas - Aprovao de compras - Gesto e aprovao de pedidos de frias -
Processos nicos Colaborao - Gesto documental de alto nvel - Gesto de processos de colaborao - Criao de documentos tcnicos - Desenvolvimento de s/w - Ad-hoc - Encaminhamento informativo de documentos - Aprovaes de pedidos ou requisies -
68
O Workflow geralmente classificado segundo quatro categorias: ad-hoc, colaborao, administrativo e de produo. Estas categorias de processos tm em comum a sua importncia dentro da organizao, mas havendo grandes diferenas relacionadas com o nvel de rigidez e estrutura nas definies dos processos. Um Workflow de produo tem como finalidade o suporte de processos organizacionais pr-definidos, executando a sequncia de actividades de uma forma muito rgida e estruturada (Quadro 3.3). Por outro lado, um Workflow ad-hoc d maior importncia partilha de informao pelos utilizadores, do que ao prprio processo que normalmente no muito estruturado. Um Workflow administrativo tem a ver com processos burocrticos e repetitivos encontrados tipicamente nas organizaes. Finalmente, um Workflow de colaborao caracteriza-se pela dinmica e pela comunidade de participantes envolvidos no processo. Nestes casos, pode-se estabelecer vrias iteraces de uma mesma etapa at chegada a um consenso por parte do grupo envolvido, e s depois passar etapa seguinte. Os tipos de solues nesta rea so categorizados face ao tipo de processo e o valor acrescentado para a organizao, e tambm face ao relacionamento da complexidade das tarefas com as suas estruturas (Figura 3.24). A tecnologia de Workflow faz parte integrante do Business Process Management (BPM) que engloba de forma mais abrangente a classe de tecnologia ou aplicaes para a automatizao de processos organizacionais. As aplicaes especficas de Workflow tm como principal objectivo o encaminhamento e a
Alto Produo
Complexo Produo
Valor na organizao
Colaborao
Complexidade da tarefa
Colaborao
Ad Hoc Administrativo
69
distribuio de informao e tarefas que envolvem frequentemente pessoas. Para alm deste objectivo as solues de BPM gerem efectivamente, a um nvel superior, o processo organizacional como um todo aplicando-lhe regras de negcio, integrando outras aplicaes e obtendo as respectivas mtricas globais de gesto. O BPM tem cada vez maior importncia devido convergncia de diferentes factores. A crescente necessidade da integrao funcional das organizaes, a maior abrangncia da automatizao de processos organizacionais e a procura de uma melhor agilidade organizacional esto na origem da procura de solues de BPM.
As solues BPM, tambm denominadas de POM (Process Oriented Middleware), permitem coordenar numa lgica processual vrios tipos de aplicaes de forma a automatizar um processo (Figura 3.25). A coordenao e sincronizao de diferentes processos de Workflow poder por exemplo automatizar um processo organizacional de forma completa, quer dentro das organizaes ou entre estas. As solues BPM caracterizam-se por terem vrias funcionalidades complementares e que abragem toda a organizao a nvel tecnolgico e de gesto. Pode-se identificar os seguintes grupos de funcionalidades complementares:
70
1. Gesto de processos end-to-end 2. Modelao e documentao dos processos 3. Integrao automtica ou manual de processos 4. Portabilidade e acessibilidade aos processos 5. Capacidade de crescimento e abrangncia da organizao 6. Ferramentas de anlise e monitorizao
As solues BPM permitem criar arquitecturas funcionais para a integrao de sistemas, e so modeladas de acordo com as regras de funcionamento da organizao.
Figura 3.26: Enquadramento das normas BPMN, BPML, BPEL e web services ( adaptado de BPMI.org)
Na rea do BPM existem diferentes organismos que especificam e defendem vrias normas de mercado (Figura 3.26). Algumas dessas normas complementam-se e permitem criar novas normas mais abragentes. A evoluo destas especificaes tem seguido caminhos de convergncia que procuram tirar partido da tecnologia dos web services criando uma zona nublosa mas complementar com o BPM.
71
Ao longo dos tempos surgiram vrias normas (Figura 3.27) com diferentes propsitos. O WfMC especificou o WPDL (Workflow Process Definition Language) e o XPDL (XML Process Definition Language) para a definio de processos de workflow. O OMG definiu uma extenso ao UML (Unified Modeling Language) para a modelao de processos de workflow e a proposta BOM/99-10-03 para a definio de processos. O NIST/MIT (National Institute for Standards and Technologies/MIT) definiu o PSL (Process Specification Language) e o PIF (Process Interchange Format). O BPMI.org (Business Process Management Initiative) prope entre outros o BPML (Business Process Modeling Language), o BPMN (Business Process Modeling Notation) e o BPQL (Business Process Query Language). Na iniciativa ebXML.org (Electronic Business XML) sugre o BPSS (Business Process Schedule Specification) e a OASIS por seu lado definiu o BTP (Business Transaction Protocol). Em colaborao com a HP o W3C surge com o WSCL (Web Services Conversation Language), em colaborao com a SUN, a BEA e a Intalio definiram o WSCI (Web Services Choreography Interface) e mais tarde especifica a norma WS-Choreography.
Figura 3.27: Cronologia das normas de orquestrao de web services (fonte Oracle)
A IBM tambm participa nesta rea com o WSFL (Web Services Flow Language) e a Microsoft na mesma rea com o XLANG que baseado no WSDL dos web services. A IBM e a Microsoft juntaram esforos para fundir estas especificaes numa mais recente chamada BPEL4WS 1.0 (Business Process Execution Language for Web Services) ou simplesmente BPEL. Esta convergncia incorporou as especificaes WS-Coordination, WS-Transaction e WS-Security em resposta especificao BPML mais abragente. A agncia DARPA (Defense Advanced Research Projects Agency) definiu o DAML-S (DARPA Agent Markup Language - Services) para a automao de web services.
72
Assistindo a uma convergncia nesta rea, o WfMC e o BPMI.org relacionaram conceptualmente as normas dividindo em reas de definio e execuo internas e externas dos processos incluindo o B2B (Figura 3.28). Centrado o enquadramento nas funcionalidades especficas da definio e execuo de processos, as reas mais relevantes relacionam-se com a definio de processos, a coreografia que permite integrar os web services, a execuo/interaco dos processos e os prprios web services:
Definio de processos o XPDL, BPML e BPEL Coreografia de processos o WSCI e BPEL Execuo/Interaco o Wf-XML e BPEL Web Services o SOAP, WDSL e UDDI
73
Para alm de ser uma das normas mais recentes, e baseada numa especificao da OASIS, o BPEL (Figura 3.29) suportado pela IBM, Microsoft , Oracle, BEA, SAP e Siebel cujas solues e clientes correspondem praticamente totalidade do mercado nesta rea. Esta realidade levou a Oracle Corporation a comprar a empresa Collaxa, que estava a liderar o mercado nesta rea, integrando a sua tecnologia. Esta norma baseada no XML e nos web services permite definir a orquestrao dos servios dentro de uma lgica processual e permite a integrao ponto a ponto de sistemas ou aplicaes. So identificadas as etapas de um processo, a sua interaco com outros sistemas e toda a lgica da sua execuo (Figura 3.30). Esta especificao requer um sistema que permita executar os processos definidos por esta via.
Numa lgica de continuidade a BEA e IBM juntaram esforos e definiram o BPELJ (BPEL for Java). O BPML e o BPEL partilham as mesmas bases quanto aos web services (SOAP, WSDL e UDDI), quanto ao XML (Xpath e XSDL) e s
74
especificaes WS-Security e WS-Transactions. No entanto o BPMI.org considera o BPEL como um subconjunto do BPML [BPMI 2002] devido ao facto deste contemplar no s a rea da execuo dos processos mas tambm a sua prpria definio.
Com o objectivo de optimizar a sua dinmica, as organizaes procuram solues integradoras que permitam automatizar os seus processos reduzir custos operacionais e agilizar os seus procedimentos. As solues informticas tpicas de workflow e de gesto documental so os predecessores das solues de BPM que abragem tanto as interaes humanas como as integraes com aplicaes. Esta abordagem permite identificar e documentar os processos, automatiz-los e executlos integrando-se com os sistemas existentes sem ter de alter-los. Estas solues so por vezes menos dispendiosas do que as abordagens orientadas informao ou s aplicaes que obrigam a outro tipo de implementao. As normas XML, Web Services e BPEL vieram dar um grande contributo para o sucesso deste tipo de perspectiva da integrao de SI.
3.4
Web
Services
arquitectura
Service
Oriented
Arquitecture
A evoluo da tecnologia possibilitou s organizaes ver os seus sistemas como componentes com os quais se podem interagir e integrar num processo organizado. por exemplo possvel criar sistemas que permitem iniciar um processo estruturado de uma encomenda numa organizao, validar a transaco noutra organizao, planear a entrega dos bens com outra organizao e ter um suporte psvenda interno. Os Web Services (WS) representam um conjunto estruturado de definies para a integrao de diferentes tecnologias, desde o nvel dos sistemas operativos, at aos processos organizacionais. Os Web Services compatibilizam tecnologias e solues no integrveis partida pela sua natureza, utilizando formatos comuns de troca de informao com o XML e aplicando regras de interaco. assim possvel evitar tarefas de reconstruo de sistemas obtendo a sua reutilizao e respectiva integrao.
75
O XML a linguagem base que suporta as principais normas que estruturam os Web Services (Figura 3.31): SOAP - Simple Object Application Protocol WSDL - Web Service Description Language UDDI - Universal Definition Discovery Interface Os Web Services funcionam como uma camada de abstraco de sistemas que disponibilizam informao ou procedimentos para os outros sistemas que os invocam (Quadro 3.4).
Web Service Request/Response Comunicao sncrona do tipo RPC entre servios tightly-coupled. Comunicao assncrona do tipo ficheiro/documento/mensagem entre servios loosely-coupled. Norma WSDL SOAP e XML UDDI Registry
76
O Web Services Interoperobility Organization (WS-I) foi fundado em 2002 e tem como principal objectivo garantir a interoperabilidade entre as diferentes abordagens de arquitecturas assentes em Web Services. Esta organizao no especifica normas tcnicas nesta rea mas coopera com outros organismos que o fazem como por exemplo a Organization for the Advancement of Structured Information Standards (OASIS), o World Wide Web Consortium (W3C) e a Internet Engineering Task Force (IETF). O WS-I publicou um conjunto de linhas orientadoras num documento denominado the WS-I Basic Profile. Esta publicao centra-se na orientao e recomendao acerca da estrutura das especificaes globais dos Web Services (SOAP, WSDL, UDDI, XML e XML Schema) que devem ser definidas e agrupadas para garantir interoperabilidade entre os Web Services e as diferentes tecnologias que os suportam (Figura 3.32).
Para poder tirar partido de vrios Web Services de forma combinada, foram definidas trs normas para a sua gesto composta, criando uma plataforma denominada por Web Services Composite Application Framework (WS-CAF):
Web Service Context (WS-CTX) Web Services Coordination Framework (WS-CF) Web Services Transaction Management (WS-TXM)
O WS-CTX disponibiliza um mecanismo para gerir informao comum aos diferentes servios envolvidos e que deve ser encaminhada atravs de diversas
77
operaes. Esta funcionalidade identifica um determinado contexto que permite correlacionar as diferentes mensagens XML que circulam entre os sistemas. O WSCF faz a gesto do contexto referido e garante que as mensagens circulam de forma correcta e chegam aos diferentes pontos de destino. Por fim, o WS-TXM gere a gesto de transaces e a sua interaco com os respectivos sistemas transaccionais.
Uma integrao assente em web services denomina-se por Service Oriented Integration (SOI) e neste mbito possvel definir uma arquitectura orientada aos servios Service Oriented Architecture (SOA) [Newcomer e Lomow 2004]. No se trata de um conceito novo mas pode-se considerar que o SOA uma evoluo da arquitectura 3-tier (Figura 3.33) com a incorporao de servios que disponibilizam e integram as aplicaes de acordo com as suas especificaes (Figura 3.34).
A arquitectura Service Oriented Arquitecture (SOA) permite s organizaes disponibilizar as suas aplicaes e solues de software como servios bem definidos, permitindo a sua reutilizao e integrando-os em solues mais abrangentes e flexveis para o desempenho do negcio. Uma arquitectura SOA disponibiliza um repositrio de servios que podem ou no ser integrados numa soluo aplicacional. Cada servio representa um encapsulamento de componentes aplicacionais que contm lgica aplicacional que segue as regras do negcio. Ainda no mbito dos
78
modelos aplicacionais, que vo desde o tight coupling at ao loose coupling, a arquitectura SOA composta por camadas complementares (Figura 3.35).
Neste contexto surge o conceito de Enterprise Service Bus (ESB) baseado numa arquitectura que herda caractersticas dos Message Brokers e do SOA e que funciona como uma plataforma empresarial para implementar interfaces de comunicao baseadas em normas.
O ESB representa uma espinha dorsal de servios, mensagens, comunicaes, transformaes e de segurana sobre a qual se pode acoplar aplicaes ou simplesmente interagir com elas. Esta abordagem tira partido da grande maioria das normas e solues tcnicas referidas nos pontos anterirores, em particular do conceito de Messaging, dos Web Services e protocolos de comunicao. Os ESB seguem os princpios de um arquitetcura orientada aos servios (SOA), permitindo a integrao com diferentes tipos de servios, e incluem de forma geral as seguintes reas funcionais (Figura 3.36):
Standard-based Communication Infrastructure Standard-based Connectivity Standard-based Transformation Engines Service Oriented Architecture (SOA) for application deployment Standards-based Security
79
A camada de comunicao baseada num canal centralizado, gere a troca de mensagens garantindo o seu encaminhamento, aplicao de regras e condies, mapeamento e transformao de dados. Estas mensagens so normalmente estruturadas em XML o que permite tirar partido de funcionalidades assentes em XSLT e XPATH. A camada de conexo pode basear-se em diferentes normas como por exemplo o SOAP/HTTP para os Web Services, Java Connector Architecture (JCA) para adaptadores aplicacionais, Java Message Service (JMS) para troca de mensagens com uma plataforma J2EE.
Como nas restantes perspectivas para a integrao de SI, as normas existentes so muito importantes para determinar a portabilidade e adaptabilidade das solues encontradas. Neste mbito, a recente norma BPEL tira partido dos Web Services e do XML e claramente uma soluo completa e prtica para qualquer situao ao nvel da complexidade dos sistemas. Esta norma permite um nvel de abstraco muito grande e facilita a integrao de SI em qualquer das suas perspectivas, camadas tecnolgicas ou arquitecturas. As recentes normas tcnicas permitem novas formas de integrao nomeadamente aquelas que esto presentes nos conceitos de SOA e ESB.
80
Por seu turno, os Web Services (WS) oferecem uma arquitectura independente e baseada em normas de mercado regulamentadas e documentadas como so o XML, o WSDL, o UDDI e o SOAP. Numa organizao, a adopo de WS permite, por um lado, disponibilizar funcionalidades dos sistemas internos de forma a poder integrlos, e por outro lado, d a possibilidade de disponibilizar ou mesmo comercializar esses servios fora da organizao. Enquanto que nas abordagens tradicionais, os pontos de integrao esto previamente identificados e coordenados, os WS podem ser escolhidos no momento e consoante a sua funcionalidade ou disponibilidade. Finalmente, a tendncia do mercado tecnolgico nesta rea aponta claramente para a adopo e explorao destas normas recentes devido s vantagens que oferecem. As desvantagens dos WS esto relacionadas com alguma imaturidade ainda existente e algumas lacunas funcionais. Os WS obrigam por exemplo a adoptar tecnologia que os possa orquestrar segundo uma determinada lgica. Aqui surgiu por exemplo a norma BPEL que resulta de uma convergncia de especificaes e vontades de alguns fornecedores de software.
81
Neste sentido, nenhuma das abordagens substituiu a outra e cada caso um caso. Em cada situao, as organizaes devero forosamente analisar o impacto de cada soluo face s suas necessidades de integrao. No entanto, ambas as abordagens so viveis e necessrias para obter uma soluo de integrao de SI completa e abragente. Apesar da sua independncia, cada uma pode complementar a outra, e em conjunto, podem fornecer excelentes solues nesta rea.
No mbito de uma organizao, pode-se identificar conceptualmente a integrao de Sistemas de Informao com trs perspectivas complementares: integrao de informao, integrao de aplicaes e integrao de processos (Figura 3.37). Entre cada rea existem protocolos de comunicao, trocas de informao, funcionalidades e partilha de cdigo. As reas comuns distinguem-se pelas possveis 82
abordagens e tecnologias de base (Quadro 3.5) o que significa que algumas das camadas conceptuais e/ou tecnolgicas possam tambm podem a estar presentes.
Camada comum
1
Descrio
Troca de informao com o objectivo de interligar processos organizacionais dando origem sua execuo.
Implementao de lgica aplicacional dentro de uma aplicao para automatizao e controlo do fluxo de processo, etapas, estados.
Funcionalidades aplicacionais que entram no mbito da informao como a integrao de SQL em lnguagens de programao (ex: Oracle PL/SQL), controlo aplicacional da integridade da informao e as respectivas transaces.
Nesta camada pode haver lgica aplicacional implementada ainda na rea da Informao como por exemplo os stored procedures dos SGBD.
As camadas representadas so complementares e correspondem s perspectivas da integrao dentro de uma organizao. A integrao entre duas ou mais organizaes (Figura 3.38) pode dar-se ao nvel de qualquer uma das camadas aqui descritas, onde se procura integrar informao, aplicaes e processos. Com os Web Services possvel integrar cada uma das perspectivas entre elas, ou ento disponibilizar funcionalidades de cada perspectiva para uma integrao com outra organizao. Estas possibilidades correspondem s caractersticas de uma arquitectura do tipo SOA.
83
Pode-se ainda relacionar cada perspectiva pelo nvel de integrao desejado numa organizao que vai desde o nvel 0 onde no h integrao de sistemas at ao nvel 4 que corresponde ao nvel de integrao entre organizaes (Quadro 3.6). Cada perspectiva complementa a anterior e tem a seguinte descrio [Schmidt 2000]:
Nvel 0 (Inexistente): Existncia de sistemas de informao sem qualquer tipo de integrao ou interligao. Nvel 1 (Ponto a ponto): Primeiro nvel de integrao com sincronizao de repositrios e ligao ponto a ponto de sistemas. Sistemas tight-coupled. Nvel 2 (Estrutural): Sistemas loosely-coupled. Nvel de integrao completo em termos de aplicaes e repositrios de informao. Toda a estrutura de aplicaes est integrada. Introduo de Middleware.
Nvel 3 (Processual): Introduo de sistemas de automatizao de processos especficos para complementar os sistemas integrados existentes. Introduo de informao de gesto e indicadores acerca do comportamento da organizao.
Nvel 4 (Externo): Estando todos os sistemas internos perfeitamente integrados a todos os nveis, h aqui a introduo do relacionamento externo com outras organizaes e os seus sistemas no lgica de Business-to-Business.
84
Nvel
Caractersticas
Perspectiva
0 - Inexistente
Insero de dados e sincronizao de repositrios de informao manual. Aplicaes isoladas e monolticas. Processos manuais, em papel ou isolados dentro de uma aplicao. Organizao isolada.
1 - Ponto a ponto
Ferramentas de sincronizao de repositrios de informao (Replicao) e sistemas tight-coupled. Integrao ponto a ponto com API/RPC/ORB ou Messaging.
IA II
Inclui nvel Ponto a Ponto. Interfaces de comunicao com Message Hub / Bus. Sistemas loosely-coupled Middleware com: Message Brokers. Application Servers. Data transformation Rule processing Transaction Integrity
2 - Estrutural
IA II
3 - Processual
Informao gerida e partilhada numa lgica de processo. Funcionalidades: Automated Routing, Automated Decision e Workflow
IP IA II
Inclui nvel processual. Infraestrutura de rede e comunicao comuns (ex: Internet). Normalizao da informao comum e em XML. Integrao de Processos entre organizaes. Sistemas aplicacionais comuns. Middleware com: Secure Transaction Data Mapping
Quadro 3.6: Nvel de integrao de SI versus Perspectivas (adaptado de [Schmidt 2000])
4 Externo
IO
O nvel 2 pode por vezes representar o nvel 3 caso os sistemas aplicacionais englobem lgica aplicacional que permita automatizar os processos da organizao. 85
O XML uma norma que pode ser utilizada pela grande maioria das tecnologias ou plataformas existentes. As normas que suportam os Web Services baseiam-se no XML nas suas diversas funcionalidades. A arquitectura SOA baseia-se tambm nos Web Services e no XML mas podem ser usadas outras normas equivalentes com os mesmos objectivos de integrao (Quadro 3.7).
Java RMI Invocao de procedimentos ou servios Formato da informao Transporte Da informao Protocolo de comunicao Java Remote Method Protocol Serialized Java Stream Java RMI
CORBA CORBA
DCE RPC
Network Data Representation Protocol Data Units RPC ConnectionOriented Protocol (ex:TCP)
XML
SOAP
HTTP, SMTP
Java Interface
CORBA IDL
DCE IDL
WSDL
Java Registry
Corba Object
Cell Directory
UDDI
No mercado tecnolgico fcil encontrar definies diferentes para uma mesma sigla ou tecnologia. Por causa de questes de concorrncia no mercado das TI difcil encontrar descries estanques da cada abordagem, perspectiva ou tecnologia de integrao de SI. Mas em termos conceptuais, e de forma genrica, pode-se relacionar algumas das normas e tecnologias mais comuns com as suas famlias tecnolgicas (Figura 3.39):
86
Object Request Borker (ORB): CORBA, COM/DCOM, RMI Distribute Computing Environment (DCE): RPC Transaction Processing (TP): TP Monitor, SGBD Messaging Oriented Middleware (MOM): Message Queueing e Message Broker
Os Integration Brokers esto baseados essencialmente no Messaging mas podem incluir outras tecnologias para servir como Middleware completo para a integrao de SI. Pode conter por exemplo adaptadores para aplicaes e ferramentas de monitorizao.
Na mesma lgica, os Application Servers tambm incluem muitas das tecnologias aqui referidas e permitem diferentes abordagens de integrao de SI. Estes so comummente associados famlia dos monitores transaccionais, mas so hoje em dia muito mais do que isso.
Os Web Services posicionam-se como uma nova alternativa, embora baseados em conceitos tradicionais, para facilitar a integrao de sistemas baseada em XML. uma abordagem que tem tido uma grande aceitao no mercado obrigando os vrios fornecedores tecnolgicos a incorpor-la nos seus produtos. Com a possibilidade de disponibilizar qualquer informao ou sistema atravs dos Web Services no entanto necessrio dar-lhes alguma lgica e coordenao durante a sua integrao. Neste caso o BPEL a norma de referncia com esse mesmo intuito. 87
quase impossvel enumerar todas as normas ou tecnologias para cada situao especfica que requer desenvolvimento aplicacional ou integrao. A evoluo das TI de tal modo rpida que qualquer enquadramento feito neste sentido poderia ficar obsoleto. Mas as normas ou tecnologias mais comuns ilustradas neste trabalho podem ter aplicabilidade, ou no, consoante a perspectiva adoptada (Figura 3.40). Algumas normas so totalmente abrangentes como o caso do XML, dos Web Services ou do Messaging e outras sero mais contectualizadas.
88
A integrao da informao numa organizao ocorre essencialmente ao nvel do seu armazenamento e do seu transporte de uma fonte para outra. Neste captulo, 89
destaca-se o XML como a norma mais abragente para todo o tipo de manuseamento e integrao de informao em diversas solues tecnolgicas. Esta norma enquadra-se tambm nas outras perspectivas mas est associada na sua essncia gesto da informao. A integrao aplicacional segue essencialmente tcnicas orientadas aos mtodos ou funes programticas. Existem diversas formas de integrao directa, atravs de invocaes de cdigo, que permitem colocar componentes ou objectos a interagir atravs de canais de comunicao. Estas interaces so na maioria dos casos sncronas e baseadas no tipo request/reply entre as aplicaes envolvidas. Estas abordagens de integrao podem assentar, entre outros, em cdigo aplicacional (COBOL, C++, Java, etc..), nos API (Application Programming Interface), nos RPC (Remote Procedure Call), nos TP Monitors (Transaction Processing Monitors), nos objectos distribudos, nos componentes do tipo CORBA (Common Object Request Broker Architecture), nos Java RMI (Java Remote Method Invocation), nos MOM (Message Oriented Middleware) e nos Web Services. So aqui destacadas as seguintes normas e tcnicas: RPC, TP, ORB, COM e Messaging.
Quanto integrao entre organizaes so realadas as normas EDI e ebXML. A primeira abordagem para este tipo de integrao foi a soluo Electronic Data InterChange (EDI) sendo ainda hoje uma norma bastante utilizada. Na tentativa de tirar partido do XML surgiu o ebXML que permite estruturar nessa base as trocas de informao entre organizaes.
A integrao orientada aos processos pode seguir vrios caminhos consoante as normas adoptadas. Esta uma rea complexa onde surgem vrias especificaes resultantes de diferentes correntes no mercado tecnolgico. Neste sentido, existem diversas normas, como por exemplo o BPMN, o WSFL ou o XPDL, que seguem diferentes raciocnios e que documentam os processos de formas diferentes. Nesta rea tem-se verificado uma convergncia de especificaes que, ao longo dos tempos, se vo fundindo para criar novas normas mais abrangentes. Por essa razo, e pelo facto de tambm tirar partido do XML, d-se destaque norma BPEL para a integrao de processos. Esta norma tem sido consensual e tem aproximado os fornecedores de tecnologia o que tambm revela a sua importncia.
90
No que diz respeito integrao orientada aos servios so aqui includas as normas respeitante aos Web Sevices: SOAP, UDDI e WSDL. Os Web Services so a evoluo de muitas das outras tcnicas aqui enumeradas que sugiram com a proliferao da Internet e das suas normas de comunicao e invocao de informao e aplicaes.
91
semalhana do HyperText Markup Language (HTML) o XML permite a definio de tags ou delimitadores, que caractarizam os dados e a sua formatao, mas de forma ilimitada. possvel criar um conjunto de tags ou marcas especficas para obter uma formatao para um determinado conjunto de informao. Cada elemento, ou conjuntos de elementos, est relacionado e estruturado numa lgica de rvore ou hierarquia com dependncias e ramificaes. Uma folha da rvore ser um elemento que pode conter dados como o ttulo de um livro, o cdigo de um produto ou qualquer outro tipo de dado. Com o XML pode-se criar uma camada estruturante para um documento de texto, um registo de base de dados estruturado, um objecto com mtodos e dados como so os objectos Java, um registo de dados resultantes de uma pesquisa, a apresentao grfica de uma aplicao, etc...
O XML permite tambm separar a camada de apresentao dos dados da sua estrutura. Enquanto que o HTML especifica como o documento deve ser apresentado num web browser, o XML define o contedo desse documento. No HTML existem por exemplo tags para definir o tamanho e a cor da letra, as tags de XML descrevem os dados identificando que aquele elemento um ttulo, um autor, uma data, uma morada, uma referncia, etc... Uma estrutura XML pode tambm ser usado para troca de informao permitindo a integrao dos dados com diferentes origens e estruturaes (Figura 4.3). assim possvel obter dados de diferentes sistemas, convert-los intervenientes. numa estrutura XML e distribu-los directamente s partes
92
Os elementos XML so formados por tags de abertura <elemento>, sendo o mesmo para tags de fecho </elemento>. Por exemplo a definio do elemento marca de automvel pode ser representada da seguinte forma: </marca>Alfa
Romeo</marca>. Um documento XML estrutura-se com pelo menos trs partes: uma declarao, o Document Type Declaration (DTD) e a instncia. A declarao funciona como um cabealho descritivo que indica a verso de XML usada, o grupo de caracteres possveis ou outras caractersiticas. Um DTD caracteriza-se por um conjunto de declaraes que especifica o tipo de estrutura do documento em XML (Figura 4.4). A instncia o documento propriamente dito contendo a informao e as anotaes. Na prpria instncia poder fazer-se referncia ao DTD caso no esteja presente directamente no documento XML. Tambm existe a abordagem XML Schema Definition (XSD) que se posiciona como uma alternativa mais completa e flexvel do que o DTD. O XSD foi proposto inicialmente pela Microsoft e passou a ser uma recomendao oficial do W3C em 2001.
O XML pode ainda ser complementado com folhas de estilo do tipo Extensible Style Language (XSL) para controlar a apresentao dos dados (Figura 4.5). O XML permite estruturar e representar informao de uma forma simples e independemente da sua origem ou do seu destino. Um documento que contem informao formatada pelo XML pode no ser suficientemente flexvel para ser manipulado sobretudo quando no se conhece partida a sua estruturao. Para facilitar essa interpretao e visualizao do contedo em XML surge outra norma do W3C: o eXtensible Stylesheet Language (XSL). O XSL permitir substituir as tags de
93
estruturao da informao por marcas de formatao ou transformao semelhante ao que acontece com o HTML.
Na sua primeira abordagem, o W3C definiu o XSL com ambas as partes de formatao e de transformao do XML. Mais tarde decidiu separar criando o XML Path Language (Xpath), o XSL Transformations (XSLT) e o XSL Formatting Objects (XSLFO). Pode-se considerar o XSLFO como sendo igual ao XSL. uma liguagem de markup que descreve a formatao da apresentao de um documento XML e deixando a componente de transformao para o XSLT. O Xpath permite localizar informao dentro de um documento XML. Trata-se de uma linguagem que permite identificar partes do documento XML para poder interagir com elas. Por exemplo 94
possvel ter expresses de localizao do tipo Xpath dentro de um XSL. O XSLT permite a transformao de um documento XML noutros formatos ou estruturas. O XSLT caracteriza-se como uma metodologia com regras de transformao de uma estrutura para outra. Esta abordagem por exemplo utilizada para transformar documentos XML em documentos formatados para uma determinada apresentao, podendo ser complementado com o Xpath e permitir o controlo de troca de informao entre sistemas. O XML Document Object Model (XML DOM) consiste uma interface de programao para documentos em XML. O XML DOM define uma forma de aceder e manipular documentos XML para poder navegar pela sua estrutura modificar os valores dos seus elementos. Pelo facto de no haver restries de nomeao dos elementos de um documento XML podero ocorrer conflitos de estruturao entre este tipo de documentos. No XML possvel usar o XML
namespaces para controlar eventuais conflitos de descrio dos elementos. Os namespaces permitem resolver conflitos entre dois documentos XML no seu elemento <table> com dois namespaces (http://www.w3.org/TR/html4/ e
95
Uma transaco composta por um conjunto de operaes atmicas e s tem sucesso caso todas as operaes sejam executadas. Este conceito aplicado em muitas tecnologias como por exemplo as bases de dados transaccionais ou em motores de
96
workflow. Um monitor transaccional fornece um conjunto de funes como por exemplo a gesto de transaces falhadas, o balanceamento de carga, a consistncia e distruio de informao e nveis de segurana na execuo das transaces.
Esta tecnologia permite a integrao da aplicaes quer no acesso s bases de dados quer na gesto de interaces entre aplicaes. possvel tratar uma aplicao como um sistema ou um componente para ser chamado por uma transaco. Uma aplicao pode comunicar com outras aplicaes atravs destas transaces que tm a sua integridade garantida. Os monitores transaccionais permitem suportar sistemas distribudos e integrar diferentes componentes entre si. So suportadas vrios modelos de comunicao entre aplicaes como o store and forward, os RPC e outras formas assncronas.
Os monitores transacciomais possibilitam a criao de grandes sistemas de informao integrados e suportados por diferentes mdulos aplicacionais interligados por estas transaces. Esta tecnologia garante a execuo destas transaces de forma fivel, eficiente e com capacidade reposta.
97
Numa aplicao do tipo cliente/servidor o acesso ao programa remoto feito por chamadas sncronas do tipo RPC que so embutidas no programa cliente (Figura 4.8). Por ser um tipo de codificao trabalhoso e de difcil gesto surgiram formas automticas de gerao de cdigo para suportar o RPC. Essa gerao automtica feita com base numa linguagem de especificao da interface dos procedimentos remotos designada por IDL (Interface Definition Language) [Open 1997] e independente das liguagens de programao. Este tipo de abordagem facilita aos programadores a incorporao destes procedimentos quer do lado do cliente quer do lado do servidor. O RPC corresponde a uma das camadas da arquitectura DCE (Distributed Computing Environment) definida pelo Open Group (Figura 4.9).
O CORBA e o DCOM so duas metodologias orientadas aos objectos para a comunicao entre objectos que fornecem os mesmo tipo de funcionalidades que o RPC.
desenvolvida pela Microsoft, descreve uma plataforma para a integrao de componentes de software que suporta a sua interoperabilidade e a reutilizao. possvel construir aplicaes flexveis com a assemblagem de componentes de diferentes origens que comunicam atravs do COM (Figura 4.10). Os ambientes em Java tem especificaes semelhantes que se enquadram nos componentes JavaBeans.
A definio de um componente pode ter vrias alternativas mas de uma forma genrica pode-se definir este tipo de objecto como: Um pequeno objecto binrio ou programa que desempenha uma funo especfica e concebido de forma a comunicar e integrar com outros componentes e aplicaes 3.
Para introduzir mecanismos de comunicao remota nos prprios objectos, surge DCOM (Distributed COM) [Horstman e Kirtland 1997]. Trata-se de uma extenso do COM que permite a interaco entre componentes assentes em protocolos de comunicao em rede. Enquanto que os processos de integro COM so executados na mesma mquina em diferentes endereos, a extenso DCOM permite que a integrao de componentes sejam feita atravs das redes de comunicao e de protocolos como o HTTP. O DCOM foi criado como resposta especificao CORBA (Common Object Request Broker Architecture) do consrcio OMG (Object Management Group).
Tanto o COM como o DCOM representam uma abordagem muito especfica e baixo nvel em termos de codificao e integrao de componentes de software. As tecnologias OLE (Object Linking and Embedding), ActiveX e MTS (Microsoft transaction Server) da Microsoft esto assentes em COM e DCOM que esto dependentes do sistema operativo Windows. Estes representam um nvel superior de disponibilizao de servios aplicacionais em termos de integrao, portabilidade e
3
http://www.webopedia.com/TERM/c/component.html
99
segurana. O applet o componente em Java equivalente ao Activex da Microsoft que permitem executar pequenas aplicaes descarregadas para os web browsers a partir de servidores web remotos. O COM+ uma evoluo da especificao COM, que tira partido das funcionalidades transaccionais e messaging do MTS, para a sua utilizao e integrao em aplicaes. O COM+ tem como equivalncia no mundo Java os EJB (Enterprise Java Beans) que entretanto evoluiu para a plataforma J2EE mais abragente.
Como se pode concluir do mercado de fornecedores de software, existem duas correntes alternativas suportadas, por um lado, pela Microsoft, e por outro, por um conjunto alargado de outras empresas. Neste caso identifica-se a plataforma .NET da Microsoft e o J2EE defendido pela SUN, Oracle, IBM, Sybase e BEA.
Um ORB actua de forma a fornecer um directrio de servios disponibilizados por componentes e possibilita as ligaes com esses servios. Um ORB funciona
100
como um canal de comunicao que controla as interaces entre componentes e sistemas de forma a: Definir as interfaces de comunicao. Localizao e activao de objectos remotos. Comunicao entre clientes e os objectos.
Existem dois grandes grupos de tecnologias que permitem uma abordagem do tipo ORB: O CORBA (Common Object Request Broker Architecture) Microsoft COM (Component Object Model)
Em 1994 a OMG definiu o CORBA verso 2.0 que incluiu uma especificao mais clara do canal de comunicao ORB denominado de IIOP (Internet Inter-Orb Protocol). O IIOP baseado nos protocolos da Internet, nomeadamente na norma TCP/IP, e permite estruturar a forma como a informao circula entre os objectos. Pode-se identificar um modelo ORB mais recente com a tecnologia Java denominado de RMI (Remote Method Invocation) que permite a execuo remota de mtodos de objectos Java [Wollrath e Waldo 2005]. O Java RMI mais simples que o COM/DCOM ou o CORBA mas depende do Java. Por seu lado o COM/DCOM depende do Windows e o CORBA no to flexvel quanto os restantes apesar de estar implementado em vrias liguagens. O CORBA comeou a cair em desuso sobretudo pelo facto das comunicaes serem sncronas e pelas surgimento dos web services e da norma SOAP.
101
O MOM permite um elevado nvel de flexibilidade e independncia para a troca de mensagens entre aplicaes e sua consequente integrao. Este tipo de arquitectura indicada para aplicaes que necessitam de uma integrao orientada aos eventos. Na ocorrncia de um conjunto de situaes ou condies despoletado um evento que envia uma mensagem para o software de gesto de mensagens e do qual pode ou no esperar uma resposta. Esse software, normalmente conotado como middleware, est encarregue de gerir uma fila de mesagens (message queue) e de entregar cada uma delas ao seu destino.
A integrao entre duas aplicaes pode seguir esta filosofia onde surgem vrias alternativas com ligaes ponto a ponto, publish/subscribe ou por um canal de comunicao. Estas solues so normalmente designadas por message broker no caso de gerir as mensagens assincronamente. Os mecanismos de comunicao sncronos ou assncronos podem ter vantagens e desvantagens consoante as situaes e devem ser contempladas na configurao do software. No primeiro caso as mensagens so enviadas para o destino do qual esperada uma resposta para o sistema emissor. No segundo caso o sistema emissor e o sistema receptor no precisam de estar simultaneamente ligados ao canal de comunicao. As mensagens so colocadas em fila at que o sistema destino as receba sem ter de enviar uma resposta em troca. Neste mbito pode-se identificar pelo menos trs topologias [Hohpe et al. 2003] de comunicao:
1. Peer to peer ou Point to point 2. Hub and Spoke 3. Bus ou Pipeline ou Publish and Subscribe
102
A comunicao point to point (Figura 4.13) permite criar canais de comunicao especficos para cada ponto de integrao entre mdulos aplicacionais. A circulao da informao segue caminhos fixos com pontos de partida e de chegada previamente conhecidos. Esta no a situao mais desejvel devido sua pouca flexibilidade surgindo nos casos das solues proprietrias que no seguem normas de mercado.
A comunicao hub and spoke (Figura 4.14) permite centralizar o canal de comunicao que funciona como uma ponte comum (hub) para troca de informao. Este tipo de soluo incorpora funcionalidades de comunicao hub and spoke na sua camada de middleware e normalmente utilizada na rea de EAI. A camada de middleware funciona com gestor de mensagens do tipo Message Broker quer recebe as mensagens dos sistemas (spokes), determina os seus diversos destinos e encaminha as mensagens para os canais de destino.
103
A comunicao do tipo bus (Figura 4.15) permite difundir eventos na forma de mensagens para um ou mais destinos que os reconhecem subscrevendo a sua recepo. Os sistemas catalogam cada mensagem, identificando-a segundo um determinado tpico (publish), submetendo-as numa uma fila de mensagens (bus) em vez de envi-la para destinos especficos. O canal de comunicao envia a mensagem para todos os sistemas que pediram para receber as mensagens com essa identificao (subscribe). Trata-se de uma forma assncrona de troca de mensagens controlada por uma canal especfico de comunicao.
Ao contrrio dos RPC sncronos as solues MOM podem acumular mensagens assincronamente e, por alguma razo, no conseguir entreg-las ao seu destino. No entanto as filas de espera do MOM permitem usar o sincronismo para a entrega da informao e voltar para um estado de assincronismo caso alguns dos destinos no estejam a funcionar. As solues MOM tem interfaces aplicacionais para ser integrados em solues aplicacionais. Por exemplo, o Java Message Service (JMS) uma API em Java que faz parte da arquitectura J2EE e que permite o acesso s funcionalidades de um software do tipo MOM.
Os message brokers funcionam como uma ponte integradora entre aplicaes permitindo a circulao e troca assncrona de mensagens. Para alm da circulao e do encaminhamento das mensagens, os message brokers podem ler o contudo delas, descodific-las, interpret-las, modific-las e voltar a codific-las para depois serem entregues no destino. Trata-se de um conjunto complementar de funcionalidades como so:
104
Adaptadores ou gateways Metadata directory Message queue Audit trail database Routing service Transformation and mapping services
O XML (eXtended Markup Language) uma das linguagens mais comuns na estruturao deste tipo de mensagens. Os message brokers comerciais disponibilizam o conjunto de adaptadores j preparados para integrar com diversos tipos de sistemas e aplicaes como so o SAP, o Oracle E-Business Suite ou a PeopleSoft entre outros.
4.3.1 EDI
O EDI (Electronic Data Interchange) consiste na troca de documentos de negcio normalizados entre aplicaes e as respectivas organizaes (Figura 4.16). Documentos como notas de encomenda ou facturas so transmitidos de um sistema para outro de forma electrnica. Para isso as organizaes estabelecem um acordo para a transmisso e formato desses documentos.
105
As normas EDI especificam as regras de sintaxe dos documentos, da organizao dos dados dentro de um documento e da regras de comunicao e troca de informao. O objectivo das normas EDI a especificao deste tipo de documentos e dos protocolos de transmisso entre as organizaes. Uma mensagem EDI normalizada tem o nome de transaction set no caso do ASC X12 ou de message no caso do UN/EDIFACT (Quadro 4.1).
Uma mensagem EDI tem um cabealho (HEADER) que identifica o documento com informao como por exemplo a data do documento, o nome da empresa e a morada. O corpo do documento (DETAIL) inclui toda a informao relativa ao documento como quantidades de produto, descries e preos. No final existe um sumrio (SUMMARY) que contem informao de controlo e referente ao conjunto de linhas do documento. Cada linha designada por segment que contem elementos chamados data element.
4.3.2 ebXML
O ebXML uma norma para estruturar as trocas de informao entre organizaes. Esta norma suportada pela UN/CEFACT (United Nations Center For Trade Facilitation And Electronic Business) e a OASIS (Organization for the Advancement of Structural Information Standards). Esta norma especifica uma plataforma informacional, para o negcio electrnico, que permite s organizaes
106
encontrarem-se umas s outras e negociarem electronicamente com suporte em mensagens estruturadas em XML. O ebXML permite automatizar as conexes electrnicas entre parceiros comerciais e gerir as suas interaces.
Quando uma empresa quer fazer negcio electrnico com outra empresa segundo a norma ebXML vai seguir 3 etapas:
1. Implementation Phase 2. Discovery of Partner Information and Negotiation Phase 3. Transaction Phase
Na primeira fase, vai haver uma consulta das especificaes ebXML para determinados processos de negcio. Aps essa consulta e o entendimento dos processos associados, a organizao vai implementar os processos escolhidos dentro da sua prpria organizao segundo a norma. Desta forma vai preparar os seus sistemas de informao para interagir com outras organizaes de acordo com os processos descritos no repositrio ebXML. Quando o sistema estiver pronto, a organizao vai disponibilizar e publicar o seu perfil para que outras organizaes interessadas possam tambm interagir electronicamente com ela. Para isso vai usar o Collaboration Protocol Profile (CPP) para publicar o seu perfil de negcio no repositrio ebXML.
Na segunda fase, ser feito um acordo entre as empresas que queiram colaborar segunda esta norma e para os processos que publicam segundo o CPP. Aps verficarem que os perfis e processos esto de acordo com os interesses de cada parte, ser elaborado um acordo de cooperao denominado por Collaborative Partner Agreement (CPA) que tem a mesma funo que um contrato de colaborao.
Na terceira e ltima fase, ser dado incio colaborao electrnica no sentido em que comeam a ser trocadas as mensagens XML estruturadas de acordo com a norma ebXML e os CPP/CPA. Toda a lgica de processos e interaco comercial desta forma automatizada e as organizaes colaboram electronicamente.
107
Para por em prtica esta colaborao e integrao de SI os Web Services podem ser aqui usadas com as normas WSDL, UDDI e SOAP sobre HTTP.
O Business Process Management Initiative (BPMI.org) e o Workflow Managment Coalition (WfMC) juntaram esforos na especificao de trs normas para a definio e execuo de processos de Workflow: Wf-XML, XPDL e BPML. O Wf-XML uma variante em XML do WfMC para uma interface de interoperabilidade entre motores de execuo de processos de Workflow. O XML Process Definition Language (XPDL) caracteriza um meta-modelo mnimo de definio portvel de processos de workflow com XML. O Business Process Modeling Language (BPML) uma meta-liguagem de modelao em XML para os processos organizacionais. Do lado das empresas, a IBM e Microsoft especificaram o BPEL (Business Process Execution Language for Web Services) que define uma liguagem para especificar a orquestrao de web services. O BPEL foi oficialmente submetido pela OASIS em Maro de 2003. Tendo em conta que o WfMC est a fazer esforos de convergncia entre o XPDL e o BPEL, e sendo o BPEL a norma a que est a prevalecer no mercado inclui-se aqui a sua descrio sumria.
O BPEL uma norma que permite compor e orquestrar diferentes servios especificando toda a informao em XML. possvel integrar servios sncronos e assncronos segundo uma lgica processual e colaborativa. O BPEL permite conceber e estruturar processos transaccionais que sero executados por sistemas que suportam a automatizao de processos definidos em BPEL. Esta norma tem um conjunto de camadas estruturantes como so:
Web Services e WSDL para definir componentes XML como modelo de dados em ambientes loose-coupling Trocas sncronas e assncronas de mensagens XML Coordenao do fluxo dos processos Gesto hierrquica de excepes
108
O BPEL baseia-se nas normas XML e Web Services suportando neste contexto as normas SOAP, WSDL, UDDI, WS-Reliable Messaging, WS-Addressing, WSCoordination e WS-Transaction. Com o BPEL possvel suportar a combinao de aplicaes e sistemas acessveis atravs dos Web Services de duas formas:
Orquestrao Coreografia
Os Web Services podem ser coordenados segundo uma orquestrao que corresponde a uma combinao gerida centralmente numa lgica de processo. Neste sentido, o processo central, que pode tambm ser ele prprio um Web Service, controla a interaco com cada servio envolvido e coordena a execuo das suas diferentes operaes. A invocao de cada servio da responsabilidade do processo central (Figura 4.17). Esta abordagem normalmente seguida em processos internos nas organizaes.
Por outro lado, a coreografia dos servios no est suportada num processo central mas, neste caso, cada servio est envolvido na prpria execuo do processo principal e sabe exactamente quando deve executar as suas operaes e relacionar-se com os restantes servios (Figura 4.18). A coreografia consiste numa colaborao organizada entre os servios e na troca de mensagens. Cada servio sabe as mensagens XML que deve trocar, quando o deve fazer, que operaes deve executar e os processos participa. Embora o BPEL esteja orientado orquestrao, possvel
109
usar esta especificao para descrever e suportar uma coreografia entre Web Services. Este tipo de coreografia pode ser suportada de outras formas, por exemplo, com Java. Face a esta realidade, o consrcio W3C surge com a especificao Web Services Choreography Definition Language (WS-CDL) [W3C 2004] que vem complementar o BPEL na rea da coreografia dos Web Services.
Com a norma BPEL possvel seguir duas formas para descrever processos que suportem a orquestrao ou a coreografia:
Processos Executveis: definio completa de todas as partes de um processo e a sua sequncia que ser controlada centralmente por um motor de orquestrao.
Protocolos abstractos: permite a especificao pblica da troca de mensagens, somente entre cada interveniente, sem a especificao do processo completo mas s parte dele. Esta a configurao para a coreografia [W3C 2004].
Um processo BPEL consiste em etapas denominadas por ACTIVIDADE. Cada etapa corresponde a uma aco, ou primitiva, que corresponde a uma tarefa bsica como so:
<INVOKE> para invocar um servio <RECEIVE> para esperar por uma invocao externa (ex: receber um pedido) <REPLY> gerao de uma reposta para operaes sncronas
110
<ASSIGN> manipulao de variveis <THROW> para indicar uma excepo ou falha <WAIT> condio temporal de espera <TERMINATE> terminar um processo
Para alm destas aces, um processo BPEL suporta estruturas algortmicas mais complexas como por exemplo:
<SEQUENCE> conjunto de actividades segundo uma sequncia <FLOW> fluxos paralelos de execuo de actividades <SWITCH> condies de excuo <WHILE> para a definio de ciclos algortmicos <PICK> seleco de fluxos alternativos de processo
possvel complementar estas definies com as tags <PARTNERLINK> e <VARIABLE> para definir links de interligao e variveis respectivamente.
Um Web Service descrito atravs de uma estrutura WSDL que contm os detalhes da interaco que possvel ter-se com ele. Esta descrio contm o formato 111
das mensagens trocadas e os respectivos protocolos de transporte. O Service Provider ou fornecedor de servios regista num repositrio as definies WSDL para permitir aos sistemas identificar os Web Services e a forma como se interage com cada um. Esse repositrio funciona como um directrio informativo e estruturado de acordo com a especificao UDDI. A comunicao estabelecida entre os vrios Web Services e as entidades que os invocam regrada pelo protocolo SOAP que descreve o seu modo de interaco (Figura 4.19). O protocolo SOAP normalmente utilizado atravs de invocaes no protocolo HTTP, mas poder suporta-se noutras alternativas.
4.5.1 SOAP
O SOAP um protocolo simples baseado em XML para a troca de informao entre aplicaes via o protocolo HTTP. O SOAP o meio de comunicao onde circulam mensagem simples e utilizado para aceder a um Web Service e interagir com ele. As aplicaes podem normalemente estabelecer um canal de comunicao atravs dos protocolos CORBA, DCOM ou RPC. Estas formas de interao no so por vezes eficientes por questes configuraes de segurana, de dependncias ou de compatibilidade entre as aplicaes.
112
O SOAP utiliza o HTTP que um protocolo independente e compatvel com qualquer web browser ou servidor aplicacional. O protocolo HTTP utilizado como mtodo de comunicao do tipo request/response (pedido/resposta) seguindo as regras de estruturao do tipo SOAP. Um pedido SOAP utiliza as regras de binding do HTTP que identifica se o pedido do tipo POST ou GET. Uma mensagem SOAP contm informao estruturada em XML e contm os seguintes elementos: SOAP Envelope que identifica a mensagem. Header ou cabealho com informao. Body ou corpo com informao de REQUEST e RESPONSE. Fault ou erro com informao descritivas de erros de processamento.
Uma mensagem SOAP tem de ser estruturada em XML e no pode conter um DTD ou instrues de processamento XML. Por exemplo, um pedido SOAP de 113
informao de preo GetStockPrice a um determinado servidor, ter como parmetro StockName (Figura 4.20) e receber a resposta pelo parmetro Price (Figura 4.21). O namespace de XML para a funo est definida no endereo
http://www.stock.org/stock.
4.5.2 WSDL
O Web Service Description Language (WSDL) descreve os web services e a forma de interagir com eles. As definies dos documentos WSDL so estruturadas em XML e definem onde se encontra o web service e as operaes ou mtodos que este servio disponibiliza (Figura 4.22).
Um documento WSDL tem elementos do tipo <type>, <message>, <portType> e <binding> (Figura 4.23). O elemento <type> define o tipo de de dados utilizados num web service de acordo com a sintaxe XML schema de definio de tipos de dados. O elemento <message> identifica os elementos de dados de uma operao funcionando como a descrio dos seus parmetros. O elemento
<portType> o mais importante nesta estrutura definindo o prprio web service, as operaes que podem ser feitas e as mensagens associadas. O elemento <binding> define o formato da mensagem e o respectivo protocolo para cada port (ponto de interao ou operao). O prpio elemento de <binding> tem um nome, um estilo (style) que pode ser RPC ou DOCUMENT e o protocolo de comunicaes que
114
normalmente o HTTP. No elemento <portType> so definidas todas as operaes existentes no webservice e o seu tipo.
115
4.5.3 UDDI
O Universal Definition Discovery Interface (UDDI) corresponde a um repositrio onde se pode registar ou pesquisar servios (Figura 4.25). Tem um conjunto de documentos WSDL que permitem identificar e localizar os web services que correspondem aos requisitos de uma determinada funcionalidade.
O ciclo de registo e invocao de um webservice tem 5 etapas (Figura 4.26): 1. O web service disponibilizado por um Service Provider que o regista num directrio ou repositrio para o efeito. 2. Ao consultar o repositrio 3. Identificar um web service compatvel com as funcionalidades desejadas 4. Invocao do Web Service directamente ao seu fornecedor. 5. Devoluo das respostas pretendidas.
116
4.6 Smula
As solues para a integrao de SI esto em constante evoluo e podem ser aplicadas em diferentes situaes. Neste captulo, foram identificadas, e sumariamente explicadas, algumas das solues e normas mais comuns nesta rea. O principal objectivo foi o de clarificar o papel de cada uma delas e enquadr-las na rea da integrao de SI.
No que diz respeito integrao da informao, a norma XML utilizada em diferentes solues tecnolgicas, permitindo manusear e trocar a informao segundo um padro independentemente. Para a integrao aplicacional existem diversas formas de integrao assentes na codificao e no seu processamento. Ainda neste mbito, existem solues que se enquadram nas tecnologias de suporte a transaces, ao Messaging e aos Web Services. No que toca integrao aplicacional entre diferentes organizaes foram realadas as normas EDI e ebXML. Para a integrao orientada aos processos foi identificada a norma BPEL sendo, neste momento, uma das especificaes com mais destaque no mercado tecnolgico para a integrao de SI numa lgica de processo. Foram tambm includas neste captulo as principais normas relativas aos Web Services: SOAP, UDDI e WSDL.
117
O exemplo consiste na criao de uma aplicao que necessita de integrao com outras 2 aplicaes j existentes numa organizao. Pretende-se disponibilizar uma nova aplicao, para a gesto de requisies internas, tirando partido da informao e funcionalidades que j existem nas aplicaes de gesto de stocks e de gesto de recursos humanos. Dado que o principal propsito da implementao deste exemplo a ilustrao de diferentes abordagens de integrao, cada aplicao aqui descrita muito simples, e reala somente os componentes ou a informao que necessita de ser acedida ou integrada.
A abordagem tcnica deste exemplo de integrao est baseada em vrias tecnologias e linguagens, que permitem diferentes nveis de integrao abordados nos captulos anteriores, como so:
Oracle Database Enterprise Edition 10g Oracle Workflow 2.6.3 Oracle Forms Developer 10g e Oracle Jinitiator Java Oracle PL/SQL
118
SQL e Oracle SQL Plus Oracle Advanced Queueing para Messaging Middleware Apache, Oracle Container for Java e JDBC Case Studio 2.15 Web Services XML Oracle BPEL Process Manager 10g
Dado que se est a integrar uma nova aplicao com 2 j existentes, o exemplo integra no seu todo 3 aplicaes em concreto. A implementao deste exemplo tem duas partes onde se mostra uma primeira abordagem para a integrao das 3 aplicaes e se detalha uma segunda abordagem baseada na norma BPEL descrita neste trabalho. No final deste captulo so tecidas algumas concluses acerca destas duas implementaes.
De acordo com o vasto leque de alternativas tecnolgicas, haveria muitos cenrios possveis e diferenciados para a implementao deste caso de integrao. Foram definidos dois cenrios que permitem mostrar duas alternativas em concreto para este exemplo. Estes cenrios foram encontrados tendo como objectivo mostrar a implementao tcnica de :
Uma arquitectura a 3 nveis de uma aplicao. O uso de Messaging Middleware. A automatizao de um processo com workflow. O uso de pelo menos uma Application Programming Interface (API). A integrao aplicacional e de informao ao nvel da camada da apresentao. Uso de uma das plataformas de desenvolvimento, neste caso o J2EE. O uso de uma componente de Application Server, neste caso, o OC4J. A implementao de BPEL, XML e Web Services.
Este captulo est dividido em quatro partes. Na primeira parte feita uma breve descrio da estrutura do exemplo e de cada aplicao envolvida. Ao longo
119
desta primeira descrio detalha-se tambm, e de forma mais pormenorizada, cada aplicao, a lgica do processo de requisies e as formas de integrao implementadas. Na segunda parte do captulo inclui-se uma descrio passo a passo, seguindo todo o processo de aprovao de requisies, e mostrando ponto a ponto os tipos de integrao adoptados. Numa terceira parte, igualmente feita uma descrio passo a passo da segunda abordagem de integrao seguida. Neste caso, enquadra-se a utilizao de alternativas para esta integrao e detalha-se a sua implementao. Na quarta e ltima parte, feita uma breve smula da implementao deste exemplo e so tecidas algumas concluses.
120
mesmos bens e a aplicao de gesto de Recursos Humanos gere toda a informao relativa aos funcionrios assim como os respectivos departamentos.
A aplicao de Requisies assenta na arquitectura a 3 nveis descrita no captulo 2. Neste sentido, esta pode ser dividida em trs partes complementares e correspondentes ao nvel do cliente, ao nvel da lgica aplicacional e ao nvel da informao respectivamente (Figura 5.2). O primeiro nvel trata de camada de apresentao desta aplicao que pode ser acedida via web browser. O segundo nvel trata da execuo da lgica aplicacional e baseia-se num servidor aplicacional. O terceiro e ltimo nvel trata da disponibilizao e armazenamento da informao.
Procura-se neste caso criar diferentes tipos de integrao descritos nos captulos anteriores cobrindo a integrao de informao, a integrao aplicacional, a integrao de processos e a utilizao de uma alternativa baseada nos Web Services e no BPEL.
121
Jinitiator, por um nvel intermdio de execuo da lgica aplicacional baseado no servidor aplicacional Oracle Application Server 10g, nas suas componentes OC4J e no Forms Server, e por fim por um nvel de repositrio de informao disponibilizado pelo motor de base de dados Oracle 10g cujo nome BD_REQ.
O facto de se poder aceder a esta aplicao via protocolo HTTP torna possvel a sua integrao ao nvel da camada de apresentao por exemplo num Portal. Nesta aplicao foi embutido um objecto programado em Java, que usa a API (Application Programming Interface) do Oracle Forms e permite integrar parte da aplicao de Recursos Humanos (RH) de forma a validar os utilizadores e complementar a sua informao ao nvel da sua hierarquia (Figura 5.3). Ainda nesta aplicao, feita uma integrao de informao atravs de um Database Link que permite obter dados de outro repositrio, neste caso para validar os tipos de bens (ITEM) passveis de requisio assim como a sua descrio. Desta forma, possvel apresentar informao completa num nico cran aos utilizadores da respectiva aplicao aps o seu login.
122
Esta aplicao de Requisies integra-se tambm com um software de workflow que suporta o processo de aprovao de pedidos de aprovao para as requisies submetidas. Para este exemplo utilizada a Application Programming Interface (API) em PL/SQL para integrar com a aplicao de Requisies no seu nvel de lgica aplicacional (Figura 5.3). O processo implementado recebe da aplicao de Requisies a informao relativa ao bem requisitado, pessoa que fez essa requisio e ao seu superior. Para dar incio ao processo, a aplicao de Requisies invoca o procedimento armazenado REQ_PLSQL.INICIA_PROCESSO para o qual passa os parmetros do nmero da requisio (NUM_REQ), do utilizador que efectua a requisio (NOME_REQUISITANTE e ID_REQUISITANTE) e do superior hierrquico (SUPERIOR). Aps ser iniciado o processo tem 4 etapas principais (Figura 5.4):
Trata Requisio: Este um ponto de integrao ao nvel da informao, e onde o processo de workflow vai verificar nas bases de dados das aplicaes de Requisies e RH a descrio do tipo de bem requisitado e da identificao do departamento do utilizador em causa. Aqui implementada uma regra da organizao em que no caso do bem requisitado ser do tipo 1 (tipo DESKTOP), e do utilizador pertencer ao departamento nmero 1 (Vendas), a requisio ser automaticamente rejeitada.
123
Notifica Superior Hierrquico: Esta etapa corresponde notificao do superior hierrquico da pessoa que efectuou a requisio.
Requisio Recusada: Esta etapa corresponde notificao da pessoa que efectuou a requisio informando que o pedido de requisio foi rejeitado, automtica ou deliberadamente.
Actualiza e Despacha Requisio: Neste ponto a requisio foi aprovada. Esta etapa integra-se com a componente de Messaging deste exemplo para integrar com a aplicao de Stocks. Neste ponto feito o enqueue de uma mensagem contendo a informao da requisio para ser enviada para a aplicao de Stocks que ir tomar conta da requisio aprovada.
DEPARTAMENTOS.
124
Para este exemplo, as requisies foram criadas com o utilizador VICTOR, cujo nmero de funcionrio o 1, e cujo superior hierrquico o funcionrio de nome EDUARDO com o nmero de funcionrio 4 (Figura 5.5). Esta aplicao disponibiliza uma API em Java (valida_bd_rh.class) que permite validar quem o susperior hierrquico de um determinado funcionrio, assim como o nome completo desse funcionrio, bastando para isso enviar o parmetro do nmero de funcionrio (Figura 5.6).
125
Essa integrao foi efectuada em diferentes nveis de acordo com as respectivas estruturas aplicacionais (Figura 5.8):
126
1. Integrao aplicacional ao nvel da camada de apresentao (Ponto 0): Acesso aplicao de Requisies atravs de Web Browser na intranet da organizao. 2. Integrao de Informao (Ponto 1): Entre Aplicao Requisies e RH via componente Java que acede base de dados de RH via JDBC. 3. Integrao aplicacional (Ponto 2): Integrao de uma classe Java com lgica aplicacional da aplicao de RH e da aplicao de Requisies programada em Oracle Forms. Este ponto permite validar informao sobre a pessoa que efectua a requisio atravs da aplicao de RH. 4. Integrao de informao (Ponto 3): Atravs de um Database Link a aplicao de Requisies valida informao acerca dos bens requisitveis na base de dados da aplicao de Stocks. 5. Integrao aplicacional e de processos (Ponto 4): Integrao da aplicao de Requisies com o software de workflow atravs da sua API. O software de workflow permite tambm integrar numa lgica de processo as aplicaes de Requisies e de Stocks. 6. Integrao aplicacional (Pontos 5 e 6): Integrao do software de workflow com a o software de Messaging que se encarrega da troca de mensagens entre as aplicaes de Requisies e de Stocks. 7. Integrao aplicacional (Ponto 7): Integrao da aplicao de Stocks com o correio electrnico com o protocolo Simple Mail Transfer Protocol (SMTP).
127
Caso a requisio seja aprovada o sistema de workflow vai criar uma mensagem, com os dados da requisio aprovada, que submete a um Middleware de assente na tecnologia Oracle Advanced Queueing 10g. Esta camada de software vai encarregar-se de entregar com sucesso aplicao de Stocks uma mensagem estruturada que representa a requisio aprovada. Trata-se de um nvel de integrao entre aplicaes suportado em Middleware do tipo Messaging. Para isso, feita uma operao de Enqueue da mensagem na respectiva queue para esta seja entregue ao sistema destino atravs de uma operao do tipo Dequeue. Sendo este processo de trocas de mensagens executado com sucesso, a aplicao de Stocks tem a informao que identifica a necessidade de satifazer uma requisio. Para isso feita uma consulta base de dados que suporta a informao dos bens existentes em armazm, e quando o bem esteja disponvel enviado um email ao respectivo funcionrio que efectuou a requisio. Trata-se neste caso de uma integrao suportada no protocolo SMTP que permite o envio de informao, neste caso concreto, do envio de um email que permite fechar o ciclo do processo de submisso de requisies.
128
Este modelo Entidade-Relacionamento define as entidades e respectivos atributos para a implementao das tabelas na base de dados utilizada para a implementao deste exemplo (Figura 5.9). As entidades utilizadas para este exemplo so: ITEM, ITEM_EM_STOCK, TIPO_ITEM, DEPARTAMENTO,
N de requisio. Data de requisio. Identificao do funcionrio que cria a requisio. Nome do funcionrio que cria a requisio. Identificao do bem (ITEM) a requisitar. Nome do bem a requisitar. Justificao da requisio.
129
Nesta aplicao integrada uma classe de Java pertencente aplicao de RH (Figura 5.11). Para isso usado o objecto BEAN AREA do Oracle Forms.
130
Esta aplicao tambm se integra ao nvel da camada de informao com a aplicao de Stocks atravs de um Database Link (DBL_BD_STOCK) para obter informao detalhada acerca dos bens requisitveis (Figura 5.12).
131
Figura 5.13: Acesso via Web Browser aplicao de Requisies com utilizador VICTOR
132
Ao entrar na aplicao de Requisies o campo do nome do utilizador automaticamente preenchido (Figura 5.14). Entretanto j foi automaticamente obtida toda a informao acerca do superior hierrquico do utilizador que se autenticou na aplicao com a integrao do pedao de cdigo Java pertencente aplicao de RH que retorna a respectiva informao (Figura 5.15).
133
Durante a execuo da aplicao de Requisies feita a integrao ao nvel da informao com a aplicao de Stocks atravs de um Database Link que fornece informao a uma lista de valores acerca dos bens requisitveis (Figura 5.16).
Ao criar e submeter a requisio na aplicao de requisies mostrada uma mensagem informativa na parte inferior da aplicao que indica se a integrao com o software de workflow foi feita com sucesso ou no. Neste caso foi submetido o pedido de requisio n 10 para o um computador do tipo desktop com o utilizador Victor que pertence ao departamento de Vendas (Figura 5.17).
134
Ao submeter a requisio possvel acompanhar a execuo do processso de workflow e retirar informao para a sua monitorizao. O processo para a requisio n 10 foi iniciado (Figura 5.18) e aplicou automaticamente a regra de restrio para os bens do tipo computadores desktop requisitados por pessoas pertencentes ao departamento de Vendas (Figura 5.19).
135
Esta regra automaticamente aplicada pelo software de workflow tambm informa automaticamente o utilizador da razo pela qual houve essa recusa preenchedo o campo das observaes (Figura 5.20). Esta regra implementada num procedimento armazenado na base de dados que influencia o caminho seguido pelo processo de workflow retornando o resultado verdadeiro (T) ou falso (F) consoante a informao contida na requisio criada (Figura 5.21).
136
Para efeitos de ilustrao criada uma nova requisio n11 com o mesmo utilizador mas desta vez com um bem do tipo computador porttil com a identificao n2 (Figura 5.22).
137
Dado que esta requisio n11 no colide com a regra automtica descrita anteriormente, o processo de workflow segue o seu caminho normal (Figura 5.23) e o superior hierrquico (EDUARDO) da pesssoa que criou a requisio (VICTOR) notificado para dar o seu parecer (Figura 5.24).
138
O utilizador EDUARDO vai poder dar o seu parecer acerca da requisio n11 submetida pelo utilizador VICTOR (Figura 5.25). Neste caso s se mostra a informao acerca do nmero da requisio e da pessoa que a submeteu. Como o objectivo mostrar a especificamente a integrao entre as diversas aplicaes em cada uma das perspectivas descritas neste trabalho no foi includo na notificao informao mais detalhada acerda da requisio. Para este caso a requisio foi aprovada (Figura 5.26).
Tendo sido aprovada a requisio, o processo de workflow chegou a seu fim mas integrando-se entretanto com a componente de Messaging utilizada neste exemplo para enviar uma mensagem aplicao de Stocks informando da existncia de uma requisio aprovada (Figura 5.27).
139
BD_REQ.SUBMETER_MENSAGEM_AQ, passando como parmetros o nmero da requisio, a identificao do bem, a data da requisio e o nome do bem (Figura 5.28).
140
procedimento
invocado
efectua
uma
operao
de
ENQUEUE
(DBMS_AQ.ENQUEUE) no sistema Oracle Advanced Queueing 10g enviando a mensagem destinada aplicao BD_STOCK, que representa a integrao com a aplicao de Stocks, atravs da fila de mensagens (queue) Q_1 (Figura 5.29).
141
A aplicao de Stocks faz uma operao de leitura de mensagems invocando a API do sistema de Messaging com a operao DEQUEUE que est no cdigo TRATA_REQUISICOES_AQ.RECEBE_REQUISICAO_MESSAGING 5.30). possvel neste caso visualizar o contedo da mensagem n11. (Figura
Aps validar que o bem existe em stock feita a integrao com o sistema de email da organizao atravs do protocolo de Simple Mail Transport Protocol (SMTP) e da API da base de dados UTL_SMTP incoporada no cdigo TRATA_REQ.ENVIA_EMAIL_ITEM_DISPONIVEL (Figura 5.31). Neste caso enviado um email directamente para a pessoa que requisitou o bem informando-a que o item requisitado j est disponvel para ser levantado (Figura 5.32).
142
143
Esta abordagem est suportada no BPEL Process Manager que permite criar as suas definies e execut-las de forma a poder integrar os diferentes Web Services. Neste caso, o cran da aplicao de Requisies deixa de ser utilizado, passando a ser utilizado um cran em HTML directamente no Web Browser. Esse novo cran permite introduzir a informao relativa requisio e integra-se directamente com o sistema de execuo do BPEL. Essa informao pode ser submetida em HTML ou directamente em XML.
144
Para este exemplo criado o primeiro Web Service inserir_requisicao que permite invocar um procedimento armazenado PL/SQL que recebe informao da requisio em XML e cria o registo na respectiva base de dados BD_REQ na tabela REQUISICOES (Figura 5.34). A identificao deste Web Service feita atravs da norma WSDL e que define, entre outras coisas, o seu nome (inserir_requisicao), as mensagens de input e output e respectivas operaes (inserirRequisicao0Request e inserirRequisicao0Response) e informao para a comunicao com o protocolo SOAP, nomeadamente o estilo de operao (Remote Procedure Call - RPC) e a sua localizao na rede em http://vmartins-pt:8893/requisicoes_ws-Project1-contextroot/Inserir_requisicao (Figura 5.35).
145
Com a ferramenta de programao Oracle JDeveloper 10g feito o deployment deste Web Service numa componente do tipo Servidor Aplicacional, denominado Oracle Container for Java (OC4J) ficando desta forma disponvel e acessvel (Figura 5.36).
146
Figura 5.37: OC4J para disponibilizar os Web Services baseado na plataforma J2EE
O OC4J uma componente do servidor aplicacional da Oracle e permite um acesso via HTTP no porto 8893 a um conjunto de servios e aplicaes como so por exemplo os Web Services (Figura 5.37). Atravs do protocolo HTTP pode-se aceder ao Web Service atravs do URL http://vmartins-pt:8893/requisicoes_ws-Project1context-root/Inserir_requisicao (Figura 5.38).
Figura 5.38: Web Service para a criao das requisies com operao inserirRequisicao
147
A descrio do Web Service atravs da norma WSDL est disponvel na rede como OC4J e atravs do endereo: http://vmartins-pt:8893/requisicoes_ws-Project1context-root/Inserir_requisicao?WSDL (Figura 5.39). Pela mesma via tambm possvel invocar directamente o Web Service atravs de um cran em HTML que permite inserir os parmetros necessrios (Figura 5.40).
148
A invocao directa do Web Service inserir_requisicao retorna uma mensagem em XML com o resultado da operao e correspondente definio WSDL (Figura 5.41). Para verificar o real sucesso da operao feita uma query base de dados na sobre a tabela REQUISIES (Figura 5.42): select num_req,id_funcionario,id_item,nome_item,justificacao num_req='33'; from requisicoes where
Figura 5.42: Query sobre tabela Requisies com registo da requisio n33 subemtido por Web Service
149
150
Figura 5.44: Web Service para invocao do sistema de workflow de aprovao de requisies
Na mesma ordem de ideias, este segundo Web Service pode ser acedido directament via http no endero http://vmartins-pt:8893/requisicoes_ws-Project2context-root/Chama_wf_ws (Figura 5.44) e pode tambm ser invocado directamente pela mesma via (Figura 5.45).
151
A invocao directa deste segundo Web Service retorna informao em XML indicando que o processo de workflow foi iniciado com sucesso. Esta a mesma informao que ser passada ao sistema que executa o BPEL (Figura 5.46).
Figura 5.47: Requisio n44 submetida por Web Service sujeita a aprovao no sistema de workflow
A invocao directa deste Web Service criando a requisio n 44 despoletou o software de workflow que segue exactamente os mesmo passos e regras explicadas nos pontos anteriores na primeira abordagem de integrao deste captulo (Figura 5.47).
152
O processo n44 iniciado atravs do Web Service chama_wf_ws notificou o superior hierrquico da pessoa que criou a requisio n 44 (Figura 5.48).
153
Esta ferramenta permite conceber graficamente as definies BPEL criando automaticamente a respectiva estrutura em XML, permitindo tambm fazer o deployment da respectiva definio no Oracle OC4J que suporta o Oracle BPEL Process Manager (Figura 5.50).
154
A definio grfica deste processo BPEL est estruturada por 7 etapas processuais e 3 partnerlinks que correspondem aos 3 pontos de interaco com este processo BPEL (Figura 5.51). A primeira etapa receiveInput trata de receber informao em XML que representa a requisio que se quer criar e submeter para aprovao. A segunda etapa Assign_1 trata de passar a informao necessria para variveis internas de forma a passar somente os parmetros necessrios aquando da invocao dos Web Services. A terceira etapa Inserir_Requisicao trata de invocar de forma scncrona o Web Service inserir_requisicao armazenando o seu resultado. A quarta etapa Assign_2 trata de utilizar o resultado encontrado na etapa anterior de forma a poder invocar o prximo Web Service com os parmetros correctos.
155
A quinta etapa Chama_Workflow invoca sincronamente o Web Service chama_wf_ws de forma a iniciar o processo de workflow para aprovao do pedido de requisio e armazena o resultado dessa invocao. A sexta etapa Assign_3 trata a informao recebida na etapa anterior de forma a poder preparar o resultado final
156
deste processo BPEL. A stima e ltima etapa replyOutput retorna o resultado final para o sistema que invocou este BPEL.
Figura 5.52: Associao e passagem de valores entre parmetros do BPEL e dos Web Services
A passagem de valores feita nas etapas do tipo Assign que permitem tratar a informao em xml que veiculada ao londo do processo BPEL. No caso da etapa Assign_1 so passados os 4 valores existentes na estrutura em XML que est na inputVariable. Essa estrutura normalmente denominada de payload e tem toda a informao que enviada ao sistema que executa as definies BPEL. Dado que este exemplo em BPEL s recebe o nmero de identificao da pessoa que cria a requisio, o Web Service inserir_requisicao retorna o valor correspondente ao nome completo dessa pessoa (Figura 5.52) e que est na tabela FUNCIONARIOS da base de dados da aplicao de RH.
157
Figura 5.53: Alterao da resposta do Web Service da aplicao de Requisies que retorna nome de requisitante
O valor retornado pelo Web Service invocado armazenado na varivel return (Figura 5.53) e automaticamente mapeado para o parmetro nome Requisitante do segundo Web Service chama_wf_ws (Figura 5.54).
Figura 5.54: Passagem do valor retornado pelo Web Service alterado no ponto anterior
158
Aps a finalizao da definio em BPEL da verso 1.0 do processo REQUISICOES_BPEL faz-se o deployment dele para o sistema de execuo do BPEL BPEL Server baseado no OC4J 10g (Figura 5.55).
O sistema BPEL Server disponibiliza um ambiente de monitorizao e testes, denominado de BPEL Console, na a execuo dos processos BPEL (Figura 5.56).
Figura 5.56: BPEL Console Administrao e teste dos processos de BPEL via Web.
159
Para dar incio execuo desta segunda abordagem com BPEL utilizado um cran em HTML que se substitui ao cran da aplicao de Requisies implementado em Oracle Forms 10g. Aqui so introduzidos os valores para a requisio n100 do bem n2 pela pessoa n2 (Figura 5.57). O processo executado com sucesso retornando a informao relativa ao segundo Web Service (Figura 5.58).
Figura 5.58: Processo BPEL sncrono executado com sucesso para a requisio n 100
160
Figura 5.59: Monitorizao on-line via Web do processo BPEL para a requisio n 100
O ambiente de monitorizao do Oracle BPEL Process Manager permite visualizar o processo n100 na sua forma grfica e analisar toda a informao veiculada ao longo das suas etapas (Figura 5.59). A informao submetida atravs do cran em HTML estruturada internamente em XML (Figura 5.60).
161
Figura 5.61: XML na invocao do Web Service Inserir_Requisicao para a requisio n100
A informao passada ao primeiro Web Service tambm est estruturada em XML (Figura 5.61) assim com resultado obtido aquando da sua invocao na varivel return. Ao invocar este Web Service o BPEL vai criar um novo registo na base de dados correspondentes requisio n100 (Figura 5.62).
Figura 5.62: Verificao da criao da requisio n 100 na base de dados via BPEL + Web Service
162
A informao passada ao segundo Web Service est igualmente estruturada em XML assim como o resultado armazenado na varivel return (Figura 5.63). O processo de workflow foi entretanto lanado (Figura 5.64) e o resto da aplicao segue exactamente as mesmas etapas da primeira abordagem implementada para este exemplo (Figura 5.65).
Figura 5.64: Requisio n100 submetida ao sistema de workflow via BPEL + Web Service
163
Figura 5.75: Requisio n100 submetida ao sistema de workflow via BPEL + Web Service
No final, e tal como na primeira abordagem a aplicao de Stocks envia um email para a pessoa que efectuou a requisio, neste caso via BPEL Process Manager (Figura 5.76).
164
tambm possvel iniciar um processo BPEL directamente com informao j estruturada em XML (Figura 5.77) e envi-la desta forma para o sistema que executa o processo BPEL (Figura 5.78).
Apesar de se ter enviado directamente XML, as restantes etapas desta abordagem para a integrao destas aplicaes seguem a mesma lgica sem qualquer alterao e com o mesmo tipo de resultado (Figura 5.79).
165
Figura 5.79: Processo BPEL para a requisio n103 submetida em XML finalizado
A primeira abordagem baseou-se em tecnologias comuns para a integrao de cada aplicao (Tabela 5.1). A integrao de componentes Java, as chamadas a interfaces aplicacionais do tipo API, a integrao de informao entre bases de dados com Database Links, a integrao de processos com workflow e a utilizao do Messaging Middleware mostra-nos uma soluo para este exemplo de integrao. No que diz respeito aos pontos de integrao esta primeira abordagem contem algumas
166
dependncias entre sistemas. Por exemplo, sem a integrao na aplicao de Requisies da componente Java, pertencente aplicao de RH, a criao da requisio no seria feita com a informao correcta. E neste caso no h alternativa seno a da incorporao desta componente aplicacional.
Segunda abordagem
Integrao com aplicao de Requisies via Web Services (Introduo da informao em XML para dar incio ao pedido de requisio, suportado na interface web do BPEL Process Manager, subsituindo o cran desenvolvido em Oracle Forms).
Integrao com componente de workflow via Web Services. Integrao de processos com BPEL e Web Services (Abordagem do tipo Service Oriented Architecture).
167
A segunda abordagem pretende ser mais flexvel e utilizar solues mais recentes realando o seu papel na integrao de SI. Com a introduo de Web Services criou-se uma camada de abstraco sobre cada aplicao que passa a estar disponvel como servio. Isto permite criar pontos de integrao normalizados e suficientemente flexveis para serem, ou no, integrados noutras aplicaes. O uso do BPEL veio dar uma lgica processual utilizao de cada Web Service disponibilizando um novo ponto de partida para os pedidos de requisies. Pelo facto de aceitar directamente informao em XML, esta segunda alternativa de implementao proporciona maior flexibilidade e independncia aplicacional, ou seja, no obrigatrio utilizar uma aplicao concebida de propsito para esse efeito, como o caso do cran da aplicao de Requisies desenvolvido em Oracle Forms 10g. Neste caso, a adopo de Web Services permite, por um lado, disponibilizar funcionalidades dos sistemas internos de forma a poder integr-los, e por outro lado, dar maior adaptabilidade do processo de aprovao de requisies que agora controlado pelo BPEL. Este controlo permite tambm centralizar a administrao e a monitorizao deste processo especfico, proporcionado um nvel superior de acompanhamento do desempenho e da qualidade do processo.
A arquitectura da segunda abordagem segue a filosofia de Service Oriented Arquitecture (SOA) permitindo disponibilizar aplicaes e informao como servios. Esta realidade permite a reutilizao e integrao destes servios em solues mais abrangentes e flexveis para o desempenho do negcio. Apesar do principal propsito deste exemplo ser a ilustrao de algumas formas de integrao, suportadas em diferentes normas e tecnologias, a alternativa criada com a norma BPEL , neste caso concreto, complementar a alguns dos pontos de integrao implementados na primeira abordagem. Este tambm um dos propsitos do BPEL e dos Web Services que permitem reutilizar sistemas que podem por vezes ser classificados de obsoletos pelo simples facto de no se conseguir integrar com novas solues. Como j foi referido, cada caso de integrao de SI ter diferentes abordagens onde o BPEL pode ser uma soluo vivel.
168
6. Concluses
O tema da integrao de SI muito vasto e dinmico. Como resultado da evoluo das TI, e do seu impacto nas organizaes, h hoje em dia uma panplia de ofertas e alternativas para encontrar solues adequadas. Um dos grandes problemas neste campo a heterogeneidade de modelos, conceitos e catalogaes tecnolgicas que no ajuda no enquadramento de problemas e respectivas solues. Nos ltimos anos, tem havido uma convergncia de conceitos e tecnologias que torna esta situao ainda mais complexa. Neste sentido, a adopo de normas de mercado garante a certificao e abertura das solues implementadas nesta rea.
O enquadramento da integrao de SI centrado na informao, nas aplicaes, nos processos e na prpria organizao permite distinguir quatro perspectivas de grupos tecnolgicos nesta rea. Em cada um deles possvel tirar partido de normas de mercado como so os Web Services que permitem disponibilizar informao e invocar lgica aplicacional atravs dos protocolos de comunicao mais comuns e utilizados na Internet. A complementaridade destas quatro abordagens com os Web Services permite definir uma arquitectura orientadas aos servios, denominada por Service Oriented Architecture (SOA). A norma Business Process Execution Language (BPEL) vem de encontro necessidade de orquestrao dos Web Services na implementao do SOA, dando-lhe uma perspectiva processual, e garantindo uma integrao a esse nvel. A perspectiva da integrao entre organizaes mais abrangente tendo como principal intuito facilitar as trocas comerciais suportadas electronicamente, obrigando cada uma das organizaes a integrar parte dos seus sistemas. Um projecto para a integrao de SI pode ser muito complexo e de difcil realizao dada a sua abrangncia e s vertentes organizacionais que engloba. Um projecto desta natureza tem impacto no sistemas de informao internos, nos diferentes departamentos que tiram partido desses sistemas, nas tomadas de deciso baseadas em informao de gesto e nas relaes entre as prprias organizaes. As perspectivas conceptuais descritas neste trabalho so complementares e permitem em cada uma das suas reas seguir abordagens de integrao enquadradas. Desta forma
169
possvel reduzir alguma desta complexidade dividindo o mbito em reas com diferentes necessidades.
O planeamento de projectos para a integrao de SI pode tambm revelar-se complexo face sua abrangncia. Em cada uma das perspectivas descritas pode-se adoptar diferentes tecnologias, e configurar diferentes solues baseadas na combinao e integrao de componentes para as suportar.
Nestas ltimas dcadas assistiu-se a uma crescente evoluo no objectivo das solues informatizadas. Houve uma primeira fase cujo objectivo foi a digitalizao da informao, recorrendo-se aos sistemas de gesto de bases de dados. Com o amadurecimento destas solues, o foco passou a ser a criao de aplicaes informticas integradas, como so os Enterprise Resource Planning (ERP) que exploram as bases de dados entretanto criadas. Na ltima dcada, procurou-se a automatizao dos processos organizacionais com o intuito de aumentar a sua eficincia e de integrar aplicaes informticas. Com os Web Services e o BPEL abrem-se novas perspectivas para a explorao e integrao desses processos automatizados e das suas respectivas aplicaes. Torna-se possvel a flexibilizao total desses processos criando solues que se auto-adaptam consoante os requisitos e as situaes. Esta realidade traz novas necessidades acerca da gesto e monitorizao desse tipo de solues que esto no mbito das ferramentas de anlise e outras tecnologias do tipo Business Activity Monitorig (BAM). Com a Globalizao esta tendncia faz cada vez mais sentido dado que as organizaes deixam de estar fisicamente longnquas para estarem electronicamente prximas. A arquitectura SOA responde tecnicamente as estas questes o que a torna incontornvel quando se pensa numa soluo para a integrao de SI. E toda esta evoluo tem o seu impacto nas organizaes obrigando-as por um lado a estar sempre actualizadas, sob pena de deixarem de ser competitivas, mas trazendo por outro lado novas oportunidades.
Por seu turno, e ao longo destes anos, as normas tcnicas foram acompanhando a evoluo da tecnologia, permitindo a sua documentao e integrao. Assiste-se agora neste mbito a uma convergncia de especificaes que ajudam a encontrar as solues mais flexveis e independentes dos fornecedores de tecnologia. A norma BPEL a prova desta convergncia que aproxima os 170
fornecedores da tecnologias e as suas solues. A crescente adopo e maturidade desta norma d maior credibilidade s solues de integrao que se baseiam nela. A importncia dos processos organizacionais e da sua automatizao aqui reforada por esta mesma norma.
Para a rea da integrao de SI existe uma manifesta falta de metodologias abragentes que permitam definir, planear e documentar por completo uma abordagem para a integrao de SI. Existem diversas metodologias isoladas para as diferentes perspectivas e tecnologias descritas neste trabalho, mas no existe nenhuma abordagem global e suficientemente abragente para esta rea. Fica como sugesto a definio futura de uma metodologia abragente para a rea do Planeamento, Desenvolvimento e Gesto da Integrao de SI (PDGISI). Esta metodologia permitir definir, planear e documentar uma abordagem global e fundamentada para solucionar um problema de integrao de SI. Associado a esta sugesto fica tambm a identificao de parmetros gerais que permitam comparar solues de integrao de SI e avaliar a sua adequabilidade numa organizao, identificando as suas vantagens e retornos para a mesma.
A avaliao das estratgias e comparao das solues para a integrao de SI tem tambm lacunas evidentes. Dada a natureza complexa desta rea, e das diferentes alternativas que se apresentam face a um mesmo problema, difcil avaliar de forma sistemtica a real adequabilidade de uma soluo. Ainda neste sentido, as solues so de difcil comparao dada a sua natureza heterognea e a falta de pontos comparativos.
Para alm das questes da diferentes pespectivas encontradas neste trabalho, e das diversas normas tcnicas existentes, a solues baseadas em Open Source tm tido alguma presena nesta rea embora estejam ainda sujeitas desconfiana existente devido sua natureza aberta e no comercial. Esta realidade vem aumentar a complexidade do tema da integrao de SI.
Como tambm j foi referido, as organizaes tm cada vez mais necessidades na integrao dos seus sistemas devido a uma necessidade de maior flexibilizao dos seus sistemas e crescente concorrncia e abertura de mercados. Neste sentido, 171
surgem novos perfis profissionais nas reas das tecnologias da informao dedicados integrao de SI.
Como ltima sugesto, fica o complemento do exemplo de integrao, implementado e ilustrado neste trabalho, com tecnologias de anlise e monitorizao de actividades do tipo Business Activity Monitoring (BAM) que ajudar tambm na identificao dos parmetros de avaliao referidos neste captulo.
A integrao de SI est em constante evoluo e cruza diferentes reas e disciplinas enquadradas nos Sistemas de Informao. por isso importante clarificar e definir conceitos, abordagens e metodologias para um melhor entendimento desta realidade complexa. Este trabalho foi realizado com esta linha de pensamento e fica como contributo para a melhor clarificao e compreenso deste tema.
172
7. Apndices
7.1 Criao dos utilizadores de base de dados Oracle
create user BD_REQ IDENTIFIED BY BD_REQ DEFAULT TABLESPACE USERS TEMPORARY TABLESPACE TEMP; GRANT CONNECT, RESOURCE TO BD_REQ; GRANT aq_administrator_role TO BD_REQ; grant execute on dbms_aqadm to BD_REQ; grant execute on dbms_aq to BD_REQ; create user BD_RH IDENTIFIED BY BD_RH DEFAULT TABLESPACE USERS TEMPORARY TABLESPACE TEMP; GRANT CONNECT, RESOURCE TO BD_RH; GRANT aq_administrator_role TO BD_RH; grant execute on dbms_aqadm to BD_RH; grant execute on dbms_aq to BD_RH; create user BD_STOCK IDENTIFIED BY BD_STOCK DEFAULT TABLESPACE USERS TEMPORARY TABLESPACE TEMP; GRANT CONNECT, RESOURCE TO BD_STOCK; GRANT aq_administrator_role TO BD_STOCK; grant execute on dbms_aqadm to BD_STOCK; grant execute on dbms_aq to BD_STOCK;
173
174
DATA_ITEM_STOCK Date NOT NULL , QUANTIDADE Number NOT NULL ) / Create table REQUISICAO_XML ( ID_REQ_XML Varchar2(10) NOT NULL , DOC_XML XMLTYPE) /
table REQUISICOES add primary key (NUM_REQ) table FUNCIONARIOS add primary key (ID_FUNCIONARIO) table FUNCOES add primary key (ID_FUNCAO) table DEPARTAMENTOS add primary key (ID_DEPARTAMENTO) table ITEMS add primary key (ID_ITEM) table TIPOS_ITEM add primary key (ID_TIPO_ITEM) table FORNECEDORES add primary key (ID_FORNECEDOR) table ITEMS_EM_STOCK add primary key (ID_ITEM_STOCK) table REQUISICAO_XML add primary key (ID_REQ_XML)
Alter table REQUISICOES add foreign key (ID_FUNCIONARIO) references FUNCIONARIOS (ID_FUNCIONARIO) / Alter table FUNCIONARIOS add foreign key (ID_FUNCAO) references FUNCOES (ID_FUNCAO) / Alter table FUNCIONARIOS add foreign key (ID_DEPARTAMENTO) references DEPARTAMENTOS (ID_DEPARTAMENTO) / Alter table REQUISICOES add foreign key (ID_ITEM) references ITEMS (ID_ITEM) / Alter table ITEMS_EM_STOCK add foreign key (ID_ITEM) references ITEMS (ID_ITEM) / Alter table ITEMS add foreign key (ID_TIPO_ITEM) references TIPOS_ITEM (ID_TIPO_ITEM) / Alter table ITEMS add foreign key (ID_FORNECEDOR) references FORNECEDORES (ID_FORNECEDOR) / Alter table FUNCIONARIOS add foreign key (ID_SUPERIOR) references FUNCIONARIO (ID_FUNCIONARIO) /
175
insert into funcoes values ('1','DIRECTOR',null); insert into funcoes values ('2','FUNCIONARIO',null); insert into departamentos values ('1','VENDAS','PORTO',null); insert into departamentos values ('2','MARKETING','PORTO',null); insert into departamentos values ('3','RH','PORTO',null); insert into funcionarios values ('3','2','1','CARLOS',to_date('20-011999','dd-mm-yyyy'),NULL); insert into funcionarios values ('4','1','1','EDUARDO',to_date('1009-1996','dd-mm-yyyy'),NULL); insert into funcionarios values ('5','3','1','MARIA',to_date('11-032000','dd-mm-yyyy'),NULL); insert into funcionarios values ('1','1','2','VICTOR',sysdate,NULL); insert into funcionarios values ('2','2','2','CESAR',to_date('17-121999','dd-mm-yyyy'),NULL);
('1','COMPUTADOR DESKTOP'); ('2','MONITOR'); ('3','RATO'); ('4','DISCO EXTERNO'); ('5','TECLADO'); ('6','CD'); ('7','PLACA WIRELESS'); ('8','TRANSFORMADOR'); ('9','COMPUTADOR PORTATIL');
INSERT INTO FORNECEDORES VALUES ('1','FORNECEDOR 1 PT','FORNECEDOR NACIONAL','PORTO'); INSERT INTO FORNECEDORES VALUES ('2','FORNECEDOR 2 FR','FORNECEDOR ESTRANGEIRO','PARIS'); INSERT INTO ITEMS VALUES RAM',NULL); INSERT INTO ITEMS VALUES 100GB DISCO',NULL); INSERT INTO ITEMS VALUES DESKTOP',NULL); INSERT INTO ITEMS VALUES 200GB',NULL); INSERT INTO ITEMS VALUES XZTP',NULL); ('1','1','1','DESKTOP MARCA XPTO 2GB ('2','1','9','PORTATIL MARCA XPTO 1GB RAM ('3','1','8','TRANSFORMADOR ZPTO PARA ('4','2','4','DISCO EXTERNO PARA BACKUP XZTP ('5','1','7','PLACA WIRELESS MARCA
INSERT INTO ITEMS_EM_STOCK VALUES ('1','5',SYSDATE,5); INSERT INTO ITEMS_EM_STOCK VALUES ('2','2',SYSDATE,2); INSERT INTO ITEMS_EM_STOCK VALUES ('3','4',SYSDATE,2);
176
begin dbms_aqadm.create_queue_table ( Queue_table => 'QT_1', Multiple_consumers => TRUE, auto_commit => TRUE, Compatible => '8.1', Queue_payload_type => 'Requisicao_t'); end; / begin DBMS_AQADM.CREATE_QUEUE ( queue_name => 'Q_1', retention_time => 3600, auto_commit => true, queue_table => 'QT_1'); end; / DECLARE subscriber sys.aq$_agent; BEGIN
subscriber := sys.aq$_agent('BD_STOCK', NULL, NULL); DBMS_AQADM.ADD_SUBSCRIBER(queue_name => 'Q_1', subscriber => subscriber); END; /
begin DBMS_AQADM.START_QUEUE (
177
DBMS_AQADM.SCHEDULE_PROPAGATION(queue_name => 'BD_REQ.Q_1', destination => 'dbl_bd_stock'); END; / /********** COMANDOS PARA BD_STOCK ********************/ CREATE type Requisicao_t as object ( NUM_REQ Varchar2(10), ID_ITEM Varchar2(10), DATA Date, NOME_ITEM Varchar2(50)); / begin dbms_aqadm.create_queue_table ( Queue_table => 'QT_2', Multiple_consumers => TRUE, auto_commit => TRUE, Compatible => '8.1', Queue_payload_type => 'Requisicao_t'); end; / begin DBMS_AQADM.CREATE_QUEUE ( queue_name => 'Q_2', retention_time => 3600, auto_commit => true, queue_table => 'QT_2'); end; / begin DBMS_AQADM.START_QUEUE ( queue_name => 'Q_2', enqueue => TRUE, dequeue => TRUE); end; /
/**************************** Com BD_REQ - ENQUEUE *************** *********/ DECLARE enqueue_options message_properties recipients message_handle DBMS_AQ.enqueue_options_t; DBMS_AQ.message_properties_t; DBMS_AQ.aq$_recipient_list_t; RAW(16);
178
message
Requisicao_t;
message := Requisicao_t(NUM_REQ,ID_ITEM,DATA,NOME_ITEM); recipients(1) := sys.aq$_agent('BD_STOCK',NULL,NULL); message_properties.recipient_list := recipients; DBMS_AQ.ENQUEUE(queue_name => 'Q_1', enqueue_options => enqueue_options, message_properties => message_properties, payload => message, msgid => message_handle); commit; END; / ------------------------------create or replace procedure submeter_mensagem_aq(NUM_REQ inVARCHAR2, ID_ITEM in VARCHAR2, DATA in DATE, NOME_ITEM in VARCHAR2) is Pragma autonomous_transaction; enqueue_options message_properties recipients message_handle message DBMS_AQ.enqueue_options_t; DBMS_AQ.message_properties_t; DBMS_AQ.aq$_recipient_list_t; RAW(16); Requisicao_t;
BEGIN NUM_REQ_V :=NUM_REQ; ID_ITEM_V :=ID_ITEM; DATA_V := DATA; NOME_ITEM_V := NOME_ITEM; message := Requisicao_t(NUM_REQ_V,ID_ITEM_V,DATA_V,NOME_ITEM_V); recipients(1) := sys.aq$_agent('BD_STOCK',NULL,NULL); message_properties.recipient_list := recipients; DBMS_AQ.ENQUEUE(queue_name => 'BD_REQ.Q_1', enqueue_options => enqueue_options, message_properties => message_properties, payload => message, msgid => message_handle);
179
commit; END; /
--NOTA:
DECLARE dequeue_options dbms_aq.dequeue_options_t; message_properties dbms_aq.message_properties_t; message_handle RAW(16); message Requisicao_t; no_messages exception; pragma exception_init (no_messages, -25228); BEGIN dequeue_options.wait := DBMS_AQ.NO_WAIT; BEGIN dequeue_options.consumer_name := 'BD_STOCK'; dequeue_options.navigation := DBMS_AQ.FIRST_MESSAGE; LOOP DBMS_AQ.DEQUEUE(queue_name => 'BD_REQ.Q_1', dequeue_options => dequeue_options, message_properties => message_properties, payload => message, msgid => message_handle); DBMS_OUTPUT.PUT_LINE (message.NUM_REQ||' '||message.ID_ITEM||' '||message.DATA||' '||message.NOME_ITEM); dequeue_options.navigation := DBMS_AQ.NEXT_MESSAGE; END LOOP; EXCEPTION WHEN no_messages THEN DBMS_OUTPUT.PUT_LINE ('No h mais mensagens.'); COMMIT; END; END; /
create or replace function ler_mensagem_aq(identificacao in varchar2) return varchar2 is dequeue_options dbms_aq.dequeue_options_t; message_properties dbms_aq.message_properties_t; message_handle RAW(16); message Requisicao_t; no_messages exception; pragma exception_init (no_messages, -25228);
180
identificacao_v varchar2(10); BEGIN dequeue_options.wait := DBMS_AQ.NO_WAIT; --identificacao_v:=identificacao; identificacao_v:='BD_STOCK'; BEGIN -- dequeue_options.consumer_name := 'BD_STOCK'; dequeue_options.consumer_name := identificacao_v; dequeue_options.navigation := DBMS_AQ.FIRST_MESSAGE; LOOP DBMS_AQ.DEQUEUE(queue_name => 'BD_REQ.Q_1', dequeue_options => dequeue_options, message_properties => message_properties, payload => message, msgid => message_handle); DBMS_OUTPUT.PUT_LINE (message.NUM_REQ||' '||message.ID_ITEM||' '||message.DATA||' '||message.NOME_ITEM); return(message.NUM_REQ||'-'||message.ID_ITEM||''||message.DATA||'-'||message.NOME_ITEM); dequeue_options.navigation := DBMS_AQ.NEXT_MESSAGE;
END LOOP; EXCEPTION WHEN no_messages THEN DBMS_OUTPUT.PUT_LINE ('No h mais mensagens.'); Return('0'); COMMIT; END; END; /
181
PROCEDURE RECEBE_REQUISICAO_MESSAGING; PROCEDURE ENVIA_EMAIL_ITEM_DISPONIVEL (NUM_REQ IN VARCHAR2); END; --------------------------------------------------------------------CREATE OR REPLACE PACKAGE BODY TRATA_REQ IS PROCEDURE RECEBE_REQUISICAO_MESSAGING IS a varchar2(100); begin a:=bd_req.ler_mensagem_aq('BD_STOCK'); dbms_output.put_line(a); end; PROCEDURE ENVIA_EMAIL_ITEM_DISPONIVEL (NUM_REQ IN VARCHAR2) IS conn UTL_SMTP.CONNECTION; crlf VARCHAR2( 2 ):= CHR( 13 ) || CHR( 10 ); mesg VARCHAR2( 1000 ); BEGIN conn:= utl_smtp.open_connection( 'emeasmtp.oracle.com', 25 ); utl_smtp.helo( conn, 'emeasmtp.oracle.com' ); utl_smtp.mail( conn, 'victor.martins@oracle.com' ); utl_smtp.rcpt( conn, 'victor.martins@oracle.com' ); mesg:= 'Date: ' || TO_CHAR( SYSDATE, 'dd Mon yy hh24:mi:ss' ) || crlf || 'From: APROVACAO DE REQUISICOES <victor.martins@oracle.com>' || crlf || 'Subject: ITEM REQUISITADO '||NUM_REQ||' DISPONIVEL' || crlf || 'To: victor.martins <victor.martins@oracle.com>' || crlf || 'Cc: victor.martins <victor.martins@oracle.com>' || crlf || '' || crlf || ' O item da requisicao '||NUM_REQ ||' esta disponivel e reservado em armazem. '|| crlf || '****************************************'; utl_smtp.data( conn, mesg ); utl_smtp.quit( conn ); END; end;
182
183
184
create or replace package BODY REQ_PLSQL as -- PROCEDIMENTO PARA INICIAR PROCESSO DE WORKFLOW COM PARAMETROS DA APLICAO FORMS. procedure INICIA_PROCESSO(NUM_REQ in varchar2, NOME_REQUISITANTE in varchar2, ID_REQUISITANTE IN VARCHAR2, SUPERIOR IN VARCHAR2, PROCESSO in varchar2 default null, Item_Type in varchar2 default null ) is ItemType varchar2(30) := nvl(Item_Type,'REQ_ITEM'); ItemKey varchar2(30) := NUM_REQ; begin wf_engine.CreateProcess( ItemType => ItemType, ItemKey => ItemKey, process => PROCESSO ); wf_engine.SetItemAttrText ( itemtype => itemtype, itemkey => itemkey, aname => 'NUM_REQ', avalue => NUM_REQ);
--
185
wf_engine.SetItemAttrText (
itemtype => itemtype, itemkey => itemkey, aname => 'NOME_REQUISITANTE', avalue => NOME_REQUISITANTE); itemtype => itemtype, itemkey => itemkey, aname => 'ID_REQUISITANTE', avalue => ID_REQUISITANTE); itemtype => itemtype, itemkey => itemkey, aname => 'SUPERIOR', avalue => SUPERIOR); itemtype => itemtype, itemkey => itemkey );
-wf_engine.SetItemAttrText (
-wf_engine.SetItemAttrText (
-- PROCEDIMENTO CHAMADO PELO WORKFLOW PARA VERIFICAR A REQUISIO E -- TRATA OS SEUS DADOS. procedure TRATA_REQ ( itemtype itemkey actid funcmode resultout in varchar2, in varchar2, in number, in varchar2, out varchar2)IS
tipo_item_v varchar2(10); id_funcionario_v varchar2(10); id_departamento_v varchar2(5); num_req_v varchar2(30); BEGIN if (funcmode = 'RUN') then num_req_v := wf_engine.GetItemAttrText(itemtype => itemtype, itemkey => itemkey, aname => 'NUM_REQ' ); select id_item, id_funcionario into tipo_item_v, id_funcionario_v from bd_req.requisicoes where num_req = num_req_v; select id_departamento into id_departamento_v from bd_rh.funcionarios where id_funcionario = id_funcionario_v;
186
-- rea de cdigo para validao de requisio com parmetros errados. Uma regra de negcio simples -- diz que quem pertence ao departamento de Vendas no pode requisitar computadores do tipo desktop.
if (tipo_item_v='1' and id_departamento_v='1' ) then -wf_engine.SetItemAttrText ( itemtype => itemtype, itemkey => itemkey, aname => 'OBSERVACOES', avalue => 'O Departamento de Vendas no pode requisitar este tipo de item.'); resultout := 'COMPLETE:F'; -else -resultout := 'COMPLETE:T'; -end if; end if; END TRATA_REQ; ------------------------------------------------------------------------------------------------------- PROCEDIMENTO QUE D INICIO FASE DE ENTREGA DO ITEM REQUISITADO, OU DADO INICIO FASE DE ENCOMENDA -----------------------------------------------------------------------------------------------------procedure DESPACHA_REQ ( itemkey actid funcmode resultout num_req_v varchar2(30); itemtype in varchar2, in varchar2, in number, in varchar2, out varchar2)IS
BEGIN -- Nesta fase feito o enqueue no AQ Messaging -num_req_v := wf_engine.GetItemAttrText(itemtype => itemtype, itemkey => itemkey, aname => 'NUM_REQ' ); bd_req.submeter_mensagem_aq (NUM_REQ_v,ID_ITEM,DATA,NOME_ITEM);
187
188
valor=rset.getString(1); rset.close(); stmt.close(); System.out.println ("Fecha conexo Aplicao RH."); conn.close(); System.out.println ("Envia valores para Forms."); } catch (Exception e) { System.out.println ("Erro."); e.printStackTrace(); } return(valor); } }
189
<variable name="Inserir_Requisicao_inserirRequisicao_OutputVariable" messageType="ns1:inserirRequisicao0Response"/> <variable name="Chama_Workflow_chamaWorkflow_InputVariable" messageType="ns2:chamaWorkflow0Request"/> <variable name="Chama_Workflow_chamaWorkflow_OutputVariable" messageType="ns2:chamaWorkflow0Response"/> </variables><!-============================================================= ==== --><!-- ORCHESTRATION LOGIC --><!-- Set of activities coordinating the flow of messages across the --><!-- services integrated within this business process --><!-============================================================= ==== --> <sequence name="main"><!-- Receive input from requestor. Note: This maps to operation defined in REQUISICOES_BPEL.wsdl --> <receive name="receiveInput" partnerLink="client" portType="client:REQUISICOES_BPEL" operation="process" variable="inputVariable" createInstance="yes"/><!-- Generate reply to synchronous request --> <assign name="Assign_1"> <copy> <from variable="inputVariable" part="payload" query="/client:REQUISICOES_BPELProcessRequest/client:NUM_REQ"/> <to variable="Inserir_Requisicao_inserirRequisicao_InputVariable" part="numReq"/> </copy> <copy> <from variable="inputVariable" part="payload" query="/client:REQUISICOES_BPELProcessRequest/client:ID_ITEM"/> <to variable="Inserir_Requisicao_inserirRequisicao_InputVariable" part="idItem"/> </copy> <copy> <from variable="inputVariable" part="payload" query="/client:REQUISICOES_BPELProcessRequest/client:ID_REQUISITANTE"/> <to variable="Inserir_Requisicao_inserirRequisicao_InputVariable" part="idRequisitante"/> </copy> <copy> <from variable="inputVariable" part="payload" query="/client:REQUISICOES_BPELProcessRequest/client:JUSTIFICACAO"/> <to variable="Inserir_Requisicao_inserirRequisicao_InputVariable" part="justificacao"/> </copy> </assign> <invoke name="Inserir_Requisicao" partnerLink="PartnerLink_Inserir_requisicao" portType="ns1:Inserir_requisicaoPortType" operation="inserirRequisicao" inputVariable="Inserir_Requisicao_inserirRequisicao_InputVariable" outputVariable="Inserir_Requisicao_inserirRequisicao_OutputVariable"/>
191
<assign name="Assign_2"> <copy> <from variable="inputVariable" part="payload" query="/client:REQUISICOES_BPELProcessRequest/client:NUM_REQ"/> <to variable="Chama_Workflow_chamaWorkflow_InputVariable" part="numReq"/> </copy> <copy> <from variable="inputVariable" part="payload" query="/client:REQUISICOES_BPELProcessRequest/client:ID_ITEM"/> <to variable="Chama_Workflow_chamaWorkflow_InputVariable" part="idItem"/> </copy> <copy> <from variable="inputVariable" part="payload" query="/client:REQUISICOES_BPELProcessRequest/client:ID_REQUISITANTE"/> <to variable="Chama_Workflow_chamaWorkflow_InputVariable" part="idRequisitante"/> </copy> <copy> <from variable="inputVariable" part="payload" query="/client:REQUISICOES_BPELProcessRequest/client:JUSTIFICACAO"/> <to variable="Chama_Workflow_chamaWorkflow_InputVariable" part="justificacao"/> </copy> <copy> <from variable="Inserir_Requisicao_inserirRequisicao_OutputVariable" part="return"/> <to variable="Chama_Workflow_chamaWorkflow_InputVariable" part="nomeRequisitante"/> </copy> </assign> <invoke name="Chama_Workflow" partnerLink="PartnerLink_Chama_workflow" portType="ns2:Chama_wf_wsPortType" operation="chamaWorkflow" inputVariable="Chama_Workflow_chamaWorkflow_InputVariable" outputVariable="Chama_Workflow_chamaWorkflow_OutputVariable"/> <assign name="Assign_3"> <copy> <from variable="Chama_Workflow_chamaWorkflow_OutputVariable" part="return"/> <tovariable="outputVariable" part="payload" query="/client:REQUISICOES_BPELProcessResponse/client:result"/> </copy> </assign> <reply name="replyOutput" partnerLink="client" portType="client:REQUISICOES_BPEL" operation="process" variable="outputVariable"/> </sequence> </process>
192
Referncias bibliogrficas
[ACS 2004] Australian Computer Society (ACS), Integration using EAI or Web services which is a better choice?, Australian Computer Society,
[Allen 2001] Allen, D., Don't Let EAI Tools Get in the Way of Good Design, http://www.eaiquadrant.com/str/allen_2.html, 2001.
[Alves 1995] Alves, M., A Reengenharia dos Processos de Negcio, Texto Editora, 1995.
[Arkhipenkov e Golubev 2001] Arkhipenkov, S. e D. Golubev, "Oracle Express OLAP", Charles River Media, 2001.
[Bernstein 1996] Bernstein, P., "Middleware: A Model for Distributed Services", Communications of the ACM, 1996.
[Bertino 1991] Bertino E., Integration of Heterogeneous Data Repositories by Using Object-Oriented Systems,1991. Views, Workshop on Interoperability in Multidatabase
[Birrell e Nelson 1984] Birrell, A.D. e Bruce J. Nelson, "Implementing Remote Procedure Calls", ACM Transactions on Computer Systems, 1984.
[BPMI 2002] BPMI, BPML|BPEL4WS: A Convergence Path toward a Standard BPM Stack, BPMI, http://www.bpmi.org/downloads/BPML-BPEL4WS.pdf, 2002.
[Brown 1996] Brown, A., "Preface: Foundations for Component-Based Software Engineering", IEEE Computer Society Press, http://media.wiley.com/
product_data/excerpt/8X/08186771/081867718X-1.pdf, 1996.
193
[Bussler 2003] Bussler, C., B2B Integration: Concepts and Architecture, Spinger, 2003.
[Carnegie 1997] Carnegie Mellon Software Engineering Institute (SEI), Software Technology Roadmap, Carnegie Mellon SEI, http://www.sei.cmu.edu/str/versions /str.7.28.97.pdf, 1997.
[Carroll 2000] Carroll, J., The Economics of Integration, Integrated Design Inc., http://www.eaiindustry.org/docs/TheEconomicsOfIntegration.pdf, 2000.
[Carvalho 2001] Carvalho, J.M., e-Business & e-Commerce: On & Offline, Edies Slabo, 2001
[Chartier 2004] Chartier R., "Application Architecture: An N-Tier Approach", http://www.15seconds.com/issue/011023.htm, 2004.
[Chase 2000] Chase P., The Seven Hidden Challenges of Application Integration, http://oracle.ittoolbox.com/, Scribe Software Corporation, 2000.
[Cherry 2000] Cherry Tree & Co., Extended Enterprise Applications: Spotlight Report, http://www.cherrytreeco.com, 2000.
[Chopra e Meindl 2000] Chopra, S. e P. Meindl, Supply Chain Management: Strategy, Planning and Operations, Prentice Hall, 2000.
[Claybrook 1992] Claybrook, B., OLTP: Online Transaction Processing Systems, John Wiley & Sons, 1992.
[COM 1998] Stearns D., COM: Component Object Model Technologies, Microsoft Corporation, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomg /html/msdn_basicpmd.asp, 1998.
194
[Coulouris et al. 2000] Coulouris, G., Dollimore, J., Kindberg, T., Distributed Systems: Concepts and Design (3rd Edition), Addison Wesley, 2000.
[Craggs 2003] Craggs, S., Raising EAI Standards, Saint Consulting Limited, http://www.eaiindustry.org /docs/Raising%20EAI%20standards.pdf, 2003.
[CSC 2002] Computer Sciences Corporation (CSC), The Emergence of Business Process Management, CSC, http://www.ebizq.net/hot_topics/bpm/features
/1763.html, 2002.
[CSC 2003] Computer Sciences Corporation (CSC), The Architecture rEvolution: Exploring the Network Effect on Infrastructure, Applications and Business Process, http://www.csc.com/aboutus/lef/uploads /LEF_ARCHREV.pdf, 2003.
[Date 2003] Date, C.J., An Introduction do Database Systems (Eighth edition), Addison-Wesley Publishing Company, 2003.
[Deplhi 2002] Delphi Group, Perspectives on Information Retrieval 2002, http://www.delphigroup.com/research/ir_perspectives_sum.pdf, 2002.
[Horstman e Kirtland 1997] Horstmann, M. e M. Kirtland, DCOM: Distributed Component Object Model, Microsoft Corporation, http://msdn.microsoft.com /library/default.asp?url=/library/en-us/dndcom/html/msdn_dcomarch.asp, 1997.
[Delphi 2002] Delphi Group (DG), BPM2002 Market Milestone Report, DG, http://www.delphigroup.com/coverage/bpm_webservices.htm, 2002.
[Dickman 1995] Dickman, A., "Two-Tier Versus Three-Tier Apps", Informationweek 553, http://www.informationweek.com/553/53olapp.htm , 1995.
[Dubray 2003] Dubray, J., Business Process Engines in Application Architecture, Attachmate, http://www.ebpml.org/technoforum_2003_b_eng.ppt, 2003.
195
[Earl 1989] Earl, M.J.,Management Strategies for Information Technology, Prentice-Hall, 1989.
[Eckerson 1995] Eckerson, W., "Three Tier Client/Server Architecture: Achieving Scalability, Performance, and Efficiency in Client Server Applications", Open Information Systems, 1995.
[Edelstein
1994]
Edelstein,
H.,
"Unraveling
Client/Server
Architecture",
[Edwards e Newing 2000] Edwards, P. e R. Newing, Application Integration for eBusiness Strategies for integrating key applications, systems and processes, Optima Media 2000. Group, http://www.business-intelligence.co.uk/reports/app_int/default.asp,
[Fischer 2003] Fischer, L., Workflow Handbook 2003 10Th year anniversary edition, http://www.wfmc.org, WFMC, 2003.
[Georgakopoulos et al. 1995] Georgakopoulos D., H. Hornick e A. Sheth, An overview of workflow management: From process modeling to infrastructure for automation, Distributed and Parallel Databases Journal, 1995.
[Gunter 1995] Gunter, D., Client/Server Programming With RPC and DCE, QUE, 1995.
[Hepper 2003] Hepper S. e S. Hesmer, Introducing the Portlet Specification, JavaWorld, 2003. http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-portlet.html,
[Hines 1996] Hines, John R., "Software Engineering", IEEE Spectrum, 1996.
[Hollingsworth 2004] Hollingsworth D., The Workflow Reference Model 10 Years, WfMC, http://www.wfmc.org/standards/docs/Ref_Model_10_years_on_Hollings
[Hohpe et al. 2003] Hohpe G. e B. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Addison Wesley, 2003.
[Houston 1998] Houston, P., Building Distributed Applications with Message Queuing Middleware, Microsoft Corporation, http://msdn.microsoft.com
/library/default.asp?url=/library/en-us/dnmqqc/html/bldappmq.asp, 1998.
[Hudson e Johnson 1994] Hudson, D. e J. Johnson, Client-Server Goes Business Critical. Dennis, MA: The Standish Group International, 1994.
[IEEE 1990] Institute of Electrical and Electronics Engineers, IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, 1990.
[Integr8
2005]
Integr8
Consulting,
Services:
Styles
of
Integration,
http://www.integr8consulting.com, 2005.
[Jenkins et al. 2004] Jenkins, T., D. Glazer e H. Schaper, Enterprise Content Management Technology: What You Need to Know, Open Text Corporation, 2004.
[Kelly
2003]
Kelly,
D.,
Core
to
your
Business,
Oracle
Magazine,
[Kenneth e Laudon 2003] Kenneth C. e Jane P. Laudon, Management Information Systems Eighth Edition, Prentice Hall, 2003
[Kochar 2005] Kochar, H., Oracle Business Activity Monitoring, Oracle Corporation, http://www.oracle.com/technology/products/integration/bam/pdf/BAM
Whitepaper.pdf, 2005.
[Levine 2005] Levine, R., EAI Roads to Riches, Business Integration Journal, http://www.bijonline.com/PDF /levine%20july-aug.pdf, 2005.
197
[Lewis 2000] Lewis, R. 2000, Advanced Messaging Applications with MSMQ and MQSERIES, Que Professional, 2000.
[Lopes e Ramalho 2005] Lopes, C. e J. Ramalho, Web Services Aplicaes Distribudas sobre Protocolos Internet, 2005
[Magic 2003] Magic Software, The Business of Process Integration, Magic Software, http://www.ebizq.net/white_papers/3237.html, 2003.
[McKie 2003] McKie, S., The Big BAM, Intelligent Enterprise Magazine (IEM), http://www.intelligententerprise.com/030718/612feat3_1.jhtml?_requestid=457248, 2003.
[Miers 2005] Miers D., BPMToo Much BP, Not Enough of the M, WFMC, http://www.wfmc.org/information/Miers_too_%20much_BP.pdf, 2005.
[Morgenthal 2005] Morgenthal, J., Enterprise Information Integration: A Pragmatic Approach, Lulu Press, 2005.
[Newcomer e Lomow 2004] Newcomer, E. e G. Lomow, Addison-Wesley Professional, Understanding Soa With Web Services, 2004.
[Open
1997]
Open
Group,
CDE
1.1:
Remote
Procedure
Call,
[Papakonstantinou et al.1995] Papakonstantinou Y., H. Garcia-Molina e J. Widom, Object Exchange Across Heterogeneous Information Sources, IEEE International Conference on Data Engineering (ICDE), 1995.
[Pereira 1998] Pereira, Jos Luis, Tecnologia de bases de dados, FCA, 1998.
198
[Plesums
2002]
Plesums,
C.,
Introduction
to
Workflow,
WFMC,
http://www.wfmc.org/information/introduction_to_workflow02.pdf, 2002.
[Ramalho e Henriques 2002] Ramalho, J. e P. Henriques, XML & XSL da teoria prtica, FCA, 2002.
[Rao 1995] Rao, B., Data Communications International, "Making the Most of Middleware", 1995.
[Reynolds 2002] Reynolds, J., A Practical Guide to CRM., CMP Books, 2002.
[Serain 2002] Serain, D., Middleware and Enterprise Application Integration., Springer, 2002.
[Schmidt 2000] Schmidt, J., Enabling Next-Generation Enterprises, Business Integration Journal, http://www.bijonline.com/Article.asp?ArticleID=48, 2000.
[Schreiber 1995] Schreiber, R., "Middleware Demystified", Cahners Publishing Company, 1995
[Schussel
1996]
Schussel,
G.,
Client/Server
Past,
Present
and
Future
http://news.dci.com/geos/dbsejava.htm, 1996.
[Serrano e Fialho 2003] Serrano, A. e C. Fialho, Gesto do Conhecimento: o novo paradigma das organizaes, FCA, 2003.
[Spiers 2005] Spiers, J., Ten Ways to Sabotage Your Application Integration Effort, http://www.eaiindustry.org/docs/TenWaystoSabotageYourApplication.pdf, 2005.
[Steinke 1995] Steinke, S., Middleware Meets the Network., LAN The Network Solutions Magazine, 1995
199
[Summer 2004] Summer, M., Enterprise Resource Planning., Prentice Hall, 2004
[Thalheim 2000] Thalheim, B., Entity-Relationship Modeling: Foundations of Database Technology, Springer, 2000.
[Trauth 1989] Trauth, E.M., The Evolution of Information Resource Management., Information & Management, 1989.
[Ullman 1997] Ullman, J.D., Information integration using logical views, International Conference on Database Theory (ICDT) vol. 1186, 1997.
[Ulrich 2002] Ulrich, W., Synchronize EAI with Tactical and Strategic initiatives, http://www.eaiindustry.org/docs/SynchronizeEAIwithTacticalandStrategic.pdf, 2002
[Vitt et al 2002] Vitt, E., M. Luckevich e S. Misner, Business Intelligence, Microsoft Press, 2002.
[Watt 2002] Watt, D, E-Business Implementation: a guide to web services, EAI, BPI, e-commerce, content management, portals and supporting technologies, Butterworth Heinemann, 2002
[Westphal e Blaxton 1998] Westphal, C. e T. Blaxton, "Data Mining Solutions: Methods and Tools for Solving Real-World Problems", Wiley, 1998.
[William et al. 2000] William, R., M. Francis e B. Wiliam, Enterprise Application Integration: A Wiley Tech Brief, John Wiley & Sons, 2000.
[Wollrath e Waldo 2005] Wollrath A. e J. Waldo, An overview of RMI applications., Sun Developer Network, http://java.sun.com/docs/books/tutorial /rmi/overview.html, 2005.
[Wong 2001] Wong, S., Web Services: The Next Evolution of Application Integration, Integration Consortium, http://www.eaiindustry.org/docs
[Woods 2003] Woods, D., Packaged Composite Applications: An O'Reilly Field Guide to Enterprise Software, O'Reilly, 2003.
[Wrazen 2000] Wrazen, E., EAI Tools are not the Complete Solution, http://www.xephon.com/islibrary/islibrary.php?todo=eq.5.000100&subject=2, 2000.
[W3C 2004] W3C, Web Services Choreography Description Language Version 1.0, W3C, http://www.w3.org/TR/ws-cdl-10,2004.
[Yee 2001] Yee A., Integrating Your e-Business Enterprise, SAMS, 2001.
[Zahavi 1999] Zahavi, R., Entreprise Application Integration with CORBA, John Wiley & Sons, 1999.
201