faculdade de ciˆencias -...

Universidade de LisboaFaculdade de Ciencias

Departamento de Informatica

SMARTPHONES PARA IDENTIFICACAO E

PAGAMENTOS

Ricardo Goncalves de Santa Ana

Mestrado em Engenharia Informatica

2007

Universidade de LisboaFaculdade de Ciencias

Departamento de Informatica

SMARTPHONES PARA IDENTIFICACAO E

PAGAMENTOS

Ricardo Goncalves de Santa Ana

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

Mestrado em Engenharia Informatica

2007

Declaracao

Ricardo Goncalves de Santa Ana, aluno no 29191 da Faculdade de Ciencias da

Universidade de Lisboa, declara ceder os seus direitos de copia sobre o seu Relatorio

de Projecto em Engenharia Informatica, intitulado ”Smartphones para Identificacao

e Pagamentos”, realizado no ano lectivo de 2006/2007 a Faculdade de Ciencias da

Universidade de Lisboa para o efeito de arquivo e consulta nas suas bibliotecas e

publicacao do mesmo em formato electronico na Internet.

FCUL, 17 de Setembro de 2007

Joao Miguel Correia da Silva Carreira Almeida, supervisor do projecto de Ri-

cardo Goncalves de Santa Ana, aluno da Faculdade de Ciencias da Universidade de

Lisboa, declara concordar com a divulgacao do Relatorio do Projecto em Engenharia

Informatica, intitulado ”Smartphones para Identificacao e Pagamentos”.

Lisboa, 17 de Setembro de 2007

Nota sobre Confidencialidade

Este documento representa a versao publica do relatorio ”Smartphones para

Identificacao e Pagamentos”.

Nesta versao, a informacao considerada confidencial, por parte da Instituicao de

Acolhimento do Projecto, foi omitida. No entanto, o presente relatorio foi elaborado

com isto em mente para que seja possıvel captar a visao geral do trabalho realizado

e as tecnologias envolvidas neste projecto bem como os principais problemas envol-

vidos nos diversos cenarios.

Para esse efeito, toda a informacao confidencial foi devidamente assinalada no

relatorio e colocada em um anexo, o B, omitido nesta versao do relatorio.

Resumo

Este documento descreve o projecto realizado no ambito da disciplina Projecto em

Engenharia Informatica do Mestrado em Engenharia Informatica da Faculdade de

Ciencias 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 cartoes inteligentes, apesar de nao serem uma novidade tecnologica, comecam

agora a chegar ao domınio das aplicacoes do grande publico, nomeadamente na area

bancaria e da identificacao pessoal. Estes dispositivos, que para muitos ainda sao

uma pequena evolucao dos cartoes com banda magnetica, sao reais computadores

que a progressao da tecnologia de micro electronica ira dotar rapidamente de capaci-

dade de processamento e memoria, possibilitando o armazenamento e tratamento de

mais informacao, e sobretudo permitindo a sua interligacao atraves de um crescente

numero de tecnologias de comunicacao. Os cartoes nas suas multiplas vertentes de

Smart Card, RFID e dispositivos moveis, podem tornar-se dispositivos capilares nas

futuras redes permitindo identificar, localizar, autenticar e armazenar informacao

de pessoas, contratos ou dos mais diversos objectos.

i

Conteudo

Lista de Figuras vi

1 Introducao 1

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Contexto Cientıfico e Tecnologico . . . . . . . . . . . . . . . . . . . . 1

1.3 Objectivos do estagio . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Organizacao e Metodologia . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.1 A Link Consulting . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5 Planeamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.6 Organizacao 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 Solucao . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.1 Ponto de Integracao . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.2 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Aplicacao 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 Nocao de Framework . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.5 JSR-172: J2METMWeb Services Specification . . . . . . . . . 21

3.2.6 JSR-177: Security and Trust Services API for J2ME (SATSA) 22

3.2.7 Nocao de Stub . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.8 Factory Design Pattern . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Situacao Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

iii

3.4 Situacao Actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5.1 Interface APDUConnection . . . . . . . . . . . . . . . . . . . 28

3.5.2 Arquitectura da Solucao . . . . . . . . . . . . . . . . . . . . . 31

3.5.3 Modo de Funcionamento . . . . . . . . . . . . . . . . . . . . . 31

3.6 Limitacoes Identificadas . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Servicos do Motor de Carregamento Remoto de Tıtulos 33

4.1 Objectivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Analise do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1 Software de Interoperabilidade para Terminais . . . . . . . . . 34

4.2.2 Metodos a Disponibilizar . . . . . . . . . . . . . . . . . . . . . 35

4.3 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Remote Coupler 39

5.1 Objectivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 Situacao Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2.1 Visao Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.3 Solucao pretendida . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.4 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6 Conclusao 44

6.1 Apreciacao Crıtica do Trabalho Desenvolvido . . . . . . . . . . . . . . 44

6.2 Apreciacao do Estagio . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.3 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

A Mapa de Gantt 47

B Anexo Confidencial 48

Lista de Acronimos 50

Bibliografia 52

Indice Remissivo 52

iv

Lista de Figuras

1.1 A origem da Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 O grupo AITEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Planeamento do Estagio . . . . . . . . . . . . . . . . . . . . . . . . . 6

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

2.2 Sistemas do cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Arquitectura da solucao . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Funcionamento do BizTalk Server 2006 . . . . . . . . . . . . . . . . . 12

2.5 Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Exemplo generico de uma integracao . . . . . . . . . . . . . . . . . . 13

2.7 Processo generico de um ponto de integracao . . . . . . . . . . . . . . 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 Aplicacao Tıpica baseada na JSR172 . . . . . . . . . . . . . . . . . . 22

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

3.3 Modelo de Execucao . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

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

3.5 Diagrama UML “Factory Pattern” . . . . . . . . . . . . . . . . . . . 27

3.6 Arquitectura da situacao inicial . . . . . . . . . . . . . . . . . . . . . 28

3.7 Arquitectura da situacao final . . . . . . . . . . . . . . . . . . . . . . 29

3.8 Aplicacao do padrao Factory . . . . . . . . . . . . . . . . . . . . . . 30

4.1 Solucao Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Solucao 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

vi

Capıtulo 1

Introducao

O projecto integra-se num roadmap de desenvolvimento de inovacoes e futuros

modulos de plataforma de electronic ticketing, que consiste num sistema integrado

e modular, para a implementacao de sistemas de mobile ticketing, aplicada ao

cartao SmartCard Dual-Interface com microprocessador, SmartCard Contactless de

memoria.

1.1 Motivacao

Tendo em conta que a disciplina de Projecto de Engenharia Informatica(PEI) e a

ultima do curso, representa assim um grande desafio para os alunos finalistas, reque-

rendo assim especial atencao na escolha do tema a abordar no PEI. Esta disciplina

representa o culminar do processo de graduacao de um aluno do curso de Engenharia

Informatica da FCUL pelo que deve ser abordada, de animo nao leve.

Trantando-se de uma decisao nao trivial, a motivacao para a escolha do tema

“Smartphones para Identificao e Pagamentos” foi baseada nos criterios que se se-

guem:

- O grau de interesse no tema e o auto-desafio de intervir numa area tecnologica

que apesar de nao ser recente, e actualmente emergente.

- atingir a satisfacao pessoal no desenvolvimento do trabalho

1.2 Contexto Cientıfico e Tecnologico

A generalizacao dos Smartcards Contactless aplicados a bilhetica (ticketing) para

transportes e uma realidade. Em Lisboa existem actualmente ja 1,3 milhoes de

cartoes em circulacao. A aplicacao da mesma tecnologia ao turismo e tambem ja

uma realidade com a implementacao do Cartao do Turista de Lisboa.

1

Capıtulo 1. Introducao 2

Todo este sistema tem sido feito com base numa abordagem inovadora utilizando

a plataforma de electronic ticketing. Esta parte da aplicacao de uma Metodologia de

Enterprise Architecture na fase de analise de processos de negocio, para depois seguir

com a aplicacao de Frameworks de Software Embedded na fase de implementacao

dos sistemas de ticketing baseados em contactless smartcards.

A solucao de electronic ticketing da Link, (Sistema Coordenador Integrado para

Ticketing Interoperavel & Smart Cards) e um sistema integrado e modular para a

implementacao de sistemas de electronic ticketing e cartoes. Este sistema inclui a

gestao de clientes, emissao e personalizacao de cartoes e SmartCards com contacto

e sem contacto (contactless), gestao de contratos e produtos tarifarios, vendas e

carregamentos remotos, controlo de utilizacao, gestao da seguranca, compensacao

de receitas para operadores de transportes publicos de passageiros e outros esquemas

de cartao multi-servicos, em especial associados a servicos urbanos e dos municıpios.

Qualquer sistema que requeira a atribuicao e verificacao de direitos de acesso

a servicos a clientes ou colaboradores, exige o recurso a processos e ferramentas

de gestao de valor, nomeadamente meios de pagamento, que devem ser rigorosos,

seguros e faceis de usar, mas que apresentam muitos custos operacionais.

Tradicionalmente, a agilizacao destes processos conduz a substituicao do dinheiro

por um cartao de plastico ou mesmo magnetico, o que permite simplificar algumas

partes dos processos. No entanto, deixa por resolver algumas questoes relaciona-

das com a ergonomia e a seguranca da utilizacao, ou entao obriga a grandes custos

operacionais. Estes custos sao derivados, por exemplo, das comunicacoes, da pouca

fiabilidade dos cartoes ou mesmo da fraude interna e externa do sistema, o que

tambem representa custos. Um sistema deste tipo deve apresentar uma solucao

para estes problemas: deve ser modular, baseado em standards e implementacoes

abertas, permitindo constituir-se como add-ons a sistemas existentes e nao um sis-

tema monolıtico que obrigue a substitui-los.

Assim, um moderno sistema de bilhetica (ticketing) deve basear-se numa tecno-

logia aberta, segura, fiavel e ergonomica 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 ultimos anos atingiu

um elevado nıvel de maturacao, e o SmartCITIES, para implementacao de Smart

Cards contactless dual-interface. Este sistema e baseados no sistema de operacao e

seguranca da tecnologia Calypso, que junta num mesmo cartao com chip a ergono-

mia de uma transaccao contactless, e a seguranca e baixo custo da transaccao que

pode realizar-se off-line.

A emissao de um conjunto Smart Cards personalizados, ou mesmo smart-tickets

nao personalizados, permite a eliminacao de parte dos custos associados a gestao

de valor, em moedas e/ou notas ou mesmo vinhetas (e.g. selo de passe, quota),


que a empresa tem normalmente de fazer, substituindo-o por valor electronico, num

regime totalmente seguro.

1.3 Objectivos do estagio

O objectivo deste estagio enquadra-se, essencialmente, na evolucao de componentes

que interajam com os modulos do Servidor com Motor de Carregamento Remoto de

Tıtulos e nos aspectos relacionados com a aplicacao de carregamentos desses tıtulos

em SmartPhones.

Essa evolucao passa por melhorar os servidores de suporte, que deverao disponi-

bilizar Web Services para o acesso via SmartPhones.

Este projecto sera levado a cabo pela unidade SmartCITIES da Link.

1.4 Organizacao e Metodologia

O projecto enquadra-se nas metodologias de desenvolvimento em pratica na em-

presa, tendo no entanto uma fase inicial de formacao nas tecnologias a utilizar e de

investigacao base, por forma a dotar o aluno de uma visao completa das solucoes

existentes que serao utilizadas como blocos de construcao do trabalho.

1.4.1 A Link Consulting

Desde a sua criacao em 1980, que o INESC tem sido um factor diferenciador na

sociedade portuguesa, afirmando que e possıvel criar riqueza no territorio nacional

com Portugueses, com Tecnologia e com Inovacao.

Ha pois mais de duas decadas que o INESC desenvolve um percurso original na

area da Ciencia & Tecnologia e da Inovacao. Num modelo reconhecido como ino-

vador, o INESC conseguiu fazer coexistir as actividades de investigacao, de trans-

ferencia de tecnologia, formacao e incubacao de empresas. O reconhecimento pela

actividade desenvolvida tem sido patente na evolucao das Universidades de Engenha-

ria, na presenca portuguesa no I&D europeu, na formacao profissional e na criacao

de empresas de base tecnologica.

A Link Consulting teve origem (ver Figura 1.1) na transformacao em estru-

tura empresarial dos Centros de Transferencia de Tecnologia do INESC da area de

Relatorio Final – Curso de Especializacao Profissional em Engenharia Informatica

Informatica e Computadores. Estes Centros tinham sido criados em 1991 com base

num contrato estabelecido com o PEDIP, no ambito dos Programas PEDIP.

Os Centros foram pioneiros em muitas areas de actividades como a Internet, a

Qualidade de Software, o Multimedia, o Suporte a Decisao, tendo participado em


Figura 1.1: A origem da Link

numerosos projectos, quer no mercado Portugues, 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 Transferencia de Tecnologia viessem a ser totalmente

suportadas por mecanismos de mercado. Dado ser essa a situacao dos Centros da

area de Informatica e Computadores, no contexto da reorganizacao das actividades

do INESC, decidiram os respectivos socios efectuar o spin-off destas actividades

numa unica empresa, que veio a dar origem a Link Consulting SA, cujo proposito

foi procurar desenvolver este patrimonio tecnico.

O INESC continua ser o parceiro privilegiado da Link Consulting em numerosas

actividades de Investigacao, Desenvolvimento e Formacao.

O grupo AITEC (ver Figura 1.2) integra empresas que se complementam em

termos de oferta de base tecnologica, contando com cerca de 350 colaboradores.

Figura 1.2: O grupo AITEC

A Link Consulting e uma empresa unica que consegue conjugar a experiencia

de 15 anos de actividade em algumas das maiores empresas nacionais e internacio-

nais assim como a Inovacao resultante da associacao ao INESC, o mais prestigiado

Instituto Portugues de I&D em Tecnologias da Informacao.


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 enderecar os respectivos problemas. Os sectores seguintes sao

naturalmente aqueles onde existe maior dinamica economica e onde maior numero

de projectos tem sido realizados:

1. Administracao Publica

2. Floresta

3. Logıstica

4. Telecomunicacoes

5. Servicos Financeiros

6. Saude

1.5 Planeamento

O planeamento definido para o estagio esta brevemente descrito na Figura 1.3. O

mapa de Gantt correspondente ao planeamento pode ser consultado nos Apendice

A.

1.6 Organizacao do documento

Este documento esta organizado da seguinte forma:

• O Capıtulo 2 Enterprise Application Integration, que descreve o trabalho de

integracao no estagio. Este projecto, como o nome indica, resolve um problema

de integracao de aplicacoes de uma organizacao, por sua vez, cliente da Link.

• O Capıtulo 3 Aplicacao Cliente de Carregamento Remoto de Tıtulos. Des-

creve o prototipo da aplicacao movel, desenvolvida para estudo das necessi-

dades dos novos modulos a desenvolver bem como possıveis alteracoes nos ja

existentes para que aplicacoes moveis possam aceder ao Servidor com Motor

de Carregamento Remoto de Tıtulos. E tambem este capıtulo que foca o tema

do estagio.

Isto permitira a venda e o carregamento de tıtulos nos telemoveis que suportem

a tecnologia Near Field Communication.

• O Capıtulo 4 Remote Coupler. Neste capıtulo, esta descrita a implementacao

do “Remote Coupler” do Software de Interoperabildade para Terminais - Nıvel

Leitor.


Figura 1.3: Planeamento do Estagio

• O Capıtulo 5 Servicos do Motor de Carregamento Remoto de Tıtulos. Do-

cumenta o desenvolvimento do Servico Web que disponibiliza os metodos de

negocio do Software de Interoperabildade para Terminais.

• O Capıtulo 6 Conclusao e elaccoes retiradas de todo o projecto bem como

uma descricao do trabalho futuro.

Capıtulo 2

Enterprise Application Integration

Este capıtulo, tem como proposito documentar o trabalho de integracao na empresa,

realizado na Fase 1 do planeamento do estagio (Figura 1.3). Serviu ainda de base

para a aprendizagem das solucoes e arquitecturas que servem de suporte a integracao

das solucoes de mobile ticketing tendo em conta que e igualmente necessaria uma

arquitectura de backoffice que suporte a integracao de todos os sistemas envolvidos

neste cenario.

2.1 Enquadramento

Data a multiplicidade de sistemas e aplicacoes que uma organizacao pode ter, o

esforco para a replicacao de dados entre os diversos sistemas pode atingir um valor

elevado. Uma vez que as organizacoes estao sempre em constante mudanca, e ex-

pectavel que os Sistemas de Informacao das empresas estejam sempre alinhados com

os seus processos e nao uma adaptacao dos processos ao modo de funcionamento

dos mesmos Sistemas. Enterprise Application Integration (EAI), e um processo para

ligar diferentes aplicacoes e Sistemas, a outros, de forma a ganhar vantagem compe-

titiva tanto operacional como financeira reduzindo tambem os custos de gestao da

informacao.

2.1.1 EAI - Enterprise Application Integration

Quando diferentes sistemas nao conseguem partilhar a sua informacao de uma forma

eficiente e eficaz, sao criados constrangimentos que requerem a intervencao humana

sob a forma de tomada de decisoes ou introducao de dados. Com uma arquitectura

EAI correctamente implementada, as organizacoes podem entao canalizar os seus

esforcos para as competencias de criacao de valor ao inves de se focaram na gestao

dos fluxos de informacao.

Durante geracoes, os sistemas foram construıdos para servirem um unico proposito

e para um conjunto especıfico de utilizadores e ainda sem tomarem em linha de

7

Capıtulo 2. Enterprise Application Integration 8

conta a integracao dos mesmos sistemas, com outros de ainda maiores dimensoes

e multiplas aplicacoes. EAI e a solucao para o resultado nao antecipado do de-

senvolvimento de aplicacoes sem uma visao central em mente. O que as empresas

pretendem e partilhar dados e processos sem terem de realizar alteracoes profundas

nas suas aplicacoes ou na estrutura dos dados. So com a criacao de um metodo para

atingir este tipo de integracao e que EAI pode ser tanto funcional e economicamente

viavel.

Um dos grandes desafios que as organizacoes modernas enfrentam, e o de pro-

videnciar a todos os seus colaboradores um acesso completo, transparente e em

tempo-real a informacao. Muitos dos sistemas legados, ainda hoje utilizados, foram

desenvolvidos usando tecnologias proprietarias e hoje consideradas arcaicas e por

vezes de difıcil integracao com outros sistemas. Como consequencia sao criados “si-

los” de informacao dispersos pelos departamentos das organizacoes. Esses sistemas,

dificultam o movimento coerente da informacao de uma aplicacao para a outra. EAI,

como uma disciplina, tem como objectivo aliviar muitos desses problemas, bem como

criar novos paradigmas que, verdadeiramente, apoiem as organizacoes pro-activas.

Tem tambem a intencao de superar o simples objectivo de inter-ligar aplicacoes e

facilita o aparecimento de novas formas de potenciar o conhecimento organizacional

que pode ser aplicado na criacao de novas vantagens competitivas para a empresa.

Pode dizer-se que com um sistema de integracao a que o valor soma do numero

de sistemas quando interligados, e maior que o valor de cada sistema a funcionar

individualmente.

Melhorando a conectividade

Cada vez mais, tem sido dada maior importancia ao EAI por parte das empresas

porque nestas a computacao tem frequentemente tomado a forma de “ilhas de au-

tomacao”. Isto ocorre quando o valor individual dos sistemas nao e maximizado,

devido a um isolamento total ou parcial dos restantes sistemas da empresa. Se a

integracao for aplicada sem uma aproximacao EAI estruturada, as ligacoes “ponto-

a-ponto” crescem ao longo da organizacao. Sao acrescentadas dependencias sem

uma base definida, resultando numa malha de difıcil manutencao. Este problema

e frequentemente denominado de “esparguete”, uma alusao ao equivalente a pro-

gramacao do codigo-esparguete. Por exemplo:

Sendo n o numero de sistemas, o numero de ligacoes necessarias para

ter uma malha completa de ligacoes ponto-a-ponto e dado pela formulan(n−1)

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

2, ou 45 ligacoes “ponto-

a-ponto”.

Contudo, EAI nao se singe apenas a partilha de dados entre aplicacoes. Foca tambem

a partilha de dados do negocio e seus processos. Atender a EAI, inclui uma visao


de sistema de sistemas, que por sua vez envolve problemas multi-disciplinares, com

sistemas heterogeneos e distribuıdos por uma rede de multiplos nıveis.

Em suma, EAI inclui o desafio de unir eficazmente sistemas e diversas aplicacoes

de uma organizacao, com uma metodologia focada na integracao de processos e

dados, permitindo as organizacoes acompanhar as mudancas 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 solucao de ligacoes “ponto-a-ponto”, o EAI gera as ligacoes

entre sistemas o que permite a reducao de custos de gestao;

2. Construindo um sistema/aplicacao com integracao em mente, reduz o mon-

tante de dinheiro despendido no desenvolvimento de sistemas/aplicacoes adi-

cionais;

3. E possıvel construir novas aplicacoes tendo por base aplicacoes ja existentes;

4. Permite separar o desenvolvimento das funcionalidades nucleares, respeitantes

ao sistema/aplicacao, da compatibilidade com outros sistemas/aplicacoes;

5. Eliminacao das “ilhas” de informacao isoladas, permitindo uma gestao centra-

lizada;

6. Tecnologia que permite integrar os sistemas existentes com os novos sistemas

com um esforco relativamente pequeno;

7. Permite a propagacao de informacao em tempo real ao longo da empresa;

8. Inclui a nocao de reutilizacao, bem como de distribuicao de processos de

negocio e dados;

9. Implementacao de um ponto unico de comunicacao entre as diferentes aplicacoes,

virtualizando a interface adequada a cada uma delas, e implementando as

transformacoes de dados necessarias a troca de informacao;


10. Comunicacao entre as varias aplicacoes usando mensagens, formalizando o

conteudo de cada uma delas e facilitando o tratamento e encaminhamento da

informacao para os destinos adequados;

11. Utilizacao de um mecanismo de encaminhamento de mensagens que permite

um interface unico para as trocas de informacao em batch, assim como a

integracao transaccional on-line de varios sistemas distintos;

12. Possibilidade de tratar encadeamentos de fluxos de informacao (workflow) en-

tre as varias aplicacoes de forma a suportar cadencias de processos complexos;

2.2 O problema

O cliente possui seis sistemas independentes e heterogeneos (Figura 2.2) aos quais

pretende integrar uma nova aplicacao fornecida pela Link, o (Sistema de Gestao de

Operacoes) (Figura 2.3).

Figura 2.2: Sistemas do cliente

2.3 Objectivo

Este projecto surge como sub-objectivo de um proposito mais alargado que e a

implementacao de um sistema de bilhetica sem contacto. E com vista a atingir esse

sub-objectivo que surge a necessidade de sincronizar informacao entre os diversos

sistemas. A infra-estrutura de middleware a implementar, destina-se a suportar o

fluxo de dados entre as varias aplicacoes intervenientes nos processos da area de

operacoes.


2.4 Arquitectura da Solucao

Para a integracao dos varios sistemas actualmente existentes no cliente, e os novos

sistemas a desenvolver no ambito deste projecto, foi proposta a utilizacao de um

Middleware EAI (Enterprise Application Integration) (Figura 2.3). Este proporciona

uma camada intermedia para simplificar a integracao e partilha de informacao entre

sistemas, aumentando a flexibilidade e a velocidade em que a informacao e partilhada

entre as diferentes aplicacoes e reduzindo o custo total da solucao (nomeadamente

ao nıvel da manutencao e numero de conexoes).

Figura 2.3: Arquitectura da solucao

A utilizacao de uma ferramenta EAI, permite virtualizar a camada de integracao

entre aplicacoes atraves de uma plataforma de distribuicao de mensagens. Desta

forma, cada aplicacao ve um unico ponto de integracao com a plataforma EAI, in-

dependentemente das aplicacoes que estao a jusante. A distribuicao, transformacao

e gestao do processo de transporte e entrega de cada um dos elementos de dados,

que fazem parte do fluxo de dados, e da completa responsabilidade desta plataforma

simplificando e flexibilizando os pontos de integracao entre as diferentes aplicacoes.

Para implementar o Middleware EAI foi proposto o produto BizTalk Server 2006,

cujo modo de funcionamento e apresentado na Figura 2.4.

As integracoes baseadas no BizTalk Server 2006 podem ter uma arquitectura

de Hub-And-Spoke, em que as aplicacoes apenas “conhecem e falam” com o Hub,

atraves de um adaptador que e responsavel por efectuar as respectivas conversoes

e/ou mapeamento de dados ou podem ter uma arquitectura ESB (Entreprise Service

Bus) numa solucao baseada em WebServices. As integracoes sao implementadas e


Figura 2.4: Funcionamento do BizTalk Server 2006

configuradas atraves do Visual Studio 2005, contendo ainda o BizTalk uma serie

de ferramentas para administracao (BizTalk Server Administration), monitorizacao

(“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 facil inte-

gracao entre os sistemas, recorrendo a uma plataforma bastante robusta e flexibili-

dade, que potencia a integracao de futuros sistemas que o cliente venha a ter, e/ou

permite facilmente alteracoes a logica das integracoes ja desenvolvidas.

Durante a fase de analise, foi identificada a informacao a sincronizar entre os

sistemas e ainda identificados a origem e destino dessa informacao. A informacao

que cada sistema deve publicar, da origem a uma ’Interface’. A ’Interface’ publicada

por um sistema pode ser subscrita por pelo menos um sistema. Para estabelecer os

fluxos de informacao, e criado um outro documento com a ’Interface’ do sistema de

origem e as ’Interfaces’ dos sistemas destino que inclui as regras de conversao e/o

negocio a aplicar.

De forma a facilitar a implementacao de toda a solucao, foi determinado o padrao

Publish - Subscribe como o padrao de dispersao dos diferentes blocos de informacao

assente sobre uma comunicacao entre os diversos sistemas baseada em mensagens

que mapeiam directamente os blocos que informacao a transportar. De notar que

esta metodologia promove assim a reutilizacao das mensagens de um sistema a ser

consumida por um ou mais sistemas (Figura 2.6).

2.4.1 Ponto de Integracao

Para efeitos de implementacao, considera-se um Ponto de Integracao como sendo a

unidade basica de um conjunto de integracoes. Um Ponto de Integracao, consiste na

especificacao dos sistemas de entrada e saıda, ou Publisher e Subscriber, de um bloco


Figura 2.5: Publish-Subscribe

Figura 2.6: Exemplo generico de uma integracao

de informacao a sincronizar, as regras de transformacao de dados a aplicar, e ainda

a sua periodicidade de execucao. (Figura 2.7). Assim, as integracoes representam

a passagem de informacao entre duas interfaces no mınimo. A cada uma, esta

associado um adaptador o qual representa o meio de comunicacao/protocolo com o

sistema a que pertence essa interface.

Na qualidade de developer, fui incumbido de implementar os varios PIs. No Biz-

Talk Server 2006, a implementacao de um PI corresponde a construcao dos schemas

(mensagens) de entrada e saıda do sistemas (Figura 2.8), os mapeamentos (trans-

formacao de dados) entre mensagens correspondentes (Figura 2.9), as orquestracoes

com a logica de dispersao das mensagens e a configuracao dos canais de comunicacao

(portas e adaptadores).


Figura 2.7: Processo generico de um ponto de integracao

Publisher Subscriber Integracao Adaptador Pub/Sub Scheduler

SAE DW INTEGRACAO A ODBC/ODBC Diaria 03H00

SAE SGO INTEGRACAO A ODBC/ODBC Diaria 03H00

ERP DW INTEGRACAO B ODBC/ODBC Diaria 20H00

ERP SAE INTEGRACAO B ODBC/ODBC Diaria 20H00

ERP SGO INTEGRACAO B ODBC/ODBC Diaria 20H00

ERP Planeamento INTEGRACAO C ODBC/ODBC Online

Tabela 2.1: Exemplo de um Mapa de Integracoes

Execucao dos Pontos de Integracao

Uma integracao 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 integracao, o BizTalk Server 2006, da existencia de

novos dados da interface respectiva;

Scheduling – Atraves da configuracao do scheduler (escalonador) do BizTalk Ser-

ver 2006 para que este verifique, com determinada periodicidade, a existencia

de novos dados. Este modo e tambem referido como pooling ;

Manual – quando uma integracao e invocada a pedido (intervencao humana). Para

desencadear este processo, foi desenvolvida uma aplicacao, o Integration Laun-

cher, que invoca uma integracao em concreto (um PI) quando requisitada pelo

utilizador (Figura 2.6).

2.4.2 Ferramentas

As ferramentas abaixo descritas foram utilizadas na realizacao do projecto:

Microsoft BizTalk Server 2006

E neste servidor onde residem as aplicacoes de integracao desenvolvidas. De seguida

sao 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);


Maps – representa a transformacao a efectuar entre duas mensagens. Contem um

Extensible Stylesheet Language (XSL) que inclui as definicoes dos mapeamen-

tos a efectuar sobre o conteudo 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 recepcao ou envio de uma mensagem (ex: uma etapa pode ser o

parsing da mensagem)

Send port groups – e o agrupamento logico de send ports que podem ser usados

para enviar uma determinada mensagem para varios destinos;

Send ports – Objecto que envia mensagens aos quais estao associados a um de-

terminado adaptador;

Receive ports – O agrupamento logico de receive location;

Receive locations – Um receive location define um endereco 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 execucao 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 sao construıdos os diversos componentes do Biz-

Talk como os ’Schemas’, ’Mapas’ e ’Orquestracoes’.

Microsoft Visual SourceSafe

Sistema de controlo de versoes utilizado.

Microsoft SQL Server 2005

Sistema de Gestao de Base de Dados. Pode ser considerado como um dos sistemas

a integrar.


Oracle 9i


a integrar.

DB2


a integrar.

CVS

O CVS, ou Concurrent Versioning System, e uma ferramenta que faz o rastreio das

alteracoes efectuadas num conjunto de ficheiros permitindo assim a colaboracao entre

diversos programadores. Foi usado para fazer o controlo de versoes dos documentos

de especificacao e reporte do estado do projecto.

Figura 2.8: Exemplo de um Schema para BizTalk Server 2006

Figura 2.9: Exemplo de um Mapa para Biztalk Server 2006

Capıtulo 3

Aplicacao Cliente deCarregamento Remoto de Tıtulos

Este capıtulo documenta o tema do central do estagio, ou seja, ”Smartphones para

Identificacao e Pagamentos”.

Primeiro sao apresentadas as tecnologias de base para a construcao do prototipo,

”Aplicacao Cliente de Carregamento de Tıtulos”.

Na descricao do prototipo, pretende-se explicar o alinhamento das diferentes tec-

nologias que possibilita a construcao de aplicacoes para identificacao e pagamentos.

O desenvolvimento desde projecto teve lugar na Fase 2 do planeamento do estagio

(Figura 1.3).

3.1 Objectivo


modulos de plataforma de electronic ticketing da Link. Neste ambito, pretende-

se implementar um prototipo de uma aplicacao movel 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), e definido como

sendo um cartao que se assemelha a um cartao de credito e que tem um circuito inte-

grado para armazenar dados. Apesar de existirem inumeras aplicacoes, destacam-se

duas: cartoes de memoria, que apenas contem componentes de memoria de arma-

zenamento nao volatil e por vezes alguma logica de seguranca e os cartoes com

microprocessadores, que contem componentes de memoria e microprocessadores.

17

Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 18

A percepcao de Smart Card e a de um cartao que contem um microprocessador

e que tem um tamanho aproximadamente igual a um cartao de credito (ou menor,

por exemplo, o cartao SIM das redes GSM). As propriedades deste cartao incluem

a resistencia a intrusao (por exemplo, um sistema de ficheiros seguros, um processa-

dor seguro, fazendo uso de criptografia) e a capacidade de fornecer servicos seguros

(por exemplo, confidencialidade da informacao guardada em memoria). Nem todos

os ICCs possuem um microprocessador (por exemplo, cartoes de memoria), conse-

quentemente nem todos os ICCs sao necessariamente Smart Cards. Contudo, o uso

da terminologia por parte do publico em geral e muitas vezes inconsistente.

Contact Smart Cards

Um Smart Card com contacto tem um pequeno chip com cerca de 1,2 cm de diametro

na parte frontal. Quando e inserido num leitor de cartoes apropriado, o chip entra em

contacto com os conectores electronicos que conseguem ler e actualizar a informacao

do chip.

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

• A forma fısica.

• A posicao fısica e forma dos conectores electricos.

• As caracterısticas electricas.

• Os protocolos de comunicacao.

• O formato dos comandos enviados para o cartao, bem como o das respostas

por ele retornadas.

• A robustez do cartao.

• A funcionalidade.

Os cartoes deste tipo nao contem bateria, a energia e fornecida pelo leitor.

Contactless Smart Cards

Outro tipo de cartoes sao os Smart Cards sem contacto, no qual o chip comunica com

o leitor atraves da introducao da tecnologia de identificacao por radio frequencia,

RFID, com velocidade na ordem dos 106 a 848 kbit/s. Estes cartoes apenas neces-

sitam de serem aproximados a uma antena para realizarem uma transaccao. Este

tipo de cartoes sao muitas vezes utilizados quando as transaccoes tem que ser pro-

cessadas rapidamente ou sem maos, tais como sistemas de transito em massa (como

as entradas e saıdas do metro), onde estes podem ser usados sem a necessidade de

retira-los da carteira.


O standard para a comunicacao deste tipo de cartoes e o ISO/IEC 14443, datado

de 2001. Este standard define dois tipos de cartoes sem contacto (A e B), permite

comunicacoes ate 10 cm de distancia 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 cartoes sem contacto e o ISO

15693, que permite comunicacoes a uma distancia de 50 cm.

Um exemplo do uso deste tipo tecnologia e o projecto LisboaViva que utiliza

estes cartoes para controlar as entradas e saıdas na rede de transportes publicos de

Lisboa.

Vantagens e Desvantagens dos Smart Cards

A utilizacao de Smart Cards tras inumeras vantagens, nao so para o utilizador, como

para a seguranca dos sistemas que os utilizam e o poder computacional.

As vantagens para o utilizador sao a facilidade de usar e ter informacao portatil,

podendo os dados do utilizador ficarem guardados no cartao.

Ao nıvel da seguranca, as vantagens sao inumeras. A informacao armazenada

no cartao, pode estar protegida para leitura e/ou escrita atraves de um codigo PIN

ou dados biometricos. Os dados guardados, por sua vez, podem estar encriptados.

Cada cartao possui um numero de serie unico.

O poder computacional e grande, pois este tipo de cartoes, tem capacidade de

processamento e de comunicacao com outros terminais. Esta comunicacao e feita

atraves da ligacao a um leitor de Smart Cards, podendo a informacao e aplicacoes

em causa, serem actualizadas, sem haver a necessidade de serem emitidos novos

cartoes ou bilhetes.

Apesar dos Smart Cards apresentarem inumeras vantagens, tambem tem algu-

mas desvantagens. Estas resultam principalmente da falta de interoperabilidade ao

nıvel de cartoes e da falta de standards ao nıvel do desenho.

A falta de interoperabilidade resulta das diferentes normalizacoes do modelo

de dados, falta de standards ao nıvel da comunicacao com o exterior e diferentes

conjuntos de instrucoes (instruction set) dos muitos tipos de cartoes existentes.

As desvantagens apresentadas, impossibilita a utilizacao do mesmo cartao em

diferentes paıses ou aplicacoes.

3.2.2 Tecnologia Calypso

Um cartao Calypso e um Smart Card que permite a verificacao e transferencia de

direitos de transporte, tal como os passes/tıtulos de transportes do metropolitano

de Lisboa. O cartao pode conter varias informacoes, tais como, informacao acerca

do utilizador (dono do cartao), o ultimo acesso ao cartao, etc.


Como o direito de entrada, por exemplo numa rede do metro, acarreta valores

monetarios, a sua utilizacao e protegida por algoritmos, prevenindo assim possıveis

forjadores de produzirem cartoes falsos ou carregar um cartao sem a devida auto-

rizacao.

Os algoritmos criptograficos sao baseados em chaves secretas, guardadas dentro

do cartao, num SAM (Secure Application Module). O SAM esta sempre presente

no equipamento que interactua com os cartoes (ou ligado remotamente ao equi-

pamento). Depois da manufactura, o cartao e personalizado escrevendo-se no seu

interior as chaves secretas e os dados.

Os cartoes Calypso, podem, no entanto, ser utilizados para outras aplicacoes,

podendo ter outras caracterısticas que estendam as suas capacidades, para alem

das especificacoes Calypso. Diferentes tipos de cartoes compatıveis com a norma

Calypso podem fornecer diversos nıveis de seguranca.

Os cartoes Calypso, permitem a utilizacao do algoritmo DES (um metodo de

encriptar informacao), 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 seguranca contra a manufactura de cartoes falsos e carregamentos nao autoriza-

dos.

3.2.3 Near Field Communication

Near Field Communication, ou NFC, e uma nova tecnologia de comunicacao sem fios,

de curto alcance, que evoluiu a partir da combinacao de tecnologias de identificacao

e inter-ligacao sem contacto, ja existentes. Opera numa frequencia de 13.56 MHZ, a

uma distancia de poucos centımetros entre os dispositivos. As camadas subjacentes

a esta tecnologia sao baseadas nos standards ISO, ECMA e ETSI.

Permite, de forma simples e segura, uma interaccao bi-direccional entre disposi-

tivos permitindo ao utilizador efectuar transaccoes sem contacto, aceder a conteudo

digital e conectar dispositivos com um ‘simples toque’.

Os RFID e Smart Cards sem contacto, sao sistemas que ja se encontram am-

plamente disponıveis num variado leque de industrias e sao usados para diferentes

propositos. Esses sistemas sao a combinacao de um dispositivo de leitura/escrita

para um smart card e um transponder (transmissor-receptor). Existe sempre uma

clara separacao funcional entre os dois dispositivos que por vezes, causa limitacoes

a construcao de novas aplicacoes.

O seu modo de funcionamento e 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 e diferente das outras

tecnologias sem contacto e RFID uma vez que opera a distancias mais curtos e


interliga dois dispositivos. Integra dispositivos de leitura/escrita e o transponder

num unico circuito.

As diversas funcoes 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 moveis, abre portas para um novo mundo de

aplicacoes a construir. Os seus principais benefıcios e potencialidades sao:

• Usabilidade melhorada e experiencia de utilizacao mais rica.

• Facil acesso a servicos e conteudo disponibilizados por dispositivos fısicos

• Controlo de acessos e Ticketing

• Partilha de conteudo digital entre dispositivos atraves da sua aproximacao

• Capacidade de Pagamentos e Ticketing

A Capacidade de Pagamentos e Ticketing e de crucial importancia porque repre-

senta a tecnologia facilitadora da ideia para o projecto.

3.2.4 Nocao de Framework

No desenvolvimento de software, uma framework, ou arcabouco, 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

codigo, linguagens de script e outros softwares para ajudar a desenvolver e juntar

diferentes componentes de um projecto.

As frameworks sao projectadas com a intencao 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 determinacao das

exigencias do software.

3.2.5 JSR-172: J2METMWeb Services Specification

O objectivo global da JSR-172 e acrescentar duas novas capacidades a plataforma

J2ME que sao:

• 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:


1. um pacote adicional para o parse de dados em XML. O mais provavel, e que

os dados estruturados enviados para os dispositivos moveis pelas aplicacoes

existentes estejam sob a forma XML. De forma a evitar a inclusao de codigo

que processa-se esses dados em cada aplicacao movel, e desejavel a definicao

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 devera ser evitado a

criacao de novos formatos e protocolos de comunicacao e reutilizar os standards

existentes.

A Figura 3.1 ilustra a aplicacao tıpica baseada na JSR-172.

Figura 3.1: Aplicacao Tıpica baseada na JSR172

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

A especificacao Security and Trust Services API (SATSA), define os pacotes opcio-

nais para a plataforma Java 2 Micro Edition (J2ME).Esta especificacao, foi elabo-

rada em resposta ao pedido de especificacao, Java Specification Request 177 (JSR-

177). O seu proposito, e especificar uma coleccao de APIs que oferecam servicos de

seguranca (autenticidade, integridade e confidencialidade) integrados com um Ele-

mento Seguro (ES). Um ES, e um componente do dispositivo com J2ME e apresenta

os benefıcios que se seguem:

• Armazenamento seguro para proteccao dos dados sensıveis como chaves pri-

vadas, chaves publicas, credenciais de acesso a servicos, informacao pessoal,

entre outros;


• Operacoes criptograficas para suportar protocolos de pagamentos, integridade

e confidencialidade dos dados

• Ambiente de execucao seguro para incluir funcionalidades de seguranca. Aplicacoes

J2ME baseiam-se nessas funcionalidades para tratar servicos de valor acrescen-

tado como identificacao e autenticacao, pagamentos e aplicacoes de fidelidade.

Um elemento seguro pode tomar varias formas. Os smartcards sao os mais usados

para implementar este tipo de artefactos. Encontram-se disponıveis em telemoveis

GSM sob a forma de cartoes SIM, UICC para telemoveis 3G, e RUIM para telemoveis

CDMA. Por exemplo, nas redes de telecomunicacoes GSM, os dados de autenticacao

na rede de um dado operador sao escritos no SIM bem como informacao pessoal do

subscritor. Quando o SIM e inserido no telemovel, este fica pronto a funcionar na

rede do operador.

Alternativamente, um ES pode ser implementado por software. Esta especi-

ficacao nao exclui qualquer implementacao de Elementos Seguros apesar de alguns

pacotes da API estarem optimizados para smartcards.

A API endereca varias necessidades, satisfeitas por pacotes especificados para o

efeito:

SATSA-APDU – Este pacote define uma API para suportar a comunicacao com

smart card com recurso ao protocolo APDU. Os Smart Cards oferecem um am-

biente seguro de programacao. E o tipo de ES mais usado e para implementar

servicos de seguranca.

SATSA-PKI – Este pacote opcional define uma API para suportar assinaturas

digitais ao nıvel da aplicacao e gestao basica de credenciais do utilizador.

Para potenciar uma maior reutilizacao, esta API e independente do tipo de

ES utilizado. As assinaturas digitais usadas para autenticar os utilizadores ou

autorizar transaccoes que utilizem uma criptografia de chave publica.

SATSA-CRYPTO – Este pacote opcional e um sub-conjunto da API de crip-

tografia do versao J2SE. Providencia operacoes basicas de criptografia para

suportar Message Digest, verificacao de assinaturas , cifrar e decifrar blocos

de dados.

SATSA-JCRMI – Este pacote define a API cliente Java Card RMI 1 que permite

a uma aplicacao J2ME invocar um metodo de um objecto Java Card remoto.

1JavaCardRMI esta definida na especificacao da plataforma Java Card 2.2(http://java.sun.com/products/javacard)


3.2.7 Nocao de Stub

Num ambiente distribuıdo, as aplicacoes podem aceder a servicos que poderao estar

situados local ou remotamente. Dado que um servico so pode ser acedido, atraves

da invocacao de uma das suas operacoes, o acesso remoto requer um mecanismo que

suporte a execucao remota das operacoes.

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, e necessaria a implementacao de um proto-

colo de comunicacao responsavel pela correcta transferencia de controlo entre quem

invoca a operacao (o cliente) e o servidor remoto que ira executar a operacao pre-

tendida. O seu modelo de execucao esta esquematicamente representado na Figura

3.3.

Figura 3.3: Modelo de Execucao

Para alem do controlo das operacoes, este deve suportar a transferencia de quais-

quer argumentos necessarios a execucao da operacao e do retorno para o cliente de

um qualquer resultado. Este mecanismo e denominado “chamada a funcoes remo-

tas” (RPC – remote procedure call) e representa uma extensao da tradicional nocao

de chamada a funcoes para um ambiente distribuıdo.

Conceptualmente, uma aplicacao distribuıda consiste em varios fragmentos dis-

tintos, divididos entre quem chama a funcao (cliente) e um servidor remoto res-


ponsavel pela execucao local da operacao invocada. Estes fragmentos sao conhecidos

como: o cliente, o stub do cliente, o transporte RPC, o stub do servidor e o servidor.

A representacao esquematica destes fragmentos aparece representada na Figura 3.4

Figura 3.4: Passos de uma Chamada Remota de Procedimentos

O cliente e servidor sao ambos desenhados e implementados como se as aplicacoes

fossem para correr num ambiente centralizado tradicional. A funcao dos stubs do

cliente e servidor e “esconder” o mais possıvel a distribuicao do sistema.

Princıpios da geracao do Stub

Como o desenvolvimento manual de stubs pode ser fastidiosa e complicada, este

processo pode ser automatizado atraves de um gerador automatico de codigo.

O gerador produz o codigo do stub, na linguagem desejada, atraves de uma

linguagem de definicao 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 programacao pode permitir que diferentes partes da

aplicacao distribuıda sejam programadas em diferentes linguagens, adequando-se

a tarefa em causa. Alem disso, como estas IDL’s sao tipicamente mais restritivas,

podem incutir no programador uma abstraccao a nıvel das diferencas existentes entre

o processamento local e remoto e proibir o uso de certos construtores, normalmente

disponıveis nas linguagens de programacao. Podem ainda aumentar a linguagem

com funcionalidades nao disponıveis a partida; por exemplo, permitindo o uso de

novos tipos como strings e arrays dinamicos, ou construtores como os de tratamento

de excepcoes.

Contudo, as desvantagens sao 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 transparencia. Esta alternativa

torna tambem possıvel que a IDL nao corresponda ao que esta na realidade imple-

mentado, caso se altere uma independentemente da outra. Existe ainda o problema


de muitos sistemas de IDL necessitarem que o programador escreva codigo relati-

vamente diferente para o servidor (alterando, por exemplo, o nome das funcoes),

comparativamente ao ja existente na solucao original, nao distribuıda.

Por outro lado, uma IDL especifica a linguagem de programacao utilizada, ga-

nha em termos de transparencia e a interface e implementacao nao divergem tao

facilmente do que com uma IDL separada. Infelizmente, essa transparencia pode

induzir o programador a uma falsa sensacao de seguranca, dado que nem toda a

linguagem produzida sera distribuıda e os custos inerentes a essa distribuicao nao

sao obvios.

De modo geral, a geracao de stubs envolve varios problemas que assentam prin-

cipalmente na inexistencia de uma memoria partilhada, entre o cliente e o servidor.

Desta situacao podem advir os seguintes problemas:

• Heterogeneidade das maquinas. Diferentes maquinas podem ter diferentes

representacoes binarias dos variados tipos primitivos. Por exemplo, diferente

ordenacao de bytes e representacao de vırgulas flutuantes; diferentes precisoes

aritmeticas (16 vs. 32 bit); representacoes de vırgulas pouco usuais, etc.

A solucao 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 transmissao. Esta conversao tem custos considerados

e e desnecessaria entre maquinas do mesmo tipo. Contudo e uma solucao

simples que resolve os problemas existentes num ambiente heterogeneo.

• Transferencia de parametros e tipos. Diferentes linguagens apresentam dife-

rentes semanticas na passagem de parametros, como as invocacoes por valor e

por referencia. Os procedimentos remotos forcam normalmente um processo

de “copy-in”, “copy-out” para a passagem de parametros, que nem sempre

coincide com a semantica do mecanismo local para a passagem de parametros.

Alem disso, alguns tipos de argumentos podem ter de ser completamente proi-

bidos, por exemplo, procedimentos.

• Estruturas que se auto referenciam. Muitas das linguagens de programacao

modernas, permitem a criacao de estruturas de dados que contem apontadores

para outras estruturas de dados. Esta funcionalidade, dota o programador de

um mecanismo bastante flexıvel, mas causa problemas a nıvel da geracao do

stub que tem de fazer o marshall de toda a estrutura, quando apenas um dos

seus elementos e passado como parametro. Estruturas circulares sao ainda

mais complicadas de gerir.

• Falhas. As falhas num RPC sao ainda mais complicadas de gerir do que

as falhas a nıvel de um procedimento local, uma vez que localmente, estas


so acontecem quando a globalidade da aplicacao falha ou quando o erro e

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 padrao “Factory Design Pattern” e um padrao de desenho das linguagens de pa-

radigma Object-Oriented. Insere-se no conjunto de padroes de criacao ,‘ ‘Creational

Patterns”. Este padrao, retorna uma entre muitas instancias de classes possıveis,

dependendo das parametros passados. Normalmente, todas as classes que retorna,

tem 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 (metodo de fabricacao) que retorna o objecto

da classe Product (produto). Este elemento tambem pode definir uma im-

plementacao basica que retorna um objecto de uma classe ConcreteProduct

(produto concreto) basica;

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 implementacao para a interface Product.

Este padrao e muito utilizado em frameworks para definir e manter relacoes entre

objectos.


3.3 Situacao Inicial

Uma vez que se trata de um projecto de desenvolvimento de inovacoes e futuros

modulos da plataforma de electronic ticketing, o desejavel seria desenvolver um

prototipo cuja implementacao se encontre o mais proximo possıvel da realidade,

ou seja, uma aplicacao movel instalada em um smartphone que acedesse ao Servidor

com Motor de Carregamento Remoto de Tıtulos.

Figura 3.6: Arquitectura da situacao inicial

Para esse efeito, o smartphone deve satisfazer os seguintes requisitos: disponi-

bilizar interface NFC, suportar a plataforma J2ME e implementar as especificacoes

JSR 172 (seccao 3.2.5) e JSR177 (seccao 3.2.6 ). Quando carregados os tıtulos,

os testes poderiam ser feitos nas aplicacoes da link para verificacao dos contratos,

validando assim a prova-de-conceito (proof-of-concept) a efectuar.

3.4 Situacao Actual

Uma vez que nao foi possıvel recepcionar o dispositivo com esses requisitos, no

perıodo calendarizado para a execucao do projecto, a solucao passou por simular

todo o processo recorrendo ao emulador de um telemovel, 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 a frente.

3.5 Implementacao

3.5.1 Interface APDUConnection

Esta interface define uma ligacao APDUConnection (Application Protocol Data

Unit). As aplicacoes J2ME podem usar esta ligacao para comunicar com aplicacoes


Figura 3.7: Arquitectura da situacao final

em smart cards com atraves do protocolo APDU. O standard ISO 7816-4 define uma

APDU como um protocolo de nıvel da aplicacao entre um smart card e uma aplicacao

no dispositivo. Existem dois tipos de mensagens APDU: ’APDU de Comando’ e

’APDU de Resposta’. APDUs de Comando sao enviadas pelas aplicacoes J2ME

para os smart cards. ’APDUs de Resposta’ sao as mensagens recebidas dos smart

cards.

E esta interface que deve ser implementada para o envio das ’APDUs de Co-

mando’ e recepcao das ’APDUs de Resposta’. Utilizando esta abordagem, deixa de

ser necessaria qualquer alteracao ao codigo aquando da instalacao da Midlet num

smartphone com interface NFC.

Em seguida e apresentado o sumario dos metodos especificados nesta interface.

• byte[] changePin(int pinID)

E um metodo de alto nıvel que permite as aplicacoes J2ME solicitarem ao

utilizador o codigo PIN para alteracao e enviar ao cartao

• byte[] disablePin(int pinID)


utilizador o codigo PIN a ser desabilitado e enviar para o cartao.

• byte[] enablePin(int pinID)


utilizador o codigo PIN a ser reabilitado e enviar para o cartao.

• byte[] enterPin(int pinID)


utilizador o codigo PIN a ser verificado e enviar para o cartao.

• byte[] exchangeAPDU(byte[] commandAPDU)


Metodo para enviar uma ’APDU Commando’ para uma aplicacao do cartao e

receber a ’APDU Resposta’.

• byte[] getATR() Retorna a mensagem Answer To Reset (ATR) enviada pelo

cartao em resposta da operacao de reset

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


utilizador a introducao do codigo PIN de desbloqueio e o novo valor do codigo

PIN bloqueado para envia-los ao cartao.

E esta interface que vai encapsular o acesso ao leitor e ao cartao por parte da

Midlet. Com esta abordagem, e possıvel simular o acesso ao cartao SIM e ainda

instalar a aplicacao num smartphone com interface NFC, sem qualquer alteracao ao

codigo desenvolvido.

Na implementacao desta interface foi utilizado o padrao de desenho Factory

Method (seccao 3.2.8). A (Figura 3.8) ilustra a aplicacao concreta do padrao de

desenho no modelo de classes da aplicacao.

Figura 3.8: Aplicacao do padrao Factory

Isto facilita a construcao de varias classes de comunicacao com os diferentes lei-

tores suportados pelo Software de Interoperabilidade para Terminais sem a alteracao

das aplicacoes cliente uma vez que todas as classes implementam a mesma interface.


3.5.2 Arquitectura da Solucao

Analisando a Figura ?? do Apendice B (Anexo Confidencial) com a arquitectura

da Aplicacao Cliente tem-se que:

Emulador – Corresponde ao emulador do Wireless Toolkit da Sun. Simula o

smartphone com interface NFC.

JSR 172 — A implementacao de referencia da interface JSR172 (Seccao 3.2.5).

Foi usada para a invocacao dos metodos do Servidor com Motor de Carrega-

mento Remoto de Tıtulos. Como anteriormente referido, esta API permite as

aplicacoes moveis o consumo de Web Services.

Stubs -– Classes com toda a logica de empacotamento e desempacotamento dos

metodos e estruturas de dados do Servidor com Motor de Carregamento Re-

moto de Tıtulos. Para mais informacoes sobre stubs ver seccao 3.2.7.

APDU Connection — Implementacao da Interface APDUConnection da especi-

ficacao JSR177 (seccao 3.2.6)para a comunicacao com os cartoes 3.5.1. Aqui

foi desenvolvido todo o codigo de inicializacao dos leitores, ou seja abertura

das portas COM necessarias. Deve ser transparente a Midlet para que possa

suportar diferentes tipos de leitores. Isto torna a logica da aplicacao inde-

pendente do dispositivo usado. Consequentemente, o envio de APDUs para o

cartao SIM , por parte da Midlet e concretizado de forma simulada.

Midlet — Que corresponde a aplicacao J2ME com toda a logica de instanciacao do

“Stubs”, ’APDUConnection’ e invocacao dos metodos do Servidor com Motor

de Carregamento Remoto de Tıtulos. Serve de intermediario entre o Cartao e

o Servidor para a troca de APDUs.

3.5.3 Modo de Funcionamento

A Figura ?? do Apendice B (Anexo Confidencial) ilustra o modo de funciona-

mento da aplicacao para o carregamento e validacao de contratos.

1. Invocacao 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 cartao (APDU

Comando)

(b) Servidor envia APDU Commando para a Midlet


(c) Midlet envia APDU Commando para o Cartao 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 comunicacao com o servidor.

3.6 Limitacoes Identificadas

Durante a fase de desenvolvimento da aplicacao, surgiram algumas limitacoes refe-

rentes as APIs Java, nomeadamente na API JSR-172 (Seccao 3.2.5). Essas limitacoes

estao intrinsecamente ligadas a limitada capacidade de processamento e memoria dos

dispositivos moveis facto que impede, em alguns casos, a construcao de APIs tao

poderosas como no caso das APIs que correm nas aplicacoes em PCs convencionais.

Neste projecto em concreto, a limitacao emergente tem a haver com a API de

parse de dados em XML que nao suporta alguns tipos de dados.

A solucao passou pela redefinicao das estruturas retornadas pelo Servidor com

Motor de Carregamento Remoto de Tıtulos, de modo a circunscrever as limitacoes

apresentadas em seguida:

O estilo dos atributos O estilo de codificacao dos atributos deve ser do tipo do-

cument e nao RPC. Para Web Services de acesos movel, a implementacao

JAX-RPC deve usar o estilo Document/literar para o mapeamento entre o

WSDL do servico e a representacao Java correspondente. Isto constitui um

grave problema porque a maior parte dos servicos estao construıdos com RPC

quando a API JSR-172 suporta apenas o tipo Document.

Tipos de Dados a evitar Tipos numericos sem sinal tais como, ”xsd:unsignedInt”,

”xsd:unsignedLong”, ”xsd:unsignedShort”, e ”xsd:unsignedByte”, sao 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 nao

tem tios numericos sem sinal. Por uma questao de interoperabilidade, nao

devem ser expostos metodos com esses tipos numericos. Pode ser criados

metodos 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 precisao. Como resultado, pode ocorrer a perde de

precisao na conversao desses tipos entre plataformas.

O tipo ”xsd:anyType”,ou seja, Object, representa o maior problema porque

nao e possıvel criar um mapeamento entre qualquer objecto proveniente do

Web Service, numa estrutura de dados especıfica no cliente.

Capıtulo 4

Servicos do Motor deCarregamento Remoto de Tıtulos


(Figura 1.3).

4.1 Objectivo

Este projecto, tem por objectivo a construcao dos ”Servicos do Motor de Car-

regamento Remoto de Tıtulos”, (SMCRT). Deve ser implementado sob a forma

de um Web Service. Os metodos a disponibilizar sao os necessarios tanto para

configuracao dos leitores, como para interagir com os cartoes e SAMs.

Uma vez concluıdo, ira permitir as aplicacoes cliente operarem com os leitores

sem a inclusao da camada de negocio do Software de Interoperabilidade para Ter-

minais na maquina hospedeira da aplicacao cliente. Ao centralizar a acesso a esta

camada do Software de Interoperabilidade para Terminais, a manutencao da mesma

pode ser feita de forma transparente para as aplicacoes cliente sem necessidade de

reinstalacao da mesma nas diferentes maquinas. Assim, as aplicacoes cliente neces-

sitarao apenas de um sub-conjunto do ”Software de Interoperabilidade para

Terminais”(SIT), concretamente o Nıvel Leitor.

4.2 Analise do problema

Inicialmente (Figura 4.1), preve-se que uma aplicacao que utilize o SIT, possua uma

replica integral (todas os nıveis) da mesma instalada na maquina respectiva para a

invocacao de comandos no cartao , acesso e configuracao dos leitores. Isto implica

que cada alteracao efectuada no Nıvel de Negocio do Software deva ser propagada

por todas as aplicacoes que a utilizem.

Para facilitar a inclusao de alteracoes a camada de negocio e resolver o problema

da propagacao das suas actualizacoes, sentiu-se a necessidade de separar esta ca-

33

Capıtulo 4. Servicos do Motor de Carregamento Remoto de Tıtulos 34

Figura 4.1: Solucao Inicial

mada das restantes, a ser disponibilizada num servico web com os metodos para a

configuracao dos leitores com ilustrado na Figura 4.2.

Figura 4.2: Solucao Pretendida

4.2.1 Software de Interoperabilidade para Terminais

O Software de Interoperabilidade para Terminais e responsavel por disponibilizar

metodos de alto nıvel dos cartoes e tickets, que garantem a independencia dos for-

matos e funcionalidades basicas entre a aplicacao, e o leitor utilizados.

Neste trabalho so foram utilizadas duas famılias de cartoes, que utilizam a tecno-

logia Calypso para garantir a seguranca dos mesmos. A camada superior do SIT nao

tem qualquer conhecimento dos diversos tipos de cartoes, 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 funcoes de gestao ao nıvel da comunicacao entre o cartao e o termi-

nal/leitor utilizados.

A interface disponibilizada por este nıvel independente do leitor, representando

uma camada de abstraccao que torna mais facil o processo de integracao com dife-

rentes leitores.

Neste ambito, existem dois tipos de metodos: o primeiro, e referente a logica

de negocio e contem, por exemplo, o metodo para preparar o leitor, ou seja, a


configuracao do SAM e deteccao do cartao. O segundo, inclui o metodo auxiliar

para iniciar um comando a invocar no cartao, e esta relacionado com a arquitectura

e desenvolvimento do sistema.

A solucao proposta deve suportar o acesso simultaneo de varios clientes.

4.2.2 Metodos a Disponibilizar

Como anteriormente referido, este Servico deve disponibilizar a aplicacao cliente

uma serie de metodos de negocio e receber o respectivo resultado. No entanto, o

SMCRT tera que inicializar o SIT, antes do cliente invocar um destes metodos.

Metodo para Iniciar Interaccao

Este metodo, como o nome indica, serve para dar inıcio a interaccao do cliente

com o servidor. E retornado ao cliente um identificador (GUID), que serve para

mapear/associar o contexto do servidor (Proxy e Processo) com o cliente respectivo.

A partir desse momento, sempre que o cliente queira efectuar uma operacao das

que se seguem, tem que passar obrigatoriamente o GUID que lhe foi atribuıdo neste

metodo.

Metodo para Terminar Interaccao

Como o nome indica, este metodo serve para terminar a interaccao do cliente com

o servidor. Quando invocado, o servidor encarrega-se de destruir todo o contexto

associado a um cliente.

Metodo para Ler Estado da Ultima Operacao

Este metodo, server para obter o estado (resultado) da ultima operacao invocada

no Servico. No entanto, todas os metodos retornam o estado de invocacao.

Metodo para Afectar um Leitor

Como o nome indica, este metodo serve para afectar o leitor ao SIT.

Metodo para Libertar um Leitor

Como o nome indica, este metodo serve para desafectar o leitor ao SIT.

Metodo para Afectar SAM

Como o nome indica, este metodo serve para afectar um dos possıveis SAMs que se

encontram no leitor ao SIT.


Metodo para Libertar SAM

Como o nome indica, este metodo serve para libertar o SAM alocado na operacao

anteriormente descrita.

Metodo para Associar um Cartao a um SAM

Este metodo associa um SAM previamente alocado a um Cartao.

Metodo para Desassociar um Cartao de um SAM

Este metodo associa um SAM previamente associado a um Cartao.

Metodo para Iniciar Comunicacao com o Cartao

Como o nome indica, deve retornar os comandos necessarios para iniciar a comu-

nicacao com o cartao.

Metodo para Fechar Comunicacao com o Cartao

Como o nome indica, deve retornar os comandos necessarios para cessar a comu-

nicacao com o cartao.

Metodo para Abrir Sessao no Cartao

Como o nome indica, serve para iniciar uma sessao no Cartao.

Metodo para Fechar Sessao no Cartao

Como o nome indica, serve para fechar uma sessao no Cartao.

Metodo para Ler o Contador

Este metodo serve para ler o valor de um contador existente no Cartao.

Metodo para Escreve o Contador

Este metodo serve para escrever o valor de um contador existente no Cartao.

Metodo para Seleccionar Aplicacao do Cartao

Este metodo, serve para seleccionar uma das varias aplicacoes existentes no Cartao.

Para alem do identificador do cliente, deve ser passado o identificador da aplicacao

a seleccionar.


Metodo para Invalidar um Cartao

Como o nome indica, serve para invalidar um cartao

Metodo para Reabilitar um Cartao

Como o nome indica, serve para reabilitar um cartao.

Metodo para Escrever Dados no Cartao

Metodo generico que permite ler qualquer tipo de dados no Cartao.

Metodo para Ler Dados do Cartao

Metodo generico que permite escrever qualquer tipo de dados no Cartao.

Metodo para Verificar o PIN do Cartao

Como o nome indica, serve para verificar se o PIN do Cartao fornecido pelo cliente

e o correcto.

Metodo para Alterar o PIN do Cartao

Como o nome indica, serve para alterar o PIN do Cartao. Para alem do GUID deve

ser passado o PIN actual bem como o novo PIN.

Metodo para Iniciar um Comando

Este metodo serve para o SMCRT receber das queues o resultado de um dos metodos

anteriormente descritos. O objectivo e sempre retornar os comandos a executar no

Cartao.

E importante referir que o retorno de todos os metodos acima descritos foi conce-

bido com as limitacoes identificadas no projecto Aplicacao Cliente de Carregamento

Remoto de Tıtulos. Quer isto dizer que os objectos de retorno sao constituıdos por

atributos de tipos basicos para que o consumo do servico, por parte de aplicacoes

moveis, seja ’implementavel’.

4.3 Implementacao

Uma vez que a linguagem de programacao usada para a implementacao do Web

Service foi ASP.NET e C#, foi necessario criar um Wrapper que invocasse as funcoes

da biblioteca do Software de Interoperabilidade dado que esta esta construıda com a

Linguagem C. De seguida, deu-se inıcio a construcao do Web Service onde foi criado

Web Method por cada metodo do SIT a invocar.


Figura 4.3: Arquitectura do SMCRT

Assim analisando a arquitectura da Figura 4.3 tem-se que:

O SMCRT representa o Web Service com varios web methods disponibilizados.

O Proxy, representa um cliente no SMCRT. Este e identificado univocamente no

sistema por um Identificador Global passado ao cliente na primeira invocacao

do web service. Assume o papel de ponte entre o cliente e o processo que

responde aos seus pedidos. E o proxy que guarda as queues de comunicacao

entre o processo e o web service com a informacao a trocar com o cliente.

O Processo e responsavel por carregar em memoria o SIT, com recurso ao wrapper

criado, e invocar o metodo correspondente ao web method. Para permitir o

acesso concorrente, poderia optar-se por implementar threads para tratar os

clientes dado que consomem menos recursos e evitam a mudanca de contexto

no processador (nao e necessario guardar o program counter nem a pilha).

No entanto, esta opcao teve de ser descartada porque, internamente, o SIT

guarda o estado da invocacao das funcoes. Dado que as threads partilham o

mesmo espaco de memoria, o contexto de execucao do primeiro corromper-se-

ia aquando da invocacao de um metodo do SIT por parte de outro cliente.

Devido a este facto, sera criado um processo por cada cliente pois os processos

sao executados num espaco de memoria reservado.

A Figura ?? do Apendice B (Anexo Confidencial) ilustra o modo generico

de funcionamento da invocacao de um metodo de alto nıvel, identificado na figura

como ”High Method”.

Capıtulo 5

Remote Coupler


(Figura 1.3).

5.1 Objectivo


modulos de plataforma de electronic ticketing da Link. Neste ambito, pretende-

se implementar um prototipo de uma aplicacao movel que aceda ao Servidor com

Motor de Carregamentos Remotos , para a compra e carregamento de tıtulos no

SmartPhone. Neste ambito, devera ser adicionado o suporte a um novo coupler

designado por “Remote”. Este vai permitir as aplicacoes cliente do Servidor com

Motor de Carregamento Remoto de Tıtulos funcionarem sem SAMs locais, ou seja,

sem um SAM embutido no leitor de cartoes. Com este coupler, o acesso aos SAMs

passa a ser remoto e gerido pelo servidor SAM Server (Figura 5.3).

5.2 Situacao Inicial

Uma solucao que visa uma crescimento contınuo, de forma a acompanhar a chegada

de novas tecnologias ao mercado, tem que estar bem implementada, para que a

adicao de novas funcionalidades nao implique grandes alteracoes no codigo existente.

O “Software de Interoperabilidade para Terminais”, tendo em conta este princıpio,

foi desenhado de forma modular, permitindo assim uma abstraccao dos modulos

inferiores. E composto por tres nıveis distintos como pode ser visualizado na arqui-

tectura representada na Figura 5.1.

Analisando a Figura 5.1 com a arquitectura do Software de Interoperabilidade

para Terminais tem-se que:

O nıvel superior e responsavel por disponibilizar metodos de alto nıvel dos cartoes

e tickets, que garantem a independencia dos formatos e funcionalidades basicas entre

39

Capıtulo 5. Remote Coupler 40

Figura 5.1: Arquitectura do Software de Interoperabilidade para Terminais

a aplicacao, o coupler e o cartao utilizados.

O segundo nıvel, “Card”, corresponde a uma camada interna do “Software de

Interoperabilidade para Terminais” e e responsavel pela gestao dos metodos referen-

tes aos cartoes, independentemente do leitor utilizado. A interface disponibilizada

por esta camada, e independente do cartao, embora internamente implemente dife-

rentes funcoes para diferentes cartoes. Esta camada de abstraccao facilita o processo

de integracao/adicao de diferentes cartoes.

O nıvel leitor corresponde tambem a uma camada interna do “Software de In-

teroperabilidade para Terminais”. Esta implementa funcoes de gestao ao nıvel da

comunicacao entre o cartao e o terminal (coupler) utilizados.

A interface disponibilizada por este nıvel, e independente do leitor, contudo,

internamente utiliza diferentes funcoes para diferentes leitores. Esta camada de

abstraccao torna mais facil o processo de integracao/adicao de diferentes leitores.

Por se tratar de um sistema embebido, todos os modulos acima descritos, utilizam

um outro, designado por “Nıvel de Abstraccao do Sistema Operativo”, ou seja,

camada de abstraccao do sistema operativo. Esta camada permite isolar o software

embebido, do sistema operativo em que e executado (real time operating system),

implementando funcoes de comunicacao, log, timer e substituindo os tipos basicos,

que sao especıficos a determinadas plataformas.


Todos os modulos referidos encontram-se implementados na linguagem C, visto

tratar-se de uma solucao para um sistema embebido que deve correr em sistemas

operativos de recursos limitados como os presentes nos leitores.

No estado actual do “Software de Interoperabilidade para Terminais”, o acesso

aos SAMs so pode ser feito localmente dado que este software nao se encontra

preparado para a comunicacao com os leitores (SAMs) que estejam ligados numa

maquina remota (Figura 5.2)

Figura 5.2: Arquitectura com SAMs locais

5.2.1 Visao Funcional

Como se pode ver pela Figura ?? do Apendice B (Anexo Confidencial), existe

um modulo “Manager” que tem duas listas. Estas contem todos os cartoes e SAMs

(necessarios para a codificacao e descodificacao dos dados, contem os algoritmos

criptograficos e chaves partilhadas) registados.

Cada cartao, por sua vez, tem a sua informacao especıfica e apontadores para

a sua tabela de funcoes, a tabela de funcoes de cada tecnologia utilizada (aponta

para uma zona de memoria nao alocada, “NULL”, caso nao suporte a tecnologia em

causa), para o coupler e para o SAM associados.

Cada SAM contem a sua informacao especıfica e um apontador para o coupler

respectivo. Os couplers, por sua vez, contem a sua informacao especıfica e um

apontador para a tabela de funcoes respectiva. Os couplers do SAM e do cartao,

poderao apontar para a mesma tabela, caso o SAM se encontre dentro do leitor de

cartoes ao inves de estar num dispositivo diferente.

5.3 Solucao pretendida

Para que as alteracoes a efectuar se tornassem uma realidade, verificou-se que para

o efeito bastaria implementar um novo coupler a adicionar a API.


Figura 5.3: Arquitectura com SAMs remotos

Com o recurso as tecnicas anteriormente descritas, o processo de adicao de novos

cartoes e couplers e completamente transparente, sendo desnecessaria qualquer al-

teracao ao codigo ja existente. Para o caso especıfico da adicao do coupler “SOAP”,

a adicao necessaria pode ser visualizada na Figura 5.4.

5.4 Implementacao

O bloco “Remote” corresponde a implementacao do coupler em questao. Foi entao

criado o ficheiro “remote.c”, que contem a respectiva implementacao das funcoes a

disponibilizar ao Nıvel Leitor, isto e, contem a declaracao de uma tabela de apon-

tadores para funcoes “Coupler ftable”, neste caso particular “Remote ftable”, bem

como a implementacao destas funcoes, para o caso especıfico do “Remote”.

Uma vez que o acesso remoto aos SAM e feito via web services, e necessario

gerar todas as classes (os stubs) que permitem invocar objectos remotos. Assim,

integrou-se a implementacao do “Remote Coupler” com stubs de acesso ao Servidor

com Motor de Carregamento Remoto de Tıtulos, mantendo a mesma interface que

todos os couplers do Software de Interoperabilidade para Terminais. O stub (seccao

3.2.7), actua como fachada de invocacao de metodos remotos de forma transparente

a aplicacao, como se de codigo local se tratasse.

Para geracao dos stubs cliente para acesso ao Servidor com Motor de Carrega-

mento Remoto de Tıtulos, foi utilizada a ferramenta gSOAP. Esta ferramenta per-

mite gerar codigo C (stubs) para acesso a web services a partir do WSDL. Na posse

WSDL do Servidor com Motor de Carregamento Remoto de Tıtulos, e possıvel gerar

todo o codigo com o empacotamento e desempacotamento das mensagens SOAP em

estruturas (struct) da linguagem C e ainda os metodos a invocar no servidor.

Para finalizar, de modo a adicionar o suporte a este coupler, foi adicionado ao

ficheiro “api csc.c” que e representado na figura pelo modulo “Leitor)” a entrada


Figura 5.4: Arquitectura da SIT

respectiva na tabela existente (ja explicada anteriormente), ou seja:

#ifdef REMOTE SUPPORT

extern T ICoupler

REMOTE fCouplerTable

#endif

Static T CouplerEntry couplersTable[]=

. . .

#ifdef REMOTE SUPPORT

K CSC REMOTE TYPE, &Soap fCouplerTable

#endif

;

A flag que identifica o suporte do novo coupler “REMOTE SUPPORT” foi entao

adicionada as propriedades do projecto. Esta flag, quando activada, obriga a com-

plicacao do codigo relativo ao “Remote Coupler” originando uma build que suporte

este leitor.

Capıtulo 6

Conclusao

Globalmente, os objectivos inicialmente propostos foram claramente atingidos. As-

sim o trabalho desenvolvido apresenta um benefıcio mutuo que no caso do autor,

traduz-se na satisfacao pessoal e aquisicao de novos conhecimentos. Para a Link

Consulting, significa o enriquecimento da sua plataforma SmartCITIES e alarga-

mento da sua oferta.

As conclusoes do estagio estao divididas em tres partes. A primeira foca o

trabalho desenvolvido. A segunda pretende ser a apreciacao do estagio num computo

geral. A terceira, aflora o trabalho futuro.

6.1 Apreciacao Crıtica do Trabalho Desenvolvido

A primeira fase constituiu a aprendizagem de arquitecturas de integracao e formacao

na plataforma BizTalk Server 2006. Apos esta etapa, o autor teve de integrar uma

equipa de desenvolvimento a trabalhar com a mesma ferramenta. Esta fase permitiu

uma melhor compreensao de arquitecturas e tecnologias de integracao que podem

ser usadas como ferramentas de suporte para os sistemas de mobile ticketing.

A segunda fase, correspondeu a construcao de um prototipo sob a forma de uma

aplicacao movel para acesso aos Servicos de Carregamento de Remoto de Tıtulos.

Correspondeu assim ao perıodo mais intenso e desafiante do estagio uma vez que

o autor nunca havia tido contacto com a maior parte das tecnologias utilizadas.

Foi ultrapassada numa regime de investigacao tendo em conta a muita pesquisa

efectuada sobre os diversos conceitos como Web Services, J2ME, SOAP e como

conjugar os diversos componentes. Deve tambem ser tido em conta, o imaturo estado

das tecnologias de suporte ao consumo de web services por parte de aplicacoes J2ME

a correr dispositivos moveis, dispositivos esses que apresentam limitados recursos de

processamento, memoria e energia.

Na terceira fase, foi desenvolvido um web service para expor os Servicos do Mo-

tor de Carregamento Remoto de Tıtulos. A nıvel tecnologico, nao houve qualquer

44

Capıtulo 6. Conclusao 45

obstaculo dado que as linguagens de programacao utilizadas, o C#, ja sao do co-

nhecimento do autor.

Na ultima fase construiu-se o Remote Coupler para encapsular a localizacao dos

SAMs. Como a linguagem de programacao utilizada foi o C, permitiu um contacto

com a programacao em C sob o paradigma “Object Oriented”’ com o especificacao

de interfaces com recurso a tabelas de apontadores. No meu entender, a licao a

retirar tem a haver com a visao e conceitos aplicados com o low coupling entre

aplicacoes e seus modulos.

6.2 Apreciacao do Estagio

O balanco final da actividade de estagio, e em todas as suas vertentes, positivo.

A integracao na empresa foi feita de forma rapida. Isto deve-se ao ambiente jovem

que se vive Link, bem como um espırito de equipa bastante apurado partilhado por

todos os seus colaboradores. A alta disponibilidade de todos, tambem contribuiu

para a facilidade deste processo.

Pessoalmente, considero-me bastante realizado com o estagio. A constante apren-

dizagem representa outro factor de satisfacao. Esta aprendizagem e consequente do

envolvimento numa equipa de trabalho com colaboradores de nıvel de conhecimento

e experiencia excelentes.

A Licenciatura em Engenharia Informatica da FCUL, foi fundamental para a rea-

lizacao das tarefas propostas ao longo do estagio. Para alem da componente cientıfica

e tecnologica, a constante realizacao de trabalhos em grupo potencia o espırito de

equipa, essencial no desenvolvimento de qualquer tarefa numa organizacao.

6.3 Trabalho Futuro

O trabalho desenvolvido durante o perıodo de estagio, enquadra-se num projecto

de maiores dimensoes que sera a utilizacao da tecnologia de bilhetica , em ou-

tros servicos municipais, como parquımetros e parques de estacionamento fechados.

Como qualquer empresa que pretenda manter a lideranca no mercado deve perspec-

tivar sempre as necessidades futuras do mercado.

Numa visao transversal a todos os sub-projecto envolvidos no estagio, trabalhos

futuros a considerar sao:

• Uma vez que proxima versao do BizTalk Server 2006, denominada ’BizTalk

Server 2006 R2’ integra uma estrutura RFID, um estudo para a integracao

desta plataforma com as APIs da Link podera ser feito com vista a alargar o

conjunto de servicos da plataforma SmartCITIES.

Capıtulo 6. Conclusao 46

• A componente de seguranca pode ser melhorada no que respeita a comunicacao

entre as aplicacoes clientes e os diversos servidores, como o SMCRT (Capıtulo

4) e o Servidor com Motor de Carregamento Remoto de Tıtulos (Capıtulo 3.

• Analisando o modo de funcionamento geral do SMCRT, e possıvel idealizar a

construcao de uma plataforma generica de implementacao de servicos. Esses

servicos/negocios devem respeitar a logica : 1) aquisicao do contracto, 2)va-

lidacao dos tıtulos/contractos. Uma instanciacao de um negocio nessa plata-

forma,por exemplo, poderia ser o da industria do cinema onde fosse possıvel

a compra de bilhetes via telemovel e posterior validacao do bilhete, tambem

com o recurso ao telemovel. Como anteriormente mencionado, esse telemovel

tera que incluir a tecnologia NFC.

• No ambito do projecto ’Aplicacao Cliente de Carregamento Remoto de Tıtulos’,

fica a faltar a implementacao das funcionalidades para pagamentos moveis.

Apendice A

Mapa de Gantt

47

Apendice B

Anexo Confidencial

Devido ao seu caracter confidencial, toda a informacao deste anexo foi omitada na

versao publica do relatorio.

48

Lista de Acronimos

APDU Application Protocol Data UnitAPI Application Program Interface

BI Business Intelligence

CDC Connected Device ConfigurationCDLC Connected Limited Device ConfigurationCDMA Code Division Multiple AccessCRM Customer Relationship Management

EAI Enterprise Application IntegrationECMA European Computer Manufacturers Associa-

tionEPC Electronic Product CodeEPCGlobal Entidade responsavel pela gestao dos EPCsES Elemento SeguroETSI European Telecommunications Standard Ins-

titute

GSM Global System for Mobile communicationGUID Globally Unique Identifier

ICC Integrated Circuit CardIDE Integrated Development EnvironmentIDL Interface Description LanguageINESC Instituto de Engenharia de Sistemas e Com-

putadoresISO International Standards Organization

J2ME Java 2 Micro EditionJ2SE Java 2 Standard EditionJSR Java Specification Request

Middleware Software de interface que permite interaccaode diferentes aplicacoes de software geral-mente sobre diferentes plataformas de hard-ware e infra-estrutura para troca de dados

49

Lista de Acronimos 50

NFC Near Field Communication

PEDIP Programa Especıfico de Desenvolvimento daIndustria Portuguesa

PI Ponto de IntegracaoPIN Personal Identification Number

RACS Remote Application Core ServicesRFID Radio Frequency IDentifierRMI Remote Method InvocationRPC Remote Procedure CallRUIM Cartao usado em telemoveis CDMA para

guardar informacao de identificacao do subs-critor na rede. Equivale aos cartoes SIM nasredes GSM.

SATSA Security and Trust Services Api for J2MESCM Supply Chain ManagementSGBD Sistema de Gestao de Base de DadosSIM Subscriber Identity Module um smart card

que contem o numero de telefone do subscri-tor, detalhes de identificacao na rede codifi-cados, o codigo PIN, bem como outros dadospessoais como a agenda telefonica. O cartaoSIM de um utilizador pode ser movido de te-lefone para telefone dado que contem toda ainformacao necessaria para activar o telefone eidentificar-se perante a rede do seu fornecedordo servico.

SOAP Service Oriented Architecture Protocol

UML Unified Modelling Language

WSDL Web Services Description LanguageWTK Wireless Toolkit

XML eXtensible Markup Language

Indice

JSR-172, 21, 32

JSR-177, 22

Microsoft BizTalk Server 2006, 14

Microsoft Visual SourceSafe, 15

Microsoft Visual Studio 2005, 15

RFID, 18

SGO, 10

51

Bibliografia

[1] [marca] “What Is RFID Middleware and Where Is It Needed?”http://www.rfidupdate.com/articles/?id=1176

[2] Leaver, Sharyn., Mendelsohn, Tamara., Overby, Spivey C. and H. Yuen,Esther.,“Evaluating RFID Middleware , Picking The Right Solution For IntegratingRFID Data Into Business Applications” (13 August.04).

[3] “Understanding Microsoft BizTalk Server 2006”http://www.microsoft.com/biztalk/techinfo/whitepapers/understanding.mspx

[4] “BizTalk RFID: Making RFID Deployments Easy, Simple and Economical”http://msdn2.microsoft.com/en-us/library/aa479354.aspx

[5] “Microsoft RFID Technology Overview”http://www.microsoft.com/industry/retail/businessvalue/rfidoverview.mspx

[6] R. Rieback, Melanie, Crispo, Bruno, Tanenbaum, Andrew S., “Is Your Cat Infectedwith a Computer Virus?”http://www.rfidvirus.org/papers/percom.06.pdf, Computer Systems Group, Vrije Uni-versiteit Amsterdam, Holland.

[7] “EPCGlobal - The EPCglobal Architecture Framework”http://www.epcglobalinc.org/home

[8] “EPCGlobal - RFID Implementation Cookbook”http://www.epcglobalinc.org/what/cookbook/

[9] “Java Community Process: JSR172:J2ME Web Services Specification”(March3,2004),http://www.jcp.org/en/jsr/detail?id=172

[10] C.EnriqueOrtiz: Introduction to J2ME Web Services (April2004),http://developers.sun.com/techtopics/mobility/apis/articles/wsa/

[11] C.EnriqueOrtiz: Web Services APIs for J2ME,Part1 :Remote Service Invocation API(November 2,2004), http://www-106.ibm.com/developerworks/wireless/library/wi-jsr/

[12] C.EnriqueOrtiz: Web Services APIs for J2ME,Part2:Java API for XML Processing(July 20,2004),http://www-128.ibm.com/developerworks/wireless/library/wi-xmlparse/

52

Bibliografia 53

[13] WS-I: Basic Profile Version1.0 (April 16,2004),http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html

[14] SunMicrosystems: J2ME Web Services APIs(WSA)(2005),http://java.sun.com/products/wsa/

faculdade de ciˆencias -...

Documents