• Nenhum resultado encontrado

Smartphones para identificação de pagamentos

N/A
N/A
Protected

Academic year: 2021

Share "Smartphones para identificação de pagamentos"

Copied!
67
0
0

Texto

(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¸

ao

Ricardo Gon¸calves de Santa Ana, aluno no 29191 da Faculdade de Ciˆencias da Universidade de Lisboa, declara ceder os seus direitos de c´opia sobre o seu Relat´orio de Projecto em Engenharia Inform´atica, intitulado ”Smartphones para Identifica¸c˜ao e Pagamentos”, realizado no ano lectivo de 2006/2007 `a Faculdade de Ciˆencias da Universidade de Lisboa para o efeito de arquivo e consulta nas suas bibliotecas e publica¸c˜ao do mesmo em formato electr´onico na Internet.

FCUL, 17 de Setembro de 2007

Jo˜ao Miguel Correia da Silva Carreira Almeida, supervisor do projecto de Ri-cardo Gon¸calves de Santa Ana, aluno da Faculdade de Ciˆencias da Universidade de Lisboa, declara concordar com a divulga¸c˜ao do Relat´orio do Projecto em Engenharia Inform´atica, intitulado ”Smartphones para Identifica¸c˜ao e Pagamentos”.

(6)
(7)

Nota sobre Confidencialidade

Este documento representa a vers˜ao p´ublica do relat´orio ”Smartphones para Identifica¸c˜ao e Pagamentos”.

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

Para esse efeito, toda a informa¸c˜ao confidencial foi devidamente assinalada no relat´orio e colocada em um anexo, o B, omitido nesta vers˜ao do relat´orio.

(8)

Este documento descreve o projecto realizado no ˆambito da disciplina Projecto em Engenharia Inform´atica do Mestrado em Engenharia Inform´atica da Faculdade de Ciˆencias 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˜oes inteligentes, apesar de n˜ao serem uma novidade tecnol´ogica, come¸cam agora a chegar ao dom´ınio das aplica¸c˜oes do grande p´ublico, nomeadamente na ´area banc´aria e da identifica¸c˜ao pessoal. Estes dispositivos, que para muitos ainda s˜ao uma pequena evolu¸c˜ao dos cart˜oes com banda magn´etica, s˜ao reais computadores que a progress˜ao da tecnologia de micro electr´onica ir´a dotar rapidamente de capaci-dade de processamento e mem´oria, possibilitando o armazenamento e tratamento de mais informa¸c˜ao, e sobretudo permitindo a sua interliga¸c˜ao atrav´es de um crescente n´umero de tecnologias de comunica¸c˜ao. Os cart˜oes nas suas m´ultiplas vertentes de Smart Card, RFID e dispositivos m´oveis, podem tornar-se dispositivos capilares nas futuras redes permitindo identificar, localizar, autenticar e armazenar informa¸c˜ao 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: J2METMWeb 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´etodos a Disponibilizar . . . 35 4.3 Implementa¸c˜ao . . . 37 5 Remote Coupler 39 5.1 Objectivo . . . 39 5.2 Situa¸c˜ao Inicial . . . 39 5.2.1 Vis˜ao Funcional . . . 41 5.3 Solu¸c˜ao pretendida . . . 41 5.4 Implementa¸c˜ao . . . 42 6 Conclus˜ao 44 6.1 Aprecia¸c˜ao 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 52

(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¸

ao

O projecto integra-se num roadmap de desenvolvimento de inova¸c˜oes e futuros m´odulos de plataforma de electronic ticketing, que consiste num sistema integrado e modular, para a implementa¸c˜ao de sistemas de mobile ticketing, aplicada ao cart˜ao SmartCard Dual-Interface com microprocessador, SmartCard Contactless de mem´oria.

1.1

Motiva¸

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˜ao na escolha do tema a abordar no PEI. Esta disciplina representa o culminar do processo de gradua¸c˜ao de um aluno do curso de Engenharia Inform´atica da FCUL pelo que deve ser abordada, de ˆanimo n˜ao leve.

Trantando-se de uma decis˜ao n˜ao trivial, a motiva¸c˜ao para a escolha do tema “Smartphones para Identifi¸c˜ao e Pagamentos” foi baseada nos crit´erios que se se-guem:

- O grau de interesse no tema e o auto-desafio de intervir numa `area tecnol´ogica que apesar de n˜ao ser recente, ´e actualmente emergente.

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

1.2

Contexto Cient´ıfico e Tecnol´

ogico

A generaliza¸c˜ao dos Smartcards Contactless aplicados `a bilh´etica (ticketing) para transportes ´e uma realidade. Em Lisboa existem actualmente j´a 1,3 milh˜oes de cart˜oes em circula¸c˜ao. A aplica¸c˜ao da mesma tecnologia ao turismo ´e tamb´em j´a uma realidade com a implementa¸c˜ao do Cart˜ao 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˜ao de uma Metodologia de Enterprise Architecture na fase de an´alise de processos de neg´ocio, para depois seguir com a aplica¸c˜ao de Frameworks de Software Embedded na fase de implementa¸c˜ao dos sistemas de ticketing baseados em contactless smartcards.

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

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

Assim, um moderno sistema de bilh´etica (ticketing) deve basear-se numa tecno-logia aberta, segura, fi´avel e ergon´omica 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 matura¸c˜ao, ´e o SmartCITIES, para implementa¸c˜ao de Smart Cards contactless dual-interface. Este sistema ´e baseados no sistema de opera¸c˜ao e seguran¸ca da tecnologia Calypso, que junta num mesmo cart˜ao com chip a ergono-mia de uma transac¸c˜ao contactless, e a seguran¸ca e baixo custo da transac¸c˜ao que pode realizar-se off-line.

A emiss˜ao de um conjunto Smart Cards personalizados, ou mesmo smart-tickets n˜ao personalizados, permite a elimina¸c˜ao de parte dos custos associados `a gest˜ao 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´agio enquadra-se, essencialmente, na evolu¸c˜ao de componentes que interajam com os m´odulos do Servidor com Motor de Carregamento Remoto de T´ıtulos e nos aspectos relacionados com a aplica¸c˜ao 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¸

ao e Metodologia

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

1.4.1

A Link Consulting

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

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

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

A Link Consulting teve origem (ver Figura 1.1) na transforma¸c˜ao em estru-tura empresarial dos Centros de Transferˆencia de Tecnologia do INESC da ´area de Relat´orio Final – Curso de Especializa¸c˜ao Profissional em Engenharia Inform´atica Inform´atica 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 Multim´edia, o Suporte `a Decis˜ao, 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´atica e Computadores, no contexto da reorganiza¸c˜ao das actividades do INESC, decidiram os respectivos s´ocios efectuar o spin-off destas actividades numa ´unica empresa, que veio a dar origem `a Link Consulting SA, cujo prop´osito foi procurar desenvolver este patrim´onio t´ecnico.

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 ´e uma empresa ´unica que consegue conjugar a experiˆencia de 15 anos de actividade em algumas das maiores empresas nacionais e internacio-nais assim como a Inova¸c˜ao resultante da associa¸c˜ao ao INESC, o mais prestigiado Instituto Portuguˆes de I&D em Tecnologias da Informa¸c˜ao.

(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˜ao naturalmente aqueles onde existe maior dinˆamica econ´omica e onde maior n´umero de projectos tˆem sido realizados:

1. Administra¸c˜ao P´ublica 2. Floresta 3. Log´ıstica 4. Telecomunica¸c˜oes 5. Servi¸cos Financeiros 6. Sa´ude

1.5

Planeamento

O planeamento definido para o est´agio est´a brevemente descrito na Figura 1.3. O mapa de Gantt correspondente ao planeamento pode ser consultado nos Apˆendice A.

1.6

Organiza¸

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˜ao no est´agio. Este projecto, como o nome indica, resolve um problema de integra¸c˜ao de aplica¸c˜oes de uma organiza¸c˜ao, por sua vez, cliente da Link.

• O Cap´ıtulo 3 Aplica¸c˜ao Cliente de Carregamento Remoto de T´ıtulos. Des-creve o prot´otipo da aplica¸c˜ao m´ovel, desenvolvida para estudo das necessi-dades dos novos m´odulos a desenvolver bem como poss´ıveis altera¸c˜oes nos j´a existentes para que aplica¸c˜oes m´oveis possam aceder ao Servidor com Motor de Carregamento Remoto de T´ıtulos. ´E tamb´em este cap´ıtulo que foca o tema do est´agio.

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˜ao e elac¸c˜oes retiradas de todo o projecto bem como uma descri¸c˜ao do trabalho futuro.

(21)

Cap´ıtulo 2

Enterprise Application Integration

Este cap´ıtulo, tem como prop´osito documentar o trabalho de integra¸c˜ao na empresa, realizado na Fase 1 do planeamento do est´agio (Figura 1.3). Serviu ainda de base para a aprendizagem das solu¸c˜oes e arquitecturas que servem de suporte `a integra¸c˜ao das solu¸c˜oes de mobile ticketing tendo em conta que ´e igualmente necess´aria uma arquitectura de backoffice que suporte a integra¸c˜ao de todos os sistemas envolvidos neste cen´ario.

2.1

Enquadramento

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

2.1.1

EAI - Enterprise Application Integration

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

Durante gera¸c˜oes, os sistemas foram constru´ıdos para servirem um ´unico prop´osito e para um conjunto espec´ıfico de utilizadores e ainda sem tomarem em linha de

(22)

conta a integra¸c˜ao dos mesmos sistemas, com outros de ainda maiores dimens˜oes e m´ultiplas aplica¸c˜oes. EAI ´e a solu¸c˜ao para o resultado n˜ao antecipado do de-senvolvimento de aplica¸c˜oes sem uma vis˜ao central em mente. O que as empresas pretendem ´e partilhar dados e processos sem terem de realizar altera¸c˜oes profundas nas suas aplica¸c˜oes ou na estrutura dos dados. S´o com a cria¸c˜ao de um m´etodo para atingir este tipo de integra¸c˜ao ´e que EAI pode ser tanto funcional e economicamente vi´avel.

Um dos grandes desafios que as organiza¸c˜oes modernas enfrentam, ´e o de pro-videnciar a todos os seus colaboradores um acesso completo, transparente e em tempo-real `a informa¸c˜ao. Muitos dos sistemas legados, ainda hoje utilizados, foram desenvolvidos usando tecnologias propriet´arias e hoje consideradas arcaicas e por vezes de dif´ıcil integra¸c˜ao com outros sistemas. Como consequˆencia s˜ao criados “si-los” de informa¸c˜ao dispersos pelos departamentos das organiza¸c˜oes. Esses sistemas, dificultam o movimento coerente da informa¸c˜ao de uma aplica¸c˜ao 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˜oes pr´o-activas. Tem tamb´em a inten¸c˜ao de superar o simples objectivo de inter-ligar aplica¸c˜oes e facilita o aparecimento de novas formas de potenciar o conhecimento organizacional que pode ser aplicado na cria¸c˜ao de novas vantagens competitivas para a empresa.

Pode dizer-se que com um sistema de integra¸c˜ao a que o valor soma do n´umero 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 importˆancia ao EAI por parte das empresas porque nestas a computa¸c˜ao tem frequentemente tomado a forma de “ilhas de au-toma¸c˜ao”. Isto ocorre quando o valor individual dos sistemas n˜ao ´e maximizado, devido a um isolamento total ou parcial dos restantes sistemas da empresa. Se a integra¸c˜ao for aplicada sem uma aproxima¸c˜ao EAI estruturada, as liga¸c˜oes “ponto-a-ponto” crescem ao longo da organiza¸c˜ao. S˜ao acrescentadas dependˆencias sem uma base definida, resultando numa malha de dif´ıcil manuten¸c˜ao. Este problema ´e frequentemente denominado de “esparguete”, uma alus˜ao ao equivalente `a pro-grama¸c˜ao do c´odigo-esparguete. Por exemplo:

Sendo n o n´umero de sistemas, o n´umero de liga¸c˜oes necess´arias para ter uma malha completa de liga¸c˜oes ponto-a-ponto ´e dado pela f´ormula

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˜ao se singe apenas `a partilha de dados entre aplica¸c˜oes. Foca tamb´em a partilha de dados do neg´ocio e seus processos. Atender a EAI, inclui uma vis˜ao

(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˜oes de uma organiza¸c˜ao, com uma metodologia focada na integra¸c˜ao de processos e dados, permitindo `as organiza¸c˜oes 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˜ao de liga¸c˜oes “ponto-a-ponto”, o EAI gera as liga¸c˜oes entre sistemas o que permite a redu¸c˜ao de custos de gest˜ao;

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

3. ´E poss´ıvel construir novas aplica¸c˜oes tendo por base aplica¸c˜oes j´a 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˜ao das “ilhas” de informa¸c˜ao isoladas, permitindo uma gest˜ao 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˜ao de reutiliza¸c˜ao, bem como de distribui¸c˜ao de processos de neg´ocio e dados;

9. Implementa¸c˜ao de um ponto ´unico de comunica¸c˜ao entre as diferentes aplica¸c˜oes, virtualizando a interface adequada a cada uma delas, e implementando as transforma¸c˜oes de dados necess´arias `a troca de informa¸c˜ao;

(24)

10. Comunica¸c˜ao entre as v´arias aplica¸c˜oes usando mensagens, formalizando o conte´udo de cada uma delas e facilitando o tratamento e encaminhamento da informa¸c˜ao para os destinos adequados;

11. Utiliza¸c˜ao de um mecanismo de encaminhamento de mensagens que permite um interface ´unico para as trocas de informa¸c˜ao em batch, assim como a integra¸c˜ao transaccional on-line de v´arios sistemas distintos;

12. Possibilidade de tratar encadeamentos de fluxos de informa¸c˜ao (workflow) en-tre as v´arias aplica¸c˜oes de forma a suportar cadˆencias de processos complexos;

2.2

O problema

O cliente possui seis sistemas independentes e heterog´eneos (Figura 2.2) aos quais pretende integrar uma nova aplica¸c˜ao fornecida pela Link, o (Sistema de Gest˜ao de Opera¸c˜oes) (Figura 2.3).

Figura 2.2: Sistemas do cliente

2.3

Objectivo

Este projecto surge como sub-objectivo de um prop´osito mais alargado que ´e a implementa¸c˜ao de um sistema de bilh´etica sem contacto. ´E com vista a atingir esse sub-objectivo que surge a necessidade de sincronizar informa¸c˜ao entre os diversos sistemas. A infra-estrutura de middleware a implementar, destina-se a suportar o fluxo de dados entre as v´arias aplica¸c˜oes intervenientes nos processos da ´area de opera¸c˜oes.

(25)

Cap´ıtulo 2. Enterprise Application Integration 11

2.4

Arquitectura da Solu¸

ao

Para a integra¸c˜ao dos v´arios sistemas actualmente existentes no cliente, e os novos sistemas a desenvolver no ˆambito deste projecto, foi proposta a utiliza¸c˜ao de um Middleware EAI (Enterprise Application Integration) (Figura 2.3). Este proporciona uma camada interm´edia para simplificar a integra¸c˜ao e partilha de informa¸c˜ao entre sistemas, aumentando a flexibilidade e a velocidade em que a informa¸c˜ao ´e partilhada entre as diferentes aplica¸c˜oes e reduzindo o custo total da solu¸c˜ao (nomeadamente ao n´ıvel da manuten¸c˜ao e n´umero de conex˜oes).

Figura 2.3: Arquitectura da solu¸c˜ao

A utiliza¸c˜ao de uma ferramenta EAI, permite virtualizar a camada de integra¸c˜ao entre aplica¸c˜oes atrav´es de uma plataforma de distribui¸c˜ao de mensagens. Desta forma, cada aplica¸c˜ao vˆe um ´unico ponto de integra¸c˜ao com a plataforma EAI, in-dependentemente das aplica¸c˜oes que est˜ao a jusante. A distribui¸c˜ao, transforma¸c˜ao e gest˜ao 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 integra¸c˜ao entre as diferentes aplica¸c˜oes. Para implementar o Middleware EAI foi proposto o produto BizTalk Server 2006, cujo modo de funcionamento ´e apresentado na Figura 2.4.

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

(26)

Figura 2.4: Funcionamento do BizTalk Server 2006

configuradas atrav´es do Visual Studio 2005, contendo ainda o BizTalk uma s´erie de ferramentas para administra¸c˜ao (BizTalk Server Administration), monitoriza¸c˜ao (“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´acil inte-gra¸c˜ao entre os sistemas, recorrendo a uma plataforma bastante robusta e flexibili-dade, que potencia a integra¸c˜ao de futuros sistemas que o cliente venha a ter, e/ou permite facilmente altera¸c˜oes `a l´ogica das integra¸c˜oes j´a desenvolvidas.

Durante a fase de an´alise, foi identificada a informa¸c˜ao a sincronizar entre os sistemas e ainda identificados a origem e destino dessa informa¸c˜ao. A informa¸c˜ao que cada sistema deve publicar, d´a 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˜ao, ´e criado um outro documento com a ’Interface’ do sistema de origem e as ’Interfaces’ dos sistemas destino que inclui as regras de convers˜ao e/o neg´ocio a aplicar.

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

2.4.1

Ponto de Integra¸

ao

Para efeitos de implementa¸c˜ao, considera-se um Ponto de Integra¸c˜ao como sendo a unidade b´asica de um conjunto de integra¸c˜oes. Um Ponto de Integra¸c˜ao, consiste na especifica¸c˜ao dos sistemas de entrada e sa´ıda, ou Publisher e Subscriber, de um bloco

(27)

Cap´ıtulo 2. Enterprise Application Integration 13

Figura 2.5: Publish-Subscribe

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

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

Na qualidade de developer, fui incumbido de implementar os v´arios PIs. No Biz-Talk Server 2006, a implementa¸c˜ao de um PI corresponde `a constru¸c˜ao dos schemas (mensagens) de entrada e sa´ıda do sistemas (Figura 2.8), os mapeamentos (trans-forma¸c˜ao de dados) entre mensagens correspondentes (Figura 2.9), as orquestra¸c˜oes com a l´ogica de dispers˜ao das mensagens e a configura¸c˜ao dos canais de comunica¸c˜ao (portas e adaptadores).

(28)

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

Publisher Subscriber Integra¸c˜ao Adaptador Pub/Sub Scheduler SAE DW INTEGRAC¸ ˜AO A ODBC/ODBC Di´aria 03H00 SAE SGO INTEGRAC¸ ˜AO A ODBC/ODBC Di´aria 03H00 ERP DW INTEGRAC¸ ˜AO B ODBC/ODBC Di´aria 20H00 ERP SAE INTEGRAC¸ ˜AO B ODBC/ODBC Di´aria 20H00 ERP SGO INTEGRAC¸ ˜AO B ODBC/ODBC Di´aria 20H00 ERP Planeamento INTEGRAC¸ ˜AO 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´aves da configura¸c˜ao do scheduler (escalonador) do BizTalk Ser-ver 2006 para que este Ser-verifique, com determinada periodicidade, a existˆencia de novos dados. Este modo ´e tamb´em referido como pooling;

Manual – quando uma integra¸c˜ao ´e invocada a pedido (interven¸c˜ao humana). Para desencadear este processo, foi desenvolvida uma aplica¸c˜ao, o Integration Laun-cher, que invoca uma integra¸c˜ao 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˜oes de integra¸c˜ao desenvolvidas. De seguida s˜ao 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)

Cap´ıtulo 2. Enterprise Application Integration 15

Maps – representa a transforma¸c˜ao a efectuar entre duas mensagens. Cont´em um Extensible Stylesheet Language (XSL) que inclui as defini¸c˜oes dos mapeamen-tos a efectuar sobre o conte´udo 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 – ´e o agrupamento l´ogico de send ports que podem ser usados para enviar uma determinada mensagem para v´arios 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

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

DB2

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

CVS

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

Figura 2.8: Exemplo de um Schema para BizTalk Server 2006

(31)

Cap´ıtulo 3

Aplica¸

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˜ao apresentadas as tecnologias de base para a constru¸c˜ao do prot´otipo, ”Aplica¸c˜ao Cliente de Carregamento de T´ıtulos”.

Na descri¸c˜ao do prot´otipo, pretende-se explicar o alinhamento das diferentes tec-nologias que possibilita a constru¸c˜ao de aplica¸c˜oes para identifica¸c˜ao e pagamentos. O desenvolvimento desde projecto teve lugar na Fase 2 do planeamento do est´agio (Figura 1.3).

3.1

Objectivo

O projecto integra-se num roadmap de desenvolvimento de inova¸c˜oes e futuros m´odulos de plataforma de electronic ticketing da Link. Neste ˆambito, pretende-se implementar um prot´otipo de uma aplica¸c˜ao m´ovel 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 cart˜ao que se assemelha a um cart˜ao de cr´edito e que tem um circuito inte-grado para armazenar dados. Apesar de existirem in´umeras aplica¸c˜oes, destacam-se duas: cart˜oes de mem´oria, que apenas cont´em componentes de memoria de arma-zenamento n˜ao vol´atil e por vezes alguma l´ogica de seguran¸ca e os cart˜oes com microprocessadores, que contˆem componentes de mem´oria e microprocessadores.

(32)

A percep¸c˜ao de Smart Card ´e a de um cart˜ao que cont´em um microprocessador e que tem um tamanho aproximadamente igual a um cart˜ao de cr´edito (ou menor, por exemplo, o cart˜ao SIM das redes GSM). As propriedades deste cart˜ao incluem a resistˆencia a intrus˜ao (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˜ao guardada em mem´oria). Nem todos os ICCs possuem um microprocessador (por exemplo, cart˜oes de mem´oria), conse-quentemente nem todos os ICCs s˜ao necessariamente Smart Cards. Contudo, o uso da terminologia por parte do p´ublico 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 diˆametro na parte frontal. Quando ´e inserido num leitor de cart˜oes apropriado, o chip entra em contacto com os conectores electr´onicos que conseguem ler e actualizar a informa¸c˜ao do chip.

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

• A forma f´ısica.

• A posi¸c˜ao f´ısica e forma dos conectores el´ectricos. • As caracter´ısticas el´ectricas.

• 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˜oes deste tipo n˜ao contˆem bateria, a energia ´e fornecida pelo leitor.

Contactless Smart Cards

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

(33)

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

O standard para a comunica¸c˜ao deste tipo de cart˜oes ´e o ISO/IEC 14443, datado de 2001. Este standard define dois tipos de cart˜oes sem contacto (A e B), permite comunica¸c˜oes at´e 10 cm de distˆancia 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˜oes sem contacto ´e o ISO 15693, que permite comunica¸c˜oes a uma distancia de 50 cm.

Um exemplo do uso deste tipo tecnologia ´e o projecto LisboaViva que utiliza estes cart˜oes para controlar as entradas e sa´ıdas na rede de transportes p´ublicos de Lisboa.

Vantagens e Desvantagens dos Smart Cards

A utiliza¸c˜ao de Smart Cards tr´as in´umeras vantagens, n˜ao s´o para o utilizador, como para a seguran¸ca dos sistemas que os utilizam e o poder computacional.

As vantagens para o utilizador s˜ao a facilidade de usar e ter informa¸c˜ao port´atil, podendo os dados do utilizador ficarem guardados no cart˜ao.

Ao n´ıvel da seguran¸ca, as vantagens s˜ao in´umeras. A informa¸c˜ao armazenada no cart˜ao, pode estar protegida para leitura e/ou escrita atrav´es de um c´odigo PIN ou dados biom´etricos. Os dados guardados, por sua vez, podem estar encriptados. Cada cart˜ao possui um n´umero de s´erie ´unico.

O poder computacional ´e grande, pois este tipo de cart˜oes, tˆem capacidade de processamento e de comunica¸c˜ao com outros terminais. Esta comunica¸c˜ao ´e feita atrav´es da liga¸c˜ao a um leitor de Smart Cards, podendo a informa¸c˜ao e aplica¸c˜oes em causa, serem actualizadas, sem haver a necessidade de serem emitidos novos cart˜oes ou bilhetes.

Apesar dos Smart Cards apresentarem in´umeras vantagens, tamb´em tˆem algu-mas desvantagens. Estas resultam principalmente da falta de interoperabilidade ao n´ıvel de cart˜oes e da falta de standards ao n´ıvel do desenho.

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

As desvantagens apresentadas, impossibilita a utiliza¸c˜ao do mesmo cart˜ao em diferentes pa´ıses ou aplica¸c˜oes.

3.2.2

Tecnologia Calypso

Um cart˜ao Calypso ´e um Smart Card que permite a verifica¸c˜ao e transferˆencia de direitos de transporte, tal como os passes/t´ıtulos de transportes do metropolitano de Lisboa. O cart˜ao pode conter v´arias informa¸c˜oes, tais como, informa¸c˜ao acerca do utilizador (dono do cart˜ao), o ´ultimo acesso ao cart˜ao, etc.

(34)

Como o direito de entrada, por exemplo numa rede do metro, acarreta valores monet´arios, a sua utiliza¸c˜ao ´e protegida por algoritmos, prevenindo assim poss´ıveis forjadores de produzirem cart˜oes falsos ou carregar um cart˜ao sem a devida auto-riza¸c˜ao.

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

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

Os cart˜oes Calypso, permitem a utiliza¸c˜ao do algoritmo DES (um m´etodo de encriptar informa¸c˜ao), 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˜oes falsos e carregamentos n˜ao autoriza-dos.

3.2.3

Near Field Communication

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

Permite, de forma simples e segura, uma interac¸c˜ao bi-direccional entre disposi-tivos permitindo ao utilizador efectuar transac¸c˜oes sem contacto, aceder a conte´udo digital e conectar dispositivos com um ‘simples toque’.

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

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

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 distˆancias mais curtos e

(35)

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

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

As diversas fun¸c˜oes 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´oveis, abre portas para um novo mundo de aplica¸c˜oes a construir. Os seus principais benef´ıcios e potencialidades s˜ao:

• 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´udo digital entre dispositivos atrav´es da sua aproxima¸c˜ao • 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¸

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˜ao projectadas com a inten¸c˜ao 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˜ao das exigˆencias do software.

3.2.5

JSR-172: J2ME

TM

Web Services Specification

O objectivo global da JSR-172 ´e acrescentar duas novas capacidades `a plataforma J2ME que s˜ao:

• 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´avel, ´e que os dados estruturados enviados para os dispositivos m´oveis pelas aplica¸c˜oes existentes estejam sob a forma XML. De forma a evitar a inclus˜ao de c´odigo que processa-se esses dados em cada aplica¸c˜ao m´ovel, ´e desej´avel a defini¸c˜ao 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´a ser evitado a cria¸c˜ao de novos formatos e protocolos de comunica¸c˜ao 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˜ao Security and Trust Services API (SATSA), define os pacotes opcio-nais para a plataforma Java 2 Micro Edition (J2ME).Esta especifica¸c˜ao, foi elabo-rada em resposta ao pedido de especifica¸c˜ao, Java Specification Request 177 (JSR-177). O seu prop´osito, ´e especificar uma colec¸c˜ao de APIs que ofere¸cam servi¸cos de seguran¸ca (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 protec¸c˜ao dos dados sens´ıveis como chaves pri-vadas, chaves p´ublicas, credenciais de acesso a servi¸cos, informa¸c˜ao pessoal, entre outros;

(37)

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

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

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

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

Alternativamente, um ES pode ser implementado por software. Esta especi-fica¸c˜ao n˜ao exclui qualquer implementa¸c˜ao 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˜ao com smart card com recurso ao protocolo APDU. Os Smart Cards oferecem um am-biente seguro de programa¸c˜ao. ´E 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˜ao e gest˜ao b´asica de credenciais do utilizador. Para potenciar uma maior reutiliza¸c˜ao, esta API ´e independente do tipo de ES utilizado. As assinaturas digitais usadas para autenticar os utilizadores ou autorizar transac¸c˜oes que utilizem uma criptografia de chave p´ublica.

SATSA-CRYPTO – Este pacote opcional ´e um sub-conjunto da API de crip-tografia do vers˜ao J2SE. Providencia opera¸c˜oes b´asicas de criptografia para suportar Message Digest, verifica¸c˜ao 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.

1JavaCardRMI est´a definida na especifica¸ao da plataforma Java Card 2.2

(38)

3.2.7

No¸

ao de Stub

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

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 necess´aria a implementa¸c˜ao de um proto-colo de comunica¸c˜ao respons´avel pela correcta transferˆencia de controlo entre quem invoca a opera¸c˜ao (o cliente) e o servidor remoto que ir´a executar a opera¸c˜ao pre-tendida. O seu modelo de execu¸c˜ao est´a esquematicamente representado na Figura 3.3.

Figura 3.3: Modelo de Execu¸c˜ao

Para al´em do controlo das opera¸c˜oes, este deve suportar a transferˆencia de quais-quer argumentos necess´arios `a execu¸c˜ao da opera¸c˜ao e do retorno para o cliente de um qualquer resultado. Este mecanismo ´e denominado “chamada a fun¸c˜oes remo-tas” (RPC – remote procedure call) e representa uma extens˜ao da tradicional no¸c˜ao de chamada a fun¸c˜oes para um ambiente distribu´ıdo.

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

(39)

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

pons´avel pela execu¸c˜ao local da opera¸c˜ao invocada. Estes fragmentos s˜ao conhecidos como: o cliente, o stub do cliente, o transporte RPC, o stub do servidor e o servidor. A representa¸c˜ao esquem´atica destes fragmentos aparece representada na Figura 3.4

Figura 3.4: Passos de uma Chamada Remota de Procedimentos

O cliente e servidor s˜ao ambos desenhados e implementados como se as aplica¸c˜oes fossem para correr num ambiente centralizado tradicional. A fun¸c˜ao dos stubs do cliente e servidor ´e “esconder” o mais poss´ıvel a distribui¸c˜ao 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´es de um gerador autom´atico de c´odigo.

O gerador produz o c´odigo do stub, na linguagem desejada, atrav´es de uma linguagem de defini¸c˜ao 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´em disso, como estas IDL’s s˜ao tipicamente mais restritivas, podem incutir no programador uma abstrac¸c˜ao 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˜ao. Podem ainda aumentar a linguagem com funcionalidades n˜ao dispon´ıveis `a partida; por exemplo, permitindo o uso de novos tipos como strings e arrays dinˆamicos, ou construtores como os de tratamento de excep¸c˜oes.

Contudo, as desvantagens s˜ao 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ˆencia. Esta alternativa torna tamb´em poss´ıvel que a IDL n˜ao corresponda ao que est´a 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´odigo relati-vamente diferente para o servidor (alterando, por exemplo, o nome das fun¸c˜oes), comparativamente ao j´a existente na solu¸c˜ao original, n˜ao distribu´ıda.

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

De modo geral, a gera¸c˜ao de stubs envolve v´arios problemas que assentam prin-cipalmente na inexistˆencia de uma mem´oria partilhada, entre o cliente e o servidor. Desta situa¸c˜ao podem advir os seguintes problemas:

• Heterogeneidade das m´aquinas. Diferentes m´aquinas podem ter diferentes representa¸c˜oes bin´arias dos variados tipos primitivos. Por exemplo, diferente ordena¸c˜ao de bytes e representa¸c˜ao de v´ırgulas flutuantes; diferentes precis˜oes aritm´eticas (16 vs. 32 bit); representa¸c˜oes de v´ırgulas pouco usuais, etc.

A solu¸c˜ao 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˜ao. Esta convers˜ao tem custos considerados e ´e desnecess´aria entre m´aquinas do mesmo tipo. Contudo ´e uma solu¸c˜ao simples que resolve os problemas existentes num ambiente heterog´eneo.

• Transferˆencia de parˆametros e tipos. Diferentes linguagens apresentam dife-rentes semˆanticas na passagem de parˆametros, como as invoca¸c˜oes por valor e por referˆencia. Os procedimentos remotos for¸cam normalmente um processo de “copy-in”, “copy-out” para a passagem de parˆametros, que nem sempre coincide com a semˆantica do mecanismo local para a passagem de parˆametros. Al´em 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˜ao modernas, permitem a cria¸c˜ao de estruturas de dados que contˆem 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˜ao do stub que tem de fazer o marshall de toda a estrutura, quando apenas um dos seus elementos ´e passado como parˆametro. Estruturas circulares s˜ao 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)

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

s´o acontecem quando a globalidade da aplica¸c˜ao 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 padr˜ao “Factory Design Pattern” ´e um padr˜ao de desenho das linguagens de pa-radigma Object-Oriented. Insere-se no conjunto de padr˜oes de cria¸c˜ao ,‘ ‘Creational Patterns”. Este padr˜ao, retorna uma entre muitas instˆancias de classes poss´ıveis, dependendo das parˆametros passados. Normalmente, todas as classes que retorna, tˆem 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´etodo de fabrica¸c˜ao) que retorna o objecto da classe Product (produto). Este elemento tamb´em pode definir uma im-plementa¸c˜ao b´asica que retorna um objecto de uma classe ConcreteProduct (produto concreto) b´asica;

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˜ao ´e muito utilizado em frameworks para definir e manter rela¸c˜oes entre objectos.

(42)

3.3

Situa¸

ao Inicial

Uma vez que se trata de um projecto de desenvolvimento de inova¸c˜oes e futuros m´odulos da plataforma de electronic ticketing, o desej´avel seria desenvolver um prot´otipo cuja implementa¸c˜ao se encontre o mais pr´oximo poss´ıvel da realidade, ou seja, uma aplica¸c˜ao m´ovel 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˜oes JSR 172 (sec¸c˜ao 3.2.5) e JSR177 (sec¸c˜ao 3.2.6 ). Quando carregados os t´ıtulos, os testes poderiam ser feitos nas aplica¸c˜oes da link para verifica¸c˜ao dos contratos, validando assim a prova-de-conceito (proof-of-concept ) a efectuar.

3.4

Situa¸

ao Actual

Uma vez que n˜ao foi poss´ıvel recepcionar o dispositivo com esses requisitos, no per´ıodo calendarizado para a execu¸c˜ao do projecto, a solu¸c˜ao passou por simular todo o processo recorrendo ao emulador de um telem´ovel, 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

Implementa¸

ao

3.5.1

Interface APDUConnection

Esta interface define uma liga¸c˜ao APDUConnection (Application Protocol Data Unit). As aplica¸c˜oes J2ME podem usar esta liga¸c˜ao para comunicar com aplica¸c˜oes

(43)

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

Figura 3.7: Arquitectura da situa¸c˜ao final

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

´

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

Em seguida ´e apresentado o sum´ario dos m´etodos especificados nesta interface.

• byte[] changePin(intpinID) ´

E um m´etodo de alto n´ıvel que permite `as aplica¸c˜oes J2ME solicitarem ao utilizador o c´odigo PIN para altera¸c˜ao e enviar ao cart˜ao

• byte[] disablePin(int pinID) ´

E um m´etodo de alto n´ıvel que permite `as aplica¸c˜oes J2ME solicitarem ao utilizador o c´odigo PIN a ser desabilitado e enviar para o cart˜ao.

• byte[] enablePin(int pinID) ´

E um m´etodo de alto n´ıvel que permite `as aplica¸c˜oes J2ME solicitarem ao utilizador o c´odigo PIN a ser reabilitado e enviar para o cart˜ao.

• byte[] enterPin(int pinID) ´

E um m´etodo de alto n´ıvel que permite `as aplica¸c˜oes J2ME solicitarem ao utilizador o c´odigo PIN a ser verificado e enviar para o cart˜ao.

(44)

M´etodo para enviar uma ’APDU Commando’ para uma aplica¸c˜ao do cart˜ao 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´etodo de alto n´ıvel que permite `as aplica¸c˜oes J2ME solicitarem ao utilizador a introdu¸c˜ao do c´odigo PIN de desbloqueio e o novo valor do c´odigo PIN bloqueado para envi´a-los ao cart˜ao.

´

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

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

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

Isto facilita a constru¸c˜ao de v´arias classes de comunica¸c˜ao com os diferentes lei-tores suportados pelo Software de Interoperabilidade para Terminais sem a altera¸c˜ao das aplica¸c˜oes cliente uma vez que todas as classes implementam a mesma interface.

(45)

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

3.5.2

Arquitectura da Solu¸

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˜ao de referˆencia da interface JSR172 (Sec¸c˜ao 3.2.5). Foi usada para a invoca¸c˜ao dos m´etodos do Servidor com Motor de Carrega-mento Remoto de T´ıtulos. Como anteriormente referido, esta API permite `as aplica¸c˜oes m´oveis o consumo de Web Services.

Stubs -– Classes com toda a l´ogica de empacotamento e desempacotamento dos m´etodos e estruturas de dados do Servidor com Motor de Carregamento Re-moto de T´ıtulos. Para mais informa¸c˜oes sobre stubs ver sec¸c˜ao 3.2.7.

APDU Connection — Implementa¸c˜ao da Interface APDUConnection da especi-fica¸c˜ao JSR177 (sec¸c˜ao 3.2.6)para a comunica¸c˜ao com os cart˜oes 3.5.1. Aqui foi desenvolvido todo o c´odigo de inicializa¸c˜ao dos leitores, ou seja abertura das portas COM necess´arias. Deve ser transparente `a Midlet para que possa suportar diferentes tipos de leitores. Isto torna a l´ogica da aplica¸c˜ao inde-pendente do dispositivo usado. Consequentemente, o envio de APDUs para o cart˜ao SIM , por parte da Midlet ´e concretizado de forma simulada.

Midlet — Que corresponde `a aplica¸c˜ao J2ME com toda a l´ogica de instancia¸c˜ao do “Stubs”, ’APDUConnection’ e invoca¸c˜ao dos m´etodos do Servidor com Motor de Carregamento Remoto de T´ıtulos. Serve de intermedi´ario entre o Cart˜ao e o Servidor para a troca de APDUs.

3.5.3

Modo de Funcionamento

A Figura ?? do Apˆendice B (Anexo Confidencial) ilustra o modo de funciona-mento da aplica¸c˜ao para o carregamento e valida¸c˜ao 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¸

oes Identificadas

Durante a fase de desenvolvimento da aplica¸c˜ao, surgiram algumas limita¸c˜oes refe-rentes `as APIs Java, nomeadamente na API JSR-172 (Sec¸c˜ao 3.2.5). Essas limita¸c˜oes est˜ao intrinsecamente ligadas `a limitada capacidade de processamento e mem´oria dos dispositivos m´oveis facto que impede, em alguns casos, a constru¸c˜ao de APIs t˜ao poderosas como no caso das APIs que correm nas aplica¸c˜oes em PCs convencionais. Neste projecto em concreto, a limita¸c˜ao emergente tem a haver com a API de parse de dados em XML que n˜ao suporta alguns tipos de dados.

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

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

Tipos de Dados a evitar Tipos num´ericos sem sinal tais como, ”xsd:unsignedInt”, ”xsd:unsignedLong”, ”xsd:unsignedShort”, e ”xsd:unsignedByte”, s˜ao 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˜ao tem tios num´ericos sem sinal. Por uma quest˜ao de interoperabilidade, n˜ao devem ser expostos m´etodos com esses tipos num´ericos. Pode ser criados m´etodos 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˜ao. Como resultado, pode ocorrer a perde de precis˜ao na convers˜ao 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˜ao 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´etodos a disponibilizar s˜ao os necess´arios tanto para configura¸c˜ao dos leitores, como para interagir com os cart˜oes e SAMs.

Uma vez conclu´ıdo, ir´a permitir `as aplica¸c˜oes cliente operarem com os leitores sem a inclus˜ao da camada de neg´ocio do Software de Interoperabilidade para Ter-minais na m´aquina hospedeira da aplica¸c˜ao cliente. Ao centralizar a acesso a esta camada do Software de Interoperabilidade para Terminais, a manuten¸c˜ao da mesma pode ser feita de forma transparente para as aplica¸c˜oes cliente sem necessidade de reinstala¸c˜ao da mesma nas diferentes m´aquinas. Assim, as aplica¸c˜oes cliente neces-sitar˜ao 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ˆe-se que uma aplica¸c˜ao que utilize o SIT, possua uma r´eplica integral (todas os n´ıveis) da mesma instalada na m´aquina respectiva para a invoca¸c˜ao de comandos no cart˜ao , acesso e configura¸c˜ao dos leitores. Isto implica que cada altera¸c˜ao efectuada no N´ıvel de Neg´ocio do Software deva ser propagada por todas as aplica¸c˜oes que a utilizem.

Para facilitar a inclus˜ao de altera¸c˜oes `a camada de neg´ocio e resolver o problema da propaga¸c˜ao das suas actualiza¸c˜oes, 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 ´e respons´avel por disponibilizar m´etodos de alto n´ıvel dos cart˜oes e tickets, que garantem a independˆencia dos for-matos e funcionalidades b´asicas entre a aplica¸c˜ao, e o leitor utilizados.

Neste trabalho s´o foram utilizadas duas fam´ılias de cart˜oes, que utilizam a tecno-logia Calypso para garantir a seguran¸ca dos mesmos. A camada superior do SIT n˜ao tem qualquer conhecimento dos diversos tipos de cart˜oes, 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˜oes de gest˜ao ao n´ıvel da comunica¸c˜ao entre o cart˜ao e o termi-nal/leitor utilizados.

A interface disponibilizada por este n´ıvel independente do leitor, representando uma camada de abstrac¸c˜ao que torna mais f´acil o processo de integra¸c˜ao com dife-rentes leitores.

Neste ˆambito, existem dois tipos de m´etodos: o primeiro, ´e referente `a l´ogica de neg´ocio e contem, por exemplo, o m´etodo para preparar o leitor, ou seja, a

Imagem

Figura 1.2: O grupo AITEC
Figura 1.3: Planeamento do Est´ agio
Figura 2.1: Arquitectura ponto-a-ponto versus Arquitectura EAI
Figura 2.2: Sistemas do cliente
+7

Referências

Documentos relacionados

No primeiro, destacam-se as percepções que as cuidadoras possuem sobre o hospital psiquiátrico e os cuidados com seus familiares durante o internamento; no segundo, evidencia-se

Com o intuito de aperfeic¸oar a realizac¸˜ao da pesquisa O/D, o objetivo do presente trabalho ´e criar um aplicativo para que os usu´arios do transporte p´ublico informem sua origem

Resultados: Os parâmetros LMS permitiram que se fizesse uma análise bastante detalhada a respeito da distribuição da gordura subcutânea e permitiu a construção de

Neste capítulo, será apresentada a Gestão Pública no município de Telêmaco Borba e a Instituição Privada de Ensino, onde será descrito como ocorre à relação entre

Assim, o presente trabalho surgiu com o objetivo de analisar e refletir sobre como o uso de novas tecnologias, em especial o data show, no ensino de Geografia nos dias atuais

No prazo de 10 dias contada da deliberação, para os condóminos presentes, ou contada da sua comunicação, para os condómino ausentes, pode ser exigida ao administrador a convocação

O mar profundo é uma vasta região que recobre aproximadamente 70% da superfície da terra, sendo considerado ainda uma vastidão a ser explorada e estudada pelo homem. A coleção

Este trabalho é resultado de uma pesquisa quantitativa sobre a audiência realizada em 1999 envolvendo professores e alunos do Núcleo de Pesquisa de Comunicação da Universidade