Implementação dos serviços EPCIS para o BizTalk RFID. Dissertação para obtenção do Grau de Mestre em. Engenharia Informática e de Computadores

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 encorajamento 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 trabalho. O meu sincero agradecimento a todos. 13 de Maio de 2011 Pedro Daniel Parreira Ferreira

.

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 sistemas 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 i

ii

Abstract Supply Chains are becoming more complex, with more players and involving a wide variety of information 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 information, contained in RFID tags, between business partners that have different and heterogeneous information 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 storing events and interfaces that meet the EPCIS standards of the EPCglobal architecture. Keywords: RFID, BizTalk, middleware, EPCglobal, EPCIS iii

iv

Í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 v

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 vi

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 vii

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 viii

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 ix

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 intervenientes, 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 utilizados 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 necessidade de se criarem normas para uniformizar o funcionamento da mesma. A organização internacional EPCglobal 1, 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 normalização predominante na comunidade RFID [3][4]. A EPCglobal criou a rede EPC (EPC Network) [5], que foi desenhada e implementada com o objectivo 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 1

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 componentes 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 inovarem 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 dispositivos 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. 2

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 sistemas 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 3

Para a comunicação entre sistemas é necessário que sejam seguidas regras que definam as interfaces aplicacionais e os protocolos de comunicação. Na seguinte imagem ilustram-se três grupos distintos 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 respeitem as normas EPCIS. 1.2. Objectivos Como objectivo para este trabalho, realizado em parceria com a empresa Link Consulting 2, propomonos desenvolver uma solução que facilite a adopção das normas EPCglobal para sistemas de informaçã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 4

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 realizados 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 recomendações da comunidade com mais experiência e conhecimento na área, para que possamos integrar 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 middleware 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 trabalho desenvolvido, justificando as opções tomadas e abrangendo todas as tecnologias utilizadas. 5

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. 6

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 surgiu 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 GS1 3, 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 identificar 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 anexadas 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/ 7

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. 8

Fig. 2.2 Componentes da arquitectura EPCglobal. 9

De seguida, com base na especificação EPCIS [7], faz-se uma sucinta descrição das responsabilidades dos principais elementos envolvidos: Readers: Hardware que efectua a leitura e/ou escrita das etiquetas RFID quando estas passam 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 Capturing 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 duplicados. 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, envolvendo 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 eventos 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 informaçã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 10

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 (caixas) foram verificados como estando agregados aos seguintes objectos (palete). Existem três interfaces EPCIS, a interface Capture, Query Control e Query Callback. A Capture Interface é 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 Control é 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íncrono ou standing request, o cliente estabelece uma subscrição para uma pesquisa periódica e, sempre que esta for executada, os resultados são entregues assincronamente ao destinatá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 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. 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 pesquisa a um serviço EPCIS relevante mas este é desconhecido, tal acontece quando o histórico 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. 11

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 aplicações dentro da mesma empresa ou em empresas diferentes. Assim, é possível que os participantes 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 framework 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 estruturados 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; 12

Lida com leituras de dados filtrados e consolidados, contextualizando as observações na realidade 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 elevado 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. 2.2. Fosstrak Fig. 2.4 Relação entre as interfaces EPCIS. O Fosstrak 4 é um sistema open source, disponível gratuitamente, para o rastreio e monitorização de objectos. Este sistema implementa um conjunto de normas 5 estabelecidas pela comunidade EPCglobal, tais como ALE, RP, RM, LLRP, TDT e EPCIS. O projecto Fosstrak (inicialmente denominado por Accada) foi iniciado pelo grupo de sistemas distribuídos e pelo laboratório Auto-ID da universidade ETH em Zurique, tendo como público-alvo os programadores 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 13

Neste contexto, é de salientar esta solução que tem como objectivo fornecer componentes essenciais 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 ocasionais 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 arquitectura, semelhante recomendada pela organização EPCglobal [17]. Alguns exemplos de middlewares são o Siemens RFID middleware 6, o Sun Java System RFID Software 7, o Oracle Sensor Edge- Server 8, 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 14

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. Apesar de estes sistemas serem bastante eficientes no tratamento isolado de dados RFID, não consideram 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, disponibilizando um modo uniforme de descobrir, comunicar e manipular dispositivos RFID num ambiente 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 plataforma 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 dispositivos. A figura seguinte ilustra uma vista geral de alto nível da arquitectura do BizTalk RFID [19]. 15

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 permite 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 à 16

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 estado 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 dispositivos. 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 manipulação dos pipelines de processamento de eventos necessários para a filtragem, agregação e transformaçã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 sistemas 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 etiquetas 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. 17

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 Server 11 é 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 protocolos 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 18

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 MessageBox. 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 possa 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: 19

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 processos 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 també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 eventos EPCIS envolve as observações de EPCs dos dispositivos de leitura e também a adição de contexto de negócio. A plataforma Biztalk Server contém implementações para trabalhar com um conjunto 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 contexto de negócio de sistemas da linha de negócio (LOB), e permite também a implementação das interfaces 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. 20

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 associar 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 Center, 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 desenvolvimento 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. 21

Este projecto denominado rfrbnet 12 desafios: (Rede Integrada de Rastreio de Bens) respeita os seguintes 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 agregadora. 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 privacidade 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 longo 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 plataforma apenas disponibiliza interfaces para que seja possível a partilha de informação com os restantes 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 recomendações EPCglobal. 12 rfrbnet - http://www.rfrb.net/site/ 22

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, reconhecida 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ância às principais componentes, à forma como estas interagem e aos papéis que cada uma desempenha 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 concretos dos serviços de acesso à informação e dos vínculos a protocolos de interface. Esta abordagem 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 framework. 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 hardware RFID, middleware RFID e EPCIS. A camada Hardware RFID representa as etiquetas e os leitores 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. 23

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 hardware 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. 24

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 responsabilidades de cada uma das restantes camadas da arquitectura da solução são descritas em seguida: Capture Application Tem em consideração a informação de negócio proveniente de outros sistemas e, seguindo um conjunto de regras estabelecidas, é responsável por transformar os eventos RFID, recebidos das camadas 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. 25

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 Callback. 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 utilizador, 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 eventos 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 26

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 apresentados 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 implementação. getvendorversion Devolve a versão da extensão desenvolvida pelo fornecedor. Este identificador 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. 27

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 28

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 existindo 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 trabalho desenvolvido. 29

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 Framework 13 A framework.net é uma plataforma da Microsoft que ajuda na criação de aplicações, proporcionando 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 disponibilizados e consumidos pelos clientes. Esta tecnologia implementa normas para a interoperabilidade 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 mensagens confiável utilizando sessões criadas sobre WS-Reliable Messaging e utilizando também MSMQ [26]. Microsoft SQL Server 15 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. SvcUtil 17 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 30

WSCF.Blue 18 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 componentes 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/ 31

4.1. Soluções e Trabalho Utilizado O BizTalk RFID foi o middleware RFID utilizado nesta solução, não havendo qualquer desenvolvimento nesta camada. Para desempenhar o papel da camada Capture Application utilizámos a componente 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 permite-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 camadas superiores da arquitectura. Na fase inicial deste trabalho desenvolvemos uma Capture Application que efectua uma conversão simples dos eventos capturados em eventos EPCIS, a mesma conversã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 mysql 19, enquanto a nossa solução está em SQL Server, para o carregamento dos dados exemplo foi necessária efectuar uma conversã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/ 32

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 subscriptions. 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 campo 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. 33

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 UTC 20. 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 34

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 quantidade 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. 35

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 armazena-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 pesquisas (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 quantidade 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 TransactionEvent. 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 36

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 realizar é configurada exactamente como numa situação de pesquisa de eventos normal, com o acrescento 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 seguintes 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, é feita 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 utilizá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. 37

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 utilizadores. 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 apenas 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 agendamento. 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 paralelamente são armazenados na base de dados. 38

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 conseguia 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 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. 39

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 serviço. 2. Foi utilizada outra aplicação, a aplicação cliente do Fosstrak, que apesar de estar desenvolvida numa outra linguagem de programação (Java), mostrou-se com capacidade de comunicaçã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 mensagens 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 utilizador. 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 falsamente 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 autenticado 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 tecnologia WCF [28]. O WCF providencia o acesso a estas funcionalidades através da configuração de bindings 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. 40

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. 41

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 instalados 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. 42

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 Time Zone Offset +00:00 EPCs Action Business Step Read Point Business Location 2011-04-20T06:00:00Z urn:epc:id:sgtin:0057000.123780.7788 ADD urn:epcglobal:cbv:bizstep:commissioning urn:epc:id:sgln:0614141.00729.rp1 urn:epc:id:sgln:0614141.00729.fabrica 43

2. Paletização dos objectos fabricados Event Type Event Time Time Zone Offset +00:00 Parent Object Child EPCs Action Business Step Read Point Business Location Aggregation event 2011-04-20T09:00:10Z urn:epc:id:sscc:0614141.1234567890 urn:epc:id:sgtin:0057000.123780.7788 urn:epc:id:sgtin:0057000.123430.2028 urn:epc:id:sgtin:0057000.123430.2029 ADD urn:epcglobal:cbv:bizstep:packing urn:epc:id:sgln:0614141.00729.rp2 urn:epc:id:sgln:0614141.00729.fabrica 3. Carregamento da palete no veículo de transporte Event Type Object event Event Time Time Zone Offset +00:00 EPCs Action Business Step Read Point Business Location 2011-04-21T10:05:57Z urn:epc:id:sscc:0614141.1234567890 OBSERVE urn:epcglobal:cbv:bizstep:loading urn:epc:id:sgln:0614141.00729.rp3 urn:epc:id:sgln:0614141.00729.fabrica 4. Descarregamento da palete do veículo de transporte Event Type Object event Event Time Time Zone Offset +00:00 EPCs Action Business Step Read Point Business Location 2011-04-23T09:22:43Z urn:epc:id:sscc:0614141.1234567890 OBSERVE urn:epcglobal:cbv:bizstep:receiving urn:epc:id:sgln:0614141.00729.rp1 urn:epc:id:sgln:0614141.00729.armazem 5. Inventário Event Type Event Time Time Zone Offset +00:00 Quantity 5 Business Step Read Point Quantity event 2011-04-23T12:36:17Z urn:epcglobal:cbv:bizstep:storing urn:epc:id:sgln:0614141.00729.rp2 44

Business Location urn:epc:id:sgln:0614141.00729.armazem 6. Carregamento da palete no veículo de transporte Event Type Object event Event Time Time Zone Offset +00:00 EPCs Action Business Step Read Point Business Location 2011-04-24T17:03:23Z urn:epc:id:sscc:0614141.1234567890 OBSERVE urn:epcglobal:cbv:bizstep:loading urn:epc:id:sgln:0614141.00729.rp3 urn:epc:id:sgln:0614141.00729.armazem 7. Descarregamento da palete no veículo de transporte Event Type Object event Event Time Time Zone Offset +00:00 EPCs Action Business Step Read Point Business Location 2011-04-27T09:23:17Z urn:epc:id:sscc:0614141.1234567890 OBSERVE urn:epcglobal:cbv:bizstep:receiving urn:epc:id:sgln:0614141.00729.rp1 urn:epc:id:sgln:0614141.00729.loja 8. Despaletização dos objectos fabricados Event Type Event Time Time Zone Offset +00:00 Parent Object Child EPCs Action Business Step - Read Point Business Location Aggregation event 2011-04-27T10:57:47Z urn:epc:id:sscc:0614141.1234567890 urn:epc:id:sgtin:0057000.123780.7788 urn:epc:id:sgtin:0057000.123430.2028 urn:epc:id:sgtin:0057000.123430.2029 DELETE urn:epc:id:sgln:0614141.00729.rp2 urn:epc:id:sgln:0614141.00729.loja 9. Venda do produto Event Type Event Time Object event Time Zone Offset +00:00 EPCs 2011-04-28T13:14:17Z urn:epc:id:sgtin:0057000.123780.7788 45

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, Armazém ou Loja), o Centro de Controlo poderá efectuar pesquisas de informação aos sistemas, utilizando 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 executadas. 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. 46

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 ocorrem de 10 em 10 minutos. Parâmetros da pesquisa Parâmetros da subscrição Event type = Object Event 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 anterior. Como ainda não ocorreram eventos até este momento o resultado da pesquisa será vazio. Parâmetros da pesquisa Resultado da pesquisa Event type = Object Event 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 47

Read Point Business Location urn:epc:id:sgln:0614141.00729.rp1 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 Resultado da pesquisa Event type = Object Event 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 ocorreram eventos desde a última execução o resultado da pesquisa será vazio. Parâmetros da pesquisa Resultado da pesquisa Event type = Object Event 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. 48

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 Parâmetros da subscrição Event type = Object Event 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 anterior. Como ainda não ocorreram eventos até este momento o resultado da pesquisa será vazio. Parâmetros da pesquisa Resultado da pesquisa Event type = Object Event 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 Resultado da pesquisa Event type = Object Event 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 49

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 Resultado da pesquisa Event type = Object Event 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 NUnit 21 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 sistemas 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 aplicaçõ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/ 50

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 ocorreram 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 51

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 ) 52

- 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 soapui 22. 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 EPCglobal 23. 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-Materials 24, 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. 53

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 agregação e desagregação. A figura seguinte representa os detalhes de agregação na montagem de um portátil: 54

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. 55

Tempo de resposta (ms) Descrição dos testes Com estes testes queríamos validar que a nossa solução não apresenta erros e para isso foi importante 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 posteriormente 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. 35000 30000 25000 20000 15000 10000 5000 0 0 2000 4000 6000 8000 10000 Número de registos na resposta Fosstrak A nossa Solução Fig. 5.6 - Representação gráfica dos resultados dos testes de desempenho Número de registos Tempo médio de resposta (ms) na resposta 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 56

A nossa solução só apresenta tempo inferior de resposta ao Fosstrak para um único registo na resposta. Para mais registos, apresenta uma performance inferior, demora 1.5 vezes o tempo de resposta do Fosstrak (em média). Propomos como trabalho futuro a identificação do problema e a optimização da performance do sistema. 57

6. Conclusões e Trabalho Futuro Neste capítulo, será apresentado um resumo do trabalho que foi desenvolvido ao longo desta dissertaçã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 desenvolvimentos 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 facilita a substituição destas por outras mais evoluídas, que estejam de acordo com as normas EPCglobal, 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 desenvolvida 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 estudo 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. 58

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 resultados obtidos nos testes efectuados foram sempre os correctos. Acreditamos que os casos de utilizaçã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 parceiros de negócio. 6.2. Trabalho Futuro Apesar de todos os objectivos a que nos propusemos terem sido cumpridos, ao longo do desenvolvimento 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 59

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 eventos 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 identificador 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 informaçã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 endereço. 60

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 Society, 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 Communications 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 Services, Department of Computer Engineering, KyungHee University, Korea, 2007. [19] M. Beckner, M. Simms, and R. Venkatesh, Pro RFID in BizTalk Server 2009, Apress, 2009. 61

[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/enus/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, [Online]. 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, patterns & practices by Microsoft, 2008. [29] A. Ilic, T. Andersen, and F. Michahelles, EPCIS-based Supply Chain Visualization Tool, Auto-ID Labs White Paper, 2009. 62

ANEXO A Modelo de Domínio 63