Resumo Palavras-Chave:

Tamanho: px
Começar a partir da página:

Download "Resumo Palavras-Chave:"

Transcrição

1 Agradecimentos Expresso a minha gratidão ao Professor Doutor José Alves Marques, pela sua orientação ao longo deste trabalho e por ter possibilitado o desenvolvimento da dissertação no âmbito de um projecto realizado pela unidade TSU (Telcos, Saúde e Utilities) pertencente à Link Consulting. Agradeço o total apoio dos meus colegas de unidade no decorrer de todo o trabalho desenvolvido na Link Consulting. Agradeço particularmente a total disponibilidade e a partilha constante de conhecimento através das indicações fornecidas e do esclarecimento de dúvidas por parte dos Analistas Bruno Barreiros e José Robalo e do Consultor Senior responsável pelo projecto, Engenheiro Pedro Pires. Além de todos os conselhos técnicos, agradeço também ao Coordenador da Unidade, Engenheiro Nuno Silveira, o facto de ter feito com que a integração inicial na equipa e na unidade a que pertenci tivesse sido o mais natural possível. Por fim, um muito obrigado pelo excelente ambiente em que pude trabalhar, fruto de uma unidade composta por pessoas tão competentes e simpáticas. Aproveito também para agradecer à minha namorada Ana Lusquiños toda a paciência, compreensão e sobretudo, todos os momentos em que me transmitiu a força e perseverança necessárias à conclusão deste trabalho. Um muito obrigado a todos os meus colegas de curso, nomeadamente ao Ricardo Reis, Tagore Dinis, João Maurício, Luís Liberado, Ricardo Carapeto, Nuno Almeida, André Ferreira, Raul Mesquita, Jorge Fernandes e David Cunha por terem personificado, durante estes cinco anos de curso agora concluídos e durante o desenvolvimento desta dissertação, toda a diversão, boa disposição e amizade necessárias ao longo de um percurso académico. Esta é também uma óptima oportunidade para expressar o meu respeito e profunda amizade pelos meus amigos de sempre, Filipe Macedo, Pedro Dias, Rui Parente, João Miranda, Miguel Maria, e todos os outros que me brindam todos os dias com a sua amizade absoluta e sincera e que foram responsáveis por grande parte do equilíbrio saudável entre o desenvolvimento da dissertação e os momentos de lazer, fundamental na conclusão deste trabalho. Finalmente e não em último lugar, gostaria de agradecer e expressar à minha família todo o amor que me é dado e que retribuo sem qualquer espécie de reserva e todo o apoio que incessantemente me foi e é dado. Sem a minha família, nunca teria chegado onde cheguei e mais importante ainda, nunca teria percorrido este caminho da forma correcta e regida pelos princípios que toda a vida me foram transmitidos. Obrigado! i

2 Resumo A perda ou tratamento incorrecto da bagagem nos aeroportos tem vindo a aumentar actualmente, aumentando com isso os custos associados a este tipo de situações. Esta tese propõe, no âmbito de um projecto realizado pela Link Consulting, um sistema capaz de melhorar todo o processo de tratamento de bagagens através da monitorização em tempo-real das malas processadas. Pretende-se que a monitorização constante do processo detecte atempadamente eventuais erros no processo de tratamento, permitindo assim uma acção proactiva na correcção destas situações. Isto melhorará significativamente a performance dos sistemas de tratamento de bagagens actuais, reduzindo consequentemente os custos associados. Foram estudados os seguintes temas: os standards praticados na indústria aeroportuária; a tecnologia RFID utilizada na detecção das malas; a teoria que fundamenta o processamento de eventos; alguns protótipos de sistemas de monitorização semelhantes; e o conjunto de ferramentas Oracle utilizadas na implementação do sistema. A arquitectura apresentada contempla os vários requisitos previamente definidos, tendo sido descrito o modo de funcionamento de cada uma das componentes que a compõem. Por fim, foram explicados os vários procedimentos utilizados para garantir a correcção do sistema desenvolvido, entre os quais a simulação de cenários, utilizados para verificar o correcto funcionamento de cada componente isoladamente e da solução como um todo. Foi criado um protótipo totalmente funcional que concretiza a arquitectura proposta: realiza o processamento dos dados resultantes da detecção das malas; apresenta a informação em tempo-real através de relatórios; armazena permanentemente a informação resultante da monitorização e permite também a consulta do histórico da monitorização através de uma aplicação Web. Este sistema inova no sentido em que permite a monitorização individual de cada uma das malas processadas, uma vez que obtém a informação através da leitura de etiquetas colocadas em cada mala. Isto permite que a monitorização apresente uma grande granularidade, podendo ser detectadas situações de excepção relativas apenas a uma única mala, o que diminui a latência da resposta a este tipo de situações e consequentemente permite que estas ocorrências sejam corrigidas antes que se tornem em erros visíveis para o passageiro. Como o sistema também possibilita que os passageiros possam aceder a informação sobre o estado das suas malas, através do uso da aplicação interface presente no sistema desenvolvido, diminui-se assim o sentimento de insegurança dos passageiros em relação ao processo de tratamento das bagagens em aeroportos. Palavras-Chave: Sistema de monitorização de bagagens, processo de tratamento de bagagens, processamento de eventos em tempo-real, tecnologia RFID, monitorização de bagagens flexível ii

3 Abstract The loss or mishandling of luggage in airports is increasing nowadays, tremendously raising its associated costs. This thesis proposes, within the scope of a project done by Link Consulting, a system capable of improving the whole baggage handling process, by monitoring the processed luggage in real-time. It's expected that the constant monitoring detects possible errors in a timely manner, allowing a proactive attitude when correcting this kind of situations. This will increase the performance of the currently used baggage handling systems and therefore will reduce their associated costs. The following themes were studied: the standards used in the airport industry; the RFID technology used in the luggage detection; the theory that supports event processing; prototypes of similar monitoring systems; and the Oracle tools used in the system development. The presented system architecture has in concern the previously defined requirements and describes the operating mode of each component. In the end, several procedures used to guarantee the system correctness were explained, including the simulation of real scenarios, used to verify the correct behavior of each component and to guarantee the correct interaction between components. A totally functional prototype that implements the proposed architecture was developed: it processes the data that results from the luggage detection; it presents real-time information reports; it stores permanently the information that results from luggage monitoring and it also allows the access to historic tracking information using a Web application. This system increases the monitoring detail when compared to current monitoring systems because it allows the individual tracking of each processed bag, since the information used is obtained by reading the tag placed in each bag. Therefore, system granularity is increased and it's possible to detect exceptional situations happening only to a single bag. This reduces the reaction latency on this kind of situations, allowing smaller correction times that avoid passengers being early informed about the mishandling of their luggage. The system also enables passengers access to real-time information about their luggage by using an interface Web application included in the developed system, reducing passengers uncertainty about the baggage handling process. Keywords: Baggage tracking system, baggage handling process, real-time event processing, RFID technology, flexible baggage monitoring iii

4 Índice 1. Introdução Descrição do Problema Objectivos Solução Desenvolvida Contribuição e Resultados Atingidos Organização da Dissertação Trabalho Relacionado Soluções Comerciais Processo de Tratamento de Bagagens Standards e Práticas Recomendadas Baggage Information Messages License Plate Number Tecnologia RFID Electronic Product Code EPCglobal Architecture Framework Tratamento de Eventos Requisitos do Processamento de Eventos em Tempo-Real Sistemas de Processamento de Eventos em Tempo-Real Oracle Complex Event Processing Sistemas Semelhantes Oracle Business Activity Monitoring Síntese Arquitectura da Solução Principais Componentes Principais Requisitos Síntese Descrição da Solução Tratamento de Eventos iv

5 Principais Conceitos Eventos Utilizados Descrição do Modo de Processamento Modelo de Domínio Indicadores de Negócio Aplicação Interface Enterprise Service Bus Descrição do Modo de Funcionamento Repositório de Eventos Síntese Avaliação Experimental Testes de Desenvolvimento Testes Unitários Testes de Integração Simulação do Sistema Teste da Componente de Tratamento de Eventos Teste da Componente de Indicadores de Negócio Avaliação Qualitativa Síntese Conclusões e Trabalho Futuro Conclusões Finais e Contribuições Trabalho Futuro Referências 90 Anexo A Resumo dos Campos das Information Messages 93 Anexo B Campos Disponíveis para Armazenamento de Informação numa Tag 94 Anexo C Topologia do Sistema de Monitorização Implementado no Aeroporto de Pequim 95 Anexo D Event Processing Network da Solução 96 Anexo E Hierarquia de Eventos da Solução 98 Anexo F Modelo de Domínio da Solução 99 v

6 Anexo G Modelo Entidade-Relação da Base de Dados 100 Anexo H Exemplos de Relatórios da Componente de Indicadores de Negócio 101 Anexo I Mensagens Utilizadas no Simulador de Eventos 103 Anexo J Resultados obtidos no benchmark do Oracle CEP 105 vi

7 Lista de Figuras Fig Origens dos erros no tratamento das bagagens (adaptado de [1]) 2 Fig Esquema representativo de um processo de tratamento de bagagens [6]. 9 Fig Entrada de um encaminhador primário, com leitores de códigos de barras para identificação das malas. 11 Fig Exemplo esquemático de um sistema de encaminhamento de bagagens (adaptado de [6]). 12 Fig Visão geral da framework arquitectural proposta pela EPCglobal. 20 Fig Processamento da stream enquanto os dados fluem, com armazenamento opcional. 22 Fig Sistema de processamento de streams, com uma base de dados embebida neste. 24 Fig Conceitos e operadores nos quais se baseia a semântica abstracta implementada pela CQL (adaptado de [15]). 27 Fig Exemplo de query composta por diferentes tipos de operadores. Cada nó da árvore corresponde a um operador, sendo a cor que define o seu tipo. As relações que servem de input ou output são identificadas por R a j e as streams de input ou output são identificadas por S a..d. 28 Fig Composição de um plano de query composto por operadores, queues e sinopses. 31 Fig Arquitectura do EPC Sensor Network. 32 Fig Arquitectura da plataforma Complex Event Processing da Oracle, adaptado de [25]. 34 Fig Fluxo de dados típico de uma aplicação assente na plataforma Complex Event Processing da Oracle. 35 Fig Arquitectura proposta pela Oracle no âmbito do tratamento de bagagens num aeroporto. 36 Fig Arquitectura proposta por Ting et al. para um sistema de monitorização de bagagens distribuído (adaptado de [29]). 37 Fig Procedimento de localização de uma mala (adaptado de [29]). 39 Fig Colocação dos leitores RFID ao longo do processo de encaminhamento das bagagens. 40 Fig Diagrama arquitectural do Oracle Business Activity Monitoring. 41 Fig Diagrama arquitectural da solução. 46 Fig Principais componentes de uma aplicação orientada a eventos [36]. 53 Fig Representações gráficas dos elementos de uma EPN Processador, Canal, Stream, Adaptador, Bean, Event Bean e Cache. 55 Fig Parte da EPN responsável pelo processamento de eventos provenientes do SGO. 58 Fig Elementos da EPN que participam na monitorização das malas (adaptado do Anexo D). 61 Fig Detalhe dos elementos da EPN envolvidos na monitorização dos tempos das malas em cada segmento. 64 Fig Classes de domínio Baggage e Flight e respectivos campos. 65 Fig Configuração do plano BaggageMessage Plan no Plan Monitor. 66 Fig Plano BaggageMessage Plan que executa a manipulação da informação proveniente das mensagens enviadas pela CTE para que possa ser apresentada pela CIN. 67 Fig Relatório de Operação de um voo de partida. 68 vii

8 Fig Exemplo de informação apresentada pela aplicação interface sobre a localização de uma mala. 70 Fig Composição da componente Enterprise Service Bus da solução. 72 Fig Diagrama da aplicação de mercados de capitais utilizada no benchmark do Oracle CEP. 80 Fig Latência média obtida por número de ligações simultâneas (primeira sessão de testes). 81 Fig Latência máxima absoluta por número de ligações simultâneas (primeira sessão de testes).81 Fig Latência média por frequência de injecção de eventos (segunda sessão de testes). 82 Fig Latência máxima por frequência de injecção de eventos (segunda sessão de testes). 82 Fig Latência medida durante 10 minutos de emissão de eventos com um tempo de espera entre eventos de 1 segundo. 83 Fig Requisitos não-funcionais e a forma como estes foram cumpridos. 85 viii

9 Lista de Tabelas Tabela 2.1. Conteúdo de uma Baggage Transfer Message. 14 Tabela 2.2. Composição e interpretação dos campos de um License Plate Number. 16 Tabela 2.3. Campos de um Electronic Product Code SGTIN-96 (adaptado de [14]). 19 Tabela 2.4. Comparação do RFID Com códigos de barras no contexto do tratamento de bagagens. 40 Tabela 3.1. Tabela de requisitos não-funcionais que o sistema desenvolvido deve cumprir. 49 Tabela 3.2. Critérios de validação dos vários requisitos não-funcionais definidos para a arquitectura apresentada. 50 Tabela 3.3. Resumo dos componentes da arquitectura da solução. 51 Tabela 4.1. Exemplo de uma mensagem XML vinda do SGO que representa a partida de um avião. 58 Tabela 4.2. Mensagens XML enviadas para a componente de indicadores de negócio. 60 ix

10 Lista de Acrónimos/Abreviaturas ADC AI ALE ARE BAM BIM BIP BPM/BPEL BSM CEP CIN CQL CTE DAO DCS DSMS EDA EPC EPL EPN ERP ESB ESN GIS GORM GSP IATA IS ISM JDBC JMS JSP JVM LPN LTWS MVC POJO RE Active Data Cache Aplicação Interface Application Level Events Active Reports Engine Business Activity Monitoring Baggage Information Messages Baggage Improvement Programme Business Process Management/Business Process Execution Language Baggage Source Message Complex Event Processing Componente de Indicadores de Negócio Continuous Query Language Componente de Tratamento de Eventos Data Access Object Departure Control System Data Stream Management System Event-Driven Architecture Electronic Product Code Event Processing Language Event Processing Network Enterprise Resource Planning Enterprise Service Bus EPC Sensor Network Geographic Information System Grails Object Relational Mapping Groovy Server Pages International Air Transport Association Information Service Information Service Manager Java Database Connectivity Java Message Service Java Server Pages Java Virtual Machine License Plate Number Location Tracking Web Service Model View Controller Plain Old Java Object Repositório de Eventos x

11 RFID RNF SE SGBD SGTIN SLA SOA SOAP STREAM TSU UDDI WSDL XE Radio Frequency Identification Requisito Não-Funcional Simulador de Eventos Sistema de Gestão de Bases de Dados Serialized Global Trade Item Number Service Level Agreement Service-Oriented Architecture Simple Object Access Protocol Ver DSMS Telcos, Saúde e Utilities Universal Description Discovery and Integration Web Services Description Language Express Edition xi

12 You ve got to be careful if you don t know where you re going, cause you might not get there. Yogi Berra xii

13 1. Introdução O tratamento da bagagem nos aeroportos está relacionado com factores de complexidade e incerteza na perspectiva da maior parte dos passageiros, tais como muitos outros aspectos relacionados com o tráfego aéreo. Muitos passageiros, mais ou menos frequentemente, sentiram um momento de incerteza quando viram a sua bagagem desaparecer atrás das cortinas, nos balcões de check-in. O cliente abstrai-se de toda a complexidade inerente ao processo de tratamento de bagagens, vendo-o como uma caixa preta que, se tudo correr bem, fornecerá como output a bagagem que entrou outrora no sistema. Poucos imaginam o quão complexo e propenso a erros é todo o sistema que permite que a bagagem seja encaminhada desde o aeroporto em que o passageiro embarca até ao destino final, quando a sua mala sai no carrossel respectivo. A bagagem que por algum motivo se perde no decorrer deste processo, apesar de ser uma pequena percentagem da totalidade da bagagem tratada, continua a ser uma das principais preocupações para os passageiros aéreos. Acresce ainda o facto de o problema ter vindo a complicar-se de ano para ano, devido ao aumento do número de passageiros aéreos (e consequente congestão dos aeroportos) e do recente reforço das medidas de segurança a que toda a bagagem tem de ser sujeita, o que se tem traduzido num custo anual de 3,8 mil milhões de dólares para a indústria [1]. Como reacção a este problema, a IATA (International Air Transport Association) apresentou um conjunto de medidas, o Baggage Improvement Programme (BIP), que visa minimizar o problema das malas perdidas ou atrasadas. As medidas propostas inserem-se em diferentes abordagens, e vão desde a formação complementar do pessoal envolvido no processo de tratamento de bagagem até à melhoria do processo de leitura dos códigos de barras que identificam cada mala, passando pela integração dos sistemas responsáveis pelo controlo de partidas e pelo tratamento da bagagem que assim partilharão informação relevante. Esta dissertação foi desenvolvida no âmbito da empresa Link Consulting, estando a solução aqui presente inserida num projecto em estudo para uma entidade de gestão aeroportuária no contexto do tratamento e processamento de bagagens. Este projecto é desenvolvido por diferentes unidades que compõem a empresa, tendo esta dissertação sido inserida na unidade TSU Telcos, Saúde e Utilities. O tema principal desta dissertação está inserido no contexto anteriormente descrito e prendese com a definição precisa do problema da monitorização e localização de bagagens num aeroporto e na proposta de uma solução que resolva da melhor forma possível o problema encontrado. Para tal, nas secções que se seguem será descrito todo o trabalho realizado durante o desenvolvimento da tese, desde a fase de análise do trabalho relacionado com o tema em questão até ao desenho, implementação e testes da solução proposta. 1

14 1.1. Descrição do Problema Um dos principais problemas ao qual o BIP pretende responder é a falta de confiança que os passageiros mostram em relação ao processo de tratamento de bagagens, que deveria ser encarado como se de outro qualquer serviço se tratasse. Grande parte desta falta de confiança parte do facto de todo o processo de tratamento das malas ser desconhecido para os passageiros, visto que estes não têm acesso a qualquer informação sobre o estado das suas malas durante todo o percurso que estas percorrem. Do ponto de vista do sistema de tratamento de bagagens em si, grande parte dos erros no processo são devido a: erros no processo de transferência das malas entre aviões quando estes fazem escala (49%), atrasos no encaminhamento das malas que depois faz com que estas não embarquem no avião (16%), erros no tratamento das bagagens no aeroporto de destino (8%) ou erros no carregamento/descarregamento das malas para/do avião (5%) (cf. Fig. 1.1). Fig Origens dos erros no tratamento das bagagens (adaptado de [1]) Tanto a desconfiança por parte dos passageiros em relação ao processo de tratamento de bagagens como as consequências dos erros que possam surgir neste processo poderiam ser minimizadas (idealmente, eliminadas) se existisse um sistema que permitisse: - Ao passageiro, acompanhar todo o percurso das suas bagagens, acedendo para esse efeito a uma aplicação através de uma interface Web ou então subscrevendo um serviço que lhe permitisse receber informação relevante sobre o estado das suas malas em determinados pontos do processo de tratamento a que estas são sujeitas (quando a mala entrasse no avião, o passageiro recebia uma mensagem escrita informando-o desse acontecimento, por exemplo); - Aos responsáveis pelo processo de tratamento de bagagens, saber a cada momento do processo em que segmento do percurso é que as malas estão, para que se porventura estas não fossem recebidas onde seria esperado, fosse despoletado um alerta em tempo útil, permitindo assim que houvesse uma reacção atempada a um 2

15 possível erro no processo de tratamento das malas. Se por alguma razão for necessário localizar determinada mala para que esta seja reintroduzida no processo de tratamento ou seja reencaminhada (devido ao passageiro afinal não ter embarcado no avião ou devido a ter partido noutro voo que não o previsto, por exemplo), é muito importante que existam mecanismos que permitam localizar a mala de uma forma imediata e com uma precisão suficiente para que a procura da mala se restrinja a um espaço bem definido do aeroporto, fazendo com que essa procura seja muito mais rápida e eficiente. Actualmente, os sistemas disponíveis não permitem acompanhar com a precisão desejada todo o percurso de uma mala específica, desde que esta entra no check-in, passando pelos vários segmentos e zonas de espera, até que por fim embarque no avião. Isto deve-se, em parte, ao facto do uso dos códigos de barras como meio de identificação das malas ainda ser o método mais utilizado, que não permite uma taxa de leitura muito elevada quando comparado com outros métodos e que muitas das vezes exige a intervenção humana no processo de identificação, não permitindo a automatização total da monitorização das bagagens. Por outro lado, a monitorização efectuada actualmente contempla o processo de tratamento de bagagens como se este se tratasse de uma caixa preta, em que não é possível obter informação detalhada em cada ponto intermédio do processo (nalguns casos, apenas existe informação estatística resultante da contagem do número de malas processadas). Posto isto, o problema que se pretende solucionar é o da falta de informação precisa e em tempo útil sobre a localização e estado das bagagens durante o período de tempo em que estas se encontram dentro do sistema de tratamento de bagagens e na totalidade do percurso que estas percorrem Objectivos O propósito desta dissertação será dar resposta ao problema descrito anteriormente e passará pela criação de um sistema de monitorização que apresente indicadores de desempenho do negócio com informação relevante sobre todo o processo de tratamento das bagagens e que permita saber a localização de uma mala que se encontre em qualquer segmento do processo de tratamento de bagagens, desde que esta entra no processo até dar entrada no respectivo avião. Será possível, usando o sistema desenvolvido, saber em qualquer momento a localização de uma mala específica, em que estado do processo é que esta se encontra, a que voo está associada, qual o percurso que lhe foi atribuído e quais foram os segmentos que de facto já percorreu, quais os alertas despoletados e que de alguma forma estão relacionados com a mala em questão ou quais as malas que embarcaram em determinado voo. Usando a informação resultante da monitorização constante da localização das malas, serão fornecidos vários indicadores de desempenho do processo: tempo médio que uma mala demora desde que entra no check-in até ao seu embarque no avião; número de malas encaminhadas por unidade de tempo; tempo médio que demora a correcção de uma situação de excepção (mala 3

16 detectada num segmento que não pertence ao percurso que lhe foi atribuído, mala demorou mais do que o esperado num certo segmento, etc.); tempo médio que demora uma mala a percorrer um certo segmento; número de malas correctamente embarcadas, não embarcadas, descarregadas e perdidas; tempo de descarregamento de um avião (tempo desde a saída da primeira mala do avião até à chegada da última mala ao tapete de entrega das malas) e tempo desde a colocação dos calços até à primeira entrega. Serão também detectadas pelo sistema as seguintes ocorrências: bagagem que embarca em determinado avião sem estar associada a nenhum voo, bagagem que entra num avião que não é o suposto, bagagem que devia entrar num avião e este parte sem esta ter embarcado, mala que era esperada à saída do avião e que não chegou. Estes indicadores e avisos de ocorrências trarão informação valiosa que poderá ser usada quer na resolução de eventuais problemas que surjam com as malas, quer na melhoria do processo de tratamento das malas através da identificação de eventuais bottlenecks. Os objectivos da dissertação passam assim primeiramente por compreender todo o sistema de tratamento de bagagens no contexto de um aeroporto para permitir posteriormente a implementação da solução que possibilitará a localização das bagagens no decorrer de todo o processo ao qual estas são sujeitas. Isto implica a identificação dos requisitos do sistema e de elementos-chave comuns a todos os sistemas de tratamento de bagagens, independentemente do aeroporto. Serão também estudados os seguintes elementos: trabalhos desenvolvidos no contexto da localização de objectos; standards e práticas que regem o sector dos transportes aéreos; sistemas que especificam o uso do RFID e de como devem ser tratados os dados que resultam do uso desta tecnologia e soluções disponíveis comercialmente que permitem tratar eficientemente a enorme quantidade de informação resultante da monitorização constante de objectos. Depois de bem definido o problema, passar-se-á ao desenho da arquitectura do sistema e ao desenvolvimento da aplicação que concretizará os vários objectivos aqui definidos. O desenvolvimento será feito usando tecnologia da Oracle, nomeadamente o Oracle Complex Event Processor (CEP), o Oracle Business Activity Monitoring (BAM), o Oracle Enterprise Service Bus (ESB) e a Oracle Database 10g Express Edition (XE) e tecnologia open-source, nomeadamente a Framework Grails, criada para o desenvolvimento de aplicações Web. A componente de processamento dos eventos resultantes da monitorização das malas será desenvolvida recorrendo ao CEP, enquanto a elaboração dos indicadores de negócio que farão parte dos dashboards a mostrar aos responsáveis pelo processo de tratamento das malas será implementado usando o BAM; a componente que permitirá a comunicação entre os diferentes componentes que farão parte do sistema basear-se-á no ESB enquanto a aplicação interface com que os utilizadores interagirão será uma aplicação Web desenvolvida usando a Framework Grails e permitirá o acesso a informação detalhada sobre a localização das bagagens. A informação que resultará da monitorização das bagagens será armazenada num repositório de eventos que consistirá numa base de dados Oracle e será esta componente que será consultada pela aplicação interface. 4

17 Por fim, o protótipo desenvolvido passará por uma série de testes para garantir que o sistema corresponde aos requisitos que se identificaram e que é uma solução viável para o problema da localização de bagagens no contexto de um aeroporto. Assim sendo e em suma, os principais objectivos do trabalho a realizar são: - Compreender todo o contexto em que o problema está inserido; - Identificar correctamente o problema; - Desenhar a arquitectura do sistema; - Desenvolver um protótipo que implemente a arquitectura; - Testar o protótipo para garantir que este se adequa aos requisitos; - Escrever a dissertação que registará o trabalho desenvolvido e as contribuições alcançadas com o desenvolvimento do sistema Solução Desenvolvida A solução que foi desenvolvida corresponde aos objectivos que foram propostos e assenta numa arquitectura composta pelas seguintes componentes: uma componente responsável pela recepção e encaminhamento das leituras provenientes da monitorização RFID e de outras mensagens dos sistemas do aeroporto (ESB); outra que efectua o processamento das mensagens e infere destas informação útil sobre o processo de tratamento de bagagens (CTE); um repositório de eventos (RE) utilizado para persistir o resultado do processamento dos eventos recebidos, funcionando como um histórico do processamento de eventos; uma componente que apresenta em tempo-real, aos responsáveis pelo processo de tratamento das bagagens, o estado actual do processo, usando para isso relatórios acessíveis através da Web (CIN); e ainda uma aplicação Web (AI) que permite, tanto a um passageiro como a um utilizador que participa na gestão do processo de tratamento das bagagens, aceder ao histórico do processo construído a partir da informação resultante da monitorização Contribuição e Resultados Atingidos Com o desenvolvimento da tese e do protótipo que esta implicou, provou-se que é possível criar uma plataforma de monitorização aplicada ao processo de tratamento de bagagens com uma granularidade tão fina quanto a necessária, sem que o desempenho do sistema ou a correcção da monitorização sejam comprometidos. A flexibilidade que a plataforma apresenta foi um dos requisitos fundamentais que regeu todo o desenvolvimento, permitindo assim que sejam atribuídos vários percursos ao mesmo voo ou que existam pontos de monitorização que utilizem leitores RFID móveis em vez dos leitores RFID fixados ao longo do percurso, por exemplo. Podem ser ainda utilizados mecanismos de identificação das malas que não os inicialmente previstos, desde que as leituras das malas sejam entregues ao sistema de monitorização através da interface criada para esse efeito. O sistema implementado demonstra que é possível executar a monitorização, em tempo-real, de um processo complexo como é o processo de tratamento das bagagens num aeroporto e que 5

18 implica o processamento de uma quantidade de eventos significativa, sem que seja necessário o recurso a servidores de grande capacidade. O sistema implementado difere dos sistemas de monitorização comerciais existentes, na medida em que foi desenvolvido para que o passageiro possa ter acesso a informação sobre o estado das suas malas no processo de tratamento a que estas são sujeitas. O passageiro pode aceder à informação directamente, ou pode ser notificado quando as suas bagagens se encontrem em determinada situação. O acesso do passageiro a este tipo de informação permite aumentar a confiança deste num processo que desconhece e do qual depende a segurança das suas malas. Nos sistemas de monitorização que actualmente são utilizados, existe apenas uma perspectiva macroscópica do processo de tratamento, isto é, o processo de tratamento é visto como um todo, sabendo-se apenas em cada instante quantas malas foram processadas, o número médio de malas por avião, etc. Já no sistema de monitorização desenvolvido, cada mala é considerada uma entidade independente e única, sendo o conjunto de informações referentes a cada mala actualizado constantemente à medida que o processo de tratamento de bagagens é monitorizado. Assim, é possível saber em cada momento, o estado completo da mala, desde os pontos de monitorização que já percorreu, até aos tempos que demorou entre cada um, se no decorrer da monitorização foram detectadas situações anómalas, etc. Toda esta informação permite agir proactivamente na gestão do processo de tratamento, permitindo corrigir situações de erro menores que poderiam posteriormente provocar o atraso da entrega das malas ao passageiro, ou em última instância, a perda irreversível das malas Organização da Dissertação Esta tese está organizada em 6 capítulos. Além deste primeiro capítulo introdutório, que serviu para introduzir o contexto em que a dissertação se insere e para apresentar o motivo que originou o problema, os restantes capítulos estão estruturados da seguinte forma: - Capítulo 2: Trabalho Relacionado Neste capítulo é feita uma análise dos vários trabalhos relevantes no contexto da monitorização de objectos, processamento e tratamento de bagagens e standards a respeitar. - Capítulo 3: Arquitectura da Solução Aqui será apresentada uma visão global da solução proposta, sendo definidos os principais componentes que constituem a solução e respectivas responsabilidades. - Capítulo 4: Descrição da Solução Este capítulo consistirá numa descrição mais detalhada do protótipo implementado, abrangendo todas as componentes tecnológicas do sistema que foram implementadas. 6

19 - Capítulo 5: Avaliação Experimental Neste capítulo serão demonstrados os vários testes que se realizaram ao longo do desenvolvimento da solução e que atestam a correcção e eficiência desta. - Capítulo 6: Conclusões e Trabalho Futuro Por fim, serão condensadas as principais conclusões a que se chegaram juntamente com uma sugestão de trabalho futuro caso se pretenda continuar o trabalho aqui iniciado. 7

20 2. Trabalho Relacionado Neste capítulo serão analisados os trabalhos realizados em diferentes contextos e que se relacionam de alguma forma com o tema desta dissertação. Serão referidas algumas soluções comerciais que permitem a localização das bagagens enquanto estas são encaminhadas ao longo do processo de tratamento de bagagens, apesar de não estarem disponíveis quaisquer pormenores técnicos acerca destas. Será também explicado em que consiste o processo de tratamento das malas desde que estas entram no check-in até entrarem no avião. Este processo de negócio, tal como todos os outros que acontecem num aeroporto têm de cumprir regras bem definidas pela organização que rege o sector, a IATA, sendo que algumas das regras e standards mais relevantes para o desenvolvimento desta dissertação serão também explicadas neste capítulo. Será dado também algum ênfase ao uso da tecnologia RFID como método de identificação das malas, uma vez que esta tecnologia apresenta grandes vantagens quando comparada com outros métodos de identificação. Relacionado com esta tecnologia, estão os esforços de algumas organizações para definirem um standard que permita identificar univocamente um objecto e uma arquitectura de um sistema que permite partilhar essa informação entre entidades distintas. Devido ao enorme volume de dados que é gerado como resultado das leituras RFID, será dada particular atenção aos sistemas desenvolvidos com o objectivo de tratar eficientemente tais quantidades de eventos. Dado que os eventos são gerados de uma forma contínua e ao longo do tempo, as premissas tradicionais nas quais se baseiam os sistemas de gestão de bases de dados tal como os conhecemos não são válidas. Assim sendo, serão estudados os requisitos que um sistema que lide com eventos deve respeitar, a teoria em que assenta este tipo de sistemas, bem como alguns protótipos de sistemas implementados que visam tratar de dados provenientes de fontes contínuas. Será ainda analisada a solução de tratamento de eventos da Oracle, uma vez que será nesta que o protótipo desenvolvido se baseará, juntamente com a arquitectura sugerida pela Oracle para a implementação dos sistemas automáticos que gerem os vários processos num aeroporto, e na qual se salienta o uso da componente de tratamento de eventos da Oracle para o processamento da informação resultante da monitorização das malas. Por fim, apresenta-se a análise realizada a um sistema semelhante ao que esta dissertação se propõe a desenvolver e que foi implementado como protótipo no aeroporto de Pequim Soluções Comerciais Existem algumas soluções que possibilitam a localização de bagagens no contexto de um aeroporto, sendo a maioria delas oferecidas comercialmente, pelo que não existe muita informação disponível sobre estas, a não ser nalguns casos os business cases disponibilizados pelas empresas que as comercializam. No entanto, é de referir que em todas as soluções comerciais abordadas, a localização das bagagens surge como consequência da adopção de um novo sistema de tratamento e processamento de bagagens, e não através de um sistema de localização de bagagens que seria 8

21 integrado no sistema de processamento de bagagens já existente. Acresce ainda o facto da localização de bagagens como ferramenta apenas estar disponível internamente aos elementos da companhia aérea ou do aeroporto que interagem com o sistema, visto não existir uma interface Web que permita que os clientes acedam ao mesmo tipo de informação. Inseridas no contexto anterior, salientam-se os sistemas de tratamento de bagagens das empresas SkyTECH[2], AirIT[3] e FKI Logistex[4] que referem a possibilidade dos seus sistemas permitirem a localização das malas ao longo do percurso que estas fazem durante todo o processo de tratamento e encaminhamento a que são sujeitas. Um dos objectivos da solução proposta consiste na flexibilidade que esta tem de possuir para que seja possível adaptar-se facilmente a qualquer aeroporto. Sendo assim, esta terá de se adaptar quer aos sistemas de tratamento de bagagens quer aos sistemas de cooperação entre aeroportos para localização das malas que já existem [5]. Para tal, terão de ser respeitados todos os standards relevantes e práticas recomendadas que regem o sector. A polivalência que a solução apresenta em relação às restrições que as várias soluções comerciais impõem faz com que seja a opção mais adequada quando apenas se pretende um sistema de localização modular e não a mudança completa do sistema de processamento de bagagens Processo de Tratamento de Bagagens O processo de tratamento de bagagens é composto por uma série de passos, desde o checkin inicial das malas até ao momento em que o passageiro as recolhe no destino. Na Fig. 2.1 estão representados, através de um diagrama de blocos, os principais sub-processos pelos quais as malas passam e os segmentos percorridos por estas entre esses mesmos sub-processos [6]. Fig Esquema representativo de um processo de tratamento de bagagens [6]. 9

22 No diagrama distinguem-se três categorias de sub-processos: - Sub-processos executados pelo agente de handling (amarelo). - Sub-processos executados pelo operador do aeroporto (vermelho). - Sub-processos executados pela polícia ou agentes alfandegários (azul). As malas são carregadas e descarregadas do avião pelo agente de handling. Depois de descarregada, a bagagem é transportada para a zona de recolha de bagagem. Antes de as malas chegarem à zona de recolha podem ser inspeccionadas por agentes alfandegários, caso tenham sido seleccionadas para inspecção por algum critério de escolha previamente estabelecido. Caso as malas sejam apenas de transferência, isto é, fazem apenas escala no aeroporto em questão, são então remetidas para a zona de transferência. O agente de handling também é responsável pelo sub-processo de check-in, pelo transporte das malas do check-in para o sistema de encaminhamento de bagagens e pelo transporte destas para o avião após serem encaminhadas. Nalguns aeroportos já existe a possibilidade do check-in não ser feito localmente mas antes num local externo ao aeroporto, como por exemplo, no hotel. Todas as malas que pertençam a voos de saída são inspeccionadas pela polícia excepto malas com autorização one-stop security, isto é, malas que respeitam um acordo entre certos países europeus que permite que malas e passageiros em transferência não tenham de ser revistos novamente nos locais onde fazem escala. O operador do aeroporto é responsável apenas pelo subprocesso de encaminhamento de bagagens. Acrescente-se ainda o facto de o diagrama apresentado na Fig. 2.1 ter sido utilizado durante a apresentação ao cliente do projecto no qual esta dissertação se insere, tendo sido validado pelo cliente a conformidade do diagrama com a estrutura apresentada pelo processo de tratamento de bagagens. O sistema de encaminhamento de bagagens estende-se por todo o aeroporto, ligando várias zonas onde as malas permanecem temporariamente: zonas de chegada e transferência de bagagens, zonas de partida de bagagens e zonas de recolha de bagagens. Os principais elementos que compõem este sistema são: - Passadeiras rolantes, - Balcões de check-in, - Encaminhadores primários, - Encaminhadores secundários, - Zonas temporárias para bagagens. As passadeiras são usadas para ligar os vários componentes do sistema de encaminhamento de bagagens que estão distribuídos ao longo de um aeroporto e transportam as malas durante todo o processo. As malas são etiquetadas quando dão entrada nos balcões de check-in. Depois serão então encaminhadas para o sistema de encaminhamento que tratará de as levar até ao avião correcto. 10

23 Os encaminhadores são responsáveis pelo encaminhamento correcto das malas. É feita a distinção entre encaminhadores primários e secundários pelo facto de os primários além do encaminhamento das malas propriamente dito, serem responsáveis pelos procedimentos de segurança a que as malas têm de ser sujeitas, pelo tratamento de malas que chegaram demasiado cedo (deram entrada no sistema até quatro horas antes da hora de partida) e pelo tratamento de malas que por algum motivo não conseguiram ser correctamente identificadas, enquanto os secundários apenas têm a função de encaminharem as malas vindas dos encaminhadores primários para as respectivas zonas de partida ou transferência de onde serão depois levadas até aos aviões correspondentes. Na Fig. 2.2 é possível observar-se a entrada de um encaminhador primário onde as malas são identificadas através da leitura de códigos de barras para depois poderem ser correctamente encaminhadas. Estas passagens nas quais estão aplicados dispositivos que permitem a identificação das malas são tipicamente chamadas de gates. No caso em que o método de identificação escolhido utiliza tecnologia RFID, em vez de vários leitores de códigos de barras teríamos vários leitores RFID num mesmo gate para assim aumentar a taxa de leitura nestes locais. Fig Entrada de um encaminhador primário, com leitores de códigos de barras para identificação das malas. As zonas temporárias para bagagens funcionam como locais intermédios entre componentes do sistema de encaminhamento em que as malas esperam até serem passadas ao componente seguinte. Esta decomposição do sistema de encaminhamento é importante, pois é com base nesta e nos vários segmentos que ligam os diversos componentes do sistema que a localização de cada uma das malas é possível. Caso um dos segmentos (ou mesmo uma das componentes do sistema de encaminhamento) seja demasiado extenso, poderá ser dividido em segmentos mais pequenos através da colocação de mais dispositivos de identificação ao longo do percurso abrangido por este. Desta forma e quando necessário, a granularidade em qualquer dos percursos pode ser aumentada sem que tenha de haver uma reconfiguração geral do sistema. 11

24 Na Fig. 2.3 estão exemplificados os vários componentes que um sistema de encaminhamento de bagagens pode ter bem como as várias ligações entre estes. Os encaminhadores principais direccionam as malas para os encaminhadores secundários correctos e estes encaminharão então as malas para os respectivos receptáculos, de onde serão levadas depois para os aviões. Fig Exemplo esquemático de um sistema de encaminhamento de bagagens (adaptado de [6]) Standards e Práticas Recomendadas A International Air Transport Association (ou simplesmente IATA) representa actualmente 230 companhias aéreas, estando presente em 150 países e abrange 93% de todo o tráfego aéreo internacional agendado. Para que todas estas companhias possam coexistir o melhor possível, a IATA define uma série de práticas recomendadas (Recommended Practices, no original) que com a evolução do tempo passam a ser regras obrigatórias (Resolutions, no original) e que regem toda a indústria da aviação. Estas práticas recomendadas são concebidas em conferências onde participam os representantes das várias companhias aéreas associadas e têm como objectivos a simplificação dos processos de negócio e o aumento contínuo do bem-estar dos passageiros enquanto são reduzidos custos e é melhorada a eficiência. Um dos três elementos-chave da Missão a que a IATA se propõe actualmente é o de permitir a pessoas e a mercadoria movimentarem-se na rede aérea global criada pelos seus associados de uma forma tão fácil como se viajassem apenas numa única companhia aérea de um único país. Uma das principais formas de garantir que as companhias aéreas interajam entre si sem quaisquer problemas passa pela definição de boas práticas (as tais práticas recomendadas) e por um conjunto de regras que devem e têm de ser respeitadas, respectivamente. Assim, garante-se que apesar de um voo ter os países de origem e destino diferentes e as companhias aéreas que nele participam serem distintas, não haverá qualquer problema desde que sejam respeitados todos os procedimentos pré-estabelecidos pela IATA. 12

25 Da mesma forma, para se poder garantir o mesmo nível de coerência em todo o processo pelo qual as bagagens passam, seja qual for a origem dos vários sistemas intervenientes, têm de existir também regras explícitas que definam quais os procedimentos a realizar em determinada situação. Ao longo do processo de tratamento e encaminhamento das bagagens participam vários sistemas, desde o sistema de controlo de partidas (Departure Control System, ou DCS) que tem um papel preponderante no início do processo, passando pelos sistemas responsáveis pelo encaminhamento das malas até ao avião correcto e ainda os sistemas quer permitem a reconciliação dos passageiros com as suas malas Baggage Information Messages A coordenação de todos os sistemas intervenientes no processamento das bagagens só é possível graças à troca de mensagens entre estes, permitindo que o encaminhamento de bagagens, a reconciliação entre passageiros e suas malas e outros serviços relacionados com estas sejam automatizados com sucesso. Às mensagens usadas dá-se o nome de Baggage Information Messages, ou BIMs (em [7] estas mensagens são chamadas de Baggage Service Messages). Na Recommended Practice 1745 presente em [8] a IATA define os vários tipos de mensagens que compõem o conjunto das Baggage Information Messages: - Baggage Source Message (BSM), - Baggage Transfer Message (BTM), - Baggage Processed Message (BPM), - Baggage Unload Message (BUM), - Baggage Control Message (BCM), - Baggage Not Seen Message (BNS), - Baggage Manifest Message (BMM) e - Baggage Request (BRQ). Estas mensagens são enviadas entre os vários sistemas automáticos de tratamento de bagagens com o objectivo de automatizar ao máximo os processos de encaminhamento e tratamento de bagagens e o processo de reconciliação dos passageiros com as respectivas malas. A definição de todas estas mensagens surge como resposta à necessidade de existir uma interface bem definida entre os diferentes sistemas, em que cada mensagem tem uma semântica concreta sem qualquer tipo de ambiguidade. Assim, cada interveniente nos referidos processos tem liberdade suficiente para implementar as recomendações da IATA da forma que melhor entender, desde que as mensagens enviadas para os sistemas que o sucedem no decorrer do processo respeitem as várias práticas recomendadas pela IATA. Cada mensagem é composta por vários campos que são usados para codificar a informação a ser transmitida ao receptor. A definição de cada um dos campos bem como a sua sintaxe está também presente na prática recomendada referida. Como exemplos de campos comuns temos os campos.d,.f,.i e.n, que contêm informação sobre: Bag Check-In Details, Outbound Flight Information, Inbound Flight Information e Baggage Tag Details, respectivamente (cf. Anexo A). 13

26 Todos os campos definidos são considerados obrigatórios, opcionais ou condicionais, consoante a sua existência seja obrigatória, opcional ou se a sua presença seja condicionada por factores que possam existir. A obrigatoriedade de cada campo varia com o tipo de mensagem. Tome-se como exemplo as Baggage Source Messages: este tipo de mensagens é enviado assim que a mala inicia o processo de tratamento de bagagens para que os sistemas automáticos de encaminhamento saibam como a processar. Tanto o campo.f como o campo.i (que guardam informação sobre o voo em que a mala parte e o voo em que a mala chegou, respectivamente) são considerados condicionais pois a direcção do voo em questão define a presença de um dos campos, isto é, caso o voo seja de partida, então tem de estar presente o campo.f, senão o voo é considerado de chegada e o campo presente passa a ser o.i. Se considerarmos as Baggage Transfer Messages, que têm como objectivo, numa viagem em que existe uma escala intermédia, informar o aeroporto onde foi realizada a escala que a mala chegou em determinado voo e partirá noutro, tanto o campo que representa o voo de chegada (.I) como o campo que representa o voo de partida (.F) são obrigatórios, pois essa informação é fundamental para o encaminhamento da mala. Considere-se agora o conteúdo de um campo.f:.f/lh1274/05may/jfk<, isto informa-nos que a companhia responsável pelo voo de saída em questão tem como identificador LH, o número do voo é o 1274, partirá a 5 de Maio (05MAY) e o aeroporto de destino tem como identificador JFK. Como último exemplo, na Tabela 2.1 é possível verificar o conteúdo de uma BTM completa, composta pelos vários campos que a compõem. Conteúdo da BTM BTM<.V/1TORD<.I/KL318/14JAN/AMS<.F/UA423/14JAN/DEN< Descrição do campo - Início de uma BTM; - Bagagem que fez escala (T) em ORD; - Chegou no voo KL318 vindo de AMS; - Partirá no voo UA423 para DEN;.N/ < - São 3 malas em que o ID da primeira é o ;.P/SMITH/J< ENDBTM< - Nome do passageiro; - Fim de uma BTM. Tabela 2.1. Conteúdo de uma Baggage Transfer Message License Plate Number Na Resolution 740, Attachment A presente em [8], é definido o License Plate Number, ou LPN, como um número de 10 dígitos que identifica univocamente uma única mala de um passageiro em determinada viagem (se o passageiro possuir várias malas, é atribuído um LPN a cada uma). Este identificador é usado no encaminhamento automático, reconciliação entre passageiro e mala, na entrega da mala ao passageiro quando ambos chegam ao seu destino e por fim, caso o percurso da 14

27 mala seja monitorizado para evitar erros no seu processamento, também deve ser utilizado o LPN como identificador de cada mala no sistema de monitorização. No ponto da resolução em questão, são definidos os vários campos que compõem um LPN. São sempre três os campos existentes em cada LPN e são também eles usados para codificar informação relevante sobre a mala. Na Tabela 2.2 são apresentados cada um dos campos, juntamente com o seu significado, possível conteúdo e interpretação de cada um dos campos do exemplo fornecido. Tome-se por exemplo agora a entrada de uma mala no processo de tratamento de bagagens através dos balcões de check-in. Após a verificação dos documentos necessários, o passageiro deixa a sua mala no balcão para que esta possa ser encaminhada até ao respectivo avião. Para ser encaminhada, os sistemas de encaminhamento automático necessitam de informação sobre o destino da mala. Assim sendo e como resultado do check-in, é enviada para os sistemas de encaminhamento automático existentes uma Baggage Source Message para assim lhes transmitir a informação necessária para o correcto encaminhamento da mala. Por mor de eficiência e para evitar a congestão dos sistemas de encaminhamento, em vez de ser enviada uma BSM por cada mala, tipicamente opta-se por enviar uma BSM por cada conjunto de malas que tenham o mesmo destino uma vez que, caso fosse enviado somente uma BSM por mala, apenas o campo.n das BSM (que identifica a mala em questão) mudaria. Assim, existe um mecanismo que permite que uma BSM se refira a várias malas e não apenas a uma: o conteúdo do campo.n é um número de 13 dígitos, em que os primeiros 10 dígitos são interpretados como um LPN e os restantes 3 dígitos são interpretados como o número de malas que têm como LPN os valores exactamente seguintes ao LPN dos primeiros 10 dígitos (assume-se que os LPN são atribuídos sequencialmente). Tome-se como exemplo o seguinte conteúdo do campo.n:.n/ <. Isto significa que entraram no processo 5 malas (o conteúdo dos 3 últimos dígitos, 005 ) e que o LPN da primeira mala é , sendo que os LPN das restantes quatro malas serão os valores exactamente seguintes, isto é, , , e , respectivamente. 15

28 Exemplo: Posição do Campo Conteúdo Possível Semântica Interpretação do Exemplo 0 LPN usado apenas entre companhias aéreas. 1º Campo: º dígito 1 2 LPN de tipo "fallback". Se o serviço de Baggage Information Messages não estiver a funcionar correctamente no aeroporto de origem, este tipo de LPN é usado no encaminhamento da bagagem até ao avião, tendo depois de ser removido. Tem de existir também um LPN "normal" juntamente com a mala, para identificar a mala univocamente. LPN para ser usado entre companhias aéreas, mas atribuído apenas a malas mais prioritárias. Tipicamente, atribuído a malas que de alguma forma não foram tratadas inicialmente da forma esperada (atrasos, erros no encaminhamento, etc.). Mala considerada prioritária porque sofreu um atraso e não embarcou (devido a um erro no seu encaminhamento). 3-9 LPN usado entre companhias aéreas e também caso o check-in seja feito on-line (a semântica de cada um dos valores tem de ser pré-estabelecida entre as companhias que os usam). 2º Campo: º ao 4º dígito Código de 3 dígitos atribuído pela IATA e que identifica univocamente cada companhia aérea responsável pela emissão dos LPN. Caso o LPN seja emitido por uma entidade do aeroporto que não possua este código de identificação, este deve ter o valor de "000". LPN da mala emitido num balcão da British Airways (125 é o código numérico da British Airways). 3º Campo: ª ao 10º dígito Número de 6 dígitos que identifica univocamente cada mala. Este número pode assumir todos os valores aqui apresentados, excepto em situações pontuais em que a atribuição de intervalos de valores a cada entidade é definida pela IATA. Mala identificada univocamente pelo número Isto garante que o LPN da mala é único no conjunto de LPNs que foram emitidos pela British Airways. Tabela 2.2. Composição e interpretação dos campos de um License Plate Number. 16

29 2.4. Tecnologia RFID A tecnologia RFID, ou Radio Frequency Identification, é usada para identificar e monitorizar um determinado objecto ao qual foi incorporado uma tag, que não é mais do que um dispositivo que responde a determinado estímulo recebido através de ondas de rádio. A distância entre o leitor e a tag RFID pode variar e não é necessário haver um espaço aberto entre estes para que a leitura aconteça. Devido a estas características, esta tecnologia apresenta vantagens em relação a outras tecnologias de identificação de objectos (como por exemplo, o uso de leitores de códigos de barras). A captura de eventos ao longo de um processo pelo qual passam qualquer tipo de bens é realizada através da identificação de cada objecto ao longo de uma série de pontos que se estendem por todo o processo em questão. A monitorização que resulta da permanente identificação dos bens em vários pontos de leitura permite melhorar a eficiência de todo o processo porque passa a ser possível saber o percurso exacto de cada bem, o tempo que demorou em cada segmento, os possíveis erros que entretanto surjam e consequentemente, combinando toda esta informação com dados históricos é possível detectar com precisão os bottlenecks do processo, os sub-processos a melhorar ou a redesenhar completamente, etc. Dado que a granularidade permitida na localização de um bem é proporcional ao número de leitores existentes ao longo do percurso que este percorre [9] e que um leitor RFID apresenta uma taxa de leitura na ordem dos 96,89% no contexto do tratamento de bagagens [10] (em [7] afirma-se que é possível atingir uma taxa de leitura de 99%) que é muito maior que a apresentada por qualquer leitor de códigos de barras, a tecnologia RFID torna-se como o natural sucessor dos códigos de barras. Estando esta tecnologia a evoluir a um ritmo acelerado, tanto a nível técnico como de adopção pelos mais variados sectores, a IATA assumiu a introdução do RFID em toda a logística do processamento das bagagens [11] para mitigar os erros aos quais a indústria aérea tem estado invariavelmente associada [12]. Como consequência das vantagens que apresenta, do apoio à sua adopção na indústria dos transportes aéreos, da maturidade e potencial que a tecnologia apresenta e dos standards bem definidos [7], estima-se que os 20 milhões de dólares que foram gastos em 2006 com tecnologia RFID passem para 100 milhões de dólares em 2016 [13]. Sabendo de todos os benefícios inerentes à implantação do RFID nos sistemas automáticos de tratamento de bagagens (nomeadamente nos sistemas de encaminhamento, reconciliação com passageiros e monitorização de bagagens), muitas companhias aéreas e aeroportos já iniciaram a transição dos sistemas actuais de identificação das bagagens para sistemas que usem como método de captura de eventos a tecnologia RFID. São disso exemplo os seguintes aeroportos e companhias: Hong Kong International Airport, Delta Airlines, McCarran International Airport, British Airways, Heathrow Airport, Singapore Airlines e o Narita International Airport [7]. Na Recommended Practice 1740c presente em [8], a IATA define o conjunto de boas práticas a seguir na adopção do RFID por parte das companhias associadas, nomeadamente a definição dos standards que serão usados na comunicação entre leitores e tags (ISO C) e a escolha do protocolo que a aplicação tem de usar quer para comprimir e guardar os dados (ISO/IEC 15961) quer para identificar os comandos que estão disponíveis para interagir com a tag (ISO/IEC 15962) [10]. A 17

30 única informação que a IATA exige que esteja armazenada na memória da tag é a informação relativa ao LPN da mala, pois cada mala estará etiquetada com uma tag que permitirá que a mala seja monitorizada ao longo do seu percurso. Os restantes campos da tag que poderiam conter informação sobre a mala são opcionais porque as tags colocadas podem ter sido codificadas previamente e não no momento em que são colocadas no processo de check-in. Para cada campo existe uma forma de codificar a informação para assim aproveitar da melhor forma o escasso espaço disponível que existe numa tag (cf. Anexo B) Electronic Product Code A forma como a informação será codificada em cada uma das tags respeita os standards criados pela EPCglobal. A EPCglobal é uma organização global neutra sem fins lucrativos responsável pelo desenvolvimento e validação de standards relativos ao EPC, ou Electronic Product Code, usado actualmente na tecnologia RFID. Este Electronic Product Code é a concretização do princípio da identidade única: cada objecto físico, carga, local, bem, ou qualquer outra entidade que necessite de ser monitorizada para atingir um objectivo de negócio de determinada indústria tem associado um Electronic Product Code único que a identifica univocamente. O EPC é um número de 96 bits composto por vários campos definido em [14]. Podem ser utilizados vários tipos de sistemas de identidade que definem quais os campos e respectivos tamanhos e a sua interpretação. Um dos sistemas mais usado é o SGTIN, ou Serialized Global Trade Item Number, para monitorizar o movimento de quaisquer bens que circulem entre diversas entidades. Dos campos utilizados no EPC SGTIN-96 (o comprimento total de um EPC deste tipo é de 96 bits), realça-se o papel do prefixo da entidade, que pode ter até 40 bits de comprimento (mínimo de 20 bits) e identifica univocamente a entidade que atribuiu o EPC; a referência do objecto que identifica através de um número que pode ter até 24 bits de comprimento (com um mínimo de 4 bits) a classe ou o tipo do objecto; e por fim, um número de série com 38 bits de comprimento que identifica univocamente o objecto em questão (cf. Tabela 2.3). O valor do filtro permite uma filtragem rápida pois define o tipo genérico de objecto (o valor 001 binário, por exemplo, refere-se a bens de consumo passíveis de serem enviados entre entidades). O valor da partição define o número de bits atribuídos quer ao prefixo da entidade quer à referência do objecto. Como exemplo disto temos o valor 4 decimal que define que sejam atribuídos 27 bits ao prefixo da entidade e 17 bits à referência do objecto). 18

31 Cabeçalho Valor do Filtro Partição Prefixo da Entidade Referência do Objecto Número de Série Comprimento Valores possíveis (binário) NA NA (intervalo - 9 (intervalo (valor máximo decimal) decimal) decimal) Define o tipo Define o Define o de sistema tipo de número de Valor que Número de série de produto, bits Valor que identifica a que identifica Semântica identidade a utilizar (está para permitir a atribuídos ao prefixo identifica a entidade que classe/tipo do objecto univocamente o objecto em aqui rápida da entidade atribuiu o EPC. em questão na classe apresentado filtragem e referência questão. a que pertence. o SGTIN). de tags. do objecto. Legenda: NA Não se aplica. Tabela 2.3. Campos de um Electronic Product Code SGTIN-96 (adaptado de [14]) EPCglobal Architecture Framework A EPCglobal criou uma framework arquitectural que suporta a identificação de bens ao longo de qualquer cadeia de valor e permite a partilha da informação resultante dessa identificação pelas entidades que utilizam essa mesma framework. Pretende-se que esta framework venha a ser o standard que define como é que as aplicações e sistemas que necessitam de monitorização de bens devem agir no sentido de obterem toda a informação relevante e a partilharem de forma inteligível com as outras que também se regem pela framework, que é composta pelo conjunto de hardware, software e standards que definem o tipo de dados a utilizar, juntamente com uma rede partilhada de serviços que podem ser usados por todas aquelas entidades que participam e que permitirá um acesso partilhado a todo o tipo de informação resultante da monitorização dos bens que incorporam tags compatíveis com o EPC. Na Fig. 2.4 estão patentes as três principais acções que se podem realizar no âmbito da Framework da EPCglobal: troca física de bens que incorporam uma tag que contém um EPC, a captura de informação sobre os bens proveniente de tags que estão incorporadas nestes e por fim a troca de informação sobre os bens entre as entidades que pertencem à rede EPC (interpretando a figura de baixo até ao topo). 19

32 Fig Visão geral da framework arquitectural proposta pela EPCglobal. Cada uma das acções contempladas na framework arquitectural EPC envolve diferentes standards que regem a forma como essas acções devem ser desempenhadas e que são também definidos pela EPCglobal na referida framework: 1. EPC Physical Object Exchange Os standards utilizados na troca física de bens especificam os vários tipos de tags e a forma como a informação é armazenada na memória que cada tipo de tags possui. São eles: 1.1. UHF Class 0 Gen 1 RF Protocol 1.2. UHF Class 1 Gen 1 RF Protocol 1.3. UHF Class 1 Gen 1 Tag Protocol 1.4. UHF Class 1 Gen 2 Tag Protocol 1.5. EPC Tag Data Specification 2. EPC Infrastructure for Data Capture Todos os standards necessários à identificação e monitorização de bens e à utilização do EPC dentro de uma mesma organização são aqui definidos. Todos os procedimentos que são precisos para agregar e armazenar os dados EPC, criação de novos EPC para atribuição e a monitorização dos bens dentro da organização também estão explícitos nesta camada. Por fim, é de referir a não imposição de quaisquer restrições à implementação por parte da EPCglobal, exigindo esta apenas o respeito pelas normas por ela definidas para que assim a interoperabilidade entre EPC criados por diferentes entidades seja sempre mantida. Estas normas estão expressas nos seguintes standards: 2.1. EPC Tag Data Specification 2.2. Reader Protocol 20

33 2.3. Reader Management 2.4. Tag Data Translation 2.5. Application Level Events 2.6. EPCIS Capture Interface 2.7. EPCIS Data Specification 3. EPC Data Exchange Permite a ligação entre entidades que fazem parte da rede EPC e faz com que esta ligação seja transparente quando, por exemplo, uma entidade precisa de saber informação sobre determinado bem ao qual foi atribuído um EPC por outra entidade. A partilha de informação relevante para os negócios das organizações que comunicam entre si é garantida desde que sejam respeitados os seguintes standards: 3.1. EPCIS Data Specification 3.2. EPCIS Query Interface 3.3. EPCIS ONS 3.4. EPCIS Discovery 3.5. Subscriber Authentication É de notar o facto da arquitectura proposta estar assente num modelo de camadas, em que à medida que se caminha no sentido da interacção entre organizações que partilham informação sobre os bens, existe uma progressiva abstracção da forma como foram desempenhadas as várias leituras, sabendo-se apenas que existe informação sobre determinado bem, e que caso essa informação não seja acessível localmente, existirá um mecanismo para obter essa informação remotamente Tratamento de Eventos O uso da tecnologia RFID na captura de eventos permite alcançar melhorias significativas para os processos de negócio através da possibilidade da automatização completa dos mecanismos de identificação e da captura de dados no decorrer de todo o processo. No entanto, os dados resultantes das leituras RFID criaram novos obstáculos para os sistemas de tratamento de eventos actuais devido aos dados serem temporalmente dependentes, mudarem dinamicamente, terem uma semântica implícita (muitas vezes deduzida apenas pela composição de eventos específicos) e devido à grande granularidade existente no processo, serem gerados em grandes quantidades. Estas características levaram a que fossem definidos alguns requisitos considerados fundamentais para que estes sistemas consigam processar correcta e eficientemente todos os eventos gerados. Os sistemas de gestão de bases de dados tradicionais estão aptos apenas para correr queries únicas sobre um conjunto finito de dados. Num contexto de tratamento de eventos, o resultado das queries deve evoluir dinamicamente e o conjunto de dados que estas processam está constantemente a crescer, não sendo assim finito mas sim uma stream contínua de eventos sobre os quais será aplicada uma query cujo resultado deve ser semanticamente equivalente à situação em 21

34 que o conjunto de dados é finito. Com o objectivo de concretizar um sistema que lide correctamente com situações em que são necessárias queries contínuas sobre um conjunto de dados que à partida não se conhece o limite, surgiu em Stanford [15] um protótipo chamado Data Stream Management System (DSMS) ou STREAM que suporta o uso de queries contínuas sobre streams de eventos contínuas e simultaneamente sobre conjuntos de dados tradicionais. Será também aqui abordada a framework disponibilizada pela Oracle para facilitar o processamento e tratamento de eventos e onde é desenvolvida tipicamente toda a lógica de negócio para que, depois do processamento dos eventos (na grande maioria das vezes, um processamento faseado em que gradualmente a informação resultante dos eventos é enriquecida), estes sejam enviados já com informação de negócio relevante para os ERP (Enterprise Resource Planning) ou sistemas de análise do negócio (BAM, etc.) Requisitos do Processamento de Eventos em Tempo-Real Actualmente existem sistemas comerciais de processamento de streams de dados que permitem a criação de aplicações orientadas a eventos sem que seja também preciso o desenvolvimento dos mecanismos necessários a uma aplicação deste tipo (interfaces para recepção dos dados, gestão das streams de dados, etc.). Em [16] são definidos os oito requisitos que um sistema deste tipo tem de satisfazer para que possa ser considerado capaz de realizar o processamento em tempo-real de streams de dados: Fig Processamento da stream enquanto os dados fluem, com armazenamento opcional. 1. Manter os dados em movimento Para que o sistema mantenha uma baixa latência, os dados têm de poder ser processados sem que o custo do armazenamento destes seja elevado. Uma operação de armazenamento obriga a uma transacção completa na base de dados e consequentemente implica acessos ao disco para persistir os dados e possivelmente uma escrita no log. 22

35 Na maior parte dos sistemas de processamento de dados em tempo real, não é nem aceitável nem necessário sequer que os dados sejam armazenados antes de serem processados. Em vez disso, os dados devem ser processados na stream, enquanto estes fluem, sendo o armazenamento opcional e irrelevante para o processamento dos dados (cf. Fig. 2.5). 2. Permitir queries SQL nas streams de dados Nos sistemas que lidam com streams de dados, tem de existir um mecanismo que permita realizar queries sobre os dados que fluem nas streams, permitindo assim a obtenção de informação em tempo real (quer para efeitos de monitorização exclusiva do fluxo de dados, quer utilizando a informação daí resultante no processamento dos dados). Tipicamente, essas queries são concretizadas através de SQL adaptado às streams de dados, visto existirem algumas premissas que mudam neste contexto quando comparado com queries SQL tradicionais sobre conjuntos de dados estáticos. Apesar de haver a possibilidade de realizar essas queries em C++ ou Java (linguagens nas quais assentam a maior parte das ferramentas de processamento de eventos), usa-se o SQL pois estas linguagens acarretam ciclos de desenvolvimento mais longos e um maior custo de manutenção. Nalguns sistemas que surgiram, especialmente em meios mais académicos (é disso exemplo o sistema proposto em [17]), em vez da adaptação do SQL ao contexto das streams, optaram pela criação de uma nova linguagem que permita a realização de queries sobre os dados que fluem. No entanto, estas linguagens não têm tido uma boa aceitação, primeiro porque obrigam a aprendizagem de uma linguagem completamente nova e que ainda por cima assenta num paradigma temporal, e depois porque tendo o SQL a aceitação que tem, qualquer sistema que permita aceder a dados armazenados numa base de dados tem de permitir queries SQL. Como os sistemas de processamento de streams são considerados extensões aos sistemas de gestão de bases de dados actuais (porque permitem realizar queries também sobre a stream de dados) faz sentido que estes ofereçam também uma extensão ao SQL que permita todo o tipo de operações tradicionais mas sobre o fluxo de dados a processar. 3. Tratar quaisquer imperfeições no fluxo de dados (atrasos, faltas, dados fora-de-ordem) Numa base de dados tradicional, os dados estão sempre presentes antes da query ser realizada, mas num sistema de processamento de streams em tempo real, dado que os dados idealmente nunca são armazenados, a infra-estrutura que suporta o sistema tem de permitir o correcto funcionamento do processamento ainda que alguns dados se atrasem, se percam ou cheguem simplesmente fora de ordem. Caso a presença de todos os dados seja estritamente necessária, nunca se deve bloquear o sistema à espera que estes cheguem, mas sim despoletar um alerta de tempo excedido caso estes não cheguem ao sistema dentro de algum tempo, pois enquanto o sistema está bloqueado à espera, outros dados precisarão também de serem processados. 23

36 4. Gerar um resultado previsível Um sistema que processa fluxos de dados tem de garantir que uma série de dados temporalmente sequenciais são processados de uma maneira previsível para garantir que o resultado deste processamento é determinístico e poderá ser repetido caso seja necessário. Este requisito torna-se ainda mais importante quando são consideradas a tolerância a faltas e a recuperação do sistema em caso de desastre, visto que nestes casos o fluxo de dados seria repetido e reprocessado, esperando-se que fosse obtido o mesmo resultado, independentemente do momento da execução. Fig Sistema de processamento de streams, com uma base de dados embebida neste. 5. Integrar os dados armazenados com os dados provenientes da stream Os sistemas de processamento de streams de eventos têm de permitir o armazenamento e acesso transparente aos dados históricos, isto é, tanto os dados que deram entrada no sistema anteriormente como a informação que deles resultou tem de estar acessível para que se possa, juntamente com dados actuais, obter informação relevante sobre o estado actual da informação. Temos como exemplo disso o seguinte comportamento: gerar um alerta quando o valor médio das acções da Google nos últimos 10 minutos excederem esse mesmo valor mas nos últimos 50 minutos, desde que isto não tenha acontecido mais do que 5 vezes nas últimas 7 horas de transacções. Neste caso, usa-se informação histórica juntamente com dados recentes para que o comportamento descrito possa ser implementado. Também é frequente algumas empresas quererem testar o algoritmo de processamento que desenvolveram com dados históricos para verificar o desempenho do sistema e se necessário testar até cenários alternativos, não previstos à partida. Existem também situações em que é necessário o sistema começar a processar alguns dados históricos (começar o processamento num momento no passado), para, por exemplo, a informação resultante do processo começar de um ponto considerado normal para depois disso então começaram a ser processados os dados em tempo real. É de salientar que essa transição entre dados históricos e dados reais deve ser feita automaticamente, sem qualquer intervenção manual. Os dados históricos nunca podem estar armazenados numa base de dados cujo acesso a esta tenha de passar por uma ligação remota, dado que isto acarretaria uma latência excessiva, resultando num overhead excessivo para o sistema que estaria a processar o fluxo de dados. Uma 24

37 solução para uma situação destas seria o próprio sistema de processamento ter embebido um sistema de gestão de bases de dados local, sendo a base de dados local uma réplica da base de dados remota (cf. Fig. 2.6). Assim, o acesso à base de dados não seria tão penalizante visto não ser necessária qualquer ligação a outra máquina, pelo que o processamento dos dados históricos e a consequente transição para dados em tempo-real seria realizado sem quaisquer problemas. 6. Garantir a segurança e a disponibilidade dos dados Para preservar a integridade da informação que para muitas empresas é crítica e evitar problemas no processamento em tempo-real dos dados, é necessário que o sistema apresente algum tipo de solução que permita uma alta disponibilidade do sistema. Como exemplo disto, temos os serviços financeiros que assumem que os seus sistemas têm de estar online sempre, independentemente do que aconteça. Se porventura acontece algum tipo de falha, esta tem de ser contornada através dum processo de recuperação que utilize réplicas do servidor que estava a ser utilizado antes da falha e que de seguida o sistema consiga continuar. Reiniciar o sistema que falhou e recuperar o estado usando para isso o log onde foram registadas as várias acções realizadas não é uma acção comportável para a maior parte dos sistemas de processamento de fluxos de dados em tempo real porque durante esse tempo, não seriam processados quaisquer dados que eventualmente surgissem. Assim sendo, tem de existir um sistema de réplicas que permitam, na eventualidade de uma falha, o contínuo processamento do fluxo de dados. 7. Permitir a partição das aplicações automaticamente garantindo a futura escalabilidade Deve ser possível particionar o sistema por vários processadores ou máquinas para atingir uma maior escalabilidade, sem que para isso o programador tenha de desenvolver código específico para esse efeito. Actualmente, existe a tendência de se optar por um conjunto de máquinas que realizarão o processamento do fluxo de dados de forma distribuída em vez de se optar por um único servidor mais potente. Isto faz com que o risco seja mitigado, visto o processamento estar a ser realizado paralelamente e permite poupar consideravelmente já que o custo de um conjunto de máquinas típicas é menor do que o de um servidor equivalente. Os sistemas de processamento de fluxos têm de permitir também que as várias acções a realizar sejam desempenhadas de uma forma multi-tarefa, obtendo-se assim vantagem dos (cada vez mais comuns) processadores com vários núcleos. Mesmo que a máquina em questão não possua mais que um núcleo, é recomendável usar-se uma abordagem multi-tarefa para se evitarem bloqueios devido a esperas de eventos externos, por exemplo, evitando-se assim uma latência elevada do sistema. 8. Processar e responder instantaneamente Por fim, nenhum destes requisitos fará sentido se o sistema apesar de os cumprir a todos, não conseguir cumprir o objectivo principal de processar um grande volume de dados provenientes de uma stream com um baixo tempo de reacção (baixa latência). Um sistema que pretende realizar este tipo de processamento, tem de ser capaz de processar dezenas a centenas de milhares de dados por 25

38 segundo com uma latência entre o micro segundo e o milissegundo, isto usando hardware comercial sem quaisquer alterações específicas para o problema em questão. É de realçar o facto de que este comportamento acontece enquanto são tratadas eventuais imperfeições na stream de dados, integrando dados históricos com dados em tempo real, se preciso escalando o sistema para um sistema distribuído e mantendo a tolerância a faltas necessária num sistema deste tipo. Para ser alcançado este nível de desempenho, o sistema tem de estar altamente optimizado de forma que o fluxo de execução minimize o overhead em relação ao trabalho que é realmente desempenhado. Um exemplo disto é a solução sugerida no ponto 5 que faz com que sejam minimizados os acessos a entidades externas, através da integração de todas as funcionalidades críticas num único processo Sistemas de Processamento de Eventos em Tempo-Real Os sistemas de gestão de bases de dados (SGBD) tradicionais foram criados para responder de forma eficiente a queries únicas sobre um conjunto de dados finito armazenado de alguma forma numa base de dados. No entanto, muitas aplicações modernas precisam de realizar queries contínuas (isto é, queries em que o seu resultado é actualizado conforme os dados mudam, e não calculado de novo de cada vez que isto acontece) sobre um fluxo ilimitado de dados. Para responder a esta necessidade, foi iniciado um projecto na Universidade de Stanford [15, 18] com o objectivo de desenvolver um sistema de gestão de streams de dados (Data Stream Management System, ou DSMS), também chamado de STREAM, que suporta uma ampla variedade de queries contínuas sobre fluxos de dados contínuos e também sobre conjuntos de dados tradicionais. Pretende-se que o protótipo criado no âmbito deste projecto funcione em ambientes em que o fluxo de dados seja rápido, as características das streams e a carga que as queries implicam variem ao longo do tempo e em que os recursos disponíveis possam ser limitados. É de realçar ainda que apesar de o STREAM permitir que sejam feitas queries aos fluxos de dados da mesma forma que são feitas queries a conjuntos de dados numa base de dados tradicional, não pode ser aplicada no primeiro caso a mesma semântica relacional que é utilizada no último, pois queries contínuas aplicadas a um fluxo de dados que continuamente se altera têm de ter em conta uma série de premissas temporais e causais que não existem nos SGBD tradicionais. Por isso mesmo, em [18] define-se detalhadamente a Continuous Query Language (ou CQL), uma linguagem declarativa baseada no SQL e desenvolvida no âmbito do STREAM para permitir realizar as tais queries contínuas sobre streams de dados e relações dinâmicas entre esses mesmos dados, ao contrário das relações existentes nos SGBD tradicionais em que as relações existentes entre tabelas são estáticas. Em [19, 20, 21] o uso de queries contínuas expressas nalguma linguagem declarativa é exemplificado. Contudo, não passa de um exemplo, primariamente para ilustrar o potencial que uma linguagem declarativa pode oferecer no processamento de dados provenientes de um fluxo contínuo. Durante o desenvolvimento da CQL e do motor de execução desta foi tido em conta a necessidade da CQL se mostrar o mais completa possível de forma a poder ser considerada como uma ferramenta 26

39 eficiente e genérica para realizar queries contínuas sobre streams de dados e permitir relações dinâmicas entre estas. Fig Conceitos e operadores nos quais se baseia a semântica abstracta implementada pela CQL (adaptado de [15]). Para permitir o uso de mecanismos mais complexos nas queries, tais como agregações, queries dentro de outras queries (subqueries), o uso de janelas para delimitar o fluxo de dados e a realização de joins entre streams e relações tradicionais, a semântica que o SQL define em relação a estes mecanismos teve de ser estendida para se adaptar ao conceito das queries contínuas. A esta adaptação da semântica do SQL chamou-se semântica abstracta, sendo o CQL não mais do que uma linguagem declarativa concreta que implementa esta semântica abstracta. A semântica abstracta implementada pela CQL baseia-se em dois conceitos fundamentais, o conceito de stream e o conceito de relação: 1. Uma stream S é um conjunto ilimitado de pares <s, t> em que s é um tuplo e t é um timestamp que exprime o tempo de chegada lógico do tuplo s à stream S. 2. Uma relação R é um conjunto de tuplos que varia no tempo. Um conjunto de tuplos no instante t é expresso por R(t) e é designado por relação instantânea. É de realçar o facto de esta definição de relação diferir da definição tradicional que não tem qualquer noção temporal associada. São ainda utilizados três tipos de operadores para manipular streams e relações (cf. Fig. 2.7): 1. Um operador relação-relação que opera sobre uma ou mais relações e produz como resultado uma relação. 2. Um operador stream-relação que opera sobre uma stream e produz como resultado uma relação. 3. E um terceiro operador relação-stream que opera sobre uma relação e produz como resultado uma stream. Quando necessária a transformação de uma stream noutra stream, deve ser usada uma composição dos operadores acima referidos. 27

40 Uma query contínua Q é composta por uma árvore de operadores que pertencem a um dos tipos anteriormente definidos. O input desta query são as streams e as relações que serão inicialmente processadas pelas folhas da árvore e o output da query será o resultado do processamento do operador que estará na raíz da árvore (cf. Fig. 2.8). O resultado da query Q é uma stream ou uma relação conforme o tipo de operador que esteja na raiz da árvore. Fig Exemplo de query composta por diferentes tipos de operadores. Cada nó da árvore corresponde a um operador, sendo a cor que define o seu tipo. As relações que servem de input ou output são identificadas por R a j e as streams de input ou output são identificadas por S a..d. Cada operador que compõe a query Q, num determinado instante t, depende de todos os seus inputs existentes até ao momento t: estes inputs poderão ser tuplos de uma stream S i com timestamps t para cada stream de input S i ou relações instantâneas R j (t ) em que t t para cada relação de input R j. Da mesma forma, o referido operador produzirá como resultado num instante t tuplos de S com timestamp t se o resultado esperado do operador for uma stream S, ou uma relação instantânea R(t) se o resultado esperado for uma relação R, sendo o tipo de resultado consequência do tipo de operador em questão. Na Fig. 2.8 está patente a árvore em que consiste uma certa query, composta pelos diferentes operadores. Como exemplo de um operador relação-relação, temos o operador A, que recebe como input as relações R a, R b e R c nos instantes t 0, t 1 e t 2 e gera como output no instante t 4 a relação R d. De notar o facto de t 0, t 1 e t 2 não terem de ser necessariamente diferentes e de todos estes terem de ser anteriores ou iguais a t 4 (i.e., t 0,t 1,t 2 t 4 ). Para implementar os operadores relação-relação na CQL são usados os mecanismos tradicionais do SQL, explorando assim o poder expressivo deste e não acrescentando qualquer complexidade desnecessária. Temos também o exemplo de um operador stream-relação se considerarmos o operador B, que recebe uma stream S a como input e gera uma relação R e no instante t 5. Este tipo de operador no CQL é baseado no conceito de janela deslizante [22] sobre uma stream de dados, e pode ser expresso usando os seguintes tipos de janelas: 28

41 1. Uma janela deslizante baseada em tuplos, que aplicada a uma stream S, usa como argumento um inteiro N > 0 e produz uma relação R. Num certo tempo t, R(t) contém os N tuplos de S com os maiores timestamps t. O número de tuplos que farão parte da janela deslizante especifica-se colocando [Rows N] a seguir a S. Caso a janela deslizante não tenha limite definido, usa-se [Rows Unbounded] para especificar que a janela não tem limites e como tal será composta por todos os pares <s, t >, t t que pertençam a S. 2. Uma janela deslizante baseada em tempo, que aplicada a uma stream S, recebe como argumento um intervalo de tempo w e devolve uma relação R. Num instante t, R(t) contém todos os tuplos de S com timestamps entre t w e t. Especifica-se o intervalo de tempo w colocando [Range w] a seguir a S na query. Caso se queira especificar o momento actual (w = 0), usa-se [Now] a seguir a S. 3. E por fim, uma janela deslizante particionada, que aplicada a uma stream S, recebe como argumentos um inteiro N e um conjunto de atributos {A 1,,A k } de S, sendo especificada por [Partition By A 1,,A k Rows N]. Quando aplicada, faz com que a stream S seja particionada em diferentes substreams, cada uma destas baseada num valor idêntico dos atributos A 1,,A k, de seguida é aplicada uma janela deslizante com N tuplos a cada uma destas substreams, e como resultado devolve a união destas janelas. Por fim, temos o exemplo de um operador relação-stream se analisarmos o operador E da Fig. 2.8 que recebe uma relação R d no instante t 4 e como resultado gera uma stream S d. Existem três operadores deste tipo: 1. Istream, ou insert stream, que aplicada a uma relação R devolve uma stream S que contém todos os pares <s, t> sempre que o tuplo s pertença a R(t) R(t 1), i.e., sempre que o tuplo s tenha sido inserido em R no instante t. 2. Dstream, ou delete stream, que aplicado a uma relação R devolve uma stream S que contém todos os pares <s, t> sempre que o tuplo s pertença a R(t-1) R(t), i.e., sempre que o tuplo s tenha sido apagado de R no instante t. 3. Rstream, ou relation stream, aplicado a uma relação R, devolve uma stream que contém todos os pares <s, t> que estão em R no instante t (R(t)), i.e., todos os tuplos actuais de R são encaminhados para a stream S a cada instante. Como exemplo concreto da aplicação de todos estes operadores e conceitos, temos a seguinte query contínua que filtra uma stream S: Select Istream(*) From S [Rows Unbounded] Where S.A > 10 29

42 Para a query ser realizada serão efectuados uma série de passos: 1. A stream S é convertida numa relação através do operador stream-relação [Rows Unbounded], que insere na relação todos os pares que pertençam à stream. 2. O operador relação-relação S.A > 10 é aplicado à relação que resultou do ponto 1, resultando noutra relação já com o conteúdo filtrado. 3. Por fim, é mostrado uma stream com o conteúdo da relação gerada em 2, devido à aplicação do operador relação-stream Istream(*). Como uma das principais características do CQL é permitir realizar queries sobre streams, foram criados uma série de atalhos sintácticos e assumidos certos comportamento por defeito para permitir que a escrita dessas mesmas queries sobre streams possa ser feita de uma forma mais intuitiva. Usando estes mecanismos de simplificação, o exemplo anterior seria escrito da seguinte forma: Select * From S Where S.A > 10 Quando a query é registada no STREAM (sistema de gestão de streams de dados) para posteriormente ser executada, é compilado a partir desta um plano de query. Estes planos são compostos pelos operadores, que realizam o processamento dos dados, queues, que desempenham o papel de armazenamento temporário dos tuplos antes e depois do processamento de cada operador e sinopses, que encapsulam o estado interno de cada operador. Tome-se agora como exemplo a seguinte query que ilustrará a composição do plano de query resultante, composto pelos vários operadores, queues e sinopses: Select * From S1 [Rows 1000], S2 [Range 2 Minutes] Where S1.A = S2.A AND S1.A > 10 Neste exemplo existem quatro operadores: um select, um binary-join (é realizado um join entre as duas relações que resultam da aplicação do mecanismo de janela deslizante às streams S1 e S2), e duas instâncias do operador stream-relação que aplicam uma janela deslizante a cada uma das streams de input. As queues q 1 e q 2 contêm os dados provenientes das streams, a queue q 3 consiste no output da aplicação da janela deslizante [Rows 1000] à stream S 1, enquanto a queue q 4 tem o resultado da aplicação da janela deslizante [Range 2 Minutes] à stream S 2. A queue q 5 contém os elementos que resultaram da operação S1 [Rows 1000] JOIN S2 [Range 2 Minutes], enquanto a queue q 6 tem os elementos desta após a aplicação do Select (operador relação-relação). Na Fig. 2.9 é possível visualizar a organização deste plano de query. 30

43 Fig Composição de um plano de query composto por operadores, queues e sinopses. Por fim, salienta-se o facto da ferramenta para tratamento de eventos da Oracle (descrita de seguida) ser baseada neste sistema de gestão de streams de dados (os operadores, a própria CQL, etc.), tendo inclusivamente sido apresentado conjuntamente pela Oracle, StreamBase e universidades de Cornell e Stanford (estes últimos, criadores do STREAM) um artigo que defende a uniformização de uma extensão ao SQL para tratamento de eventos [23]. Neste artigo, salientam-se as diferenças entre a abordagem da Oracle baseada no STREAM e a abordagem implementada pela StreamBase, onde é demonstrado um exemplo que em certos casos, só uma das abordagens é que funciona correctamente, pelo que é proposto um modelo que funde as duas abordagens e que baseado neste modelo mais genérico, será possível criar um standard visto que o modelo no qual as abordagens assentarão será uniforme. O modelo sugerido acrescentou também expressividade às duas abordagens consideradas. A explicação mais detalhada dos mecanismos nos quais se baseia o STREAM justifica-se pela ferramenta da Oracle ter sido baseada neste e por ser esta que será utilizada no desenvolvimento da solução, na componente de tratamento de eventos. Temos também em [24] o exemplo de um sistema de processamento de eventos complexos que é implementado como uma extensão à arquitectura da EPCglobal apresentada anteriormente (cf. Secção 2.4.2) e que é considerada como o standard que rege a captura e difusão de eventos RFID. Este sistema é chamado de EPC Sensor Network (ESN) e acrescenta ainda o facto de integrar também o processamento de leituras provenientes de sensores wireless que possam estar ligados ao sistema. A componente fundamental deste sistema é o middleware responsável por permitir que todo o processamento seja realizado de forma eficiente de forma a permitir tratar um grande volume de eventos, desde que estes chegam vindos dos leitores ou sensores até que seja entregue informação relevante às aplicações de negócio. O ESN possui mecanismos de filtragem, agrupamento e agregação, para que à medida que os eventos são processados possam ser criados eventos complexos que condensam informação que originalmente vinha dispersa por vários eventos simples. 31

44 O STREAM, que pode ser considerado apenas como um motor de processamento de eventos, permite apenas que sejam definidas querys que definem o processamento de streams de eventos (processamento esse que possivelmente resultará em novos eventos complexos que serão depois inseridos noutra stream para serem novamente processados), não possuindo quaisquer interfaces (sem ser os mecanismos de streams ou relações descritos anteriormente) para receber eventos de dispositivos de leitura ou para enviar o resultado do processamento para aplicações que dele necessitem. O ESN além de todos os mecanismos necessários ao correcto processamento dos eventos possui ainda componentes que permitem a interacção com a fonte dos eventos e com os receptores de informação sobre os eventos. Mais concretamente, o STREAM implementa apenas e só o processamento de eventos, que por si só não realiza qualquer trabalho. Tem de haver também um conjunto de ferramentas que interajam quer com os dispositivos de captura de eventos, quer com os consumidores da informação resultante do processamento de eventos (tipicamente, a informação gerada pelo processamento de eventos é colocada numa queue que depois será consumida pela aplicação de negócio ou é feita uma invocação de um Web Service criado pela aplicação de negócio para que a informação necessária lhe possa ser enviada). Fig Arquitectura do EPC Sensor Network. 32

45 Estes componentes estão patentes no diagrama do ESN presente na Fig É de realçar a componente Extension ALE, que é uma extensão ao standard Application Level Events, que define a interface que tem de ser usada para que aplicações que necessitam de interagir com informação proveniente de qualquer tipo de tags o consigam fazer, sem que se tenham de se preocupar com a complexidade e heterogeneidade do meio através do qual as tags foram lidas. Esta componente permite a interacção entre as aplicações empresariais e o middleware existente no ESN. É no middleware que o processamento de eventos é executado, permitindo que as aplicações consigam aceder a informação de negócio relevante que não seria possível obter antes do processamento dos eventos. Como se pode ver na Fig. 2.10, o middleware (a cinzento) é composto por quatro componentes principais: o Event Handler, responsável por interagir com as diferentes fontes de eventos (leitores RFID ou sensores); a componente Event Database que permite armazenar os eventos temporariamente (ou permanentemente, para efeitos de auditoria ou histórico, por exemplo); o Event Processing Engine onde os eventos são filtrados, agrupados, agregados e onde poderão dar origem a eventos complexos e por fim o Event Action Unit, que gera acções específicas associadas a determinado tipo de evento complexo Oracle Complex Event Processing A solução da Oracle para tratamento de eventos [25] passa por uma arquitectura composta não só por um motor de processamento de eventos (Complex Event Processor, ou CEP) e uma linguagem que permite especificar regras de processamento dos eventos (Event Processing Language, ou EPL) mas por uma plataforma completa que permite que sejam realizadas queries sobre as streams de eventos e que estas mesmas queries possam estar completamente integradas com código Java especificado pelo programador, assente num modelo de programação que combina Plain Old Java Objects (POJO) com a Framework Spring. Esta plataforma funciona como um servidor aplicacional onde as aplicações que serão desenvolvidas com base nesta arquitectura serão instaladas e executadas. Foi definido no início do desenvolvimento da plataforma que um dos principais requisitos arquitecturais seria o de não sacrificar a performance de todo o sistema em prol de uma plataforma de desenvolvimento tão rica como a que é apresentada, tendo resultado numa arquitectura que permite um desenvolvimento flexível e à medida mesmo em aplicações que exigem um processamento em tempo-real. A plataforma da Oracle para o processamento de eventos complexos é composta por três camadas principais que podem ser observadas na Fig. 2.11: a camada da Runtime Java, a camada do processamento de eventos complexos e a camada do ambiente de desenvolvimento. Na camada inferior, temos a Runtime Java que é composta pela Máquina Virtual Java (Java Virtual Machine, ou JVM) e as principais classes Java. Em cima desta camada, reside o processamento de eventos complexos (Oracle Complex Event Processing), implementado usando APIs standard do Java SE 5. É recomendado pela Oracle que o processamento de eventos corra em versões específicas da JVM, nomeadamente Oracle JRockit e JRockit Real Time, para que sejam assim atingidas as menores latências possíveis nas aplicações desenvolvidas. Quando é necessário 33

46 um grau de determinismo maior, é recomendado o uso da JVM JRockit Real Time que é baseada na Oracle JRockit mas que acrescenta a esta extensões que permitem que o garbage collection seja determinístico. O Complex Event Processing é um container Java implementado com uma arquitectura modular e flexível baseada na Framework OSGi. Os serviços que este apresenta incluem serviços fundamentais como os que permitem que sejam realizadas funções de logging, segurança e gestão de aplicações e serviços mais específicos a aplicações orientadas a eventos, como serviços de gestão de streams e o motor de processamento de eventos propriamente dito. Esta camada contém também um kernel responsável pela calendarização e sincronização de threads em tempo real com especial cuidado para que sejam mantidos uma baixa latência e o determinismo necessários em aplicações deste tipo. As aplicações desenvolvidas nesta plataforma e que consistem numa mistura de POJOs com queries EPL podem ser dinamicamente instaladas no servidor (container) e aceder aos vários serviços disponíveis através do mecanismo de injecção de dependências existente através do Spring. Existe também um sistema de monitorização integrado na Framework que permite a monitorização precisa da latência dos eventos processados e um ambiente de desenvolvimento baseado em plugins para o Eclipse, que completam a arquitectura apresentada na Fig Fig Arquitectura da plataforma Complex Event Processing da Oracle, adaptado de [25]. É de referir também que esta plataforma para tratamento de eventos assenta no protótipo proposto em [15] na Universidade de Stanford, pelo que a EPL referida anteriormente não é mais do que a CQL definida em [18] e o conceito de processadores, streams e queries realizadas a estas é integralmente adaptado desse mesmo protótipo, como se poderá ver de seguida. Na Fig apresenta-se um exemplo de um fluxo de dados de uma aplicação desenvolvida usando o CEP da Oracle. Do lado esquerdo entram na aplicação streams com dados vindos de uma 34

47 ou mais fontes. De seguida, os dados são recebidos e convertidos numa representação interna de um evento no Adapter correspondente. Esta representação interna pode ser um Objecto Java definido programaticamente ou um Map Java. À medida que o adapter cria os objectos que representam os eventos, envia-os para os componentes que se registaram como estando à escuta deste mesmo adapter (estes componentes são chamados de listeners). No exemplo são as streams que estão à escuta do respectivo adapter. Uma stream é essencialmente uma queue associada a uma pool de threads que permite que componentes que participem em ambos os sentidos do fluxo de eventos possam ser executados assincronamente. Não existe qualquer obrigação em incluir uma stream no caminho que os eventos percorrem, porém a presença de uma stream é útil pois permite aumentar a concorrência no acesso aos eventos que de outra forma seria realizado de forma sequencial. Fig Fluxo de dados típico de uma aplicação assente na plataforma Complex Event Processing da Oracle. As streams do exemplo ligam os adapters ao Processor (ou processador). Um processador representa uma instância do motor de processamento de eventos e possui um conjunto de queries escritas em EPL. Estas queries suportam a filtragem, agregação, pattern matching, e a junção de streams de eventos. O resultado das queries EPL é enviado para qualquer componente que esteja à escuta do processador em questão. No exemplo da figura, um POJO está à escuta do processador, podendo realizar um pós-processamento dos eventos que resultaram da execução das queries, despoletando determinadas acções ou enviando informações relevantes para os sistemas externos através de mecanismos standard (como é o caso do JMS) ou de protocolos de comunicação proprietários, uma vez que é permitido programar completamente a forma como o POJO desempenha as suas funções, uma vez que este é especificado em Java. Ao conjunto de adapters, streams, processadores e POJOs ligados entre si dá-se o nome de Event Processing Network (EPN), pois é através da rede construída por estes componentes e respectivas ligações que os eventos fluem e consequentemente são processados. 35

48 Em [26] é apresentada a arquitectura sugerida pela Oracle para o processamento e monitorização de eventos no âmbito do tratamento e encaminhamento de bagagens num aeroporto, que aplica a plataforma CEP para executar o processamento de eventos, uma componente de Business Activity Monitoring (BAM) para mostrar o estado do processo de tratamento das bagagens e um Service Bus para ligar os vários módulos que compõem a arquitectura, tudo componentes da Oracle. No diagrama (cf. Fig. 2.13) são apresentados os vários componentes da arquitectura, as suas responsabilidades e a forma como estes comunicam entre si. Fig Arquitectura proposta pela Oracle no âmbito do tratamento de bagagens num aeroporto. Após o processamento dos eventos provenientes do processo de Baggage Handling no Event Server (que usa a plataforma CEP), o resultado é enviado quer para a componente Situational Awareness, responsável por demonstrar a situação actual do processo de tratamento de bagagens (BAM) e por permitir a orquestração de eventuais processos de negócio (Business Process Management/Business Process Execution Language, BPM/BPEL), quer para o Service Bus, que depois se encarregará de entregar a informação relevante às aplicações de negócio que dela precisam. Os eventos processados podem ser não só eventos de leitura das malas no percurso que estas fazem mas também eventos originados pelos vários sistemas existentes num aeroporto, como o sistema de controlo de partidas ou o sistema de gestão operacional do aeroporto. Poderá ou não existir o armazenamento dos eventos processados numa base de dados, para efeitos de auditoria, registo e mesmo recuperação de falhas, podendo esse armazenamento ser implementado no Event Server, através de um POJO que recebe todos os eventos e que os persiste numa base de dados, por exemplo. Frischbier em [27] compara a solução de captura e tratamento de eventos provenientes de leitores RFID da Oracle com a solução da SAP (SAP Auto-Id Infrastructure, ou AII) para o mesmo efeito e conclui que a solução da Oracle apresenta duas grandes vantagens, que é a de suportar de origem as interfaces mais comuns, reduzindo assim a necessidade de se terem de criar adapters 36

49 específicos para se ligarem os dispositivos ao Event Processor e o facto do desenvolvimento das aplicações na plataforma da Oracle ser mais simples e flexível devido ao CEP possuir uma arquitectura modular muito bem definida e permitir a fácil adopção de componentes desenvolvidos por terceiros através da programação de um adapter específico, usando uma linguagem standard como o Java Sistemas Semelhantes Existem actualmente alguns protótipos de sistemas de monitorização do processo de tratamento de bagagens, dos quais se realça o protótipo implementado no aeroporto de Pequim, tendo o seu desenvolvimento sido descrito detalhadamente em [28, 10, 29]. Em [7, 30] avalia-se o uso do RFID como método de identificação das bagagens em sistemas de monitorização do processo ao qual as malas são sujeitas, concluindo-se no primeiro caso, através de testes a um protótipo testado em laboratório, que o RFID na monitorização de bagagens pode melhorar significativamente todas as operações num aeroporto relacionadas com as malas e a segurança em todo o processo de tratamento; já no segundo caso, conclui-se através dos resultados obtidos da análise da implementação do RFID nos sistemas de processamento de bagagens de 400 aeroportos que os erros no tratamento das bagagens podem ser reduzidos no mínimo em 10%. Esta melhoria acontece sobretudo devido ao aumento da taxa de leitura das etiquetas das malas em relação ao uso dos leitores de códigos de barras, podendo ainda aumentar se a informação mais precisa proveniente das leituras RFID for também usada nos sistemas que gerem o processo de tratamento das malas, visto que na análise realizada não foram consideradas as melhorias que esta tecnologia traz no aumento da informação histórica disponível, na redução de operações manuais (como as leituras manuais de códigos de barras) ou na verificação dos contratos de nível dos serviços (Service Level Agreements, ou SLAs) estabelecidos entre os diferentes participantes no processo. Fig Arquitectura proposta por Ting et al. para um sistema de monitorização de bagagens distribuído (adaptado de [29]). 37

50 Em [28, 10, 29], Ting et al. define gradualmente uma arquitectura de um sistema de monitorização de bagagens semelhante à solução que será proposta e que também utiliza como método de identificação a tecnologia RFID. Um protótipo do sistema, baseado numa aplicação distribuída, que implementa a arquitectura sugerida foi implementado no aeroporto de Pequim (Beijing Capital International Airport, BCIA), com o objectivo de permitir a localização das bagagens no aeroporto. Em [29] sugere-se um sistema distribuído de monitorização da localização das bagagens, onde estas estão etiquetadas com uma tag RFID que é detectada através de leitores RFID, sendo os dados resultantes destas leituras depois processados pelo sistema de forma a obter informação inteligível. Por razões de eficiência, os dados resultantes têm de ser filtrados e aglomerados, passando a existir após esta triagem eventos complexos em vez de eventos simples (cada leitura de uma mala por um leitor pode ser considerado um evento simples). A informação sobre a localização de cada mala pode ser obtida remotamente, através da invocação de um Web Service (cf. Fig. 2.14) existente em cada sistema de monitorização, pelo que se considera que a arquitectura sugerida é orientada a serviços (Service-Oriented Architecture, SOA). Os dados provenientes da leitura das malas são enviados dos leitores para a camada de Middleware do sistema, que é responsável pelo Hardware Adapter, que abstrai as funcionalidades dos diferentes protocolos de I/O de cada um dos leitores, pelo Device Management que permite a gestão dos vários leitores ligados ao sistema e pelo Event Management, que permite a filtragem e aglomeração dos eventos, fazendo com que apenas eventos relevantes despoletem processos de negócio nas aplicações de negócio ou sejam registados para futura consulta. O componente Device Management implementa o conceito de leitor lógico e permite que sejam associadas streams de eventos a cada um destes leitores. O conceito de leitor lógico resulta da possibilidade de estar mais do que um leitor num mesmo ponto de monitorização para aumentar a taxa de leitura, pelo que esses leitores serão representados por apenas um leitor lógico do lado da aplicação. O Information Service (IS) contém um repositório local para armazenar informação relevante (i.e., informação resultante do processamento dos eventos em bruto gerados pelos leitores). É responsável por capturar a ocorrência dos eventos complexos que resultam do processamento da camada de Middleware e de os armazenar de forma eficiente no repositório local. Esta componente responde também a queries feitas através do sistema de monitorização local, obtendo os dados necessários à construção da resposta no repositório local. A camada de Integração permite que outros sistemas equivalentes na rede possam usar funcionalidades locais através do mecanismo de invocação de Web Services. As mensagens usadas são baseadas em XML, e é usado o WSDL (Web-Services Description Language) e o UDDI (Universal Description Discovery and Integration) para realizar a descrição, subscrição, descoberta, etc. dos Web Services existentes. 38

51 Quando o Location Tracking Web Service (LTWS) presente na camada de Integração de um sistema deste tipo recebe uma mensagem SOAP (que tem de respeitar obrigatoriamente o WSDL que descreve o Web Service invocado) e essa mensagem contém uma query sobre a localização de uma tag (que corresponde a determinada mala), o LTWS envia os parâmetros contidos na query para o Information Service Manager (ISM) que é responsável por gerar uma instrução XQuery. Consoante os parâmetros da query, essa instrução é enviada ou para o IS local ou para um IS remoto. Quando o IS questionado responder, o ISM obtém as coordenadas da mala contidas na resposta e passa essas mesmas coordenadas ao LTWS, sendo este por fim responsável pela invocação de um Geographic Information System (GIS) através da sua API (UI Service) para apresentar geograficamente os locais por onde a mala passou. No diagrama patente na Fig está explícito o procedimento de localização aqui descrito. Fig Procedimento de localização de uma mala (adaptado de [29]). Em [10] Ting et al. continua a descrever a implementação do sistema de monitorização no aeroporto de Pequim, descrevendo a topologia do sistema implementado e a sua distribuição física pelo Terminal 2 do aeroporto. Na Fig pode observar-se a colocação de diversos leitores (na figura chamados de Tracking Readers) ao longo dos vários percursos que as malas podem percorrer, para que possa ser monitorizada a progressão destas ao longo de todo o seu processo de encaminhamento. No Anexo C pode ser observado um diagrama que ilustra a organização dos vários componentes do sistema, as suas responsabilidades e ainda os módulos que compõem cada um destes componentes. Nesse diagrama é possível verificar que o protótipo proposto tem também uma componente que pode comunicar com o passageiro através do envio de uma mensagem escrita para o seu telemóvel, informando-o assim da chegada sem contratempos da(s) sua(s) mala(s) ao avião previsto. Por fim é analisada também a viabilidade de um sistema como o implementado em termos de reduções de custos, melhoria da eficiência dos processos, investimento e infra-estrutura necessária. Desta análise concluí-se que o uso da tecnologia RFID no contexto do tratamento de bagagens é muito superior à identificação através da leitura de códigos de barras e que apesar do investimento inicial ter de ser superior (não pelo custo dos leitores, mas sim pelo custo das tags) o investimento 39

52 será compensado por uma melhoria acentuada na eficiência do processo e pela redução real dos erros no processo de encaminhamento, visto estes poderem ser corrigidos num curto espaço de tempo após terem acontecido. Na Tabela 2.4 compara-se o uso do RFID com o uso dos códigos de barras num conjunto de factores relevantes para os sistemas de tratamento de bagagens, resumindo as vantagens que o RFID acrescenta quando comparado com a leitura de códigos de barras. Fig Colocação dos leitores RFID ao longo do processo de encaminhamento das bagagens. Tecnologia Alcance Anti-Colisão Memória Programação Leitura por humanos Penetrabilidade Códigos de barras RFID (UHF EPC Class 1 Generation 2) < 10 cm Não Pequena Limitado Limitada Impossível < 10 m Sim Grande Flexível Impossível Boa Tecnologia Influência de sujidade Degradação com o uso Velocidade de leitura Encriptação Investimento Código de Leitores: barras/tag: Códigos de barras Muito alta Limitada Baixa (~ 4 seg) Não Alto Baixo RFID (UHF EPC Class 1 Generation 2) Sem influência Sem influência Muito alta (<1600 tags/seg) Sim Baixo Alto Tabela 2.4. Comparação do RFID Com códigos de barras no contexto do tratamento de bagagens. 40

53 2.7. Oracle Business Activity Monitoring Pretende-se que a solução desenvolvida apresente a informação resultante da monitorização do processo de encaminhamento de bagagens de uma forma clara e facilmente acessível. A componente da solução responsável pela apresentação dos indicadores de negócio será desenvolvida utilizando o Oracle Business Activity Monitoring (Oracle BAM), que permite monitorizar eventos de negócio vindos de um qualquer sistema que agregue vários processos de negócio. Assim, é possível melhor compreender a relação entre a ocorrência de determinado evento (ou a combinação de diferentes eventos) e o impacto que esta tem nos indicadores de performance do negócio monitorizado, aumentando a informação disponível sobre os processos de negócio em questão. Esta informação é fundamental para a contínua melhoria da eficiência dos processos monitorizados. Fig Diagrama arquitectural do Oracle Business Activity Monitoring. Como o Oracle BAM permite realizar a monitorização ao nível do processo de negócio, é possível saber sempre que eventos originaram uma situação de excepção, visto que se consegue saber que eventos é que precederam a excepção e em que ponto do processo de negócio é que estes ocorreram. Assim, consegue-se observar uma relação causal entre os vários eventos e entre os eventos e o impacto que estes tiveram no processo de negócio. Para que isto seja possível, o Oracle BAM assenta numa arquitectura baseada na troca de mensagens e maioritariamente residente em memória para que se consiga analisar em tempo-real os eventos que surgem e apresentar relatórios 41

54 que expressam constantemente o estado actual do processo de negócio. Com uma arquitectura deste tipo, não é necessário consultar a informação armazenada em base de dados para se obterem dados úteis sobre o processo de negócio (os sistemas tradicionais usam queries sobre um data warehouse), visto que toda a informação é obtida em tempo-real, assim que os eventos são gerados e dão entrada no Oracle BAM. Na Fig pode-se observar o diagrama arquitectural que relaciona os vários componentes do Oracle BAM, responsáveis pela integração de dados, colocação dos dados necessários em cache (data caching), monitorização e análise dos dados, alarmística do processo de negócio e por fim, pela elaboração e entrega de relatórios. O Enterprise Link é a componente do Oracle BAM responsável pela integração de dados. Permite o movimento, transformação e carregamento dos dados de entrada para o Active Data Cache do Oracle BAM. Os dados de entrada podem ser obtidos de várias fontes, tais como: Web Services, queues de mensagens ou ficheiros de texto. É possível também obter através do Enterprise Link dados históricos de data warehouses convencionais usando para isso queries, permitindo assim que possam ser gerados alertas baseados na comparação da informação recebida em tempo-real com o desempenho médio do processo de negócio proveniente de dados históricos. A Active Data Cache (ADC) é o sistema de armazenamento do Oracle BAM, baseado em memória, persistente e transaccional, que apresenta um elevado desempenho, nomeadamente nos tempos de acesso, possibilitando desta forma a monitorização constante dos dados que chegam em tempo-real à ADC. O termo dados activos contrapõe-se ao termo dados históricos, visto que é utilizado para caracterizar os conjuntos de dados que reflectem, em (quase) tempo-real, a situação do objecto da monitorização. A ADC armazena também todas as definições e configurações usadas na execução de todas as componentes do Oracle BAM. Apesar de toda a informação presente na ADC ser armazenada persistentemente de forma a existir sempre uma cópia de segurança, a ADC foi especificada de forma a tirar partido da grande quantidade de memória RAM existente actualmente em qualquer servidor. O Event Engine do Oracle BAM monitoriza em tempo-real as alterações aos dados provenientes das diversas fontes e outras situações que possam ocorrer no processo de negócio, através da verificação constante de regras e condições definidas pelo utilizador. Como resposta a essas alterações pode despoletar uma série de acções, incluindo a notificação do utilizador através de alertas e/ou relatórios. É esta componente que permite que os utilizadores monitorizem efectivamente o seu negócio e que detectem determinadas situações, podendo assim actuar de forma precisa, no momento exacto e caso seja necessário, informar a pessoa certa. O Active Reports Engine (ARE) do Oracle BAM obtém e formata a informação necessária para a criação de relatórios, que serão depois apresentados ao utilizador através do Active Viewer. Os relatórios podem incluir uma combinação de gráficos, tabelas, folhas de cálculo, indicadores de performance (Key Performance Indicators, KPIs), etc. Quando o utilizador solicita a apresentação de um relatório, o ARE obtém um snapshot que representa o estado mais recente de todos os dados presentes na ADC e que é utilizado para criar a 42

55 apresentação inicial do relatório. O ARE cria também uma ligação entre o relatório e a ADC para que futuras alterações aos dados utilizados na apresentação inicial do relatório sejam também apresentadas no relatório, possibilitando assim que o utilizador aceda ao segundo a informação sobre o processo de negócio monitorizado. A Report Cache do Oracle BAM permite que o acesso aos relatórios acedidos recentemente seja mais rápido, pois coloca estes relatórios numa cache antes de os preencher com os dados relevantes e de os entregar ao utilizador que os solicitou. Quando o relatório for novamente solicitado, este já existe em cache, eliminando assim o overhead do acesso à base de dados. O Message Center do Oracle BAM é responsável por notificar os utilizadores (através de e- mail, mensagens instantâneas ou SMS) caso sejam detectadas pelo Event Engine situações de excepção ou que de alguma forma exijam a notificação dos responsáveis pelo processo monitorizado. A arquitectura que o Oracle BAM apresenta permite que este aceda aos dados provenientes de diversas fontes e entregue a informação relevante ao utilizador final em poucos segundos. Este processo começa pela detecção de alguma alteração ou pela ocorrência de algum evento no processo de negócio monitorizado, que gera uma mensagem que chegará ao Enterprise Link. Quando o Enterprise Link recebe a mensagem, invoca o procedimento que foi definido para tratar do tipo de mensagens em questão. Como resultado do procedimento, os dados na Active Data Cache são actualizados e quer o Event Engine quer o Active Reports Engine são notificados da alteração. Caso ainda não esteja presente, o relatório que será actualizado com os novos dados é colocado na Report Cache. O Event Engine avalia o conjunto de regras definidas pelo utilizador e caso alguma delas se verifique, despoleta a acção correspondente, como por exemplo utilizar o Message Center para enviar um alerta para um ou mais utilizadores. Caso seja necessário apresentar num relatório informação sobre alguma das verificações realizadas pelo Event Engine, esta informação é enviada para o Active Reports Engine. Se no momento em que o ARE é notificado estiverem a ser visualizados pelos utilizadores relatórios que mostram ou que envolvem alguns dos dados que foram alterados, o ARE actualiza permanentemente esses relatórios até que o utilizador os feche. A interacção entre o utilizador e o Oracle BAM faz-se através do Active Viewer, Active Studio, Architect e Administrator. O Active Viewer é a interface que o utilizador usa para aceder aos relatórios. Através do Active Studio o utilizador responsável pela configuração da monitorização do processo de negócio pode criar e editar os relatórios a apresentar. A criação dos relatórios implica a selecção dos campos a apresentar, a formatação e filtragem da informação que será apresentada e a selecção dos tipos de vistas que serão utilizados no relatório (gráficos de barras, listagens, etc.). É também no Active Studio que se podem criar regras que definem os momentos em que os relatórios serão criados e entregues aos utilizadores. É através do Architect que são criados os data objects que serão colocados na Active Data Cache para serem posteriormente utilizados na criação de relatórios. A criação dos data objects implica a definição dos procedimentos que serão utilizados para preencher os objectos a partir dos dados recebidos através do Enterprise Link. 43

56 O Administrator permite que o administrador do Oracle BAM faça a gestão dos utilizadores e do servidor em que o Oracle BAM está instalado. Além da normal gestão dos utilizadores (criar ou apagar utilizadores), é possível também definir níveis de segurança para utilizadores e objectos a que estes acedem, obtendo-se assim um controlo mais fino dos acessos. A gestão da Active Data Cache e a manutenção e configuração dos serviços que o Oracle BAM disponibiliza também é realizada através do Administrator Síntese Neste capítulo foram referidas algumas soluções comercialmente distribuídas para monitorização do processo de tratamento de bagagens. No entanto, estas soluções surgem como consequência da adopção de um novo sistema de tratamento e encaminhamento de bagagens, não permitindo apenas a implementação do sistema de monitorização. Foi também introduzido o processo de tratamento de bagagens, os diversos procedimentos que este implica e a distribuição num aeroporto dos sistemas que o executam. Todo o processo implica o uso de diferentes standards, garantindo assim a correcta interacção entre as várias entidades que nele participam. Foram explicadas as mensagens trocadas entre sistemas intervenientes no processamento das bagagens e a semântica da informação que compõe essas mensagens. Estando esta dissertação inserida no desenvolvimento de um projecto de monitorização em que o mecanismo de identificação das malas utiliza tecnologia RFID, foram analisados alguns standards nesta área, juntamente com a arquitectura recomendada para a captura e difusão de informação proveniente de RFID. Foi dada especial atenção ao tratamento de eventos provenientes de diversas fontes de informação, pois grande parte do processamento executado pela solução consiste precisamente no tratamento de eventos. Enumeraram-se os vários requisitos que um sistema de processamento de eventos deve cumprir para que consiga desempenhar a sua função com sucesso. Neste capítulo foram também analisados diversos sistemas de processamento de eventos existentes, tendo sido analisada em detalhe toda a teoria que suporta o sistema de processamento de eventos utilizado no desenvolvimento da solução. Em menor detalhe, foram estudados sistemas que permitem o processamento de eventos, salientando-se a componente de processamento de eventos utilizada na solução (Oracle Complex Event Processing). Efectuou-se a análise de sistemas, que à semelhança do que é proposto nesta dissertação, têm como objectivo monitorizar o processamento de bagagens num aeroporto. Por fim, foi ainda analisada a arquitectura do Oracle Business Activity Monitoring, que permite apresentar informação sobre processos de negócio das mais diversas formas e que será utilizada na solução implementada. 44

57 3. Arquitectura da Solução A solução proposta de seguida baseia-se em vários elementos resultantes da pesquisa que culminou no trabalho relacionado anteriormente descrito. Todos os standards em vigor e as práticas recomendadas pela IATA foram tidas em conta para que a solução se adequasse ao contexto real de um aeroporto, visto que um demonstrador que implementa um sistema idêntico ao aqui descrito será entregue no âmbito do projecto em que esta dissertação se insere. Neste capítulo será descrita a solução de um ponto de vista arquitectural, dando-se particular importância aos principais componentes que a compõem, à forma como estes interagem e aos papéis que cada um destes desempenha durante a execução da solução. Para isso, serão descritos sucintamente cada um dos componentes, sendo de seguida apresentado o diagrama arquitectural que ilustra a forma como a solução está organizada. Serão enumerados também os requisitos que foram definidos como principais e que irão reger todo o desenvolvimento da solução Principais Componentes Na Fig. 3.1 estão presentes os principais componentes da solução: os componentes responsáveis pelo tratamento de eventos e pela criação dos indicadores de negócio (respectivamente Componente de Tratamento de Eventos, ou CTE e Componente de Indicadores de Negócio, ou CIN), o repositório de eventos (ou RE) responsável pela persistência dos eventos e informação de mais alto nível, a aplicação interface (ou AI) disponível através de Web e que permite o acesso a informação relevante sobre o estado das malas que estão sob monitorização, o Enterprise Service Bus (ou ESB) que permite o encaminhamento dos eventos e fornece mecanismos de gestão e balanceamento de carga que garantem a disponibilidade do serviço e por fim, o simulador de eventos (ou SE) que tem como principal objectivo a simulação de situações reais através do envio de sequências de eventos para que o sistema os processe e reaja de acordo com estes. A CTE é responsável pela recepção dos eventos e é nesta que as regras de processamento dos eventos são concretizadas, enriquecendo os eventos em bruto que dão entrada no sistema até que por fim novos eventos com informação de negócio resultantes deste processamento sejam gerados e encaminhados para as componentes que deles precisam, nomeadamente a componente responsável pelos indicadores de negócio. A CTE recebe não só os eventos vindos da camada Tags relativos a leituras de malas como também recebe eventos vindos dos sistemas externos do aeroporto que representam associações entre malas e voos (eventos vindos do sistema de controlo de partidas) e eventos operacionais do aeroporto (vindos do sistema de gestão operacional) e que representam, por exemplo, a partida ou chegada de um determinado voo. Esta componente é também responsável por persistir o seu estado interno e os eventos recebidos e gerados no repositório de eventos. 45

58 A CIN é composta pelas interfaces que permitem a recepção dos eventos com a informação necessária para que os indicadores de negócio possam ser apresentados, pelos mecanismos que convertem os eventos recebidos em informação inteligível para que esta possa ser apresentada nos relatórios que apresentam os indicadores de negócio e ainda pelos modelos dos relatórios que serão apresentados (sem estarem preenchidos com quaisquer dados). Tanto os modelos dos relatórios, como os dados que serão usados para preencher os relatórios são armazenados temporariamente em caches que também fazem parte da CIN. Fig Diagrama arquitectural da solução. A AI consiste numa aplicação Web que permite o acesso a informação sobre o estado do processo de encaminhamento das bagagens (localização das malas, estado do avião, alertas que entretanto tenha surgido, etc.) que tenha sido registada no repositório de eventos pela componente de tratamento de eventos. Como os eventos processados pela CTE são guardados à medida que surgem, a informação apresentada por esta componente não tem um atraso significativo em relação ao instante em que o evento de facto ocorreu, considerando-se, sem qualquer prejuízo para o utilizador, que a informação apresentada pela AI é a mais actual. 46

59 O ESB é responsável por disponibilizar uma interface standard que permite o envio de eventos de leitura de malas para o sistema de localização de bagagens e por encaminhar esses mesmos eventos para a CTE. Para tal é disponibilizado pelo ESB um Web Service que é invocado quando se pretende enviar leituras de malas para o sistema e que assim despoleta o encaminhamento da mensagem XML correspondente ao evento para a CTE. As mensagens enviadas pelos sistemas externos do aeroporto (DCS e SGO) passarão também pelo ESB através da invocação de um Web Service, sendo por fim entregues à CTE. A presença na solução de um ESB que desempenha o papel de intermediário entre os componentes que produzem eventos (sistemas externos do aeroporto e a camada Tags) e a CTE acarreta custos em termos de desempenho porque implica que por cada evento entregue à CTE exista um overhead adicional devido à inserção da mensagem XML na respectiva queue JMS por parte do ESB. No entanto, o uso de um ESB na solução reforça a separação de componentes visto que o emissor de eventos abstrai-se completamente do modo como a CTE receberá os eventos, sendo esta uma das características fundamentais de uma arquitectura orientada a eventos (Event- Driven Architecture, EDA) como é a arquitectura da solução apresentada. A presença do ESB favorece também o processo de alteração e/ou adição de novos componentes, visto que o ESB fornece uma interface standard (na arquitectura apresentada, um Web Service) que oculta os detalhes da forma como a informação é depois entregue à CTE. Caso seja necessário, o ESB permite fazer a validação e transformação dos dados enviados através da invocação do Web Service antes que estes sejam entregues à CTE. Todos estes factores justificam o uso de um ESB no sistema, ainda que este afecte o desempenho global do sistema. O repositório de eventos, tal como já foi referido anteriormente, permite que a persistência dos eventos seja concretizada, fazendo assim com que estes possam ser consultados posteriormente. É responsável também por armazenar o estado actual da CTE. É de referir ainda que a persistência dos eventos é realizada na CTE por uma thread própria para não prejudicar o desempenho da solução, dado que o acesso à base de dados acarreta um overhead significativo. O simulador de eventos envia directamente eventos para o sistema para que este possa assim ser correctamente testado ainda que na realidade não tenham acontecido quaisquer eventos. Para tornar a simulação mais flexível, é possível definir independentemente os momentos em que cada evento é enviado para o sistema Principais Requisitos Espera-se que a solução apresentada demonstre uma série de características qualitativas de forma a garantir que cumpra os objectivos a que se propõe. Na Tabela 3.1 apresentam-se as características qualitativas de alto-nível que se espera que o sistema desenvolvido cumpra, divididas pelas respectivas sub-características. As sub-características surgem como um refinamento das características qualitativas com o objectivo de as tornar mensuráveis (na realidade, as subcaracterísticas subdividem-se em atributos, sendo estes medidos com o recurso a métricas definidas). A nomenclatura e as definições aqui utilizadas seguem o modelo de qualidade definido pelo ISO [31] apresentado em [32], tendo sido complementadas quando necessário. 47

60 Característica Qualitativa Definição: Subcaracterísticas esperadas: Descrição da sub-característica: Funcionalidade Capacidade que um produto de software tem de fornecer as funcionalidades esperadas. Segurança Capacidade de um produto de software que permite evitar acessos não-autorizados a funcionalidades e/ou a dados, não afectando o acesso dos restantes utilizadores legítimos [33]. Fiabilidade Capacidade que um produto de software tem de manter o nível de desempenho esperado sob determinadas condições durante um determinado período de tempo. Disponibilidade Não é referida directamente no ISO 9126 mas depende das três subcaracterísticas da fiabilidade: robustez, tolerância a faltas e recuperabilidade. Em [32, 34] define-se disponibilidade como a capacidade de um produto de software conseguir desempenhar a sua função num determinado período de tempo e sob condições préestabelecidas. Modificabilidade Capacidade de um produto de software que permite a implementação de uma modificação especificada. Em [33] surge ligada ao custo que implica a implementação de uma modificação. Testabilidade Capacidade de um produto de software que permite que este possa ser validado. Em [33] é definido como a facilidade com que um produto de software permite demonstrar os seus erros através da execução de testes. Manutenabilidade Capacidade que um produto de software tem de ser modificado. Modularidade Não é referida directamente no ISO 9126 mas é considerado como uma sub-característica da manutenabilidade em [32]. Define-se como o número máximo de componentes que dependem de outro componente da arquitectura. Escalabilidade Definido em [35] como a capacidade que um produto de software tem de suportar o aumento do número de utilizadores e de recursos disponíveis sem que isso implique um decréscimo visível do desempenho ou um aumento da complexidade do sistema. Considerada uma sub-característica da manutenabilidade dado que se refere à facilidade com que os recursos utilizados pelo produto de software são modificados. 48

61 Característica Qualitativa Definição: Subcaracterísticas esperadas: Descrição da sub-característica: Eficiência Capacidade que um produto de software tem de apresentar o desempenho esperado. Comportamento em relação ao tempo Capacidade que o produto de software tem de apresentar tempos de resposta e de processamento esperados sob condições pré-estabelecidas durante o desempenho das suas funções. Portabilidade Capacidade que um produto de software tem de possibilitar a sua transferência entre ambientes diferentes. Adaptabilidade Capacidade de um produto de software que permite que este se adapte a diferentes ambientes específicos recorrendo apenas às funcionalidades implementadas. Tabela 3.1. Tabela de requisitos não-funcionais que o sistema desenvolvido deve cumprir. Dado que a conformidade de um produto de software com as características qualitativas esperadas passa pela medição dos atributos que fazem parte das respectivas sub-características [31, 32], o conjunto de sub-características apresentado na tabela anterior define o conjunto de requisitos não-funcionais que se espera que o sistema apresentado cumpra (doravante será utilizado o termo requisito não-funcional, ou RNF em vez de sub-característica, dado que têm o mesmo significado). Na Tabela 3.2 é descrita a forma como cada RNF será validado. Dado que a latência da solução apresentada é um dos comportamentos possíveis de medir em relação ao tempo e que o sistema proposto deve apresentar o estado do processo de tratamento de bagagens quase em tempo-real, a latência do sistema caracterizará a eficiência com que o sistema desempenha as suas funcionalidades. A latência do sistema refere-se ao período de tempo entre a entrada de um evento na CTE e a saída de um evento correspondente para a CIN relacionado com a entrada do primeiro. Note-se que poderão ser enviados vários eventos para a CIN como consequência da entrada de um único evento na CTE (um evento de leitura de uma mala poderá despoletar não só o envio de um evento de leitura para a CIN como também um evento de início de descarregamento de avião, por exemplo), pelo que a latência de um evento refere-se ao tempo desde que um evento entra na CTE até sair o primeiro evento correspondente da CTE em direcção à CIN. Requisito Não-Funcional Segurança Disponibilidade Validação: O sistema apresentado deve permitir que nem todos os utilizadores tenham permissões de acesso, dado que existe informação do processo de tratamento de bagagens que apenas deve estar acessível aos responsáveis pelo processo. Dado que o sistema proposto tem como objectivo a monitorização constante de um processo contínuo, este deve estar disponível durante 99,99% do tempo. 49

62 Requisito Não-Funcional Modificabilidade Testabilidade Modularidade Escalabilidade Latência Adaptabilidade Validação: Dado que o sistema apresentado é ainda um protótipo, todo o desenvolvimento deve ser bem documentado e regido por padrões de desenho para que o custo de uma posterior modificação seja minimizado. Tratando-se de um protótipo, é fundamental que desde o início do desenvolvimento existam ferramentas para assegurar o comportamento esperado das funcionalidades implementadas. Nenhuma das componentes da arquitectura apresentada deve depender de outras componentes também presentes na arquitectura. Para que tal aconteça, devem ser utilizados apenas mecanismos standard de comunicação entre as várias componentes. Dado que o protótipo apresentado será utilizado primeiramente em aeroportos de pequena dimensão, deve ser desenvolvido tendo em conta a futura adição de servidores que será necessária para que o protótipo suporte a carga de eventos associada a aeroportos de maior dimensão. O sistema deve apresentar uma latência de 5 segundos no máximo, pelo que não deve haver um desfasamento entre a detecção de um evento e a comunicação deste à CIN de mais de 5 segundos. O sistema deve estar preparado de raiz para se adaptar a qualquer configuração dos sistemas de encaminhamento de bagagens de um aeroporto, dado que se pretende que seja utilizado em vários aeroportos. Como tal, deve ser facilmente parametrizável, permitindo que os percursos de monitorização sejam alterados sem que seja necessário alterar qualquer funcionalidade implementada Síntese Tabela 3.2. Critérios de validação dos vários requisitos não-funcionais definidos para a arquitectura apresentada. Neste capítulo foi introduzido o diagrama arquitectural da solução e as componentes que o constituem. Foram enumeradas e descritas de uma forma genérica as responsabilidades de cada uma das componentes e a forma como estas interagem entre si. Referiram-se ainda os principais requisitos que devem ser cumpridos para que o sistema de monitorização desenvolvido apresente as funcionalidades esperadas e o desempenho necessário ao bom funcionamento do sistema. Na Tabela 3.3 apresenta-se um resumo dos vários elementos que compõem a arquitectura da solução com uma breve descrição de cada elemento. Nome Descrição: Permite realizar o check-in das malas de cada passageiro. É também Sistema de responsável por enviar Baggage Source Messages para o sistema de DCS Controlo de encaminhamento de bagagens do aeroporto e para o sistema Partidas apresentado, indicando a que voo cada mala está associada. 50

63 SGO CTE CIN AI RE ESB SE Tags Nome Sistema de Gestão Operacional Componente de Tratamento de Eventos Componente de Indicadores de Negócio Aplicação Interface Repositório de Eventos Enterprise Service Bus Simulador de Eventos Camada Tags Descrição: Sistema que gere todas as operações num aeroporto, tais como partidas de aviões, colocação de calços em aviões que chegaram, etc. Informa o sistema de monitorização que as referidas situações aconteceram através do envio de mensagens. Componente principal do sistema de monitorização. Recebe mensagens vindas do DCS, SGO e da camada Tags que representam diversos eventos e que são por si processadas. Após processamento dos eventos, envia a informação necessária para a CIN para que esta consiga apresentar os relatórios do processo de tratamento das bagagens. Realiza também a persistência dos eventos processados no RE. Componente responsável por apresentar os relatórios em tempo-real do estado do processo de tratamento das malas com base na informação que recebe da CTE. Pode ser acedida através da Web. Componente do sistema que permite consultar a informação resultante da monitorização armazenada no RE. Apresenta informação sobre as malas, o seu percurso, alarmes que possam ter sido lançados, etc. Permite que os passageiros possam aceder a informação actualizada ao segundo sobre o estado das suas malas. Para o pessoal responsável pelo processo de tratamento, é uma alternativa à CIN para consultar informação sobre o processo. Base de dados que armazena persistentemente o estado interno do sistema de monitorização e o histórico dos eventos processados. Bus que medeia a interacção entre DCS, SGO, camada Tags e a CTE. Concretiza a noção de separação entre componentes permitindo que posteriormente sejam substituídos componentes da solução sem que haja qualquer alteração dos componentes que permanecem. Ferramenta criada para testar a CTE. Permite enviar eventos que na realidade deveriam vir do DCS, SGO e da camada Tags. Camada de onde são enviados os eventos de leitura de malas para a CTE. Tabela 3.3. Resumo dos componentes da arquitectura da solução. 51

64 4. Descrição da Solução Neste capítulo serão apresentadas as diferentes componentes da solução implementada. Tanto o papel que cada componente tem na solução como o seu modo de funcionamento será descrito. Serão também introduzidos alguns conceitos fundamentais para a total compreensão dos mecanismos de processamento de eventos e os vários tipos de eventos usados na solução. Será descrito o modo de funcionamento da componente de tratamento de eventos, da componente de indicadores de negócio, da aplicação interface e da componente Enterprise Service Bus, sendo também apresentados alguns exemplos que ilustram o funcionamento de cada uma destas componentes Tratamento de Eventos A componente de tratamento de eventos (CTE) presente na solução desempenha toda a lógica de negócio existente e é responsável por, a partir da recepção de eventos básicos de diferentes tipos, inferir informação de negócio relevante que é depois encapsulada em novos eventos que serão por fim enviados ou para a componente responsável pelos indicadores de negócio (na forma de mensagens) ou então armazenados para efeitos de auditoria. Para tal, cada evento recebido despoleta uma série de procedimentos durante o seu processamento que poderão resultar na emissão de novos eventos (que serão também processados pela componente). Tipicamente, estes novos eventos gerados acrescentam informação útil que complementa a informação presente nos eventos que os originaram, obtida quer através da análise dos eventos originais quer a partir do estado interno da componente. Os passos descritos anteriormente processamento de um evento, execução de procedimentos e possível emissão de novo(s) evento(s) repetem-se iterativamente até que por fim a execução de procedimentos não despoleta a emissão de quaisquer eventos. Na solução aqui apresentada, quando esta situação se verifica não é necessário enriquecer o evento em questão (pois este já contém toda a informação necessária) e procede-se assim ao envio da mensagem com a informação correspondente à componente de indicadores de negócio (CIN), para que esta actualize os indicadores de negócio necessários Principais Conceitos Na subsecção 4.1 foram introduzidos alguns conceitos que envolvem a noção de eventos e o processamento destes. No entanto, para que a solução seja compreendida completamente e sem quaisquer ambiguidades, os conceitos a utilizar na descrição da solução devem ser definidos explicitamente. Assim sendo, apresentam-se de seguida as definições aqui utilizadas [36]. Define-se evento como uma ocorrência num sistema externo que aconteceu de facto ou que se considera que terá acontecido nesse mesmo sistema, ou então como uma entidade programática que representa a referida ocorrência num sistema computacional. Aplicando esta definição ao contexto em questão, tanto o acto da leitura de uma mala por um certo leitor (uma ocorrência num 52

65 sistema externo), como a mensagem XML enviada para a CTE (representação de uma ocorrência que se considera ter acontecido), como um objecto enviado dentro da CTE entre diferentes elementos que a constituem (entidade programática que representa uma ocorrência) são definidos como eventos. É de notar que as duas situações seguintes podem surgir: a ocorrência de um evento pode ser representada por mais que uma entidade programática (como se verificará de seguida, a primeira leitura de uma mala que está a sair de um avião não só é representada por um evento de leitura de mala normal, como também é representado por um evento de início de descarga das bagagens do avião); uma dada entidade programática que representa a ocorrência de um evento pode capturar apenas algumas das características da referida ocorrência. Na definição anterior foi usado o termo entidade programática quando se poderia ter usado simplesmente objecto. No entanto, apesar da grande maioria dos sistemas actuais de tratamento de eventos se basearem num paradigma de programação orientado a objectos, ainda existem sistemas em que a representação de eventos assenta em registos numa base de dados ou estruturas em C ou COBOL, daí que tenha sido utilizado o termo mais vago entidade programática. Doravante, será utilizado o termo objecto para descrever a entidade programática que representa a ocorrência de um evento, visto que a CTE presente na solução se baseia em Java. Todas as aplicações orientadas a eventos são formadas por componentes que geram os eventos que serão posteriormente processados produtores de eventos ; componentes que recebem os eventos processados e que tipicamente executam algum procedimento com base nestes consumidores de eventos ; e uma componente responsável pelo processamento dos eventos gerados pelos produtores processador de eventos, que poderá enviar eventos para os consumidores como consequência do processamento dos eventos originais. Na Fig. 4.1 podem observar-se os principais componentes arquitecturais de uma aplicação orientada a eventos. Fig Principais componentes de uma aplicação orientada a eventos [36]. A componente intermédia responsável pelo processamento dos eventos nos casos mais simples poderá apenas encaminhar ou filtrar os eventos que recebe vindos dos produtores de eventos. Contudo, das principais mais-valias que uma aplicação orientada a eventos oferece é o facto do próprio processador de eventos poder gerar eventos adicionais que serão também eles processados, actuando assim como gerador de eventos. Estes novos eventos gerados ou são reencaminhados para que sejam novamente processados ou então são enviados directamente para os consumidores de eventos. 53

66 Apesar do processador de eventos surgir na Fig. 4.1 como um componente monolítico, na realidade o processamento dos eventos é especificado como uma sequência de acções de cada um dos componentes que constituem o processador de eventos. Cada elemento que compõe o processador de eventos é definido como um agente de processamento de eventos, responsável por realizar uma parte do processamento de eventos. Usando a definição anterior, verifica-se que de um ponto de vista macro a CTE da solução é um agente de processamento de eventos, visto executar o processamento de eventos; no entanto e caso se observe apenas a CTE, iremos verificar que também esta se decompõe em vários agentes de processamento de eventos. Por processamento de eventos entenda-se então qualquer computação que realize operações sobre eventos, tais como operações de leitura, criação, transformação ou eliminação de eventos. Como foi referido anteriormente, o processador de eventos pode ser constituído por vários agentes de processamento de eventos. Estes agentes são especificados usando uma linguagem de processamento de eventos (ou Event Processing Language, EPL). As EPLs actuais apresentam um dos seguintes estilos: baseadas em regras, baseadas em scripts, assentes em extensões ao SQL ou baseadas noutras linguagens de álgebra relacionais. Na solução aqui apresentada é utilizada a ferramenta Oracle CEP para o processamento de eventos. A EPL que esta usa assenta numa extensão ao SQL que foi desenvolvida em Stanford [15] (cf. Secção 2.5.2). Os vários agentes que compõem o processador de eventos estão ligados entre si para que o(s) evento(s) resultante(s) do processamento de um agente possam ser enviados para o(s) agente(s) que se segue(m). Desta forma, os eventos que deram entrada no processador de eventos vão sendo processados ao longo dos agentes por que passam, até chegarem por fim aos consumidores de eventos. Ao conjunto de agentes de processamento de eventos e às ligações que existem entre estes dá-se o nome de rede de processamento de eventos (ou Event Processing Network, EPN). A ferramenta Oracle CEP permite ainda incluir na EPN outros elementos que não agentes de processamento de eventos e que também participarão no processamento dos eventos. A título de exemplo, podem existir elementos presentes na EPN que disponibilizam código Java e que podem assim conter lógica de negócio. Assim sendo, numa aplicação desenvolvida com o Oracle CEP, podem estar presentes na EPN os seguintes elementos [37]: - Processadores, que correspondem exactamente à definição de agente descrita anteriormente por serem os únicos elementos na EPN de uma aplicação Oracle CEP que são configurados através de uma EPL, neste caso através da Oracle CQL. São responsáveis pelo consumo de eventos normalizados vindos de um canal de entrada, pelo processamento desses mesmos eventos usando queries previamente definidas (usando para isso a EPL) e podem como resultado gerar novos eventos para um canal de saída; - Canais, responsáveis por ligarem elementos numa EPN. Têm como função guardarem temporariamente e por ordem de chegada os eventos que se destinam ao agente seguinte enquanto este não estiver disponível para os processar; 54

67 - Streams, desempenham as mesmas funções que os canais só que permitem também que o seu conteúdo e desempenho seja monitorizado através do visualizador que o Oracle CEP fornece e que o acesso aos eventos seja realizado de forma concorrencial; - Adaptadores, responsáveis por permitirem a interacção com o exterior. Para isso disponibilizam interfaces (que se situam na fronteira da EPN) que podem ser de entrada caso liguem os geradores de eventos à EPN, ou de saída caso permitam que os eventos resultantes do processamento sejam enviados para os consumidores de eventos; - Beans, que podem estar ligados a um canal e são despoletados aquando da inserção de um novo evento nesse mesmo canal. São elementos onde se coloca código utilizador que implementa a lógica de negócio, sendo geralmente objectos simples (POJOs). Caso seja necessário, podem ser usados serviços externos ao bean disponibilizados pelo Oracle CEP, como por exemplo JMS, Web Services ou acesso ao sistema de ficheiros para que assim os eventos processados pelo bean possam ser encaminhados para consumidores de eventos externos; - Event Beans, idênticos aos beans genéricos descritos anteriormente só que como utilizam a API do Oracle CEP, os beans deste tipo podem ser geridos e monitorizados pelo Oracle CEP; - Caches, usadas para armazenamento temporário de eventos, podendo ser usadas para aumentar a performance da aplicação se guardarem eventos e/ou objectos que são acedidos frequentemente durante a execução da aplicação. Na Fig. 4.2 estão presentes as representações gráficas de cada um dos elementos que podem constar de uma EPN e que serão utilizadas no diagrama da EPN presente na componente de tratamento de eventos. Fig Representações gráficas dos elementos de uma EPN Processador, Canal, Stream, Adaptador, Bean, Event Bean e Cache Eventos Utilizados Na componente de tratamento de eventos da solução aqui apresentada são usados vários tipos de eventos, desde os eventos mais simples que entram na EPN da solução até aos eventos mais complexos que contêm informação de negócio derivada da análise de vários factores (acontecimento de outros eventos concorrentes, estado interno da componente, etc.). Estes últimos surgem como resultado do processamento de todos os elementos da EPN, sendo por fim enviados para os consumidores de eventos da solução nomeadamente, a componente de indicadores de negócio. 55

68 Os eventos simples entram na EPN através de três adaptadores. Estes adaptadores são responsáveis por converterem as mensagens XML presentes na respectiva queue JMS em eventos simples e com uma semântica bem definida que serão de seguida injectados na EPN para posterior processamento. O adaptador baggagequeueadapter espera que cheguem à queue JMS BaggageReadQueue as mensagens XML que representam a leitura de uma mala em determinado ponto de monitorização. Assim que chegue uma mensagem, esta é convertida num evento de leitura (ReadEvent) que será introduzido na EPN para posterior processamento. Os eventos provenientes do sistema de controlo de partidas (DCS) que chegam à componente de tratamento de eventos representam uma associação entre determinada mala e um certo voo. Esta associação é fundamental para que se consigam monitorizar os percursos de cada uma das malas, visto ser esta que define o caminho que cada mala deve percorrer para chegar ao respectivo avião. Cada evento enviado pelo DCS apenas pode criar uma nova associação ou então apagar ou alterar uma associação já existente. Cada evento (AssociationReceivedEvent) gerado pelo dcsqueueadapter é o resultado da conversão das mensagens XML que representam operações do DCS presentes na queue JMS DCSQueue em eventos de associação, que serão consequentemente introduzidos na EPN. São ainda recebidos pelo sistema de monitorização de malas os eventos vindos do sistema de gestão de operações (SGO) do aeroporto. Este sistema é responsável num aeroporto por gerir vários processos operacionais num aeroporto, nomeadamente a carga e descarga das malas, o processo de check-in, os procedimentos necessários para que os aviões possam partir ou aterrar, etc. Vindos deste sistema, chegam à solução eventos que representam a colocação dos calços num avião que aterrou (ChocksOnEvent), a partida de um avião (TakeOffEvent) ou então o fim da recepção de malas para determinado voo nos balcões de check-in (CheckInClosedEvent). Os eventos vindos do SGO e introduzidos na EPN são obtidos a partir da conversão das mensagens XML presentes na queue JMS SGOQueue pelo sgoqueueadapter. No fim do processamento dos eventos na EPN são enviados eventos com informação de negócio relevante para a componente responsável por demonstrar o estado actual de todo o processo de tratamento das bagagens componente de indicadores de negócio. Estes eventos são colocados em queues JMS especiais (definidas como tópicos JMS, que funcionam segundo um método de publicação/subscrição) sob a forma de mensagens XML pelos três Event Beans que estão no fim da EPN (CommunicateBeans). O flighteventcommunicatebean é responsável por colocar no topic flighttopic mensagens XML que representam os eventos relativos a voos que este recebeu e que devem ser comunicados. Esses eventos podem ser os seguintes: entrada no sistema de um novo voo (NewFlightEvent); encerramento do check-in de um voo (CheckInClosedEvent); colocação dos calços num avião (ChocksOnEvent); partida de um avião (TakeOffEvent); início do carregamento e descarregamento de um avião (FlightLoadStartEvent e FlightUnloadStartEvent, 56

69 respectivamente); fim do descarregamento de um avião (FlightUnloadEndEvent) e por último, fim do tempo destinado à colocação das malas no carrossel de entrega (DeliverTimeEndedEvent). O baggageeventcommunicatebean coloca no topic baggagetopic mensagens XML que representam os eventos de bagagem que este recebe e que deve comunicar à componente de indicadores de negócio. Estes eventos podem ser leituras de malas (ReadEvent) ou eventos de negócio relativos às malas (AbstractBaggageBusinessEvent). Um evento de leitura pode ser relativo a uma mala que esteja associada a um voo (AssociatedReadEvent) ou não (NotAssociatedReadEvent). Caso a leitura de uma mala associada seja a primeira, então a mensagem XML enviada para a CIN corresponde a um evento FirstReadEvent. Em relação aos eventos de negócio relativos às malas, as mensagens XML podem exprimir associações entre malas e voos (AssociationEvent), o carregamento/descarregamento de uma mala no avião (LoadedEvent ou UnloadedEvent, respectivamente), a chegada de uma mala ao carrossel de recolha (DeliveredEvent) ou por último, a saída de uma mala do aeroporto após ter sido recolhida no carrossel (OutAirportEvent). O último dos beans de comunicação é o baggagealertcommunicatebean, responsável por colocar as mensagens XML relativas a eventos de alerta no topic alerttopic. Os eventos de alerta podem representar as seguintes situações: uma mala está associada a um voo e este parte sem que esta tenha sido carregada (BaggageMissingEvent); uma mala parte num voo sem estar associada a este (BaggageNotAssociatedEvent); uma mala demora mais que o esperado a percorrer um segmento do percurso de encaminhamento (BaggageTimeoutEvent); e por fim, uma mala é lida num ponto de monitorização que não pertence ao percurso que a levará ao voo a que está associada (BaggageWrongPathEvent). No Anexo E é possível verificar a hierarquia de eventos completa utilizada na EPN. Os eventos foram implementados como objectos Java simples (POJOs), tendo sido usado o mecanismo de herança do Java para melhor organizar os eventos existentes. Todos os eventos gerados na CTE são armazenados permanentemente no repositório de eventos pelo bean PersistenceStore que utiliza o bean de serviço de persistência (persistenceservice) para tal. O bean de serviço abstrai o acesso à base de dados, que é realizado através de uma ligação JDBC Descrição do Modo de Processamento O processamento dos eventos à medida que estes percorrem a EPN da CTE é realizado recorrendo a diferentes formas de enviar os eventos entre elementos, de executar procedimentos sobre estes e por fim de comunicar com o exterior, quer na entrada dos eventos na componente de tratamento de eventos quer na saída destes para a componente de indicadores de negócio. O enriquecimento dos vários eventos processados é realizado nos beans da EPN que são responsáveis por correlacionar os diversos eventos que fluem pela EPN e a partir daí gerar outros eventos complexos. 57

70 No Anexo D é possível observar a EPN completa, onde os vários elementos da EPN se interligam entre si para que o processamento dos eventos possa ser levado a cabo. Neste mesmo anexo apresentam-se também os vários elementos da EPN que apesar de não estarem directamente ligados à rede de processamento dos eventos, são injectados nos beans e adaptadores que deles precisam, através do mecanismo de dependency injection existente na Framework Spring na qual assenta a ferramenta Oracle CEP utilizada no desenvolvimento desta solução. Como exemplo de elementos da EPN nesta situação temos as caches e os beans responsáveis pelo acesso aos dados armazenados na base de dados (Data Access Objects) e os beans de serviço. Tome-se agora como exemplo a Fig. 4.3 onde está representada uma parte da EPN da solução responsável pelo processamento dos eventos vindos do sistema de gestão operacional (SGO) e pelo envio de eventos com informação de negócio como resultado desse processamento. Fig Parte da EPN responsável pelo processamento de eventos provenientes do SGO. Observe-se a título de exemplo a chegada à queue JMS SGOQueue de uma mensagem XML (cf. Tabela 4.1) que representa a partida de um avião do aeroporto. O sgoqueueadapter é responsável por obter a mensagem da queue e convertê-la no evento correspondente, usando para isso o bean messageparsingservice que permite realizar o parsing das mensagens XML vindas dos sistemas externos à solução (este bean foi injectado no sgoqueueadapter através dos mecanismos que a Framework Spring fornece). Como resultado da conversão obtém-se um TakeOffEvent que será introduzido na EPN. Conteúdo da mensagem XML <message> <type>take_off</type> <flight>ua423</flight> <timestamp> T12:00:00 </timestamp> </message> Descrição do campo - Início de mensagem; - Tipo da mensagem; - Referência do voo; - Instante em que mensagem foi gerada pelo SGO; - Fim de mensagem. Tabela 4.1. Exemplo de uma mensagem XML vinda do SGO que representa a partida de um avião. 58

71 O evento obtido é então introduzido na sgoinstream e chega simultaneamente aos três processadores que se seguem na EPN: chocksoncheckprocessor, checkinclosedcheck Processor e takeoffcheckprocessor. Praticamente todos os processadores na EPN da solução são utilizados apenas como filtros de forma a garantir que só os eventos com o tipo esperado é que prosseguem no segmento da EPN em questão. Como exemplo de uma query Oracle CQL que especifica um destes processadores temos a seguinte query do TakeOffCheckProcessor: SELECT * FROM TakeOffEvent retain 1 event Assim, caso chegue ao takeoffcheckprocessor um chocksonevent este evento é descartado neste processador pois foi configurado para apenas reter eventos do tipo TakeOffEvent. Este comportamento é seguro porque sabe-se à partida que o evento em questão será deixado passar no respectivo processador, permitindo assim traçar um caminho bem definido para cada tipo de eventos. Tendo passado no processador correcto, o evento chega ao takeoffprocessingbean, onde será processado segundo a lógica de negócio implementada no bean flightservice. Tanto neste caso como em todos os outros, os beans presentes na EPN não executam qualquer processamento sobre os eventos, delegando todo o trabalho para os beans de serviço, que são injectados através do Spring nos beans da EPN. Desta forma, os beans que estão na EPN são apenas responsáveis pela recepção de eventos e pelo possível envio de outros eventos como resultado da execução dos serviços sobre os eventos recebidos. Como consequência do processamento do evento TakeOffEvent pelo flightservice, o takeoffprocessingbean envia para o flighteventcommunicatebean um evento de partida do voo UA423 (para a componente de indicadores de negócio tomar conhecimento que o avião em questão partiu). Caso existam malas associadas ao voo que não tenham embarcado neste antes da partida, é enviado por cada mala nestas condições um evento de alerta (BaggageMissingEvent) para o baggagealertcommunicatebean, para que este possa avisar a CIN que aconteceu uma situação de excepção. Há ainda que salientar que o TakeOffEvent enviado pelo takeoffprocessingbean difere do TakeOffEvent original que recebeu do sgoqueueadapter, pois o evento que será enviado foi enriquecido com informação que à partida não existia: enquanto o campo airport do evento gerado pelo sgoqueueadapter não está preenchido, esse mesmo campo é preenchido pelo takeoffprocessingbean através da pesquisa pela informação do voo (FlightInformation) na base de dados. Assim, quando o evento chegar ao bean de comunicação flighteventcommunicatebean, este tem toda a informação disponível no evento. No caso do envio de eventos de alerta por parte do takeoffprocessingbean, o procedimento que é executado no flightservice verifica se cada mala associada ao voo em questão já se encontra dentro do avião. Para isso, compara-se o campo currentlocation de cada mala com o ponto de monitorização à entrada do avião, e caso coincida, sabe-se que a mala foi identificada quando estava a entrar no avião. Caso hajam malas que não tenham entrado por alguma razão no avião, a currentlocation destas não coincide com o ponto de monitorização à porta do 59

72 avião e consequentemente serão enviados eventos de alerta para o baggagealertcommunicatebean. Na Tabela 4.2 podem observar-se as mensagens XML enviadas para a componente de indicadores de negócio referentes aos eventos de partida do avião UA423 e ao facto da mala com LPN não ter embarcado no referido voo apesar de estar associada a este. Na mensagem de alerta, pode ver-se o tipo de alerta (MISSING), o instante em que foi detectado que a mala não partiu no avião ( T12:00:15) e ainda o código e descrição do último ponto de monitorização onde a mala foi monitorizada (SMA_CHKIN, ponto de monitorização no fim do processo de check-in). Com esta informação a componente de indicadores de negócio poderá apresentar uma série de indicadores que permitem avaliar o desempenho de todo o processo de encaminhamento das malas. Conteúdo da mensagem XML <message> <operation>take_off</operation> <flight>ua423</flight> <direction>outbound</direction> <timestamp> T12:00:00 </timestamp> <airport>sma</airport> </message> Descrição do campo - Início de mensagem; - Tipo da mensagem; - Referência do voo; - Direcção do voo; - Instante em que mensagem foi gerada originalmente pelo SGO; - Aeroporto em questão; - Fim de mensagem; <message> <alert>missing</alert> <flight>ua423</flight> <direction>outbound</direction> <timestamp> T12:00:15 </timestamp> <baggage> </baggage> Tipo de alerta; Referência do voo; - Direcção do voo; - Instante em que evento foi gerado pelo takeoffprocessingbean; - LPN da mala; <locationcode>sma_chkin</locationcode> - Código do ponto de monitorização; <locationdescription> Fim do processo de Check-In. </locationdescription> </message> - Descrição do ponto de monitorização; - Fim de mensagem. Tabela 4.2. Mensagens XML enviadas para a componente de indicadores de negócio. 60

73 O processamento de todas as outras mensagens provenientes dos sistemas externos à solução (leituras de malas, mensagens do SGO e DCS) é feito de forma análoga à descrita anteriormente para o processamento dos eventos de partida dos aviões: existe um adaptador que converte as mensagens nas queues em eventos e de seguida insere-os na EPN; é feito o encaminhamento dos eventos para chegarem ao respectivo bean; o bean delega o processamento do evento a um bean de serviço, encarregue de executar os procedimentos necessários; e por fim, como resultado do processamento do bean de serviço, podem ser enviados pelo bean um ou mais eventos que serão posteriormente processados pelo beans que os receberão. Contudo, a monitorização do tempo que cada mala demora em determinado segmento (delimitado por dois pontos de monitorização) é efectuada através de um mecanismo de emissão Fig Elementos da EPN que participam na monitorização das malas (adaptado do Anexo D). cíclica de eventos. Observe-se a Fig. 4.4 onde estão presentes os elementos da EPN que participam na monitorização dos percursos das bagagens através do processamento de eventos que representam leituras de malas ao longo dos pontos de monitorização. O baggagequeueadapter converte as mensagens XML que representam eventos de leitura de malas vindas da queue BaggageReadQueue em eventos ReadEvent. Estes eventos são depois enviados para o baggageprocessingbean, passando pela stream baggageinstream e pelo baggagemonitoringprocessor (que realiza a filtragem dos eventos, filtrando todos os eventos que não sejam eventos de leitura). Para processar os eventos, o baggageprocessingbean delega a execução dos procedimentos necessários ao bean de serviço baggagesupportservice. O bean de serviço cria o objecto de domínio Baggage caso a mala que foi lida ainda não exista em cache (baggagecache). Se esta foi a primeira leitura da mala, é criado um evento FirstReadEvent que será enviado posteriormente. 61

74 Caso a mala esteja associada a um voo (porque foi previamente processado na CTE um evento vindo do DCS que associou a mala a um voo específico), é criado um evento AssociatedReadEvent e o estado da mala é alterado para em monitorização (MONITORING). Assumindo que a mala está associada, é possível saber o percurso que esta deverá percorrer e como tal é verificado se o ponto de monitorização onde foi lida pertence ao percurso correcto. Se o ponto não pertencer ao percurso que levará a mala ao avião correcto, o estado da mala é alterado para WRONG_PATH e é criado um evento de alerta BaggageWrongPathEvent. Se a mala ainda não estiver associada a um voo, o estado da mala é alterado para não associada mas em monitorização (NOTASSOC_MONITORING) e é criado um evento de leitura NotAssociatedReadEvent. Se porventura o ponto de monitorização em que a mala foi lida for considerado o fim de um percurso, isto é, coincide com a entrada de um avião, é criado então um evento de alerta que representa a entrada de uma mala num avião que não está associada a qualquer voo (BaggageNotAssociatedEvent). Após a execução da lógica de negócio por parte do baggagesupportservice, os eventos criados anteriormente são enviados pelo baggageprocessingbean para os beans que se seguem: para o baggagealertcommunicatebean, no caso de existirem eventos de alerta (BaggageWrongPathEvent ou BaggageNotAssociatedEvent) que devem ser comunicados à CIN; para o baggageeventcommunicatebean, no caso de existirem eventos de leitura de uma mala (que esteja associada ou não) que têm de ser comunicados à CIN; e por fim, para o baggageassociatedprocessingbean, caso existam eventos de leitura de malas que estejam associadas a algum voo. É de notar que um evento AssociatedReadEvent que representa a leitura de uma mala associada será enviado tanto para o baggageassociatedprocessingbean, que é responsável pela execução da lógica de negócio relativa a malas associadas como para o baggageeventcommunicatebean, para este dar a conhecer a leitura de uma mala associada à CIN. No entanto, um evento FirstReadEvent será recebido apenas pelo referido bean de comunicação. Isto porque a query do processador que está entre o baggageprocessingbean e o bean de comunicação permite passar todos os eventos ReadEvent (e na hierarquia de eventos o FirstReadEvent herda deste). Já o processador entre o baggageprocessingbean e o baggageassociatedprocessingbean permite que apenas os eventos do tipo AssociatedReadEvent passem. Quando um evento de leitura de uma mala associada (AssociatedReadEvent) chega ao baggageassociatedprocessingbean, este delega o processamento do evento ao bean de serviço baggageassociatedservice. Caso o voo associado à mala em questão tenha partido, o estado da mala é alterado para não carregada (NOT_LOADED) e passa-se a considerar a mala como prioritária (RUSH), a fim de minimizar as consequências da mala não ter embarcado no voo correcto. É também neste bean que é monitorizado o tempo que cada mala demora em determinado segmento do percurso. Como todos os eventos de leitura que aqui chegam são de malas que estão 62

75 associadas a algum voo, sabe-se qual o percurso que estas devem percorrer, os pontos de monitorização que fazem parte deste e os tempos máximos que as malas devem demorar em cada segmento (delimitado por dois pontos de monitorização sequenciais que pertençam ao percurso). Suponha-se agora a existência da seguinte estrutura em que se guardaria, para cada mala associada, um tuplo composto por: o último ponto de monitorização onde esta foi lida e o ponto de monitorização seguinte no percurso esperado; o tempo em que foi efectuada a última leitura e o tempo máximo em que se espera que a mala seja lida no ponto seguinte. Para monitorizar situações em que as malas demoram mais tempo do que o suposto em determinado segmento (este atraso na maioria dos casos é sintoma de extravio ou tratamento incorrecto da mala no processo de encaminhamento) poder-se-ia criar um elemento na EPN responsável por percorrer constantemente a estrutura descrita, analisando cada tuplo desta. Caso haja uma mala em que a sua localização ainda coincida com o último ponto de monitorização referido no respectivo tuplo e o tempo máximo presente neste já tenha sido ultrapassado, considera-se que houve algum problema com a mala pois esta não percorreu o segmento em que se encontra no intervalo de tempo considerado normal. Assim sendo, a CIN é avisada desta situação para que os responsáveis pelo processo de encaminhamento das malas possam corrigir a situação anómala o mais rápido possível. Seguindo a anterior suposição, a componente que percorre a estrutura descrita teria de estar em espera activa, isto é, estaria num ciclo infinito a percorrer a estrutura, mesmo que esta não contivesse qualquer tuplo. Isto desperdiçaria milhares de ciclos de relógio, diminuindo a eficiência da componente de tratamento de eventos e sobretudo aumentando a latência de um módulo da solução que se quer o mais expedito possível, visto que num contexto real teria de lidar com milhares de eventos por minuto. Para evitar esta situação e não deteriorar a performance da CTE, recorreu-se a um mecanismo cíclico de emissão de eventos do Oracle CEP para concretizar a monitorização dos tempos. Quando um evento AssociatedReadEvent chega ao BaggageAssociatedProcessing Bean é criado um evento de monitorização de tempo (TimeoutCheckEvent) que contém a localização actual da mala referida no evento que foi recebido e o tempo máximo associado ao segmento em que está. O evento criado será enviado para o checkbaggagetimeoutprocessing Bean, sendo antes processado pelo baggagetimeoutmonitoringprocessor. A query que define este processador é a seguinte: SELECT * FROM TimeoutCheckEvent retain 10 seconds Isto significa que todos os eventos enviados para o bean de monitorização dos tempos serão entregues normalmente a este, permanecendo durante 10 segundos uma cópia dos eventos no processador. Até agora, todos os eventos enviados para os beans chegavam por defeito a estes vindos da Istream (ou insert stream ) dos processadores (cf. Secção 2.5.2, onde foram explicados os conceitos de Istream, Dstream e Rstream presentes no CQL do STREAM, usado na ferramenta Oracle CEP). No caso em questão, assim que um TimeoutCheckEvent chega ao processador, é enviado pela Istream para o bean que se segue porque respeita a condição da query (visto não existir qualquer condição, apenas tem de ser um TimeoutCheckEvent). Só passados 10 segundos do 63

76 evento ter chegado ao processador é que uma cópia deste sai pela Dstream do processador em direcção ao bean, visto que como o tempo em que o evento tem de permanecer no processador já expirou ( retain 10 seconds ), a condição já não é satisfeita. É este evento que fica retido 10 segundos no processador antes de chegar pela Dstream ao bean checkbaggagetimeout ProcessingBean que será processado. Quando o evento chega ao bean pela Dstream, este delega ao bean de serviço timeoutsservice a verificação do tempo máximo (isto é, se o tempo máximo já foi atingido). Caso o tempo máximo ainda não tenha sido ultrapassado e a mala ainda esteja no mesmo ponto de monitorização, o evento TimeoutCheckEvent é reenviado para o baggagetimeoutmonitoring Processor. Se a localização da mala já não coincidir com o ponto de monitorização referido no evento, o evento é descartado (visto a mala já ter percorrido o segmento em questão, já que foi detectada noutro ponto de monitorização). Se o tempo máximo tiver sido ultrapassado e a mala continuar no mesmo ponto de monitorização referido pelo evento, conclui-se que a mala demorou mais tempo do que o suposto a percorrer o segmento em que se encontra e como tal deve ser enviado para o baggagealertcommunicatebean um evento que representa o atraso da mala no segmento em que se encontra (BaggageTimeoutEvent). Fig Detalhe dos elementos da EPN envolvidos na monitorização dos tempos das malas em cada segmento. O mecanismo de retorno do evento ao processador e a retenção do evento neste durante 10 segundos antes ser novamente enviado para o bean concretiza a noção de emissão cíclica de eventos (cf. Fig. 4.5). Desta forma aumenta-se a eficiência e precisão da monitorização dos tempos porque se elimina o desperdício de ciclos de relógio quando não existem tempos para monitorizar e porque o intervalo de tempo que demora cada mala a ser monitorizada é exactamente o tempo definido na query do processador Modelo de Domínio Todos os objectos de domínio utilizados na componente de tratamento de eventos são Plain Old Java Objects (POJOs), funcionando apenas como objectos que agregam toda a informação relevante sobre determinada entidade existente no domínio do problema, não contendo qualquer lógica de negócio. Os conceitos de bagagem e voo são concretizados através das classes Baggage e Flight, respectivamente e contém os campos que se observam na Fig

77 Um objecto da classe Baggage contém a seguinte informação: a localização actual e as localizações anteriores da mala; o voo a que a mala está associada, a direcção que esta tem (caso o voo a que esteja associada seja de partida ou de chegada) e um historial dos voos a que a mala já esteve associada; o License Plate Number; o estado da mala (indica se esta não embarcou no avião esperado, se está sob monitorização, etc.) e o tipo (poderá ser uma mala prioritária, por exemplo); e por fim um booleano que representa se a mala se encontra no percurso correcto. Fig Classes de domínio Baggage e Flight e respectivos campos. A classe Flight contém várias informações sobre o voo, nomeadamente: um campo que representa a informação de voo (que encapsula a direcção e a referência do voo em questão), a referência alternativa, a data prevista do voo e a data actual do voo (poderão diferir em situações de atraso ou de algum imprevisto), o aeroporto (a que o voo se destina ou de onde vem o voo, caso o voo seja de saída ou de entrada, respectivamente) e o estado do voo (se já foi carregado, se tem os calços colocados, etc.). Existe também informação sobre os momentos em que a primeira e última mala saíram do avião e os momentos em que as mesmas malas foram colocadas no tapete de entrega, para permitir o cálculo do tempo de entrega das malas para cada voo, fundamental para a verificação do cumprimento dos SLAs entre entidades que participam em todo o processo de chegada dos aviões e respectivas malas. Existe ainda no objecto Flight informação útil para a monitorização das malas: referência de todas as malas associadas ao voo em questão; os percursos que as malas que estão associadas ao voo devem percorrer e por fim o conjunto de pontos de monitorização que compõem esses mesmos percursos. As referências dos pontos de monitorização (List<Checkpoint>) existem no objecto Flight apenas para evitarem o acesso ao objecto Path de cada vez que se quer aceder a um ponto de monitorização que pertença a um dos percursos do voo. Esta decisão surgiu devido ao grande número de acessos deste tipo, o que faria com que se tornasse num possível bottleneck no processo de monitorização das malas. No Anexo F é possível observar-se o diagrama que representa o modelo de domínio da componente de tratamento de eventos. 65

78 4.2. Indicadores de Negócio A componente de indicadores de negócio (CIN) tem como objectivo apresentar aos responsáveis pelo processo de tratamento das bagagens os relatórios com informação em tempo-real sobre todo o processo, desde o cumprimento dos SLAs pré-estabelecidos até à listagem de eventuais ocorrências que possam ter sucedido (atrasos de malas em determinado segmento do percurso, malas detectadas em percursos errados, etc.). Para tal, as mensagens enviadas pela CTE que representam a ocorrência dos mais variados eventos (leitura de mala, mala no caminho errado, mala descarregada do avião, etc.) são recebidas pela CIN através dos tópicos JMS alerttopic, flighttopic e baggagetopic. Estes tópicos contêm respectivamente, mensagens de alerta (indicam que uma mala não associada embarcou em determinado avião, por ex.), mensagens relativas a voos (informam o registo de um novo voo, por ex.) ou então relativas a malas (leituras de malas, associação entre malas e voos, etc.). O acesso a quaisquer dados no Oracle BAM é abstraído por um Data Object. A função dos Data Objects é a de colocar todos os dados em memória (na Active Data Cache) antes de estes serem acedidos, diminuindo assim a latência do acesso a quaisquer dados. Como os tópicos JMS são uma fonte de dados, o acesso a estes tem de ser abstraído através de um Data Object. Os Data Objects alertsmessages, flightmessages e baggagemessages abstraem o acesso aos tópicos descritos anteriormente. Cada Data Object pode ser visto como uma tabela, com um conjunto de campos e que contém uma série de registos. Como o Data Object baggagemessages abstrai o acesso ao topic JMS baggagetopic que contém mensagens relativas a malas, existe uma relação directa entre a informação presente em cada mensagem no topic e a informação presente em cada registo do Data Object. Após a recepção das mensagens, os registos dos Data Objects correspondentes são processados por um conjunto de procedimentos encadeados até que por fim são inseridas no Data Object criado para conter a informação processada. Dos Data Objects criados na CIN, além dos já referidos que abstraem o acesso aos tópicos JMS, existem também o infoalert, o infoflight e o infobaggage que contêm a informação proveniente das mensagens de alerta, de voos e de bagagens depois das manipulações necessárias (criação de campos derivados, por ex.). Os Data Objects Ocorrencias e SLAs, juntamente com o infoalert, infoflight e infobaggage contêm a informação que será apresentada nos relatórios consultados através do Active Viewer. A cada conjunto de procedimentos encadeados dá-se o nome de plano. Após a criação dos planos, deve ser configurada a frequência com que cada plano é executado, através do Plan Monitor presente no Administrator do Oracle BAM. Para que os planos obtenham as mensagens assim que estas chegam (em tempo-real), é necessário que estes corram ininterruptamente, isto é, que sejam reiniciados assim que terminem. Na Fig. 4.7 é possível verificar a configuração do plano BaggageMessage Plan no Plan Monitor. Este plano está configurado para reiniciar a sua execução após uma execução com sucesso ou após uma falha na execução do plano. 66 Fig Configuração do plano BaggageMessage Plan no Plan Monitor.

79 O BaggageMessage Plan é responsável por obter as mensagens XML do Data Object baggagemessages e realizar a manipulação necessária para actualizar ou criar um novo registo no Data Object infobaggage. Cada registo do infobaggage representa um evento relativo a uma mala. Cada registo representa um evento, que pode ser uma nova associação, uma leitura de mala, o carregamento de uma mala num avião, etc. O campo type do registo é que define o tipo de evento que este representa. Na Fig. 4.8 pode observar-se, a título de exemplo, o conjunto de procedimentos que compõem o plano em questão. Por cada registo no baggagemessages, verifica-se se este representa uma nova associação (NEW_ASSOCIATION). Depois é efectuado a alteração do nome de alguns campos para que o registo possa depois ser inserido no Data Object infobaggage. O elemento do plano que insere o registo no infobaggage é o BAM Update Baggage Association. Se existir um registo no infobaggage com LPN igual ao do registo que está a ser processado, os campos direction e flight são actualizados (a mala em questão está associada a um novo voo). Caso o registo não seja nem do tipo FIRST_READ nem do tipo NEW_ASSOCIATION, são adicionados ao registo os campos que ainda não existem neste e que fazem parte do Data Object infobaggage. De seguida o valor destes novos campos é calculado e o nome do campo timestamp é alterado para coincidir com os campos do Data Object resultante. No fim, o registo em questão é inserido no infobaggage. Fig Plano BaggageMessage Plan que executa a manipulação da informação proveniente das mensagens enviadas pela CTE para que possa ser apresentada pela CIN. O preenchimento de todos os Data Objects presentes na CIN é realizado de forma semelhante e é o resultado, como neste caso, da execução de um plano. Caso exista algum relatório cuja informação apresentada seja proveniente de um Data Object que tenha sido alterado, a informação que consta do relatório é actualizada para reflectir as alterações ao Data Object. Cada elemento dos relatórios apresentados (gráficos, listas, etc.) usa os dados presentes nos Data Objects para apresentar a informação da forma escolhida. Durante a criação dos relatórios através do Active Studio, cada elemento que fará parte do relatório é configurado, definindo assim qual a informação a apresentar: a média da monitorização de determinado SLA, ou a contagem de determinado tipo de registo num Data Object, por exemplo. 67

80 A Fig. 4.9 é um exemplo de um relatório de Operação da CIN para um voo de partida. Das três bagagens associadas ao voo, três embarcaram no avião correcto. O contador das malas embarcadas foi configurado para apresentar o número de registos do Data Object infobaggage que sejam do tipo LOADED, enquanto o contador de malas foi configurado para contar o número de registos que sejam do tipo NEW_ASSOCIATION (por cada registo deste tipo, sabe-se que existe uma mala associada a um voo). O gráfico de barras foi configurado para apresentar o número de leituras registadas em cada ponto de monitorização. Para isso, são contados os registos do tipo READ e agrupados segundo a informação do campo locationcode. Fig Relatório de Operação de um voo de partida. No Anexo H podem observar-se ainda os seguintes exemplos: um relatório de SLAs, que apresenta os mostradores com a média dos quatro SLAs que são monitorizados e a listagem dos SLAs por voo; e um relatório de Ocorrências, que mostra as ocorrências excepcionais referentes a bagagens e as ocorrências referentes a SLAs por cada voo (como por exemplo, o tempo de entrega das bagagens acordado entre o handler e a entidade que gere o aeroporto é excedido). As ocorrências relativas a bagagens correspondem às quatro mensagens de alerta enviadas pela CTE, nomeadamente: mala detectada num caminho errado; mala não associada a qualquer voo embarca num voo; mala associada a um voo não embarca no voo esperado; e por fim, mala demora mais tempo que o esperado a percorrer determinado segmento do percurso. No exemplo do relatório de Ocorrências presente no Anexo H, é possível ainda observar-se um gráfico da distribuição do número de ocorrências pelo tipo. Este gráfico mostra que foi detectada uma mala que demorou mais tempo do que o previsto a percorrer um segmento (tempo expirado) Aplicação Interface A aplicação interface (AI) tem como objectivo permitir a passageiros e responsáveis pelo processo de encaminhamento das malas o acesso a informação sobre o estado das malas, como a localização destas, locais em que estiveram anteriormente, se já embarcaram no avião, etc. Através da disponibilização imediata de informação sobre as malas aos respectivos passageiros consegue-se diminuir a insegurança que estes possuem relativamente ao processo a que são sujeitas as malas. 68

81 Devido à monitorização das malas constante e de forma activa, se porventura existirem erros no processo de encaminhamento das malas, esses erros serão detectados antes que dêem origem a eventuais atrasos ou outros imprevistos. Como o passageiro pode ter acesso à informação resultante da monitorização das malas, a confiança deste no processo de encaminhamento aumenta. A aplicação interface permite também que responsáveis pelo processo de encaminhamento das malas acedam à listagem de alertas agrupados segundo um critério pré-estabelecido (por voo, por intervalo de tempo, etc.) ou então acedam directamente aos dados que estão armazenados na base de dados e que são utilizados para mostrar aos passageiros toda a informação. É de notar que a aplicação interface não funciona em tempo real, isto é, funciona apenas como uma aplicação que permite o acesso a dados históricos, ainda que as leituras de malas façam parte da informação apresentada pela aplicação interface assim que estas sejam armazenadas na base de dados. Como mecanismo de obtenção de informação em tempo real sobre o processo de encaminhamento das malas existe a componente de indicadores de negócio, que notifica através de dashboards os responsáveis pelo processo de encaminhamento de bagagens assim que acontecimentos relevantes sejam detectados pela componente de tratamento de eventos. A AI foi desenvolvida utilizando o Grails, uma Framework open source para desenvolvimento de aplicações Web em Groovy, uma linguagem OO dinâmica baseada em Java e que quando compilada resulta em bytecode nativo Java VM. A escolha desta Framework baseou-se no facto da aplicação interface não ser o principal objectivo desta dissertação, pelo que eram necessárias ferramentas que permitissem o rápido desenvolvimento de uma aplicação Web. Como o Grails adopta um paradigma de programação definido como programação por convenção (isto é, todos os detalhes de configuração são escondidos intencionalmente do programador para que este apenas tenha que se preocupar com o desenvolvimento da lógica da aplicação), este foi escolhido para facilitar o desenvolvimento da AI. O Grails utiliza o padrão arquitectural MVC (Model View Controller), em que os controladores implementam o comportamento das páginas da aplicação Web (chamado de acção), as páginas são as vistas, que apresentam a informação ao utilizador da AI e que podem ser implementadas através de JSP ou GSP (Java Server Pages ou Groovy Server Pages, respectivamente). A informação apresentada é obtida do modelo, que é persistido para a base de dados através do mapeamento relacional de objectos do Grails (Grails object relational mapping, GORM), que por sua vez utiliza o Hibernate para concretizar o acesso à base de dados. Para o desenvolvimento da AI, para cada tabela da base de dados que fosse necessária consultar, foi criada a respectiva classe de domínio. O acesso à base de dados e os detalhes do carregamento de cada campo dos objectos de domínio a partir das respectivas tabelas na base de dados são abstraídos pelo GORM, sendo apenas necessário a correcta definição das classes do domínio. Depois foram criados os controladores que implementam a lógica necessária à apresentação da informação que foi considerada relevante quer para os passageiros quer para os responsáveis pelo processo de tratamento das malas. Cada controlador tem acesso às várias classes de domínio, obtendo assim a informação que será manipulada para de seguida ser apresentada pela 69

82 respectiva vista. Toda a parte gráfica da apresentação da informação é realizada nas vistas, concretizando estas a interface do utilizador. É possível também definir perfis de acesso na AI através do mecanismo de controlo de acessos que foi implementado, permitindo assim restringir o acesso a informação sensível por parte de utilizadores que não possuem as credenciais necessárias (os passageiros não devem ter conhecimento de quaisquer eventos de alerta, por exemplo). O controlo de acessos foi implementado utilizando para isso o Plug-in Spring Security disponível para o Grails. Como a AI é uma aplicação Web, basta fazer o deploy desta num qualquer servidor Web (GlassFish, Tomcat, Oracle AS, etc.) que permita instalar aplicações Web baseadas em Java (as aplicações Grails são desenvolvidas em Groovy, que compila para bytecode Java). Para se aceder à aplicação, basta aceder ao servidor em questão, como é possível observar na Fig Fig Exemplo de informação apresentada pela aplicação interface sobre a localização de uma mala. A informação apresentada na figura acima demonstra o percurso da mala com o LPN , desde que foi identificada às 17:48:30 à saída do check-in até que por fim deu entrada no voo TP123 pela entrada nº1 às 17:50:10. Entre a primeira e a última leitura da mala, esta foi identificada no ponto de monitorização A, à entrada do encaminhador, na saída nº1 do encaminhador, à entrada da zona temporária de armazenamento, à saída da zona de armazenamento e por fim no ponto de monitorização B, antes de ter entrado no respectivo avião. 70

83 4.4. Enterprise Service Bus Actualmente, qualquer sistema que pretenda usar extensivamente Web Services (apresente uma abordagem arquitectural orientada a serviços, Service-Oriented Architecture ou simplesmente SOA) ou que possua várias componentes implementadas usando diferentes tecnologias precisa de um produto que faça de intermediário entre as diversas partes que compõem a solução e que disponibilize uma interface comum baseada em standards que possa ser facilmente usada. O standard de eleição nestes referidos intermediários é o XML e por isso mesmo as componentes cujas interfaces assentem em XML adaptam-se sem quaisquer dificuldades à introdução de um elemento com as referidas características que medeie a comunicação. Independentemente de se considerar o Enterprise Service Bus (ou ESB) como uma arquitectura ou como um produto em si [38], existe um consenso em relação às características fundamentais de um ESB. A Gartner define um Enterprise Service Bus como uma nova arquitectura que explora Web Services, desempenha o papel de middleware entre vários emissores de mensagens, permitindo o encaminhamento inteligente das mensagens e a transformação destas quando necessário. Um ESB funciona como um backbone ubíquo que permite a integração de diversos componentes e serviços através do qual estes comunicam (não acarretando custos significativos em termos de complexidade). [39]. A presença do ESB da Oracle na arquitectura da solução proposta baseia-se nalgumas premissas consideradas fundamentais neste tipo de cenários [40]: a necessidade duma camada de abstracção entre os vários componentes do sistema para que este permita a posteriori a fácil adição de outros emissores de eventos que não os pré-estabelecidos; a garantia de que as mensagens enviadas são de facto entregues ao receptor e caso este não as possa receber imediatamente, as mensagens em questão são guardadas até que este as receba; a possibilidade de acontecer uma sobrecarga do sistema devido a um número muito elevado de mensagens que leve a que seja necessário usar um mecanismo de balanceamento de carga que não estava previsto inicialmente; caso seja necessário integrar os serviços disponibilizados pela solução num nível superior de integração com os restantes processos da organização que o utilizará, isto é possibilitado pelo ESB visto este utilizar standards bem definidos e adoptados num grande número de sistemas empresariais; o sistema tem de permitir que as ligações entre os vários componentes (chamadas ligações end-to-end), apesar de poderem ser de diferentes tipos, possam ser configuradas de forma semelhante e num único ponto central, facilitando assim a manutenção e gestão de todo o sistema; e por fim, garantir que todos estes requisitos possam ser satisfeitos da forma mais transparente possível para todos os componentes que fazem parte do sistema de localização de bagagens Descrição do Modo de Funcionamento O ESB permite definir um conjunto de interfaces standard para os vários componentes heterogéneos de uma solução, ligando as interfaces que criou às interfaces originais de cada um dos componentes. Além de ter o papel de intermediário na comunicação entre componentes, visto que encaminha as mensagens entre componentes, realiza também caso seja necessário a transformação 71

84 das mensagens que são enviadas, isto é, transforma a mensagem emitida por um componente para que esta possa assim ser recebida e compreendida pelo receptor. No diagrama da solução (cf. Fig. 3.1), é possível verificar que a camada Tags comunica com a componente de tratamento de eventos através da invocação de um Web Service. Esta camada é responsável pela gestão e execução de todo o processo de captura de eventos. As leituras das tags RFID das malas, já tratadas e eliminadas de eventuais erros, são o resultado deste processo que é depois enviado para a CTE. A interface criada no ESB é o Web Service (WS) através do qual são enviadas as leituras para a CTE. Cada invocação do WS representa a leitura de uma mala e consiste numa mensagem SOAP cujo corpo respeita o seguinte formato XML: <xsd:element name="baggagereadevent"> <xsd:complextype> <xsd:sequence minoccurs="1" maxoccurs="1"> <xsd:element name="lpn" type="xsd:string"/> <xsd:element name="flightdate" type="xsd:datetime"/> <xsd:element name="timestamp" type="xsd:datetime"/> <xsd:element name="locationcode" type="xsd:string"/> </xsd:sequence> </xsd:complextype> </xsd:element> A informação enviada para a CTE por cada leitura é composta pelo LPN da mala, pelo tempo e código do local em que a tag RFID foi lida e pela data do voo em que se espera que a mala parta. Esta informação é codificada na tag no momento em que esta é emitida e colocada na mala, nomeadamente no momento em que é feito o check-in desta (só assim seria possível saber a data do voo de cada mala). É necessário que a data do voo esteja na tag porque existe a possibilidade real da mesma mala ter duas tags RFID (a tag de um voo anterior não foi retirada, por exemplo), fazendo com que apenas seja possível distinguir o LPN correcto do obsoleto através da data de voo de cada uma das tags (a informação presente na tag mais antiga é descartada). Após a invocação do WS através da mensagem SOAP, o BaggageReadRoutingService (um dos elementos do ESB) encaminha a informação presente na mensagem até ao BaggageReadJMSAdapter que constrói a mensagem XML correspondente à leitura e de seguida insere-a na queue JMS BaggageReadQueue. Será desta queue que a CTE receberá posteriormente as leituras de malas. Na Fig podem observar-se os elementos que compõem o ESB e que executam o procedimento aqui descrito. Fig Composição da componente Enterprise Service Bus da solução. 72

85 4.5. Repositório de Eventos O repositório de eventos é a componente da solução responsável pelo armazenamento permanente dos eventos tratados pela CTE, funcionando como um histórico de toda a monitorização do processo de tratamento das bagagens. Esta componente assenta numa base de dados Oracle 10g Express Edition, com a qual a CTE interage através de JDBC (Java Database Connectivity). Já relativamente à AI, apesar de esta utilizar JDBC para aceder ao repositório, o acesso é abstraído pelo uso do GORM. No Anexo G pode observar-se o modelo Entidade-Relação da base de dados em que consiste o repositório de eventos Síntese Este capítulo iniciou-se com a descrição detalhada da componente de tratamento de eventos. Foram introduzidos os principais conceitos necessários à compreensão dos mecanismos de processamento de eventos, como a definição formal de evento e o conceito de rede de processamento de eventos (EPN), por exemplo. Foi também explicada a hierarquia de eventos utilizada na componente de tratamento de eventos, desde os eventos originais vindos de fontes externas ao sistema de monitorização, tais como as leituras de malas e as mensagens vindas dos sistemas de gestão e controlo do aeroporto até aos eventos enviados para a componente de indicadores de negócio, passando pelos eventos gerados no decorrer do processamento dos eventos originais. O modo de funcionamento da componente de tratamento de eventos foi explicado, seguindose os vários passos do processamento de um evento, desde que este entra na EPN até chegar à componente de indicadores de negócio. Apresentaram-se exemplos de eventos entregues à CIN representados por mensagens XML e analisou-se detalhadamente o papel dos vários elementos da EPN responsáveis pelo processamento dos eventos de leitura de malas recebidos pela CTE. Além do processamento de eventos realizado de forma linear, foi dado o exemplo presente na EPN da CTE da solução em que o processamento dos eventos é feito de forma cíclica, onde o bean em questão se retroalimenta caso seja necessário. Por fim, foi explicado o modelo de domínio utilizado na CTE. Sobre a componente de indicadores de negócio, o seu modo de funcionamento foi também descrito, sendo explicados os procedimentos executados após a recepção das mensagens XML enviadas pela CTE, a passagem das mensagens pelos planos definidos previamente e por fim, a apresentação dos relatórios recorrendo à informação armazenada nos Data Objects resultante do processamento dos planos. Foi também apresentado e explicado um plano configurado e foi dado um exemplo de um relatório de operação de um voo de partida. Descreveram-se também neste capítulo as funcionalidades da aplicação interface da solução, responsável por permitir o fácil acesso de passageiros e pessoal responsável do aeroporto a dados históricos do processo de tratamento de bagagens. Explicou-se como é que esta componente foi implementada e apresentaram-se ainda exemplos de informação apresentada pela AI. 73

86 Por fim, destacam-se ainda neste capítulo a explicação sobre o Enterprise Service Bus utilizado na solução, tendo sido referido o formato das mensagens que o Web Service disponibilizado por esta componente espera e a forma como as mensagens são encaminhadas para a respectiva queue. 74

87 5. Avaliação Experimental Neste capítulo serão descritos os testes realizados durante o desenvolvimento do protótipo. Haverá uma secção sobre os testes efectuados para garantir a correcção do desenvolvimento, nomeadamente os testes unitários e os testes de integração, criados para garantir a correcção das classes que implementam a lógica de negócio e a correcta interacção entre os diversos componentes da solução, respectivamente. Além da correcção dos métodos implementados, também foi necessário garantir que o protótipo desenvolvido suportasse a carga de eventos que seria gerada num cenário real. Para isso, foi utilizado um simulador de eventos que permite simular diferentes cenários num aeroporto (chegada de um avião e descarga das respectivas malas, por exemplo), através do envio sequencial de um conjunto de eventos para a CTE. Desta forma é possível verificar o comportamento da solução perante os vários cenários simulados. Por fim, será descrita a forma como foram realizados os testes à CIN para garantir a correcção dos indicadores de negócio apresentados aos utilizadores através dos relatórios e serão descritas as formas que foram encontradas para cumprir os requisitos não-funcionais definidos para a solução Testes de Desenvolvimento O desenvolvimento do protótipo foi continuamente testado através do uso de testes unitários, responsáveis por garantir a correcção de cada unidade de código presente no protótipo. Estes testes verificavam que o resultado da execução de cada unidade era o esperado, sendo em grande parte das vezes criados os testes antes da implementação da unidade testada (test-driven development). Foi dada especial atenção durante a criação dos testes unitários aos métodos dos beans de serviço porque são estes que encapsulam toda a lógica de negócio. Após a execução dos testes unitários, foram ainda criados vários testes de integração para garantir que os vários componentes da solução funcionavam correctamente como um todo Testes Unitários Os testes unitários consistem nos testes criados para garantirem a correcção das várias unidades de código que compõem a CTE. Estes testes foram criados recorrendo à Framework de testes unitários JUnit [41] que permite a fácil criação de testes unitários para aplicações desenvolvidas em Java. Todos os beans de serviço têm a respectiva classe de teste, na qual a correcção da lógica de negócio de cada método do bean é testada. Como exemplo temos o bean de serviço TimeoutsService cuja classe de teste é a TimeoutsServiceTest. Esta classe de teste é composta por testes que garantem o correcto processamento dos eventos TimeoutCheckEvent. Os seguintes cenários são exemplo de situações testadas por esta classe de teste: caso chegue um evento TimeoutCheckEvent que refira uma mala não associada, não deverá ser 75

88 realizada a monitorização dos tempos entre pontos de monitorização para a mala em questão (não estando a mala associada a um voo, não é possível saber o seu percurso logo o tempo máximo que esta pode demorar num segmento é desconhecido); caso chegue um TimeoutCheckEvent que refere um ponto de monitorização e cuja mala também referida por este entretanto tenha mudado de posição (já não se encontrando no ponto de monitorização referido), o tempo que a mala demora no segmento que inicia com o ponto de monitorização do evento não deve ser monitorizado porque a mala já se encontra noutro segmento. Como existe a dependência entre vários beans de serviço (o TimeoutsService necessita do BaggageService para obter as malas referidas pelos eventos de monitorização de tempos, por exemplo) poderia acontecer que um dos serviços não passasse com sucesso nos respectivos testes unitários devido a um erro no bean do qual depende e não de um erro no seu próprio código. Para evitar estas situações são utilizados mock objects, que neste caso simulam o comportamento do bean de serviço real. Para isso, são criados na classe de teste e por cada bean de serviço necessário (que não o bean de serviço que está a ser testado), um mock object que respeita a interface do bean que simula, imitando assim o comportamento deste. Assim é possível testar as unidades de código isoladamente, sem que seja necessária a correcção das dependências de cada unidade Testes de Integração Os testes de integração pretendem verificar que todas as componentes do protótipo desenvolvido interagem entre si da forma esperada. Para isso serão efectuados testes que exigem a participação simultânea de diferentes componentes da solução, verificando-se assim a correcta integração entre as diferentes componentes da solução. Antes de serem executados testes que necessitam da execução de todas as componentes da solução, são executados casos de teste que pretendem garantir a correcta interacção num subconjunto de componentes. Para se testar a invocação do Web Service disponibilizado pelo Enterprise Service Bus e que após a invocação era colocada uma mensagem XML na queue JMS BaggageReadQueue, foi usado o soapui, uma ferramenta open source para teste de Web Services. Após a invocação do Web Service, a respectiva mensagem XML foi lida pelo adaptador da CTE responsável por converter as mensagens presentes na BaggageReadQueue em eventos de leitura. Assim, verificou-se que tanto o Enterprise Service Bus como a ligação entre a CTE e as queues JMS estavam a funcionar correctamente. Foram também criados testes para garantir que a ligação entre a CTE e o repositório de eventos funcionasse correctamente. Todos os pormenores da ligação à base de dados são abstraídos pelos vários DAOs, ou Data Access Objects, que não são mais do que beans que permitem o acesso aos objectos de dados (FlightDao, BaggageDao, etc.). Os testes que garantem a correcta integração entre a CTE e o repositório de eventos são os testes que asseguram o correcto funcionamento de cada DAO. Estes testes não só testam a ligação, como também testam a correcta correspondência entre os objectos e respectivos atributos utilizados no modelo de domínio da CTE e as tabelas e respectivos campos da base de dados. 76

89 5.2. Simulação do Sistema Para permitir que o protótipo desenvolvido fosse testado em cenários o mais próximo possível da realidade, foi criado um simulador de eventos (SE) que interage com a CTE através de JMS (cf. Fig. 3.1). Como a solução implementada apenas recebe eventos através das queues JMS, criadas para a recepção de mensagens provenientes dos sistemas de gestão operacional e de controlo de partidas do aeroporto e dos vários leitores RFID, o simulador de eventos tem apenas de colocar as mensagens consoante a sua origem nas respectivas queues JMS. Do ponto de vista da CTE, esta não consegue distinguir se os eventos são originados pelo simulador de eventos ou se são realmente gerados pelos vários sistemas do aeroporto, visto que o SE apenas envia mensagens que respeitem na totalidade o formato das mensagens que a CTE espera. O simulador de eventos obtém as mensagens que serão enviadas de um ficheiro XML. Este ficheiro contém ainda, por cada mensagem, um campo <timeoffset> que especifica o tempo que deve ser esperado antes do envio da mensagem e um campo <type>, que define a origem da mensagem (se esta vem do SGO, do DCS ou se é uma leitura de mala). De seguida apresenta-se o exemplo de uma mensagem que supostamente teria sido originada pelo DCS e que é enviada pelo simulador de eventos: <event> <timeoffset>5</timeoffset> <data><![cdata[ BSM<.V/1TZRH<.I/ARR03/18APR/LIS/F<.N/ < ENDBSM< ]]></data> <type>dcs</type> </event> Esta mensagem representa uma Baggage Source Message cujo conteúdo está patente no nó <data> e indica que o voo de chegada ARR03 está associado a 10 malas e que o LPN da primeira é (cf. Secção 2.3.1). Tanto as mensagens provenientes do SGO como as mensagens que representam leituras de malas contêm um campo <timestamp>. Este campo indica o momento em que as mensagens foram geradas ou o momento em que as leituras foram realizadas. O formato utilizado no campo <timestamp> é YYYY-MM-DD'T'HH:mm:ss ( T12:00:01, por exemplo). O conteúdo deste campo na mensagem pode também ser #{currentdate}, que faz com que durante o envio das mensagens o simulador de eventos coloque no conteúdo do campo o tempo actual. No Anexo I podem ser observados exemplos de todas as mensagens usadas no simulador de eventos. Após a obtenção, através da leitura de um ficheiro, das várias mensagens XML que deveriam ser enviadas para a CTE, o simulador de eventos envia as mensagens pela ordem em que estas se 77

90 encontram no ficheiro. Antes do envio de cada mensagem, o simulador de eventos espera o tempo (em segundos) especificado no campo <timeoffset> da mensagem. Caso seja iniciado o simulador de eventos com o argumento (-a), o valor de tempo do campo referido deve ser considerado absoluto e não relativo, isto é, não deve ser esperado qualquer tempo entre o envio das mensagens, sendo o envio das mensagens feito no segundo especificado no campo <timeoffset> (sendo considerado o instante em que a aplicação começa como o segundo 0). Para garantir que o sistema desenvolvido se comporta da forma esperada foram criados cenários de partida e chegada de malas para serem posteriormente simulados através da emissão de mensagens pelo simulador de eventos. Como resultado destas simulações esperava-se não só confirmar o correcto funcionamento da CTE, mas também verificar: a correcta persistência dos eventos no repositório de eventos, a apresentação do histórico da monitorização através da aplicação interface e ainda a apresentação dos relatórios que contêm informação sobre o cumprimento dos SLAs, informação detalhada sobre as ocorrências excepcionais que possam ter acontecido durante o processo de tratamento das bagagens e ainda informação sobre as operações executadas por cada avião. Nos cenários de chegada, começou-se por testar apenas a chegada de um avião com todas as malas a serem entregues correctamente. Depois associou-se mais que um percurso válido ao voo em questão, para que as malas pudessem chegar ao tapete de entrega por mais do que um percurso. De seguida, alteraram-se os testes para que os eventos de leitura enviados pelo simulador de eventos despoletassem em diferentes pontos de monitorização alertas devido às malas terem demorado mais que o previsto em diferentes segmentos dos percursos. Por fim, criaram-se propositadamente eventos de leituras das malas em pontos de monitorização que não pertenciam a nenhum dos percursos associados ao voo para que fossem despoletados alertas devido às malas terem sido detectadas em percursos errados. Durante todas as simulações também se verificou se os eventos de mala descarregada do avião, mala colocada no tapete de entrega e mala detectada à saída do aeroporto eram correctamente enviados pela CTE para a CIN. Nos cenários de partida, a simulação foi feita da mesma forma, incrementando gradualmente a complexidade nos cenários. Além das situações também testadas nos cenários de partida, verificou-se ainda se eram enviados, pela CTE para a CIN, os seguintes eventos de alerta: mala em falta, quando um voo partia e nem todas as malas associadas tinham embarcado neste e mala embarcada incorrectamente, quando uma mala associada a um voo é detectada noutro avião que partiu. Houve o cuidado dos cenários criados conterem um maior número de pontos de monitorização do que na realidade existirão quando o protótipo for testado já no seu ambiente de produção e posteriormente, quando já tiver entrado em produção. Os cenários usados nos testes também tinham um número de malas monitorizadas semelhante ao que será esperado quando o protótipo já tiver entrado em produção. Desta forma conseguiu-se testar o protótipo com uma carga de eventos semelhante à carga de eventos no ambiente de produção. 78

91 É de salientar ainda que este protótipo consiste num demonstrador que será entregue ao cliente para demonstrar as possibilidades da monitorização em tempo-real do processo de tratamento de bagagens, estimando-se que os testes num ambiente real (com a instalação do protótipo nos servidores e com a captura de eventos realizada por leitores RFID reais) serão realizados apenas no fim de Outubro, pelo que não será possível a inclusão em tempo útil dos resultados destes testes na dissertação. Apesar de o protótipo ter sido desenvolvido numa máquina virtual que fica aquém da capacidade de processamento de um servidor, foi possível realizar a simulação dos cenários criados sem que o desempenho da máquina virtual impedisse a obtenção dos resultados esperados. De referir ainda que em produção, a componente de tratamento de eventos e a componente de indicadores de negócio devem ser instaladas em servidores diferentes porque a própria Oracle desaconselha fortemente a instalação na mesma máquina do Oracle CEP e do Oracle BAM, por razões de compatibilidade entre tecnologias e para garantir o desempenho necessário de ambas as componentes (ambas as componentes acedem à base de dados e como a base de dados utilizada no protótipo é essencialmente para fins de demonstração, não suporta acessos concorrentes que necessitam de utilizar várias ligações simultâneas à base de dados). Todas as componentes da solução estão instaladas na mesma máquina virtual que será entregue com o protótipo por uma questão de simplicidade. Apesar disto, o protótipo entregue apresenta-se totalmente funcional, sendo possível aceder simultaneamente quer à aplicação interface quer aos relatórios da componente de indicadores de negócio, enquanto a componente de tratamento de eventos, o Enterprise Service Bus e o repositório de eventos executam as suas funções. A máquina virtual entregue com o protótipo foi criada e testada numa máquina com um processador Intel Core 2 Duo T7300 a 2 Ghz, com 4 Gb de memória RAM, 500 Gb de disco rígido e com o Windows Server 2003 R2 com o Service Pack 2 instalado. Os cenários referidos anteriormente foram simulados usando a máquina virtual entregue, com todas as componentes a correr na máquina descrita sem quaisquer problemas Teste da Componente de Tratamento de Eventos Dado que não foi possível testar o protótipo desenvolvido no seu ambiente de produção (instalado nos servidores dedicados), apresenta-se aqui um estudo de benchmark [25] realizado pela Oracle que visa demonstrar a eficiência do processamento de eventos quando utilizado o Complex Event Processing da Oracle. No referido estudo, a latência dos eventos processados pelo CEP é medida no contexto de uma aplicação que trabalha com mercados de capitais, verificando-se que, com uma frequência de injecção de eventos na ordem do milhão de eventos por segundo, a aplicação desenvolvida alcança uma latência média de 67,3 microsegundos. O cenário em que a aplicação será testada é composto por um gerador de eventos que envia os eventos através de TCP/IP para a aplicação desenvolvida com o Oracle CEP, que por sua vez é composta por um adaptador, um processador de eventos e por fim por um POJO responsável por obter as medições da latência dos objectos. Na Fig. 5.1 é possível verificar o diagrama que ilustra o teste realizado. 79

92 Fig Diagrama da aplicação de mercados de capitais utilizada no benchmark do Oracle CEP. O gerador de eventos envia mensagens com dados sobre o mercado de acções através de uma ou mais ligações TCP com uma frequência de injecção de eventos configurável. O adaptador recebe as mensagens vindas de um socket, cria um evento por cada mensagem recebida e envia-o para o processador de eventos. Cada mensagem enviada é chamada de stock tick e é composta pelo nome da acção em questão e pelo último preço registado. O processador de eventos verifica, por cada uma das 200 acções diferentes, as duas situações seguintes: - O preço da acção aumenta ou diminui mais do que 2 pontos percentuais em relação ao último preço conhecido; - O preço da acção aumentou nos últimos 3 stock ticks. Dado que são 200 acções diferentes e são verificadas duas condições por cada acção, o processador de eventos contém 400 queries em CQL que concretizam as condições expressas anteriormente. Quando um stock tick recebido verifica uma das condições enumeradas é enviado um evento para o POJO, que mede a latência para o evento em questão e agrega os dados estatísticos para depois serem apresentados. Os tempos utilizados no cálculo da latência coincidem com o momento em que as mensagens são lidas do socket (antes da criação do evento) e com o momento em que o POJO recebe o evento. O gerador de eventos simula dinamicamente a variação de preços das diferentes acções usando um algoritmo geométrico com movimento Browniano, em que o preço de cada acção é actualizado antes de ser enviado. O adaptador foi configurado para utilizar uma thread por cada ligação com o gerador de eventos, sendo cada thread responsável pela criação dos eventos e pela injecção destes no processador de eventos. Foi utilizada uma máquina para o Oracle CEP e outra para o gerador de eventos, ligados por uma ligação Ethernet gigabit. As duas máquinas utilizadas eram idênticas e consistiam cada uma num servidor Intel Xeon com quatro processadores Intel X7350 Quad-Core a 2,93GHz cada (16 cores no total) com 8MB cache L2 por processador, 32GB de RAM e a correr Red Hat Enterprise Linux 5.0 de 32bits. Os testes realizados consistiram em duas sessões de testes: - Dez execuções em que o número de ligações ao CEP foi incrementado de 1 até 10, com uma frequência de mensagens por segundo e por ligação a serem enviadas pelo gerador de eventos, durante 10 minutos; 80

93 Latência máxima (milissegundos) Latência média (microssegundos) - Dez execuções em que se mantiveram 10 ligações ao CEP, com uma frequência de mensagens por segundo e por ligação enviadas pelo gerador de eventos a ser incrementada de até mensagens, durante 10 minutos. Os resultados obtidos com a execução das duas sessões de teste estão presentes no Anexo J (adaptados de [25]), apresentando-se de seguida os gráficos que ilustram os resultados obtidos. Nas seguintes figuras apresentam-se os gráficos que ilustram a primeira sessão de testes (Fig. 5.2 e Fig. 5.3), em que variava o número de ligações simultâneas entre o gerador de eventos e o CEP e a segunda sessão de testes (Fig. 5.4 e Fig. 5.5), em que variava a frequência de injecção de eventos por ligação. Latência média por eventos/segundo/ligação 80,0 70,0 60,0 50,0 40,0 30,0 20,0 10,0 0, Número de ligações simultâneas Fig Latência média obtida por número de ligações simultâneas (primeira sessão de testes). Latência máxima absoluta por eventos/segundo/ligação 25,00 20,00 15,00 10,00 5,00 0, Número de ligações simultâneas Fig Latência máxima absoluta por número de ligações simultâneas (primeira sessão de testes). 81

94 Latência máxima (milissegundos) Latência média (microssegundos) Latência média por frequência de injecção (10 ligações) 80,0 70,0 60,0 50,0 40,0 30,0 20,0 10,0 0,0 Frequência de injecção de eventos (eventos/segundo) Fig Latência média por frequência de injecção de eventos (segunda sessão de testes). Latência máxima por frequência de injecção (10 ligações) 25,00 20,00 15,00 10,00 5,00 0,00 Frequência de injecção de eventos (eventos/segundo) Fig Latência máxima por frequência de injecção de eventos (segunda sessão de testes). Pode concluir-se da análise dos gráficos aqui apresentados que o Oracle CEP, quando sujeito a uma carga de eventos significativa como a dos testes realizados em [25], não ultrapassa os 25 milissegundos de latência máxima, sendo que a latência média do processamento de eventos não chega aos 70 microssegundos em ambas as sessões de teste. Na componente de tratamento de eventos da solução, um evento passa no máximo (assumindo que o tempo que uma mala demora em determinado segmento é apenas verificado uma vez) por 9 elementos da rede de processamento de eventos da CTE (4 processadores, um adaptador e 4 beans). Dado que os processadores de eventos usados na CTE funcionam apenas como filtros, permitindo passar apenas os tipos de eventos esperados, a latência que cada processador implica é negligenciável quando comparada com o tempo de processamento nos vários beans presentes na rede de processamento de eventos da CTE. 82

95 Para verificar a latência apresentada pelo protótipo desenvolvido na máquina virtual utilizada no desenvolvimento da solução, foi criado um benchmark sintético que envolve a emissão de um certo número de eventos de leitura que resultarão em eventos de negócio, sendo depois registado o tempo entre a injecção do evento de leitura na rede de processamento de eventos e a saída do evento correspondente para a CIN. O teste realizado consistiu na geração de eventos de leitura com o simulador de eventos durante 10 minutos com um atraso de 1 segundo entre a emissão de cada evento, resultando na emissão de aproximadamente 600 eventos. A latência média observada neste teste foi de 42,54 milissegundos e corresponde ao tempo entre a criação do evento de leitura (ReadEvent) após obter a mensagem XML da respectiva queue e o envio do evento de leitura para a componente de indicadores de negócio no bean baggageeventcommunicatebean. A latência máxima observada neste teste foi de 696,71 milissegundos. Na Fig. 5.6 é possível observar a latência observada à medida que são enviados os vários eventos e a latência média calculada. Fig Latência medida durante 10 minutos de emissão de eventos com um tempo de espera entre eventos de 1 segundo Teste da Componente de Indicadores de Negócio Após se verificar o comportamento esperado da CTE nos vários cenários criados com o objectivo de simular situações de chegada e partida de voos e respectivas bagagens, foram executados os mesmos cenários mas agora com o intuito de verificar a correcção do comportamento da CIN. Como o desenvolvimento da CIN foi feito sobretudo usando as ferramentas gráficas disponibilizadas pelo Oracle BAM, não foi possível durante o desenvolvimento da componente a criação e execução de testes unitários para a CIN. No entanto, o Oracle BAM permite inserir, para efeitos de teste, registos nos vários Data Objects existentes, permitindo assim que os planos configurados pudessem ser testados. Após a inserção de registos nos respectivos Data Objects (alertsmessages, flightmessages e baggagemessages), todos os planos que se iniciam com a obtenção de dados dos referidos Data Objects são executados e como resultado são preenchidos os Data Objects que serão usados como fonte de informação para o preenchimento dos relatórios (cf. Secção 4.2). Desta forma é possível verificar que a manipulação dos registos dos Data Objects de 83

96 entrada foi efectuada correctamente e que os relatórios apresentaram a informação da forma esperada. Apesar da CIN ser a parte mais visível da solução implementada, a componente de indicadores de negócio está presente na solução sobretudo para demonstrar que é possível apresentar de forma gráfica a informação obtida a partir do processamento dos eventos resultantes da monitorização das bagagens. Como a CIN não contém lógica de negócio complexa, uma vez que apenas realiza as manipulações necessárias à apresentação da informação, esta não foi testada de forma exaustiva. Contudo, refira-se que são apresentados os níveis de cumprimento de todos os SLAs definidos como necessários na elaboração da especificação da solução Avaliação Qualitativa Na seguinte tabela enumeram-se os requisitos não-funcionais definidos para o sistema desenvolvido e a forma encontrada para cumprir esses mesmos requisitos. Requisito Forma como foi cumprido: Não-Funcional Segurança Disponibilidade Modificabilidade Testabilidade Modularidade Escalabilidade Na aplicação interface foi implementado um mecanismo de controlo de acessos em que é possível definir diferentes perfis de utilizador, podendo assim controlar-se a informação a que cada utilizador tem acesso. O protótipo desenvolvido não apresenta ainda a disponibilidade pretendida para um sistema desta natureza. Contudo, a arquitectura implementada apresenta vários elementos que permitem aumentar a disponibilidade da solução com um custo relativamente baixo, dado que é possível adicionar outra componente de tratamento de eventos paralela e que podem ser utilizados os mecanismos de persistência das queues de eventos. O desenvolvimento da solução utilizou vários padrões de desenho e todo o código foi comentado com o objectivo de não comprometer o desenvolvimento futuro da solução. Foi desenvolvido no âmbito da solução um simulador de eventos para testar cabalmente o comportamento do sistema de monitorização desenvolvido. Foi também utilizada uma Framework de testes para automatizar o processo de execução de testes unitários durante o desenvolvimento da componente de tratamento de eventos. Foram utilizados mecanismos standard de comunicação entre componentes (Web Services, JMS) e a sintaxe das mensagens trocadas está bem definida pelo que não existem dependências entre os componentes da arquitectura desenvolvida. Caso seja necessário escalar o sistema para que este suporte uma maior carga de eventos e/ou um maior número de utilizadores é possível alterá-lo através da adição de outras componentes de tratamento de eventos, de outras componentes de indicadores de negócio e outras aplicações interface, dado que existem mecanismos que permitem coordenar as várias réplicas das componentes e que poderão ser utilizados na solução no futuro (Oracle Coherence, mecanismos de balanceamento de carga do Enterprise Service Bus). 84

97 Requisito Não-Funcional Latência Adaptabilidade Forma como foi cumprido: Nos testes realizados na máquina disponível, a componente de tratamento de eventos apresentou uma latência máxima de 696,71 milissegundos (0,69671 segundos). Ainda que não tenha sido medida a latência de um evento até que este seja apresentado pela componente de indicadores de negócio, a latência total do sistema não deverá chegar aos 5 segundos, dado que os testes foram realizados numa máquina virtual suportada por uma máquina com hardware comum. É possível definir os percursos que as malas deverão percorrer bem como o tempo esperado para cada segmento sem que seja necessário alterar qualquer funcionalidade do sistema Síntese Fig Requisitos não-funcionais e a forma como estes foram cumpridos. Neste capítulo foram expostas as várias formas criadas para assegurar a correcção do protótipo desenvolvido. Foram utilizados durante o desenvolvimento do protótipo testes unitários e testes de integração, e nas fases mais avançadas do desenvolvimento foram simulados cenários reais usando para isso o simulador de eventos, também criado no âmbito do projecto. Os testes unitários permitiram assegurar a correcção de toda a lógica de negócio implementada na CTE e garantiam que após uma alteração à CTE, todas as funcionalidades anteriormente implementadas e testadas continuavam correctas. Os testes de integração asseguraram o correcto funcionamento da solução como um todo, uma vez que testavam a correcta interacção entre as várias componentes da solução. Quando o sistema já apresentava robustez suficiente, foram simulados vários cenários reais para garantir que a solução se comportava da forma esperada quando tinha de processar uma carga real de eventos. A simulação tornou possível a descoberta de algumas incoerências no comportamento da solução, tendo sido realizada a simulação de diversos cenários até que fossem corrigidos todos os erros da solução, que de outra forma teriam passado incólumes. Além da simulação de eventos utilizada também para verificar que os relatórios apresentados pela CIN eram correctamente actualizados, foram também inseridos, para efeitos de teste, registos nos vários Data Objects da CIN. Assim, foi possível testar isoladamente a CIN, antes da integração desta com a CTE. Desta forma garantiu-se a correcção e a robustez da solução desenvolvida. Como o protótipo criado é um demonstrador cuja finalidade fundamental é a de comprovar a possibilidade de criar um sistema com as características da solução aqui implementada (uma plataforma de monitorização flexível e escalável, que permite a obtenção de informação de cada uma das bagagens processadas num aeroporto), poderá acontecer que a solução final, que entrará em produção depois dos diversos testes em ambiente real, apresente algumas diferenças em relação ao protótipo aqui apresentado. No entanto, todos os conceitos basilares de uma plataforma de monitorização com as características referidas foram utilizados no protótipo, pelo que a versão final será um refinamento do trabalho até aqui desenvolvido. 85

98 6. Conclusões e Trabalho Futuro Neste capítulo será apresentado um resumo do trabalho que foi desenvolvido nesta dissertação, serão enumeradas as várias conclusões a que se chegaram com este trabalho, descrever-se-ão as principais contribuições geradas ao longo do desenvolvimento de toda a dissertação e serão ainda indicados alguns pontos que poderão ser melhorados ou adicionados à solução desenvolvida Conclusões Finais e Contribuições No âmbito desta tese, foi especificado um sistema de monitorização aplicado ao processo de tratamento de bagagens existente em qualquer aeroporto e consequentemente procedeu-se à implementação de um protótipo do sistema especificado. Era necessário que o sistema desenhado não impusesse a alteração e/ou adopção de quaisquer sistemas automáticos de tratamento de bagagens, podendo ser instalado de forma modular em qualquer processo de tratamento de bagagens. A forma como a solução interage com os sistemas do aeroporto e as funcionalidades que foram implementadas respeitam todos os regulamentos da IATA aplicáveis ao contexto em que a solução se insere, garantindo-se assim a adaptação do sistema desenvolvido a qualquer aeroporto. O protótipo implementado, ainda que servisse apenas como demonstrador da tecnologia utilizada, deveria também suportar, à partida, o número de pontos de monitorização e a carga de eventos que se espera que existam nos aeroportos onde o demonstrador primeiramente será testado (aeroportos de Ponta Delgada, Horta, Santa Maria e Flores). Os testes realizados no protótipo entregue, ainda que não tenham sido executados em máquinas equivalentes às que serão utilizadas em produção, garantem em parte que o protótipo desenvolvido suportará a carga de eventos esperada no ambiente de produção. Durante todo o desenvolvimento da solução evitou-se a criação de dependências entre os vários componentes, quer através do isolamento de cada um dos componentes quer através do uso de mecanismos de interacção entre estes considerados standards nos sistemas de informação empresariais. Como tal, é possível que qualquer componente da solução seja substituída por outra equivalente (mudar a componente de indicadores de negócio para que esta utilize uma ferramenta SAP, por exemplo) sem que para isso toda a solução tenha de ser alterada. O protótipo criado ilustra as várias vertentes de um sistema de monitorização, uma vez que foi implementada a componente responsável pelo processamento dos eventos, a componente que apresenta os relatórios do estado do processo, as componentes que permitem o armazenamento permanente de eventos e a consulta do histórico de eventos processados e ainda foi utilizado um Enterprise Service Bus na recepção dos eventos. Contudo, esta dissertação incidiu essencialmente sobre a temática do processamento de eventos, tendo sido analisada quer a teoria subjacente ao processamento de eventos quer a ferramenta utilizada na solução proposta que concretiza a teoria estudada, pelo que a componente de 86

99 indicadores de negócio presente no protótipo serve, no âmbito desta tese, apenas como prova conceptual de que é possível apresentar uma série de indicadores de negócio com base na informação obtida e processada pela componente de processamento de eventos da arquitectura apresentada. Ainda assim, é de realçar que a informação apresentada pela componente de indicadores de negócio consiste nos indicadores de desempenho solicitados pelo cliente do projecto no qual esta dissertação se insere, pelo que a informação contida nos relatórios apresentados é fruto de uma necessidade real e não apenas uma demonstração das possibilidades do sistema de monitorização proposto. O trabalho aqui desenvolvido não foi maioritariamente orientado a resultados, tendo sido realizado com um carácter sobretudo exploratório, visto que as várias tecnologias usadas (Oracle CEP, Oracle BAM, Grails, Oracle ESB) não tinham ainda sido utilizadas previamente num projecto com a dimensão do demonstrador aqui implementado, o que explica também a escassez de resultados quantitativos. Os testes que serão efectuados ao sistema em ambiente de produção não foram realizados em tempo útil para que os resultados obtidos tivessem sido incluídos nesta dissertação, pelo que apenas foram simulados alguns cenários e foram efectuados testes de carga ao protótipo na máquina disponível para que pudesse de alguma forma ser verificada a correcção e capacidade de processamento de eventos da solução desenvolvida. Salienta-se também o facto do desenvolvimento da componente de tratamento de eventos ter sido realizado de uma forma gradual e por vezes em diferentes direcções (para que pudesse ser explorado o Oracle CEP e as suas várias possibilidades de utilização) sem que esse carácter exploratório do desenvolvimento atrasasse o progresso de todo o projecto. Isto deve-se à flexibilidade apresentada pelo Oracle CEP que permite a reconfiguração da rede de processamento de eventos de uma forma simples e imediata. Observando os objectivos propostos para esta dissertação, verifica-se que estes foram cumpridos, na medida em que foram estudados de uma forma aprofundada quer o contexto em que o problema se insere quer os vários trabalhos realizados previamente em diferentes áreas e que se relacionam com o tema da dissertação; foi proposta uma solução que apresentava uma arquitectura que cumpria, na teoria, todos os requisitos pré-estabelecidos; foi implementado um protótipo que concretiza os vários elementos presentes na definição da arquitectura; foram tomadas uma série de medidas para garantir a correcção do sistema criado; e por fim, todo o trabalho realizado foi aqui registado para posterior consulta. Destaca-se por fim a experiência profissional na Link Consulting resultante da participação no projecto no qual esta dissertação se insere, onde grande parte do trabalho aqui expresso foi desenvolvido com o total apoio da equipa responsável. 87

100 6.2. Trabalho Futuro Apesar do trabalho desenvolvido ter cumprido os objectivos propostos, foram detectadas ao longo do desenvolvimento desta dissertação alguns pontos que poderiam, caso existisse mais tempo disponível e o âmbito da dissertação aumentasse, ser melhorados e/ou realizados de forma mais exaustiva. A simulação do protótipo em cenários reais foi realizada através do uso do simulador de eventos, que cumpriu totalmente a sua função, permitindo que diferentes cenários fossem configurados e posteriormente executados. No entanto, é de salientar o facto do simulador de eventos ter sido desenvolvido paralelamente ao desenvolvimento do restante protótipo, implicando um custo temporal que idealmente teria sido evitado, já que o simulador de eventos não está contemplado pelo âmbito definido para a tese. Existem trabalhos [42, 43] que têm vindo a ser desenvolvidos no sentido de criar Frameworks que tornem os testes de aplicações orientadas a eventos em actividades mais simples, o que permitirá acelerar o processo de verificação em aplicações deste tipo. Dado que se espera que uma aplicação orientada a eventos processe uma enorme carga de eventos, deve também ser possível medir o desempenho que a aplicação apresenta de uma forma fiável, permitindo realizar a comparação com outras medições efectuadas. Em [44] é proposta uma Framework que permite avaliar o desempenho de uma aplicação de processamento de eventos. Durante o posterior desenvolvimento da solução poderão ser seguidas algumas das indicações presentes nos referidos trabalhos para aperfeiçoar e acelerar o processo de testes a que o desenvolvimento estará sujeito. O uso de ferramentas deste tipo poderá melhorar tanto a qualidade e variedade dos testes realizados como a produtividade do desenvolvimento da aplicação, visto que é comum a forte integração destas ferramentas com os ambientes de desenvolvimento utilizados. O sistema desenvolvido não apresenta ainda mecanismos que lhe permitem recuperar após uma falha, ainda que os elementos necessários a um mecanismo deste tipo já estejam presentes na arquitectura da solução. Como tal, para aumentar a disponibilidade que o sistema apresenta poderiam ser usados os mecanismos de persistência que as queues utilizadas possuem, permitindo que os eventos que não tenham ainda sido processados não se percam, diminuindo assim os lapsos na monitorização efectuada. Dado que o acesso às queues JMS pode ser concorrente, é possível também ter uma segunda componente de tratamento de eventos paralela à já existente, em que ambas partilhariam, além das mesmas queues JMS, a informação (sobre malas, voos, etc.) armazenada nas caches que o Oracle CEP fornece. Para que a partilha de caches possa existir, poderá ser usada a solução de caches distribuídas da Oracle [45] (Oracle Coherence) que permite realizar a gestão e sincronização de caches bem como a partilha destas de forma transparente. Utilizando uma componente de tratamento de eventos paralela, aumentar-se-ia assim a disponibilidade da solução e a capacidade total de processamento de eventos da solução. Utilizando o mecanismo de caches partilhadas introduzido anteriormente será também possível eliminar a invocação do Web Service como método de envio dos eventos de leitura da camada Tags para a CTE, uma vez que as caches do Oracle Coherence têm simultaneamente uma 88

101 API Java e.net que permitirão que a camada Tags (que utiliza.net) coloque directamente numa cache partilhada com a CTE (baseada em Java) os eventos de leitura que serão processados. Assim, todos os eventos que a camada Tags colocasse na cache poderiam ser lidos pela CTE. Uma situação que também poderia ser alvo de melhoramentos é a apresentação do caminho percorrido de determinada mala quando este é consultado através da aplicação interface. A listagem dos pontos que aparecem, apesar de cada ponto possuir descrição, não é completamente explícita para a grande maioria dos passageiros, que não tem conhecimentos suficientes para compreender a informação relacionada com o processo de tratamento de bagagens. Como um dos principais objectivos é aumentar a confiança dos passageiros em relação ao processo de tratamento de bagagens, a informação a que estes acedem deve ser de fácil compreensão. Para isso poderia ser utilizado um sistema de informação geográfica (Geographic Information System, ou GIS), responsável por mapear os pontos de monitorização onde a mala foi detectada num diagrama que contenha a disposição física no aeroporto dos vários sistemas que participam no processo de tratamento de bagagens. Assim, o passageiro poderia aceder a informação visual sem precisar de qualquer conhecimento específico. Poderá ser também criada futuramente uma nova componente na solução cuja responsabilidade seja a de notificar o passageiro sobre eventos que tenham sido detectados e que se relacionem com as suas malas. Para o passageiro poder escolher os tipos de eventos que pretendesse receber, haveria um mecanismo que permitiria a subscrição de eventos. As notificações poderiam ser entregues através de diversos canais: , SMS, twitter, etc. A componente criada poderia ser totalmente independente das componentes já existentes, podendo aproveitar a entrega de eventos assíncrona da CTE através da implementação de um bean de comunicação na EPN semelhante aos já existentes só que este verificaria por cada evento, se este deveria ou não ser comunicado ao passageiro. Como alternativa, podia também ser utilizado o Message Center que faz parte da arquitectura do Oracle BAM e que através de regras definidas no Event Engine permite notificar diferentes receptores. Actualmente as situações excepcionais são detectadas através da correlação de vários eventos nos vários beans presentes na rede de processamento da CTE e os responsáveis pelo processo de tratamento de bagagens são depois alertados através dos dashboads apresentados pela componente de indicadores de negócio para que possam reagir da melhor forma possível. No futuro, poderá ser feita a correlação dos vários alertas enviados para a CIN para que as acções que corrigirão as situações detectadas sejam despoletadas de forma automática, não necessitando de intervenção humana. 89

102 7. Referências [1] I. A. T. Association, Baggage improvement programme, simplifying the business, International Air Transport Association, Tech. Rep., [2] Baggage handling solution. SkyTECH Solutions. [Online]. Available: [3] Baggage management system. AirIT. [Online]. Available: [4] Airport systems. FKI Logistex. [Online]. Available: [5] Worldtracer. SITA. [Online]. Available: [6] T. Vogel, Technical system specification to rfid-enable the baggage sorting system at zurich airport, Master's thesis, Swiss Federal Institute of Technology Zurich, [7] I. A. T. Association, Rfid business case for baggage tagging, International Air Transport Association, Tech. Rep., [8] I. A. T. Association, Passenger Services Conference Resolutions Manual. International Air Transport Association, [9] J. Hightower and G. Borriello, Location systems for ubiquitous computing, [10] Z. Ting, O. Yuanxin, and Y. He, Traceable air baggage handling system based on rfid tags in the airport, Journal of Theoretical and Applied Electronic Commerce Research, vol. 3, [11] I. A. T. Association, Rfid transition plan for baggage, International Air Transport Association, Tech. Rep., [12] A. T. U. Council, Mishandled baggage, Air Transport Users Council, Tech. Rep., [13] P. Harrop, R. Das, and G. Holland. (2008, June) Rfid for airports and airlines [Online]. Available: [14] EPCglobal, Tag Data Standards, EPCglobal Std., Rev. 1.4, June [Online]. Available: [15] A. Arasu, B. Babcock, S. Babu, J. Cieslewicz, M. Datar, K. Ito, R. Motwani, U. Srivastava, and J. Widom, Stream: The stanford data stream management system, Stanford InfoLab, Technical Report , [Online]. Available: [16] M. Stonebraker, U. Ã etintemel, and S. Zdonik, The 8 requirements of real-time stream processing, SIGMOD Rec., vol. 34, no. 4, pp , December [Online]. Available: [17] C. Zang and Y. Fan, Complex event processing in enterprise information systems based on rfid, Enterp. Inf. Syst., vol. 1, no. 1, pp. 3 23, [18] A. Arasu, S. Babu, and J. Widom, The cql continuous query language: Semantic foundations and query execution, Stanford InfoLab, Technical Report , [Online]. Available: [19] NiagaraCQ: A Scalable Continuous Query System for Internet Databases, [20] Characterizing Memory Requirements for Queries over Continuous Data,

103 [21] Processing complex aggregate queries over data streams. New York, NY, USA: ACM, [22] Models and issues in data stream systems. New York, NY, USA: ACM, [23] N. Jain, S. Mishra, A. Srinivasan, J. Gehrke, J. Widom, H. Balakrishnan, U. Çetintemel, M. Cherniack, R. Tibbetts, and S. Zdonik, Towards a streaming sql standard, Proc. VLDB Endow., vol. 1, no. 2, pp , [24] Complex Event Processing in EPC Sensor Network Middleware for Both RFID and WSN. Washington, DC, USA: IEEE Computer Society, [25] Oracle. (2008, September) Oracle complex event processing performance. [Online]. Available: [26]. (2008) Airline baggage handling demo - oracle soa solutions. Fornecido pela Oracle. [27] S. Frischbier, Existing rfid infrastructures - comparison and evaluation, RFID Seminar, pp , [28] Z. Ting, O. Yuanxin, L. Chao, and X. Zhang, A scalable rfid-based system for location-aware services, IEEE, [29] Z. Ting, X. Zhang, and O. Yuanxin, A framework of networked rfid system supporting location tracking, IEEE, [30] Assessing the Feasibility of Using RFID Technology in Airports, [Online]. Available: [31] ISO/IEC :2001 Software engineering - Product Quality: Quality Model, ISO/IEC Std., [32] F. Losavio, L. Chirinos, N. Lévy, and A. Ramdane-Cherif, Quality characteristics for software architecture, Journal of Object Technology, vol. 2, no. 2, pp , [33] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Second Edition. Addison-Wesley Professional, April [Online]. Available: [34] A. S. Tanenbaum and M. van Steen, Distributed Systems: Principles and Paradigms (2nd Edition). Upper Saddle River, NJ, USA: Prentice-Hall, Inc., [Online]. Available: [35] Scale in Distributed Systems. IEEE Computer Society Press, [36] O. Etzion and P. Niblett, Event Processing in Action. Manning, February [37] P. Purich, Oracle CEP Getting Started. Oracle, May [38] PolarLake, Understanding the esb, February [39] S. Chande. (2004, March) Esb: Enterprise service bus. Department of Computer Science - University of Helsinki. [40] D. Chappell, Enterprise Service Bus. O'Reilly Media, Inc., July [41] V. Massol and T. Husted, JUnit in Action. Greenwich, CT, USA: Manning Publications Co., [42] J. Schiefer, G. Saurer, and A. Schatten, Testing event-driven business processes, Journal of Computers, vol. 1, no. 7, pp ,

104 [43] Y. Lee, Soa test framework based on bpa -simulated event proxy, New Trends in Information and Service Science, International Conference on, vol. 0, pp , [44] M. R. N. Mendes, P. Bizarro, and P. Marques, A framework for performance evaluation of complex event processing systems, in DEBS '08: Proceedings of the second international conference on Distributed event-based systems. New York, NY, USA: ACM, 2008, pp [45] Oracle. (2009) Oracle coherence data sheet. Fornecido pela Oracle. Consultado em Outubro de [Online]. Available: 92

105 Anexo A Resumo dos Campos das Information Messages 93

106 Anexo B Campos Disponíveis para Armazenamento de Informação numa Tag 94

107 Anexo C Topologia do Sistema de Monitorização Implementado no Aeroporto de Pequim 95

108 Anexo D Event Processing Network da Solução 96

109 97

110 Anexo E Hierarquia de Eventos da Solução 98

111 Anexo F Modelo de Domínio da Solução 99

112 Anexo G Modelo Entidade-Relação da Base de Dados 100

113 Anexo H Exemplos de Relatórios da Componente de Indicadores de Negócio 101

114 102

Ricardo Gomes Clemente. Uma arquitetura para processamento de eventos de log em tempo real. Dissertação de Mestrado

Ricardo Gomes Clemente. Uma arquitetura para processamento de eventos de log em tempo real. Dissertação de Mestrado 1 Ricardo Gomes Clemente Uma arquitetura para processamento de eventos de log em tempo real Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do título de Mestre pelo

Leia mais

Plataforma integrada para testes em arquitecturas orientadas a serviços

Plataforma integrada para testes em arquitecturas orientadas a serviços Plataforma integrada para testes em arquitecturas orientadas a serviços Índice Introdução... 2 A solução... 2 Plataforma Integrada (principais características)... 4 Eliminar limitações à execução de testes

Leia mais

REST Um Estilo de Arquitetura de Sistemas Distribuídos

REST Um Estilo de Arquitetura de Sistemas Distribuídos REST Um Estilo de Arquitetura de Sistemas Distribuídos Márcio Alves de Araújo¹, Mauro Antônio Correia Júnior¹ 1 Faculdade de Computação Universidade Federal de Uberlândia (UFU) Monte Carmelo MG Brasil

Leia mais

Service Oriented Architectures

Service Oriented Architectures Service Oriented Architectures Uma abordagem evolutiva Manager, IT Middleware Vodafone Portugal Mario.saraiva@vodafone.com Agenda 1. O desafio da Integração O princípio do Middleware, ActiveWorks e Middleware

Leia mais

Service Oriented Architecture SOA

Service Oriented Architecture SOA Service Oriented Architecture SOA Arquitetura orientada aos serviços Definição: Arquitetura de sistemas distribuídos em que a funcionalidade é disponibilizada sob a forma de serviços (bem definidos e independentes)

Leia mais

Enunciado de apresentação do projecto

Enunciado de apresentação do projecto Engenharia de Software Sistemas Distribuídos 2 o Semestre de 2009/2010 Enunciado de apresentação do projecto FEARSe Índice 1 Introdução... 2 2 Cenário de Enquadramento... 2 2.1 Requisitos funcionais...

Leia mais

Manual de Utilizador. CNCVisual. Julho de 2006. Âmbito do Projecto de 5º Ano de Engenharia Mecânica. Autor: Bruno Lameiro

Manual de Utilizador. CNCVisual. Julho de 2006. Âmbito do Projecto de 5º Ano de Engenharia Mecânica. Autor: Bruno Lameiro Manual de Utilizador CNCVisual Julho de 2006 Âmbito do Projecto de 5º Ano de Engenharia Mecânica Autor: Bruno Lameiro Introdução: A existência do manual de utilizador da aplicação CNCVisual tem como objectivo

Leia mais

Melhoria de Conhecimentos em Garantia de Qualidade no Software. (Tipos de Teste)

Melhoria de Conhecimentos em Garantia de Qualidade no Software. (Tipos de Teste) Melhoria de Conhecimentos em Garantia de Qualidade no Software (Tipos de Teste) Av. Conde de Valbom, nº 30 8º 1050-068 Lisboa Telf: +351 213 510 540 Fax: +351 213 510 549 Controlo do Documento Elaborado

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

SOA 2.0 ou Event-Driven SOA

SOA 2.0 ou Event-Driven SOA SOA SOA 2.0 ou Event-Driven SOA 1 Introdução Recentemente, a Oracle anuciou o termo SOA 2.0. E já deu para imaginar a repercussão que isto teve. Estamos em um momento onde SOA (Service-Oriented Architecture),

Leia mais

Curriculum DeGóis Guia de preenchimento do Curriculum Vitae (Informação mínima necessária)

Curriculum DeGóis Guia de preenchimento do Curriculum Vitae (Informação mínima necessária) Curriculum DeGóis Guia de preenchimento do Curriculum Vitae (Informação mínima necessária) /curriculum Julho de 2008 Versão 1.1 1 Introdução O objectivo deste guia é auxiliar o utilizador da Plataforma

Leia mais

ROADSHOW PORTO RFID aplicado à Gestão Logística 26 de Maio 2011 Luis Peixoto

ROADSHOW PORTO RFID aplicado à Gestão Logística 26 de Maio 2011 Luis Peixoto ROADSHOW PORTO RFID aplicado à Gestão Logística 26 de Maio 2011 Luis Peixoto The global language of business GS1 EPCglobal/RFID Uma ferramenta logística RASTREABILIDADE INFORMAÇÃO EM TEMPO REAL GS1 EPC

Leia mais

Versão 1.0. [08.02.2012] 2012, Portugal - Efacec Sistemas de Gestão S.A. Todos os direitos reservados. 1

Versão 1.0. [08.02.2012] 2012, Portugal - Efacec Sistemas de Gestão S.A. Todos os direitos reservados. 1 Copyright 2012 Efacec Todos os direitos reservados. Não é permitida qualquer cópia, reprodução, transmissão ou utilização deste documento sem a prévia autorização escrita da Efacec Sistemas de Gestão S.A.

Leia mais

Gestão de Configurações II

Gestão de Configurações II Gestão de Configurações II Bibliografia Livro: Software Configuration Management Patterns: Effective Teamwork, Practical Integration Gestão de Projecto 14 Padrões de Gestão Os padrões de gestão de configurações

Leia mais

Tese / Thesis Work Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java

Tese / Thesis Work Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java Licenciatura em Engenharia Informática Degree in Computer Science Engineering Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java Performance analysis of large distributed

Leia mais

WebSphere MQ. Bruno Miguel de Sousa Gonçalves

WebSphere MQ. Bruno Miguel de Sousa Gonçalves WebSphere MQ Bruno Miguel de Sousa Gonçalves 1.Introdução ao WebSphere Os produtos WebSphere providenciam comunicação entre programas através da interligação entre componentes heterogéneos, processadores,

Leia mais

GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA

GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA Sandra CARVALHO 1, Pedro GALVÃO 2, Cátia ALVES 3, Luís ALMEIDA 4 e Adélio SILVA 5 RESUMO As empresas de abastecimento de água gerem diariamente

Leia mais

Utilização de DGPS para Monitorização de Frotas em Ambiente Urbano

Utilização de DGPS para Monitorização de Frotas em Ambiente Urbano Utilização de DGPS para Monitorização de Frotas em Ambiente Urbano Telmo Cunha (1,2), Phillip Tomé (1), Sérgio Cunha (2), Jaime Cardoso (2) e Luisa Bastos (1) (1) Observatório Astronómico da Universidade

Leia mais

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA Introdução Nesta edição do Catálogo de Serviços apresentamos os vários tipos de serviços que compõe a actual oferta da Primavera na área dos serviços de consultoria.

Leia mais

Sistemas de Informação no sector da Construção. João Poças Martins, FEUP/GEQUALTEC, 2011 1

Sistemas de Informação no sector da Construção. João Poças Martins, FEUP/GEQUALTEC, 2011 1 Sistemas de Informação no sector da Construção João Poças Martins, FEUP/GEQUALTEC, 2011 1 Sistemas de Informação no sector da Construção 1. SI na Construção. Introdução 2. ERP 3. BIM 4. Outras aplicações

Leia mais

Vídeo Vigilância Abordagem Open-Source

Vídeo Vigilância Abordagem Open-Source Vídeo Vigilância Abordagem Open-Source Alunos: Justino Santos, Paulo Neto E-mail: eic10428@student.estg.ipleiria.pt, eic10438@student.estg.ipleiria.pt Orientadores: Prof. Filipe Neves, Prof. Paulo Costa

Leia mais

An enterprise distributed system

An enterprise distributed system An enterprise distributed system 2º Trabalho Prático Tecnologias de Distribuição e Integração 4º Ano do Mestrado Integrado em Engenharia Informática e Computação João Carlos Figueiredo Rodrigues Prudêncio

Leia mais

UNIVERSIDADE DE AVEIRO

UNIVERSIDADE DE AVEIRO UNIVERSIDADE DE AVEIRO DEPARTAMENTO DE ECONOMIA, GESTÃO E ENGENHARIA INDUSTRIAL MESTRADO EM GESTÃO DA INFORMAÇÃO DISCIPLINA: GESTÃO DA INFORMAÇÃO CAPACIDADE DE RESPOSTA A SOLICITAÇÕES DO EXTERIOR - DIÁLOGO

Leia mais

Sistemas Operativos: Introdução. February 22, 2011

Sistemas Operativos: Introdução. February 22, 2011 Sistemas Operativos: Introdução February 22, 2011 Sumário Introdução aos Sistemas Operativos Organização de Computadores Sistema Operativo Abstracções Oferecidas por um SO Serviços dum SO Interfaces dum

Leia mais

A compreensão do mecanismo de transações é essencial, sempre que a

A compreensão do mecanismo de transações é essencial, sempre que a Transações A compreensão do mecanismo de transações é essencial, sempre que a base de dados d servir várias clientes simultaneamente. Em SQL é possível definir explicitamente os limites de uma transação.

Leia mais

Processo de análise estruturada - Abordagem clássica

Processo de análise estruturada - Abordagem clássica Processo de análise estruturada - Abordagem clássica Desenvolver modelo físico actual Modelo físico actual Modelos a desenvolver tendo em conta a abordagem clássica Desenvolver modelo lógico actual Modelo

Leia mais

Enunciado do Projecto

Enunciado do Projecto C O M P U T A Ç Ã O M Ó V E L 2 0 0 7 / 2 0 0 8 Enunciado do Projecto 17 de Março de 2008 1. Objectivos Desenvolver uma aplicação num domínio aplicacional específico que envolva replicação e sincronização

Leia mais

Programação 2ºSemestre MEEC - 2010/2011. Programação 2º Semestre 2010/2011 Enunciado do projecto

Programação 2ºSemestre MEEC - 2010/2011. Programação 2º Semestre 2010/2011 Enunciado do projecto Mestrado Integrado em Engenharia Electrotécnica e de Computadores Programação 2º Semestre 2010/2011 Enunciado do projecto O projecto a desenvolver pelos alunos consistirá numa sistema de monitorização,

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

Leia mais

ANA obtém certificação em quatro áreas críticas com apoio da VP Consulting

ANA obtém certificação em quatro áreas críticas com apoio da VP Consulting ANA obtém certificação em quatro áreas críticas com apoio da VP Consulting Contactos: Isabel Fonseca Marketing VP Consulting Telefone: +351 22 605 37 10 Fax: +351 22 600 07 13 Email: info@vpconsulting.pt

Leia mais

Concurso público para aquisição de plataforma de facturação electrónica. Resposta aos pedidos de esclarecimentos. Julho de 2009

Concurso público para aquisição de plataforma de facturação electrónica. Resposta aos pedidos de esclarecimentos. Julho de 2009 GLOBALGARVE COOPERAÇÃO E DESENVOLVIMENTO, SA Concurso público para aquisição de plataforma de facturação electrónica Resposta aos pedidos de esclarecimentos Julho de 2009 Página 1 de 7 No seguimento do

Leia mais

Projecto de Programação MEEC - 2010/2011-1ºSemestre. Mestrado Integrado em Engenharia Electrotécnica e de Computadores

Projecto de Programação MEEC - 2010/2011-1ºSemestre. Mestrado Integrado em Engenharia Electrotécnica e de Computadores Mestrado Integrado em Engenharia Electrotécnica e de Computadores Programação 2010/2011 Enunciado do projecto O projecto a desenvolver pelos alunos consistirá numa sistema de monitorização do estado de

Leia mais

Web Services como Tecnologia de Suporte a Processos de Negócio

Web Services como Tecnologia de Suporte a Processos de Negócio Web Services como Tecnologia de Suporte a Processos de Negócio Rodrigo C. Macedo, Vasco Mesquita, Artur Caetano, André Vasconcelos, José Tribolet Centro de Engenharia Organizacional, INESC INOV e Departamento

Leia mais

Entrega de Folhas de Férias

Entrega de Folhas de Férias Entrega de Folhas de Férias Guia do Utilizador Versão 4.0 Agosto/ 2014 Índice 1. Introdução 2. Criar/ Validar Folhas de Férias 3. Acesso à funcionalidade 4. Inserir/ Consultar Folhas de Férias 5. Comprovativo

Leia mais

PHC dteamcontrol Externo

PHC dteamcontrol Externo PHC dteamcontrol Externo A gestão remota de projectos e de informação A solução via Internet que permite aos seus Clientes participarem nos projectos em que estão envolvidos, interagindo na optimização

Leia mais

Índice. Como aceder ao serviço de Certificação PME? Como efectuar uma operação de renovação da certificação?

Índice. Como aceder ao serviço de Certificação PME? Como efectuar uma operação de renovação da certificação? Índice Como aceder ao serviço de Certificação PME? Como efectuar uma operação de renovação da certificação? Como efectuar uma operação de confirmação de estimativas? Como aceder ao Serviço de Certificação

Leia mais

Especificação Técnica ACSS

Especificação Técnica ACSS Especificação Técnica ACSS ET.ACSS.011-2011 Serviço de Registo de Requisições de MCDT Interface para recepção de requisições electrónicas ICS DESCRITORES Sistema de recepção de requisições de meios complementares

Leia mais

PHC dteamcontrol Interno

PHC dteamcontrol Interno O módulo PHC dteamcontrol Interno permite acompanhar a gestão de todos os projectos abertos em que um utilizador se encontra envolvido. PHC dteamcontrol Interno A solução via Internet que permite acompanhar

Leia mais

PHC dteamcontrol Interno

PHC dteamcontrol Interno PHC dteamcontrol Interno A gestão remota de projectos em aberto A solução via Internet que permite acompanhar os projectos em aberto em que o utilizador se encontra envolvido, gerir eficazmente o seu tempo

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Desenho de Software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt desenho Desenho (dicionário Priberam on-line) do Lat.! designu s. m., arte de representar

Leia mais

Oracle BPM 11g. Análise à Plataforma

Oracle BPM 11g. Análise à Plataforma Oracle BPM 11g Análise à Plataforma Maio de 2010 Tive o privilégio de ser convidado a participar no "EMEA BPM 11g beta bootcamp" em Abril de 2010, no qual tive contacto mais próximo com a última versão

Leia mais

O ITIL e o Plano de Contingência. Lúcia Cerqueira & António Correia informatica@chts.min-saude.pt

O ITIL e o Plano de Contingência. Lúcia Cerqueira & António Correia informatica@chts.min-saude.pt Lúcia Cerqueira & António Correia informatica@chts.min-saude.pt A Equipa de IT do CHTS,E.P.E. Equipa composta por 12 Elementos Framework ITIL using RT ( linha Servicedesk (1ª e 2ª Reorganização da Equipa

Leia mais

O nosso foco é alertar se necessário e ajudar a recuperar rapidamente os dados correctos. Intelligent Video Analysis

O nosso foco é alertar se necessário e ajudar a recuperar rapidamente os dados correctos. Intelligent Video Analysis O nosso foco é alertar se necessário e ajudar a recuperar rapidamente os dados correctos Intelligent Video Analysis 2 Intelligent Video Analysis Conferir sentido e estrutura Quando se trata de videovigilância,

Leia mais

ILM e as Arquitecturas Empresariais por Pedro Sousa

ILM e as Arquitecturas Empresariais por Pedro Sousa ILM e as Arquitecturas Empresariais por Pedro Sousa Neste artigo clarifica-se os objectivos do ILM (Information Life Cycle Management) e mostra-se como estes estão dependentes da realização e manutenção

Leia mais

Wide Scope. Soluções de Optimização

Wide Scope. Soluções de Optimização Wide Scope Soluções de Optimização 2 Wide Scope Scheduler sequenciamento e optimização da produção A oportunidade para passar a agir, em vez de reagir. Maximizar a capacidade produtiva dos recursos quando

Leia mais

SIBS PROCESSOS cria solução de factura electrónica com tecnologias Microsoft

SIBS PROCESSOS cria solução de factura electrónica com tecnologias Microsoft SIBS PROCESSOS cria solução de factura electrónica com tecnologias Microsoft A solução MB DOX oferece uma vantagem competitiva às empresas, com a redução do custo de operação, e dá um impulso à factura

Leia mais

OCL: Object Constraint Language

OCL: Object Constraint Language OCL: Amílcar Domingos Rodrigues Santy Fernandes, Girson César Silva Monteiro, Rui Sá Guerra, Simão Castro Faculdade de Engenharia da Universidade Do Porto, Rua Dr. Roberto Frias, s/n 4200-465 Porto, Portugal

Leia mais

1 ARQUITECTURA DO PRODUTO - MODULARIZAÇÃO E SISTEMAS DE PLATAFORMAS NA INDUSTRIA FERROVIÁRIA... 20.19.

1 ARQUITECTURA DO PRODUTO - MODULARIZAÇÃO E SISTEMAS DE PLATAFORMAS NA INDUSTRIA FERROVIÁRIA... 20.19. 1 ARQUITECTURA DO PRODUTO - MODULARIZAÇÃO E SISTEMAS DE PLATAFORMAS NA INDUSTRIA FERROVIÁRIA... 20.19. ESTRATÉGIA DE INOVAÇÃO 1 ARQUITECTURA DO PRODUTO - MODULARIZAÇÃO E SISTEMAS DE PLATAFORMAS NA INDUSTRIA

Leia mais

FEUP 2006/2007 Mestrado em Tecnologias Multimédia Doc. Apresentação V0

FEUP 2006/2007 Mestrado em Tecnologias Multimédia Doc. Apresentação V0 FEUP 2006/2007 Mestrado em Tecnologias Multimédia Doc. Apresentação V0 TÍTULO: Animatic - Marionetas Digitais Interactivas ORIENTADORES: Professor Doutor Aníbal Ferreira Professor Doutor Rui Torres ALUNO:

Leia mais

Guia de Acesso à Formação Online Formando 2011

Guia de Acesso à Formação Online Formando 2011 Plano [1] Guia de Acesso à Formação Online 2011 [2] ÍNDICE ÍNDICE...2 1. Introdução...3 2. Metodologia Formativa...4 3. Actividades...4 4. Apoio e Acompanhamento do Curso...5 5. Avaliação...6 6. Apresentação

Leia mais

Como a Cisco TI virtualizou os Servidores de Aplicações dos Centros de Dados

Como a Cisco TI virtualizou os Servidores de Aplicações dos Centros de Dados Case Study da Cisco TI Como a Cisco TI virtualizou os Servidores de Aplicações dos Centros de Dados A implementação de servidores virtualizados proporciona economias significativas de custos, diminui a

Leia mais

Sistema de Tratamento Automático da Declaração de Introdução no Consumo e do Documento Administrativo de Acompanhamento

Sistema de Tratamento Automático da Declaração de Introdução no Consumo e do Documento Administrativo de Acompanhamento AUTOR: DGITA DATA: 2007-02-22 VERSÃO: 1.0 Sistema de Tratamento Automático da Declaração de Introdução no Consumo e do Documento Administrativo de Acompanhamento Sistema de Impostos Especiais sobre o Consumo

Leia mais

3 Serviços na Web (Web services)

3 Serviços na Web (Web services) 3 Serviços na Web (Web services) 3.1. Visão Geral Com base na definição do Word Wide Web Consortium (W3C), web services são aplicações autocontidas, que possuem interface baseadas em XML e que descrevem

Leia mais

3 ao Quadrado - Agenda Web

3 ao Quadrado - Agenda Web 3 ao Quadrado - Agenda Web Relatório de Gestão de Projectos de Software - Grupo A - LEIC 2001/2002 http://gnomo.fe.up.pt/gps01a João Montenegro - ei97023@fe.up.pt André Teixeira - ei97024@fe.up.pt Carlos

Leia mais

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP Cleber de F. Ferreira¹, Roberto Dias Mota¹. ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil cleberferreirasi@hotmail.com, motaroberto@hotmail.com Resumo.

Leia mais

Dynamic Data Center. A infra-estrutura de suporte às SOA. Francisco Miller Guerra Senior Product Manager Fujitsu Siemens Computers

Dynamic Data Center. A infra-estrutura de suporte às SOA. Francisco Miller Guerra Senior Product Manager Fujitsu Siemens Computers Dynamic Data Center A infra-estrutura de suporte às SOA Francisco Miller Guerra Senior Product Manager Fujitsu Siemens Computers As necessidades do negócio pressionam continuamente as infra-estruturas

Leia mais

Grupo 34. Universidade do Minho Conselho de Cursos de Engenharias Licenciatura em Engenharia de Sistemas de Software

Grupo 34. Universidade do Minho Conselho de Cursos de Engenharias Licenciatura em Engenharia de Sistemas de Software Universidade do Minho Conselho de Cursos de Engenharias Licenciatura em Engenharia de Sistemas de Software Desenvolvimento de Sistemas de Software DSS - 2009/2010 Grupo 34 Guilherme Silva 47048 Rui Meira

Leia mais

Integrated Network Operations Support System ISO 9001 Certified A Plataforma Integradora Integrated Platform O INOSS V2 é uma poderosa plataforma de operação e gestão centralizada de redes e serviços de

Leia mais

MANUAL DE UTILIZAÇÃO DA PLATAFORMA MOODLE

MANUAL DE UTILIZAÇÃO DA PLATAFORMA MOODLE MANUAL DE UTILIZAÇÃO DA PLATAFORMA MOODLE A EQUIPA DO PTE 2009/2010 Índice 1. Entrar na plataforma Moodle 3 2. Editar o Perfil 3 3. Configurar disciplina 4 3.1. Alterar definições 4 3.2. Inscrever alunos

Leia mais

Gestão de Processos de Negócio

<Insert Picture Here> Gestão de Processos de Negócio Gestão de Processos de Negócio Susana Santos Principal Sales Consultant Agenda Quais os Desafios Business Process Management Modelação Execução Interacção Humana Monitorização Resumo

Leia mais

Serviço de instalação e arranque da solução de armazenamento de rede HP StoreEasy 5000

Serviço de instalação e arranque da solução de armazenamento de rede HP StoreEasy 5000 Serviço de instalação e arranque da solução de armazenamento de rede HP StoreEasy 5000 Serviços HP Dados técnicos O Serviço de instalação e arranque da solução de armazenamento de rede HP StoreEasy 5000

Leia mais

MODELO 827 CARACTERÍSTICAS. Controlador Trunking

MODELO 827 CARACTERÍSTICAS. Controlador Trunking MODELO 827 Controlador Trunking CARACTERÍSTICAS Obedece completamente ao Standard MPT1327/1343 e é compatível com os radiotelefones MPT1352/1327. Tem estrutura modular e o seu sistema de controlo com informação

Leia mais

Ao conjunto total de tabelas, chamamos de Base de Dados.

Ao conjunto total de tabelas, chamamos de Base de Dados. O QUE É O ACCESS? É um sistema gestor de base de dados relacional. É um programa que permite a criação de Sistemas Gestores de Informação sofisticados sem conhecer linguagem de programação. SISTEMA DE

Leia mais

UNIVERSIDADE. Sistemas Distribuídos

UNIVERSIDADE. Sistemas Distribuídos UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Web Services Web Services Existem diferentes tipos de comunicação em um sistema distribuído: Sockets Invocação

Leia mais

Análise de Sistemas. Conceito de análise de sistemas

Análise de Sistemas. Conceito de análise de sistemas Análise de Sistemas Conceito de análise de sistemas Sistema: Conjunto de partes organizadas (estruturadas) que concorrem para atingir um (ou mais) objectivos. Sistema de informação (SI): sub-sistema de

Leia mais

Case Study. Metro do Porto. Projecto de Radio Trunking

Case Study. Metro do Porto. Projecto de Radio Trunking Metro do Porto Projecto de Radio Trunking Esta solução providencia um sistema de rádio operacional, privado, que pode ser utilizada para comunicações de emergências, quer pelos condutores dos veículos,

Leia mais

Especificações de oferta Monitorização da infra-estrutura remota

Especificações de oferta Monitorização da infra-estrutura remota Descrição dos serviços Especificações de oferta Monitorização da infra-estrutura remota Este serviço oferece serviços de Monitorização da infra-estrutura remota Dell (RIM, o Serviço ou Serviços ) conforme

Leia mais

Portal AEPQ Manual do utilizador

Portal AEPQ Manual do utilizador Pedro Gonçalves Luís Vieira Portal AEPQ Manual do utilizador Setembro 2008 Engenharia Informática - Portal AEPQ Manual do utilizador - ii - Conteúdo 1 Introdução... 1 1.1 Estrutura do manual... 3 1.2 Requisitos...

Leia mais

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO. SISTEMAS DE GESTÃO DE BASE DE DADOS Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO. SISTEMAS DE GESTÃO DE BASE DE DADOS Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO CONCEITOS BÁSICOS 1 Necessidade das base de dados Permite guardar dados dos mais variados tipos; Permite

Leia mais

Lógica de Negócio e Acesso a dados. Parte 2.2

Lógica de Negócio e Acesso a dados. Parte 2.2 Lógica de Negócio e Acesso a dados Parte 2.2 Estilos arquitecturais Orientado à tabela Table Module Table Data Gateway BLL DAL Orientado aos objectos Domain Model Active Record Data Mapper BLL DAL BLL

Leia mais

Requisitos e Modelação

Requisitos e Modelação Requisitos e Modelação combinação essencial para melhorar o processo de desenvolvimento de software Class4 -End1 -End2 Class1 * * System Actor1 * -End3 -End5 -End7 * Actor2 UseCase1 -End4 * UseCase2 -End6

Leia mais

Interface Homem Máquina para Domótica baseado em tecnologias Web

Interface Homem Máquina para Domótica baseado em tecnologias Web Interface Homem Máquina para Domótica baseado em tecnologias Web João Alexandre Oliveira Ferreira Dissertação realizada sob a orientação do Professor Doutor Mário de Sousa do Departamento de Engenharia

Leia mais

COLIBRI Ambiente Colaborativo Multimédia MÓDULO MOODLE. Rui Ribeiro colibri@fccn.pt. FCCN - Dezembro 2010

COLIBRI Ambiente Colaborativo Multimédia MÓDULO MOODLE. Rui Ribeiro colibri@fccn.pt. FCCN - Dezembro 2010 COLIBRI Ambiente Colaborativo Multimédia MÓDULO MOODLE FCCN - Dezembro 2010 Rui Ribeiro colibri@fccn.pt Módulo COLIBRI Concebido por: José Coelho Universidade Aberta Apoiado por: Rui Ribeiro FCCN Vitor

Leia mais

Projecto de Engenharia de Software e Sistemas Distribuídos 2009-10. Requisitos para a 3ª entrega do projecto. FeaRSe.

Projecto de Engenharia de Software e Sistemas Distribuídos 2009-10. Requisitos para a 3ª entrega do projecto. FeaRSe. Departamento de Engenharia Informática Engenharia de Software, Sistemas Distribuídos Requisitos para a 3ª entrega do projecto FeaRSe 6 de Maio de 2010 Índice Índice... 1 1 Sumário... 2 2 Requisitos...

Leia mais

Engenharia de Software Sistemas Distribuídos. 2º Semestre, 2007/2008. Departamento Engenharia Informática. Enunciado do projecto: Loja Virtual

Engenharia de Software Sistemas Distribuídos. 2º Semestre, 2007/2008. Departamento Engenharia Informática. Enunciado do projecto: Loja Virtual Engenharia de Software Sistemas Distribuídos 2º Semestre, 2007/2008 Departamento Engenharia Informática Enunciado do projecto: Loja Virtual Fevereiro de 2008 Índice Índice...2 Índice de Figuras...3 1 Introdução...4

Leia mais

Nagios XI Soluções de Monitorização

Nagios XI Soluções de Monitorização Nagios XI Soluções de Monitorização O Nagios é uma solução líder de mercado na área da monitorização e alarmística, desenvolvido pela software house Norte Americana com o mesmo nome. O Nagios XI é uma

Leia mais

FERRAMENTAS? a alterar, em muitas organizações, um. instrumento tão abrangente como um orçamento

FERRAMENTAS? a alterar, em muitas organizações, um. instrumento tão abrangente como um orçamento O QUE É IMPRESCINDÍVEL NUMA SOLUÇÃO DE ORÇAMENTAÇÃO E PREVISÃO? Flexibilidade para acomodar mudanças rápidas; Usabilidade; Capacidade de integração com as aplicações a montante e a jusante; Garantir acesso

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

M323 AUTOMAÇÃO TRABALHO LABORATORIAL Nº 7

M323 AUTOMAÇÃO TRABALHO LABORATORIAL Nº 7 ESCOLA SUPERIOR NÁUTICA INFANTE D. HENRIQUE DEPARTAMENTO DE ENGENHARIA MARÍTIMA M323 AUTOMAÇÃO TRABALHO LABORATORIAL Nº 7 INTRODUÇÃO À PROGRAMAÇÃO DE AUTÓMATOS INDUSTRIAIS Por: Prof. Luis Filipe Baptista

Leia mais

A Gestão de Configurações suporte dos Sistemas de Informação

A Gestão de Configurações suporte dos Sistemas de Informação A Gestão de Configurações suporte dos Sistemas de Informação O funcionamento dos sistemas e tecnologias de informação e comunicação têm nas organizações um papel cada vez mais crítico na medida em que

Leia mais

Fábio Costa e Miguel Varela

Fábio Costa e Miguel Varela Sistema de Informação e Gestão dos Laboratórios do Departamento de Eng.ª Electrotécnica com Tecnologia RFID Projecto Final de Licenciatura em Eng. Electrotécnica e de Computadores Ramo de Electrónica e

Leia mais

Comunicação de Dados de Autenticação e Credenciais de Acesso para Resposta ao Inquérito

Comunicação de Dados de Autenticação e Credenciais de Acesso para Resposta ao Inquérito Mais informação Acesso ao Sistema de Transferência Electrónica de dados de Inquéritos (STEDI). Onde se acede ao sistema de entrega de Inquéritos? Deverá aceder ao sistema através do site do GEP www.gep.mtss.gov.pt

Leia mais

Livraria dos Mestres

Livraria dos Mestres Gestão de Projectos Informáticos Livraria dos Mestres 3ª Entrega Empresa B Grupo nº 11 João Maurício nº 53919 Ricardo Carapeto nº 53942 Nuno Almeida nº 53946 Page 1 of 28 Índice 1. Sumário para a Gestão

Leia mais

Estudo de criação de valor Como os agentes de viagens podem lucrar com as soluções de reservas de automóveis

Estudo de criação de valor Como os agentes de viagens podem lucrar com as soluções de reservas de automóveis Estudo de criação de valor Como os agentes de viagens podem lucrar com as soluções de reservas de automóveis ALTEN ÍNDICE INTRODUÇÃO SÍNTESE INTRODUÇÃO RESULTADOS Análise de produtividade Análise de rendimentos

Leia mais

Conceito. As empresas como ecossistemas de relações dinâmicas

Conceito. As empresas como ecossistemas de relações dinâmicas Conceito As empresas como ecossistemas de relações dinâmicas PÁG 02 Actualmente, face à crescente necessidade de integração dos processos de negócio, as empresas enfrentam o desafio de inovar e expandir

Leia mais

GS1 Contributo para uma Classificação Global

GS1 Contributo para uma Classificação Global GS1 Contributo para uma Classificação Global GS1 Portugal e o Sistema GS1 1ª Reunião da Rede Portuguesa sobre Composição dos Alimentos Projecto PortFIR 16 Dezembro 2008 Agenda Quem somos Sistema GS1 Quem

Leia mais

COMPROMISSO DE PRESTAÇÃO DE SERVIÇOS AOS PASSAGEIROS DAS TRANSPORTADORAS AÉREAS COMERCIAIS

COMPROMISSO DE PRESTAÇÃO DE SERVIÇOS AOS PASSAGEIROS DAS TRANSPORTADORAS AÉREAS COMERCIAIS COMPROMISSO DE PRESTAÇÃO DE SERVIÇOS AOS PASSAGEIROS DAS TRANSPORTADORAS AÉREAS COMERCIAIS As transportadoras europeias elaboraram o Compromisso sobre Prestação de Serviços aos Passageiros das Transportadoras

Leia mais

Manual do utilizador das funções avançadas do sistema de correio de voz Cisco Unity Express 7.0.2

Manual do utilizador das funções avançadas do sistema de correio de voz Cisco Unity Express 7.0.2 Manual do utilizador das funções avançadas do sistema de correio de voz Cisco Unity Express 7.0.2 Última actualização: 12 March 2009 Este manual fornece informações sobre a utilização das funções de correio

Leia mais

VRM Monitor. Ajuda Online

VRM Monitor. Ajuda Online VRM Monitor pt Ajuda Online VRM Monitor Índice pt 3 Índice 1 Introdução 3 2 Vista geral do sistema 3 3 Getting started 4 3.1 Iniciar o VRM Monitor 4 3.2 Iniciar o Configuration Manager 4 4 Configurar

Leia mais

Serviço de Faturação Eletrónica

Serviço de Faturação Eletrónica E-Invoicing Serviço prestado em acordo de interoperabilidade com a: Nov.2013 Ref. 02.007.14353 ÍNDICE 1 O que é uma Fatura Eletrónica? 3 2 Porquê a Faturação Eletrónica? 4 3 Quais as Vantagens? 7 4 O papel

Leia mais

PROJETO DE SISTEMA RFID EM AEROPORTOS PARA RASTREAMENTO E IDENTIFICAÇÃO DE BAGAGENS E PASSAGEIROS

PROJETO DE SISTEMA RFID EM AEROPORTOS PARA RASTREAMENTO E IDENTIFICAÇÃO DE BAGAGENS E PASSAGEIROS PROJETO DE SISTEMA RFID EM AEROPORTOS PARA RASTREAMENTO E IDENTIFICAÇÃO DE BAGAGENS E DESIGN SYSTEM FOR TRACKING RFID AT AIRPORTS AND IDENTIFICATION OF PASSENGERS AND THEIR LUGGAGE Rodrigo R. Ferreira

Leia mais

A versão básica disponibiliza a informação criada no Microsoft Navision em unidades de informação

A versão básica disponibiliza a informação criada no Microsoft Navision em unidades de informação O Business Analytics for Microsoft Business Solutions Navision ajuda-o a ter maior controlo do seu negócio, tomar rapidamente melhores decisões e equipar os seus funcionários para que estes possam contribuir

Leia mais

Gestão dos Níveis de Serviço

Gestão dos Níveis de Serviço A Gestão dos Níveis de Serviço (SLM) Os sistemas e tecnologias de informação e comunicação têm nas empresas um papel cada vez mais importante evoluindo, hoje em dia, para níveis mais elevados de funcionamento

Leia mais

PHC Workflow. Informatize de forma eficaz todos os circuitos e processos de trabalho usados na sua empresa

PHC Workflow. Informatize de forma eficaz todos os circuitos e processos de trabalho usados na sua empresa PHCWorkflow DESCRITIVO O PHC Workflow permite que o conjunto de acções a executar, sigam uma ordem pré- -definida de acordo com as normas da empresa, aumentando a agilidade e produtividade dos colaboradores.

Leia mais

PHC Dashboard CS. Diversidade de análises de dados pré-configuradas. Representação gráfica da informação do sistema

PHC Dashboard CS. Diversidade de análises de dados pré-configuradas. Representação gráfica da informação do sistema PHC Dashboard CS Um novo nível de gestão A gestão da informação empresarial de forma sintética, visual e abrangente, possibilitando uma tomada de decisão mais rápida, correcta e precisa. BUSINESS AT SPEED

Leia mais

manual instalação e configuração v13 1

manual instalação e configuração v13 1 manual instalação e configuração v13 1 Conteúdo Introdução... 3 Conteúdo do DVD:... 3 Instalação e configuração do ERP... 4 Instalação do ERP... 4 Configuração do ERP... 6 Como actualização de versão...

Leia mais

ENIAC. Introdução aos Computadores e à Programação (Noções Básicas)

ENIAC. Introdução aos Computadores e à Programação (Noções Básicas) ENIAC Introdução aos Computadores e à ção (Noções Básicas) Introdução aos Computadores e à ção (Noções Básicas) 1 Introdução aos Computadores e à ção (Noções Básicas) 2 O transistor foi inventado em 1947

Leia mais

PHC Dashboard CS. Diversidade de análises de dados pré-configuradas. Representação gráfica da informação do sistema

PHC Dashboard CS. Diversidade de análises de dados pré-configuradas. Representação gráfica da informação do sistema PHC Dashboard CS Um novo nível de gestão A gestão da informação empresarial de forma sintética, visual e abrangente, possibilitando uma tomada de decisão mais rápida, correcta e precisa. BUSINESS AT SPEED

Leia mais