Upload
dokiet
View
216
Download
0
Embed Size (px)
Citation preview
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),
Capıtulo 1. Introducao 3
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
Capıtulo 1. Introducao 4
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.
Capıtulo 1. Introducao 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 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.
Capıtulo 1. Introducao 6
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
Capıtulo 2. Enterprise Application Integration 9
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;
Capıtulo 2. Enterprise Application Integration 10
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.
Capıtulo 2. Enterprise Application Integration 11
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
Capıtulo 2. Enterprise Application Integration 12
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
Capıtulo 2. Enterprise Application Integration 13
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).
Capıtulo 2. Enterprise Application Integration 14
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);
Capıtulo 2. Enterprise Application Integration 15
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.
Capıtulo 2. Enterprise Application Integration 16
Oracle 9i
Sistema de Gestao de Base de Dados. Pode ser considerado como um dos sistemas
a integrar.
DB2
Sistema de Gestao 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
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
O projecto integra-se num roadmap de desenvolvimento de inovacoes e futuros
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.
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 19
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.
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 20
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
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 21
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:
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 22
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;
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 23
• 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)
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 24
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-
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 25
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
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 26
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
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 27
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.
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 28
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
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 29
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)
E um metodo de alto nıvel que permite as aplicacoes J2ME solicitarem ao
utilizador o codigo PIN a ser desabilitado e enviar para o cartao.
• byte[] enablePin(int pinID)
E um metodo de alto nıvel que permite as aplicacoes J2ME solicitarem ao
utilizador o codigo PIN a ser reabilitado e enviar para o cartao.
• byte[] enterPin(int pinID)
E um metodo de alto nıvel que permite as aplicacoes J2ME solicitarem ao
utilizador o codigo PIN a ser verificado e enviar para o cartao.
• byte[] exchangeAPDU(byte[] commandAPDU)
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 30
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)
E um metodo de alto nıvel que permite as aplicacoes J2ME solicitarem ao
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.
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 31
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
Capıtulo 3. Aplicacao Cliente de Carregamento Remoto de Tıtulos 32
(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
O desenvolvimento desde projecto teve lugar na Fase 3 do planeamento do estagio
(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
Capıtulo 4. Servicos do Motor de Carregamento Remoto de Tıtulos 35
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.
Capıtulo 4. Servicos do Motor de Carregamento Remoto de Tıtulos 36
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.
Capıtulo 4. Servicos do Motor de Carregamento Remoto de Tıtulos 37
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.
Capıtulo 4. Servicos do Motor de Carregamento Remoto de Tıtulos 38
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
O desenvolvimento desde projecto teve lugar na Fase 4 do planeamento do estagio
(Figura 1.3).
5.1 Objectivo
O projecto integra-se num roadmap de desenvolvimento de inovacoes e futuros
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.
Capıtulo 5. Remote Coupler 41
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.
Capıtulo 5. Remote Coupler 42
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
Capıtulo 5. Remote Coupler 43
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 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