M´ etodos a Disponibilizar - An´ alise do problema

4.2 An´ alise do problema

4.2.2 M´ etodos a Disponibilizar

Como anteriormente referido, este Servi¸co deve disponibilizar à aplica¸cão cliente uma série de métodos de negócio e receber o respectivo resultado. No entanto, o SMCRT terá que inicializar o SIT, antes do cliente invocar um destes métodos.

Método para Iniciar Interaçcão

Este método, como o nome indica, serve para dar in´ıcio à interaçcão do cliente com o servidor. É 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 opera¸cão das que se seguem, tem que passar obrigatoriamente o GUID que lhe foi atribu´ıdo neste método.

Método para Terminar Interaçcão

Como o nome indica, este método serve para terminar a interaçcão do cliente com o servidor. Quando invocado, o servidor encarrega-se de destruir todo o contexto associado a um cliente.

Método para Ler Estado da Última Opera¸cão

Este método, server para obter o estado (resultado) da última opera¸cão invocada no Servi¸co. No entanto, todas os métodos retornam o estado de invoca¸cão.

M´etodo para Afectar um Leitor

Como o nome indica, este m´etodo serve para afectar o leitor ao SIT.

M´etodo para Libertar um Leitor

Como o nome indica, este m´etodo serve para desafectar o leitor ao SIT.

M´etodo para Afectar SAM

Como o nome indica, este m´etodo serve para afectar um dos poss´ıveis SAMs que se encontram no leitor ao SIT.

M´etodo para Libertar SAM

Como o nome indica, este m´etodo serve para libertar o SAM alocado na opera¸c˜ao anteriormente descrita.

M´etodo para Associar um Cart˜ao a um SAM

Este m´etodo associa um SAM previamente alocado a um Cart˜ao.

M´etodo para Desassociar um Cart˜ao de um SAM

Este m´etodo associa um SAM previamente associado a um Cart˜ao.

Método para Iniciar Comunica¸cão com o Cartão

Como o nome indica, deve retornar os comandos necessários para iniciar a comunica¸cão com o cartão.

Método para Fechar Comunica¸cão com o Cartão

Como o nome indica, deve retornar os comandos necessários para cessar a comunica¸cão com o cartão.

Método para Abrir Sessão no Cartão

Como o nome indica, serve para iniciar uma sess˜ao no Cart˜ao.

Método para Fechar Sessão no Cartão

Como o nome indica, serve para fechar uma sess˜ao no Cart˜ao.

M´etodo para Ler o Contador

Este m´etodo serve para ler o valor de um contador existente no Cart˜ao.

M´etodo para Escreve o Contador

Este m´etodo serve para escrever o valor de um contador existente no Cart˜ao.

Método para Seleccionar Aplica¸cão do Cartão

Este método, serve para seleccionar uma das várias aplica¸cões existentes no Cartão. Para além do identificador do cliente, deve ser passado o identificador da aplica¸cão a seleccionar.

Cap´ıtulo 4. Servi¸cos do Motor de Carregamento Remoto de T´ıtulos 37

M´etodo para Invalidar um Cart˜ao

Como o nome indica, serve para invalidar um cart˜ao

M´etodo para Reabilitar um Cart˜ao

Como o nome indica, serve para reabilitar um cart˜ao.

M´etodo para Escrever Dados no Cart˜ao

Método genérico que permite ler qualquer tipo de dados no Cartão.

M´etodo para Ler Dados do Cart˜ao

Método genérico que permite escrever qualquer tipo de dados no Cartão.

M´etodo para Verificar o PIN do Cart˜ao

Como o nome indica, serve para verificar se o PIN do Cart˜ao fornecido pelo cliente ´e o correcto.

M´etodo para Alterar o PIN do Cart˜ao

Como o nome indica, serve para alterar o PIN do Cart˜ao. Para al´em do GUID deve ser passado o PIN actual bem como o novo PIN.

M´etodo para Iniciar um Comando

Este método serve para o SMCRT receber das queues o resultado de um dos métodos anteriormente descritos. O objectivo é sempre retornar os comandos a executar no Cartão.

E importante referir que o retorno de todos os métodos acima descritos foi conce- bido com as limita¸cões identificadas no projecto Aplica¸cão Cliente de Carregamento Remoto de T´ıtulos. Quer isto dizer que os objectos de retorno são constitu´ıdos por atributos de tipos básicos para que o consumo do servi¸co, por parte de aplica¸cões móveis, seja ’implementável’.

4.3 Implementa¸c˜ao

Uma vez que a linguagem de programa¸cão usada para a implementa¸cão do Web Service foi ASP.NET e C#, foi necessário criar um Wrapper que invocasse as fun¸cões da biblioteca do Software de Interoperabilidade dado que esta está constru´ıda com a Linguagem C. De seguida, deu-se in´ıcio á constru¸cão do Web Service onde foi criado Web Method por cada método do SIT a invocar.

Figura 4.3: Arquitectura do SMCRT

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

O SMCRT representa o Web Service com v´arios web methods disponibilizados.

O Proxy, representa um cliente no SMCRT. Este é identificado univocamente no sistema por um Identificador Global passado ao cliente na primeira invoca¸cão do web service. Assume o papel de ponte entre o cliente e o processo que responde aos seus pedidos. É o proxy que guarda as queues de comunica¸cão entre o processo e o web service com a informa¸cão a trocar com o cliente.

O Processo é responsável por carregar em memória o SIT, com recurso ao wrapper criado, e invocar o método 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 mudan¸ca de contexto no processador (não é necessário guardar o program counter nem a pilha). No entanto, esta op¸cão teve de ser descartada porque, internamente, o SIT guarda o estado da invoca¸cão das fun¸cões. Dado que as threads partilham o mesmo espa¸co de memória, o contexto de execu¸cão do primeiro corromper-se- ia aquando da invoca¸cão de um método do SIT por parte de outro cliente. Devido a este facto, será criado um processo por cada cliente pois os processos são executados num espa¸co de memória reservado.

A Figura ?? do Apêndice B (Anexo Confidencial) ilustra o modo genérico de funcionamento da invoca¸cão de um método 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 est´agio (Figura 1.3).

5.1 Objectivo

O projecto integra-se num roadmap de desenvolvimento de inova¸cões e futuros módulos de plataforma de electronic ticketing da Link. Neste âmbito, pretende- se implementar um protótipo de uma aplica¸cão móvel que aceda ao Servidor com Motor de Carregamentos Remotos , para a compra e carregamento de t´ıtulos no SmartPhone. Neste âmbito, deverá ser adicionado o suporte a um novo coupler designado por “Remote”. Este vai permitir às aplica¸cões cliente do Servidor com Motor de Carregamento Remoto de T´ıtulos funcionarem sem SAMs locais, ou seja, sem um SAM embutido no leitor de cartões. Com este coupler, o acesso aos SAMs passa a ser remoto e gerido pelo servidor SAM Server (Figura 5.3).

5.2 Situa¸c˜ao Inicial

Uma solu¸cão 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 adi¸cão de novas funcionalidades não implique grandes altera¸cões no código existente. O “Software de Interoperabilidade para Terminais”, tendo em conta este princ´ıpio, foi desenhado de forma modular, permitindo assim uma abstraçcão dos módulos inferiores. É composto por três n´ıveis distintos como pode ser visualizado na arquitectura 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 é responsável por disponibilizar métodos de alto n´ıvel dos cartões e tickets, que garantem a independência dos formatos e funcionalidades básicas entre

Figura 5.1: Arquitectura do Software de Interoperabilidade para Terminais

a aplica¸c˜ao, o coupler e o cart˜ao utilizados.

O segundo n´ıvel, “Card”, corresponde a uma camada interna do “Software de Interoperabilidade para Terminais” e é responsável pela gestão dos métodos referen- tes aos cartões, independentemente do leitor utilizado. A interface disponibilizada por esta camada, é independente do cartão, embora internamente implemente diferentes fun¸cões para diferentes cartões. Esta camada de abstraçcão facilita o processo de integra¸cão/adi¸cão de diferentes cartões.

O n´ıvel leitor corresponde também a uma camada interna do “Software de In- teroperabilidade para Terminais”. Esta implementa fun¸cões de gestão ao n´ıvel da comunica¸cão entre o cartão e o terminal (coupler ) utilizados.

A interface disponibilizada por este n´ıvel, é independente do leitor, contudo, internamente utiliza diferentes fun¸cões para diferentes leitores. Esta camada de abstraçcão torna mais fácil o processo de integra¸cão/adi¸cão de diferentes leitores.

Por se tratar de um sistema embebido, todos os módulos acima descritos, utilizam um outro, designado por “N´ıvel de Abstraçcão do Sistema Operativo”, ou seja, camada de abstraçcão do sistema operativo. Esta camada permite isolar o software embebido, do sistema operativo em que é executado (real time operating system), implementando fun¸cões de comunica¸cão, log, timer e substituindo os tipos básicos, que são espec´ıficos a determinadas plataformas.

Cap´ıtulo 5. Remote Coupler 41

Todos os m´odulos referidos encontram-se implementados na linguagem C, visto tratar-se de uma solu¸c˜ao 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 só pode ser feito localmente dado que este software não se encontra preparado para a comunica¸cão com os leitores (SAMs) que estejam ligados numa máquina remota (Figura 5.2)

Figura 5.2: Arquitectura com SAMs locais

5.2.1 Vis˜ao Funcional

Como se pode ver pela Figura ?? do Apêndice B (Anexo Confidencial), existe um módulo “Manager” que tem duas listas. Estas contêm todos os cartões e SAMs (necessários para a codifica¸cão e descodifica¸cão dos dados, contêm os algoritmos criptográficos e chaves partilhadas) registados.

Cada cartão, por sua vez, tem a sua informa¸cão espec´ıfica e apontadores para a sua tabela de fun¸cões, a tabela de fun¸cões de cada tecnologia utilizada (aponta para uma zona de memória não alocada, “NULL”, caso não suporte a tecnologia em causa), para o coupler e para o SAM associados.

Cada SAM contém a sua informa¸cão espec´ıfica e um apontador para o coupler respectivo. Os couplers, por sua vez, contêm a sua informa¸cão espec´ıfica e um apontador para a tabela de fun¸cões respectiva. Os couplers do SAM e do cartão, poderão apontar para a mesma tabela, caso o SAM se encontre dentro do leitor de cartões ao invés de estar num dispositivo diferente.

5.3 Solu¸c˜ao pretendida

Para que as altera¸c˜oes a efectuar se tornassem uma realidade, verificou-se que para o efeito bastaria implementar um novo coupler a adicionar `a API.

Figura 5.3: Arquitectura com SAMs remotos

Com o recurso às técnicas anteriormente descritas, o processo de adi¸cão de novos cartões e couplers é completamente transparente, sendo desnecessária qualquer altera¸cão ao código já existente. Para o caso espec´ıfico da adi¸cão do coupler “SOAP”, a adi¸cão necessária pode ser visualizada na Figura 5.4.

5.4 Implementa¸c˜ao

O bloco “Remote” corresponde à implementa¸cão do coupler em questão. Foi então criado o ficheiro “remote.c”, que contém a respectiva implementa¸cão das fun¸cões a disponibilizar ao N´ıvel Leitor, isto é, contém a declara¸cão de uma tabela de apontadores para fun¸cões “Coupler ftable”, neste caso particular “Remote ftable”, bem como a implementa¸cão destas fun¸cões, para o caso espec´ıfico do “Remote”.

Uma vez que o acesso remoto aos SAM é feito via web services, é necessário gerar todas as classes (os stubs) que permitem invocar objectos remotos. Assim, integrou-se a implementa¸cão 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 (seçcão 3.2.7), actua como fachada de invoca¸cão de métodos remotos de forma transparente `

a aplica¸c˜ao, como se de c´odigo local se tratasse.

Para gera¸cão dos stubs cliente para acesso ao Servidor com Motor de Carrega- mento Remoto de T´ıtulos, foi utilizada a ferramenta gSOAP. Esta ferramenta permite gerar código C (stubs) para acesso a web services a partir do WSDL. Na posse WSDL do Servidor com Motor de Carregamento Remoto de T´ıtulos, é poss´ıvel gerar todo o código com o empacotamento e desempacotamento das mensagens SOAP em estruturas (struct) da linguagem C e ainda os métodos 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 m´odulo “Leitor)” a entrada

Cap´ıtulo 5. Remote Coupler 43

Figura 5.4: Arquitectura da SIT

respectiva na tabela existente (j´a explicada anteriormente), ou seja:

#ifdefREMOTE SUPPORT

extern T ICoupler

REMOTE fCouplerTable

#endif

Static T CouplerEntry couplersTable[]= . . .

#ifdefREMOTE SUPPORT

K CSC REMOTE TYPE, &Soap fCouplerTable

#endif

;

A flag que identifica o suporte do novo coupler “REMOTE SUPPORT” foi então adicionada às propriedades do projecto. Esta flag, quando activada, obriga a com- plica¸cão do código relativo ao “Remote Coupler” originando uma build que suporte este leitor.

Conclus˜ao

Globalmente, os objectivos inicialmente propostos foram claramente atingidos. As- sim o trabalho desenvolvido apresenta um benef´ıcio mútuo que no caso do autor, traduz-se na satisfa¸cão pessoal e aquisi¸cão de novos conhecimentos. Para a Link Consulting, significa o enriquecimento da sua plataforma SmartCITIES e alarga- mento da sua oferta.

As conclusões do estágio estão divididas em três partes. A primeira foca o trabalho desenvolvido. A segunda pretende ser a aprecia¸cão do estágio num cômputo geral. A terceira, aflora o trabalho futuro.

6.1 Aprecia¸c˜ao Cr´ıtica do Trabalho Desenvolvido

A primeira fase constituiu a aprendizagem de arquitecturas de integra¸cão e forma¸cão na plataforma BizTalk Server 2006. Após esta etapa, o autor teve de integrar uma equipa de desenvolvimento a trabalhar com a mesma ferramenta. Esta fase permitiu uma melhor compreensão de arquitecturas e tecnologias de integra¸cão que podem ser usadas como ferramentas de suporte para os sistemas de mobile ticketing.

A segunda fase, correspondeu à constru¸cão de um protótipo sob a forma de uma aplica¸cão móvel para acesso aos Servi¸cos de Carregamento de Remoto de T´ıtulos. Correspondeu assim ao per´ıodo mais intenso e desafiante do estágio uma vez que o autor nunca havia tido contacto com a maior parte das tecnologias utilizadas. Foi ultrapassada numa regime de investiga¸cão tendo em conta a muita pesquisa efectuada sobre os diversos conceitos como Web Services, J2ME, SOAP e como conjugar os diversos componentes. Deve também ser tido em conta, o imaturo estado das tecnologias de suporte ao consumo de web services por parte de aplica¸cões J2ME a correr dispositivos móveis, dispositivos esses que apresentam limitados recursos de processamento, memória e energia.

Na terceira fase, foi desenvolvido um web service para expor os Servi¸cos do Mo- tor de Carregamento Remoto de T´ıtulos. A n´ıvel tecnol´ogico, n˜ao houve qualquer

Cap´ıtulo 6. Conclus˜ao 45

obstáculo dado que as linguagens de programa¸cão utilizadas, o C#, já são do co- nhecimento do autor.

Na última fase construiu-se o Remote Coupler para encapsular a localiza¸cão dos SAMs. Como a linguagem de programa¸cão utilizada foi o C, permitiu um contacto com a programa¸cão em C sob o paradigma “Object Oriented”’ com o especifica¸cão de interfaces com recurso a tabelas de apontadores. No meu entender, a li¸cão a retirar tem a haver com a visão e conceitos aplicados com o low coupling entre aplica¸cões e seus módulos.

No documento Smartphones para identificação de pagamentos (páginas 49-59)