Embed Size (px)
Citation preview
Implementação dos serviços EPCIS para o BizTalk RFID
Pedro Daniel Parreira Ferreira
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Maio 2011
Agradecimentos
Expresso a minha gratidão ao Professor Doutor José Alves Marques, pela sua orientação ao longo
deste trabalho. Agradeço também ao Professor Miguel Pardal pela ajuda fornecida e o encorajamen-
to transmitido nas alturas de maior dificuldade, que me ajudaram completar este desafio.
Quero agradecer também à Link Consulting por me ter dado a possibilidade e as condições para
realizar este trabalho, podendo contar com o tempo e apoio de dois dos seus consultores seniores.
Assim, agradeço ao Eng. Mário Romano e ao Eng. Manuel Fonseca, não só por todo o tempo que
me acompanharam na resolução de problemas mas também por todas as sugestões que me deram.
A vossa experiência e conhecimento foram cruciais para o sucesso deste trabalho.
Quero agradecer a toda minha família, um agradecimento especial para os meus pais, porque sem o
vosso constante apoio seria tudo muito mais difícil. Obrigado por toda a ajuda que me deram, não só
durante a minha formação académica mas também durante a minha formação pessoal.
Aos meus amigos e colegas de curso que me acompanharam nesta jornada, obrigado pelo apoio,
votos de confiança e encorajamento transmitidos ao longo da realização do trabalho.
Finalmente e não em último lugar, deixo aqui o agradecimento para uma pessoa muito especial, a
minha namorada Filipa Xavier, que foi o meu principal suporte durante a realização deste trabalho,
que me ajudou imenso e transmitiu a força e perseverança necessárias para a conclusão deste tra-
balho.
O meu sincero agradecimento a todos.
13 de Maio de 2011
Pedro Daniel Parreira Ferreira
.
i
Resumo
As cadeias de valor têm vindo a tornar-se mais complexas, com mais intervenientes e envolvendo
uma grande variedade de sistemas de informação. A tecnologia RFID tem potencial para melhorar
estes processos e, por isso, fez-se um esforço para a sua normalização, liderado pela EPCglobal. A
EPCIS é uma das camadas da arquitectura EPCglobal que disponibiliza serviços para partilha de
informação.
O problema abordado neste trabalho é a necessidade de implementar a norma EPCIS para a partilha
de informação, contida nas etiquetas RFID, entre empresas parceiras de negócio que possuem sis-
temas de informação distintos e heterogéneos. Neste sentido, foi identificada a necessidade de uma
implementação que facilitasse o cumprimento da norma EPCIS para middlewares RFID já existentes.
Para demonstrar a funcionalidade e utilidade da solução desenvolvida, foi realizada uma extensão
para o middleware BizTalk RFID, que disponibiliza informação para outros sistemas independentes e
heterogéneos, de acordo com a norma EPCIS. Estes desenvolvimentos consistiram na criação de
serviços Web, de um repositório para armazenar eventos e de interfaces que respeitam as normas
EPCIS da arquitectura EPCglobal.
Palavras-chave: RFID, BizTalk RFID, middleware, EPCglobal, EPCIS
ii
iii
Abstract
Supply Chains are becoming more complex, with more players and involving a wide variety of infor-
mation systems. The RFID technology has the potential to improve these processes, and therefore
became an effort for their standardization, led by EPCglobal. The EPCIS is one of the EPCglobal
architecture layers that provide services for information sharing.
The problem addressed in this work is the need to implement the EPCIS standard for sharing informa-
tion, contained in RFID tags, between business partners that have different and heterogeneous infor-
mation systems. In this sense, we identified the need for an implementation that facilitates compliance
with the EPCIS standard for RFID middleware already in place. To demonstrate the functionality and
usefulness of the developed solution, an extension to the BizTalk RFID middleware was successfully
carried out, providing information to other independent and heterogeneous systems, according to the
EPCIS standard. These developments included the preparation of web services, a repository for stor-
ing events and interfaces that meet the EPCIS standards of the EPCglobal architecture.
Keywords: RFID, BizTalk, middleware, EPCglobal, EPCIS
iv
v
Índice
1. Introdução ....................................................................................................................................... 1
1.1. Descrição do Problema ........................................................................................................... 2
1.2. Objectivos ................................................................................................................................ 4
1.3. Estrutura do documento .......................................................................................................... 5
2. Trabalho Relacionado ..................................................................................................................... 7
2.1. EPCglobal ............................................................................................................................... 7
2.1.1. EPCIS ................................................................................................................................ 12
2.2. Fosstrak ................................................................................................................................. 13
2.3. Middleware RFID .................................................................................................................. 14
2.3.1. BizTalk RFID ..................................................................................................................... 15
2.3.2. Arquitectura BizTalk RFID ................................................................................................. 15
2.3.3. Comparação da arquitectura BizTalk RFID com EPCglobal ............................................ 17
2.4. BizTalk Server ....................................................................................................................... 18
2.5. rfrbNet ................................................................................................................................... 21
3. Arquitectura da Solução ................................................................................................................ 23
3.1. Recomendações EPCglobal ................................................................................................. 23
3.2. Arquitectura ........................................................................................................................... 23
3.3. Segurança ............................................................................................................................. 28
3.4. Comparação com a arquitectura EPCglobal ......................................................................... 29
4. Descrição da Solução ................................................................................................................... 30
4.1. Soluções e Trabalho Utilizado .............................................................................................. 32
4.2. Repositório ............................................................................................................................ 32
4.3. Capture Interface .................................................................................................................. 36
4.4. Query Control ........................................................................................................................ 36
4.5. Query Callback ...................................................................................................................... 38
4.6. Query Interface...................................................................................................................... 39
4.7. Client Application .................................................................................................................. 40
4.8. Segurança ............................................................................................................................. 40
5. Avaliação ....................................................................................................................................... 42
vi
5.1. Cenário de Utilização ............................................................................................................ 42
5.1.1. Utilização do Mecanismo Callback ................................................................................... 46
5.2. Testes Unitários e de Integração .......................................................................................... 50
5.2.1. Integração com o Fosstrak ................................................................................................ 50
5.2.2. Integração com rfrbNet ..................................................................................................... 53
5.3. Testes de Desempenho ........................................................................................................ 56
6. Conclusões e Trabalho Futuro ...................................................................................................... 58
6.1. Conclusões Finais e Contribuições ....................................................................................... 58
6.2. Trabalho Futuro ..................................................................................................................... 59
7. Referências ................................................................................................................................... 61
ANEXO A – Modelo de Domínio ........................................................................................................... 63
ANEXO B – Detalhe das pesquisas efectuadas à solução .................................................................. 64
vii
Lista de Figuras
Fig. 1.1 - Arquitectura de um sistema RFID. .......................................................................................... 3
Fig. 1.2 – Demonstração de uma possível utilização do RFID numa cadeia de valor ........................... 3
Fig. 1.3 – Ilustração de três grupos com regras de comunicação distintas. .......................................... 4
Fig. 1.4 – Ilustração da localização do trabalho a realizar na arquitectura de um sistema RFID. ......... 5
Fig. 2.1 – Esquema da utilização da framework EPCglobal [9]. ............................................................ 8
Fig. 2.2 – Componentes da arquitectura EPCglobal. ............................................................................. 9
Fig. 2.3 – Exemplo de configuração da arquitectura EPCglobal. ......................................................... 12
Fig. 2.4 – Relação entre as interfaces EPCIS. ..................................................................................... 13
Fig. 2.5 – Arquitectura geral dos middlewares RFID [17]. .................................................................... 15
Fig. 2.6 – Arquitectura BizTalk RFID. ................................................................................................... 16
Fig. 2.7 – Integração do BizTalk Server RFID na arquitectura EPCglobal. ......................................... 18
Fig. 2.8 – Principais componentes do Biztalk Server. .......................................................................... 19
Fig. 2.9 – Desenho de um sistema EPCIS utilizando o Biztalk Server. ............................................... 21
Fig. 3.1 – Desenho simplificado da arquitectura da solução. ............................................................... 24
Fig. 3.2 – Diagrama da arquitectura da solução. ................................................................................. 24
Fig. 3.3 – Diagrama UML dos diferentes tipos de eventos EPCIS [7]. ................................................ 26
Fig. 3.4 - Protecção de agente, acção e recurso de uma aplicação informática ................................. 28
Fig. 3.5 – Comparação da arquitectura EPCglobal com a arquitectura proposta. ............................... 29
Fig. 4.1 – Diagrama da arquitectura da solução .................................................................................. 31
Fig. 4.2 – Tabelas do repositório onde são armazenados os eventos EPCIS ..................................... 34
Fig. 4.3 – Relações entre a tabela event_ObjectEvent e as restantes tabelas do repositório ............. 35
Fig. 4.4 – Ilustração do funcionamento da camada Query Callback .................................................... 38
Fig. 4.5 – Workaround para resolver o problema de importação do ficheiro XSD. .............................. 39
Fig. 5.1 – Exemplificação de um cenário de utilização. ....................................................................... 43
Fig. 5.2 – Exemplificação do funcionamento da subscrição com agendamento. ................................ 47
Fig. 5.3 – Exemplificação do funcionamento da subscrição com mecanismo de trigger. .................... 48
Fig. 5.4 - rfrbNet: Visão geral de cadeia de distribuição ...................................................................... 54
Fig. 5.5 - rfrbNet: Detalhes de agregação na montagem de um portátil .............................................. 55
Fig. 5.6 - Representação gráfica dos resultados dos testes de desempenho ..................................... 56
viii
Lista de Tabelas
Tabela 3.1 - Serviços da camada EPCIS Query Control. .................................................................... 27
Tabela 4.1 – Descrição da tabela subscriptions do repositório EPCIS ................................................ 33
Tabela 4.2 – Descrição da tabela event_objectEvent do repositório EPCIS ....................................... 34
Tabela 4.3 – Exemplos de parâmetros para a pesquisa de eventos ................................................... 36
Tabela 4.4 – Bindings mais utilizados no serviços WCF [28]. .............................................................. 41
Tabela 5.1 - Resultados dos testes de desempenho ........................................................................... 56
ix
Lista de Acrónimos/Abreviaturas
ALE - Application-Level Events
API - Application Programming Interface
ASN - Advance Shipping Notice
B2B - Business-to-Business
BPM - Business Process Management
CRM - Customer Relationship Management
DSPI - Device Service Provider Interface
EAI - Enterprise Application Integration
EPC - Electronic Product Code
EPCIS - EPC Information Services
ERP - Enterprise Resource Planning
LOB - Line of Business
ONS - Object Name Service
RFID - Radio-Frequency Identification
SDK - Software Development Kit
SOAP - Simple Object Access Protocol
TDT - Tag Data Translation
URI - Uniform Resource Identifier
WCF - Windows Communication Foundation
WMS - Warehouse Management System
1
1. Introdução
Ao longo do tempo as cadeias de valor têm-se tornado mais complexas e com mais intervenientes. É
comum que um objecto, desde a sua origem até ao seu destino final, passe por diversos intervenien-
tes, cada um com os seus sistemas de rastreio e monitorização.
A tecnologia RFID (Radio Frequency Identification) [1] tem-se vindo a impor neste meio e tem sido
cada vez mais utilizada nas cadeias de valor [2]. Apesar do custo associado aos equipamentos utili-
zados e etiquetas, esta tecnologia apresenta vantagens em relação ao código de barras, tornando os
processos mais simples e eficazes, nomeadamente[1]:
Possibilidade de armazenar mais informação;
Melhor segurança:
o Impossibilidade de leitura sem leitores próprios;
o A informação armazenada pode estar encriptada;
Leitura automática da etiqueta, sem intervenção humana;
Não é necessário existir linha de visão para efectuar a leitura;
Informação fisicamente distribuída, a informação pode não estar armazenada num sistema
central mas sim numa etiqueta anexada ao próprio objecto, tornando possível a sua consulta
em qualquer lugar e a qualquer hora.
À medida que o número de interessados nesta tecnologia RFID foi aumentando, surgiu a necessida-
de de se criarem normas para uniformizar o funcionamento da mesma. A organização internacional
EPCglobal1, em conjunto com empresas líderes de mercado, desenvolveu normas para a comunica-
ção de informação, criando então a norma Electronic Product Code (EPC), a qual se tornou na nor-
malização predominante na comunidade RFID [3][4].
A EPCglobal criou a rede EPC (EPC Network) [5], que foi desenhada e implementada com o objecti-
vo de uniformizar a partilha de informação de objectos através da internet. Esta rede foi construída
tendo em consideração tecnologias e normas da internet reconhecidas internacionalmente.
Os standards EPCglobal foram criados para cumprir os seguintes objectivos [6]:
Facilitar a troca de informação e de objectos entre parceiros de negócio
Para que seja possível haver troca de informação entre parceiros de negócio, é necessário
que haja um acordo prévio sobre a estrutura e significado da informação a ser trocada, e os
mecanismos pelos quais a troca será realizada.
Promover a existência de um mercado competitivo
1 EPCglobal - http://www.gs1.org/epcglobal
2
Os standards da EPCglobal definem as interfaces que deverão existir entre as componentes
de um sistema RFID. A normalização destas interfaces facilitam a interoperabilidade de com-
ponentes produzidos por diferentes fabricantes, promovendo assim um aumento da oferta
para as empresas que utilizam ou que pretendem utilizar sistemas RFID.
Incentivar a inovação dos sistemas
Os standards EPCglobal definem interfaces dando liberdade aos implementadores para ino-
varem nos produtos e sistemas que desenvolvem, enquanto a normalização das interfaces
assegura a interoperabilidade das diferentes componentes da arquitectura.
A componente EPCIS (EPC Information Services) [7] surge neste contexto como uma das camadas
da rede EPC, que é responsável por disponibilizar serviços para partilha de informação.
O rápido desenvolvimento de aplicações RFID, associado às vantagens que esta tecnologia traz,
levou ao aumento de empresas interessadas em participar no desenvolvimento de sistemas e dispo-
sitivos desta tecnologia. Confrontadas com diversas aplicações RFID e com os diversos protocolos
de comunicação, as empresas questionam-se sobre como fazer com que os sistemas de informação
existentes se liguem aos leitores RFID. A essência da questão é o middleware RFID, que faz uma
abstracção do hardware, apresentando uma interface para aplicações de alto nível.
Assim, a camada EPCIS permite a compatibilidade de diferentes middlewares RFID através de um
conjunto de interfaces e serviços normalizados.
1.1. Descrição do Problema
A figura 1.1 apresenta uma arquitectura típica de um sistema RFID numa dada organização. Os
dados das etiquetas são capturados por leitores, recolhidos, filtrados e armazenados na base de
dados. A partir destes dados são gerados eventos com informação de negócio.
3
Fig. 1.1 - Arquitectura de um sistema RFID.
A evolução do negócio leva a que sejam feitas diferentes parcerias com outras empresas ao longo do
tempo, sendo necessário que os sistemas de informação comuniquem entre si. [8]
Num processo de negócio semelhante ao ilustrado na figura seguinte, onde existem várias entidades
responsáveis pela cadeia de abastecimento de produtos e em que estas entidades possuem siste-
mas de informação independentes, é necessário que exista partilha de informação no sentido de uma
coordenação eficiente. [8]
Fig. 1.2 – Demonstração de uma possível utilização do RFID numa cadeia de valor
4
Para a comunicação entre sistemas é necessário que sejam seguidas regras que definam as interfa-
ces aplicacionais e os protocolos de comunicação. Na seguinte imagem ilustram-se três grupos dis-
tintos de parceiros de negócio com redes de comunicação distintas. Recorrendo às normas EPC,
pretende-se que todos possam comunicar entre si.
Fig. 1.3 – Ilustração de três grupos com regras de comunicação distintas.
No cenário em que vamos trabalhar já existe um sistema RFID mas não existem interfaces que res-
peitem as normas EPCIS.
1.2. Objectivos
Como objectivo para este trabalho, realizado em parceria com a empresa Link Consulting2, propomo-
nos desenvolver uma solução que facilite a adopção das normas EPCglobal para sistemas de infor-
mação, nomeadamente a norma EPCIS.
Para demonstrar a funcionalidade e utilidade da implementação, iremos utilizar o Microsoft BizTalk
RFID como middleware e estendê-lo de modo a que disponibilize informação, de acordo com as
normas, para outros sistemas independentes e heterogéneos. A integração final é ilustrada na figura
seguinte.
2 Link Consulting - http://www.link.pt
5
Fig. 1.4 – Ilustração da localização do trabalho a realizar na arquitectura de um sistema RFID.
Para garantir que a solução possa vir a ser utilizada num ambiente real e empresarial, serão realiza-
dos testes de validação e de integração com outras soluções existentes, que cumprem as mesmas
normas.
Para atingir estes objectivos teremos que compreender as necessidades existentes, verificar qual o
trabalho desenvolvido nesta área que possa ser aproveitado e, por fim, estudar as normas e reco-
mendações da comunidade com mais experiência e conhecimento na área, para que possamos inte-
grar no nosso trabalho as melhores ideias e soluções já desenvolvidas.
1.3. Estrutura do documento
Daqui em diante, a organização dos capítulos segue a mesma ordem que a metodologia seguida.
Assim, começa-se por analisar o trabalho relacionado (capítulo 2) com o tema. Esta secção inclui um
estudo aprofundado das normas EPCglobal e respectiva arquitectura, visto que as mesmas terão de
ser incorporadas na solução. Também aqui é estudada com detalhe a camada EPCIS e o middlewa-
re BizTalk RFID.
De seguida, é apresentada a arquitectura da solução (capítulo 3) com uma visão global da solução
proposta e uma breve descrição dos módulos que a compõem.
Finalmente, é apresentada a solução (capítulo 4) onde é feita uma descrição mais detalhada do tra-
balho desenvolvido, justificando as opções tomadas e abrangendo todas as tecnologias utilizadas.
6
A mesma solução foi sujeita a diversos testes de forma a garantir que satisfazia todos os requisitos e
produzia os resultados esperados. A descrição dos testes e respectivos resultados encontra-se na
secção Avaliação (capítulo 5).
Por fim, na conclusão (capítulo 6), é feito um resumo dos principais resultados e ainda apresentada a
proposta de trabalho futuro.
7
2. Trabalho Relacionado
Este capítulo tem como objectivo descrever tecnologias e projectos já realizados, relevantes para
este trabalho.
2.1. EPCglobal
A arquitectura recomendada pela organização EPCglobal é um standard da tecnologia RFID, e sur-
giu da necessidade de comercialização da mesma, por parte de várias empresas do mercado das
tecnologias e da distribuição[9]. Esta organização estabeleceu um conjunto de normas globais do
sistema GS13, que combina a tecnologia RFID com as infra-estruturas de redes de comunicação
existentes e com o EPC [6]. Além disto, elaborou ainda uma framework, tendo como objectivo identi-
ficar e localizar, de uma forma imediata e automática, um objecto ao longo do seu percurso na cadeia
de valor, estabelecendo um conjunto de serviços que possam ser utilizados por parceiros de negócio,
para procurar e aceder a grandes quantidades de informação de cada EPC, sendo esta informação
compartilhada apenas entre utilizadores autorizados.
A rede EPCglobal é constituída por cinco componentes de alto nível [9]:
Sistemas RFID – Sistemas que identificam objectos, efectuam leituras das etiquetas anexa-
das aos objectos, que os acompanham durante o seu trajecto. Nestes sistemas estão incluí-
das as etiquetas EPC e os respectivos leitores.
EPC middleware – Sistema que recebe informação resultante da leitura de uma etiqueta
EPC e armazena, filtra e agrupa essa informação para ser posteriormente utilizada por outras
aplicações, tais como, WMS e ERP. O objectivo desta partilha de informação é permitir a
gestão e controlo dentro da empresa.
EPC Information Services (EPCIS) – Conjunto de serviços que permite a partilha de dados
EPC pela rede EPCglobal. Esta camada utiliza como input outros sistemas para adicionar
contexto de negócio à informação obtida da leitura das etiquetas. Para além de receber
informação, esta camada também a partilha com outros sistemas. A partilha de informação
efectuada nesta camada é diferente da efectuada no middleware, pois tem como objectivo
partilhar informação com parceiros de negócio.
Object Name Services (ONS) - Conjunto de serviços que permite a procura dos endereços
de repositórios EPC, a partir de um identificador EPC.
EPC Discovery Services (EPC-DS) – Conjunto de serviços que localiza todos os repositó-
rios EPCIS que poderão ter informação sobre um particular EPC.
3 GS1 - http://www.gs1.org/
8
A seguinte imagem mostra a ligação que existe entre estes componentes.
Fig. 2.1 – Esquema da utilização da framework EPCglobal [9].
Estas componentes estão representadas em detalhe na figura seguinte, em que as caixas verdes
representam as interfaces regidas pelas normas EPCglobal, enquanto as caixas azuis representam
hardware e/ou software do sistema.
9
Fig. 2.2 – Componentes da arquitectura EPCglobal.
10
De seguida, com base na especificação EPCIS [7], faz-se uma sucinta descrição das responsabilida-
des dos principais elementos envolvidos:
Readers: Hardware que efectua a leitura e/ou escrita das etiquetas RFID quando estas pas-
sam na zona de leitura.
Reader Protocol Interface [10]: Interface que define o modo como os dados das etiquetas,
lidos pelos leitores, são enviados para a camada Filtering & Collection. Os eventos nesta
interface serão do tipo “Leitor A viu EPC X na data T.”
Filtering & Collection: Software que filtra e consolida os dados das leituras de etiquetas
RFID ao longo de um determinado intervalo de tempo.
Filtering & Collection (ALE) Interface [11]: Interface que define o modo como os eventos
filtrados e consolidados na camada Filtering & Collection são enviados para a camada Captu-
ring Application. Os eventos nesta interface serão do tipo “No leitor lógico L, entre a data T1
e T2, foram observados os seguintes EPCs”. Esta lista resultante de EPCs não contém dupli-
cados.
EPCIS Capturing Application [7]: Software que, com a cooperação de outras fontes de
informação envolvidas num determinado passo do processo de negócio, adiciona contexto
de negócio aos eventos recebidos da camada Filtering & Collection. Esta camada deverá
conseguir interpretar o passo, ou passos, do processo de negócio a que o evento recebido
pertence. O papel desempenhado pela Capture Application poderá ser complexo, envolven-
do a associação de vários eventos de várias aplicações Filtering & Collection, ou poderá ser
simples, efectuando uma transformação simples e directa dos eventos EPC em eventos
EPCIS. Esta camada também é responsável por armazenar os eventos EPCIS no repositório
EPCIS para que os eventos estejam disponíveis para futuras pesquisas.
EPCIS Accessing Application [7]: Representa a aplicação que efectua pesquisas de even-
tos EPCIS ao sistema e, que poderá executar processos de negócio tais como, gestão de
armazéns, envio e recepção de objectos e análise histórica de produção, com base na infor-
mação recebida.
EPCIS-enabled Repository [7]: Armazena eventos EPCIS gerados por uma ou mais EPCIS
Capturing Applications, tornando-os disponíveis para posteriores pesquisas efectuadas pelas
aplicações de acesso.
Partner Application: Sistema de um parceiro de negócio que se encontra fora da organiza-
ção e que desempenha o mesmo papel que a EPCIS Accessing Application. As Partner
11
Applications podem ter acesso apenas a um subconjunto de informação que está disponível
no EPCIS Repository.
EPCIS Interfaces[7]: Interfaces utilizadas na transferência dos dados EPCIS para o repositó-
rio, aplicações de pesquisa de eventos da própria empresa e de parceiros de negócio. Os
eventos EPCIS nesta interface são do tipo “No local X, à data T, os seguintes objectos (cai-
xas) foram verificados como estando agregados aos seguintes objectos (palete) ”. Existem
três interfaces EPCIS, a interface Capture, Query Control e Query Callback. A Capture Inter-
face é utilizada para a entrega de eventos EPCIS da Capturing Application para o repositório
EPCIS, aplicações de acesso e aplicações de parceiros de negócio. A Interface Query Con-
trol é utilizada para que aplicações, da própria empresa ou de parceiros de negócio, possam
obter dados EPCIS, depois de estes terem sido capturados. Esta interface disponibiliza dois
modos de interacção, síncrono e assíncrono. No modo síncrono ou “on-demand”, o cliente
efectua o pedido através da interface e recebe a resposta imediatamente. No modo assín-
crono ou “standing request”, o cliente estabelece uma subscrição para uma pesquisa periódi-
ca e, sempre que esta for executada, os resultados são entregues assincronamente ao des-
tinatário, através da Interface Query Callback. Por fim, a interface Query Callback, para além
de definir o modo como o resultado das pesquisas periódicas é enviado aos respectivos
subscritores, pode também ser usada para entregar eventos EPCIS imediatamente após a
captura na camada Capturing Application.
ONS[12]: O Object Naming Server é um serviço da rede que permite a procura dos endere-
ços de repositórios EPC, a partir de um identificador do gestor de EPC ou de um EPC com-
pleto. Especificamente, o ONS disponibiliza um meio para procurar um endereço de um ser-
viço EPCIS disponibilizado pela organização que ficou encarregue do EPC do objecto em
questão.
Discovery Capability: Refere-se a um mecanismo, cuja especificação ainda não foi definida
até à data da elaboração deste documento, que localiza todos os repositórios EPCIS que
poderão ter informação sobre um particular EPC. Isto é útil quando se deseja fazer uma pes-
quisa a um serviço EPCIS relevante mas este é desconhecido, tal acontece quando o históri-
co de manipulação de um objecto é desejado mas é desconhecida a sua origem.
Na figura seguinte está ilustrada uma possível situação de utilização da arquitectura EPCglobal. As
etiquetas com EPC são lidas pelos dispositivos de leitura e estes enviam essa informação para o
middleware à qual estão ligados. O middleware terá a responsabilidade de guardar essa informação
e/ou enviá-la para ser processada em camadas superiores da arquitectura.
12
Fig. 2.3 – Exemplo de configuração da arquitectura EPCglobal.
2.1.1. EPCIS
A EPCIS é uma das componentes da arquitectura recomendada pela EPCglobal, cujo objectivo é
permitir que aplicações e/ou instalações RFID separadas partilhem dados EPC, estando estas apli-
cações dentro da mesma empresa ou em empresas diferentes. Assim, é possível que os participan-
tes adquiram uma vista comum de objectos EPC, dentro de um contexto de negócio relevante.
Como é ilustrado na figura 2.2, a componente EPCIS está localizada no topo da arquitectura da fra-
mework EPCglobal, acima do nível de leituras de dados brutos EPC (hardware) e também acima do
nível de dados filtrados e consolidados (middleware).
Esta componente é responsável por capturar eventos EPC vindos das camadas inferiores (Filtering &
Collection) e torná-los disponíveis para que possam ser feitas pesquisas e subscrições por parte dos
parceiros de negócio. Indica também como é que os eventos e as interrogações devem ser estrutu-
rados e as ligações que devem ser utilizadas para a partilha de informação entre os sistemas dos
parceiros de negócio. Esta componente utiliza dados vindos da camada inferior e acrescenta-lhe o
contexto de negócio vindo de outras fontes, tais como o ERP e o WMS, e guarda esse resultado no
seu repositório para poder servir como base para outras tarefas de processamento de informação.
As principais características da componente EPCIS são que esta:
Lida com dados históricos e com dados actuais;
13
Lida com leituras de dados filtrados e consolidados, contextualizando as observações na rea-
lidade de negócio a que se aplica;
Opera dentro do ambiente da empresa a um nível muito mais diverso e multifacetado que os
níveis inferiores da arquitectura da rede EPCglobal. Por estar posicionado no nível mais ele-
vado da arquitectura é o ponto natural de ligação com os sistemas de outras empresas, que
variam muito de empresa para empresa.
A componente EPCIS é constituída por diferentes camadas, a Capture Interface, o Repositório e a
Query Interface (Control e Callback).
A figura seguinte ilustra o funcionamento do conjunto destas mesmas camadas, o modo como estas
estão ligadas e as direcções dos fluxos de informação.
Fig. 2.4 – Relação entre as interfaces EPCIS.
2.2. Fosstrak
O Fosstrak4
é um sistema open source, disponível gratuitamente, para o rastreio e monitorização de
objectos. Este sistema implementa um conjunto de normas5 estabelecidas pela comunidade EPCglo-
bal, tais como ALE, RP, RM, LLRP, TDT e EPCIS.
O projecto Fosstrak (inicialmente denominado por Accada) foi iniciado pelo grupo de sistemas distri-
buídos e pelo laboratório Auto-ID da universidade ETH em Zurique, tendo como público-alvo os pro-
gramadores de aplicações, os novos utilizadores de EPC, os integradores de sistemas e os grupos
universitários e industriais de investigação [13].
4 Fosstrak - http://www.fosstrak.org/
5 Normas EPCglobal - http://www.gs1.org/gsmp/kc/epcglobal
14
Neste contexto, é de salientar esta solução que tem como objectivo fornecer componentes essen-
ciais para aplicações da rede EPC, formar os utilizadores da rede EPC, promover a utilização das
normas EPCglobal na educação e na investigação e facilitar a prototipagem.
Neste momento, o Fosstrak possui várias componentes da arquitectura EPCglobal [14] :
EPCIS - Certificado pela EPCglobal.
Biblioteca Tag Data Translation (TDT) – Esta biblioteca facilita a conversão de diferentes
representações EPC (BINARY, tag-encoding URI, pure-identity URI, legacy formats) e foi
desenvolvida pelo autor da especificação EPCglobal TDT [15].
Middleware Filtering & Collection - Suporta a versão 1.1 do EPCglobal ALE [11].
Suporte de Leitura - Foi desenvolvido o suporte para os leitores RFID mais comuns.
De acordo com Pereira [16], que fez um estudo sobre a possível utilização do Fosstrak numa cadeia
de valor, o Fosstrak está preparado apenas para prototipagem, uma vez que existem falhas ocasio-
nais para pequenos sistemas de produção e apresenta uma difícil integração com regras e lógica de
negócio, quando aplicado num ambiente real.
2.3. Middleware RFID
Ao analisar os middlewares existentes no mercado notamos que, neste momento, existem vários
sistemas que são propriedade de empresas na área do RFID, que construíram a sua própria arqui-
tectura, semelhante recomendada pela organização EPCglobal [17]. Alguns exemplos de middlewa-
res são o Siemens RFID middleware6, o Sun Java System RFID Software
7, o Oracle Sensor Edge-
Server8, o IBM WebSphere RFID Premises Server
9 e o BizTalk RFID
10.
6 Siemens RFID middleware - http://www.automation.siemens.com/rfid/en/competence-in-rfid.html
7 Sun Java System RFID - http://java.sun.com/developer/technicalArticles/Ecommerce/rfid/sjsrfid/RFID.html
8 Oracle Sensor Edge Server - http://download.oracle.com/docs/cd/B14099_19/wireless.1012/b13819/rfid.htm
9 IBM WebSphere RFID Premises Server - http://www.redbooks.ibm.com/abstracts/sg247147.html
10 BizTalk RFID - http://www.microsoft.com/biztalk/en/us/rfid.aspx
15
Fig. 2.5 – Arquitectura geral dos middlewares RFID [17].
Estas plataformas têm arquitecturas semelhantes, conforme ilustrado na figura anterior, e fazem uma
abstracção do hardware apresentando uma interface simples para as aplicações de alto nível. Ape-
sar de estes sistemas serem bastante eficientes no tratamento isolado de dados RFID, não conside-
ram por completo a especificação EPCIS para a partilha de informação, o que seria bastante útil para
o desenvolvimento de diferentes componentes por diversas organizações de modo que fossem
facilmente integradas [18].
2.3.1. BizTalk RFID
Não confundir o BizTalk RFID com o BizTalk Server, que será descrito mais adiante. O BizTalk RFID
é um middleware de RFID enquanto que o BizTalk Server é um servidor de integração.
O middleware Microsoft BizTalk RFID [19] facilita a instalação e configuração de sistemas RFID, dis-
ponibilizando um modo uniforme de descobrir, comunicar e manipular dispositivos RFID num ambien-
te Microsoft Windows [20].
O sucesso desta abordagem da Microsoft advém da possibilidade de adicionar novas camadas de
software à tecnologia, permitindo que todos os tipos de dispositivos possam ser incorporados de um
modo plug-and-play [20].
Esta infra-estrutura trabalha com uma linha de aplicações de negócio tais como, sistemas ERP,
WMS e outros softwares mais especializados, permitindo alguma flexibilidade [20].
2.3.2. Arquitectura BizTalk RFID
O BizTalk RFID, com a sua arquitectura extensível e características de segurança, oferece uma pla-
taforma que facilita o desenvolvimento de uma variedade larga de soluções RFID. A sua arquitectura
foi projectada de modo a que seja possível uma fácil transição de um baixo volume para um grande
volume de instalações RFID visto que, com a interface DSPI, facilmente se adicionam novos disposi-
tivos. A figura seguinte ilustra uma vista geral de alto nível da arquitectura do BizTalk RFID [19].
16
Fig. 2.6 – Arquitectura BizTalk RFID.
De seguida faz-se uma sucinta descrição das responsabilidades dos diversos elementos
envolvidos[19] :
Camada de Hardware
Nesta camada encontram-se todos os dispositivos que se pretendem controlar e obter informação.
Aqui podem estar incluídos leitores RFID, impressoras de etiquetas e leitores de códigos de barras.
Camada Device Service Provider Interface (DSPI)
Esta camada é composta por um conjunto genérico extensível de APIs que ajuda os fornecedores de
hardware a construir os device providers, interfaces especializadas que permitem a utilização dos
dispositivos RFID.
Para diminuir os esforços de integração, a Microsoft fornece uma plataforma, as especificações e os
testes de software, na forma de um kit de desenvolvimento de software RFID (SDK). Este SDK per-
mite a normalização de protocolos de múltiplas comunicações e suporte para um legado de leitores e
outros dispositivos de identificação automática.
A partir do momento em que os device providers são construídos usando o SDK, qualquer dispositivo
na rede pode ser descoberto, configurado e manipulado. Os programadores podem criar soluções ao
nível do negócio que interajam com os dispositivos RFID de um modo simples e uniforme, devido à
17
elevada quantidade de device providers existentes no BizTalk RFID, facilitando assim a configuração
e utilização dos dispositivos.
Camada Engine e Runtime
Esta camada permite que as aplicações filtrem, agreguem e transformem eventos RFID no seu esta-
do bruto, para informação específica do negócio. A primeira parte desta camada é composta pelo
event processing engine, que permite aos programadores de aplicações criar e gerir processos para
a transformação de eventos RFID, abstraindo-se do tipo de dispositivo de leitura e dos protocolos de
comunicação subjacentes.
A segunda parte desta camada é o device management, que é responsável por gerir todos os dispo-
sitivos. O device management permite um acompanhamento do estado do dispositivo, a observação
e controlo da configuração deste e o acesso a dispositivos de um modo fiável.
Camada BizTalk RFID APIs
Esta camada disponibiliza o modelo de objectos e APIs que facilitam o desenho, instalação e mani-
pulação dos pipelines de processamento de eventos necessários para a filtragem, agregação e trans-
formação da informação em informação útil.
Camada Designers Tools & Adapters
Está disponível um conjunto de APIs que permitem a criação de diferentes tipos de processos de
negócio. Uma dessas APIs é a Designers, que pode ser usada durante o período de desenho para
criar um processo de negócio RFID. Outro exemplo é a API Adapters que ajuda na integração de
eventos RFID em tempo real com o Microsoft BizTalk Server e/ou com aplicações ao nível do negó-
cio.
2.3.3. Comparação da arquitectura BizTalk RFID com EPCglobal
A EPCglobal estabeleceu um programa de certificação de software de modo a garantir que os siste-
mas adoptem um conjunto de normas estabelecidas por esta.
A figura seguinte mostra onde o BizTalk RFID encaixa na arquitectura recomendada pela EPCglobal,
desempenhando o papel da camada Filtering & Collection e da camada Capture Application. O Biz-
Talk RFID é responsável por filtrar e guardar a informação vinda dos leitores após a leitura de etique-
tas RFID (Filtering & Collection) e também contém uma versão simplificada da Capture Application,
onde converte os eventos EPC em eventos EPCIS e envia-os para a Capture Interface.
18
Fig. 2.7 – Integração do BizTalk Server RFID na arquitectura EPCglobal.
2.4. BizTalk Server
O servidor de Business Process Management (BPM), o Microsoft BizTalk Server11
é um produto que
permite a médias e grandes organizações automatizar os seus processos de negócio.
O BizTalk permite que haja um ponto central de integração entre sistemas que não partilham proto-
colos de comunicação, fornecendo um vasto conjunto de funcionalidades, das quais se destacam:
Serviços de comunicação e de transformação de mensagens XML;
Serviços de orquestração que permitem automatizar os vários passos de processamento
(workflow);
Capacidade de interacção com sistemas externos através de adaptadores próprios;
11
Microsoft BizTalk Server - http://www.microsoft.com/biztalk
19
Possibilidade de integração com Web Services [21].
A comunicação entre o BizTalk e os outros sistemas é efectuada através da troca de mensagens. O
motor de mensagens do BizTalk recebe as mensagens vindas de outros sistemas, identifica o seu
formato, extrai elementos da mensagem, aplica regras de encaminhamento (routing), e entrega as
mensagens no destino. O processamento a aplicar a cada mensagem é definido através de uma ou
mais orquestrações, e durante este processamento é utilizada uma base de dados chamada Messa-
geBox.
O BizTalk Server dispõe de uma funcionalidades de automatização e modelação de processos de
negócio, comunicação Business-to-Business (B2B), integração de aplicações empresariais (EAI) e
broker de mensagens.
A figura seguinte ilustra as principais componentes do BizTalk Server.
Fig. 2.8 – Principais componentes do Biztalk Server.
O BizTalk Server Engine pode ser dividido em dois blocos principais:
A componente de comunicação, que permite a troca de informação com outras aplicações. A
existência de adaptadores para diferentes tipos de comunicação permite que o servidor pos-
sa suportar uma variedade de protocolos e formatos de dados, incluindo web services.
Apoio para a criação e execução de processos, denominados por orquestrações. Construí-
das sobre a componente de comunicação, as orquestrações implementam a lógica que move
a totalidade ou parte de um processo de negócio.
Existem outras componentes que podem ser utilizadas em conjunto com a componente principal,
nomeadamente:
20
O “Business Rule Engine” que avalia conjuntos de regras complexos.
O “Health and Activity Tracking” que permite a monitorização e manutenção do servidor e
das orquestrações que estão em execução.
O “Enterprise Single Sign-On” (SSO) que facilita a integração de sistemas de autenticação.
O “Business Activity Monitoring” permite a observação, por parte dos utilizadores, do estado
de um processo de negócio em execução. A informação exibida é definida pelos utilizadores
e por isso, há uma abstracção da informação técnica e é fornecida apenas a informação de
negócio.
O Biztalk Server é utilizado principalmente como plataforma para soluções de processamento de
pagamentos, visibilidade da cadeia de valor, interacções multi-canal e suporte à decisão de proces-
sos que ocorrem próximo do tempo real [22].
Para além da integração de aplicações dentro de uma organização, o Biztalk Server também permite
a integração com aplicações de parceiros de negócio, que se encontram fora da organização.
O BizTalk contém um conjunto de adaptadores que facilitam a integração com diferentes aplicações,
de diferentes tecnologias, diminuindo o esforço associado ao desenvolvimento de soluções e tam-
bém a complexidade das mesmas [23].
O BizTalk Server poderia ser utilizado na nossa solução, na camada responsável pelo tratamento de
eventos, onde os eventos RFID são transformados em eventos EPCIS. Seria importante agregar a
informação relevante de diferentes sistemas num só local para ajudar nessa transformação.
Apesar de não se utilizar o Biztalk Server na solução desenvolvida, podemos fazer uma pequena
análise sobre o trabalho que teria de ser desenvolvido caso optássemos por este caminho.
O Biztalk Server poderia desempenhar as funções da camada Capture Application, visto que suporta
o desenvolvimento e deployment de serviços EPCIS em vários aspectos [20]. A construção de even-
tos EPCIS envolve as observações de EPCs dos dispositivos de leitura e também a adição de con-
texto de negócio. A plataforma Biztalk Server contém implementações para trabalhar com um conjun-
to variado de dispositivos. Todos os dispositivos podem comunicar com as camadas superiores à
plataforma Biztalk RFID, utilizando as interfaces disponibilizadas (DSPI). Permite a adição de contex-
to de negócio de sistemas da linha de negócio (LOB), e permite também a implementação das inter-
faces EPCIS Capture e EPCIS Query. O Biztalk Server providencia ligações com vários sistemas,
usando adaptadores para cada um dos sistemas, facilitando assim a recolha de informação de negó-
cio.
A arquitectura de uma solução EPCIS com o BizTalk Server, deve ter um desenho semelhante ao
ilustrado na figura seguinte.
21
Fig. 2.9 – Desenho de um sistema EPCIS utilizando o Biztalk Server.
Esta solução iria implicar uma orquestração de forma a receber mensagens do message bus e asso-
ciar contexto de negócio para gerar os eventos EPCIS. Por exemplo, quando uma transportadora
envia um ASN com os identificadores dos artigos vendidos, o workflow pode associar o ASN com os
eventos EPCIS. A principal vantagem em utilizar o Biztalk Server é que este possui adaptadores que
facilitam a comunicação com os sistemas LOB. Os processos de negócio podem gerar um elevado
volume de eventos EPCIS e estes podem beneficiar das capacidades de escalabilidade presentes no
BizTalk. Para soluções que não utilizem message bus, entre a camada Edge e a camada Data Cen-
ter, o Biztalk Server disponibiliza um adaptador SQL para capturar os eventos.
2.5. rfrbNet
Aquando da realização deste trabalho, a Link Consulting encontrava-se no processo de desenvolvi-
mento de uma plataforma distribuída, cujo objectivo é o rastreio de bens equipados com etiquetas
RFID em cadeias abertas, permitindo uma fácil adesão e interligação entre os agentes da cadeia de
valor.
22
Este projecto denominado rfrbNet12
(Rede Integrada de Rastreio de Bens) respeita os seguintes
desafios:
Federação de Entidades - As entidades envolvidas no transporte e controlo dos bens
devem poder registar-se na rede e disponibilizarem os serviços de rastreio que entenderem,
para que outras entidades possam utilizá-los sempre que pretenderem localizar um bem, ou
saber o percurso efectuado por este.
Escalabilidade - O rastreio dos bens ao longo das organizações envolvidas na cadeia de
valor é algo que é comum acontecer ao nível do lote, da palete ou de outra unidade agrega-
dora. A passagem para o nível do item levanta imediatamente um problema de escala e
volume de dados que, naturalmente, sugere soluções distribuídas e descentralizadas como
forma de distribuir a elevada quantidade de informação gerada.
Privacidade – Importa considerar mecanismos que assegurem os requisitos mínimos de pri-
vacidade e segurança na informação que circula nas etiquetas, garantindo ainda que a
informação fornecida como resposta às diversas pesquisas por parte dos utilizadores ao lon-
go do percurso das etiquetas tem em conta as permissões de cada um.
Segurança – Ao longo da cadeia de valor, as etiquetas têm de atravessar vários domínios de
segurança, tanto ao a nível físico como lógico, pelo que a correcta adequação às várias polí-
ticas é crucial.
A ideia desta plataforma é permitir com que os agentes da cadeia de valor tenham um servidor
EPCIS hospedado na mesma. Para os agentes que possuem um servidor EPCIS próprio, esta plata-
forma apenas disponibiliza interfaces para que seja possível a partilha de informação com os restan-
tes participantes.
Os objectivos que esta solução pretende atingir são os seguintes:
Menores custos de implementação pelos efeitos de escala e reaproveitamento de estrutura;
Maior flexibilidade na federação à rede aumenta a capacidade de escolha, aumentando a
competitividade e baixando os preços dos serviços e produtos;
Capacidade de integrar players mais pequenos, que actualmente não têm capacidade de
entrar nos circuitos de rastreio por RFID;
Rapidez na montagem de processos de rastreio.
A relevância da rfrbNet para este trabalho é a possibilidade de fazer alguns testes de integração da
nossa solução e garantir que existe comunicação com outros sistemas, que respeitam as recomen-
dações EPCglobal.
12
rfrbNet - http://www.rfrb.net/site/
23
3. Arquitectura da Solução
A construção da solução proposta tem em conta toda a análise e estudo do trabalho relacionado
anteriormente descrito. As normas recomendadas pela EPCglobal e o middleware BizTalk RFID,
fornecido pela Link Consulting, foram considerados para que a solução se tornasse válida, reconhe-
cida e adequada a um contexto real de utilização.
Neste capítulo é descrita a solução de um ponto de vista arquitectural, dando-se particular importân-
cia às principais componentes, à forma como estas interagem e aos papéis que cada uma desempe-
nha na solução. Para tal, são descritas sucintamente cada uma das componentes, sendo de seguida
apresentado o diagrama arquitectural que ilustra a forma como a solução está organizada.
3.1. Recomendações EPCglobal
As recomendações EPCglobal devem ser tomadas em consideração ao longo do desenvolvimento
de uma solução EPCIS. Assim, são consideradas as seguintes:
Estrutura por camadas
A estrutura de dados, num sentido abstracto, deve ser especificada separadamente de detalhes con-
cretos dos serviços de acesso à informação e dos vínculos a protocolos de interface. Esta aborda-
gem permite a existência de standards e interfaces que são independentes da implementação.
Extensível
As especificações principais fornecem um conjunto de tipos de dados e operações, mas também
fornecem possibilidades para que esse mesmo conjunto possa ser estendido para uma indústria
específica ou área de aplicação. As extensões permitem que os requisitos sejam atendidos de modo
a aproveitar o máximo de vantagens da framework original, mas também possibilitam a integração de
novas normas que possam surgir ou evolução das actuais.
Modular
A estrutura em camadas e a extensibilidade permite que as diferentes partes de toda a framework
EPCIS possam ser especificadas separadamente, mantendo no entanto a coerência de toda a fra-
mework. Assim, permite-se que os processos de normalização e implementação possam evoluir.
3.2. Arquitectura
Começou-se por estruturar a arquitectura da solução o mais simples possível, constituída por hard-
ware RFID, middleware RFID e EPCIS. A camada Hardware RFID representa as etiquetas e os leito-
res RFID, a camada Middleware RFID representa o software que faz a captura e tratamento da
informação das etiquetas e a camada EPCIS, de um modo simplificado, representa o software que
permite a partilha dessa informação.
24
Fig. 3.1 – Desenho simplificado da arquitectura da solução.
Como o objectivo deste trabalho era desenvolver a camada EPCIS, surgiu a necessidade de utilizar
soluções já existentes que desempenhassem o papel das camadas inferiores, middleware e hardwa-
re RFID.
A seguinte figura ilustra a arquitectura proposta para a nossa solução, em que a zona assinalada
com “EPCIS” representa a componente desenvolvida.
Fig. 3.2 – Diagrama da arquitectura da solução.
25
Conforme referido anteriormente, o objectivo é estender o BizTalk RFID com as camadas EPCIS. As
funcionalidades desta framework foram explicadas no capítulo do trabalho relacionado, e as respon-
sabilidades de cada uma das restantes camadas da arquitectura da solução são descritas em segui-
da:
Capture Application
Tem em consideração a informação de negócio proveniente de outros sistemas e, seguindo um con-
junto de regras estabelecidas, é responsável por transformar os eventos RFID, recebidos das cama-
das inferiores, em eventos EPCIS [7]. Existem cinco tipos de eventos EPCIS, um genérico e quatro
subclasses que podem representar os diferentes tipos de eventos numa cadeia de valor [24][7].
EPCISEvent - Este é o evento genérico e base para todos os outros tipos de eventos. Este
possui apenas três parâmetros, a data em que o evento é criado pela Capture Application, a
data em que o evento é armazenado no repositório e o fuso horário (time zone offset).
ObjectEvent - Contém informação de um ou mais objectos físicos identificados por EPCs.
AggregationEvent - Contém informação de objectos que estão agregados entre si.
QuantityEvent - Contém informação relativa à quantidade de objectos de uma determinada
classe.
TransactionEvent - Contém informação de objectos que se tornam associados, ou deixaram
de o ser, a uma ou mais transacções de negócio.
A relação entre estes diferentes tipos de eventos pode ser observada na figura seguinte.
26
Fig. 3.3 – Diagrama UML dos diferentes tipos de eventos EPCIS [7].
Após a conversão, os eventos EPCIS são enviados para o repositório e para a camada Query Call-
back. Todos os eventos são enviados para a camada Query Callback para permitir que os parceiros
de negócio possam ter informação sobre eventos EPCIS antes de estes serem armazenados na
base de dados. Queremos com isto que a informação dos eventos chegue mais depressa ao utiliza-
dor, evitando o tempo de escrita e de leitura da base de dados.
Capture Interface
Na nossa solução, que poderá ser observada na figura 3.2, a camada Capture Interface recebe even-
tos da camada Capture Application, e é responsável por enviá-los para o repositório EPCIS, onde
estes são armazenados, e para a camada Event Callback, onde são tratados em tempo real.
Base de dados
A base de dados deverá armazenar eventos EPCIS e subscrições de pesquisas. Os eventos EPCIS
armazenados serão enviados pela Capture Application após a sua transformação, enquanto que as
subscrições armazenadas serão registadas pelos utilizadores.
EPCIS Query Control
A camada Query Control aceita pedidos de pesquisas de informação (poll) e subscrição de pesquisas
(subscribe). A camada aceita os pedidos de pesquisa vindos do utilizador, executa a pesquisa na
27
base de dados e devolve o resultado ao mesmo. Um utilizador poderá também subscrever pesquisas
que podem ser executadas num determinado período ou assim que é detectado um novo evento.
Estas subscrições também serão registadas no repositório.
Os serviços da camada EPCIS Query Control, recomendados pela EPCglobal [7], estão apresenta-
dos na tabela seguinte.
subscribe Regista a subscrição de uma pesquisa para uma notificação assíncrona. O
resultado dessa pesquisa é enviado através da Query Callback Interface para
o URI especificado pelo utilizador.
unsubscribe Remove o registo de uma subscrição efectuada anteriormente.
poll Efectua uma pesquisa com os parâmetros definidos pelo utilizador e devolve
o resultado dessa pesquisa.
getQueryNames Retorna a lista das queries pré-definidas que poderão ser utilizadas nos
métodos subscribe e poll.
getSubscriptionIDs Devolve a lista com os identificadores das subscrições activas.
getStandardVersion Devolve a versão da especificação EPCIS na qual corresponde a implemen-
tação.
getVendorVersion Devolve a versão da extensão desenvolvida pelo fornecedor. Este identifica-
dor deverá ser definido pelo fornecedor.
Tabela 3.1 - Serviços da camada EPCIS Query Control.
EPCIS Query Callback
A camada Query Callback tem duas funções. A primeira consiste em enviar eventos EPCIS para o
utilizador assim que estes são registados, sem que o utilizador tenha que fazer uma nova pesquisa.
Esta função só é válida quando o utilizador efectua uma subscrição do tipo trigger.
As subscrições do tipo trigger são subscrições de pesquisas que só são executadas quando um
evento é capturado pela Capture Application. Sempre que é detectado um novo evento é efectuada
uma pesquisa à base de dados para verificar se existe alguma subscrição para este. Se existir uma
subscrição para o evento, este é enviado para endereço de destino configurado na subscrição, caso
contrário o evento é apenas armazenado na base de dados a aguardar uma nova pesquisa.
28
A segunda função consiste em executar pesquisas periódicas que foram subscritas pelo utilizador.
Os utilizadores quando efectuam a subscrição de uma pesquisa deverão especificar o período de
execução das mesmas, e sempre que pesquisa for executada e forem encontrados novos resultados,
os resultados são enviados para o endereço especificado pelo utilizador.
EPCIS Query Interface
A camada EPCIS Query Interface tem a responsabilidade de fazer a interacção da aplicação cliente
com as restantes camadas do sistema, a Query Callback e a Query Control.
Client Application
A aplicação cliente interage com o sistema e efectua subscrições e pesquisas de informação. Para
além desta aplicação poderão existir outras aplicações de outros sistemas que, estando de acordo
com as normas EPCgobal, conseguem interagir com o sistema. Um exemplo dessas aplicações é a
aplicação cliente do Fosstrak que vai ser utilizada para validar a interoperabilidade do nosso sistema
com um sistema diferente.
3.3. Segurança
Um aspecto que também deverá ser considerado é o modelo de segurança[25], que tradicionalmente
é representada por três conceitos abstractos, o agente, a acção e o recurso. O agente representa a
entidade que consome a informação e pode ser uma pessoa, organização ou programa informático.
A acção é a funcionalidade que o agente tenta aceder. Por fim, o recurso representa os dados e
outros recursos necessários para a acção.
Os mecanismos primitivos de segurança, representados na figura seguinte, pretendem garantir a
autenticação dos agentes, a autorização e não-repúdio das acções e a disponibilidade, integridade e
confidencialidade dos recursos.
Fig. 3.4 - Protecção de agente, acção e recurso de uma aplicação informática
29
Sem este modelo de segurança qualquer utilizador poderia fazer pesquisas e subscrições a qualquer
repositório EPCIS e todos os utilizadores teriam acesso a toda a informação do repositório, não exis-
tindo qualquer restrição de dados.
3.4. Comparação com a arquitectura EPCglobal
Ao longo do desenvolvimento da solução, foi efectuado um esforço para que as recomendações
EPCglobal fossem integradas e para que o trabalho desenvolvido possa ser integrado com outras
soluções que utilizem as mesmas normas. A figura seguinte ilustra a relação que existente entre a
arquitectura da solução desenvolvida e a arquitectura recomendada pela EPCglobal.
Fig. 3.5 – Comparação da arquitectura EPCglobal com a arquitectura proposta.
Verifica-se que o middleware BizTalk RFID em conjunto com o hardware correspondem às camadas
inferiores da arquitectura EPCglobal, ficando a faltar as camadas superiores, identificadas como tra-
balho desenvolvido.
30
4. Descrição da Solução
Neste capítulo são apresentadas as tecnologias utilizadas e as diferentes componentes da solução
implementada. É ainda descrito o papel que cada componente tem na solução assim como o seu
modo de funcionamento.
Para o desenvolvimento da solução proposta foram utilizadas as seguintes tecnologias:
C# Linguagem de programação orientada a objectos, desenvolvida pela Microsoft como parte da plataforma .NET.
Microsoft .NET Framework13 A framework .NET é uma plataforma da Microsoft que ajuda na criação de aplicações, pro-
porcionando um modelo de programação abrangente e consistente, suportado por APIs.
WCF (Windows Communication Foundation)14
Esta tecnologia Microsoft melhora a forma como as aplicações comunicam entre si, criando
uma camada de abstracção entre os serviços criados e a forma como os mesmos são dispo-
nibilizados e consumidos pelos clientes. Esta tecnologia implementa normas para a interope-
rabilidade de web services, permite a existência de múltiplos padrões de mensagens (o
padrão mais comum é o pedido/resposta), suporta a publicação de metadados dos serviços
utilizando formatos normalizados (WSDL, XML Schema e WS-Policy), as mensagens podem
ser cifradas, podem ser enviadas utilizando diferentes protocolos de transporte (o mais
comum é enviar mensagens SOAP utilizando HTTP) e também garante uma troca de men-
sagens confiável utilizando sessões criadas sobre WS-Reliable Messaging e utilizando tam-
bém MSMQ [26].
Microsoft SQL Server15
Sistema de gestão de bases de dados relacionais.
LINQ (Language-Integrated Query)16
Componente do Microsoft .NET que contém uma sintaxe unificada que facilita a criação e
manutenção de consultas a bases de dados.
SvcUtil17
Aplicação que permite a geração do código dos contratos de serviços, clientes e tipos de
dados através de documentos de metadados.
13
Microsoft .NET Framework - http://www.microsoft.com/net/overview.aspx 14
WCF - http://msdn.microsoft.com/en-us/netframework/aa663324 15
Microsoft SQL Server - http://www.microsoft.com/sqlserver/ 16
LINQ - http://msdn.microsoft.com/en-us/netframework/aa904594 17
SvcUtil - http://msdn.microsoft.com/en-us/library/aa347733.aspx
31
WSCF.Blue18
Esta ferramenta é um add-in do Visual Studio que facilita o desenvolvimento de web services
utilizando a abordagem “contract-first”. Esta ferramenta fornece os seguintes recursos:
- Ajuda na criação de um WSDL a partir de um ou mais XSD’s
- Gerador de data contract
- Gerador de stubs Service/Endpoint
- Gerador de client proxy
- Gerador do código data contract que suporta a selecção de múltiplas fontes
XSD/WSDL
- Suporte para geração de código C# e VB .NET
- Detector de erros encontrados no WSDL
A solução desenvolvida tem em conta a arquitectura apresentada no capítulo anterior. O seguinte
diagrama ilustra o trabalho desenvolvido assim como as decisões tomadas para cada uma das com-
ponentes da arquitectura, as quais serão explicadas e justificadas ao longo deste capítulo.
Fig. 4.1 – Diagrama da arquitectura da solução
18
WSCF.Blue - http://wscfblue.codeplex.com/
32
4.1. Soluções e Trabalho Utilizado
O BizTalk RFID foi o middleware RFID utilizado nesta solução, não havendo qualquer desenvolvi-
mento nesta camada. Para desempenhar o papel da camada Capture Application utilizámos a com-
ponente do BizTalk RFID e a aplicação Fosstrak Capture Client. Esta última aplicação respeita a
normas EPCglobal, permite que o utilizador submeta eventos EPCIS num repositório EPCIS e permi-
te-nos testar a integração da nossa solução com outra Capture Application.
Apesar de não fazer parte dos objectivos do trabalho a existência da camada Capture Application é
indispensável para existir a transformação dos eventos RFID em eventos EPCIS. Era importante ter
um fluxo completo de informação desde a leitura da etiqueta RFID até a chegada dessa informação a
um cliente.
Como não existia informação de negócio que pudéssemos utilizar, foram criadas regras simples para
garantir que todos os eventos RFID seriam convertidos em object events (evento EPCIS). Assim,
todos os eventos presentes capturados são convertidos em object events e enviados para as cama-
das superiores da arquitectura. Na fase inicial deste trabalho desenvolvemos uma Capture Applica-
tion que efectua uma conversão simples dos eventos capturados em eventos EPCIS, a mesma con-
versão efectuada pela Capture Application do BizTalk RFID. Como a nova versão do BizTalk RFID
passou a incorporar um event handler que efectua a mesma conversão, optámos por passar a usar a
solução Microsoft em vez da nossa implementação que não acrescentava valor.
4.2. Repositório
Esta camada contém o repositório de eventos EPCIS e de subscrições. Na criação desta base de
dados houve o cuidado de fazer com que a mesma apresente uma estrutura em que o carregamento
dos dados de exemplo da solução Fosstrak fosse o mais simples possível.
Uma vez que a base de dados da solução Fosstrak está em mySQL19
, enquanto a nossa solução
está em SQL Server, para o carregamento dos dados exemplo foi necessária efectuar uma conver-
são do script SQL disponibilizado pelo Fosstrak. Para fazer essa conversão utilizámos a ferramenta
“Microsoft SQL Server Migration Assistant 2005 for MySQL” e a conversão foi directa. Este passo foi
bastante importante visto que uma das componentes da avaliação do trabalho ser a comparação dos
resultados da nossa solução com os resultados da solução Fosstrak.
A base de dados foi criada usando a ferramenta SQL Server e para todos os acessos à informação
foi utilizada a tecnologia LINQ (Language-Integrated Query) para fazer as pesquisas.
A relação entre as tabelas descritas e o modelo de domínio poderá ser observados no anexo A deste
documento. O detalhe e significado de cada campo da tabela da base de dados pode ser consultado
na especificação EPCIS [7].
19
mySQL - http://www.mysql.com/
33
Para garantir o bom funcionamento da base de dados foi necessário seguir algumas boas práticas
[27], nomeadamente foi necessário garantir a integridade de domínio, a integridade de entidade e
integridade referencial.
As subscrições são armazenadas no repositório utilizando apenas uma tabela chamada subscrip-
tions. Esta tabela contém a seguinte informação:
subscriptionid Campo com o identificador da subscrição.
parameters Campo com os parâmetros de pesquisa de eventos. Os parâmetros são por
exemplo Action = “add” ou recordTime >= 2010/12/1.
dest Campo com o endereço de destino para onde deve ser enviado o resultado
da pesquisa.
sched Campo com o agendamento especificado pelo utilizador e que contémo
período com que a pesquisa deverá ser executada.
trigg Campo que identifica se a subscrição é do tipo trigger ou não. Os valores
permitidos neste campo são True ou False. Se este campo for True, o cam-
po sched é ignorado.
initialrecordingtime Campo com a data a partir do qual a pesquisa associada à subscrição deve
começar a ser executada.
exportifempty Campo que identifica se o utilizador deve ser notificado quando não existem
eventos resultantes da pesquisa efectuada. Os valores permitidos neste
campo são True ou False
queryname Campo com o nome da query.
lastexecuted Sempre que a pesquisa associada à subscrição é executada, a data da sua
execução é armazenada neste campo.
Tabela 4.1 – Descrição da tabela subscriptions do repositório EPCIS
Os eventos EPCIS podem-se dividir em 4 grupos, Object Events, Aggregation Events, Transaction
Events e Quantity Events. De seguida será descrita estrutura de cada um destes grupos, que se
representada na figura seguinte.
34
Fig. 4.2 – Tabelas do repositório onde são armazenados os eventos EPCIS
Object Events
Um Object Event contém informação sobre um evento que está associado a um ou mais objectos
físicos, e que estão identificados com EPCs.
De seguida é feita uma pequena descrição da tabela event_ObjectEvent e dos seus campos:
id Identificador do evento
eventTime A data e hora em que a Capture Application registou o evento.
recordTime A data e hora em que o evento foi armazenado no repositório EPCIS.
eventTimeZoneOffset O fuso horário em vigor no local de ocorrência do evento, expresso como
um deslocamento do UTC20
. Por exemplo +01:00.
action O modo como o evento se relaciona com ciclo de vida do EPC. Poderá
ter três valores, ADD, OBSERVE ou DELETE
bizStep O passo do processo negócio a que o evento pertence.
Disposition O estado no processo de negócio dos objectos associados aos EPCs.
readPoint O ponto de leitura onde o evento ocorreu.
bizLocation A localização de negócio onde os objectos associados ao EPC deverão
ser encontrados.
Tabela 4.2 – Descrição da tabela event_objectEvent do repositório EPCIS
20
UTC - Coordinated Universal Time
35
A tabela Object Events está associada a outras tabelas da base de dados, tal como é ilustrado na
figura seguinte.
Fig. 4.3 – Relações entre a tabela event_ObjectEvent e as restantes tabelas do repositório
Aggregation Events
Um evento do tipo Aggregation representa uma agregação de objectos físicos.
Muitos dos campos da tabela Aggregation Events são semelhantes à tabela dos Object Events. A
diferença notável é a adição de um novo campo chamado parentID. O campo parentID identifica o
elemento “pai” da agregação efectuada.
Transaction Events
Um evento do tipo Transaction representa a associação e desassociação de um ou mais objectos a
uma ou mais transacções de negócio.
A tabela Transaction Events tem os mesmos campos que a tabela Aggregation Events….
Quantity Events
Os Quantity Events representam uma classe de objectos físicos e à qual está associada uma quanti-
dade de objectos.
As diferenças notáveis são a dois novos campos chamados Quantity e epcClass. O campo Quantity
indica o número de eventos capturados, enquanto que o campo epcClass identifica a classe do
objectos associado a um determinado evento.
36
4.3. Capture Interface
Para esta camada desenvolvemos um serviço com o WCF que foi criado de acordo com as normas
EPCglobal. Esta camada recebe um evento EPCIS, envia-o para a camada Query Callback e arma-
zena-o no repositório, utilizando a tecnologia LINQ. A tabela da base de dados onde os eventos são
armazenados depende do tipo do evento, por exemplo, se for recebido um evento do tipo object, o
evento será registado na tabela event_objectEvents.
Conseguimos com isto evitar o vínculo à Capture Application, com esta interface é possível substituir
a Capture Application sem fazer qualquer alteração, desde que esta cumpra os standards.
4.4. Query Control
Esta camada é constituída por um serviço criado com o auxílio da tecnologia WCF e este serviço tem
principalmente o objectivo de permitir pesquisas de eventos (Poll) e permitir subscrições de pesqui-
sas (Subscribe) para serem executadas posteriormente.
Quando se faz uma pesquisa de eventos, este serviço faz a pesquisa no repositório de eventos
assumindo os parâmetros introduzidos pelo utilizador e, caso encontre resultados, utiliza a Query
Interface para os entregar ao utilizador.
As pesquisas que se podem fazer na base de dados não são livres, foi definido um conjunto de
parâmetros com os quais se podem fazer pesquisas. Os resultados da pesquisa são enviados ao
utilizador através de uma mensagem que terá sempre a mesma estrutura, variando apensas a quan-
tidade de eventos devolvidos.
Segue-se alguns exemplos de parâmetros disponíveis:
eventType Especificação do tipo de eventos EPCIS de que se quer obter resultados. As
opções de escolha são ObjectEvent, AggregationEvent, QuantityEvent, ou Tran-
sactionEvent.
eventTime Especificação da data e hora da conversão de evento EPC para evento EPCIS,
efectuada pela Capture Application.
bizStep Especificação do step do processo de negócio.
Um exemplo urn:epcglobal:cbv:bizstep:accepting
readPoint Especificação do ponto de leitura.
Um exemplo urn:epc:id:sgln:0614141.00729.shipping-door1
Tabela 4.3 – Exemplos de parâmetros para a pesquisa de eventos
37
A descrição dos restantes pode ser consultada na especificação EPCIS [7].
Esta restrição tem como objectivo a normalização das pesquisas efectuadas ao repositório e também
a protecção do sistema. Assim, não é possível que o utilizador faça pesquisas para as quais não
tenha permissão ou que possam afectar a performance do sistema.
Quando é feita uma subscrição, esta é armazenada numa tabela específica para tal, assim como os
parâmetros introduzidos pelo utilizador. Nesta situação não existe mais nenhuma actividade e esta
subscrição passará a ser tratada posteriormente pela camada Query Callback.
O utilizador pode fazer uma subscrição e receber os resultados de uma pesquisa de acordo com um
agendamento determinado por si ou após a chegada de um novo evento. A pesquisa que se vai rea-
lizar é configurada exactamente como numa situação de pesquisa de eventos normal, com o acres-
cento dos seguintes parâmetros:
Data e hora de quando a pesquisa deve ser efectuada;
Endereço para onde devem ser enviar os resultados;
Identificador que será atribuído à subscrição que se está a criar;
trigger que permite fazer uma subscrição sem agendamento, ou seja, em vez de se criar um
agendamento que verifica a existência de novos eventos numa determinada data, o sistema
faz a verificação após a detecção de novos eventos. Permitimos com isto que os utilizadores
tenham acesso aos eventos assim que eles ocorrem.
Para além dos dois métodos principais, o poll e o subscribe, esta camada também contém os seguin-
tes métodos:
getQueryNames
Este método devolve o nome de todas as queries disponíveis.
getSubscriptionIDs
Este método faz uma verificação de todas as subscrições existentes na base de dados e
devolve uma lista com os identificadores dessas mesmas subscrições
unsubscribe
Com este método é possível que um utilizador cancele uma subscrição que tenha feito, é fei-
ta uma pesquisa na base de dados pelo identificador da subscrição e esta é eliminada da
base de dados
getStandardVersion
Este método devolve a versão da norma EPCIS que estamos a utilizar. Na nossa solução uti-
lizámos a versão mais recente da norma e por isso o valor retornado é "StandardVersion -
EPCIS 1.0.1".
getVendorVersion
Este método devolve a versão da extensão feita pelo fornecedor.
38
4.5. Query Callback
Esta camada, tal como a anterior, é constituída por um serviço criado com o auxílio da tecnologia
WCF e este serviço tem o objectivo de fazer uma verificação de existência de subscrições periódicas
e entregar os resultados ao respectivo destinatário.
Para que este mecanismo funcione foi criada uma thread que a todos os minutos (um minuto é o
intervalo configurado por omissão) verifica se existem subscrições. Sempre que é detectada uma
subscrição é criada uma nova thread (uma thread para cada subscrição encontrada) para executar a
pesquisa subscrita e enviar os resultados para o endereço especificado na subscrição. Assim, várias
pesquisas podem ser processadas em paralelo, o que optimiza os tempos de espera dos vários util i-
zadores. Doutro modo, as pesquisas seriam processadas uma a uma, sequencialmente.
A figura seguinte ilustra o funcionamento da camada Query Callback.
Fig. 4.4 – Ilustração do funcionamento da camada Query Callback
Sempre que uma pesquisa subscrita é executada, os resultados enviados para o utilizador são ape-
nas os eventos que ocorreram desde a última execução. O sistema sabe quais os eventos que não
foram recebidos pelo utilizador através do registo da última execução da pesquisa e assim, só são
enviados os eventos que ocorreram após essa data.
Como já foi referido pode-se utilizar uma subscrição através de um trigger em vez de um agenda-
mento. Quando é recebido um evento, é verificado se existe uma subscrição com o parâmetro trigger
a que o evento recebido pertença. Se existir, o evento é enviado para o endereço especificado na
subscrição. Com esta alternativa permitimos que o utilizador do sistema receba eventos quase em
tempo real, estes eventos são enviados directamente da camada Capture Application e paralelamen-
te são armazenados na base de dados.
39
4.6. Query Interface
Uma vez que se pretendia que interface a partir da qual as aplicações comunicam com os serviços
EPCIS seguisse as normas recomendadas pela EPCglobal e, visto que o Fosstrak apresenta uma
solução que cumpre estas normas, optou-se por uma aproximação “contract-first” na integração de
serviços via SOAP, utilizando a descrição do serviço EPCIS que é disponibilizada pelo Fosstrak.
Para a geração do esqueleto da interface a partir do WSDL do Fosstrak foi utilizada a ferramenta
WSCF.blue que, com algumas configurações, consegue fazer esta geração automaticamente.
Foram encontrados alguns problemas nesta fase do desenvolvimento.
1. O WSDL utilizado era complexo, continha imports de ficheiros XSD e a ferramenta não con-
seguia identificar a localização dos mesmos. Para a ferramenta interpretar os ficheiros XSD é
preciso que estes também sejam adicionados ao projecto, para além do WSDL.
2. O WSCF.blue utiliza a ferramenta “xsd”, que faz parte da framework .NET. Foi verificado
durante o desenvolvimento deste trabalho que esta apresenta um erro ao interpretar tipos de
dados complexos, mais concretamente arrays multidimensionais. O erro foi reportado à
Microsoft que confirmou a sua existência e a sua resolução ainda não fazia parte dos seus
planos. Para a resolução do problema foi sugerido um workaround que resolveu o problema,
descrito na figura seguinte. O workaround consistia na introdução de um atributo que apesar
de não ser utilizado na solução possibilita a utilização do tipo ArrayOfString.
<xsd:complexType name="ArrayOfString">
<xsd:sequence>
<xsd:element name="string" type="xsd:string" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<!-- workaround -->
<xsd:attribute name=" OptionalAttribute " type="xsd:string" />
</xsd:complexType>
Fig. 4.5 – Workaround para resolver o problema de importação do ficheiro XSD.
3. Enfrentámos outro problema nos pedidos efectuados pela aplicação cliente do Fosstrak, em
que estas continham mensagens SOAP sem qualquer valor no campo “soap:action”. Devido
ao nosso desenvolvimento com WCF, o dispatcher do serviço determina a operação a ser
executada através do campo action, não podendo existir diferentes métodos com a mesma
action. Os dispatchers são responsáveis por traduzir as mensagens recebidas em chamadas
ao método da aplicação, e enviar os resultados de volta para o invocador do serviço. Para
contornar este problema, o dispatcher do serviço teve que ser alterado, criando-se um cus-
tom dispatcher. Com esta alteração o dispatch passou a ser feito através do nome do método
em vez do nome da action.
40
4.7. Client Application
Neste desenvolvimento foram utilizadas três aplicações que consomem eventos EPCIS.
1. Foi desenvolvida uma consola onde é possível fazer pedidos de pesquisa síncronos e onde
se obtém a resposta a esses mesmos pedidos. Esta aplicação faz pesquisas no repositório
utilizando pedidos SOAP. Para a criação desta aplicação foi utilizada a ferramenta SvcUtil,
que pertence ao Windows SDK e que permite gerar o código da aplicação a partir de um ser-
viço.
2. Foi utilizada outra aplicação, a aplicação cliente do Fosstrak, que apesar de estar desenvol-
vida numa outra linguagem de programação (Java), mostrou-se com capacidade de comuni-
cação com o sistema desenvolvido, graças à utilização das normas de web services SOAP.
3. Foi criada uma aplicação que contém um serviço que aguarda os resultados das subscri-
ções. Quando é feita uma subscrição, é definido o endereço para onde devem ser enviados
os resultados. As mensagens enviadas com os resultados da pesquisa estão no formato
SOAP e, a estrutura da mensagem enviada para esta aplicação é igual à estrutura das men-
sagens enviadas para as aplicações descritas anteriormente. Teve-se de configurar o serviço
para que este interpretasse as mensagens recebidas e apresentasse os resultados ao utili-
zador.
4.8. Segurança
Para podermos considerar um sistema seguro, este deverá incluir as seguintes funcionalidades [28]:
Auditoria – garante que o utilizador que tenha executado uma acção não possa negar fal-
samente que a tenha executado (não-repúdio).
Autenticação – garante uma identificação confiável dos utilizadores que acedem ao sistema.
Autorização – determina quais os recursos e operações do sistema a que o utilizador auten-
ticado tem permissão.
Integridade – garante que os dados estão protegidos contra alguma modificação acidental
ou deliberada.
Os requisitos de segurança descritos anteriormente estão cobertos pelas funcionalidades da tecnolo-
gia WCF [28]. O WCF providencia o acesso a estas funcionalidades através da configuração de bin-
dings e behaviors dos serviços. Os bindings definem o modo de segurança, credenciais e outras
configurações de segurança, enquanto que os behaviors definem o modo de como as credenciais
dos clientes são autenticadas e autorizadas e também as credenciais do serviço.
A seguinte tabela mostra os bindings que são normalmente mais utilizados.
41
Binding Configurações de Segurança Padrão
basicHttpBinding Sem segurança
netTcpBinding Segurança de transporte com autenticação Windows
wsFederationHttpBinding Segurança de mensagem com autenticação issue token
wsHttpBinding Segurança de mensagem com autenticação Windows
Tabela 4.4 – Bindings mais utilizados no serviços WCF [28].
A tecnologia WCF também utiliza um conjunto de standards de web services (WS-*) que garantem a
segurança da comunicação entre o serviço e o cliente [28]. Estes standards incluem:
WS-Policy – permite a definição dos requisitos da política de segurança nos endpoints.
Estes requisitos incluem regras de privacidade, regras de encriptação e tokens de segurança
WS-Security – permite aplicar segurança sobre uma parte da mensagem SOAP ou sobre
mensagens SOAP completas, através de verificações de integridade e encriptação.
WS-Trust – permite a utilização de tokens segurança que estabelecem um ambiente seguro
de comunicação.
WS-SecureConversation – permite a criação de uma sessão de comunicação segura entre
o cliente e o serviço através da reutilização dos tokens usados pelos protocolos anteriores,
WS-Policy, WS-Security e WS-Trust.
Nesta solução não foi configurada nenhuma destas funcionalidades de segurança mas, de qualquer
modo, não queríamos deixar de salientar que com esta solução é possível configurar qualquer
mecanismo de segurança, desde que suportado pelo WCF.
42
5. Avaliação
A avaliação da solução tem como objectivo garantir que esta satisfaz os requisitos definidos. Assim,
foram realizados testes unitários durante todo o desenvolvimento do sistema para garantir que todos
os serviços estão bem construídos (i.e. de acordo com a especificação funcional) e para detectar
eventuais erros que pudessem surgir durante o desenvolvimento da solução e em alterações futuras
que venham a ser necessárias. Após a execução dos testes unitários, foram ainda criados vários
testes de integração para garantir que as várias componentes da solução funcionam correctamente
como um todo. Por fim foram realizados testes de desempenho à nossa solução e ao Fosstrak, para
avaliar a capacidade de resposta e poder compará-la com outra solução.
Para a realização dos testes foram instalados dois repositórios EPCIS, o repositório Fosstrak e o
repositório da nossa solução. A base de dados do Fosstrak utiliza a tecnologia mySQL enquanto que
a nossa base de dados utiliza a tecnologia SQL Server. Para facilitar o carregamento de informação
nas bases de dados foi criada uma aplicação que coloca um determinado número de eventos no
repositório para serem posteriormente utilizados nos testes.
A máquina de testes utilizada contém um processador Intel Core 2 Duo CPU P8700 @2.53GHz com
2GB de RAM. As características de rede não são relevantes, visto que os repositórios estão instala-
dos na mesma máquina.
5.1. Cenário de Utilização
A seguinte figura ilustra um cenário de utilização de um sistema EPCIS numa cadeia de valor [29].
Estão representadas as fases que um produto percorre desde a sua produção até à sua entrega ao
cliente final. Em cada uma das fases existe leitor RFID que detecta um objecto etiquetado e que gera
um evento EPCIS. Cada entidade possui um servidor EPCIS que regista eventos e recebe pedidos
de informação.
43
Fig. 5.1 – Exemplificação de um cenário de utilização.
De seguida são descritas cada uma destas fases e o conteúdo do evento enviado para a Capture
Interface.
1. Fabrico do produto e colocação da etiqueta RFID
Event Type Object event
Event Time 2011-04-20T06:00:00Z
Time Zone Offset +00:00
EPCs urn:epc:id:sgtin:0057000.123780.7788
Action ADD
Business Step urn:epcglobal:cbv:bizstep:commissioning
Read Point urn:epc:id:sgln:0614141.00729.rp1
Business Location urn:epc:id:sgln:0614141.00729.fabrica
44
2. Paletização dos objectos fabricados
Event Type Aggregation event
Event Time 2011-04-20T09:00:10Z
Time Zone Offset +00:00
Parent Object urn:epc:id:sscc:0614141.1234567890
Child EPCs urn:epc:id:sgtin:0057000.123780.7788
urn:epc:id:sgtin:0057000.123430.2028
urn:epc:id:sgtin:0057000.123430.2029
Action ADD
Business Step urn:epcglobal:cbv:bizstep:packing
Read Point urn:epc:id:sgln:0614141.00729.rp2
Business Location urn:epc:id:sgln:0614141.00729.fabrica
3. Carregamento da palete no veículo de transporte
Event Type Object event
Event Time 2011-04-21T10:05:57Z
Time Zone Offset +00:00
EPCs urn:epc:id:sscc:0614141.1234567890
Action OBSERVE
Business Step urn:epcglobal:cbv:bizstep:loading
Read Point urn:epc:id:sgln:0614141.00729.rp3
Business Location urn:epc:id:sgln:0614141.00729.fabrica
4. Descarregamento da palete do veículo de transporte
Event Type Object event
Event Time 2011-04-23T09:22:43Z
Time Zone Offset +00:00
EPCs urn:epc:id:sscc:0614141.1234567890
Action OBSERVE
Business Step urn:epcglobal:cbv:bizstep:receiving
Read Point urn:epc:id:sgln:0614141.00729.rp1
Business Location urn:epc:id:sgln:0614141.00729.armazem
5. Inventário
Event Type Quantity event
Event Time 2011-04-23T12:36:17Z
Time Zone Offset +00:00
Quantity 5
Business Step urn:epcglobal:cbv:bizstep:storing
Read Point urn:epc:id:sgln:0614141.00729.rp2
45
Business Location urn:epc:id:sgln:0614141.00729.armazem
6. Carregamento da palete no veículo de transporte
Event Type Object event
Event Time 2011-04-24T17:03:23Z
Time Zone Offset +00:00
EPCs urn:epc:id:sscc:0614141.1234567890
Action OBSERVE
Business Step urn:epcglobal:cbv:bizstep:loading
Read Point urn:epc:id:sgln:0614141.00729.rp3
Business Location urn:epc:id:sgln:0614141.00729.armazem
7. Descarregamento da palete no veículo de transporte
Event Type Object event
Event Time 2011-04-27T09:23:17Z
Time Zone Offset +00:00
EPCs urn:epc:id:sscc:0614141.1234567890
Action OBSERVE
Business Step urn:epcglobal:cbv:bizstep:receiving
Read Point urn:epc:id:sgln:0614141.00729.rp1
Business Location urn:epc:id:sgln:0614141.00729.loja
8. Despaletização dos objectos fabricados
Event Type Aggregation event
Event Time 2011-04-27T10:57:47Z
Time Zone Offset +00:00
Parent Object urn:epc:id:sscc:0614141.1234567890
Child EPCs urn:epc:id:sgtin:0057000.123780.7788
urn:epc:id:sgtin:0057000.123430.2028
urn:epc:id:sgtin:0057000.123430.2029
Action DELETE
Business Step -
Read Point urn:epc:id:sgln:0614141.00729.rp2
Business Location urn:epc:id:sgln:0614141.00729.loja
9. Venda do produto
Event Type Object event
Event Time 2011-04-28T13:14:17Z
Time Zone Offset +00:00
EPCs urn:epc:id:sgtin:0057000.123780.7788
46
Action DELETE
Business Step -
Read Point urn:epc:id:sgln:0614141.00729.rp3
Business Location urn:epc:id:sgln:0614141.00729.loja
10. Consulta de informação
Que paletes saíram da fábrica no dia 23/4/2011?
Parâmetros da pesquisa Event type = Object Event
Business Step = urn:epcglobal:cbv:bizstep:loading
Business Location = urn:epc:id:sgln:0614141.00729.fabrica
Event Time >= 2011-04-23T00:00:00Z
Event Time < 2011-04-24T00:00:00Z
Quantas paletes estão no armazém?
Parâmetros da pesquisa Event Type = Quantity event
Business Location = urn:epc:id:sgln:0614141.00729.armazem
Que produtos chegaram à loja no dia 23/4/2011?
Parâmetros da pesquisa Event Type = Object event
Business Step = urn:epcglobal:cbv:bizstep:receiving
Business Location = urn:epc:id:sgln:0614141.00729.loja
Event Time >= 2011-04-23T00:00:00Z
Event Time < 2011-04-24T00:00:00Z
A vantagem da utilização da nossa solução é que, independentemente do middleware que é utilizado
em qualquer uma das entidades responsáveis pelo fabrico e transporte de objectos (Fábrica, Arma-
zém ou Loja), o Centro de Controlo poderá efectuar pesquisas de informação aos sistemas, utilizan-
do apenas uma interface normalizada.
5.1.1. Utilização do Mecanismo Callback
Subscrições com agendamento
O utilizador efectua uma subscrição para receber todos os eventos do tipo Object que ocorrem de 10
em 10 minutos. Periodicamente o sistema verifica se existem subscrições que devam ser executa-
das. Assim que é efectuada a pesquisa, é enviado o resultado para o endereço especificado pelo
utilizador. Este resultado só contém eventos que tenham ocorrido desde a última execução, ou seja,
nos últimos 10 minutos. O seguinte diagrama exemplifica o funcionamento desta situação.
47
Fig. 5.2 – Exemplificação do funcionamento da subscrição com agendamento.
1. O utilizador efectua uma subscrição para receber todos os eventos do tipo Object que ocor-
rem de 10 em 10 minutos.
Parâmetros da pesquisa Event type = Object Event
Parâmetros da subscrição Destination URI = http://localhost:8888
Initial Record Time = 2011-05-09T23:37:34.921+01:00
Subscription ID = 1
Schedule = 10 minutos
2. É efectuada a pesquisa e o resultado é enviado para o endereço especificado no ponto ante-
rior. Como ainda não ocorreram eventos até este momento o resultado da pesquisa será
vazio.
Parâmetros da pesquisa Event type = Object Event
Resultado da pesquisa vazio
3. O sistema EPCIS recebe um evento através da interface Capture.
Event Type Object event
Event Time 2011-04-20T06:36:17Z
Time Zone Offset +00:00
EPCs urn:epc:id:sgtin:0057000.123780.7788
Action ADD
Business Step urn:epcglobal:cbv:bizstep:commissioning
48
Read Point urn:epc:id:sgln:0614141.00729.rp1
Business Location urn:epc:id:sgln:0614141.00729.fabrica
4. Ao fim de 10 minutos é efectuada a mesma pesquisa que envia um resultado.
Parâmetros da pesquisa Event type = Object Event
Resultado da pesquisa Evento com EPC urn:epc:id:sgtin:0057000.123780.7788
5. Ao fim de mais 10 minutos, 20 minutos no total, é efectuada nova pesquisa. Como não ocor-
reram eventos desde a última execução o resultado da pesquisa será vazio.
Parâmetros da pesquisa Event type = Object Event
Resultado da pesquisa vazio
Subscrições do tipo trigger
O utilizador efectua uma subscrição para receber todos os eventos do tipo Object assim que chegam
ao servidor EPCIS. Sempre que é recebido um novo evento, o sistema efectua uma verificação se
este é do tipo Object e se for, envia-o para o endereço definido pelo utilizador. O seguinte diagrama
exemplifica o funcionamento desta situação.
Fig. 5.3 – Exemplificação do funcionamento da subscrição com mecanismo de trigger.
49
1. O utilizador efectua uma subscrição para receber todos os eventos do tipo Object assim que
estes chegam ao sistema EPCIS.
Parâmetros da pesquisa Event type = Object Event
Parâmetros da subscrição Destination URI = http://localhost:8888
Initial Record Time = 2011-05-09T23:37:34.921+01:00
Subscription ID = 2
Trigger = on
2. É efectuada a pesquisa e o resultado é enviado para o endereço especificado no ponto ante-
rior. Como ainda não ocorreram eventos até este momento o resultado da pesquisa será
vazio.
Parâmetros da pesquisa Event type = Object Event
Resultado da pesquisa vazio
3. O sistema EPCIS recebe um evento através da interface Capture.
Event Type Object event
Event Time 2011-04-20T06:36:17Z
Time Zone Offset +00:00
EPCs urn:epc:id:sgtin:0057000.123780.7788
Action ADD
Business Step urn:epcglobal:cbv:bizstep:commissioning
Read Point urn:epc:id:sgln:0614141.00729.rp1
Business Location urn:epc:id:sgln:0614141.00729.fabrica
4. O sistema detecta a chegada do novo evento e envia-o para o endereço especificado na
subscrição.
Parâmetros da pesquisa Event type = Object Event
Resultado da pesquisa Evento com EPC urn:epc:id:sgtin:0057000.123780.7788
5. O sistema EPCIS recebe um evento através da interface Capture.
Event Type Object event
Event Time 2011-04-20T06:36:17Z
Time Zone Offset +00:00
EPCs urn:epc:id:sgtin:0057000.123780.7789
Action ADD
Business Step urn:epcglobal:cbv:bizstep:commissioning
Read Point urn:epc:id:sgln:0614141.00729.rp1
50
Business Location urn:epc:id:sgln:0614141.00729.fabrica
6. O sistema detecta a chegada do novo evento e envia-o para o endereço especificado na
subscrição.
Parâmetros da pesquisa Event type = Object Event
Resultado da pesquisa Evento com EPC urn:epc:id:sgtin:0057000.123780.7789
5.2. Testes Unitários e de Integração
Os testes unitários garantem a correcção das várias unidades de código que compõem a solução
desenvolvida. Estes testes foram criados recorrendo à Framework de testes unitários NUnit21
que
permite a fácil criação de testes unitários para aplicações desenvolvidas em C# e .NET.
Foram criados testes para cada serviço existente na solução e para cada método necessário para o
correcto funcionamento da mesma. A realização dos testes ao longo do desenvolvimento da solução
garantiu que durante a criação de novas funcionalidades o trabalho desenvolvido até ao momento
estava validado e não era danificado.
Foram também criados testes unitários para o sistema Fosstrak, não com o objectivo de verificar
quais as falhas do sistema, mas sim validar se os resultados obtidos na nossa solução coincidiam
com o esperado.
Os testes de integração pretendem verificar que todas as componentes da solução desenvolvida
interagem entre si apresentando um determinado resultado esperado.
Para isso, após o desenvolvimento de uma nova componente da solução, foram efectuados testes
que exigiam a participação simultânea das componentes da solução, verificando-se assim a correcta
integração das mesmas.
5.2.1. Integração com o Fosstrak
Para testar a integração da solução desenvolvida com outras soluções EPCIS que respeitem as
normas estabelecidas pela EPCglobal, simulámos a introdução e pesquisa de informação a dois sis-
temas EPCIS com tecnologias diferentes mas com a mesma informação na base de dados.
Para efectuarmos garantir que os dados são os mesmos nos diferentes sistemas replicámos os
dados existentes na base de dados do sistema Fosstrak para a base de dados do nosso sistema.
Foram efectuados os mesmos testes às duas interfaces, Capture e Query Control, utilizando as apli-
cações cliente do Fosstrak, que possuem alguns exemplos de cenários reais. Queríamos com isto
verificar se o comportamento dos dois sistemas é idêntico.
21
NUnit - http://www.nunit.org/
51
Testes à interface EPCIS Query Control
As pesquisas efectuadas foram as seguintes:
- Procura uma agregação de uma determinada palete
(devolve os eventos da palete com identificador “urn:epc:id:sscc:0614141.1234567890”)
- Procura de todos os eventos de um determinado EPC que ocorreu numa determinada
data
(devolve todos os eventos com o EPC “urn:epc:id:sgtin:0034000.987650.2686” que ocorre-
ram depois da data “2006-01-01T05:20:31+00:00”)
- Procura todos os eventos gerados por um determinado leitor
(devolve todos os eventos que ocorreram no leitor RFID em determinada posição)
- Procura os EPC’s com uma determinada data de envio
(devolve os eventos com o business step “shipping” e com o código EPC
“urn:epc:id:sgtin:0057000.123430.2028”)
- Procura todos os EPCs que ocorreram num determinado ano
(devolve todos os eventos que ocorreram no ano 2006)
O detalhe das pesquisas realizadas, assim como os resultados obtidos, podem ser observados no
anexo B deste documento.
Testes à interface EPCIS Capture
Também foi testada a Capture Interface desenvolvida utilizando os exemplos da Capture Application
do Fosstrak.
Os registos efectuados na Capture Interface foram os seguintes:
- Adição de um objecto com um novo EPC que ainda não existe no repositório
(regista o evento com action “ADD” e EPC “urn:epc:id:sgtin:0057000.123780.7788”)
- Observação de um objecto com um EPC existente no repositório
(regista o evento do tipo “object” com action “OBSERVE” e EPC
“urn:epc:id:sgtin:0057000.123780.7788”)
- Adição de uma agregação com um EPC que identifica a palete e com mais 4 EPCs que
identificam os objectos individuais contidos na palete
(regista o evento do tipo “aggregation” com action “ADD”, com parent object
“urn:epc:id:sscc:0614141.1234567890” e com child EPCs
52
“urn:epc:id:sgtin:0057000.123780.7788 urn:epc:id:sgtin:0057000.123430.2027
urn:epc:id:sgtin:0057000.123430.2028 urn:epc:id:sgtin:0057000.123430.2029”)
- A chegada de uma palete a um determinado local
(regista o evento do tipo “object” com action “OBSERVE” e com business step
“urn:epcglobal:cbv:bizstep:arriving” )
- A partida de uma palete de um determinado local
( regista o evento do tipo “object” com action “OBSERVE” e com business step
“urn:epcglobal:cbv:bizstep:departing” )
- Passagem de um objecto num leitor durante o processo de fabrico
(regista o evento do tipo “object” com action “OBSERVE” e com business step
“http://epcis.fosstrak.org/bizstep/production” )
- Carregamento de 2 paletes num veículo de transporte
(regista o evento do tipo “object” com action “OBSERVE”, com business step
“urn:epcglobal:cbv:bizstep:loading” e com disposition “urn:epcglobal:cbv:disp:in_transit” )
- Objecto recebido para reparação
(regista o evento do tipo “object” com action “OBSERVE”, com business step
“urn:epcglobal:cbv:bizstep:receiving”, com disposition “http://epcis.fosstrak.org/disp/in_repair”
e com business location “urn:epc:id:sgln:0614141.00101.repair-center”)
- Agregação de 3 objectos com EPC numa palete identificada com código de barras
(regista o evento do tipo “aggregation” com action “ADD”, com child EPCs
“urn:epc:id:sgtin:0057000.123430.2025 urn:epc:id:sgtin:0057000.123430.2027
urn:epc:id:sgtin:0057000.123430.2028” )
- Desagregação de uma palete após chegada ao cliente
(regista o evento do tipo “aggregation” com action “DELETE”, com parent object
“urn:epc:id:sscc:0614141.2644895423”)
- Contagem do inventário de 67 objectos
(regista o evento do tipo “quantity” com o campo quantity igual a 67 e com business step
“urn:epcglobal:cbv:bizstep:storing” )
- Adição de dois novos objectos a uma transacção após alteração pedida pelo cliente
(regista o evento do tipo “transaction” com action “ADD” e com EPCs
“urn:epc:id:sgtin:0057000.678930.5003 urn:epc:id:sgtin:0057000.678930.5004” )
53
- Transacção finalizada
(regista o evento do tipo “transaction” com action “DELETE” e com EPCs
“urn:epc:id:sgtin:0057000.678930.5003 urn:epc:id:sgtin:0057000.678930.5004”)
Posteriormente os resultados entre as duas soluções foram comparados utilizando a ferramenta soa-
pUI22
. A ferramenta soapUI é uma ferramenta open source para teste de Web Services que permite
definir a mensagens SOAP que são enviadas para o servidor e recebe as respostas enviadas por
este.
Analisando os resultados obtidos em ambas as soluções, não se verificou nenhuma diferença entre
as respostas das duas soluções.
5.2.2. Integração com rfrbNet
Depois de resolvidas as questões relacionadas com aprovisionamento, descoberta e definição de
políticas dos intervenientes, a rede rfrbNet cumpre as suas primitivas de rastreio graças às interfaces
de Capture e Query normalizadas pela EPCglobal.
Inicialmente, a rede rfrbNet foi construída sobre a plataforma Fosstrak, a qual, conforme já referido, é
uma plataforma de middleware RFID open source cujo repositório foi também certificado pela EPC-
global23
. Por sua vez, visto que a camada de captura da rede rfrbNet assenta no middleware BizTalk
RFID, o nosso trabalho apresentará e permitirá validar uma alternativa aos interfaces EPCIS do
Fosstrak.
Cenário
Na rede rfrbNet, é testado o cenário de construção da Bill-Of-Materials24
, tendo em conta a hierarquia
de componentes que compõe um produto ao longo da sua vida e ao longo dos circuitos logísticos
directos e inversos.
Na figura seguinte, observamos um esquema geral da cadeia de distribuição directa envolvida na
produção de um portátil:
22
soapUI - http://www.soapui.org/ 23
Certificações EPCglobal - http://www.gs1.org/epcglobal/certification/sw_cert 24
Bill-Of-Materials - Lista de matérias-primas, componentes ou peças necessária para o fabrico de um produto.
54
Fig. 5.4 - rfrbNet: Visão geral de cadeia de distribuição
O principal objectivo da construção do Bill-Of-Materials é a identificação das componentes de um
produto. Para isso, a rede tem que interrogar os sistemas EPCIS envolvidos nas operações de agre-
gação e desagregação. A figura seguinte representa os detalhes de agregação na montagem de um
portátil:
55
Fig. 5.5 - rfrbNet: Detalhes de agregação na montagem de um portátil
Por fim, completa-se a actualização do Bill-Of-Materials com o cenário da logística inversa de repara-
ção de equipamento, substituindo uma componente por outra operação que é composta pelas opera-
ções de desagregação do componente avariado e agregação do componente substituído.
Interfaces
Como já foi referido, a rede rfrbNet cumpre as suas primitivas de rastreio invocando os interfaces de
normalizadas pela EPCglobal:
Capture Interface: captura de eventos de negócio;
Query interface: consolidação ao longo da rede dos eventos de agregação e desagregação
de forma a construir a Bill-Of-Materials.
As seguintes aplicações utilizam as interfaces:
Capture Interface:
o Link.rfrbnet.SupplyChainSimulator – simulador da cadeia de abastecimento, capaz
de gerar os eventos de Capture no contexto desta cadeia;
Query Interface:
o Link.rfrbnet.TrackAndTrace – aplicação de consulta de localização e historial;
o Link.rfrbnet.BillOfMaterials – aplicação de consulta de Bill-Of-Materials;
o Link.rfrbnet.Dashboard – Dashboard de monitorização de actividades em tempo real.
56
Descrição dos testes
Com estes testes queríamos validar que a nossa solução não apresenta erros e para isso foi impor-
tante utilizar um sistema empresarial que já possui uma bateria de testes. A ideia era executar a
bateria de testes utilizando os serviços EPCIS do Fosstrak existentes no sistema rfrbNet, e poste-
riormente substituir esses serviços pela nossa solução e verificar se os resultados são idênticos.
Resultados
A substituição da implementação dos interfaces EPCIS do Fosstrak pela nossa solução produziu um
resultado positivo, uma vez que obtivemos os mesmos resultados após a substituição.
5.3. Testes de Desempenho
Para testar o desempenho da nossa solução foi realizado um conjunto de testes a dois sistemas
EPCIS, a nossa solução e o Fosstrak. Estes testes consistiram em popular as bases de dados de
ambos os sistemas com um elevado número de registos (igual para ambos os sistemas) e medir os
tempos de resposta às pesquisas efectuadas.
Fig. 5.6 - Representação gráfica dos resultados dos testes de desempenho
Número de registos na resposta
Tempo médio de resposta (ms)
Fosstrak A nossa Solução
1 60 50
10 108 162
100 276 414
1000 1657 2488
10000 21015 31554
Tabela 5.1 - Resultados dos testes de desempenho
0
5000
10000
15000
20000
25000
30000
35000
0 2000 4000 6000 8000 10000
Tem
po
de
re
spo
sta
(ms)
Número de registos na resposta
Fosstrak
A nossa Solução
57
A nossa solução só apresenta tempo inferior de resposta ao Fosstrak para um único registo na res-
posta. Para mais registos, apresenta uma performance inferior, demora 1.5 vezes o tempo de res-
posta do Fosstrak (em média). Propomos como trabalho futuro a identificação do problema e a opti-
mização da performance do sistema.
58
6. Conclusões e Trabalho Futuro
Neste capítulo, será apresentado um resumo do trabalho que foi desenvolvido ao longo desta disser-
tação, assim como as conclusões obtidas e principais contribuições. Com o objectivo de enriquecer a
solução obtida, é feita uma análise crítica da mesma, onde se identificam alguns pontos que poderão
ser melhorados ou adicionados a esta solução.
6.1. Conclusões Finais e Contribuições
Como objectivo para este trabalho, propusemo-nos a desenvolver uma solução que facilitasse a
adopção das normas EPCglobal para sistemas de informação, nomeadamente a norma EPCIS.
Assim, numa fase inicial, propusemo-nos a desenvolver serviços EPCIS que comunicassem com o
Biztalk RFID, permitindo a este disponibilizar dados EPC para outros sistemas. Apesar dos desen-
volvimentos terem sido feitos para este middleware, esta solução poderá ser utilizada por qualquer
middleware que respeite as normas EPCglobal.
Cumprimos as recomendações da EPCglobal desenvolvendo uma solução estruturada por camadas
que traz a vantagem de ter standards e interfaces independentes da implementação, e extensível
para ser utilizada em qualquer área de negócio. A existência de uma arquitectura por camadas facili-
ta a substituição destas por outras mais evoluídas, que estejam de acordo com as normas EPCglo-
bal, permitindo escalabilidade e uma evolução natural da solução.
Desenvolvemos uma solução “chave na mão” que pode ser instalada sobre qualquer sistema RFID,
apresentando como único requisito que os eventos EPCIS recebidos pela Capture Interface estejam
de acordo com as normas EPCglobal. Esta solução foi valorizada pela empresa Link Consulting visto
que poderá ser utilizada em projectos futuros que tenham a necessidade de implementar os serviços
EPCIS. Ao mesmo tempo, garante-se a possibilidade de uma substituição por implementações mais
robustas no futuro (ex: IBM e Oracle). Esta solução, quando comparada com uma solução desenvol-
vida sobre BizTalk Server, tem a vantagem de não ter obrigatoriedade de licenciamento, permitindo a
implementação de projectos pequenos sem custos demasiado elevados.
Para atingirmos o nosso objectivo principal, foram necessárias várias etapas, nomeadamente o estu-
do das normas internacionais EPCglobal e a análise de middlewares RFID. Foi ainda necessária a
criação de serviços de acordo com as normas e, neste ponto, gostaríamos de destacar a importância
da existência de uma solução académica (Fosstrak), que permitiu a comparação de resultados. O
mecanismo por trás dos serviços não é simples, visto que existem mecanismos publish/subscribe em
que a verificação de subscrições obrigou à criação de um temporizador que efectua verificações
periódicas.
59
O modelo de compatibilidade com os interfaces definidos implicou uma aproximação “contract-first”
na integração de serviços via SOAP. A maior dificuldade encontrada neste trabalho foi o facto dos
contratos especificados pela EPCglobal não definirem o campo action, que é obrigatória em WCF
para a determinação da operação a ser executada pelo serviço. A resolução deste problema não foi
trivial e a sua solução passou pela alteração do dispatcher do serviço, criando um custom dispatcher.
Com esta alteração, o dispatch passou a ser feito através do nome do método em vez do nome da
action.
A avaliação cumpriu as nossas expectativas, com excepção dos testes de desempenho, e os resul-
tados obtidos nos testes efectuados foram sempre os correctos. Acreditamos que os casos de utili-
zação identificados reflectem a realidade empresarial, principalmente os casos de teste no sistema
rfrbNet.
Os resultados dos testes de desempenho deixaram-nos surpreendidos ao apresentarem tempos de
resposta 1,5 vezes superior aos tempos de resposta da solução Fosstrak. Apesar de apresentar uma
performance inferior, consideramos que, o facto de a solução retornar 333 registos por segundo (em
média) são tempos de resposta aceitáveis, se considerarmos que estes registos correspondem aos
momentos mais importantes das movimentações de objectos físicos numa cadeia de valor.
Garantimos que as normas EPCglobal são cumpridas comparando a nossa solução com outra, que
já as cumpre, e comprovamos que a nossa solução consegue comunicar com outros sistemas de
tecnologias diferentes.
Com a solução que foi desenvolvida e com o resultado dos testes efectuados, acreditamos que este
trabalho é um passo importante na construção de uma solução que pode ser aplicada num ambiente
real. Em termos de aplicação e utilização do trabalho desenvolvido, consideramos que o mesmo
pode ser utilizado noutros trabalhos relacionados com este tema, que necessitem de implementar a
camada EPCIS, e também por empresas que queiram disponibilizar informação para os seus parcei-
ros de negócio.
6.2. Trabalho Futuro
Apesar de todos os objectivos a que nos propusemos terem sido cumpridos, ao longo do desenvol-
vimento foram surgindo novas ideias que podem enriquecer o trabalho.
Para garantir que os recursos computacionais do sistema são geridos de uma forma mais eficiente,
sugerimos a utilização de um mecanismo de thread pooling. Resumidamente, o mecanismo de
thread pooling consiste num processo de criação e gestão de threads para que, sempre que exista
uma nova tarefa no sistema, se utilize uma thread já existente em vez de se criar uma nova.
Para simular todo o processo, desde a leitura de uma etiqueta RFID até a partilha de informação com
outros sistemas, foi necessário utilizar uma Capture Application. Esta aplicação é uma das camadas
da arquitectura recomendada pela EPCglobal e tem a responsabilidade de converter um evento RFID
60
num evento EPCIS. Esta conversão é efectuada tendo com base algumas regras de negócio, que
não foram consideradas neste trabalho. Posto isto, utilizámos esta aplicação com uma conversão de
eventos simples, sem adicionar contexto de negócio. Normalmente, estas regras de negócio são
fornecidas por outros sistemas e propomos, como trabalho futuro, a alteração da Capture Application
para que receba informação de outros sistemas da empresa ou de terceiros e, que converta os even-
tos RFID em eventos EPCIS com mais informação útil.
Sugerimos também o desenvolvimento da camada ONS da arquitectura EPCglobal. O ONS é um
serviço da rede que permite a procura dos endereços de repositórios EPC, a partir de um identifica-
dor do gestor de EPC ou de um EPC completo. Especificamente, o ONS disponibiliza um meio para
procurar um endereço de um serviço EPCIS disponibilizado pela organização que ficou encarregue
do EPC do objecto em questão. Sem esta camada não é possível saber o endereço de um repositó-
rio EPCIS para um dado EPC. Na nossa solução, assumimos que todos os endereços dos repositó-
rios são conhecidos por todos os parceiros de negócio.
O mecanismo Discovery Service [6], que localiza todos os repositórios EPCIS que poderão ter infor-
mação sobre um particular EPC, referido nas recomendações da EPCglobal, não foi desenvolvido.
Prevemos que este mecanismo seja uma mais-valia para soluções EPCIS, sendo útil principalmente
quando se deseja fazer uma pesquisa de informação a um serviço EPCIS mas não se sabe o ende-
reço.
61
7. Referências
[1] K. Finkenzeller, “RFID Handbook: Fundamentals and Applications in Contactless Smart Cards and Identification,” John Wiley & Sons, Ltd, 2003, p. 434.
[2] S. Lewis, “A basic introduction to RFID technology and its use in the supply chain,” Laran RF-ID white-paper, 2004.
[3] G. Capone, D. Costlow, W. Grenoble, and R. Novack, “The RFID-Enabled Warehouse,” SAP University Thought Leadership Supply Chain Paper, Penn State, 2004.
[4] C. Floerkemeier, C. Roduner, and M. Lampe, “RFID Application Development With the Accada Middleware Platform,” IEEE Systems Journal, 2007.
[5] K. Leong, M. Ng, and D. Engels, “EPC Network Architecture,” White Paper Series / Edition 1, Auto-ID Labs, 2005.
[6] K. Traub, F. Armenio, H. Barthel, P. Dietrich, J. Duker, C. Floerkemeier, J. Garrett, and M. Harrison, “The EPCglobal Architecture Framework,” GS1 EPCglobal, 2010.
[7] “EPC Information Services ( EPCIS ) Version 1 . 0 . 1 Specification,” GS1 EPCglobal, 2007.
[8] W. Hansen and F. Gillert, “RFID for the Optimization of Business Processes,” John Wiley & Sons, Ltd, 2008.
[9] C. Du and S. Han, “Integrating EPCglobal Network with Web Services,” IEEE Computer Socie-ty, 2009.
[10] “Low Level Reader Protocol ( LLRP ),” GS1 EPCglobal, 2010.
[11] “The Application Level Events ( ALE ) Specification,” GS1 EPCglobal, 2009.
[12] “EPCglobal Object Name Service (ONS) 1.0.1,” GS1 EPCglobal, 2008.
[13] C. Floerkemeier, M. Lampe, and C. Roduner, “Facilitating RFID Development with the Accada Prototyping Platform,” IEEE International Conference on Pervasive Computing and Communi-cations Workshops, 2007.
[14] “Fosstrak EPCIS - Architecture Guide,” [Online]. Available: http://www.fosstrak.org/epcis/docs/architecture-guide.html.
[15] EPCglobal Tag Data Translation (TDT) 1.4 Specification, GS1 EPCglobal, 2009.
[16] G. Pereira, “Dissertação de Mestrado: Assessment of an open-source, standards-based RFID supply chain integration,” DEI, IST, 2009.
[17] W. Yanyan, Z. Xiaofeng, W. Yaohua, and X. Peipei, “The research of RFID middleware’s data management model,” IEEE International Conference on Automation and Logistics, 2008.
[18] T. Nguyen, Y. Lee, R. Huq, B. Jeong, and S. Lee, “A Data Model for EPC Information Servic-es,” Department of Computer Engineering, KyungHee University, Korea, 2007.
[19] M. Beckner, M. Simms, and R. Venkatesh, “Pro RFID in BizTalk Server 2009,” Apress, 2009.
62
[20] “Implementing EPC Information Services with Microsoft BizTalk Server 2006 R2,” [Online]. Available: http://msdn.microsoft.com/en-us/library/cc721650.aspx.
[21] G. Alonso, F. Casati, H. Kuno, and V. Machiraju, “Web Services: Concepts, Architectures and Applications,” Springer Verlag, 2004.
[22] “Introducing BizTalk Server 2010,” [Online]. Available: http://technet.microsoft.com/en-us/library/aa547058%2528BTS.70%2529.aspx.
[23] D. Jefford, K. Smith, and E. Fairweather, “Professional BizTalk Server 2006,” Wiley Publishing, Inc., 2007.
[24] F. Michahelles, C. Floerkemeier, and M. Harrison, “Technology, Standards, and Real-World Deployments of the EPC Network,” IEEE Computer Society, 2003.
[25] M. Pardal, “Dissertação de Mestrado: Tecnologia de segurança para Web Services,” DEI, IST, 2006.
[26] D. Chappell, “Introducing Windows Communication Foundation in .NET Framework 4,” [On-line]. Available: http://msdn.microsoft.com/en-us/library/ee958158.aspx.
[27] A. Silberschatz, H.F. Korth, and S. Sudarshan, “Database System Concepts, 4th Edition,” The McGraw-Hill Companies, 2005.
[28] J.D. Meier, C. Farre, J. Taylor, P. Bansode, S. Gregersen, M. Sundararajan, and R. Boucher, “Improving Web Services Security - Scenarios and Implementation Guidance for WCF,” pat-terns & practices by Microsoft, 2008.
[29] A. Ilic, T. Andersen, and F. Michahelles, “EPCIS-based Supply Chain Visualization Tool,” Au-to-ID Labs White Paper, 2009.
63
ANEXO A – Modelo de Domínio
64
ANEXO B – Detalhe das pesquisas efectuadas à solução
Título
Search for an aggregation onto a certain pallet
Parâmetros de Entrada
eventType AggregationEvent
EQ_action ADD
MATCH_parentID urn:epc:id:sscc:0614141.1234567890
Resultado
<resultsBody>
<EventList>
<AggregationEvent>
<eventTime>2006-06-01T14:55:04.000Z</eventTime>
<recordTime>2006-08-18T12:50:07.000Z</recordTime>
<eventTimeZoneOffset>+01:00</eventTimeZoneOffset>
<parentID>urn:epc:id:sscc:0614141.1234567890</parentID>
<childEPCs>
<epc>urn:epc:id:sgtin:0057000.123430.2025</epc>
<epc>urn:epc:id:sgtin:0057000.123430.2027</epc>
<epc>urn:epc:id:sgtin:0057000.123430.2028</epc>
</childEPCs>
<action>ADD</action>
<bizStep>urn:epcglobal:cbv:bizstep:picking</bizStep>
<disposition>urn:epcglobal:cbv:disp:in_progress</disposition>
<readPoint>
<id>urn:epc:id:sgln:0614141.00729.shipping-door1</id>
</readPoint>
<bizLocation>
<id>urn:epc:id:sgln:0614141.00729.whatever450</id>
</bizLocation>
<bizTransactionList>
<bizTransaction
type="urn:epcglobal:cbv:fmcg:btt:po">http://transaction.acme.com/po/12345678</bizTransaction>
<bizTransaction
type="urn:epcglobal:cbv:btt:asn">http://transaction.acme.com/asn/1152</bizTransaction>
</bizTransactionList>
<xyz:temperature
xmlns:xyz="http://www.example.com/epcis/extensions/">25</xyz:temperature>
</AggregationEvent>
</EventList>
65
</resultsBody>
Título
Return all events for a given EPC that occurred after a given date
Parâmetros de Entrada
eventType ObjectEvent
GE_eventTime 2006-01-01T05:20:31+00:00
MATCH_epc urn:epc:id:sgtin:0034000.987650.2686
Resultado
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<resultsBody>
<EventList>
<ObjectEvent>
<eventTime>2006-05-10T03:50:35.000Z</eventTime>
<recordTime>2006-08-18T12:50:11.000Z</recordTime>
<eventTimeZoneOffset>+01:00</eventTimeZoneOffset>
<epcList>
<epc>urn:epc:id:sgtin:0034000.987650.2686</epc>
</epcList>
<action>OBSERVE</action>
<bizStep>urn:epcglobal:cbv:bizstep:receiving</bizStep>
<disposition>urn:epcglobal:cbv:disp:returned</disposition>
<readPoint>
<id>urn:epc:id:sgln:0614141.00729.whatever217</id>
</readPoint>
<bizLocation>
<id>urn:epc:id:sgln:0614141.00729.loc217</id>
</bizLocation>
<xyz:temperature
xmlns:xyz="http://www.example.com/epcis/extensions/">21</xyz:temperature>
</ObjectEvent>
<ObjectEvent>
<eventTime>2006-05-09T20:01:44.000Z</eventTime>
<recordTime>2006-08-18T12:50:16.000Z</recordTime>
<eventTimeZoneOffset>+01:00</eventTimeZoneOffset>
<epcList>
<epc>urn:epc:id:sgtin:0034000.987650.2686</epc>
<epc>urn:epc:id:sgtin:0034000.987650.3542</epc>
</epcList>
66
<action>OBSERVE</action>
<bizStep>urn:epcglobal:cbv:bizstep:loading</bizStep>
<disposition>urn:epcglobal:cbv:disp:in_transit</disposition>
<readPoint>
<id>urn:epc:id:sgln:0614141.00729.whatever215</id>
</readPoint>
<bizLocation>
<id>urn:epc:id:sgln:0614141.00729.loc215</id>
</bizLocation>
<bizTransactionList>
<bizTransaction
type="urn:epcglobal:cbv:fmcg:btt:po">http://transaction.acme.com/po/12345678</bizTransaction>
</bizTransactionList>
</ObjectEvent>
</EventList>
</resultsBody>
Título
Return all events generated by a given reader
Parâmetros de Entrada
eventType ObjectEvent, AggregationEvent, QuantityEvent, TransactionEvent
EQ_readPoint urn:epc:id:sgln:0614141.00729.whatever215
Resultado
<resultsBody>
<EventList>
<ObjectEvent>
<eventTime>2006-05-09T20:01:44.000Z</eventTime>
<recordTime>2006-08-18T12:50:16.000Z</recordTime>
<eventTimeZoneOffset>+01:00</eventTimeZoneOffset>
<epcList>
<epc>urn:epc:id:sgtin:0034000.987650.2686</epc>
<epc>urn:epc:id:sgtin:0034000.987650.3542</epc>
</epcList>
<action>OBSERVE</action>
<bizStep>urn:epcglobal:cbv:bizstep:loading</bizStep>
<disposition>urn:epcglobal:cbv:disp:in_transit</disposition>
<readPoint>
<id>urn:epc:id:sgln:0614141.00729.whatever215</id>
</readPoint>
67
<bizLocation>
<id>urn:epc:id:sgln:0614141.00729.loc215</id>
</bizLocation>
<bizTransactionList>
<bizTransaction
type="urn:epcglobal:cbv:fmcg:btt:po">http://transaction.acme.com/po/12345678</bizTransaction>
</bizTransactionList>
</ObjectEvent>
<ObjectEvent>
<eventTime>2007-04-23T11:26:52.000Z</eventTime>
<recordTime>2007-04-23T11:26:52.000Z</recordTime>
<eventTimeZoneOffset>+01:00</eventTimeZoneOffset>
<epcList>
<epc>urn:epc:id:sgtin:0057000.123430.2028</epc>
</epcList>
<action>OBSERVE</action>
<bizStep>urn:epcglobal:cbv:bizstep:shipping</bizStep>
<readPoint>
<id>urn:epc:id:sgln:0614141.00729.whatever215</id>
</readPoint>
<bizLocation>
<id>urn:epc:id:sgln:0614141.00729.loc215</id>
</bizLocation>
</ObjectEvent>
</EventList>
</resultsBody>
Título
Retrieve an EPC’s shipping date
Parâmetros de Entrada
eventType ObjectEvent
EQ_action OBSERVE
EQ_bizStep urn:epcglobal:cbv:bizstep:shipping
MATCH_epc urn:epc:id:sgtin:0057000.123430.2028
Resultado
<resultsBody>
<EventList>
<ObjectEvent>
<eventTime>2007-04-23T11:26:52.000Z</eventTime>
68
<recordTime>2007-04-23T11:26:52.000Z</recordTime>
<eventTimeZoneOffset>+01:00</eventTimeZoneOffset>
<epcList>
<epc>urn:epc:id:sgtin:0057000.123430.2028</epc>
</epcList>
<action>OBSERVE</action>
<bizStep>urn:epcglobal:cbv:bizstep:shipping</bizStep>
<readPoint>
<id>urn:epc:id:sgln:0614141.00729.whatever215</id>
</readPoint>
<bizLocation>
<id>urn:epc:id:sgln:0614141.00729.loc215</id>
</bizLocation>
</ObjectEvent>
</EventList>
</resultsBody>
Título
Retrieve all EPCs that were returned in year 2006
Parâmetros de Entrada
eventType ObjectEvent
EQ_action OBSERVE
GE_eventTime 2006-01-01T00:00:00+00:00
LT_eventTime 2007-01-01T00:00:00+00:00
EQ_disposition urn:epcglobal:cbv:disp:returned
Resultado
<resultsBody>
<EventList>
<ObjectEvent>
<eventTime>2006-05-10T03:50:35.000Z</eventTime>
<recordTime>2006-08-18T12:50:11.000Z</recordTime>
<eventTimeZoneOffset>+01:00</eventTimeZoneOffset>
<epcList>
<epc>urn:epc:id:sgtin:0034000.987650.2686</epc>
</epcList>
<action>OBSERVE</action>
<bizStep>urn:epcglobal:cbv:bizstep:receiving</bizStep>
<disposition>urn:epcglobal:cbv:disp:returned</disposition>
<readPoint>
69
<id>urn:epc:id:sgln:0614141.00729.whatever217</id>
</readPoint>
<bizLocation>
<id>urn:epc:id:sgln:0614141.00729.loc217</id>
</bizLocation>
<xyz:temperature
xmlns:xyz="http://www.example.com/epcis/extensions/">21</xyz:temperature>
</ObjectEvent>
</EventList>
</resultsBody>
