sistema de localização de bagagens · a perda ou tratamento incorrecto da bagagem nos aeroportos...
TRANSCRIPT
i
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!
ii
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
iii
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
iv
Índice
1. Introdução 1
1.1. Descrição do Problema ................................................................................................................. 2
1.2. Objectivos ..................................................................................................................................... 3
1.3. Solução Desenvolvida .................................................................................................................. 5
1.4. Contribuição e Resultados Atingidos ............................................................................................ 5
1.5. Organização da Dissertação ........................................................................................................ 6
2. Trabalho Relacionado 8
2.1. Soluções Comerciais .................................................................................................................... 8
2.2. Processo de Tratamento de Bagagens ........................................................................................ 9
2.3. Standards e Práticas Recomendadas ........................................................................................ 12
2.3.1. Baggage Information Messages .......................................................................................... 13
2.3.2. License Plate Number .......................................................................................................... 14
2.4. Tecnologia RFID ......................................................................................................................... 17
2.4.1. Electronic Product Code ...................................................................................................... 18
2.4.2. EPCglobal Architecture Framework ..................................................................................... 19
2.5. Tratamento de Eventos............................................................................................................... 21
2.5.1. Requisitos do Processamento de Eventos em Tempo-Real ............................................... 22
2.5.2. Sistemas de Processamento de Eventos em Tempo-Real ................................................. 26
2.5.3. Oracle Complex Event Processing ...................................................................................... 33
2.6. Sistemas Semelhantes ............................................................................................................... 37
2.7. Oracle Business Activity Monitoring ........................................................................................... 41
2.8. Síntese ........................................................................................................................................ 44
3. Arquitectura da Solução 45
3.1. Principais Componentes ............................................................................................................. 45
3.2. Principais Requisitos ................................................................................................................... 47
3.3. Síntese ........................................................................................................................................ 50
4. Descrição da Solução 52
4.1. Tratamento de Eventos............................................................................................................... 52
v
4.1.1. Principais Conceitos ............................................................................................................. 52
4.1.2. Eventos Utilizados ................................................................................................................ 55
4.1.3. Descrição do Modo de Processamento ............................................................................... 57
4.1.4. Modelo de Domínio .............................................................................................................. 64
4.2. Indicadores de Negócio .............................................................................................................. 66
4.3. Aplicação Interface ..................................................................................................................... 68
4.4. Enterprise Service Bus ............................................................................................................... 71
4.4.1. Descrição do Modo de Funcionamento ............................................................................... 71
4.5. Repositório de Eventos ............................................................................................................... 73
4.6. Síntese ........................................................................................................................................ 73
5. Avaliação Experimental 75
5.1. Testes de Desenvolvimento ....................................................................................................... 75
5.1.1. Testes Unitários ................................................................................................................... 75
5.1.2. Testes de Integração............................................................................................................ 76
5.2. Simulação do Sistema ................................................................................................................ 77
5.3. Teste da Componente de Tratamento de Eventos ..................................................................... 79
5.4. Teste da Componente de Indicadores de Negócio .................................................................... 83
5.5. Avaliação Qualitativa .................................................................................................................. 84
5.6. Síntese ........................................................................................................................................ 85
6. Conclusões e Trabalho Futuro 86
6.1. Conclusões Finais e Contribuições ............................................................................................ 86
6.2. Trabalho Futuro .......................................................................................................................... 88
7. 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
vi
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
vii
Lista de Figuras
Fig. 1.1. Origens dos erros no tratamento das bagagens (adaptado de [1]) 2
Fig. 2.1. Esquema representativo de um processo de tratamento de bagagens [6]. 9
Fig. 2.2. Entrada de um encaminhador primário, com leitores de códigos de barras para identificação
das malas. 11
Fig. 2.3. Exemplo esquemático de um sistema de encaminhamento de bagagens (adaptado de [6]). 12
Fig. 2.4. Visão geral da framework arquitectural proposta pela EPCglobal. 20
Fig. 2.5. Processamento da stream enquanto os dados fluem, com armazenamento opcional. 22
Fig. 2.6. Sistema de processamento de streams, com uma base de dados embebida neste. 24
Fig. 2.7. Conceitos e operadores nos quais se baseia a semântica abstracta implementada pela CQL
(adaptado de [15]). 27
Fig. 2.8. 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 Ra…j e as streams de input ou output são identificadas por Sa..d. 28
Fig. 2.9. Composição de um plano de query composto por operadores, queues e sinopses. 31
Fig. 2.10. Arquitectura do EPC Sensor Network. 32
Fig. 2.11. Arquitectura da plataforma Complex Event Processing da Oracle, adaptado de [25]. 34
Fig. 2.12. Fluxo de dados típico de uma aplicação assente na plataforma Complex Event Processing
da Oracle. 35
Fig. 2.13. Arquitectura proposta pela Oracle no âmbito do tratamento de bagagens num aeroporto. 36
Fig. 2.14. Arquitectura proposta por Ting et al. para um sistema de monitorização de bagagens
distribuído (adaptado de [29]). 37
Fig. 2.15. Procedimento de localização de uma mala (adaptado de [29]). 39
Fig. 2.16. Colocação dos leitores RFID ao longo do processo de encaminhamento das bagagens. 40
Fig. 2.17. Diagrama arquitectural do Oracle Business Activity Monitoring. 41
Fig. 3.1. Diagrama arquitectural da solução. 46
Fig. 4.1. Principais componentes de uma aplicação orientada a eventos [36]. 53
Fig. 4.2. Representações gráficas dos elementos de uma EPN – Processador, Canal, Stream,
Adaptador, Bean, Event Bean e Cache. 55
Fig. 4.3. Parte da EPN responsável pelo processamento de eventos provenientes do SGO. 58
Fig. 4.4. Elementos da EPN que participam na monitorização das malas (adaptado do Anexo D). 61
Fig. 4.5. Detalhe dos elementos da EPN envolvidos na monitorização dos tempos das malas em cada
segmento. 64
Fig. 4.6. Classes de domínio Baggage e Flight e respectivos campos. 65
Fig. 4.7. Configuração do plano BaggageMessage Plan no Plan Monitor. 66
Fig. 4.8. 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. 4.9. Relatório de Operação de um voo de partida. 68
viii
Fig. 4.10. Exemplo de informação apresentada pela aplicação interface sobre a localização de uma
mala. 70
Fig. 4.11. Composição da componente Enterprise Service Bus da solução. 72
Fig. 5.1. Diagrama da aplicação de mercados de capitais utilizada no benchmark do Oracle CEP. 80
Fig. 5.2. Latência média obtida por número de ligações simultâneas (primeira sessão de testes). 81
Fig. 5.3. Latência máxima absoluta por número de ligações simultâneas (primeira sessão de testes).81
Fig. 5.4. Latência média por frequência de injecção de eventos (segunda sessão de testes). 82
Fig. 5.5. Latência máxima por frequência de injecção de eventos (segunda sessão de testes). 82
Fig. 5.6. Latência medida durante 10 minutos de emissão de eventos com um tempo de espera entre
eventos de 1 segundo. 83
Fig. 5.7. Requisitos não-funcionais e a forma como estes foram cumpridos. 85
ix
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
x
Lista de Acrónimos/Abreviaturas
ADC Active Data Cache
AI Aplicação Interface
ALE Application Level Events
ARE Active Reports Engine
BAM Business Activity Monitoring
BIM Baggage Information Messages
BIP Baggage Improvement Programme
BPM/BPEL Business Process Management/Business Process Execution Language
BSM Baggage Source Message
CEP Complex Event Processing
CIN Componente de Indicadores de Negócio
CQL Continuous Query Language
CTE Componente de Tratamento de Eventos
DAO Data Access Object
DCS Departure Control System
DSMS Data Stream Management System
EDA Event-Driven Architecture
EPC Electronic Product Code
EPL Event Processing Language
EPN Event Processing Network
ERP Enterprise Resource Planning
ESB Enterprise Service Bus
ESN EPC Sensor Network
GIS Geographic Information System
GORM Grails Object Relational Mapping
GSP Groovy Server Pages
IATA International Air Transport Association
IS Information Service
ISM Information Service Manager
JDBC Java Database Connectivity
JMS Java Message Service
JSP Java Server Pages
JVM Java Virtual Machine
LPN License Plate Number
LTWS Location Tracking Web Service
MVC Model View Controller
POJO Plain Old Java Object
RE Repositório de Eventos
xi
RFID Radio Frequency Identification
RNF Requisito Não-Funcional
SE Simulador de Eventos
SGBD Sistema de Gestão de Bases de Dados
SGTIN Serialized Global Trade Item Number
SLA Service Level Agreement
SOA Service-Oriented Architecture
SOAP Simple Object Access Protocol
STREAM Ver DSMS
TSU Telcos, Saúde e Utilities
UDDI Universal Description Discovery and Integration
WSDL Web Services Description Language
XE Express Edition
xii
You’ve got to be careful if you don’t know where you’re going,
’cause you might not get there.
Yogi Berra
1
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 prende-
se 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.
2
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).
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
Fig. 1.1. Origens dos erros no tratamento das bagagens (adaptado de [1])
3
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.
1.2. 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
4
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.
5
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.
1.3. 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.
1.4. 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
6
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.
1.5. 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.
7
- 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.
8
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.
2.1. 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
9
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.
2.2. Processo de Tratamento de Bagagens
O processo de tratamento de bagagens é composto por uma série de passos, desde o check-
in 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. 2.1. Esquema representativo de um processo de tratamento de bagagens [6].
10
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 sub-
processo 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.
11
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.
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.
Fig. 2.2. Entrada de um encaminhador primário, com leitores de códigos de barras para identificação das malas.
12
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.
2.3. 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.
Fig. 2.3. Exemplo esquemático de um sistema de encaminhamento de bagagens (adaptado de [6]).
13
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.
2.3.1. 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).
14
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 Descrição do campo
BTM<≡ - Início de uma BTM;
.V/1TORD<≡ - Bagagem que fez escala (T) em ORD;
.I/KL318/14JAN/AMS<≡ - Chegou no voo KL318 vindo de AMS;
.F/UA423/14JAN/DEN<≡ - Partirá no voo UA423 para DEN;
.N/0074123456003<≡ - São 3 malas em que o ID da primeira é o 0074123456;
.P/SMITH/J<≡ - Nome do passageiro;
ENDBTM<≡ - Fim de uma BTM.
Tabela 2.1. Conteúdo de uma Baggage Transfer Message.
2.3.2. 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
15
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 5.1.2 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/0074123456005<≡. Isto significa que entraram no processo 5 malas (o conteúdo dos 3 últimos
dígitos, ―005‖) e que o LPN da primeira mala é 0074123456, sendo que os LPN das restantes quatro
malas serão os valores exactamente seguintes, isto é, 0074123457, 0074123458, 0074123459 e
0074123460, respectivamente.
16
Exemplo: 2125325679
Posição do Campo
Conteúdo Possível
Semântica Interpretação do
Exemplo
1º Campo: 2125325679
1º dígito
0 LPN usado apenas entre companhias aéreas.
Mala considerada prioritária porque sofreu um atraso e não embarcou (devido a um erro no seu encaminhamento).
1
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.
2
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.).
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: 2125325679
2º ao 4º dígito
000-999
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: 2125325679
5ª ao 10º dígito
000000-
999999
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 325679. 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.
17
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 18000-6C) 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
18
ú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).
2.4.1. 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).
19
Cabeçalho Valor do
Filtro Partição
Prefixo da
Entidade
Referência
do Objecto Número de Série
Comprimento 8 3 3 20-40 24-4 38
Valores
possíveis
0011 0000
(binário) NA NA
999.999
-
999.999.999.999
(intervalo
decimal)
9.999.999
-
9
(intervalo
decimal)
274.877.906.943
(valor máximo
decimal)
Semântica
Define o tipo
de sistema
de
identidade a
utilizar (está
aqui
apresentado
o SGTIN).
Define o
tipo de
produto,
para
permitir a
rápida
filtragem
de tags.
Define o
número de
bits
atribuídos
ao prefixo
da entidade
e referência
do objecto.
Valor que
identifica a
entidade que
atribuiu o EPC.
Valor que
identifica a
classe/tipo
do objecto
em
questão.
Número de série
que identifica
univocamente o
objecto em
questão na classe
a que pertence.
Legenda: NA – Não se aplica.
Tabela 2.3. Campos de um Electronic Product Code SGTIN-96 (adaptado de [14]).
2.4.2. 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).
20
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
Fig. 2.4. Visão geral da framework arquitectural proposta pela EPCglobal.
21
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.
2.5. 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
22
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.).
2.5.1. 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:
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.
Fig. 2.5. Processamento da stream enquanto os dados fluem, com armazenamento opcional.
23
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.
24
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.
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
Fig. 2.6. Sistema de processamento de streams, com uma base de dados embebida neste.
25
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
26
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.
2.5.2. 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
27
eficiente e genérica para realizar queries contínuas sobre streams de dados e permitir relações
dinâmicas entre estas.
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.
Fig. 2.7. Conceitos e operadores nos quais se baseia a semântica abstracta implementada pela CQL (adaptado de [15]).
28
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.
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 Si com
timestamps ≤ t para cada stream de input Si ou relações instantâneas Rj(t’) em que t’ ≤ t para
cada relação de input Rj. 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 Ra, Rb e Rc nos instantes t0, t1 e t2 e gera como output no instante t4
a relação Rd. De notar o facto de t0, t1 e t2 não terem de ser necessariamente diferentes e de todos
estes terem de ser anteriores ou iguais a t4 (i.e., t0,t1,t2 ≤ t4). 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 Sa como input e gera uma relação Re no instante t5. 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:
Fig. 2.8. 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 Ra…j e as streams de input ou output são identificadas por Sa..d.
29
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 {A1,…,Ak} de S, sendo
especificada por ―[Partition By A1,…,Ak 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 A1,…,Ak, 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 Rd no instante t4 e como resultado gera uma stream Sd. 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
30
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 q1 e q2 contêm os dados provenientes das streams, a queue q3
consiste no output da aplicação da janela deslizante ―[Rows 1000]‖ à stream S1, enquanto a queue
q4 tem o resultado da aplicação da janela deslizante ―[Range 2 Minutes]‖ à stream S2. A queue q5
contém os elementos que resultaram da operação ―S1 [Rows 1000] JOIN S2 [Range 2
Minutes]‖, enquanto a queue q6 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.
31
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.
Fig. 2.9. Composição de um plano de query composto por operadores, queues e sinopses.
32
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. 2.10. Arquitectura do EPC Sensor Network.
33
Estes componentes estão patentes no diagrama do ESN presente na Fig. 2.10. É 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.
2.5.3. 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
34
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 plug-
ins para o Eclipse, que completam a arquitectura apresentada na Fig. 2.11.
É 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. 2.12 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
Fig. 2.11. Arquitectura da plataforma Complex Event Processing da Oracle, adaptado de [25].
35
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.
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.
Fig. 2.12. Fluxo de dados típico de uma aplicação assente na plataforma Complex Event Processing da Oracle.
36
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.
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
Fig. 2.13. Arquitectura proposta pela Oracle no âmbito do tratamento de bagagens num aeroporto.
37
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.
2.6. 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. 2.14. Arquitectura proposta por Ting et al. para um sistema de monitorização de
bagagens distribuído (adaptado de [29]).
38
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.
39
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. 2.15 está explícito o procedimento de
localização aqui descrito.
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. 2.16 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
Fig. 2.15. Procedimento de localização de uma mala (adaptado de [29]).
40
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.
Tecnologia Alcance Anti-Colisão Memória Programação Leitura por
humanos Penetrabilidade
Códigos de
barras < 10 cm Não Pequena Limitado Limitada Impossível
RFID (UHF
EPC Class 1
Generation 2)
< 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
Leitores: Código de
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.
Fig. 2.16. Colocação dos leitores RFID ao longo do processo de encaminhamento das bagagens.
41
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.
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
Fig. 2.17. Diagrama arquitectural do Oracle Business Activity Monitoring.
42
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. 2.17 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
43
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.
44
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.
2.8. 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.
45
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.
3.1. 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.
46
Fig. 3.1. Diagrama arquitectural da solução.
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.
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.
47
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.
3.2. 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 sub-
caracterí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 9126-1 [31] apresentado em [32], tendo sido complementadas quando necessário.
48
Característica
Qualitativa Definição:
Sub-
caracterí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 sub-
caracterí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.
Manutenabilidade
Capacidade que um
produto de software
tem de ser
modificado.
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.
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.
49
Característica
Qualitativa Definição:
Sub-
caracterí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 Validação:
Segurança
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.
Disponibilidade 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.
50
Requisito Não-Funcional Validação:
Modificabilidade 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.
Testabilidade Tratando-se de um protótipo, é fundamental que desde o início do
desenvolvimento existam ferramentas para assegurar o comportamento
esperado das funcionalidades implementadas.
Modularidade
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.
Escalabilidade
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.
Latência 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.
Adaptabilidade
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.
Tabela 3.2. Critérios de validação dos vários requisitos não-funcionais
definidos para a arquitectura apresentada.
3.3. Síntese
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:
DCS
Sistema de
Controlo de
Partidas
Permite realizar o check-in das malas de cada passageiro. É também
responsável por enviar Baggage Source Messages para o sistema de
encaminhamento de bagagens do aeroporto e para o sistema
apresentado, indicando a que voo cada mala está associada.
51
Nome Descrição:
SGO Sistema de Gestão
Operacional
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.
CTE
Componente de
Tratamento de
Eventos
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.
CIN
Componente de
Indicadores de
Negócio
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.
AI Aplicação Interface
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.
RE Repositório de
Eventos
Base de dados que armazena persistentemente o estado interno do
sistema de monitorização e o histórico dos eventos processados.
ESB Enterprise Service
Bus
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.
SE Simulador de
Eventos
Ferramenta criada para testar a CTE. Permite enviar eventos que na
realidade deveriam vir do DCS, SGO e da camada Tags.
Tags 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.
52
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.
4.1. 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.
4.1.1. 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
53
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.
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.
Fig. 4.1. Principais componentes de uma aplicação orientada a eventos [36].
54
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;
55
- 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.
4.1.2. 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.
Fig. 4.2. Representações gráficas dos elementos de uma EPN – Processador, Canal, Stream, Adaptador, Bean, Event Bean e Cache.
56
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,
57
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.
4.1.3. 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.
58
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.
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 Descrição do campo
<message> - Início de mensagem;
<type>TAKE_OFF</type> - Tipo da mensagem;
<flight>UA423</flight> - Referência do voo;
<timestamp>
2009-04-04T12:00:00
</timestamp>
- Instante em que mensagem
foi gerada pelo SGO;
</message> - Fim de mensagem.
Tabela 4.1. Exemplo de uma mensagem XML vinda do SGO que representa a partida de um avião.
Fig. 4.3. Parte da EPN responsável pelo processamento de eventos provenientes do SGO.
59
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
60
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 0125678921 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 (2009-04-04T12: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 Descrição do campo
<message> - Início de mensagem;
<operation>TAKE_OFF</operation> - Tipo da mensagem;
<flight>UA423</flight> - Referência do voo;
<direction>OUTBOUND</direction> - Direcção do voo;
<timestamp>
2009-04-04T12:00:00
</timestamp>
- Instante em que mensagem foi
gerada originalmente pelo SGO;
<airport>SMA</airport> - Aeroporto em questão;
</message> - Fim de mensagem;
<message>
<alert>MISSING</alert> Tipo de alerta;
<flight>UA423</flight> Referência do voo;
<direction>OUTBOUND</direction> - Direcção do voo;
<timestamp>
2009-04-04T12:00:15
</timestamp>
- Instante em que evento foi gerado
pelo takeOffProcessingBean;
<baggage>0125678921</baggage> - LPN da mala;
<locationCode>SMA_CHKIN</locationCode> - Código do ponto de monitorização;
<locationDescription>
Fim do processo de Check-In.
</locationDescription>
- Descrição do ponto de
monitorização;
</message> - Fim de mensagem.
Tabela 4.2. Mensagens XML enviadas para a componente de indicadores de negócio.
61
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
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.
Fig. 4.4. Elementos da EPN que participam na monitorização das malas (adaptado do Anexo D).
62
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
63
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
64
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).
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.
4.1.4. 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. 4.6.
Fig. 4.5. Detalhe dos elementos da EPN envolvidos na monitorização dos tempos das malas em cada segmento.
65
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.
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.
Fig. 4.6. Classes de domínio Baggage e Flight e respectivos campos.
66
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.
Fig. 4.7. Configuração do plano BaggageMessage Plan no Plan Monitor.
67
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.
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.
Fig. 4.8. Plano BaggageMessage Plan que executa a manipulação da informação proveniente das
mensagens enviadas pela CTE para que possa ser apresentada pela CIN.
68
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.
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).
4.3. 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.
Fig. 4.9. Relatório de Operação de um voo de partida.
69
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
70
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. 4.10.
A informação apresentada na figura acima demonstra o percurso da mala com o LPN
0000510051, 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.
Fig. 4.10. Exemplo de informação apresentada pela aplicação interface sobre a localização de uma mala.
71
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.
4.4.1. 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
72
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. 4.11 podem observar-se os elementos que compõem o ESB e que
executam o procedimento aqui descrito.
Fig. 4.11. Composição da componente Enterprise Service Bus da solução.
73
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.
4.6. 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, seguindo-
se 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.
74
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.
75
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.
5.1. 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.
5.1.1. 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
76
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.
5.1.2. 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.
77
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/0000010001010<≡
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 é
0000010001 (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 (2009-04-04T12: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
78
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.
79
É 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.
5.3. 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.
80
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 100.000 mensagens por segundo e por ligação a serem
enviadas pelo gerador de eventos, durante 10 minutos;
Fig. 5.1. Diagrama da aplicação de mercados de capitais utilizada no benchmark do Oracle CEP.
81
- 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 10.000 até 100.000 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.
Fig. 5.2. Latência média obtida por número de ligações simultâneas (primeira sessão de testes).
Fig. 5.3. Latência máxima absoluta por número de ligações simultâneas (primeira sessão de testes).
0,0
10,0
20,0
30,0
40,0
50,0
60,0
70,0
80,0
1 2 3 4 5 6 7 8 9 10Latê
ncia
média
(m
icro
ssegundos)
Número de ligações simultâneas
Latência média por 100.000 eventos/segundo/ligação
0,00
5,00
10,00
15,00
20,00
25,00
1 2 3 4 5 6 7 8 9 10Latê
ncia
máxim
a (
mili
ssegundos)
Número de ligações simultâneas
Latência máxima absoluta por 100.000 eventos/segundo/ligação
82
Fig. 5.4. Latência média por frequência de injecção de eventos (segunda sessão de testes).
Fig. 5.5. 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.
0,0
10,0
20,0
30,0
40,0
50,0
60,0
70,0
80,0
Latê
ncia
média
(m
icro
ssegundos)
Frequência de injecção de eventos (eventos/segundo)
Latência média por frequência de injecção (10 ligações)
0,00
5,00
10,00
15,00
20,00
25,00
Latê
ncia
máxim
a (
mili
ssegundos)
Frequência de injecção de eventos (eventos/segundo)
Latência máxima por frequência de injecção (10 ligações)
83
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.
5.4. 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
Fig. 5.6. Latência medida durante 10 minutos de emissão de eventos com um tempo de espera entre eventos de 1 segundo.
84
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.
5.5. 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
Não-Funcional
Forma como foi cumprido:
Segurança 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.
Disponibilidade
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.
Modificabilidade 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.
Testabilidade 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.
Modularidade 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.
Escalabilidade 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).
85
Requisito
Não-Funcional
Forma como foi cumprido:
Latência 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.
Adaptabilidade É 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.
Fig. 5.7. Requisitos não-funcionais e a forma como estes foram cumpridos.
5.6. Síntese
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.
86
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.
6.1. 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
87
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.
88
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
89
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: e-mail, 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.
90
7. Referências
[1] I. A. T. Association, ―Baggage improvement programme, simplifying the business,‖
International Air Transport Association, Tech. Rep., 2008.
[2] Baggage handling solution. SkyTECH Solutions. [Online]. Available:
http://www.skytechsolutions.com/pdf/Airport%20Operations/Baggage%20Handling.pdf
[3] Baggage management system. AirIT. [Online]. Available:
http://www.airit.com/assets/pdfs/BMSsheet.pdf
[4] Airport systems. FKI Logistex. [Online]. Available: http://www.fkilogistex.com/_pdf/case-
studies/Jacksonville_CS.pdf
[5] Worldtracer. SITA. [Online]. Available: http://www.worldtracer.aero/
[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, 2007.
[7] I. A. T. Association, ―Rfid business case for baggage tagging,‖ International Air Transport
Association, Tech. Rep., 2007.
[8] I. A. T. Association, Passenger Services Conference Resolutions Manual. International Air
Transport Association, 2008.
[9] J. Hightower and G. Borriello, ―Location systems for ubiquitous computing,‖ 2001.
[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, 2008.
[11] I. A. T. Association, ―Rfid transition plan for baggage,‖ International Air Transport Association,
Tech. Rep., 2007.
[12] A. T. U. Council, ―Mishandled baggage,‖ Air Transport Users Council, Tech. Rep., 2007.
[13] P. Harrop, R. Das, and G. Holland. (2008, June) Rfid for airports and airlines 2008-2018.
[Online]. Available: http://www.idtechex.com/products/en/articles/00000486.asp
[14] EPCglobal, Tag Data Standards, EPCglobal Std., Rev. 1.4, June 2008. [Online]. Available:
http://www.epcglobalinc.org/standards/tds/tds_1_4-standard-20080611.pdf
[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 2004-20, 2004. [Online]. Available: http://ilpubs.stanford.edu:8090/641/
[16] M. Stonebraker, U. Çetintemel, and S. Zdonik, ―The 8 requirements of real-time stream
processing,‖ SIGMOD Rec., vol. 34, no. 4, pp. 42–47, December 2005. [Online]. Available:
http://dx.doi.org/10.1145/1107499.1107504
[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, 2007.
[18] A. Arasu, S. Babu, and J. Widom, ―The cql continuous query language: Semantic foundations
and query execution,‖ Stanford InfoLab, Technical Report 2003-67, 2003. [Online]. Available:
http://ilpubs.stanford.edu:8090/758/
[19] NiagaraCQ: A Scalable Continuous Query System for Internet Databases, 2000.
[20] Characterizing Memory Requirements for Queries over Continuous Data, 2002.
91
[21] Processing complex aggregate queries over data streams. New York, NY, USA: ACM, 2002.
[22] Models and issues in data stream systems. New York, NY, USA: ACM, 2002.
[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. 1379–1390, 2008.
[24] Complex Event Processing in EPC Sensor Network Middleware for Both RFID and WSN.
Washington, DC, USA: IEEE Computer Society, 2008.
[25] Oracle. (2008, September) Oracle complex event processing performance. [Online]. Available:
http://www.oracle.com/technology/products/event-driven-
architecture/collateral/cepperformancewhitepaper.pdf
[26] ——. (2008) Airline baggage handling demo - oracle soa solutions. Fornecido pela Oracle.
[27] S. Frischbier, ―Existing rfid infrastructures - comparison and evaluation,‖ RFID Seminar, pp.
17–32, 2006.
[28] Z. Ting, O. Yuanxin, L. Chao, and X. Zhang, ―A scalable rfid-based system for location-aware
services,‖ IEEE, 2007.
[29] Z. Ting, X. Zhang, and O. Yuanxin, ―A framework of networked rfid system supporting location
tracking,‖ IEEE, 2006.
[30] Assessing the Feasibility of Using RFID Technology in Airports, 2007. [Online]. Available:
http://dx.doi.org/10.1109/RFIDEURASIA.2007.4368091
[31] ISO/IEC 9126-1:2001 Software engineering - Product Quality: Quality Model, ISO/IEC Std.,
2001.
[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. 133–150, 2003.
[33] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Second Edition.
Addison-Wesley Professional, April 2003. [Online]. Available:
http://www.amazon.com/exec/obidos/redirect?tag=citeulike07-20&path=ASIN/0321154959
[34] A. S. Tanenbaum and M. van Steen, Distributed Systems: Principles and Paradigms (2nd
Edition). Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 2006. [Online]. Available:
http://portal.acm.org/citation.cfm?id=1202502
[35] Scale in Distributed Systems. IEEE Computer Society Press, 1994.
[36] O. Etzion and P. Niblett, Event Processing in Action. Manning, February 2010.
[37] P. Purich, Oracle CEP Getting Started. Oracle, May 2009.
[38] PolarLake, ―Understanding the esb,‖ February 2006.
[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 2004.
[41] V. Massol and T. Husted, JUnit in Action. Greenwich, CT, USA: Manning Publications Co.,
2003.
[42] J. Schiefer, G. Saurer, and A. Schatten, ―Testing event-driven business processes,‖ Journal of
Computers, vol. 1, no. 7, pp. 69–80, 2006.
92
[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. 293–298, 2009.
[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. 313–316.
[45] Oracle. (2009) Oracle coherence data sheet. Fornecido pela Oracle. Consultado em Outubro
de 2009. [Online]. Available: http://www.oracle.com/products/middleware/coherence/docs/oracle-
coherence-data-grid-datasheet.pdf
93
Anexo A Resumo dos Campos das Information Messages
94
Anexo B Campos Disponíveis para Armazenamento de
Informação numa Tag
95
Anexo C Topologia do Sistema de Monitorização Implementado
no Aeroporto de Pequim
96
Anexo D Event Processing Network da Solução
97
98
Anexo E Hierarquia de Eventos da Solução
99
Anexo F Modelo de Domínio da Solução
100
Anexo G Modelo Entidade-Relação da Base de Dados
101
Anexo H Exemplos de Relatórios da Componente de Indicadores de Negócio
102
103
Anexo I Mensagens Utilizadas no Simulador de Eventos
1. Mensagem proveniente do SGO que informa que foram colocados os calços no voo ARR03:
<event>
<timeoffset>0</timeoffset>
<data><![CDATA[
<message>
<type>CHOCKS_ON</type>
<flight>ARR03</flight>
<timestamp>2009-04-04T16:00:01</timestamp>
</message>
]]></data>
<type>SGO</type>
</event>
2. Mensagem proveniente do DCS que informa que existem 10 malas (cujo LPN da primeira é o
0000010001) que estão associadas ao voo ARR03 que chegou:
<event>
<timeoffset>5</timeoffset>
<data><![CDATA[
BSM<≡
.V/1TZRH<≡
.I/ARR03/18APR/LIS/F<≡
.N/0000010001010<≡
ENDBSM<≡
]]></data>
<type>DCS</type>
</event>
3. Mensagem proveniente da leitura da mala 0000010001 no ponto PLN_2:
<event>
<timeoffset>10</timeoffset>
<data><![CDATA[
<message>
<lpn>0000010001</lpn>
<flightDate>#{currentDate}</flightDate>
<locationCode>PLN_2</locationCode>
<timestamp>#{currentDate}</timestamp>
</message>
]]></data>
<type>BAGGAGEREAD</type>
</event>
104
4. Mensagem proveniente do SGO que informa que o check-in para o voo ARR03 foi encerrado:
<event>
<timeoffset>0</timeoffset>
<data><![CDATA[
<message>
<type>CHECKIN_CLOSED</type>
<flight>ARR03</flight>
<timestamp>#{currentDate}</timestamp>
</message>
]]></data>
<type>SGO</type>
</event>
5. Mensagem proveniente do SGO que informa que o voo ARR03 partiu:
<event>
<timeoffset>0</timeoffset>
<data><![CDATA[
<message>
<type>TAKE_OFF</type>
<flight>ARR03</flight>
<timestamp>#{currentDate}</timestamp>
</message>
]]></data>
<type>SGO</type>
</event>
105
Anexo J Resultados obtidos no benchmark do Oracle CEP
Dados referentes à primeira sessão de testes:
Número de
ligações
Frequência de injecção de eventos
por ligação (eventos/segundo)
Frequência de injecção de eventos
total (eventos/segundo)
Frequência de eventos de saída
(eventos/segundo)
Latência média (microsegundos)
Latência máxima absoluta
(milisegundos)
1 100.000 100.000 3911 42,6 8,77
2 100.000 200.000 7811 44,0 12,77
3 100.000 300.000 11686 47,2 12,93
4 100.000 400.000 15595 49,3 13,45
5 100.000 500.000 19466 51,5 15,73
6 100.000 600.000 23351 53,6 16,64
7 100.000 700.000 27234 55,5 18,60
8 100.000 800.000 31235 58,3 19,50
9 100.000 900.000 35080 62,0 19,21
10 100.000 1.000.000 38890 67,3 21,52
Dados referentes à segunda sessão de testes:
Número de
ligações
Frequência de injecção de eventos
por ligação (eventos/segundo)
Frequência de injecção de eventos
total (eventos/segundo)
Frequência de eventos de saída
(eventos/segundo)
Latência média (microsegundos)
Latência máxima absoluta
(milisegundos)
10 10.000 100.000 3893 45,2 13,97
10 20.000 200.000 7793 45,7 13,26
10 30.000 300.000 11676 47,2 13,81
10 40.000 400.000 15564 49,3 16,12
10 50.000 500.000 19460 51,6 19,21
10 60.000 600.000 23348 54,2 20,96
10 70.000 700.000 27239 56,6 20,91
10 80.000 800.000 31123 59,4 20,31
10 90.000 900.000 35001 62,9 21,83
10 100.000 1.000.000 38890 67,3 21,52