Smartphones para identificação de pagamentos

(1)

Universidade de Lisboa

Faculdade de Ciˆencias

Departamento de Inform´

atica

SMARTPHONES PARA IDENTIFICAC

¸ ˜

AO E

PAGAMENTOS

Ricardo Gon¸

calves de Santa Ana

Mestrado em Engenharia Inform´

atica

(2)

(3)

Universidade de Lisboa

Faculdade de Ciˆencias

Departamento de Inform´

atica

SMARTPHONES PARA IDENTIFICAC

¸ ˜

AO E

PAGAMENTOS

Ricardo Gon¸

calves de Santa Ana

Projecto orientado pelo Eng. <Jo˜ao Miguel Correia da Silva Carreira Almeida> e co-orientado pelo Prof. Dr. <Lu´ıs Correia>

Mestrado em Engenharia Inform´

atica

(4)

(5)

Declara¸

c˜

ao

Ricardo Gon¸calves de Santa Ana, aluno no 29191 da Faculdade de Ciências da Universidade de Lisboa, declara ceder os seus direitos de cópia sobre o seu Relatório de Projecto em Engenharia Informática, intitulado ”Smartphones para Identifica¸cão e Pagamentos”, realizado no ano lectivo de 2006/2007 à Faculdade de Ciências da Universidade de Lisboa para o efeito de arquivo e consulta nas suas bibliotecas e publica¸cão do mesmo em formato electrónico na Internet.

FCUL, 17 de Setembro de 2007

João Miguel Correia da Silva Carreira Almeida, supervisor do projecto de Ri-cardo Gon¸calves de Santa Ana, aluno da Faculdade de Ciências da Universidade de Lisboa, declara concordar com a divulga¸cão do Relatório do Projecto em Engenharia Informática, intitulado ”Smartphones para Identifica¸cão e Pagamentos”.

(6)

(7)

Nota sobre Confidencialidade

Este documento representa a versão pública do relatório ”Smartphones para Identifica¸cão e Pagamentos”.

Nesta versão, a informa¸cão considerada confidencial, por parte da Institui¸cão de Acolhimento do Projecto, foi omitida. No entanto, o presente relatório foi elaborado com isto em mente para que seja poss´ıvel captar a visão geral do trabalho realizado e as tecnologias envolvidas neste projecto bem como os principais problemas envol-vidos nos diversos cenários.

Para esse efeito, toda a informa¸cão confidencial foi devidamente assinalada no relatório e colocada em um anexo, o B, omitido nesta versão do relatório.

(8)

Este documento descreve o projecto realizado no âmbito da disciplina Projecto em Engenharia Informática do Mestrado em Engenharia Informática da Faculdade de Ciências da Universidade de Lisboa.

O projecto foi desenvolvido na empresa Link Consulting que nasceu no final de 1998, constituindo uma empresa de caracter´ısticas inovadoras, que congrega hoje cerca de duas centenas de colaboradores altamente qualificados e motivados, com um amplo conhecimento do mercado e das empresas.

Os cartões inteligentes, apesar de não serem uma novidade tecnológica, come¸cam agora a chegar ao dom´ınio das aplica¸cões do grande público, nomeadamente na área bancária e da identifica¸cão pessoal. Estes dispositivos, que para muitos ainda são uma pequena evolu¸cão dos cartões com banda magnética, são reais computadores que a progressão da tecnologia de micro electrónica irá dotar rapidamente de capaci-dade de processamento e memória, possibilitando o armazenamento e tratamento de mais informa¸cão, e sobretudo permitindo a sua interliga¸cão através de um crescente número de tecnologias de comunica¸cão. Os cartões nas suas múltiplas vertentes de Smart Card, RFID e dispositivos móveis, podem tornar-se dispositivos capilares nas futuras redes permitindo identificar, localizar, autenticar e armazenar informa¸cão de pessoas, contratos ou dos mais diversos objectos.

(9)

(10)

Lista de Figuras vi

1 Introdu¸c˜ao 1

1.1 Motiva¸c˜ao . . . 1

1.2 Contexto Cient´ıfico e Tecnol´ogico . . . 1

1.3 Objectivos do est´agio . . . 3

1.4 Organiza¸c˜ao e Metodologia . . . 3

1.4.1 A Link Consulting . . . 3

1.5 Planeamento . . . 5

1.6 Organiza¸c˜ao do documento . . . 5

2 Enterprise Application Integration 7 2.1 Enquadramento . . . 7

2.1.1 EAI - Enterprise Application Integration . . . 7

2.2 O problema . . . 10

2.3 Objectivo . . . 10

2.4 Arquitectura da Solu¸c˜ao . . . 11

2.4.1 Ponto de Integra¸c˜ao . . . 12

2.4.2 Ferramentas . . . 14

3 Aplica¸c˜ao Cliente de Carregamento Remoto de T´ıtulos 17 3.1 Objectivo . . . 17

3.2 Tecnologias e Conceitos Base . . . 17

3.2.1 Smart Cards . . . 17

3.2.2 Tecnologia Calypso . . . 19

3.2.3 Near Field Communication . . . 20

3.2.4 No¸c˜ao de Framework . . . 21

3.2.5 JSR-172: J2METM_{Web Services Specification} _{. . . 21}

3.2.6 JSR-177: Security and Trust Services API for J2ME (SATSA) 22 3.2.7 No¸c˜ao de Stub . . . 24

3.2.8 Factory Design Pattern . . . 27

3.3 Situa¸c˜ao Inicial . . . 28

(11)

3.4 Situa¸c˜ao Actual . . . 28

3.5 Implementa¸c˜ao . . . 28

3.5.1 Interface APDUConnection . . . 28

3.5.2 Arquitectura da Solu¸c˜ao . . . 31

3.5.3 Modo de Funcionamento . . . 31

3.6 Limita¸c˜oes Identificadas . . . 32

4 Servi¸cos do Motor de Carregamento Remoto de T´ıtulos 33 4.1 Objectivo . . . 33

4.2 An´alise do problema . . . 33

4.2.1 Software de Interoperabilidade para Terminais . . . 34

4.2.2 Métodos a Disponibilizar . . . 35 4.3 Implementa¸cão . . . 37 5 Remote Coupler 39 5.1 Objectivo . . . 39 5.2 Situa¸cão Inicial . . . 39 5.2.1 Visão Funcional . . . 41 5.3 Solu¸cão pretendida . . . 41 5.4 Implementa¸cão . . . 42 6 Conclusão 44 6.1 Aprecia¸cão Cr´ıtica do Trabalho Desenvolvido . . . 44

6.2 Aprecia¸c˜ao do Est´agio . . . 45

6.3 Trabalho Futuro . . . 45

A Mapa de Gantt 47

B Anexo Confidencial 48

Lista de Acr´onimos 50

Bibliografia 52

´_{Indice Remissivo} ₅₂

(12)

(13)

Lista de Figuras

1.1 A origem da Link . . . 4

1.2 O grupo AITEC . . . 4

1.3 Planeamento do Est´agio . . . 6

2.1 Arquitectura ponto-a-ponto versus Arquitectura EAI . . . 9

2.2 Sistemas do cliente . . . 10

2.3 Arquitectura da solu¸c˜ao . . . 11

2.4 Funcionamento do BizTalk Server 2006 . . . 12

2.5 Publish-Subscribe . . . 13

2.6 Exemplo gen´erico de uma integra¸c˜ao . . . 13

2.7 Processo gen´erico de um ponto de integra¸c˜ao . . . 14

2.8 Exemplo de um Schema para BizTalk Server 2006 . . . 16

2.9 Exemplo de um Mapa para Biztalk Server 2006 . . . 16

3.1 Aplica¸c˜ao T´ıpica baseada na JSR172 . . . 22

3.2 Conceito de Procedimentos num Programa Distribu´ıdo . . . 24

3.3 Modelo de Execu¸c˜ao . . . 24

3.4 Passos de uma Chamada Remota de Procedimentos . . . 25

3.5 Diagrama UML “Factory Pattern” . . . 27

3.6 Arquitectura da situa¸c˜ao inicial . . . 28

3.7 Arquitectura da situa¸c˜ao final . . . 29

3.8 Aplica¸c˜ao do padr˜ao Factory . . . 30

4.1 Solu¸c˜ao Inicial . . . 34

4.2 Solu¸c˜ao Pretendida . . . 34

4.3 Arquitectura do SMCRT . . . 38

5.1 Arquitectura do Software de Interoperabilidade para Terminais . . . . 40

5.2 Arquitectura com SAMs locais . . . 41

5.3 Arquitectura com SAMs remotos . . . 42

5.4 Arquitectura da SIT . . . 43

(14)

(15)

Cap´ıtulo 1

Introdu¸

c˜

ao

O projecto integra-se num roadmap de desenvolvimento de inova¸cões e futuros módulos de plataforma de electronic ticketing, que consiste num sistema integrado e modular, para a implementa¸cão de sistemas de mobile ticketing, aplicada ao cartão SmartCard Dual-Interface com microprocessador, SmartCard Contactless de memória.

1.1 Motiva¸

c˜

ao

Tendo em conta que a disciplina de Projecto de Engenharia Inform´atica(PEI) ´e a ´

ultima do curso, representa assim um grande desafio para os alunos finalistas, reque-rendo assim especial aten¸cão na escolha do tema a abordar no PEI. Esta disciplina representa o culminar do processo de gradua¸cão de um aluno do curso de Engenharia Informática da FCUL pelo que deve ser abordada, de ânimo não leve.

Trantando-se de uma decisão não trivial, a motiva¸cão para a escolha do tema “Smartphones para Identifi¸cão e Pagamentos” foi baseada nos critérios que se se-guem:

- O grau de interesse no tema e o auto-desafio de intervir numa àrea tecnológica que apesar de não ser recente, é actualmente emergente.

- atingir a satisfa¸c˜ao pessoal no desenvolvimento do trabalho

1.2 Contexto Cient´ıfico e Tecnol´

ogico

A generaliza¸cão dos Smartcards Contactless aplicados à bilhética (ticketing) para transportes é uma realidade. Em Lisboa existem actualmente já 1,3 milhões de cartões em circula¸cão. A aplica¸cão da mesma tecnologia ao turismo é também já uma realidade com a implementa¸cão do Cartão do Turista de Lisboa.

(16)

Todo este sistema tem sido feito com base numa abordagem inovadora utilizando a plataforma de electronic ticketing. Esta parte da aplica¸cão de uma Metodologia de Enterprise Architecture na fase de análise de processos de negócio, para depois seguir com a aplica¸cão de Frameworks de Software Embedded na fase de implementa¸cão dos sistemas de ticketing baseados em contactless smartcards.

A solu¸cão de electronic ticketing da Link, (Sistema Coordenador Integrado para Ticketing Interoperável & Smart Cards) é um sistema integrado e modular para a implementa¸cão de sistemas de electronic ticketing e cartões. Este sistema inclui a gestão de clientes, emissão e personaliza¸cão de cartões e SmartCards com contacto e sem contacto (contactless), gestão de contratos e produtos tarifários, vendas e carregamentos remotos, controlo de utiliza¸cão, gestão da seguran¸ca, compensa¸cão de receitas para operadores de transportes públicos de passageiros e outros esquemas de cartão multi-servi¸cos, em especial associados a servi¸cos urbanos e dos munic´ıpios. Qualquer sistema que requeira a atribui¸cão e verifica¸cão de direitos de acesso a servi¸cos a clientes ou colaboradores, exige o recurso a processos e ferramentas de gestão de valor, nomeadamente meios de pagamento, que devem ser rigorosos, seguros e fáceis de usar, mas que apresentam muitos custos operacionais.

Tradicionalmente, a agiliza¸cão destes processos conduz à substitui¸cão do dinheiro por um cartão de plástico ou mesmo magnético, o que permite simplificar algumas partes dos processos. No entanto, deixa por resolver algumas questões relaciona-das com a ergonomia e a seguran¸ca da utiliza¸cão, ou então obriga a grandes custos operacionais. Estes custos são derivados, por exemplo, das comunica¸cões, da pouca fiabilidade dos cartões ou mesmo da fraude interna e externa do sistema, o que também representa custos. Um sistema deste tipo deve apresentar uma solu¸cão para estes problemas: deve ser modular, baseado em standards e implementa¸cões abertas, permitindo constituir-se como add-ons a sistemas existentes e não um sis-tema monol´ıtico que obrigue a substitui-los.

Assim, um moderno sistema de bilhética (ticketing) deve basear-se numa tecno-logia aberta, segura, fiável e ergonómica do ponto de vista do utilizador.

Uma plataforma de electronic ticketing que a Link Consulting tem vindo a de-senvolver com parceiros internacionais desde 1996, e que nos últimos anos atingiu um elevado n´ıvel de matura¸cão, é o SmartCITIES, para implementa¸cão de Smart Cards contactless dual-interface. Este sistema é baseados no sistema de opera¸cão e seguran¸ca da tecnologia Calypso, que junta num mesmo cartão com chip a ergono-mia de uma transaçcão contactless, e a seguran¸ca e baixo custo da transaçcão que pode realizar-se off-line.

A emissão de um conjunto Smart Cards personalizados, ou mesmo smart-tickets não personalizados, permite a elimina¸cão de parte dos custos associados à gestão de valor, em moedas e/ou notas ou mesmo vinhetas (e.g. selo de passe, quota),

(17)

Cap´ıtulo 1. Introdu¸c˜ao 3

que a empresa tem normalmente de fazer, substituindo-o por valor electr´onico, num regime totalmente seguro.

1.3 Objectivos do est´

agio

O objectivo deste estágio enquadra-se, essencialmente, na evolu¸cão de componentes que interajam com os módulos do Servidor com Motor de Carregamento Remoto de T´ıtulos e nos aspectos relacionados com a aplica¸cão de carregamentos desses t´ıtulos em SmartPhones.

Essa evolu¸c˜ao passa por melhorar os servidores de suporte, que dever˜ao disponi-bilizar Web Services para o acesso via SmartPhones.

Este projecto ser´a levado a cabo pela unidade SmartCITIES da Link.

1.4 Organiza¸

c˜

ao e Metodologia

O projecto enquadra-se nas metodologias de desenvolvimento em prática na em-presa, tendo no entanto uma fase inicial de forma¸cão nas tecnologias a utilizar e de investiga¸cão base, por forma a dotar o aluno de uma visão completa das solu¸cões existentes que serão utilizadas como blocos de constru¸cão do trabalho.

1.4.1 A Link Consulting

Desde a sua cria¸cão em 1980, que o INESC tem sido um factor diferenciador na sociedade portuguesa, afirmando que é poss´ıvel criar riqueza no território nacional com Portugueses, com Tecnologia e com Inova¸cão.

H´a pois mais de duas d´ecadas que o INESC desenvolve um percurso original na ´

area da Ciência & Tecnologia e da Inova¸cão. Num modelo reconhecido como ino-vador, o INESC conseguiu fazer coexistir as actividades de investiga¸cão, de trans-ferência de tecnologia, forma¸cão e incuba¸cão de empresas. O reconhecimento pela actividade desenvolvida tem sido patente na evolu¸cão das Universidades de Engenha-ria, na presen¸ca portuguesa no I&D europeu, na forma¸cão profissional e na cria¸cão de empresas de base tecnológica.

A Link Consulting teve origem (ver Figura 1.1) na transforma¸cão em estru-tura empresarial dos Centros de Transferência de Tecnologia do INESC da área de Relatório Final – Curso de Especializa¸cão Profissional em Engenharia Informática Informática e Computadores. Estes Centros tinham sido criados em 1991 com base num contrato estabelecido com o PEDIP, no âmbito dos Programas PEDIP.

Os Centros foram pioneiros em muitas áreas de actividades como a Internet, a Qualidade de Software, o Multimédia, o Suporte à Decisão, tendo participado em

(18)

Figura 1.1: A origem da Link

numerosos projectos, quer no mercado Portuguˆes, quer no mercado internacional, muitos dos quais no ˆambito dos programas quadros da Comunidade Europeia.

No esp´ırito original do contrato com o PEDIP existia o objectivo de que as actividades dos Centros de Transferˆencia de Tecnologia viessem a ser totalmente suportadas por mecanismos de mercado. Dado ser essa a situa¸c˜ao dos Centros da ´

area de Informática e Computadores, no contexto da reorganiza¸cão das actividades do INESC, decidiram os respectivos sócios efectuar o spin-off destas actividades numa única empresa, que veio a dar origem à Link Consulting SA, cujo propósito foi procurar desenvolver este património técnico.

O INESC continua ser o parceiro privilegiado da Link Consulting em numerosas actividades de Investiga¸c˜ao, Desenvolvimento e Forma¸c˜ao.

O grupo AITEC (ver Figura 1.2) integra empresas que se complementam em termos de oferta de base tecnol´ogica, contando com cerca de 350 colaboradores.

Figura 1.2: O grupo AITEC

A Link Consulting é uma empresa única que consegue conjugar a experiência de 15 anos de actividade em algumas das maiores empresas nacionais e internacio-nais assim como a Inova¸cão resultante da associa¸cão ao INESC, o mais prestigiado Instituto Português de I&D em Tecnologias da Informa¸cão.

(19)

Cap´ıtulo 1. Introdu¸c˜ao 5

A Link Consulting tem procurado, fruto da sua actividade de Consultoria, criar um conhecimento funcional de alguns segmentos da actividade para ter a capacidade de mais rapidamente endere¸car os respectivos problemas. Os sectores seguintes são naturalmente aqueles onde existe maior dinâmica económica e onde maior número de projectos têm sido realizados:

1. Administra¸cão Pública 2. Floresta 3. Log´ıstica 4. Telecomunica¸cões 5. Servi¸cos Financeiros 6. Saúde

1.5 Planeamento

O planeamento definido para o estágio está brevemente descrito na Figura 1.3. O mapa de Gantt correspondente ao planeamento pode ser consultado nos Apêndice A.

1.6 Organiza¸

c˜

ao do documento

Este documento est´a organizado da seguinte forma:

• O Cap´ıtulo 2 Enterprise Application Integration, que descreve o trabalho de integra¸cão no estágio. Este projecto, como o nome indica, resolve um problema de integra¸cão de aplica¸cões de uma organiza¸cão, por sua vez, cliente da Link.

• O Cap´ıtulo 3 Aplica¸cão Cliente de Carregamento Remoto de T´ıtulos. Des-creve o protótipo da aplica¸cão móvel, desenvolvida para estudo das necessi-dades dos novos módulos a desenvolver bem como poss´ıveis altera¸cões nos já existentes para que aplica¸cões móveis possam aceder ao Servidor com Motor de Carregamento Remoto de T´ıtulos. É também este cap´ıtulo que foca o tema do estágio.

Isto permitir´a a venda e o carregamento de t´ıtulos nos telem´oveis que suportem a tecnologia Near Field Communication.

• O Cap´ıtulo 4 Remote Coupler. Neste cap´ıtulo, est´a descrita a implementa¸c˜ao do “Remote Coupler” do Software de Interoperabildade para Terminais - N´ıvel Leitor.

(20)

Figura 1.3: Planeamento do Est´agio

• O Cap´ıtulo 5 Servi¸cos do Motor de Carregamento Remoto de T´ıtulos. Do-cumenta o desenvolvimento do Servi¸co Web que disponibiliza os m´etodos de neg´ocio do Software de Interoperabildade para Terminais.

• O Cap´ıtulo 6 Conclusão e elaçcões retiradas de todo o projecto bem como uma descri¸cão do trabalho futuro.

(21)

Cap´ıtulo 2

Enterprise Application Integration

Este cap´ıtulo, tem como propósito documentar o trabalho de integra¸cão na empresa, realizado na Fase 1 do planeamento do estágio (Figura 1.3). Serviu ainda de base para a aprendizagem das solu¸cões e arquitecturas que servem de suporte à integra¸cão das solu¸cões de mobile ticketing tendo em conta que é igualmente necessária uma arquitectura de backoffice que suporte a integra¸cão de todos os sistemas envolvidos neste cenário.

2.1 Enquadramento

Data a multiplicidade de sistemas e aplica¸cões que uma organiza¸cão pode ter, o esfor¸co para a replica¸cão de dados entre os diversos sistemas pode atingir um valor elevado. Uma vez que as organiza¸cões estão sempre em constante mudan¸ca, é ex-pectável que os Sistemas de Informa¸cão das empresas estejam sempre alinhados com os seus processos e não uma adapta¸cão dos processos ao modo de funcionamento dos mesmos Sistemas. Enterprise Application Integration (EAI), é um processo para ligar diferentes aplica¸cões e Sistemas, a outros, de forma a ganhar vantagem compe-titiva tanto operacional como financeira reduzindo também os custos de gestão da informa¸cão.

2.1.1 EAI - Enterprise Application Integration

Quando diferentes sistemas não conseguem partilhar a sua informa¸cão de uma forma eficiente e eficaz, são criados constrangimentos que requerem a interven¸cão humana sob a forma de tomada de decisões ou introdu¸cão de dados. Com uma arquitectura EAI correctamente implementada, as organiza¸cões podem então canalizar os seus esfor¸cos para as competências de cria¸cão de valor ao invés de se focaram na gestão dos fluxos de informa¸cão.

Durante gera¸cões, os sistemas foram constru´ıdos para servirem um único propósito e para um conjunto espec´ıfico de utilizadores e ainda sem tomarem em linha de

(22)

conta a integra¸cão dos mesmos sistemas, com outros de ainda maiores dimensões e múltiplas aplica¸cões. EAI é a solu¸cão para o resultado não antecipado do de-senvolvimento de aplica¸cões sem uma visão central em mente. O que as empresas pretendem é partilhar dados e processos sem terem de realizar altera¸cões profundas nas suas aplica¸cões ou na estrutura dos dados. Só com a cria¸cão de um método para atingir este tipo de integra¸cão é que EAI pode ser tanto funcional e economicamente viável.

Um dos grandes desafios que as organiza¸cões modernas enfrentam, é o de pro-videnciar a todos os seus colaboradores um acesso completo, transparente e em tempo-real à informa¸cão. Muitos dos sistemas legados, ainda hoje utilizados, foram desenvolvidos usando tecnologias proprietárias e hoje consideradas arcaicas e por vezes de dif´ıcil integra¸cão com outros sistemas. Como consequência são criados “si-los” de informa¸cão dispersos pelos departamentos das organiza¸cões. Esses sistemas, dificultam o movimento coerente da informa¸cão de uma aplica¸cão para a outra. EAI, como uma disciplina, tem como objectivo aliviar muitos desses problemas, bem como criar novos paradigmas que, verdadeiramente, apoiem as organiza¸cões pró-activas. Tem também a inten¸cão de superar o simples objectivo de inter-ligar aplica¸cões e facilita o aparecimento de novas formas de potenciar o conhecimento organizacional que pode ser aplicado na cria¸cão de novas vantagens competitivas para a empresa.

Pode dizer-se que com um sistema de integra¸cão a que o valor soma do número de sistemas quando interligados, é maior que o valor de cada sistema a funcionar individualmente.

Melhorando a conectividade

Cada vez mais, tem sido dada maior importância ao EAI por parte das empresas porque nestas a computa¸cão tem frequentemente tomado a forma de “ilhas de au-toma¸cão”. Isto ocorre quando o valor individual dos sistemas não é maximizado, devido a um isolamento total ou parcial dos restantes sistemas da empresa. Se a integra¸cão for aplicada sem uma aproxima¸cão EAI estruturada, as liga¸cões “ponto-a-ponto” crescem ao longo da organiza¸cão. São acrescentadas dependências sem uma base definida, resultando numa malha de dif´ıcil manuten¸cão. Este problema é frequentemente denominado de “esparguete”, uma alusão ao equivalente à pro-grama¸cão do código-esparguete. Por exemplo:

Sendo n o número de sistemas, o número de liga¸cões necessárias para ter uma malha completa de liga¸cões ponto-a-ponto é dado pela fórmula

n(n−1)

2 . Assim para n=10, uma malha teria (10)·(9)

2 , ou 45 liga¸c˜oes

“ponto-a-ponto”.

Contudo, EAI não se singe apenas à partilha de dados entre aplica¸cões. Foca também a partilha de dados do negócio e seus processos. Atender a EAI, inclui uma visão

(23)

Cap´ıtulo 2. Enterprise Application Integration 9

de sistema de sistemas, que por sua vez envolve problemas multi-disciplinares, com sistemas heterog´eneos e distribu´ıdos por uma rede de m´ultiplos n´ıveis.

Em suma, EAI inclui o desafio de unir eficazmente sistemas e diversas aplica¸cões de uma organiza¸cão, com uma metodologia focada na integra¸cão de processos e dados, permitindo às organiza¸cões acompanhar as mudan¸cas em tempo real.

(a) ponto-a-ponto (b) EAI

Figura 2.1: Arquitectura ponto-a-ponto versus Arquitectura EAI

Benef´ıcios de uma Arquitectura EAI

1. Comparando com a solu¸cão de liga¸cões “ponto-a-ponto”, o EAI gera as liga¸cões entre sistemas o que permite a redu¸cão de custos de gestão;

2. Construindo um sistema/aplica¸cão com integra¸cão em mente, reduz o mon-tante de dinheiro despendido no desenvolvimento de sistemas/aplica¸cões adi-cionais;

3. É poss´ıvel construir novas aplica¸cões tendo por base aplica¸cões já existentes;

4. Permite separar o desenvolvimento das funcionalidades nucleares, respeitantes ao sistema/aplica¸c˜ao, da compatibilidade com outros sistemas/aplica¸c˜oes;

5. Elimina¸cão das “ilhas” de informa¸cão isoladas, permitindo uma gestão centra-lizada;

6. Tecnologia que permite integrar os sistemas existentes com os novos sistemas com um esfor¸co relativamente pequeno;

7. Permite a propaga¸c˜ao de informa¸c˜ao em tempo real ao longo da empresa;

8. Inclui a no¸cão de reutiliza¸cão, bem como de distribui¸cão de processos de negócio e dados;

9. Implementa¸cão de um ponto único de comunica¸cão entre as diferentes aplica¸cões, virtualizando a interface adequada a cada uma delas, e implementando as transforma¸cões de dados necessárias à troca de informa¸cão;

(24)

10. Comunica¸cão entre as várias aplica¸cões usando mensagens, formalizando o conteúdo de cada uma delas e facilitando o tratamento e encaminhamento da informa¸cão para os destinos adequados;

11. Utiliza¸cão de um mecanismo de encaminhamento de mensagens que permite um interface único para as trocas de informa¸cão em batch, assim como a integra¸cão transaccional on-line de vários sistemas distintos;

12. Possibilidade de tratar encadeamentos de fluxos de informa¸cão (workflow) en-tre as várias aplica¸cões de forma a suportar cadências de processos complexos;

2.2 O problema

O cliente possui seis sistemas independentes e heterogéneos (Figura 2.2) aos quais pretende integrar uma nova aplica¸cão fornecida pela Link, o (Sistema de Gestão de Opera¸cões) (Figura 2.3).

Figura 2.2: Sistemas do cliente

2.3 Objectivo

Este projecto surge como sub-objectivo de um propósito mais alargado que é a implementa¸cão de um sistema de bilhética sem contacto. É com vista a atingir esse sub-objectivo que surge a necessidade de sincronizar informa¸cão entre os diversos sistemas. A infra-estrutura de middleware a implementar, destina-se a suportar o fluxo de dados entre as várias aplica¸cões intervenientes nos processos da área de opera¸cões.

(25)

2.4 Arquitectura da Solu¸

c˜

ao

Para a integra¸cão dos vários sistemas actualmente existentes no cliente, e os novos sistemas a desenvolver no âmbito deste projecto, foi proposta a utiliza¸cão de um Middleware EAI (Enterprise Application Integration) (Figura 2.3). Este proporciona uma camada intermédia para simplificar a integra¸cão e partilha de informa¸cão entre sistemas, aumentando a flexibilidade e a velocidade em que a informa¸cão é partilhada entre as diferentes aplica¸cões e reduzindo o custo total da solu¸cão (nomeadamente ao n´ıvel da manuten¸cão e número de conexões).

Figura 2.3: Arquitectura da solu¸c˜ao

A utiliza¸cão de uma ferramenta EAI, permite virtualizar a camada de integra¸cão entre aplica¸cões através de uma plataforma de distribui¸cão de mensagens. Desta forma, cada aplica¸cão vê um único ponto de integra¸cão com a plataforma EAI, in-dependentemente das aplica¸cões que estão a jusante. A distribui¸cão, transforma¸cão e gestão do processo de transporte e entrega de cada um dos elementos de dados, que fazem parte do fluxo de dados, é da completa responsabilidade desta plataforma simplificando e flexibilizando os pontos de integra¸cão entre as diferentes aplica¸cões. Para implementar o Middleware EAI foi proposto o produto BizTalk Server 2006, cujo modo de funcionamento é apresentado na Figura 2.4.

As integra¸cões baseadas no BizTalk Server 2006 podem ter uma arquitectura de Hub-And-Spoke, em que as aplica¸cões apenas “conhecem e falam” com o Hub, através de um adaptador que é responsável por efectuar as respectivas conversões e/ou mapeamento de dados ou podem ter uma arquitectura ESB (Entreprise Service Bus) numa solu¸cão baseada em WebServices. As integra¸cões são implementadas e

(26)

Figura 2.4: Funcionamento do BizTalk Server 2006

configuradas através do Visual Studio 2005, contendo ainda o BizTalk uma série de ferramentas para administra¸cão (BizTalk Server Administration), monitoriza¸cão (“Health and Activity Tracking”), entre outras. O BizTalk Server usa como suporte aplicacional a Framework .NET.

Este produto tem assim todas as caracter´ısticas para garantir uma fácil inte-gra¸cão entre os sistemas, recorrendo a uma plataforma bastante robusta e flexibili-dade, que potencia a integra¸cão de futuros sistemas que o cliente venha a ter, e/ou permite facilmente altera¸cões à lógica das integra¸cões já desenvolvidas.

Durante a fase de análise, foi identificada a informa¸cão a sincronizar entre os sistemas e ainda identificados a origem e destino dessa informa¸cão. A informa¸cão que cada sistema deve publicar, dá origem a uma ’Interface’. A ’Interface’ publicada por um sistema pode ser subscrita por pelo menos um sistema. Para estabelecer os fluxos de informa¸cão, é criado um outro documento com a ’Interface’ do sistema de origem e as ’Interfaces’ dos sistemas destino que inclui as regras de conversão e/o negócio a aplicar.

De forma a facilitar a implementa¸cão de toda a solu¸cão, foi determinado o padrão Publish - Subscribe como o padrão de dispersão dos diferentes blocos de informa¸cão assente sobre uma comunica¸cão entre os diversos sistemas baseada em mensagens que mapeiam directamente os blocos que informa¸cão a transportar. De notar que esta metodologia promove assim a reutiliza¸cão das mensagens de um sistema a ser consumida por um ou mais sistemas (Figura 2.6).

2.4.1 Ponto de Integra¸

c˜

ao

Para efeitos de implementa¸cão, considera-se um Ponto de Integra¸cão como sendo a unidade básica de um conjunto de integra¸cões. Um Ponto de Integra¸cão, consiste na especifica¸cão dos sistemas de entrada e sa´ıda, ou Publisher e Subscriber, de um bloco

(27)

Figura 2.5: Publish-Subscribe

Figura 2.6: Exemplo gen´erico de uma integra¸c˜ao

de informa¸cão a sincronizar, as regras de transforma¸cão de dados a aplicar, e ainda a sua periodicidade de execu¸cão. (Figura 2.7). Assim, as integra¸cões representam a passagem de informa¸cão entre duas interfaces no m´ınimo. A cada uma, está associado um adaptador o qual representa o meio de comunica¸cão/protocolo com o sistema a que pertence essa interface.

Na qualidade de developer, fui incumbido de implementar os vários PIs. No Biz-Talk Server 2006, a implementa¸cão de um PI corresponde à constru¸cão dos schemas (mensagens) de entrada e sa´ıda do sistemas (Figura 2.8), os mapeamentos (trans-forma¸cão de dados) entre mensagens correspondentes (Figura 2.9), as orquestra¸cões com a lógica de dispersão das mensagens e a configura¸cão dos canais de comunica¸cão (portas e adaptadores).

(28)

Figura 2.7: Processo gen´erico de um ponto de integra¸c˜ao

Publisher Subscriber Integra¸cão Adaptador Pub/Sub Scheduler SAE DW INTEGRAÇ ÃO A ODBC/ODBC Diária 03H00 SAE SGO INTEGRAÇ ÃO A ODBC/ODBC Diária 03H00 ERP DW INTEGRAÇ ÃO B ODBC/ODBC Diária 20H00 ERP SAE INTEGRAÇ ÃO B ODBC/ODBC Diária 20H00 ERP SGO INTEGRAÇ ÃO B ODBC/ODBC Diária 20H00 ERP Planeamento INTEGRAÇ ÃO C ODBC/ODBC Online

Tabela 2.1: Exemplo de um Mapa de Integra¸c˜oes

Execu¸c˜ao dos Pontos de Integra¸c˜ao

Uma integra¸c˜ao pode ser invocada de diferentes modos:

Eventos – ex: trigger associado a uma tabela ou file system o qual envia um evento a notificar o sistema de integra¸c˜ao, o BizTalk Server 2006, da existˆencia de novos dados da interface respectiva;

Scheduling – Atráves da configura¸cão do scheduler (escalonador) do BizTalk Ser-ver 2006 para que este Ser-verifique, com determinada periodicidade, a existência de novos dados. Este modo é também referido como pooling;

Manual – quando uma integra¸cão é invocada a pedido (interven¸cão humana). Para desencadear este processo, foi desenvolvida uma aplica¸cão, o Integration Laun-cher, que invoca uma integra¸cão em concreto (um PI) quando requisitada pelo utilizador (Figura 2.6).

2.4.2 Ferramentas

As ferramentas abaixo descritas foram utilizadas na realiza¸c˜ao do projecto:

Microsoft BizTalk Server 2006 ´

E neste servidor onde residem as aplica¸cões de integra¸cão desenvolvidas. De seguida são apresentados os principais componentes do BizTalk 2006:

Schema – representa a estrutura das mensagens em XML. Um schema pode re-presentar uma ou mais mensagens (Figura 2.8);

(29)

Maps – representa a transforma¸cão a efectuar entre duas mensagens. Contém um Extensible Stylesheet Language (XSL) que inclui as defini¸cões dos mapeamen-tos a efectuar sobre o conteúdo de uma mensagem a passar para outra (Figura 2.9);

Orchestrations – representa o processo implementado;

Pipeline – permite definir as diversas etapas, e sua ordem, a serem executadas aquando da recep¸c˜ao ou envio de uma mensagem (ex: uma etapa pode ser o parsing da mensagem)

Send port groups – é o agrupamento lógico de send ports que podem ser usados para enviar uma determinada mensagem para vários destinos;

Send ports – Objecto que envia mensagens aos quais est˜ao associados a um de-terminado adaptador;

Receive ports – O agrupamento l´ogico de receive location;

Receive locations – Um receive location define um endere¸co especifico (ex: direc-toria, URL) no qual ´e esperado provir mensagens. Em cada receive location esta configurado o pipeline a usar para processar as mensagens;

Message Boxes – contem todas as MessageBox Databases usadas no BizTalk Ser-ver group. Uma mensagem pode passar pela MessageBox mais que uma vez durante a execu¸c˜ao de um processo;

Adapters – Contem todos os send e receive adapters configurados no BizTalk Ser-ver group e associados adapters handlers. Os adaptadores representam os conectores que permitem receber e enviar mensagens entre endpoints;

Microsoft Visual Studio 2005

O IDE de desenvolvimento aonde s˜ao constru´ıdos os diversos componentes do Biz-Talk como os ’Schemas’, ’Mapas’ e ’Orquestra¸c˜oes’.

Microsoft Visual SourceSafe

Sistema de controlo de vers˜oes utilizado.

Microsoft SQL Server 2005

Sistema de Gest˜ao de Base de Dados. Pode ser considerado como um dos sistemas a integrar.

(30)

Oracle 9i

DB2

CVS

O CVS, ou Concurrent Versioning System, é uma ferramenta que faz o rastreio das altera¸cões efectuadas num conjunto de ficheiros permitindo assim a colabora¸cão entre diversos programadores. Foi usado para fazer o controlo de versões dos documentos de especifica¸cão e reporte do estado do projecto.

Figura 2.8: Exemplo de um Schema para BizTalk Server 2006

(31)

Cap´ıtulo 3

Aplica¸

c˜

ao Cliente de

Carregamento Remoto de T´ıtulos

Este cap´ıtulo documenta o tema do central do est´agio, ou seja, ”Smartphones para Identifica¸c˜ao e Pagamentos”.

Primeiro são apresentadas as tecnologias de base para a constru¸cão do protótipo, ”Aplica¸cão Cliente de Carregamento de T´ıtulos”.

Na descri¸cão do protótipo, pretende-se explicar o alinhamento das diferentes tec-nologias que possibilita a constru¸cão de aplica¸cões para identifica¸cão e pagamentos. O desenvolvimento desde projecto teve lugar na Fase 2 do planeamento do estágio (Figura 1.3).

3.1 Objectivo

O projecto integra-se num roadmap de desenvolvimento de inova¸cões e futuros módulos de plataforma de electronic ticketing da Link. Neste âmbito, pretende-se implementar um protótipo de uma aplica¸cão móvel que aceda ao Servidor com Motor de Carregamentos Remotos , para a compra e carregamento de t´ıtulos no SmartPhone.

3.2 Tecnologias e Conceitos Base

3.2.1 Smart Cards

Um Smart Card, chip card ou Integrated Circuit(s) Card (ICC), é definido como sendo um cartão que se assemelha a um cartão de crédito e que tem um circuito inte-grado para armazenar dados. Apesar de existirem inúmeras aplica¸cões, destacam-se duas: cartões de memória, que apenas contém componentes de memoria de arma-zenamento não volátil e por vezes alguma lógica de seguran¸ca e os cartões com microprocessadores, que contêm componentes de memória e microprocessadores.

(32)

A percep¸cão de Smart Card é a de um cartão que contém um microprocessador e que tem um tamanho aproximadamente igual a um cartão de crédito (ou menor, por exemplo, o cartão SIM das redes GSM). As propriedades deste cartão incluem a resistência a intrusão (por exemplo, um sistema de ficheiros seguros, um processa-dor seguro, fazendo uso de criptografia) e a capacidade de fornecer servi¸cos seguros (por exemplo, confidencialidade da informa¸cão guardada em memória). Nem todos os ICCs possuem um microprocessador (por exemplo, cartões de memória), conse-quentemente nem todos os ICCs são necessariamente Smart Cards. Contudo, o uso da terminologia por parte do público em geral é muitas vezes inconsistente.

Contact Smart Cards

Um Smart Card com contacto tem um pequeno chip com cerca de 1,2 cm de diâmetro na parte frontal. Quando é inserido num leitor de cartões apropriado, o chip entra em contacto com os conectores electrónicos que conseguem ler e actualizar a informa¸cão do chip.

Os standards ISO/IEC 7816 e ISO/IEC 7810 definem:

• A forma f´ısica.

• A posi¸cão f´ısica e forma dos conectores eléctricos. • As caracter´ısticas eléctricas.

• Os protocolos de comunica¸c˜ao.

• O formato dos comandos enviados para o cart˜ao, bem como o das respostas por ele retornadas.

• A robustez do cart˜ao. • A funcionalidade.

Os cartões deste tipo não contêm bateria, a energia é fornecida pelo leitor.

Contactless Smart Cards

Outro tipo de cartões são os Smart Cards sem contacto, no qual o chip comunica com o leitor através da introdu¸cão da tecnologia de identifica¸cão por rádio frequência, RFID, com velocidade na ordem dos 106 a 848 kbit/s. Estes cartões apenas neces-sitam de serem aproximados a uma antena para realizarem uma transaçcão. Este tipo de cartões são muitas vezes utilizados quando as transaçcões têm que ser pro-cessadas rapidamente ou sem mãos, tais como sistemas de trânsito em massa (como as entradas e sa´ıdas do metro), onde estes podem ser usados sem a necessidade de retirá-los da carteira.

(33)

Cap´ıtulo 3. Aplica¸c˜ao Cliente de Carregamento Remoto de T´ıtulos 19

O standard para a comunica¸cão deste tipo de cartões é o ISO/IEC 14443, datado de 2001. Este standard define dois tipos de cartões sem contacto (A e B), permite comunica¸cões até 10 cm de distância do leitor. Houve propostas para o ISO 14443 do tipo C, D, E e F mas estes foram rejeitados pelo ISO (International Organization for Standardization). Uma alternativa ao standard dos cartões sem contacto é o ISO 15693, que permite comunica¸cões a uma distancia de 50 cm.

Um exemplo do uso deste tipo tecnologia é o projecto LisboaViva que utiliza estes cartões para controlar as entradas e sa´ıdas na rede de transportes públicos de Lisboa.

Vantagens e Desvantagens dos Smart Cards

A utiliza¸cão de Smart Cards trás inúmeras vantagens, não só para o utilizador, como para a seguran¸ca dos sistemas que os utilizam e o poder computacional.

As vantagens para o utilizador são a facilidade de usar e ter informa¸cão portátil, podendo os dados do utilizador ficarem guardados no cartão.

Ao n´ıvel da seguran¸ca, as vantagens são inúmeras. A informa¸cão armazenada no cartão, pode estar protegida para leitura e/ou escrita através de um código PIN ou dados biométricos. Os dados guardados, por sua vez, podem estar encriptados. Cada cartão possui um número de série único.

O poder computacional é grande, pois este tipo de cartões, têm capacidade de processamento e de comunica¸cão com outros terminais. Esta comunica¸cão é feita através da liga¸cão a um leitor de Smart Cards, podendo a informa¸cão e aplica¸cões em causa, serem actualizadas, sem haver a necessidade de serem emitidos novos cartões ou bilhetes.

Apesar dos Smart Cards apresentarem inúmeras vantagens, também têm algu-mas desvantagens. Estas resultam principalmente da falta de interoperabilidade ao n´ıvel de cartões e da falta de standards ao n´ıvel do desenho.

A falta de interoperabilidade resulta das diferentes normaliza¸cões do modelo de dados, falta de standards ao n´ıvel da comunica¸cão com o exterior e diferentes conjuntos de instru¸cões (instruction set ) dos muitos tipos de cartões existentes.

As desvantagens apresentadas, impossibilita a utiliza¸cão do mesmo cartão em diferentes pa´ıses ou aplica¸cões.

3.2.2 Tecnologia Calypso

Um cartão Calypso é um Smart Card que permite a verifica¸cão e transferência de direitos de transporte, tal como os passes/t´ıtulos de transportes do metropolitano de Lisboa. O cartão pode conter várias informa¸cões, tais como, informa¸cão acerca do utilizador (dono do cartão), o último acesso ao cartão, etc.

(34)

Como o direito de entrada, por exemplo numa rede do metro, acarreta valores monetários, a sua utiliza¸cão é protegida por algoritmos, prevenindo assim poss´ıveis forjadores de produzirem cartões falsos ou carregar um cartão sem a devida auto-riza¸cão.

Os algoritmos criptográficos são baseados em chaves secretas, guardadas dentro do cartão, num SAM (Secure Application Module). O SAM está sempre presente no equipamento que interactua com os cartões (ou ligado remotamente ao equi-pamento). Depois da manufactura, o cartão é personalizado escrevendo-se no seu interior as chaves secretas e os dados.

Os cartões Calypso, podem, no entanto, ser utilizados para outras aplica¸cões, podendo ter outras caracter´ısticas que estendam as suas capacidades, para além das especifica¸cões Calypso. Diferentes tipos de cartões compat´ıveis com a norma Calypso podem fornecer diversos n´ıveis de seguran¸ca.

Os cartões Calypso, permitem a utiliza¸cão do algoritmo DES (um método de encriptar informa¸cão), com chaves secretas de 64 bits, ou o uso do algoritmo DESX (uma variante do algoritmo referido acima), com chaves secretas de 128 bits, ou ainda, o algoritmo triplo DES, com chaves secretas de 112 bits, oferecendo alto n´ıvel de seguran¸ca contra a manufactura de cartões falsos e carregamentos não autoriza-dos.

3.2.3 Near Field Communication

Near Field Communication, ou NFC, é uma nova tecnologia de comunica¸cão sem fios, de curto alcance, que evoluiu a partir da combina¸cão de tecnologias de identifica¸cão e inter-liga¸cão sem contacto, já existentes. Opera numa frequência de 13.56 MHZ, a uma distância de poucos cent´ımetros entre os dispositivos. As camadas subjacentes a esta tecnologia são baseadas nos standards ISO, ECMA e ETSI.

Permite, de forma simples e segura, uma interaçcão bi-direccional entre disposi-tivos permitindo ao utilizador efectuar transaçcões sem contacto, aceder a conteúdo digital e conectar dispositivos com um ‘simples toque’.

Os RFID e Smart Cards sem contacto, são sistemas que já se encontram am-plamente dispon´ıveis num variado leque de indústrias e são usados para diferentes propósitos. Esses sistemas são a combina¸cão de um dispositivo de leitura/escrita para um smart card e um transponder (transmissor-receptor). Existe sempre uma clara separa¸cão funcional entre os dois dispositivos que por vezes, causa limita¸cões `

a constru¸c˜ao de novas aplica¸c˜oes.

O seu modo de funcionamento é muito similar ao dos RFIDs. O leitor, quando activado, emite um sinal que alimenta o microchip da tag e permite a leitura de pequenas quantidades de dados armazenados na tag. NFC é diferente das outras tecnologias sem contacto e RFID uma vez que opera a distâncias mais curtos e

(35)

interliga dois dispositivos. Integra dispositivos de leitura/escrita e o transponder num ´unico circuito.

As diversas fun¸cões no chip podem ser controladas e activadas por software. Assim, pode actuar tanto como dispositivo de leitura/escrita bem como tag RFID. Quando combinado com dispositivos móveis, abre portas para um novo mundo de aplica¸cões a construir. Os seus principais benef´ıcios e potencialidades são:

• Usabilidade melhorada e experiˆencia de utiliza¸c˜ao mais rica.

• F´acil acesso a servi¸cos e conte´udo disponibilizados por dispositivos f´ısicos • Controlo de acessos e Ticketing

• Partilha de conteúdo digital entre dispositivos através da sua aproxima¸cão • Capacidade de Pagamentos e Ticketing

A Capacidade de Pagamentos e Ticketing ´e de crucial importˆancia porque repre-senta a tecnologia facilitadora da ideia para o projecto.

3.2.4 No¸

c˜

ao de Framework

No desenvolvimento de software, uma framework, ou arcabou¸co, ´e uma estrutura de suporte definida em que um outro projecto de software pode ser organizado e desenvolvido. Uma framework pode incluir programas de suporte, bibliotecas de c´odigo, linguagens de script e outros softwares para ajudar a desenvolver e juntar diferentes componentes de um projecto.

As frameworks são projectadas com a inten¸cão de facilitar o desenvolvimento de software, habilitando os designers e programadores a perderem menos tempo com detalhes de baixo n´ıvel do sistema, preocupando-se mais com a determina¸cão das exigências do software.

3.2.5 JSR-172: J2ME

TM

Web Services Specification

O objectivo global da JSR-172 é acrescentar duas novas capacidades à plataforma J2ME que são:

• acesso remoto a web services baseados no paradigma SOAP/XML • parse de dados em XML

Para atingir esse objectivo global, foram especificados dois pacotes (packages) opcionais:

(36)

1. um pacote adicional para o parse de dados em XML. O mais provável, é que os dados estruturados enviados para os dispositivos móveis pelas aplica¸cões existentes estejam sob a forma XML. De forma a evitar a inclusão de código que processa-se esses dados em cada aplica¸cão móvel, é desejável a defini¸cão de pacotes adicionais que pudessem ser acrescentados na plataforma.

2. Criar um pacote opcional que facilitasse o acesso aos web services baseados em XML, a partir dos perfis CDC e CLDC. Onde for poss´ıvel deverá ser evitado a cria¸cão de novos formatos e protocolos de comunica¸cão e reutilizar os standards existentes.

A Figura 3.1 ilustra a aplica¸c˜ao t´ıpica baseada na JSR-172.

Figura 3.1: Aplica¸c˜ao T´ıpica baseada na JSR172

3.2.6 JSR-177: Security and Trust Services API for J2ME

(SATSA)

A especifica¸cão Security and Trust Services API (SATSA), define os pacotes opcio-nais para a plataforma Java 2 Micro Edition (J2ME).Esta especifica¸cão, foi elabo-rada em resposta ao pedido de especifica¸cão, Java Specification Request 177 (JSR-177). O seu propósito, é especificar uma coleçcão de APIs que ofere¸cam servi¸cos de seguran¸ca (autenticidade, integridade e confidencialidade) integrados com um Ele-mento Seguro (ES). Um ES, é um componente do dispositivo com J2ME e apresenta os benef´ıcios que se seguem:

• Armazenamento seguro para proteçcão dos dados sens´ıveis como chaves pri-vadas, chaves públicas, credenciais de acesso a servi¸cos, informa¸cão pessoal, entre outros;

(37)

• Opera¸c˜oes criptogr´aficas para suportar protocolos de pagamentos, integridade e confidencialidade dos dados

• Ambiente de execu¸cão seguro para incluir funcionalidades de seguran¸ca. Aplica¸cões J2ME baseiam-se nessas funcionalidades para tratar servi¸cos de valor acrescen-tado como identifica¸cão e autentica¸cão, pagamentos e aplica¸cões de fidelidade.

Um elemento seguro pode tomar várias formas. Os smartcards são os mais usados para implementar este tipo de artefactos. Encontram-se dispon´ıveis em telemóveis GSM sob a forma de cartões SIM, UICC para telemóveis 3G, e RUIM para telemóveis CDMA. Por exemplo, nas redes de telecomunica¸cões GSM, os dados de autentica¸cão na rede de um dado operador são escritos no SIM bem como informa¸cão pessoal do subscritor. Quando o SIM é inserido no telemóvel, este fica pronto a funcionar na rede do operador.

Alternativamente, um ES pode ser implementado por software. Esta especi-fica¸cão não exclui qualquer implementa¸cão de Elementos Seguros apesar de alguns pacotes da API estarem optimizados para smartcards.

A API endere¸ca v´arias necessidades, satisfeitas por pacotes especificados para o efeito:

SATSA-APDU – Este pacote define uma API para suportar a comunica¸cão com smart card com recurso ao protocolo APDU. Os Smart Cards oferecem um am-biente seguro de programa¸cão. É o tipo de ES mais usado e para implementar servi¸cos de seguran¸ca.

SATSA-PKI – Este pacote opcional define uma API para suportar assinaturas digitais ao n´ıvel da aplica¸cão e gestão básica de credenciais do utilizador. Para potenciar uma maior reutiliza¸cão, esta API é independente do tipo de ES utilizado. As assinaturas digitais usadas para autenticar os utilizadores ou autorizar transaçcões que utilizem uma criptografia de chave pública.

SATSA-CRYPTO – Este pacote opcional é um sub-conjunto da API de crip-tografia do versão J2SE. Providencia opera¸cões básicas de criptografia para suportar Message Digest, verifica¸cão de assinaturas , cifrar e decifrar blocos de dados.

SATSA-JCRMI – Este pacote define a API cliente Java Card RMI1 que permite a uma aplica¸c˜ao J2ME invocar um m´etodo de um objecto Java Card remoto.

1_JavaCardRMI _est´_a _definida _na _especifica¸_c˜_ao _da _plataforma _Java _Card _2.2

(38)

3.2.7 No¸

c˜

ao de Stub

Num ambiente distribu´ıdo, as aplica¸cões podem aceder a servi¸cos que poderão estar situados local ou remotamente. Dado que um servi¸co só pode ser acedido, através da invoca¸cão de uma das suas opera¸cões, o acesso remoto requer um mecanismo que suporte a execu¸cão remota das opera¸cões.

Pode observar-se esquematicamente este conceito na Figura 3.2.

Figura 3.2: Conceito de Procedimentos num Programa Distribu´ıdo

Para que este conceito seja poss´ıvel, é necessária a implementa¸cão de um proto-colo de comunica¸cão responsável pela correcta transferência de controlo entre quem invoca a opera¸cão (o cliente) e o servidor remoto que irá executar a opera¸cão pre-tendida. O seu modelo de execu¸cão está esquematicamente representado na Figura 3.3.

Figura 3.3: Modelo de Execu¸c˜ao

Para além do controlo das opera¸cões, este deve suportar a transferência de quais-quer argumentos necessários à execu¸cão da opera¸cão e do retorno para o cliente de um qualquer resultado. Este mecanismo é denominado “chamada a fun¸cões remo-tas” (RPC – remote procedure call) e representa uma extensão da tradicional no¸cão de chamada a fun¸cões para um ambiente distribu´ıdo.

Conceptualmente, uma aplica¸cão distribu´ıda consiste em vários fragmentos dis-tintos, divididos entre quem chama a fun¸cão (cliente) e um servidor remoto

(39)

res-Cap´ıtulo 3. Aplica¸c˜ao Cliente de Carregamento Remoto de T´ıtulos 25

ponsável pela execu¸cão local da opera¸cão invocada. Estes fragmentos são conhecidos como: o cliente, o stub do cliente, o transporte RPC, o stub do servidor e o servidor. A representa¸cão esquemática destes fragmentos aparece representada na Figura 3.4

Figura 3.4: Passos de uma Chamada Remota de Procedimentos

O cliente e servidor são ambos desenhados e implementados como se as aplica¸cões fossem para correr num ambiente centralizado tradicional. A fun¸cão dos stubs do cliente e servidor é “esconder” o mais poss´ıvel a distribui¸cão do sistema.

Princ´ıpios da gera¸c˜ao do Stub

Como o desenvolvimento manual de stubs pode ser fastidiosa e complicada, este processo pode ser automatizado através de um gerador automático de código.

O gerador produz o código do stub, na linguagem desejada, através de uma linguagem de defini¸cão de interfaces (IDL-Interface Definition Language), baseada na interface entre o cliente e servidor.

Cada tipo de IDL tem as suas vantagens e desvantagens. Uma IDL que seja independente da linguagem de programa¸c˜ao pode permitir que diferentes partes da aplica¸c˜ao distribu´ıda sejam programadas em diferentes linguagens, adequando-se `

a tarefa em causa. Além disso, como estas IDL’s são tipicamente mais restritivas, podem incutir no programador uma abstraçcão a n´ıvel das diferen¸cas existentes entre o processamento local e remoto e proibir o uso de certos construtores, normalmente dispon´ıveis nas linguagens de programa¸cão. Podem ainda aumentar a linguagem com funcionalidades não dispon´ıveis à partida; por exemplo, permitindo o uso de novos tipos como strings e arrays dinâmicos, ou construtores como os de tratamento de excep¸cões.

Contudo, as desvantagens são que o programador tem de mapear a interface original, codificada na linguagem definida, para a IDL utilizada, antes de poder executar o gerador do stub, perdendo assim alguma transparência. Esta alternativa torna também poss´ıvel que a IDL não corresponda ao que está na realidade imple-mentado, caso se altere uma independentemente da outra. Existe ainda o problema

(40)

de muitos sistemas de IDL necessitarem que o programador escreva código relati-vamente diferente para o servidor (alterando, por exemplo, o nome das fun¸cões), comparativamente ao já existente na solu¸cão original, não distribu´ıda.

Por outro lado, uma IDL especifica à linguagem de programa¸cão utilizada, ga-nha em termos de transparência e a interface e implementa¸cão não divergem tão facilmente do que com uma IDL separada. Infelizmente, essa transparência pode induzir o programador a uma falsa sensa¸cão de seguran¸ca, dado que nem toda a linguagem produzida será distribu´ıda e os custos inerentes a essa distribui¸cão não são óbvios.

De modo geral, a gera¸cão de stubs envolve vários problemas que assentam prin-cipalmente na inexistência de uma memória partilhada, entre o cliente e o servidor. Desta situa¸cão podem advir os seguintes problemas:

• Heterogeneidade das máquinas. Diferentes máquinas podem ter diferentes representa¸cões binárias dos variados tipos primitivos. Por exemplo, diferente ordena¸cão de bytes e representa¸cão de v´ırgulas flutuantes; diferentes precisões aritméticas (16 vs. 32 bit); representa¸cões de v´ırgulas pouco usuais, etc.

A solu¸cão mais comum para este problema requer que os stubs do cliente e servidor convertam o formato nativo para um formato comum (por exemplo, ASN.1 ou XDR) antes da transmissão. Esta conversão tem custos considerados e é desnecessária entre máquinas do mesmo tipo. Contudo é uma solu¸cão simples que resolve os problemas existentes num ambiente heterogéneo.

• Transferência de parâmetros e tipos. Diferentes linguagens apresentam dife-rentes semânticas na passagem de parâmetros, como as invoca¸cões por valor e por referência. Os procedimentos remotos for¸cam normalmente um processo de “copy-in”, “copy-out” para a passagem de parâmetros, que nem sempre coincide com a semântica do mecanismo local para a passagem de parâmetros. Além disso, alguns tipos de argumentos podem ter de ser completamente proi-bidos, por exemplo, procedimentos.

• Estruturas que se auto referenciam. Muitas das linguagens de programa¸cão modernas, permitem a cria¸cão de estruturas de dados que contêm apontadores para outras estruturas de dados. Esta funcionalidade, dota o programador de um mecanismo bastante flex´ıvel, mas causa problemas a n´ıvel da gera¸cão do stub que tem de fazer o marshall de toda a estrutura, quando apenas um dos seus elementos é passado como parâmetro. Estruturas circulares são ainda mais complicadas de gerir.

• Falhas. As falhas num RPC s˜ao ainda mais complicadas de gerir do que as falhas a n´ıvel de um procedimento local, uma vez que localmente, estas

(41)

só acontecem quando a globalidade da aplica¸cão falha ou quando o erro é esperado. Por sua vez, um procedimento executado remotamente, pode falhar por motivos completamente alheios ao cliente de diversas formas inesperadas.

3.2.8 Factory Design Pattern

O padrão “Factory Design Pattern” é um padrão de desenho das linguagens de pa-radigma Object-Oriented. Insere-se no conjunto de padrões de cria¸cão ,‘ ‘Creational Patterns”. Este padrão, retorna uma entre muitas instâncias de classes poss´ıveis, dependendo das parâmetros passados. Normalmente, todas as classes que retorna, têm uma classe ou interface pai em comum mas realizam as mesmas tarefas de forma diferente e optimizadas para diferentes tipos de dados.

Figura 3.5: Diagrama UML “Factory Pattern”

Creator – declara o factory method (método de fabrica¸cão) que retorna o objecto da classe Product (produto). Este elemento também pode definir uma im-plementa¸cão básica que retorna um objecto de uma classe ConcreteProduct (produto concreto) básica;

ConcreteCreator – sobre-escreve o factory method e retorna um objecto da classe ConcreteProduct;

Product – define uma interface para os objectos criados pelo factory method;

ConcreteProduct – uma implementa¸c˜ao para a interface Product.

Este padrão é muito utilizado em frameworks para definir e manter rela¸cões entre objectos.

(42)

3.3 Situa¸

c˜

ao Inicial

Uma vez que se trata de um projecto de desenvolvimento de inova¸cões e futuros módulos da plataforma de electronic ticketing, o desejável seria desenvolver um protótipo cuja implementa¸cão se encontre o mais próximo poss´ıvel da realidade, ou seja, uma aplica¸cão móvel instalada em um smartphone que acedesse ao Servidor com Motor de Carregamento Remoto de T´ıtulos.

Figura 3.6: Arquitectura da situa¸c˜ao inicial

Para esse efeito, o smartphone deve satisfazer os seguintes requisitos: disponi-bilizar interface NFC, suportar a plataforma J2ME e implementar as especifica¸cões JSR 172 (seçcão 3.2.5) e JSR177 (seçcão 3.2.6 ). Quando carregados os t´ıtulos, os testes poderiam ser feitos nas aplica¸cões da link para verifica¸cão dos contratos, validando assim a prova-de-conceito (proof-of-concept ) a efectuar.

3.4 Situa¸

c˜

ao Actual

Uma vez que não foi poss´ıvel recepcionar o dispositivo com esses requisitos, no per´ıodo calendarizado para a execu¸cão do projecto, a solu¸cão passou por simular todo o processo recorrendo ao emulador de um telemóvel, propriamente o emula-dor do Wireless Toolkit da J2ME API. Ainda que simulado, todo o processo foi constru´ıdo com o factor ‘proximidade da realidade’ sempre em mente como se pode verificar mais à frente.

3.5 Implementa¸

c˜

ao

3.5.1 Interface APDUConnection

Esta interface define uma liga¸cão APDUConnection (Application Protocol Data Unit). As aplica¸cões J2ME podem usar esta liga¸cão para comunicar com aplica¸cões

(43)

Figura 3.7: Arquitectura da situa¸c˜ao final

em smart cards com através do protocolo APDU. O standard ISO 7816-4 define uma APDU como um protocolo de n´ıvel da aplica¸cão entre um smart card e uma aplica¸cão no dispositivo. Existem dois tipos de mensagens APDU: ’APDU de Comando’ e ’APDU de Resposta’. APDUs de Comando são enviadas pelas aplica¸cões J2ME para os smart cards. ’APDUs de Resposta’ são as mensagens recebidas dos smart cards.

´

E esta interface que deve ser implementada para o envio das ’APDUs de Co-mando’ e recep¸cão das ’APDUs de Resposta’. Utilizando esta abordagem, deixa de ser necessária qualquer altera¸cão ao código aquando da instala¸cão da Midlet num smartphone com interface NFC.

Em seguida é apresentado o sumário dos métodos especificados nesta interface.

• byte[] changePin(intpinID) ´

E um método de alto n´ıvel que permite às aplica¸cões J2ME solicitarem ao utilizador o código PIN para altera¸cão e enviar ao cartão

• byte[] disablePin(int pinID) ´

E um método de alto n´ıvel que permite às aplica¸cões J2ME solicitarem ao utilizador o código PIN a ser desabilitado e enviar para o cartão.

• byte[] enablePin(int pinID) ´

E um método de alto n´ıvel que permite às aplica¸cões J2ME solicitarem ao utilizador o código PIN a ser reabilitado e enviar para o cartão.

• byte[] enterPin(int pinID) ´

E um método de alto n´ıvel que permite às aplica¸cões J2ME solicitarem ao utilizador o código PIN a ser verificado e enviar para o cartão.

(44)

Método para enviar uma ’APDU Commando’ para uma aplica¸cão do cartão e receber a ’APDU Resposta’.

• byte[] getATR() Retorna a mensagem Answer To Reset (ATR) enviada pelo cart˜ao em resposta da opera¸c˜ao de reset

• byte[] unblockPin(int blockedPinID,int unblockingPinID) ´

E um método de alto n´ıvel que permite às aplica¸cões J2ME solicitarem ao utilizador a introdu¸cão do código PIN de desbloqueio e o novo valor do código PIN bloqueado para enviá-los ao cartão.

´

E esta interface que vai encapsular o acesso ao leitor e ao cartão por parte da Midlet. Com esta abordagem, é poss´ıvel simular o acesso ao cartão SIM e ainda instalar a aplica¸cão num smartphone com interface NFC, sem qualquer altera¸cão ao código desenvolvido.

Na implementa¸cão desta interface foi utilizado o padrão de desenho Factory Method (seçcão 3.2.8). A (Figura 3.8) ilustra a aplica¸cão concreta do padrão de desenho no modelo de classes da aplica¸cão.

Figura 3.8: Aplica¸c˜ao do padr˜ao Factory

Isto facilita a constru¸cão de várias classes de comunica¸cão com os diferentes lei-tores suportados pelo Software de Interoperabilidade para Terminais sem a altera¸cão das aplica¸cões cliente uma vez que todas as classes implementam a mesma interface.

(45)

3.5.2 Arquitectura da Solu¸

c˜

ao

Analisando a Figura ?? do Apˆendice B (Anexo Confidencial) com a arquitectura da Aplica¸c˜ao Cliente tem-se que:

Emulador – Corresponde ao emulador do Wireless Toolkit da Sun. Simula o smartphone com interface NFC.

JSR 172 — A implementa¸cão de referência da interface JSR172 (Seçcão 3.2.5). Foi usada para a invoca¸cão dos métodos do Servidor com Motor de Carrega-mento Remoto de T´ıtulos. Como anteriormente referido, esta API permite às aplica¸cões móveis o consumo de Web Services.

Stubs -– Classes com toda a lógica de empacotamento e desempacotamento dos métodos e estruturas de dados do Servidor com Motor de Carregamento Re-moto de T´ıtulos. Para mais informa¸cões sobre stubs ver seçcão 3.2.7.

APDU Connection — Implementa¸cão da Interface APDUConnection da especi-fica¸cão JSR177 (seçcão 3.2.6)para a comunica¸cão com os cartões 3.5.1. Aqui foi desenvolvido todo o código de inicializa¸cão dos leitores, ou seja abertura das portas COM necessárias. Deve ser transparente à Midlet para que possa suportar diferentes tipos de leitores. Isto torna a lógica da aplica¸cão inde-pendente do dispositivo usado. Consequentemente, o envio de APDUs para o cartão SIM , por parte da Midlet é concretizado de forma simulada.

Midlet — Que corresponde à aplica¸cão J2ME com toda a lógica de instancia¸cão do “Stubs”, ’APDUConnection’ e invoca¸cão dos métodos do Servidor com Motor de Carregamento Remoto de T´ıtulos. Serve de intermediário entre o Cartão e o Servidor para a troca de APDUs.

3.5.3 Modo de Funcionamento

A Figura ?? do Apêndice B (Anexo Confidencial) ilustra o modo de funciona-mento da aplica¸cão para o carregamento e valida¸cão de contratos.

1. Invoca¸c˜ao do web method ’Carregar’ ou ’Validar’ contracto

2. resposta com identificador do cliente (ID)

3. Troca de APDUs

(a) A midlet, com o ID, pede novo comando a invocar no cart˜ao (APDU Comando)

(46)

(c) Midlet envia APDU Commando para o Cart˜ao e recebe APDU Resposta (d) Midlet envia APDU Resposta para o Servidor com Motor de

Carrega-mento Remoto de T´ıtulos

4. Midlet termina a comunica¸c˜ao com o servidor.

3.6 Limita¸

c˜

oes Identificadas

Durante a fase de desenvolvimento da aplica¸cão, surgiram algumas limita¸cões refe-rentes às APIs Java, nomeadamente na API JSR-172 (Seçcão 3.2.5). Essas limita¸cões estão intrinsecamente ligadas à limitada capacidade de processamento e memória dos dispositivos móveis facto que impede, em alguns casos, a constru¸cão de APIs tão poderosas como no caso das APIs que correm nas aplica¸cões em PCs convencionais. Neste projecto em concreto, a limita¸cão emergente tem a haver com a API de parse de dados em XML que não suporta alguns tipos de dados.

A solu¸cão passou pela redefini¸cão das estruturas retornadas pelo Servidor com Motor de Carregamento Remoto de T´ıtulos, de modo a circunscrever as limita¸cões apresentadas em seguida:

O estilo dos atributos O estilo de codifica¸cão dos atributos deve ser do tipo do-cument e não RPC. Para Web Services de acesos móvel, a implementa¸cão JAX-RPC deve usar o estilo Document/literar para o mapeamento entre o WSDL do servi¸co e a representa¸cão Java correspondente. Isto constitui um grave problema porque a maior parte dos servi¸cos estão constru´ıdos com RPC quando a API JSR-172 suporta apenas o tipo Document.

Tipos de Dados a evitar Tipos numéricos sem sinal tais como, ”xsd:unsignedInt”, ”xsd:unsignedLong”, ”xsd:unsignedShort”, e ”xsd:unsignedByte”, são os exem-plos t´ıpicos. Em .NET, os tipos “uint”, “ulong”, ”ushort”, e ”ubyte”, mape-amento directamente os tipos xsd supracitados, mas a linguagem Java não tem tios numéricos sem sinal. Por uma questão de interoperabilidade, não devem ser expostos métodos com esses tipos numéricos. Pode ser criados métodos sob a forma de um Wrapper a expor e transmitir esses dados como ”xsd:string”(usando System.Convert.ToString em C#).

Para os tipos ”xsd:decimal”, ”xsd:double”, and ”xsd:float”, cada plataforma tem diferentes n´ıveis de precisão. Como resultado, pode ocorrer a perde de precisão na conversão desses tipos entre plataformas.

O tipo ”xsd:anyType”,ou seja, Object, representa o maior problema porque n˜ao ´e poss´ıvel criar um mapeamento entre qualquer objecto proveniente do Web Service, numa estrutura de dados espec´ıfica no cliente.

(47)

Cap´ıtulo 4

Servi¸

cos do Motor de

Carregamento Remoto de T´ıtulos

O desenvolvimento desde projecto teve lugar na Fase 3 do planeamento do est´agio (Figura 1.3).

4.1 Objectivo

Este projecto, tem por objectivo a constru¸cão dos ”Servi¸cos do Motor de Car-regamento Remoto de T´ıtulos”, (SMCRT). Deve ser implementado sob a forma de um Web Service. Os métodos a disponibilizar são os necessários tanto para configura¸cão dos leitores, como para interagir com os cartões e SAMs.

Uma vez conclu´ıdo, irá permitir às aplica¸cões cliente operarem com os leitores sem a inclusão da camada de negócio do Software de Interoperabilidade para Ter-minais na máquina hospedeira da aplica¸cão cliente. Ao centralizar a acesso a esta camada do Software de Interoperabilidade para Terminais, a manuten¸cão da mesma pode ser feita de forma transparente para as aplica¸cões cliente sem necessidade de reinstala¸cão da mesma nas diferentes máquinas. Assim, as aplica¸cões cliente neces-sitarão apenas de um sub-conjunto do ”Software de Interoperabilidade para Terminais”(SIT), concretamente o N´ıvel Leitor.

4.2 An´

alise do problema

Inicialmente (Figura 4.1), prevê-se que uma aplica¸cão que utilize o SIT, possua uma réplica integral (todas os n´ıveis) da mesma instalada na máquina respectiva para a invoca¸cão de comandos no cartão , acesso e configura¸cão dos leitores. Isto implica que cada altera¸cão efectuada no N´ıvel de Negócio do Software deva ser propagada por todas as aplica¸cões que a utilizem.

Para facilitar a inclusão de altera¸cões à camada de negócio e resolver o problema da propaga¸cão das suas actualiza¸cões, sentiu-se a necessidade de separar esta

(48)

Figura 4.1: Solu¸c˜ao Inicial

mada das restantes, a ser disponibilizada num servi¸co web com os m´etodos para a configura¸c˜ao dos leitores com ilustrado na Figura 4.2.

Figura 4.2: Solu¸c˜ao Pretendida

4.2.1 Software de Interoperabilidade para Terminais

O Software de Interoperabilidade para Terminais é responsável por disponibilizar métodos de alto n´ıvel dos cartões e tickets, que garantem a independência dos for-matos e funcionalidades básicas entre a aplica¸cão, e o leitor utilizados.

Neste trabalho só foram utilizadas duas fam´ılias de cartões, que utilizam a tecno-logia Calypso para garantir a seguran¸ca dos mesmos. A camada superior do SIT não tem qualquer conhecimento dos diversos tipos de cartões, sendo este conhecimento adquirido somente no N´ıvel Leitor.

O N´ıvel Leitor, corresponde a parte de uma camada interna do SIT. Este n´ıvel implementa fun¸cões de gestão ao n´ıvel da comunica¸cão entre o cartão e o termi-nal/leitor utilizados.

A interface disponibilizada por este n´ıvel independente do leitor, representando uma camada de abstraçcão que torna mais fácil o processo de integra¸cão com dife-rentes leitores.

Neste âmbito, existem dois tipos de métodos: o primeiro, é referente à lógica de negócio e contem, por exemplo, o método para preparar o leitor, ou seja, a