Embed Size (px)
DESCRIPTION
Uma Proposta de Arquitetura para Sistemas de Comercialização de Títulos de Capitalização através do Short Message Service.
Citation preview
CENTRO UNIVERSITÁRIO PADRE ANCHIETA
CENTRO DE PÓS-GRADUAÇÃO
CURSO DE DESENVOLVIMENTO DE SISTEMAS EM JAVA
EDUARDO GALBIERI
UMA PROPOSTA DE ARQUITETURA PARA SISTEMAS DE
COMERCIALIZAÇÃO DE TÍTULOS DE CAPITALIZAÇÃO ATRAVÉS DO SHORT
MESSAGE SERVICE
JUNDIAÍ - SP
2013
CENTRO UNIVERSITÁRIO PADRE ANCHIETA
CENTRO DE PÓS-GRADUAÇÃO
CURSO DE DESENVOLVIMENTO DE SISTEMAS EM JAVA
EDUARDO GALBIERI
UMA PROPOSTA DE ARQUITETURA PARA SISTEMAS DE
COMERCIALIZAÇÃO DE TÍTULOS DE CAPITALIZAÇÃO ATRAVÉS DO SHORT
MESSAGE SERVICE
Monografia apresentada à banca examinadora da Pós-graduação do Centro Universitário Padre Anchieta, como exigência parcial para obtenção do título de Especialista em Desenvolvimento de Sistemas em Java, sob a orientação do Prof. Dr. Juliano Schimiguel.
JUNDIAÍ - SP
2013
EDUARDO GALBIERI
UMA PROPOSTA DE ARQUITETURA PARA SISTEMAS DE
COMERCIALIZAÇÃO DE TÍTULOS DE CAPITALIZAÇÃO ATRAVÉS DO SHORT
MESSAGE SERVICE
Monografia aprovada como requisito parcial para a obtenção do título de Especialista
em Desenvolvimento de Sistemas em Java pela seguinte banca examinadora da Pós-
graduação do Centro Universitário Padre Anchieta:
Nota: ______________
Data da defesa: ___/___/_______
Orientador
Assinatura do Aluno
Dedico este trabalho à minha querida família e,
Especialmente, à minha avó, Dona Maria.
AGRADECIMENTOS
Agradeço muito a Deus.
Agradeço ao meu orientador, Professor Dr. Juliano Schimiguel, por todo o apoio e incentivo
que me deu durante o desenvolvimento deste trabalho, e ao Professor Ms. Peter Jandl Júnior,
por sua admirável metodologia de ensino e por sua capacidade de transferir conhecimento e
experiência.
Gostaria de agradecer também a Cinara Carretero, da empresa Movile, e a Yuri Fiaschi, da
empresa Spring Mobile Solutions, pela gentileza nas informações e nos esclarecimentos sobre
o mercado de mobilidade, a JGraph Ltd., por disponibilizar o draw.io, um aplicativo online e
de uso gratuito que foi usado em algumas ilustrações deste trabalho, e ao projeto StarUML,
por disponibilizar o software de mesmo nome, uma excelente ferramenta open source e de uso
gratuito que foi usada para o projeto de modelagem do sistema.
Toda operação de mercado deve tornar o produto ou serviço valioso para o cliente, vender
mais estes produtos valiosos, manter custos baixos, parar de fazer coisas que não agreguem
valor, criar um produto inovador, associar para combinar forças, fortalecer o serviço ao
consumidor, expandir programas de marketing, melhorar distribuição, reduzir tempo de ciclo,
otimizar compra de insumos, terceirizar atividades ineficientes, descontinuar produtos
estagnados e vender ativos não produtivos. (CESAR ROMÃO)
RESUMO
O tema deste trabalho surgiu da oportunidade de concretização de uma idéia; a de construir
um canal de comercialização de títulos de capitalização usando serviços de comunicação
móvel. São serviços similares àqueles das campanhas promocionais que vemos diariamente
pela TV, o consumidor participa de promoções, faz download de jogos, músicas e muito mais,
interagindo com mensagens de texto através de seu dispositivo ou telefone móvel. Esse
trabalho contextualiza a idéia de criar um novo canal de comercialização de produtos de
capitalização com a idéia de incluir o segmento de capitalização como uma novidade no
mercado de serviços de comunicação móvel. Desta maneira, o objetivo é propor uma
arquitetura para sistemas de comercialização de títulos de capitalização através de mensagens
de texto SMS. Como materiais e métodos, a proposta é aplicar o conteúdo que foi trabalhado
durante o curso de especialização em Java, que é uma plataforma bastante poderosa e que
dispõe ao mercado uma série de tecnologias. Essas tecnologias podem oferecer soluções
eficientes e, ao mesmo tempo, permitem a criação de novas oportunidades de negócio e de
novos produtos. Esse trabalho enfatiza a interoperabilidade entre sistemas, que é um tema
bastante discutido atualmente, fato que justifica uma motivação em adotar Web Services, uma
tecnologia que tem sido tendência no mercado e que passou a representar um papel
extremamente importante na integração das empresas e parceiros de negócio. Faz também
uma abordagem da questão da segurança e os mecanismos que as tecnologias utilizadas
oferecem para garantir operações seguras e confiáveis no caso de aplicações em rede.
Finalizando a seção que se refere aos materiais e métodos utilizados, o trabalho apresentou o
uso de API(s) dedicadas, como recurso para o acesso à rede de telefonia, com vistas a permitir
uma integração unificada e padronizada, de forma que ofereçam a interoperabilidade dos
serviços de Telecom num alcance global, de acordo com o conceito de redes da próxima
geração (NGN). A pesquisa resultou em uma proposta de arquitetura de software que
culminou em uma infra-estrutura de serviços e aplicações, cuja reunião dá origem ao portfólio
de um provedor de serviços. Principalmente, esse é um trabalho que pretende colocar no
mercado um novo canal para comercialização de produtos de capitalização. Além disso, esse é
um trabalho para incentivar a criação de novos produtos voltados para o segmento de serviços
de valor agregado (VAS), que mostrou ser um mercado fascinante e rico em oportunidades.
Palavras-chave: Capitalização. Java. Mobilidade. Serviços de valor agregado. SMS.
ABSTRACT
The subject of this paper came from the opportunity of realization of an idea; build a
marketing channel for savings bonds using mobile communication services. These services
are similar to those of the promotional campaigns that we daily see on TV, the consumer
participates in promotions, downloads of games, songs and even more, interacting with text
messages through your mobile phone or device. This paper contextualizes the idea of creating
a new marketing channel for savings bonds with the idea to include the savings bonds’
segment as a novelty in the mobile communication services marketplace. In this manner, the
goal is one architecture proposal for marketing systems of savings bonds through SMS text
messages. As materials and methods, the proposal is to apply the content that was worked
during the course of specialization in Java, which is a very powerful platform and it offers to
market some number of technologies. These technologies can provide efficient solutions and,
at the same time, they allow the creation of new business opportunities and new products.
This paper emphasizes interoperability between systems, which is a theme much discussed
currently, a fact which justifies a motivation for adopt Web Services, a technology that has
been trending in the market and now represents an extremely important role for to integrate
companies and partners business. It also makes an approach about safety issue and some
mechanisms that the used technologies provide to ensure safe and reliable operations in the
case of network applications. Concluding the section about the materials and method, this
paper presented the use of dedicated API(s), as a resource for access to the telephony network,
in order to allow unified and standardized integration, in order they offer interoperability for
Telecom services in a global reach, according to the concept of next generation networks
(NGN). This research resulted in a software architecture proposal that culminated in a service
and application infrastructure, the meeting of which gives rise to a service provider’s
portfolio. Mainly, this is a paper that intends to bring to market a new marketing channel for
savings bonds. Furthermore, this is a paper for encourage the creation of new products aimed
at the segment of value-added services (VAS), which proved to be a fascinating market and
rich in opportunities.
Key-words: Savings bond. Java. Mobile. Value-added services. SMS.
LISTA DE ILUSTRAÇÕES
Figura 1 ‒ Provisões Técnicas .................................................................................................. 20
Figura 2 – Estrutura Básica da Rede SMS ............................................................................... 29
Figura 3 – Procedimento MO-SMS .......................................................................................... 33
Figura 4 – Procedimento MT-SMS .......................................................................................... 33
Figura 5 – Serviços MAP envolvidos no procedimento MO-SMS .......................................... 36
Figura 6 – Serviços MAP envolvidos no procedimento MT-SMS .......................................... 37
Figura 7 – Protocolos de Interface entre SMSC e SME ........................................................... 40
Figura 8 – Ilustração sobre Convergência Tecnológica ........................................................... 42
Figura 9 – IP-SM-GW, o gateway entre os domínios das redes GSM e IMS .......................... 46
Figura 10 ‒ Servidor Java EE e seus containeres ..................................................................... 52
Figura 11 – Exemplo de uma Bomba XML ............................................................................. 57
Figura 12 – Resultado de uma Bomba XML ............................................................................ 57
Figura 13 ‒ Diagrama de Casos de Uso ................................................................................... 67
Figura 14 ‒ Diagrama Lógico de Alto Nível ............................................................................ 68
Figura 15 ‒ Diagrama de Componentes ................................................................................... 69
Figura 16 ‒ Diagrama de Implantação ..................................................................................... 70
Figura 17 ‒ Arquitetura para o Sistema de Capitalização SMS (e-CAP)................................. 71
Figura 18 ‒ Modelo Genérico de Arquitetura .......................................................................... 73
LISTA DE ABREVIATURAS E SIGLAS
3GPP Third Generation Partnership Project
API Application Programming Interface
ASR Automatic Speech Recognition
B2B Business to Business
BI Business Intelligence
BSC Base Station Controller
BSS Base Station Subsystem
BTS Base Transceiver Station
CDMA Code Division Multiple Access
CIMD Computer Interface to Message Distribution
CMG Computer Management Group
CRM Customer Relationship Management
DAO Data Access Object
DB Database
EAR Enterprise Archive
E-CAP Sistema de Capitalização SMS
EDGE Enhanced Data Hates for GSM Evolution
EIS Enterprise Information System
EJB Enterprise Java Beans
EMS Enhanced Messaging Service
ERP Enterprise Resource Planning
ESME External Short Message Entity
ETSI European Telecommunications Standards Institute
FENACAP Federação Nacional de Capitalização
GMSC Gateway Mobile-services Switching Centre
GPRS General Packet Radio Service
GSM Global System for Mobile Communication
GSMA GSM Association
HLR Home Location Register
HSS Home Subscriber Server
HTTP Hypertext Transfer Protocol
ID Identity
IETF Internet Engineering Task Force
IMEI International Mobile Equipment Identity
IMS IP Multimedia Subsystem
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IP-SM-GW IP Short Message Gateway
ISDN Integrated Services Digital Network
ITU International Telecommunication Union
ITU-T ITU – Telecommunication Standardization Sector
IVR Interactive Voice Response
JAR Java Archive
JAVA EE Java Enterprise Edition
JVM Java Virtual Machine
MAP Mobile Application Part
MMAP Mobile Message Access Protocol
MMS Multimedia Messaging Service
MO-SMS Mobile Originated SMS
MS Mobile Station
MSC Mobile-services Switching Centre
MSISDN Mobile Subscriber ISDN
MT-SMS Mobile Terminated SMS
NGN Next Generation Network
OEM Original Equipment Manufacturer
OMA Open Mobile Alliance
ONEAPI Open Network Enabler API
OPEX Operational Expenditure
OSA/PARLAY Open Service Access/Parlay
P-CSCF Proxy ‒ Call Session Control Function
PIN Personal Identification Number
PM Pagamentos Mensais
PP Pagamentos Periódicos
PU Pagamento Único
QOS Quality of Service
QR Quick Response
REST Representational State Transfer
RFC 3261 Request for Comments 3261
RPC Remote Procedure Call
SAC Serviço de Atendimento ao Consumidor
SCM Supply Chain Management
S-CSCF Serving ‒ Call Session Control Function
SDK Software Development Kit
SDP Service Delivery Platform
SEMA Sociedade de Economia e Matemática Aplicada
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SME Short Message Entity
SMPP Short Message Peer to Peer
SMS Short Message Service
SMSC EMI SMSC External Machine Interface
SMSC Short Message Service Centre
SMS-GMSC SMS Gateway MSC
SMS-IWMSC SMS Interworking MSC
SMTP Simple Mail Transfer Protocol
SOA Service-Oriented Architecture
SOAP Simple Object Access Protocol
SS7 Signalling System No. 7
SUSEP Superintendência de Seguros Privados
TCP/IP Transmission Control Protocol / Internet Protocol
TDMA Time Division Multiple Access
TI Tecnologia da Informação
TIC Tecnologias de Informação e Comunicação
TMSI Temporary Mobile Subscriber Identity
TTS Text-to-speech
UE User Equipment
UML Unified Modelling Language
UMTS Universal Mobile Telecommunications System
VAS Value-added Services
VLR Visitor Location Register
WAP Wireless Application Protocol
WAR Web Archive
WSDL Web Services Description Language
XML Extensible Markup Language
XSD XML Schema Definition
SUMÁRIO
1. INTRODUÇÃO ............................................................................................................. 15
1.1. SISTEMA DE CAPITALIZAÇÃO NO BRASIL ................................................. 16
1.2. MERCADO DE COMUNICAÇÃO MÓVEL....................................................... 18
1.3. JUSTIFICATIVA .................................................................................................. 20
1.4. OBJETIVOS .......................................................................................................... 22
1.5. PROBLEMATIZAÇÃO DO TEMA ..................................................................... 23
1.6. REVISÃO INICIAL DA LITERATURA ............................................................. 25
2. SHORT MESSAGE SERVICE E PLATAFORMA JAVA ...................................... 27
2.1. ESTRUTURA BÁSICA DA REDE ...................................................................... 29
2.2. PROCEDIMENTOS FUNDAMENTAIS DO SMS ............................................. 33
2.3. PROTOCOLOS DE INTERCONEXÃO .............................................................. 39
2.4. NEXT GENERATION NETWORK (NGN)......................................................... 42
2.5. IP MULTIMEDIA SUBSYSTEM (IMS) .............................................................. 44
2.5.1. Funções para Interoperabilidade com o SMS ....................................... 46
2.6. ARQUITETURA JAVA EE .................................................................................. 49
2.7. MOTIVAÇÃO PARA WEB SERVICES ............................................................. 54
2.8. SEGURANÇA ....................................................................................................... 56
2.9. API(s) PADRÃO PARA REDES DE TELEFONIA ............................................ 59
3. UMA PROPOSTA DE ARQUITETURA PARA SISTEMAS DE
COMERCIALIZAÇÃO DE TÍTULOS DE CAPITALIZAÇÃO ATRAVÉS DO SHORT
MESSAGE SERVICE ............................................................................................................ 62
3.1. MATERIAIS E MÉTODOS .................................................................................. 62
3.2. MODELAGEM DO SISTEMA ............................................................................ 64
3.2.1. Perspectiva de Casos de Uso .................................................................. 64
3.2.1.1. Casos de Uso da Plataforma de Serviços ............................ 64
3.2.1.2. Casos de Uso da Aplicação e-CAP ....................................... 65
3.2.2. Perspectiva Lógica .................................................................................. 68
3.2.3. Perspectiva de Componentes .................................................................. 68
3.2.4. Perspectiva de Implantação .................................................................... 70
3.3. ARQUITETURA PROPOSTA ............................................................................. 70
3.4. DISCUSSÃO ......................................................................................................... 74
4. CONCLUSÕES E TRABALHOS FUTUROS ........................................................... 76
REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................ 80
15
1. INTRODUÇÃO
Tema deste trabalho surgiu da oportunidade de concretização de uma idéia; a de
construir um canal de comercialização de títulos de capitalização usando serviços
de comunicação móvel. São serviços similares àqueles das campanhas promocionais que
vemos diariamente pela TV, o consumidor participa de promoções, faz download de jogos,
músicas e muito mais, interagindo com mensagens de texto SMS (Short Message Service)
através de seu dispositivo ou telefone móvel.
O presente trabalho de pesquisa consiste em propor uma arquitetura para sistemas de
comercialização de produtos de capitalização através de dispositivos e telefones móveis.
Nesse sistema, a comercialização ocorre por meio do relacionamento estabelecido entre três
entidades: o consumidor, a operadora de telefonia móvel e o provedor de serviço.
O consumidor — é a entidade que irá adquirir um produto de capitalização através de
seu dispositivo ou telefone móvel; A operadora de telefonia móvel — é a entidade
responsável por intermediar o relacionamento entre o consumidor e o provedor de serviço; O
provedor de serviço — é a entidade parceira das operadoras de telefonia móvel, que irá
hospedar o sistema para comercialização de produtos de capitalização.
Os provedores de serviço são empresas parceiras das operadoras de telefonia móvel, que
oferecem seus serviços baseados em tecnologias para dispositivos e telefones móveis. Como
atual estado da técnica, os provedores de serviço oferecem soluções para vários segmentos de
mercado como o de entretenimento, o de marketing e o de negócios.
O sistema para comercialização de produtos de capitalização faz uso de tecnologias
baseadas em mensagens de texto, fato que permite que as três entidades envolvidas se
relacionem através da troca de mensagens.
Basicamente, será feita a abordagem do tema em dois aspectos: o aspecto de como está
estruturado o sistema de capitalização no Brasil e o aspecto da tecnologia usada para oferecer
serviços de comunicação móvel. A possibilidade de integração destes dois aspectos, a
justificativa e os objetivos do trabalho de pesquisa serão descritos nas próximas seções.
O
16
1.1. SISTEMA DE CAPITALIZAÇÃO NO BRASIL
Os títulos de capitalização surgiram na França no século XIX, há mais de 150 anos. Os
associados de uma cooperativa de mineradores depositavam mensalmente valores com vistas
à formação de um capital e tinham a garantia de resgatar as contribuições ao final do prazo
estabelecido, ou antecipadamente, através de sorteios.
No Brasil, desde a década de 1930, os títulos têm atendido a determinados anseios da
população brasileira. Inicialmente, os títulos de capitalização foram concebidos
exclusivamente como uma ferramenta destinada a estimular o hábito de poupar, tendo como
incentivo a participação em sorteios realizados durante a vigência do plano.
Hoje, a capitalização é um instrumento que, utilizado individualmente ou em associação
com outros mecanismos de mercado, possibilita o desenvolvimento de soluções para
diferentes tipos de demandas da sociedade e é acessível aos mais diversos públicos.
Com duas finalidades distintas, parte do valor arrecadado com o seu pagamento destina-
se a fazer a massa necessária para premiar os sorteados, e parte destina-se à constituição de
um capital para resgate dentro de prazos predeterminados.
Os percentuais destinados ao sorteio e ao resgate variam de plano para plano, em função
de seus objetivos. É assim que determinados planos dão mais ênfase para o sorteio, enquanto
outros, sem abrir mão da premiação, buscam a constituição de uma maior reserva de capital.
Inicialmente, os planos de capitalização foram concebidos, exclusivamente, como uma
ferramenta destinada a estimular o hábito da constituição de uma soma de capital de médio e
longo prazo, tendo como incentivo, a possibilidade do recebimento de uma premiação, através
de sorteios periódicos realizados durante a vigência do plano. Entretanto, devido à sua grande
flexibilidade, é vasta a possibilidade de se criar produtos utilizando os títulos de capitalização.
Como conseqüência, o mercado evoluiu significativamente e hoje oferece uma grande
variedade de tipos de produtos. Cabe às empresas de capitalização demonstrar com clareza as
principais características de cada produto, assim como cabe ao consumidor definir qual o mais
adequado às suas necessidades.
17
Dadas as diferentes características e necessidades da sociedade, o mercado de
capitalização oferece vários tipos de produtos para aumentar a eficiência de sua
comercialização por meio dos diversos canais de distribuição, seguindo as modalidades a
seguir mencionadas, onde são elencadas formas alternativas de utilização do título de
capitalização.
Tradicional — é a modalidade que tem por objetivo restituir ao titular, ao final do prazo
de vigência, o valor total dos pagamentos efetuados pelo subscritor, desde que todos os
pagamentos previstos tenham sido realizados nas datas programadas;
Compra Programada — é a modalidade pela qual a empresa de capitalização se obriga
a disponibilizar ao titular, ao final do prazo de vigência, se este assim desejar e sem qualquer
outro custo, o bem ou o serviço referenciado na ficha de cadastro, a partir de acordos
comerciais celebrados com indústrias, atacadistas ou empresas comerciais. Sendo também
garantida ao titular a faculdade de optar pelo recebimento do valor de resgate em moeda
corrente nacional;
Popular — é a modalidade que permite a participação do titular em sorteios, sem que
haja devolução integral dos valores pagos ao final do prazo de vigência;
Incentivo — é a modalidade pela qual o título de capitalização está vinculado a um
evento promocional, que pode ser de caráter comercial, ou de incentivo ou de premiação a
determinado comportamento, sem que haja devolução integral dos valores pagos. Neste caso,
o subscritor é a empresa promotora, que concede o título na forma de um sorteio entre os
clientes consumidores do produto utilizado no evento promocional.
Além disso, os títulos de capitalização são estruturados quanto a sua forma de
pagamento:
PM (Pagamentos Mensais) — é um título que prevê um pagamento a cada mês de
vigência do título;
PP (Pagamentos Periódicos) — é um título em que não há correspondência entre o
número de pagamentos e o número de meses de vigência do título;
PU (Pagamento Único) — é um título em que o pagamento é realizado uma única vez,
tendo sua vigência estipulada na proposta.
18
Desta forma, um sistema para comercialização tem o objetivo de criar um novo canal de
comercialização de produtos de capitalização baseados nas modalidades disponíveis.
O segundo objetivo de um sistema para comercialização de produtos de capitalização é
fortalecer a missão da capitalização, que é a promoção do desenvolvimento econômico e
social. Utilizando para isso uma característica única dos títulos de capitalização de juntar em
um só instrumento a distribuição de prêmios através de sorteios e a acumulação de recursos,
de modo a viabilizar soluções para as diferentes demandas do mercado.
As empresas de capitalização desenvolvem seus produtos de acordo com as realidades e
expectativas dos consumidores, contribuindo para o desenvolvimento do país através da
geração de empregos e renda, da formação de um capital interno consistente e da criação de
hábitos de responsabilidade socioeconômica.
1.2. MERCADO DE COMUNICAÇÃO MÓVEL
O mercado de comunicação móvel evoluiu muito nos últimos anos, mérito conjunto de
operadoras, agências, anunciantes e demais players que fazem parte deste mercado. Com
formatos e regras melhor definidos e maior clareza do real potencial da mobilidade, o volume
de ações móveis cresceu fortemente já a partir de 2008. Com isso, vemos grandes marcas
investindo de forma cada vez mais consistente e agências publicitárias mais interessadas em
entender como inserir elementos de mobilidade em suas campanhas. (CAVALLINI et al.,
2010)
No Brasil, o principal meio para o envio de mensagens pessoais continua sendo o SMS.
Mesmo com o aumento das opções para enviar todo tipo de mensagens, como e-mail, Twitter
e mensageiros instantâneos, o SMS continua crescendo. Em 2010, passou a representar 73%
de todas as mensagens pessoais enviadas. (CAVALLINI et al., 2010)
Além disso, no Brasil são enviados cerca de 600 milhões de SMS por mês, por pessoas
de todas as idades e classes sociais. Já em 2008, 39% das classes D/E já enviaram SMS.
(CAVALLINI et al., 2010)
19
Amplamente difundido graças aos programas de televisão com suas enquetes e
votações, a interação via SMS não tem barreiras de uso. É uma interação democrática, simples
e com baixa curva de aprendizado. Abaixo, destacamos as características do SMS:
Cobertura: 100% da base ou 185 milhões de linhas.
Time to market: em até 10 dias.
Custo para o consumidor: existem dois formatos. Um é pago pelo consumidor. Neste caso, o custo mais utilizado (mais comum) para cada SMS enviado é de 31 centavos mais impostos. No outro formato, o anunciante pode comprar um pacote para que o SMS seja gratuito para o consumidor, incentivando a interação.
Forma de pagamento: valor de programação de plataforma e , quando o SMS é pago pelo anunciante, também existe um custo por essa interação.
Métricas possíveis: detalhes de entrega das mensagens com data, horário e taxa de entrega da mensagem de resposta e taxa de cliques (quando a mensagem é entregue com um link).
Observação: dado o formato, a taxa de leitura é enorme, beirando os 100%. Apesar de o limite ser de 160 caracteres, algumas tecnologias como o CDMA, usado por parte dos clientes da operadora Vivo, aceitam apenas 138 caracteres.
(CAVALLINI et al., 2010)
20
1.3. JUSTIFICATIVA
Segundo a Superintendência de Seguros Privados (SUSEP, 2013), o mercado de
capitalização no Brasil movimentou mais de 16 bilhões de Reais em 2012 e apresenta um
crescimento médio de 15% ao ano. Essas informações do mercado são bastante
representativas, mas mesmo assim, note na Figura 1, o mercado de capitalização detém
apenas 5% da participação em seu segmento.
Figura 1 ‒ Provisões Técnicas Fonte: Superintendência de Seguros Privados (Dezembro/2012)
O presente trabalho de pesquisa pretende incluir o segmento de capitalização como uma
novidade no mercado de serviços baseados em tecnologias para dispositivos e telefones
móveis. Diante dos atuais mecanismos de capitalização, são obtidas as seguintes vantagens
através dos recursos da mobilidade:
• Agrega qualidade de pós-vendas, estabelecendo um canal de comunicação direto com o
consumidor através de seu dispositivo ou telefone móvel. O consumidor recebe diversas
informações sobre o título de capitalização que adquiriu, resultados de sorteios,
orientações e lembretes sobre o resgate do capital investido e congratulações no caso de
premiação;
21
• Aumenta a fidelidade dos clientes, usando um mecanismo que oferece praticidade aos
consumidores que usam dispositivos e telefones móveis para adquirir seus produtos. A
cobrança e o resgate do título de capitalização são automáticos, ocorrem diretamente na
conta de telefonia móvel do consumidor;
• Melhora a eficiência da comunicação, permitindo disponibilizar canais de atendimento
ao consumidor para o envio de sugestões, reclamações e o esclarecimento de dúvidas;
• Incrementa a receita das empresas de capitalização, usando a tecnologia presente nos
dispositivos e telefones móveis para a disseminação e popularização dos produtos de
capitalização;
• Estende o serviço pós-vendas, criando mecanismos de marketing de novos produtos de
capitalização;
• Fornece dados estatísticos, levantando informações regionais precisas através dos
números dos dispositivos e telefones móveis dos consumidores. Informações preciosas
para que as empresas de capitalização prospectem seus produtos para atender as
diversas condições socioeconômicas do país.
22
1.4. OBJETIVOS
Esse curso de especialização revelou que Java é uma plataforma bastante poderosa que
dispõe ao mercado uma série de tecnologias. Essas tecnologias podem oferecer soluções
eficientes e, ao mesmo tempo, permitem a criação de novas oportunidades de negócio e de
novos produtos. A proposta desse trabalho é aplicar o conteúdo que foi trabalhado durante o
curso, partindo do principio de contextualizar a idéia de criar um novo canal de
comercialização de produtos de capitalização com a idéia de incluir o segmento de
capitalização como uma novidade no mercado de serviços de comunicação móvel. Desta
maneira, o objetivo geral deste trabalho de pesquisa é propor uma arquitetura para sistemas de
comercialização de títulos de capitalização através do Short Message Service.
Os objetivos específicos são mencionados a seguir:
• Fornecer material técnico para estudo detalhado de viabilidade comercial;
• Fornecer material técnico para submissão de novos produtos de capitalização, baseados
na proposta deste trabalho, junto a SUSEP, que é o órgão governamental que
regulamenta o setor;
• Fornecer material técnico para pesquisas em outras áreas do conhecimento, como
Administração, Marketing, Análise de Sistemas e Engenharia de Software;
• Incentivar a pesquisa aplicada a tecnologias de comunicação móvel de dados e a criação
de novos produtos.
23
1.5. PROBLEMATIZAÇÃO DO TEMA
Nesta seção, são apresentados os problemas deste trabalho de pesquisa, que é
bibliográfica, relacionando o estudo das tecnologias que são necessárias para cumprir seu
objetivo, uma proposta de arquitetura para sistemas de comercialização de títulos de
capitalização. Além disso, a contextualização dessas tecnologias com fundamentos da
capitalização vai direcionar a estrutura do trabalho como um todo.
Os cenários tecnológicos são aqueles que podem ser encontrados no mercado, no que tange ao envio de SMS por agentes externos à operadora móvel. Tratam-se das situações que uma operadora tende a encontrar quando confrontada com as demandas de roaming e interconexão de SMS. (SÁ, 2003)
No aspecto destes cenários serão estudados os protocolos usados para a interconexão
entre as operadoras de telefonia móvel e as entidades provedoras de serviços externos. A
arquitetura de uma rede SMS pode conter três interfaces, sendo uma de telefonia, uma de
gateway para interconexão e outra de gateway para internet.
Nos últimos anos os serviços de informações para celulares tiveram um crescimento
bastante expressivo, sendo o WAP (Wireless Application Protocol) o precursor destes
serviços. O serviço de SMS (Short Message Service) não teve o mesmo destino que o serviço
WAP, pois explodiu nos últimos meses no país. Segundo Sá (2003), o problema do WAP é
que ele foi muito mal posicionado no mercado brasileiro, onde foi vendido como internet
móvel com velocidade de conexão muito baixa, e oferecendo conteúdos não muito
agradáveis.
Um framework para Web Services de SMS fornece classes escritas na linguagem de programação Java que, através do mecanismo de herança e implementação de suas interfaces, facilitam o atendimento de requisições a serviços web feito por mensagens SMS. O núcleo do framework faz a interface das requisições aos serviços e trata o processo de parsing da mensagem recebida, e de parsing da resposta a ser enviada. (LEDESMA, 2007)
Segundo o autor, para fornecer o serviço é necessária a implementação de um servidor
responsável pelo envio e recebimento de mensagens SMS. Este trabalho foi feito com a
utilização de uma biblioteca que permite a troca de mensagens através de um modem GSM,
ou através de um telefone celular conectado à estação de desenvolvimento.
24
Para a escolha da ferramenta de envio e recebimento de mensagens, foram adotados três
critérios de escolha: abstração da complexidade das tecnologias envolvidas, baixa curva de
aprendizado e baixo custo de implementação. Seguindo esta linha de pesquisa, foram
elencadas duas bibliotecas de código aberto, SMSLIB e OPENSMPP. Para aplicações de
grande porte, a implementação do protocolo SMPP usado a partir de uma infra-estrutura
SMSC, atenderia uma demanda de taxa de envio maior que sete mensagens por minuto.
(LEDESMA, 2007)
O protocolo SMPP está sendo utilizado recentemente para permitir a troca de SMS entre
operadoras. Para este intuito foram desenvolvidos gateways para trabalhar com este protocolo,
convertendo-o de uma tecnologia para outra (e.g., de TDMA para GSM). Este tipo de
conversão se faz bastante necessário no cenário brasileiro, dada a diversidade de tecnologias
adotadas pelas operadoras. (SILVINO JR, 2002)
Tendo em vista que as formas de pagamento móveis existentes são limitadas para
grupos específicos, que dispõem de determinado dispositivo móvel, e que esta condição
dificulta a expansão deste sistema. A arquitetura REST propõe uma independência entre o
servidor e aplicação cliente, permitindo uma maior flexibilidade na escolha das tecnologias
utilizadas às partes (MAGRIN, 2010). Além disso, este fato torna o sistema mais escalável
permitindo que atenda a demanda à medida que a base de clientes aumenta.
A adesão maciça à comunicação móvel de voz, que ainda é decorrente, e que teve o seu
início no final dos anos 80, levou a uma nova área de pesquisa aplicada nas Tecnologias de
Informação e Comunicação (TIC): a comunicação móvel de dados.
As aplicações para dispositivos móveis sem fios devem sobrepor-se à diversidade de plataformas e sistemas operacionais. De forma a obter-se uma aplicação que seja executável em todos os dispositivos, ela deve ser independente da plataforma. Isto pode ser conseguido através da linguagem de programação Java. (URBANO, 2006)
25
1.6. REVISÃO INICIAL DA LITERATURA
O Manual de Melhores Práticas das Empresas de Capitalização (FENACAP, 2008) é
um instrumento para melhor compreensão do funcionamento das empresas e dos planos de
capitalização. Pretende estimular o aperfeiçoamento constante das informações e o nível de
atendimento das empresas ao consumidor, até mesmo buscar e consolidar, por este meio, o
desenvolvimento de uma cultura no setor. Com vistas a este segmento de mercado, o trabalho
de pesquisa será baseado também na legislação do setor.
Mobilize (CAVALLINI et al., 2010) é um guia prático e conciso para entender as reais
aplicações da plataforma móvel nas mais diversas disciplinas da comunicação, como
publicidade, relacionamento, ativação, promoção ou marketing direto. São descritos conceitos
de mobilidade, números e métricas deste mercado, além de cases de aplicações já realizadas
pelas principais agências publicitárias e anunciantes no Brasil.
O trabalho de Sá (2003) apresenta estudos sobre a tecnologia SMS e sobre a
implantação de interconexão entre as operadoras de telefonia móvel. Mostra dentre as
arquiteturas apresentadas, a que tem melhor performance em satisfazer o estudo de caso que
foi proposto.
O artigo de Ledesma (2007) propõe uma alternativa de integração de duas tecnologias
que suprem algumas necessidades no contexto de desenvolvimento de sistemas nos dias de
hoje. O SMS que tem uma larga base de usuários e o uso de Web Services que têm como
propósito facilitar a interoperabilidade entre sistemas distintos com baixo nível de
acoplamento. Verificou-se também a viabilidade de utilização destas tecnologias na criação
de soluções de negócio, principalmente para servidores de informação. O conceito de
arquiteturas orientadas a serviços (SOA) regeu o desenvolvimento da aplicação e da
construção do framework, facilitando assim a convergência na utilização de serviços de
diferentes tipos de rede.
O documento SMPP – Protocolo e Aplicações (SILVINO JR, 2002) descreve as
especificações deste protocolo, que é peer to peer e aberto. Foi desenvolvido para
proporcionar uma interface de comunicação de dados flexível, permitindo a troca de
mensagens entre as entidades envolvidas.
26
O trabalho de Magrin (2010) faz uma avaliação do estado atual do pagamento móvel a
fim de entender de que forma a tecnologia pode ser utilizada para facilitar sua adoção. Nesse
contexto, é apresentada uma proposta de arquitetura de sistemas de pagamento móvel, com
foco na comunicação entre a aplicação cliente e o servidor, baseada na arquitetura de
Transferência de Estado Representacional (REST).
Embora os dispositivos móveis disponham de um grande potencial de utilidade, capaz
de transformar a Sociedade de Informação, uma segunda vez depois da sua penetração pela
Internet, verifica-se ainda uma lacuna substancial a nível de aplicações para estas tecnologias
e dispositivos, especialmente quando consideramos a possibilidade de acessar e partilhar
informação sem qualquer tipo de barreiras. É neste âmbito que o tema da dissertação de
Urbano (2006) se insere: avaliar as reais capacidades de partilha dos dispositivos móveis
utilizando a arquitetura de rede peer to peer.
27
2. SHORT MESSAGE SERVICE E PLATAFORMA JAVA
SMS (Short Message Service) é um serviço de telecomunicação que permite a
troca de mensagens de texto entre telefones celulares. Acredita-se que a primeira
mensagem de texto SMS foi enviada em 1992, por meio de um canal de sinalização de uma
rede GSM1 européia. Uma vez que este “teste” foi bem sucedido, o uso do SMS tem sido
objeto de enorme crescimento. (LE BODIC, 2003)
Foi inicialmente desenvolvido pelo Instituto Europeu de Normas de Telecomunicações,
o ETSI2, como parte da primeira fase das especificações técnicas GSM, tecnologia que deu
origem à segunda geração da telefonia móvel celular.
Originalmente, as mensagens de texto SMS não podem exceder mais de 160 caracteres
alfanuméricos. Muitos aparelhos já oferecem o EMS, uma versão avançada do SMS onde as
mensagens de texto são concatenadas, permitindo aos consumidores redigirem mensagens de
até 459 caracteres. Além disso, a evolução do SMS tem dado espaço ao surgimento de novos
modelos de mensagens que transportam conteúdo multimídia (MMS). No entanto, o formato
tradicional do SMS continua sendo o de maior popularidade.
Desde o seu surgimento inicial na segunda geração da telefonia móvel celular (GSM), o
SMS tem sido portado ou estendido para todas as novas gerações. Existe total interesse das
companhias de telecomunicações em oferecer a interoperabilidade das novas tecnologias com
o SMS. O SMS é uma tecnologia madura que está disponível em 100% dos telefones
celulares. (LE BODIC, 2003)
Segundo Dryburgh (2005), o SMS é uma ferramenta muito importante para as
operadoras de telefonia e pode fornecer informação útil para seus clientes. A operadora pode
enviar um broadcast para múltiplos consumidores informando, por exemplo, situação de
roaming, como acessar sua caixa postal ou enviando uma simples mensagem de “boas
vindas”.
Alguns países europeus e asiáticos estenderam o SMS também para a linha de telefonia
fixa. Isso permitiu aos consumidores enviarem mensagens de texto de seu telefone fixo para
1 GSM: Global System for Mobile Communication. 2 ETSI: European Telecommunications Standards Institute.
O
28
telefones celulares e vice-versa. Outro lançamento europeu para a telefonia fixa que obteve
destaque foi o SMS para correio de voz, serviço que converte a mensagem de texto em voz
sintetizada e a encaminha para a caixa postal do destinatário. (DRYBURGH, 2005)
As novas possibilidades de uso do SMS levaram as companhias de tecnologia a
disponibilizarem uma grande variedade de outros dispositivos, telefones compatíveis para a
linha fixa, aparelhos de fax, telex e softwares para a leitura de mensagens de texto no corpo de
e-mails e páginas da Internet.
Essa pesquisa revelou que o SMS é uma tecnologia bastante complexa, possui uma
listagem de especificações extensa e de difícil compreensão. Esse capítulo pretende relacionar
os tópicos essenciais que permitam uma visão geral do SMS como um todo. Na maioria das
referências bibliográficas, e para os diversos sistemas de telecomunicações, foi possível
perceber que os autores seguiram um mesmo roteiro da literatura, com capítulos abordando a
arquitetura da rede, a pilha de protocolos, os procedimentos que determinam os fluxos de
dados e as interfaces disponíveis. As seções deste capítulo estão organizadas da mesma forma,
cujo conteúdo será determinante para propor uma arquitetura de software para sistemas de
comercialização de títulos de capitalização através de mensagens de texto.
29
2.1. ESTRUTURA BÁSICA DA REDE
Para fornecer o Short Message Service, foi necessário introduzir alguns elementos
adicionais e específicos na arquitetura da rede de telefonia celular. Estas entidades funcionais
podem ser implementadas em equipamentos diferentes ou híbridos. Em qualquer caso, a
transferência de dados ocorre entre estas entidades que são mostradas na Figura 2:
Figura 2 – Estrutura Básica da Rede SMS
Fonte: Adaptado de 3GPP TS 23.040
Nesta seção, serão caracterizadas as entidades funcionais presentes na estrutura básica
da rede do Short Message Service.
• MS – Mobile Station
A entidade MS (Mobile Station) é um equipamento físico que o assinante usa para ter
acesso aos serviços de telecomunicação oferecidos. Tipicamente, uma MS consiste de um
dispositivo móvel e um smart card, cujo nome é chip SIM (Subscriber Identity Module).
O padrão GSM se refere aos telefones celulares como sendo entidades MS. Além disso,
uma infinidade de dispositivos usa modems GSM para permitir a transferência de dados sobre
as redes GSM, sem a necessidade que estes possuam as funcionalidades para comunicação de
voz.
Uma MS tem vários números ID associados, incluindo o IMEI (International Mobile
Equipment Identity), o IMSI (International Mobile Subscriber Identity), o TMSI (Temporary
Mobile Subscriber Identity), e o número MSISDN (Mobile Subscriber ISDN).
MSC
SMSC
HLR
SME
SME
SME
VLR
MS
BSS
SMS GMSC
30
• BSS – Base Station Subsystem
A entidade BSS (Base Station Subsystem) é um equipamento físico responsável pela
rádio comunicação entre a rede de telefonia celular e os dispositivos móveis (i.e., Mobile
Station). Funcionalmente, uma BSS oferece cobertura para uma determinada zona geográfica
chamada célula e é subdividida em dois componentes na rede:
a) BTS (Base Transceiver Station) que contém a antena e o equipamento de
transmissão e recepção de rádio para cobertura de uma célula.
b) BSC (Base Station Controller) responsável pela alocação dos canais de rádio e
controle de uma ou mais BTS.
• MSC – Mobile-services Switching Centre
A entidade MSC (Mobile-services Switching Centre) é um centro de chaveamento
responsável por todos os serviços de comunicação necessários para atender telefones móveis
localizados em uma associada área geográfica.
O MSC constitui a interface entre o sistema de rádio e as redes fixas, executando todas
as funções de processamento de chamadas recebidas e realizadas de telefones móveis, levando
em consideração a natureza da localização dos assinantes.
Para obter cobertura de rádio comunicação em uma dada área geográfica, é necessário
um número de estações base, cada MSC seria a interface entre várias destas estações base.
Além disso, podem ser necessários vários MSC para compor uma rede que ofereça cobertura
em nível nacional.
• HLR – Home Location Register
O HLR (Home Location Register) é um banco de dados usado para o gerenciamento de
assinantes. Uma rede de telefonia celular pode conter um ou vários bancos HLR, dependendo
do número de assinantes, da capacidade do equipamento e da organização da rede.
Dois tipos de informações básicas são armazenados no HLR:
a) Informações do assinante, que são diferentes tipos de identidade que podem ser
usadas como chave para acessar as informações no banco de dados HLR.
31
b) Informações sobre localização, permitindo que as chamadas recebidas sejam
direcionadas para o MSC onde o assinante está registrado.
Qualquer atualização feita pela operadora da rede nos dados do assinante é realizada no
HLR que, além disso, armazena também outras informações de configuração de serviços.
• VLR – Visitor Location Register
Para permitir a comunicação com um telefone móvel, a rede de telefonia celular precisa
saber onde esse aparelho está localizado. O VLR (Visitor Location Register) é uma base de
dados dinâmica usada por um MSC para recuperar as informações do assinante quando seu
telefone celular for localizado na área responsável por este VLR.
Quando um telefone celular entra em uma nova área de localização (i.e., em roaming),
se inicia um processo de registro. O MSC encarregado dessa área detecta esse novo registro e
armazena no VLR o código da área de localização onde o telefone celular está situado. Se
esse telefone celular ainda não estiver registrado, o VLR consulta as informações no HLR
associado ao assinante para assim direcionar as chamadas relacionadas a ele.
• GMSC – Gateway MSC
A entidade Gateway MSC (Gateway Mobile-services Switching Centre) é um tipo
especial de MSC usado para encaminhar chamadas para outras redes de telefonia móvel.
Sempre que uma chamada recebida for de outra operadora de telefonia, ou o assinante realizar
uma chamada para um telefone de outra operadora, essa chamada será encaminhada através
do Gateway MSC. Na prática, o GMSC é um MSC configurado pela operadora para atuar
como gateway.
• SMS-GMSC – SMS Gateway MSC
O SMS-GMSC é a interface entre a rede que fornece acesso ao SMSC (Short Message
Service Centre) e a rede de telefonia móvel. Para uma mensagem de texto ser entregue, o
SMS-GMSC consulta um HLR sobre a rota de encaminhamento até o telefone celular
destinatário.
32
• SMS-IWMSC – SMS Interworking MSC
O SMS-IWMSC é a interface entre a rede de telefonia móvel e a rede que fornece
acesso ao SMSC (Short Message Service Centre). É um MSC configurado para receber
mensagens de texto provenientes de um MSC remetente e encaminhá-las para o SMSC do
destinatário.
• SMSC – Short Message Service Centre
A entidade SMSC (Short Message Service Centre) é o elemento de uma rede de
telefonia celular responsável pela transmissão, armazenamento e envio de mensagens de texto
entre dois dispositivos móveis (i.e., entidade MS – Mobile Station). Todas as mensagens SMS
são enviadas para um SMSC. O SMSC armazena as mensagens recebidas, extrai as
informações de destino e tenta entregá-las aos seus destinatários. Se a mensagem não puder
ser entregue ao destinatário, o SMSC vai tentar entregá-la novamente em uma nova tentativa
programada. Se um telefone celular recebeu uma mensagem SMS com sucesso, ele
responderá uma mensagem de confirmação ao SMSC. Usualmente, a mensagem SMS será
descartada após dois dias se o destinatário não puder ser alcançado.
A funcionalidade de um SMSC está fora do escopo das especificações técnicas GSM,
no entanto, um SMSC e um MSC podem estar integrados num mesmo equipamento.
• SME – Short Message Entity
Qualquer entidade capaz de enviar ou receber mensagens SMS é denominada SME
(Short Message Entity). Uma SME geralmente é um aplicativo de software em um dispositivo
móvel (i.e., entidade MS – Mobile Station), mas também pode estar localizado na rede de
telefonia fixa, pode ser um aparelho de fac-símile, um equipamento de telex, um servidor de
Internet remoto, etc. Além disso, uma SME pode ser um servidor conectado diretamente, ou
por meio de um gateway, a um SMSC. Nessa situação, a SME é caracterizada como uma
entidade SME externa (ESME – External SME). Tipicamente, uma ESME representa um
provedor de serviços de valor agregado, um Proxy ou servidor WAP, um gateway de e-mail
ou um servidor de correio de voz.
33
2.2. PROCEDIMENTOS FUNDAMENTAIS DO SMS
O Short Message Service é um serviço ponto a ponto e compreende dois procedimentos
fundamentais que o dividem em duas etapas, sendo a primeira etapa, o processo de envio de
uma mensagem de texto; e a segunda etapa, o processo de entrega.
O Mobile Originated SMS é o procedimento que descreve o processo de submissão de
mensagens, assim como os relatórios referentes ao sucesso ou falha na operação. Na prática,
esse é o procedimento para a transferência de uma mensagem de texto enviada por um
dispositivo móvel remetente (MS) até um centro de mensagens (SMSC). Veja na Figura 3:
Figura 3 – Procedimento MO-SMS Fonte: Adaptado de 3GPP TS 23.040
O Mobile Terminated SMS é o procedimento que descreve o processo de entrega de
mensagens, assim como os relatórios referentes ao sucesso ou falha na operação. Na prática,
esse é o procedimento para a transferência de uma mensagem de texto a partir de um SMSC
até o dispositivo móvel destinatário (MS). Veja na Figura 4:
Figura 4 – Procedimento MT-SMS Fonte: Adaptado de 3GPP TS 23.040
Relatório
Entrega do SMS
MS
SMSC
Relatório
Envio do SMS
SMSC
MS
34
Durante os processos de envio ou entrega de mensagens de texto SMS, é importante que
as entidades envolvidas na transferência (MS e SMSC) nunca fiquem sem uma resposta sobre
o status da operação. As entidades devem ser notificadas por meio de mensagens de relatório,
que informem o sucesso da operação ou o motivo de uma eventual falha. Além disso, um
dispositivo deve ser capaz de enviar ou receber mensagens de texto a qualquer momento,
independentemente se existe ou não uma chamada de voz ou dados em andamento.
(3GPP TS 23.040, 2012)
Nas redes de telefonia fixa, a localização do assinante é estática e especificada de
acordo com um esquema de numeração utilizado pela rede. Ou seja, a localização do
assinante está relacionada exclusivamente com o seu número de telefone.
Dryburgh (2005) explica que em sistemas de telefonia celular, a localização de um
assinante pode mudar drasticamente sem que o sistema esteja ciente da mudança — por
exemplo, o assinante pode desligar seu telefone celular pouco antes de embarcar em um
avião, e depois ligá-lo novamente quando desembarcar em um novo país.
Considerando uma chamada “recebida” por um telefone celular, não existe uma relação
direta entre a sua localização naquele momento e o seu número de telefone. Por isso, a
localização e outras informações devem ser obtidas antes da chamada ser entregue a um
telefone celular, em tempo real. Desta forma, o processo de entrega de chamadas requer a
execução de uma grande quantidade de processamento, em uma camada de controle chamada
de sistema de sinalização.
Ao contrário, considerando uma chamada “realizada” por um telefone celular, esta
exige muito menos recursos de sinalização inicial, porque o sistema de rádio, onde o assinante
está registrado naquele momento, já sabe a sua localização. Porém, esse cenário pode mudar
se o assinante estiver em movimento. As entidades de rádio (BTS e BSC) e até mesmo o
centro de chaveamento (MSC) podem mudar em função de novos procedimentos de registro.
Essas mudanças são conhecidas como handovers e também exigem sinalização,
principalmente se o assinante estiver atendendo a uma chamada.
Obter as informações sobre o perfil de um assinante é uma tarefa simples para as redes
de telefonia fixa, pois reside apenas na comutação local do assinante. Já nas redes de telefonia
celular, o perfil do assinante muda em função de sua mobilidade.
35
Segundo Dryburgh (2005), seria totalmente impraticável manter as informações do
perfil do assinante, que podem mudar dinamicamente em função de sua mobilidade,
armazenadas em cada centro de chaveamento MSC em todo o mundo. É principalmente por
estas razões que os sistemas de telefonia celular contam com duas bases de dados especificas
para o gerenciamento de assinantes. As bases de dados HLR e VLR foram caracterizadas na
seção anterior3.
Mobile Application Part (MAP) é o protocolo usado para permitir a comunicação entre
as entidades da rede GSM. MAP fornece uma camada de aplicação sobre a qual são
construídos os serviços oferecidos, tais como autenticação do assinante, capacidade de
roaming, e mensagens de texto SMS. Esta camada de aplicação fornece um conjunto de
operações padronizado na especificação 3GPP TS 29.002.
As operações MAP estão organizadas em cinco categorias de serviços: serviços de
mobilidade; serviços de operação e manutenção; serviços de manipulação de chamadas;
serviços suplementares e serviços de gerenciamento do SMS. Nas próximas páginas, serão
elencados e descritos os serviços que fazem parte da categoria de gerenciamento do SMS.
3 Bases de dados HLR e VLR foram caracterizadas na seção 2.1 ‒ Estrutura básica da Rede.
36
• Serviço [MAP-Mx-FORWARD-SHORT-MESSAGE]
Esse serviço é usado nos dois procedimentos fundamentais do SMS e serve para
encaminhar uma mensagem de texto. No caso de uma mensagem submetida através do
procedimento MO-SMS, a transferência ocorre do MSC do remetente para o SMS-IWMSC.
Ao contrário, no caso de uma mensagem entregue através do procedimento MT-SMS, a
transferência ocorre do SMS-GMSC para o MSC do destinatário.
Na Figura 5, podemos ver o processo de submissão de uma mensagem de texto de
acordo com o procedimento MO-SMS.
Figura 5 – Serviços MAP envolvidos no procedimento MO-SMS
Fonte: Adaptado de Dryburgh, 2005
MSC
submitSM
submitSM Ack.
forwardSM
forwardSM Ack.
SMS
SMSC SMS-IWMSC
Interface OEM MAP-E
37
• Serviço [MAP-SEND-ROUTING-INFO-FOR-SM]
Esse serviço é usado pelo SMS-GMSC para consultar o banco de dados HLR a respeito
da localização atual do assinante. Essa operação vai retornar o endereço ISDN do MSC de
destino. Uma vez determinada a rota de destino, a mensagem de texto é encaminhada para o
MSC através do serviço forwardSM. Na Figura 6, podemos ver o processo de entrega de uma
mensagem de texto de acordo com o procedimento MT-SMS.
Figura 6 – Serviços MAP envolvidos no procedimento MT-SMS Fonte: Adaptado de Dryburgh, 2005
• Serviço [MAP-REPORT-SM-DELIVERY-STATUS]
Esse serviço é usado pelo MSC para registrar no HLR o número MSISDN de um
destinatário com status de mensagem em espera. Além disso, serve para notificar o HLR que a
mesma mensagem de texto, antes pendente, foi entregue com sucesso.
• Serviço [MAP-READY-FOR-SM]
Esse serviço é usado pelo MSC para notificar o VLR que um assinante está disponível
para receber mensagens de texto pendentes. Por sua vez, o VLR usa o mesmo serviço para
repassar essa informação ao HLR.
sendRoutingInfoForSM Ack.
SMS-GMSC MSC SMSC HLR
deliverSM
deliverSM Ack.
forwardSM
forwardSM Ack.
sendRoutingInfoForSM
SMS
38
• Serviço [MAP-ALERT-SERVICE-CENTRE]
Esse serviço é usado pelo HLR para notificar o MSC que um assinante, cujo número
MSISDN está registrado com status de mensagem em espera, foi detectado e está agora
disponível para receber a mensagem de texto.
• Serviço [MAP-INFORM-SERVICE-CENTRE]
Se ocorrer uma consulta ao banco de dados HLR sobre a rota de localização de um
destinatário que não está disponível no momento, o próprio HLR informa essa
indisponibilidade ao SMS-GMSC através do serviço informServiceCentre.
• Serviço [MAP-SEND-INFO-FOR-Mx-SMS]
Esse serviço também é usado em ambos os procedimentos MO-SMS e MT-SMS e serve
para o MSC solicitar ao VLR as informações relacionadas ao assinante. Segundo a
especificação 3GPP TS 23.040 (2012), esse serviço está disponível, porém não é mais usado a
partir da evolução das redes GSM para o sistema GPRS4.
O propósito principal do protocolo MAP é permitir a realização de chamadas entre
dispositivos móveis. Ao contrário das redes de telefonia fixa, a localização de um assinante
móvel não pode ser determinada apenas a partir de seu número de telefone. Portanto, a
localização de um telefone móvel deve ser obtida em tempo real, para que uma chamada
possa ser transferida ao MSC que esteja mais próximo a ele.
Essa seção abordou os procedimentos fundamentais do serviço SMS com vistas a
entender como é o processo de transferência de uma mensagem de texto de um remetente até
seu destinatário. Vale mencionar que as especificações técnicas usadas nessa seção descrevem
o serviço de forma global, em diferentes contextos e cenários. Os diversos contextos surgem
de novas tecnologias que acompanham as novas gerações de telefonia celular (e.g., GPRS e
UMTS5). No entanto, o tema dessa seção foi abordado de forma funcional, baseado na
plataforma GSM fase 2 e servindo como fundamento para a compreensão em qualquer
contexto. 4 GPRS: Sistema de comutação por pacotes; significa uma evolução da tecnologia GSM (comutação de circuitos), porém em domínios individuais. 5 UMTS: Terceira geração de telefonia móvel celular; oferece suporte para ambas as tecnologias anteriores GSM e GPRS.
39
2.3. PROTOCOLOS DE INTERCONEXÃO
Conforme mencionado no capítulo de introdução, os provedores de serviço são
empresas parceiras das operadoras de telefonia, que oferecem seus serviços usando a rede de
telefonia celular. Os provedores precisam de uma porta de entrada para a rede de telefonia e,
nesse esquema de conexão, estão envolvidas as entidades SMSC e SME.
Um fato importante — “Para oferecer serviços de valor agregado, um provedor de
serviços (ESME – External SME) tem acesso à rede de telefonia celular estabelecendo uma
conexão com um centro de mensagens SMS (SMSC – Short Message Service Centre).”
A patente do SMSC (ROSS, 2001) prevê um equipamento fornecido com uma
pluralidade de interfaces que permita a comunicação com várias entidades. Algumas
interfaces que podem ser fornecidas são, por exemplo, uma interface administrativa —
permitindo que um administrador faça alterações e atualizações no SMSC; uma interface de
múltiplos protocolos — através da qual, mensagens SMS sejam entregues usando protocolos
geralmente conhecidos como SMPP (Short Message Peer to Peer Protocol) e SMTP (Simple
Mail Transfer Protocol); e uma interface SS76 — fornecendo uma interface de comunicação
com outros equipamentos SMSC e outras entidades da rede de telefonia.
A funcionalidade de um SMSC está fora do escopo das especificações técnicas GSM, e
como resultado disso, não foi especificada nenhuma interface padronizada para a conexão de
entidades externas ao SMSC. Na ausência de um modelo de interface predominante, os
fabricantes de SMSC criaram os seus próprios protocolos baseados em qualquer padrão
existente, que não são necessária e integralmente incompatíveis entre si.
O Instituto Europeu de Normas de Telecomunicações reconhece que uma especificação
unificada não teria muita relevância numa fase em que diversos protocolos foram
desenvolvidos e estão atualmente em uso extensivo por muitas redes de telefonia. Por esse
motivo, foi criada uma especificação (i.e., GSM 03.39) com o objetivo de fornecer um único
documento onde vários padrões de interfaces de conexão entre SME e SMSC estarão
anexados e a disposição como implementações opcionais.
6 SS7: Signalling System No. 7 – é um conjunto de protocolos empregado nas redes de telecomunicações no
mundo todo, para fornecer os serviços de controle conhecidos por sinalização.
40
“A publicação pelo ETSI7 dos vários protocolos, de fato irá limitar a proliferação de
normas proprietárias e irá beneficiar novos desenvolvedores SMSC/SME que podem, então,
adotar um ou mais dos protocolos existentes definidos no presente documento.”
(GSM 03.39, 2000)
Em 1998, surgiu um projeto de parceria entre seis organizações de telecomunicações
para definir as especificações técnicas para a terceira geração de telefonia celular. Essa
organização, chamada 3GPP8, manteve a prévia recomendação de protocolos definida na
segunda geração GSM. Na Figura 7, temos os modelos de protocolos de interface que são
sugeridos na especificação atual. (i.e., 3GPP TR 23.039)
Protocolos de Interface entre SMSC e SME Fabricante
SMPP (Short Message Peer to Peer) Aldiscon Information Systems
SMSC EMI (SMSC External Machine Interface) Computer Management Group
CIMD (Computer Interface to Message Distribution) Nokia Networks
SMSC Open Interface Specification SEMA Group
SMSC Computer Access Protocol Ericsson
Figura 7 – Protocolos de Interface entre SMSC e SME Fonte: 3GPP TR 23.039
O SMS Forum é uma organização sem fins lucrativos que foi criada por empresas
dispostas a promover o uso do SMS na indústria da mobilidade. O SMS Forum adotou o
SMPP como seu protocolo de interface padrão para conexão a um SMSC. Os protocolos
mencionados até então são proprietários e são geralmente protocolos binários operando sobre
TCP/IP ou X-25.
7 ETSI: European Telecommunications Standards Institute. 8 3GPP: 3rd Generation Partnership Project.
41
Com o surgimento de novas aplicações de mobilidade, surge a motivação para a
evolução e o desenvolvimento de novas tecnologias. Por exemplo, o SMS Forum desenvolveu
um protocolo operando sobre protocolos como HTTP onde as mensagens são baseadas em
texto e representadas no formato XML. Este protocolo foi lançado em 2003 e é chamado
MMAP (Mobile Message Access Protocol).
“Vários fabricantes oferecem soluções SMSC. Os mais conhecidos são Logica, Nokia,
CMG, SEMA e Ericsson.” (LE BODIC, 2003) Os desenvolvedores devem adotar o protocolo
mais adequado a sua implementação particular, aplicação ou segmento de mercado.
42
2.4. NEXT GENERATION NETWORK (NGN)
O conceito de rede da próxima geração (NGN – Next Generation Network) foi
introduzido para levar em consideração as novas realidades do setor de telecomunicações,
caracterizadas por fatores como a concorrência entre as operadoras de telefonia, a explosão do
tráfego digital através da Internet e a demanda crescente pela mobilidade de modo geral.
Esses fatores determinam a busca por soluções de integração entre as diferentes redes e entre
os serviços de voz, dados, mensagens e vídeo numa única plataforma multimídia.
Segundo a União Internacional de Telecomunicações (ITU-T, 2004), o objetivo
principal da NGN é garantir que todos os elementos necessários para suas capacidades de rede
e interoperabilidade suportem aplicações globalmente, mantendo o conceito de separação
entre transporte, serviços e aplicações.
“A integração é um objetivo que conta com enorme apoio, mas cuja concretização será
demorada e progressiva, segundo procedimentos que são conhecidos como convergência.”
(RIBEIRO, 2012) A Figura 8 ilustra a convergência de mídias e serviços para uma única
plataforma multimídia.
Figura 8 – Ilustração sobre Convergência Tecnológica Fonte: Elaborado pelo autor
43
A rede da próxima geração (NGN) é um tema intensamente discutido pela comunidade
mundial sobre o futuro das telecomunicações. Construir uma plataforma convergente que
esteja integrada com as redes legadas e, ao mesmo tempo, assegurar o retorno dos
investimentos é o grande desafio a ser enfrentado pelo mercado de telecomunicações. O
conceito surgiu em 1998 e, desde então, companhias de telecomunicações espalhadas pelo
mundo têm trabalhado na implementação de redes NGN baseadas em protocolos de Internet.
De acordo com a agência ITU-T9, a definição de NGN é a seguinte:
NGN é uma rede baseada em pacotes que deve prover serviços, incluindo os de telecomunicações, e com capacidade de fazer uso da banda larga múltipla, tecnologias para o transporte de QOS10 e funções relacionadas aos serviços que devem ser independentes da tecnologia associada à camada de transporte. A rede NGN deve fornecer acesso irrestrito aos usuários para os diferentes provedores de serviço, suportando mobilidade, que irá permitir a oferta de serviços de maneira universal e consistente aos usuários. (SVERZUT, 2011)
Uma implementação baseada nos conceitos da próxima geração de redes e que tem se
mostrado eficiente no mercado de telecomunicações é a arquitetura IMS (IP Multimedia
Subsystem). Segundo Sverzut (2011), a arquitetura IMS emplacou porque pôde se integrar às
redes de telefonia móvel que são baseadas em tecnologias de segunda e terceira gerações
(GSM e UMTS). Essas redes, mesmo com tendência a serem consideradas legadas com o
passar dos anos, possuem presença marcante em todos os continentes do mundo,
representando mais de 4,6 bilhões de linhas móveis. (fonte: GSM World) 11
A arquitetura IMS é de muita relevância no contexto de convergência tecnológica e
também fundamental para o propósito deste trabalho de pesquisa. Portanto, o IP Multimedia
Subsystem será tema da próxima seção.
A conclusão de Ribeiro (2012) a respeito da convergência é que convivemos hoje em
um ambiente composto por muitas redes, de diferentes naturezas e processos de comunicação,
que estão se integrando numa rede global muito maior, mas que ainda preservam uma
heterogeneidade interna.
9 ITU-T: International Telecommunication Union – Telecommunication Standardization Sector.
10 QOS: Acrônimo para Quality of Service, termo definido pela ITU em 1994. 11 Fonte: http://www.gsmworld.com
44
2.5. IP MULTIMEDIA SUBSYSTEM (IMS)
Elaborado pela organização 3GPP, o IP Multimedia Subsystem (IMS) é um conjunto de
especificações que foi baseado nos conceitos da próxima geração de redes (NGN) e que
define uma arquitetura completa e um framework que permitem a convergência dos serviços
de voz, dados, mensagens e vídeo sobre uma infra-estrutura baseada em IP. É uma tecnologia
que pretende preencher a lacuna entre os dois paradigmas de comunicação mais bem
sucedidos, telefonia celular e Internet.
Como já citado na seção anterior, o IMS é de muita relevância no contexto de
convergência tecnológica e também fundamental para o propósito deste trabalho de pesquisa.
Diante desse fato, surge uma questão que nos leva a perguntar sobre qual será o futuro do
SMS. Essa seção pretende responder a essa questão, limitando-se a uma visão geral da
arquitetura IMS com foco, principalmente, no suporte que ela oferece ao SMS, que é o
serviço de comunicação móvel usado na realização desse sistema de comercialização de
títulos de capitalização. Além disso, esse estudo pode nos levar a novas possibilidades de
implementação desse serviço.
O IMS possui uma arquitetura normalizada de controle e prestação de serviços
multimídia que utiliza IP na camada de transporte e o protocolo SIP (Session Initiation
Protocol) para a sinalização de serviços. Neste contexto, é importante notar que,
"normalizada" refere-se apenas à arquitetura (nodos, protocolos e interfaces) e não aos
serviços fornecidos por meio dela. No caso das tecnologias de segunda e terceira gerações
(GSM e UMTS), as normas abrangem a arquitetura, bem como o conjunto de serviços. Isto
significa que os serviços estão integrados na arquitetura; não é impossível, mas torna-se
impraticável uma separação. (ERICSSON, 2010)
No entanto, IMS é diferente. É uma arquitetura normalizada, mas não inclui quaisquer
serviços padronizados. Esse fato mostra o IMS como uma infra-estrutura disponível para a
implantação de serviços.
Para que um serviço de comunicação em massa seja implantado com sucesso, é
necessário que uma boa parte de suas funções seja padronizada. Entre as funções, é
importante padronizar uma interface que forneça a interconexão com redes de outras
operadoras de telefonia; e uma interface de usuário, que permita aos consumidores se
beneficiar dos serviços oferecidos.
45
Uma vantagem da arquitetura IMS é a sua versatilidade e flexibilidade. Esse fato a
caracteriza como uma tecnologia que pode ser usada para oferecer diversos tipos de serviços.
O artigo da companhia Ericsson (2010) menciona que isso não significa que todos os serviços
implementados sobre IMS têm sido normalizados; de fato, apenas alguns conjuntos de
serviços foram normalizados até o momento.
O artigo de Leitão (2009) apresenta e discute a arquitetura e os tipos de
interoperabilidade para o serviço de mensagens SMS, com vistas à sua implementação num
cenário real de convergência entre as redes legadas GSM e as redes IMS baseadas em
protocolos de Internet.
Segundo Leitão (2009), em qualquer cenário de migração de uma tecnologia utilizada
massivamente, sempre haverá um período de convivência entre a tecnologia nova e a legada.
Nesse período, é fundamental manter os serviços de maior popularidade entre os
consumidores. Este é o caso do Short Message Service, que foi concebido inicialmente na
década de 1980 e ainda é um serviço de dados extremamente rentável para as operadoras de
telefonia móvel.
No entanto, Leitão (2009) também afirma que se considerarmos um cenário de
migração total para a tecnologia IMS, o SMS se tornaria obsoleto. Isto significa que as
operadoras de telefonia móvel deixariam de considerar uma possível interoperabilidade dos
serviços legados, que são baseados em sinalização MAP12, com as redes IMS, criando um
novo cenário que passaria a ser totalmente baseado em protocolos sobre IP.
É evidente a importância da interoperabilidade com o Short Message Service, fato que
motivou a organização 3GPP a propor em 2005 uma arquitetura que inclui um gateway entre
os domínios das redes GSM e IMS (i.e., 3GPP TS 23.204). O IP-SM-GW (IP Short Message
Gateway) será a entidade responsável pela interoperabilidade dos serviços de mensagens entre
as duas redes, conforme ilustra a Figura 9. Este gateway será visto na rede GSM como uma
entidade MSC13 e na rede IMS como um SIP14
Application Server.
12 MAP: Mobile Application Part, assunto abordado na seção 2.2 – Procedimentos Fundamentais do SMS. 13 MSC: Mobile-services Switching Centre, definido na seção 2.1– Estrutura Básica da Rede. 14 SIP: Session Initiation Protocol, protocolo especificado em RFC 3261 pela IETF. (LE BODIC, 2003)
46
Figura 9 – IP-SM-GW, o gateway entre os domínios das redes GSM e IMS Fonte: Leitão, 2009
O IP-SM-GW deve fornecer o protocolo de interface para a entrega de mensagens de
texto entre um dispositivo móvel com recursos IMS e um centro de mensagens SMS (SMSC).
Basicamente, temos duas situações funcionais: o gateway encaminha uma mensagem para um
SMSC para que seja entregue a um destinatário com recursos SMS; ou, o gateway recebe uma
mensagem de um SMSC para que seja entregue a um destinatário baseado em IMS.
2.5.1. Funções para Interoperabilidade com o SMS
A especificação 3GPP TS 23.204 (2012) propõe uma arquitetura sobre IP que suporte
plenamente as funcionalidades do SMS. A arquitetura deve ser capaz de selecionar o domínio
para a entrega de uma mensagem (entre SMS ou IMS), transformar o formato de uma
mensagem conforme necessário, notificar a rede quando um dispositivo móvel estiver
disponível para receber mensagens e fornecer um mecanismo de cobrança no domínio correto,
que seja apropriado para os serviços de interoperabilidade.
47
Para realizar os serviços de interoperabilidade de acordo com esses requisitos, o IP-SM-
GW dispõe de duas funções normalizadas que serão comentadas a seguir.
(i.e., Transport-Level Interworking e Service-Level Interworking)
• Transport-Level Interworking
A interoperabilidade Transport-level é a função onde a mensagem de texto é
encapsulada no corpo da mensagem IMS, sendo transportada até seu destinatário usando o
protocolo SIP, de forma que mantenha o formato e a funcionalidade do SMS. Além disso,
essa função deve tratar da mesma forma as notificações de status da mensagem, registrar as
configurações e autorizações desse serviço, bem como, ser responsável por registrar as
informações do assinante, de certa forma, emulando o trabalho de um MSC.
Essa forma de interoperabilidade está disponível para dispositivos móveis que suportem
enviar e receber mensagens SMS encapsuladas em mensagens IMS. Se o IP-SM-GW
identificar que se trata de uma mensagem SMS encapsulada, ele então procederá à
interoperabilidade Transport-level.
O artigo de Leitão (2009) menciona que o que se pretende com este conceito é permitir
que um consumidor continue a usufruir do SMS, independentemente da sua rede de acesso ser
IMS ou GSM.
• Service-Level Interworking
A interoperabilidade Service-level é a função onde ocorre a conversão da mensagem
SMS em mensagem instantânea no IMS, ou vice-versa, determinando se deve transformar o
formato da mensagem conforme as configurações do serviço. Além disso, essa função deve
recuperar o endereço do SMSC e incluir essa informação durante o processo de conversão da
mensagem instantânea em mensagem SMS, bem como, ser responsável por registrar as
configurações e autorizações desse serviço.
Se o IP-SM-GW identificar que se trata de uma mensagem cuja rota de destino não
pode ser encontrada no domínio IMS, ele então procederá à interoperabilidade Service-level.
A especificação 3GPP TS 23.204 (2012) também destaca que o IP-SM-GW deve ter um
tratamento adequado a respeito de convites para sessões de bate-papo. O equipamento deve
estar configurado de forma que atenda a política adotada pela operadora de telefonia com
48
relação ao serviço de chat em IMS, por exemplo, nem todos os consumidores de SMS
desejam receber convites para uma sessão de bate-papo. Nessa condição, o gateway deve
fazer o trabalho de impedir que um convite chegue ao consumidor e deve enviar, em nome do
próprio consumidor, uma mensagem de rejeição ao convite.
Uma questão importante — “A disponibilidade das funções de interoperabilidade,
Transport-level e Service-level, vai depender da autorização do consumidor, de forma que
faça a assinatura pelos serviços que desejar.”
Diante dos diversos cenários de interoperabilidade que podem surgir, o IP-SM-GW
deve assumir um comportamento que vai depender daquele cenário específico, dos recursos
do dispositivo móvel registrados na rede, e finalmente, será definido pela política da
operadora de telefonia e pelas preferências configuradas pelo consumidor.
A evolução das redes de telecomunicações vai ao sentido da introdução de tecnologias
mais recentes, com maior capacidade, possibilitando a emergência de novos e mais
sofisticados serviços. Contudo, essas evoluções na rede são muitas vezes indiferentes para
seus usuários (LEITÃO, 2009)
É possível conceber cenários de convivência de mensagens entre redes com tecnologias substancialmente distintas, possibilitando a coexistência quer dos serviços, quer das próprias redes. Tal permite a evolução gradual das redes de telecomunicações, mantendo inalterável a base de utilizadores dos serviços de mensagens (curtas ou instantâneas). (LEITÃO, 2009)
Essa conclusão de Leitão (2009) que acabamos de ler é bastante positiva neste
momento. Até este ponto da pesquisa, foi possível encontrar as informações referentes às
características das redes e aos serviços de telecomunicações, nos levando à compreensão da
infra-estrutura e direcionando o rumo dos trabalhos, além de nos revelar as principais
evoluções e tendências tecnológicas.
49
2.6. ARQUITETURA JAVA EE
Em um contexto corporativo, as empresas precisam continuamente ampliar seu alcance
nos negócios, reduzir custos, reduzir os tempos de entrega e melhorar a qualidade de seus
serviços. Para superar esses desafios, as novas aplicações precisam integrar os sistemas
corporativos existentes com novas funcionalidades de negócio. O aumento das exigências
corporativas, em termos de quantidade e complexidade, motivou a criação de novas
arquiteturas para as aplicações; das tradicionais arquiteturas, a monolítica e Cliente/Servidor,
para um modelo de arquitetura multicamadas.
Além disso, a evolução da Internet gira em torno de um ambiente extremamente
heterogêneo, que faz uso de arquiteturas distribuídas, multicamadas e peer-to-peer. Alguns
fatores críticos como latência, largura de banda e disponibilidade surgem naturalmente.
Modelos em camadas são concebidos para solucionar problemas de um domínio
específico. Desta forma, cada modelo assume uma característica peculiar.
A plataforma Java EE adota um modelo de aplicação que tem como base fundamental a
linguagem de programação Java e um ambiente de execução, este que consiste na máquina
virtual Java (JVM). A portabilidade, segurança e produtividade no desenvolvimento já são
características comprovadas da plataforma Java e completam o modelo de aplicação dessa
edição que é voltada para sistemas corporativos. A edição Java EE foi projetada para suportar
aplicações que implementam serviços corporativos para clientes, funcionários, fornecedores,
parceiros e outros que vierem a surgir sob demanda. Aplicações desse tipo são naturalmente
complexas e acessam dados a partir de uma variedade de fontes e aplicações que são
distribuídas a uma variedade de clientes. (JENDROCK et al., 2013)
Para suportar o acesso de vários usuários, as regras de negócio dessas aplicações são
implementadas em uma camada conhecida como camada intermediária, está que fica
localizada entre a camada de aplicação do cliente e a camada de serviços. A camada
intermediária consiste de um servidor tipicamente executado em um hardware dedicado, e
possui acesso a todos os serviços da companhia. Em função disso, a camada intermediária
representa um ambiente rigorosamente controlado. (JENDROCK et al., 2013)
50
A plataforma Java EE possui uma arquitetura para hospedagem de aplicações,
organizada em containeres, fato que permite a construção de aplicações multicamadas. O
desenvolvimento em camadas oferece a separação dos diferentes níveis das aplicações, cujas
características são de distribuição de componentes pela rede, portabilidade, suporte a
transações, oferecendo altas taxas de segurança e confiabilidade e com ciclos de
desenvolvimento e custos reduzidos. Para atender aos requisitos dessas aplicações, a
plataforma Java EE possui um conjunto de APIs bastante extenso.
Normalmente, as aplicações multicamadas são difíceis de desenvolver porque resultam
em muitas linhas de código para lidarem com a complexidade de tarefas e recursos de baixo
nível. A arquitetura Java EE é independente de plataforma e é baseada em componentes, o
que faz dela uma plataforma onde as aplicações são mais simples de escrever, porque a lógica
de negócio é organizada em componentes que são reutilizáveis. Além disso, um servidor Java
EE fornece serviços subjacentes dispostos nos containeres que são dedicados a cada tipo de
componente. Desta forma, é possível concentrar os esforços para elaborar a lógica de negócio,
reutilizando serviços já disponíveis ou serviços que podem ser desenvolvidos por terceiros.
Os containeres são definidos como a interface entre componentes de software e as
funcionalidades de baixo nível oferecidas por uma plataforma que suporte este componente.
Antes que possa ser executada, uma aplicação corporativa ou web deve ser implantada em um
container Java EE. Os containeres são os responsáveis por oferecer serviços a múltiplos
clientes.
O desenvolvimento de uma aplicação, em si, envolve a configuração de um container
para cada tipo de componente que será implantado nele. Esse processo de configuração de um
container customiza o suporte fornecido pelo servidor Java EE como um todo, incluindo os
serviços de segurança, gerenciamento de transações, lookups dos serviços de diretório e
conectividade remota. O fato de a plataforma Java EE ser organizada em containeres oferece
alguns serviços de infra-estrutura pré-definidos. Quanto a esse modelo de implementação, a
especificação Java EE destaca as seguintes características:
• O modelo de segurança Java EE permite configurar os componentes de negócio ou web,
de modo que os recursos do sistema sejam acessados apenas por usuários ou outras
aplicações que estejam autorizadas.
51
• O modelo de transação Java EE permite especificar as relações entre os métodos que
compõem uma única transação, de modo que todos eles sejam tratados como um único
pacote de métodos dentro da transação.
• Os serviços de lookup fornecem uma interface unificada para os serviços de diretório,
de modo que todos os componentes da aplicação possam ter acesso a esses serviços.
• O modelo de conectividade remota Java EE gerencia a comunicação entre clientes e
componentes corporativos. Um cliente pode instanciar um componente remoto e depois
pode invocar os seus métodos como se estivesse rodando na mesma máquina virtual.
Como a plataforma Java EE fornece serviços que são configuráveis, os componentes de
uma aplicação podem se comportar de formas diferentes com base nas configurações locais
do container onde são implantados. Por exemplo, um componente de negócio pode ter
configurações de segurança que permitam certo nível de acesso a um banco de dados em um
determinado ambiente de produção e, ao mesmo tempo, que permitam outro nível de acesso
ao mesmo banco de dados em outro ambiente de produção.
No entanto, os containeres também gerenciam serviços que não são configuráveis, ou
seja, os serviços que possuem os seus ciclos de vida próprios. São assim os componentes EJB,
os Servlets, os mecanismos de persistência de dados e a implementação das APIs da
plataforma Java EE.
52
A Figura 10 ilustra a organização dos componentes de software que são implantados
nos containeres. Podemos ver também o relacionamento entre os componentes de uma
aplicação, bem como, o relacionamento entre os containeres. Em seguida, são caracterizados
os elementos presentes na arquitetura Java EE.
Figura 10 ‒ Servidor Java EE e seus containeres Fonte: Adaptado de Jendrock, 2013
Database
Client
Machine
Java EE
Server
Web
Container
EJB
Container
53
• Java EE Server — Corresponde ao ambiente de execução de um servidor Java EE. Um
servidor Java EE fornece os containeres Web e EJB.
• EJB Container (Enterprise JavaBeans) — Gerencia a execução de componentes EJB
para aplicações Java EE. Componentes EJB (corporativos) e seu container são
executados no servidor Java EE.
• Web Container — Gerencia a execução de páginas web e Servlets para aplicações Java
EE. Os componentes web e seu container são executados no servidor Java EE.
• Application Client Container — Gerencia a execução de componentes da aplicação
cliente. Aplicativos clientes e seu container são executados em um computador cliente.
• Applet Container — Gerencia a execução de Applets. Consiste de um navegador web
(browser) e um plug-in Java que são executados em um computador cliente.
Devido ao fato de hospedar múltiplas aplicações, o servidor Java EE é caracterizado
como um Application Server. Usualmente, um Application Server permite o gerenciamento
local e remoto das aplicações e oferece a integração com outros serviços, tais como bancos de
dados relacionais, barramentos de mensagens, Web Services, sistemas legados e outros
Application Servers. Além disso, o servidor explora as capacidades especiais do hardware
(e.g., múltiplos processadores, hot-swapping de dispositivos, redundância, escalabilidade e
clustering).
Application Servers compatíveis com a especificação Java Enterprise Edition são uma
realidade de mercado e a aderência a este padrão amplia as possibilidades de sua utilização e
reduz a dependência de fornecedores específicos.
54
2.7. MOTIVAÇÃO PARA WEB SERVICES
A interoperabilidade foi um tema bastante discutido no Capítulo 2, fato que justifica a
motivação em adotar também Web Services na construção dessa arquitetura. Para evidenciar o
que são Web Services na prática, abaixo temos um trecho de uma entrevista citada na obra de
Josuttis (2008). A entrevista foi dada por Adam Bosworth (AB), um gerente sênior da
Microsoft no final da década de 1990, a Kirk McKusick (KM), dirigente de um grupo de
pesquisas da Universidade da Califórnia em Berkeley.
KM: Certamente, as pessoas estão falando muito sobre Web Services, mas não está claro se estão falando sobre a mesma coisa. Como você definiria “Web Services”?
AB: O termo Web Services se refere a uma arquitetura que permite que as aplicações falem umas com as outras. Ponto final. Fim da discussão.
KM: Bastante justo. Então o que podemos dizer que os Web Services não são?
AB: Bem, eles não são super eficientes. Mas isso pode não ser um problema tão grave já que estamos falando de mensagens autodescritivas que são fáceis de rotear e controlar durante o caminho. E isso é algo que não era verdadeiro nas infra-estruturas de mensagens anteriores. (MCKUSICK; BOSWORTH, 2003 apud JOSUTTIS, 2008, p.181)
Além disso, os Web Services são uma tendência: “Em 2006, mais de 60% dos 527
bilhões de dólares do mercado de serviços profissionais de TI será baseado na exploração de
padrões e tecnologias de Web Services.” (JOSUTTIS, 2008)
Segundo Pulier (2008), temos duas categorias principais de interoperabilidade através
de Web Services: 1) chamada de procedimento remota (RPC15) e 2) troca de dados.
Tipicamente, qualquer implementação de Web Services envolve uma ou ambas as categorias.
Nenhum desses processos é novo, porém, devido a sua natureza aberta, os Web Services
permitem que as chamadas de procedimento remotas e a troca de dados se tornem muito mais
versáteis do que eram no passado. O resultado é a interoperabilidade em uma escala muito
maior.
15 RPC: é uma tecnologia de comunicação entre processos que permite que um programa de computador invoque remotamente a execução de uma sub-rotina, ou de um procedimento que esteja em outro computador, por meio de uma rede compartilhada.
55
Com Web Services, é possível alcançar os mesmos resultados de tecnologias
amplamente usadas, porém mais antigas, sem o custo de manter uma rede dedicada. Isso é
importante em cenários onde há resistência às mudanças. As companhias forçam as
plataformas antigas a lidarem com processos B2B mais avançados e que estão em constante
mudança, isso geralmente cria soluções de custo elevado e causa frustrações durante as
negociações.
No entanto, não significa que isso seja uma realidade. Obviamente, a realidade é que
muitas empresas grandes usam tecnologias antigas e continuarão a usá-las no futuro. Por parte
das empresas, sempre existirá a preocupação com os custos e incertezas de uma migração,
causando, naturalmente, uma mudança gradual para a tecnologia de Web Services. Pulier
(2008) faz uma observação importante — é possível fazer uma combinação do melhor de
ambas as tecnologias de acordo com a necessidade. Por exemplo, enviando-se uma
mensagem, cujo formato é antigo e pertence a uma tecnologia legada, encapsulada em um
envelope SOAP, que pode ser transmitido pela Internet facilmente, sendo assim legível por
uma ampla gama de computadores clientes na web.
Como alternativa, é possível também manter os sistemas implantados onde estão, e
expor como Web Services apenas algumas de suas funcionalidades e dados chave. Desta
forma, os sistemas passam a oferecer serviços de interoperabilidade com seus múltiplos
fornecedores e com relativa facilidade. Um conjunto modular de serviços baseados em Web
Services, que são fracamente acoplados, garante simplicidade na substituição de um
fornecedor. Essa flexibilidade permite que as aplicações sejam projetadas em torno das
prioridades do negócio, libertando-as da dependência de tecnologias ou fornecedores.
“A interoperabilidade entre sistemas que são executados em plataformas, sistemas
operacionais e linguagens de programação diferentes é extremamente problemática — e
categoria de maior orçamento — em toda a TI.” (PULIER, 2008). Porém, os Web Services
podem reduzir muitos dos custos e esforços associados a um tipo de ambiente heterogêneo,
graças a suas capacidades de permitir invocar procedimentos remotamente e de permitir a
troca de dados entre sistemas distintos e heterogêneos.
Conforme surgem novas oportunidades de negócio que estabelecem novas parcerias e
alianças entre companhias, a tecnologia de Web Services passa a representar um papel
extremamente importante na integração das empresas e parceiros de negócio.
56
2.8. SEGURANÇA
A plataforma Java EE, por si só, já possui mecanismos de segurança para o caso de
aplicações em rede, e esses mecanismos são suficientemente flexíveis para especificar
diferentes níveis de permissão de acesso. (JANDL, 2007) Sendo assim, esta seção pretende
caracterizar apenas a questão da segurança a respeito de Web Services.
Na literatura, alguns fatores são relacionados quanto à imaturidade de Web Services,
mas um deles mostra-se de maior relevância — a questão da segurança — onde expor dados
importantes por meio de padrões que qualquer um possa compreender é uma faca de dois
gumes — eficiente por um lado e “mortal” por outro. Pulier (2008) é enfático: “[...] sem
proteger os seus serviços de acessos sem autorização, nem toda a eficiência do mundo vale os
riscos.” Então, para utilizar Web Services, o acesso de usuários e sistemas clientes deve ser
autorizado e autenticado, além de oferecer criptografia para mensagens sob demanda.
Por outro lado, tentar atender a todos os requisitos e situações possíveis de segurança
demanda um esforço que não é praticável. Mas esse esforço pode nos recompensar se
considerarmos fornecer pontos possíveis de extensão, como previsões de segurança, de forma
a permitir que a segurança seja reforçada no futuro. As boas práticas recomendam ter
segurança em mente desde o começo do desenvolvimento, mas isto não significa que você
tenha que lidar com todos os aspectos de segurança imediatamente; alguns conceitos de
segurança serão implementados à medida que o ambiente evolui.
“Você tem que definir e implementar uma abordagem de segurança estratégica que
cubra infra-estrutura, arquitetura e aplicações. A melhor abordagem é introduzir segurança
como um serviço.” (JOSUTTIS, 2008)
Segundo Josuttis (2008), em todos os sistemas distribuídos existe o risco de ataques
externos, uma vez que o sistema está exposto na web. O excesso de requisições, sejam elas
legitimas ou não, podem quebrar um provedor de serviços, e quando os ataques maliciosos
ocorrem, é preciso detectá-los e reagir rapidamente. Além disso, em um ambiente que use
XML e Web Services, também são possíveis outros tipos de ataques.
57
XML é uma linguagem primitiva e recursiva, e em determinadas situações, os
interpretadores XML podem expandir arquivos muito pequenos em documentos enormes.
Vamos considerar o exemplo da Figura 11 que é conhecido como uma “Bomba XML”.
Figura 11 – Exemplo de uma Bomba XML Fonte: Adaptado de Josuttis, 2008
Neste exemplo, o problema é que a entidade referenciada (Entidade “a” na linha 9) se
expande em três novas referências (3 vezes entidade “b” na linha 4). O mesmo ocorre com as
próximas duas entidades referenciadas (Entidades “c” e “d” nas linhas 5 e 6), levando a uma
expansão total de 33 referências. Veja na Figura 12 que no resultado exibido no browser
teremos 27 ocorrências de “foo”.
Figura 12 – Resultado de uma Bomba XML Fonte: Adaptado de Josuttis, 2008
58
Digamos que agora tenhamos 10 entidades com 10 expansões para cada uma delas. O
arquivo XML continua com poucas linhas de código, mas o interpretador XML vai expandir
isso para uma seqüência de 1010 referências, ou seja, o browser deverá exibir 10 bilhões de
ocorrências de “foo”, o que certamente consumirá muito processamento e memória.
Normalmente, os processos que enfrentam uma sobrecarga como essa quebram.
Observe que esse tipo de ataque não pode ser detectado por um firewall, porque o
problema não está no número de mensagens, mas sim no conteúdo. (JOSUTTIS, 2008) Em
aplicações onde a disponibilidade é um requisito importante, é necessário encontrar maneiras
de restringir os interpretadores XML a fim de impedir que processem esse tipo de situação.
Outra consideração importante a se mencionar é que as mensagens SOAP permitem
anexar qualquer tipo de arquivo, da mesma forma que em e-mails, e isso pode ser uma porta
de entrada para vírus, worms, etc. Nessa condição, é necessário também integrar um software
antivírus como parte da infra-estrutura.
A importância das aplicações sendo executadas em mainframes é tal que organizações antes evitavam utilizar a tecnologia de Web Services para expor interfaces por causa de medos de segurança. Esses medos foram bastante enfraquecidos por causa das muitas estórias de sucesso de exposição de Web Services de mainframes seguros, e os enormes benefícios dos custos resultantes. (PULIER, 2008)
Pulier (2008) conclui que, de fato, a tecnologia de Web Services não possui nenhuma
funcionalidade inata para lidar com desafios de segurança e gerenciamento. Por enquanto, a
solução está em manter o controle nas fronteiras do ambiente de sua aplicação, operando de
forma segura e confiável por si mesmo.
59
2.9. API(s) PADRÃO PARA REDES DE TELEFONIA
Segundo a União Internacional de Telecomunicações (ITU-T, 2004), uma rede NGN
deve ser constituída de APIs (Application Programming Interfaces), a fim de apoiar a criação,
provisão e gerenciamento de serviços. Isso garante que os provedores ofereçam serviços
customizáveis onde os próprios clientes poderão personalizar seus próprios serviços.
O artigo de Chen et al. (2006) revela que os provedores de serviços estão ansiosos para
permitir que seus clientes sejam capazes de desenvolver e implementar serviços que
aproveitem os recursos de serviços já existentes. Ao mesmo tempo, muitos desenvolvedores
de aplicativos corporativos podem ter uma relevante experiência em TI, mas não estão
familiarizados com os protocolos complexos de telefonia (e.g., SIP, ISDN, SS7, etc.). Os
desenvolvedores precisam de uma API simples para criação e desenvolvimento de serviços de
telecom.
No contexto dessa necessidade, temos um conjunto de Web Services que é o mais usado
pela comunidade de telecomunicações, o chamado Parlay X SOA. Ele foi definido pelo Grupo
Parlay em 2003 a fim de fornecer um conjunto de Web Services para Telecom, que fosse de
alto nível e simples de usar. Com a interface Parlay X SOA, os desenvolvedores de aplicativos
podem acessar e alavancar os serviços existentes na rede IMS mais facilmente através de Web
Services. (CHEN et al., 2006)
Parlay Group foi um órgão sem fins lucrativos que consistia na reunião de diversas
empresas. Ele foi estabelecido em 1998 com o objetivo principal de formular um conjunto
comum de APIs, especificamente, para criar serviços inovadores para o mercado de
telecomunicações. Atualmente, a OMA (Open Mobile Alliance) é a organização responsável
pelo desenvolvimento e manutenção das especificações Parlay.
Mais recentemente, surgiu também a OneAPI (Open Network Enabler API), um perfil
de interface totalmente baseado nas especificações ParlayREST da OMA. OneAPI é uma
iniciativa da GSM Association (GSMA) que se destina a complementar as APIs existentes nas
camadas cliente e web, fornecendo uma peça que faltava: o acesso a informações e recursos
da rede, independentemente da operadora de telefonia. Isso se torna possível com o uso de
aplicações web, em vez de simplesmente usar aplicações clientes dedicadas.
60
É de conhecimento do mercado de Telecom a existência de APIs definidas para acelerar
o desenvolvimento de aplicações para o mundo móvel, mais notavelmente, com o conjunto de
Web Services Parlay X. O time de desenvolvimento da OneAPI tem colaborado com a OMA
(Open Mobile Alliance) para revisar as especificações Parlay X no sentido de melhorar a
usabilidade da API.
O objetivo do projeto OneAPI é estender os serviços oferecidos pelas APIs atuais para
um alcance global de desenvolvedores. A GSMA aposta nos benefícios que devem acontecer
por meio do aumento da usabilidade de sistemas móveis, do aumento no volume de dados e
de uma demanda crescente e global para todos os diferentes tipos de serviços de telefonia
móvel, sejam eles serviços de voz ou dados.
A OMA anunciou em seu portal na internet que em 2013 deve encerrar os trabalhos de
desenvolvimento de novas APIs, a pedido da GSMA, que deve assumir plenamente os
trabalhos. (OPEN MOBILE ALLIANCE, 2013) De tudo que pudemos ver nesta seção, isto
significa uma possível unificação dos padrões Parlay aos padrões OneAPI, de forma que a
GSMA se consolide na adoção de sua marca OneAPI no sentido de assumir a liderança desse
mercado.
Durante a pesquisa, as primeiras conclusões direcionavam esse trabalho a propor uma
arquitetura que usasse uma implementação dos Web Services ParlayREST, em função de sua
consolidação e popularidade no segmento de Telecom. A decisão da OMA em encerrar o
desenvolvimento de novas APIs nos motiva a elencar também, como uma segunda opção, o
uso de uma implementação de OneAPI. Mas sabemos também, que o ano de 2013 dará início
a um período de transição, portanto, e a propósito desse trabalho, vamos considerar uma
arquitetura de software onde possam ser implementadas as duas APIs, ParlayREST e OneAPI.
Segundo Lozinski (2003), em desenvolvimento de software, o foco tem sido as
interfaces entre as camadas individuais. Um dos benefícios do uso de APIs comuns é que elas
garantem que as aplicações sejam independentes de hardware e de fornecedores, podendo ser
portadas facilmente para outras plataformas. Esse fato se torna bastante relevante ao
considerarmos, mais uma vez, estender os serviços oferecidos pelas APIs atuais para um
alcance global de desenvolvedores.
Considerando uma abordagem de API, no contexto de comunicação, significa que é
possível escrever aplicações portáveis que serão executadas em uma variedade de protocolos
61
subjacentes, sem a necessidade de mudanças. No contexto deste trabalho, isso significa que
uma implementação do sistema pode ser desenvolvida em qualquer plataforma, inclusive na
plataforma Java, enquanto que este fato não restringe a execução da aplicação sobre as redes
de telefonia que são baseadas em tecnologias diferentes como a GSM, GPRS, EDGE, UMTS
ou IMS.
No passado, muitas integrações eram necessárias, na maioria delas, integrações
fragmentadas e com longas curvas de aprendizagem. A necessidade de integração continua
existindo, a novidade está em definir uma API de acesso à rede que permita uma integração
unificada e padronizada, um time-to-market mais eficiente, uma redução dos custos e ampliar
a base de clientes do desenvolvedor, que poderá disponibilizar seus aplicativos para mais
operadoras de telefonia.
62
3. UMA PROPOSTA DE ARQUITETURA PARA SISTEMAS DE
COMERCIALIZAÇÃO DE TÍTULOS DE CAPITALIZAÇÃO ATRAVÉS DO
SHORT MESSAGE SERVICE
ste capítulo é o resultado do estudo de caso do trabalho de pesquisa. Nas próximas
seções, serão abordados os aspectos referentes aos materiais e métodos e
modelagem do sistema, resultando na proposta de uma arquitetura de software voltada para
sistemas de comercialização de títulos de capitalização através do Short Message Service. No
final do capítulo, serão colocadas algumas questões que são relevantes para uma discussão
com a arquitetura que foi proposta.
3.1. MATERIAIS E MÉTODOS
Durante anos, houve uma crença de que as operadoras de telefonia poderiam contar com
alguns aplicativos dedicados para aumentarem substancialmente o seu faturamento, os
aplicativos chamados de killer apps16. No entanto, hoje vivenciamos um mercado
fragmentado, com o perfil dos consumidores em constante mudança, onde as operadoras de
telefonia precisam oferecer rapidamente uma variedade de serviços que atendam a essas
necessidades e preferências individuais. Diante desse desafio, os provedores de serviços
precisam de uma plataforma flexível e que ofereça desempenho e confiabilidade. Só assim, é
possível criar um portfólio de serviços bem sucedido.
Durante a pesquisa, percebeu-se que os provedores possuem um formato de arquitetura
bem parecido, mas, notavelmente, uma das camadas teve maior destaque; a camada
correspondente ao core da plataforma, na maioria das vezes, chamado por ambiente de
execução (e.g., runtime engine). Um desses provedores possui um ambiente de execução que
roda sobre a plataforma Java. O ambiente foi projetado exclusivamente para aplicações
orientadas a eventos, que requerem processamento de transações extremamente elevado e, ao
mesmo tempo, suportando um ambiente de processamento de eventos distribuído e replicado.
O provedor afirma que o resultado é uma plataforma de execução de serviços robusta que
oferece escalabilidade e confiabilidade para qualquer aplicação implantada nela.
16 Killer Apps: É uma ferramenta de marketing que usa o sucesso de um aplicativo para incentivar o consumidor a comprar outro produto associado, é uma forma de direcionar as vendas.
E
63
Obviamente, a pesquisa revelou também que cada provedor de serviços oferece uma
gama diversificada de funcionalidades em sua plataforma, o que cada um classifica como seu
diferencial. Uma destas funcionalidades que é bem interessante é a de oferecer um framework
para a construção de serviços. Esse framework contém blocos de serviços independentes, que
podem ser usados individualmente, ou podem ser montados numa combinação de diferentes
mídias, criando assim serviços híbridos e sofisticados, reunindo telefonia, mensagens e web
na mesma aplicação.
Essa característica modular permite sua extensão de forma progressiva e reduz
drasticamente o time-to-market para os novos serviços. Oferecer um conjunto abrangente de
blocos para construção de serviços se torna interessante porque pode abstrair algumas
funcionalidades da aplicação como o gerenciamento de sessões e o gerenciamento de mídia,
por exemplo.
Além dos desafios tecnológicos, as operadoras de telefonia móvel também
experimentam constante pressão sobre suas margens de lucro, e precisam encontrar maneiras
de cortar custos. Um provedor de soluções pesquisado defende que os custos mais recorrentes
podem ser reduzidos em até 25% ao se usar menos fornecedores, ou seja, uma das melhores
maneiras para se reduzir os custos de operação (OPEX17) é consolidar todos os serviços de
valor agregado (VAS) em uma única plataforma.
Isso significa oferecer um único ponto de conexão na rede para o acesso aos ambientes
da operadora de telefonia para executar todas as operações: manutenção, atendimento ao
cliente, emissão de relatórios, gestão de alarmes e de faturamento, etc. Este único ponto de
acesso permitiria alcançar a qualquer um dos serviços disponíveis a partir de uma
autenticação com usuário e senha.
Usando como base essa metodologia e a teoria apresentada no Capítulo 2, selecionamos
os materiais que serão utilizados para a construção da arquitetura. Esses elementos
tecnológicos são: Arquitetura Java EE; Web Services; Segurança e API(s) padrão para redes
de telefonia.
17 OPEX: Acrônimo para Operational Expenditure, termo que se refere às despesas utilizadas para manter a operação, administração e manutenção de um negócio.
64
3.2. MODELAGEM DO SISTEMA
Tomando como base os materiais e métodos apresentados na seção anterior, e levando
em consideração as arquiteturas usadas por alguns provedores de serviços de valor agregado
(VAS), o sistema de capitalização SMS foi dividido em plataformas. Uma abordagem
bastante comum neste segmento é oferecer uma plataforma exclusiva para serviços, onde
diversas aplicações possam fazer uso dos serviços disponíveis. Desta forma, se ganha muito
com a reutilização dos serviços, permitindo que as aplicações se concentrem nas camadas de
interface e lógica de negócios.
Nesta etapa do trabalho, o sistema de comercialização de títulos de capitalização através
do SMS passará a ser chamado por e-CAP. Esse apelido, digamos assim, facilitará o
entendimento do sistema quando nos referirmos a seu nível de aplicação. Além disso, e-CAP
já fica como sugestão para uma marca registrada, no caso da possível viabilidade deste
trabalho como um todo. Isso seria perfeito.
Nesta seção é apresentada a modelagem do sistema usando a notação UML (Unified
Modelling Language). A ferramenta utilizada para o projeto da modelagem foi a StarUML e o
template adotado foi o padrão Rational, que representa uma estrutura arquitetural estática do
sistema, envolvendo todos os elementos importantes com relação ao domínio do problema.
Esse modelo compreende quatro perspectivas que são comentadas a seguir.
3.2.1. Perspectiva de Casos de Uso
Nesta perspectiva da modelagem, os casos de uso relacionam os requisitos funcionais
do sistema de capitalização. Primeiramente, são relacionados os casos de uso da plataforma de
serviços e, logo a seguir, são relacionados os casos de uso da aplicação e-CAP.
3.2.1.1. Casos de Uso da Plataforma de Serviços
• Receber MT-SMS (Mobile Terminated SMS) — é o caso de uso responsável por
receber as mensagens de texto que foram enviadas pelos consumidores através das
operadoras de telefonia.
• Recarga — é o caso de uso responsável por efetuar créditos nas contas de telefonia
móvel dos consumidores.
65
• Cobrança — é o caso de uso responsável por efetuar débitos nas contas de telefonia
móvel dos consumidores.
• Enviar MO-SMS (Mobile Originated SMS) — é o caso de uso responsável por enviar
mensagens de texto das aplicações para as operadoras de telefonia entregá-las aos seus
destinatários.
• Parsing — é o caso de uso responsável por extrair e interpretar o conteúdo XML
encapsulado nos Web Services.
• Routing — é o caso de uso responsável por interpretar o conteúdo das mensagens de
texto recebidas pela plataforma de serviços a fim de direcioná-las para a aplicação
correspondente.
• Database — é o caso de uso responsável por fornecer serviços de persistência em
bancos de dados.
3.2.1.2. Casos de Uso da Aplicação e-CAP
• Gestão de Produtos — é o caso de uso responsável por criar produtos baseados nas
diversas modalidades e formas de pagamento dispostas pelo mercado de capitalização.
Além disso, deve oferecer um mecanismo para monitorar o período de vigência do título
de capitalização e efetuar o crédito de resgate do título diretamente na conta de telefonia
móvel do consumidor.
• Gestão de Vendas — é o caso de uso responsável pelas transações de venda. As
operações incluem validar as mensagens de texto referentes aos pedidos de compra,
efetuar o débito dos pagamentos diretamente na conta de telefonia móvel e registrar a
venda do título de capitalização para o consumidor.
• Gestão de Sorteios — é o caso de uso que deve oferecer um mecanismo para a
realização dos sorteios, que são obrigatórios para os títulos de capitalização. Os
produtos de capitalização possuem uma característica única onde resgate e sorteios
devem coexistir.
66
• Gestão Financeira — é o caso de uso responsável pela gestão das finanças e da
contabilidade no que se refere à comercialização e ao faturamento de produtos de
capitalização.
• CRM via SMS — é o caso de uso responsável por disponibilizar canais de atendimento
ao consumidor para o envio de sugestões, reclamações e o esclarecimento de dúvidas.
• Gestão de Marketing — é o caso de uso responsável por criar mecanismos de
marketing de novos produtos de capitalização.
• Gestão de Promoções — é o caso de uso responsável por criar mecanismos de
disseminação e popularização dos produtos de capitalização. A idéia é enviar aos
consumidores mensagens com conteúdo promocional extra através da integração com
serviços oferecidos por outras plataformas, por exemplo, mensagem referente à
premiação em sorteios, mensagens contendo um hyperlink para download de conteúdo
multimídia, cupons, códigos QR (Quick Response), códigos PIN (Personal
Identification Number), etc.
• Gestão Estatística — é o caso de uso responsável pela emissão de relatórios de
desempenho, levantando informações regionais precisas através dos números dos
dispositivos e telefones móveis dos consumidores. Informações preciosas para que as
empresas de capitalização prospectem seus produtos para atender as diversas condições
socioeconômicas do país.
A Figura 13 é o diagrama de casos de uso do sistema que mostra as relações entre os
atores e os casos de uso. Além disso, o diagrama também mostra as relações entre os casos de
uso da aplicação e-CAP e os da plataforma de serviços.
67
PLATAFORMA DE SERVIÇOS
Enviar MO-SMS
Entregar MT-SMS
Recarga
Cobrança
Parsing
Routing
Operadora de TelefoniaConsumidor
Database
<<Serviços>>
1..* 1..*
APLICAÇÃO e-CAP
Gestão de Vendas
Gestão de Promoções
Empresa de Capitalização
Gestão de Produtos
Gestão de Sorteios
Gestão Financeira
CRM via SMS
Gestão de Marketing
Gestão Estatística
Figura 13 ‒ Diagrama de Casos de Uso
Fonte: Elaborado pelo autor
68
3.2.2. Perspectiva Lógica
Para detalhar a complexidade dos requisitos funcionais elencados no diagrama de casos
de uso, o sistema foi dividido em subsistemas, de maneira que mostre uma perspectiva lógica
de alto nível de seu contexto. Essa técnica visa minimizar o acoplamento entre os
subsistemas, o que reduz as dependências entre os componentes de software.
A Figura 14 é um diagrama lógico de alto nível que mostra a relação de dependência
entre os subsistemas, com o propósito de permitir o desenvolvimento independente e
incremental de cada um. Isso implica em uma modelagem particular para cada subsistema.
APLICAÇÃO e-CAP
Gestão Financeira
Gestão de VendasCRM via SMS
Gestão de Produtos
Gestão Estatística
Gestão de Marketing
Gestão de Sorteios
Gestão de Promoções
PLATAFORMA DE SERVIÇOS
Serviços de DB Serviços de Telecom
Figura 14 ‒ Diagrama Lógico de Alto Nível Fonte: Elaborado pelo autor
3.2.3. Perspectiva de Componentes
A Figura 15 é o diagrama de componentes do sistema de capitalização SMS. O
diagrama mostra a distribuição dos componentes de software em cinco pacotes de acordo com
o seu tipo. As relações de dependência, mais uma vez, mostram as seqüências para o
desenvolvimento e empacotamento dos subsistemas, que vão culminar em uma infra-estrutura
de serviços e aplicações.
69
SERVIÇOS
COMPONENTES EJB
e-CAP DB Manager.JAR
APLICAÇÕES
COMPONENTES WEB
RECURSOS
OneAPI.JAR
e-CAP.EAR
Principal.EARCRM via SMS.WARGestão de Marketing.WARGestão de Promoções.WARGestão Estatística.WAR
residents
Principal.EAR
Gestão de Produtos.WARGestão de Vendas.WARGestão de Sorteios.WARGestão Financeira.WAR
residents
CRM via SMS.WAR
Gestão de Marketing.WAR
Gestão de Promoções.WAR
Gestão Estatística.WAR
Gestão de Produtos.WAR
Gestão de Vendas.WAR
Gestão de Sorteios.WAR
Gestão Financeira.WAR
Java EE Server Runtime
Framework Web
Serviços de Telecom.EAR
End Points.JARFoundation.JARPayment.JARSMS.JAR
residents
SMS.JAR
Foundation.JAR
End Points.JAR
Payment.JAR
Serviços de DB.EAR
e-CAP DB Manager.JARresidents
OneAPI Server
Web Browser
Java Runtime Environment
Framework de Persistência
Figura 15 ‒ Diagrama de Componentes Fonte: Elaborado pelo autor
70
3.2.4. Perspectiva de Implantação
A Figura 16 é o diagrama de implantação que mostra os dispositivos de hardware onde
serão instaladas suas respectivas aplicações de software. A plataforma de serviços e o sistema
de capitalização SMS (e-CAP) serão oferecidos por um provedor de serviços de valor
agregado (VAS), que deve estar conectado à rede de telefonia por meio de um IMS
Application Server. A empresa de capitalização poderá ter acesso ao sistema e-CAP e
gerenciar suas vendas através de um web browser.
PROVEDOR DE VAS
APLICAÇÕES<<Servidor>>
e-CAP.EARcomponents
PLATAFORMA DE SERVIÇOS<<Cliente/Servidor>>
Serviços de DB.EARServiços de Telecom.EAR
components
IMS APLICATION SERVER<<Servidor>>
OneAPI Servercomponents
<<XML / HTTP(s)>>
1..*
1
EMPRESA DE CAPITALIZAÇÃO<<Cliente>>
Web Browsercomponents
<<XML / HTTP(s)>>
1..*
<<HTTP(s)>>
0..*
Figura 16 ‒ Diagrama de Implantação
Fonte: Elaborado pelo autor
3.3. ARQUITETURA PROPOSTA
Nesta seção, será apresentado o resultado da etapa de modelagem do sistema e-CAP. Na
próxima página, temos a Figura 17 que é o desenho da arquitetura proposta. A arquitetura foi
construída em quatro camadas de maneira que fosse possível reproduzir claramente a proposta
do sistema modelado na seção anterior.
71
Figura 17 ‒ Arquitetura para o Sistema de Capitalização SMS (e-CAP) Fonte: Elaborado pelo autor
Camada Cliente
Camada de Interface Web e lógica de negócios
Camada de Serviços
Camada de Sistemas de Informação Corporativos (EIS)
e-CAP
OneAPI
Server
Web
Browser
Serviços de DB
e-CAP DB Manager
Entity
Beans
Session
Beans
Entity
DAO(s)
Cliente
OneAPI
XML
XML
Serviços de Telecom
Foundation
Session
Beans
Payment
MO-SMS
End Points
Web
Services
MT-SMS
Parsing
Routing
MO-SMS
Payment
XML
72
A seguir, são comentadas as características de cada camada da arquitetura proposta para
o sistema e-CAP.
A Camada Cliente é a camada que oferece às empresas de capitalização o acesso ao
sistema e-CAP através de um web browser. Corresponde também a uma aplicação de
Telecom cliente (i.e., Cliente OneAPI) que poderá usar o Web Service MT-SMS para entregar
mensagens de texto diretamente à plataforma de serviços.
A Camada de Interface Web e lógica de negócios é uma camada dupla, ela
corresponde à interface sistêmica mais a lógica de negócio das aplicações. Os componentes
dessa camada oferecem a interface web das aplicações e acesso a todas as suas
funcionalidades através de um web browser. A aplicação e-CAP está contida nessa camada e
faz uso de componentes na camada de serviços.
A Camada de Serviços corresponde aos serviços oferecidos através de componentes
EJBs da plataforma de serviços. Temos aqui uma situação de distribuição de serviços e
recursos pela rede, tornando possível que os serviços possam se relacionar entre si ou possam
ser utilizados por diversas aplicações clientes, local ou remotamente. O e-CAP DB Manager é
o mecanismo de persistência do banco de dados da aplicação e-CAP. O acesso a esse serviço
de DB é feito através de Session Beans (componentes EJBs).
Com os Serviços de Telecom é possível enviar mensagens de texto e cobrar tarifas aos
consumidores (EJBs MO-SMS e Payment, respectivamente). O componente End Points é um
utilitário responsável pelas configurações da conexão entre cliente/servidor envolvida nas
requisições HTTP. O componente Foundation faz a interface com o servidor OneAPI Server.
Além disso, o componente Foundation realiza o parsing do conteúdo XML encapsulado nos
Web Services MT-SMS e, logo em seguida, interpreta o conteúdo das mensagens de texto
recebidas pela plataforma de serviços a fim de direcioná-las (Routing) para a aplicação
correspondente.
Camada de Sistemas de Informação Corporativos (EIS) corresponde ao acesso a
outros sistemas corporativos (e.g., ERP, CRM, SCM, BI, sistemas legados), bancos de dados
e outros elementos da infra-estrutura de TI. No caso deste projeto, estão contidos nessa
camada o servidor de banco de dados da aplicação e-CAP e o servidor da operadora de
telefonia (OneAPI Server).
73
O resultado da proposta nos remete a propor também um modelo genérico de
arquitetura, que é mostrado na Figura 18. Por exemplo, esse modelo genérico de arquitetura
permite tanto desenvolver uma aplicação stand alone, criando componentes web e uma
camada de persistência exclusiva para a aplicação, quanto permite também, desenvolver uma
aplicação sobre serviços, onde o acesso ao banco de dados é um serviço de persistência
construído com componentes EJB e compartilhado com outras aplicações.
Figura 18 ‒ Modelo Genérico de Arquitetura Fonte: Elaborado pelo autor
API DE TELECOM
FRAMEWORK DE PERSISTÊNCIA
FRAMEWORK WEB
JAVA EE SERVER RUNTIME
JAVA RUNTIME ENVIRONMENT
COMPONENTES EJB
COMPONENTES WEB
APLICAÇÕES
SERVIÇOS
74
3.4. DISCUSSÃO
É evidente que os serviços de valor agregado (VAS) fazem parte de um mercado que
está em constante mudança, em função das preferências dos consumidores, do surgimento de
novos dispositivos smart phones e do aumento da demanda. Tudo isso força os provedores a
atualizarem, constante e rapidamente, o seu portfólio de conteúdo e aplicativos. Por outro
lado, as operadoras de telefonia enfrentam muitos desafios para reduzir custos e obterem o
retorno sobre os investimentos, ditando constantes mudanças de paradigmas de receita que
aumentam os riscos para os negócios dos provedores.
Quando um concorrente lança no mercado um novo serviço, os provedores VAS, muitas
vezes, precisam oferecer um serviço similar, ou ainda melhor, dentro de dias ou semanas, para
evitar perder seus clientes. Uma alternativa seria atrair clientes corporativos, oferecendo
serviços customizados que geram uma margem de lucro maior, permitindo novos
investimentos com riscos menores. Diante disso, é necessário criar ferramentas e plataformas
padronizadas para que os provedores possam implementar novas aplicações rapidamente.
Nesta seção, colocamos em discussão algumas formas alternativas de se abordar a proposta
deste trabalho de pesquisa.
A empresa Jinny Software Ltd. tem um produto bastante interessante. Essa empresa
criou um ambiente para a criação de novos serviços de valor agregado (VAS) cuja interface é
baseada em componentes gráficos. Com essa ferramenta, os provedores podem criar novos
serviços de forma intuitiva, sem a necessidade de desenvolvedores de software, o que acelera
o time-to-market de serviços personalizados, além de facilitar o controle sobre esses serviços.
Segundo o artigo de Vuono (2013), os resultados de algumas iniciativas européias e
asiáticas demonstram que é possível, para as operadoras de telefonia móvel, incrementar suas
receitas lançando novos serviços sobre as redes legadas 2G e 2.5G, sem que seja necessário
um upgrade para redes 3G em toda a sua extensão e disponibilidade.
Com essa descoberta, o contexto de convergência tecnológica tornou a plataforma de
entrega de serviços (SDP ‒ Software Delivery Platform) não somente um item desejável para
as companhias de Telecom, mas sim uma ferramenta essencial e estratégica a fim de oferecer
serviços multimídia aos consumidores, independentemente de sua rede de acesso. “[...] Em
outras palavras, em um mundo convergente, a infra-estrutura IMS é necessária, mas não é
75
suficiente; é necessário complementá-la com uma plataforma robusta que permita a oferta de
serviços – e conteúdo – de terceiros.” (VUONO, 2013)
No entanto, a SDP ainda não é um elemento normalizado. Fato que, evidentemente,
gerou conflitos conceituais a respeito de SDP, ao ponto de algumas operadoras afirmarem que
possuem uma SDP quando, na realidade, apenas implementaram um Gateway OSA/Parlay em
sua rede.
Na realidade, uma SDP não é um produto, propriamente dito. Uma SDP é um conjunto
de soluções que visa reunir todos os serviços de Telecom em uma plataforma. Consiste de
uma plataforma que faz a interface dos provedores de serviços de valor agregado (VAS) com
o ambiente de telecomunicações, de forma que, os provedores possam, simplesmente, adquirir
‒ não construir ‒ e reutilizar ‒ não reconstruir ‒ serviços.
Os padrões da arquitetura IMS foram rigidamente definidos e se tornaram prioridade
para as operadoras de telefonia fixa pela possibilidade de redução de custos operacionais e
habilitação de serviços de múltiplo acesso. Já a arquitetura de um SDP, com a sua ausência de
padrões rígidos, vem se tornando prioridade para as operadoras de telefonia móvel pela
facilidade na inclusão de novos serviços a um baixo custo, possibilitando explorar novos
nichos de mercado com um baixo risco associado.
Além disso, algumas empresas emergentes se reuniram e desenvolveram suas próprias
SDP(s) em parceria. Essas iniciativas têm o propósito de reunir esforços a fim de criar uma
SDP para uso compartilhado e com uma variedade de serviços.
Esse sucesso revela que, futuramente, uma SDP entre em um processo de normalização
eminente. Enquanto a normalização não acontece, uma abordagem total do conceito de SDP
representaria um alto risco para esse trabalho, quando levamos em conta a possibilidade real
de mudanças. Entretanto, uma abordagem parcial do conceito de SDP pode ser interessante,
de maneira a complementar a arquitetura de software que foi proposta na seção anterior.
76
4. CONCLUSÕES E TRABALHOS FUTUROS
studar o Short Message Service foi o maior desafio desse trabalho de pesquisa,
porque é uma tecnologia bastante complexa, possui uma listagem de
especificações extensa e de difícil compreensão. Ao mesmo tempo em que fomos
surpreendidos com essa fase da pesquisa, que despendeu bastante tempo, foi bastante
interessante compreender o funcionamento do sistema em baixo nível. Ficamos diante de
diferentes contextos e cenários, estes que surgem de novas tecnologias que acompanham as
novas gerações de telefonia celular. No entanto, abordamos o SMS de uma maneira funcional,
servindo como fundamento para a compreensão em qualquer contexto, e relacionamos os
tópicos essenciais, que permitiram uma visão geral do SMS como um todo.
Normalmente, quando enviamos uma mensagem de texto SMS, o destinatário a recebe
rapidamente. Isso causa ao usuário a sensação de que a entrega de uma mensagem ocorre em
tempo real. No entanto, a entrega da mensagem em tempo real não pode ser garantida, porque
não existe uma associação de conexão entre o remetente e o destinatário. Na realidade, existe
um intermediário que é um centro de serviços (SMSC), que vai armazenar a mensagem
enviada até que seja possível entregá-la ao destinatário. Essa é uma conclusão importante, que
devemos levar em consideração no desenvolvimento de novos projetos que usem o SMS,
portanto, o SMS não é um serviço de tempo real.
Refletindo sobre a construção da arquitetura, a palavra chave talvez tenha sido
interoperabilidade. Por isso, o conceito de redes da próxima geração (NGN) se mostrou
fundamental para direcionar o rumo dos trabalhos, afinal, NGN pretende garantir redes que
ofereçam a interoperabilidade dos serviços de Telecom num alcance global. E sobre esse
paradigma, usamos como base a arquitetura IMS, que oferece uma infra-estrutura completa
para serviços de Telecom. IMS teve grande aceitação pela indústria por ser uma arquitetura
normalizada, nos mostrando que apenas soluções padronizadas podem alimentar um mercado
com um grande número de provedores de serviços e operadoras interligados.
Ao mesmo tempo em que foi bastante interessante aprender sobre sistemas de Telecom
em baixo nível, às vezes, ficamos diante de situações onde pareceu estarmos tentando
reinventar a roda, por isso, sempre é importante mencionar as lições aprendidas. Lembre-se de
pesquisar pela disponibilidade de API(s) no mercado, fazendo um comparativo entre as do
tipo open source ou proprietárias. Uma API é um recurso importantíssimo no sentido de
E
77
reduzir os esforços de pesquisa e desenvolvimento, afinal, quem especificou uma API já fez
todo o trabalho de baixo nível.
Algumas entidades e organizações de Telecom, além de elaborarem as especificações
das API(s), fornecem também os descritores dos Web Services (e.g., arquivos WSDL18,
XSD19). Com os descritores, é possível gerar os stubs de uma aplicação, automaticamente,
através de um kit de desenvolvimento de software (SDK). Além disso, muitas dessas
organizações disponibilizam implementações de referência e emuladores open source, que
podem reduzir bastante o esforço de desenvolvimento, usando de ferramentas já prontas, ou
que permitem criar aplicações customizadas, usando o código fonte disponível.
A arquitetura que foi proposta neste trabalho foi construída com base nos materiais e
métodos apresentados, e levando em consideração as arquiteturas usadas por alguns
provedores de VAS. Desta maneira, a arquitetura do sistema de capitalização SMS foi
dividida em camadas, onde uma delas corresponde à plataforma que é exclusiva para serviços.
Além de ser considerada uma boa prática, essa abordagem nos permite propor uma série de
trabalhos futuros, com o propósito de criar uma infra-estrutura de serviços de valor agregado.
Conforme a necessidade é possível implantar vários serviços na plataforma, tais como, MMS,
um servidor web como serviço, gerenciamento de assinantes, gerenciamento de conteúdo,
gerenciamento de dispositivos, gerenciamento de perfil dos assinantes, resposta interativa por
voz (IVR), conversor de texto para fala (TTS), reconhecimento de voz automático (ASR), etc.
Com relação à camada de interface web e lógica de negócios, é possível implantar sobre
ela novas aplicações, que poderão fazer uso dos serviços que estão disponíveis na plataforma
de serviços, e assim, construir uma plataforma de aplicações. O conjunto que reúne a
plataforma de aplicações e a plataforma de serviços formará o portfólio de um provedor VAS.
O resultado da pesquisa nos colocou diante de um cenário com vistas a construir um
sistema dedicado, com a parte web, banco de dados, SMS, tudo incorporado numa mesma
aplicação. Essa abordagem, certamente, não é adequada ao consideramos a possibilidade de
algum provedor VAS se interessar em colocar o sistema e-CAP no mercado. Por exemplo, os
provedores já possuem suas plataformas de SMS rodando há anos no mercado e, é bem
provável, que eles prefiram usá-las para implantar novas aplicações. A abordagem utilizada
18 WSDL: Web Services Description Language. 19 XSD: XML Schema Definition.
78
nesse trabalho, porém, permite que a aplicação e-CAP seja implementada de maneira que ela
possa trabalhar em plataformas de provedores diferentes. A idéia foi modelar uma solução
sujeita a encontrar diferentes cenários, onde seja possível a substituição de componentes de
software (serviços e aplicações) conforme for necessário. Por exemplo, é possível substituir o
serviço de SMS por outro implementado por outro fornecedor.
Como mais um trabalho futuro, deixamos como sugestão incluir mais um componente
web na aplicação e-CAP, a fim de complementá-la com um portal onde os consumidores
possam gerenciar os seus títulos de capitalização. A idéia é oferecer um canal alternativo para
os consumidores que preferem usar a internet no seu dia a dia, de maneira que possam ter
acesso a atendimento (SAC), resultados de sorteios, informações sobre o resgate, condições
contratuais, perguntas freqüentes e todas as informações pertinentes ao produto que adquiriu.
Ao final deste trabalho, chegamos a conclusões importantes quanto a potencial
viabilidade do sistema de capitalização através de mensagens de texto, isso quando nos
referimos às entidades que estão envolvidas no processo de comercialização. Começamos
com uma questão — O título de capitalização é, realmente, um bom investimento para o
consumidor? — essa é uma boa pergunta tema de bastante discussão. Enquanto alguns
economistas criticam dizendo não se passar de um mero produto de loteria disfarçado, outros
classificam o título de capitalização como sendo uma poupança forçada. De qualquer forma,
temos o título de capitalização como um produto que caiu no gosto dos brasileiros e as vendas
só nos confirmam isso. O mercado de capitalização no Brasil movimentou mais de 16 bilhões
de Reais em 2012 e apresenta um crescimento médio de 15% ao ano, fato que pode motivar
aos provedores de VAS um fluxo de receita inovador. Além disso, o título de capitalização
possui uma característica única (i.e., Capitalização = Sorteios + Resgate), uma combinação
que permite viabilizar soluções para as diferentes demandas de mercado. Com o sistema e-
CAP, as empresas de capitalização ganham um novo canal de vendas e com o título de
capitalização virtual, eliminamos o custo do produto físico feito de papel, reduzindo também,
os custos com administração.
Principalmente, esperaremos que esse trabalho contribua no sentido de colocar no
mercado um novo canal para comercialização de produtos de capitalização. Fazendo uma
correlação com os objetivos específicos que foram apresentados no capítulo de introdução, o
próximo passo seria fazer um estudo detalhado de viabilidade comercial e, em seguida,
submeter o conceito de produtos de capitalização virtuais para apreciação da SUSEP, que é o
79
órgão governamental que regulamenta o setor. Além disso, esperaremos que esse trabalho seja
utilizado como literatura para pesquisas em outras áreas do conhecimento, bem como, que
incentive a pesquisa aplicada a tecnologias de comunicação móvel, onde percebemos que
existem poucos trabalhos científicos relacionados ao assunto.
Esse trabalho de pesquisa propôs uma arquitetura de software voltada para sistemas de
comercialização de títulos de capitalização através do SMS. Essa proposta faz parte do
segmento de serviços de valor agregado (VAS), que mostrou ser um mercado fascinante e rico
em oportunidades, podemos ver isso nos trabalhos futuros relacionados neste capítulo.
Entretanto, VAS é um segmento motivado por modelos de negócio bastante dinâmicos,
geralmente ditados pelas operadoras de telefonia, que aumentam os riscos para os negócios
dos provedores de serviços. Essa foi uma questão evidenciada nas seções que falaram sobre
metodologia e discussão, de maneira que fique clara a sua relevância em um cenário que deve
atender às necessidades (individuais) dos consumidores que desejam uma variedade de
serviços. Finalmente, esperaremos que esse trabalho contribua para oferecer serviços de valor
agregado bem sucedidos e que incentive a criação de novos produtos.
80
REFERÊNCIAS BIBLIOGRÁFICAS
ANKER, Peter. 2005. Telecom ABC: A telecommunications and Internet dictionary.
Disponível em: <http://www.telecomabc.com/>. Acesso em 6 de abril de 2012.
CAVALLINI, Ricardo; XAVIER, Léo; SOCHACZEWSKI, Alon. Mobilize. 1ª edição. São Paulo: Editora dos Autores, 2010.
CHEN, Rebecca et al. 2006. Introduction to IP Multimedia Subsystem (IMS). Disponível em: <http://www.ibm.com/developerworks/webservices/library/ws-soa-ipmultisub1/>. Acesso em 25 de maio de 2012.
DRYBURGH, Lee; HEWETT, Jeff. Signalling System No.7 (SS7/C7): Protocol, Architecture,
and Services. USA: Cisco Press, 2005. Disponível em: <http://www.ss7-training.net/>. Acesso em 26 de novembro de 2012.
ERICSSON. 2010. MMTel – a standard for multimedia services over IMS. Disponível em: <http://www.ericsson.com/res/docs/whitepapers/mmtel.pdf>. Acesso em 18 de outubro de 2012.
EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE. European Radio
Message System (ERMES) Part 3: Network aspects. France: ETSI, 1992.
______. GSM 01.02 v.6.0.1 - General description of a GSM Public Land Mobile Network
(PLMN). France: ETSI, 1998.
______. GSM 01.04 v.8.0.0 - Abbreviations and acronyms. France: ETSI, 2000.
______. GSM 03.39 v.7.0.0 - Interface protocols for the connection of SMSCs to SMEs. France: ETSI, 2000.
FEDERAÇÃO NACIONAL DE CAPITALIZAÇÃO. Manual de Melhores Práticas das
Empresas de Capitalização. Rio de Janeiro: Fenacap, 2008.
GSM ASSOCIATION. 2011. OneAPI Javadoc for Java Libraries. Disponível em: <http://www.gsma.com/oneapi/software-downloads/>. Acesso em 14 de fevereiro de 2013.
______. 2011. Java Web Application for GSMA OneAPI. Disponível em: <https://github.com/OneAPI/GSMA-OneAPI>. Acesso em 14 de fevereiro de 2013.
INTERNATIONAL TELECOMMUNICATION UNION. ITU-T Recommendation Y. 2001 -
General overview of NGN. ITU-T, 2004
JANDL, Peter Jr.. Java 5 – Guia de Consulta Rápida. São Paulo: Novatec, 2006.
81
______. Java: Guia do Programador. São Paulo: Novatec, 2007.
JENDROCK, Eric et al. 2013. The Java EE 6 Tutorial. Disponível em: <http://docs.oracle.com/javaee/6/tutorial/doc/>. Acesso em 21 de março de 2013.
JOSUTTIS, Nicolai M. SOA na Prática: A Arte da Modelagem em Sistemas Distribuídos. Rio de Janeiro: Alta Books, 2008.
LE BODIC, Gwenael. Mobile Messaging Technologies and Services: SMS, EMS, and MMS.
England: John Wiley & Sons Ltd., 2003.
LEDESMA, Bruno de Medeiros. 2007. Um framework para Web Services através do Short
Message Service. Disponível em: <http://projetos.inf.ufsc.br/arquivos_projetos/projeto_697/artigo.pdf>. Acesso em 13 de março de 2012.
LEITÃO, Filipe A.; FREIRE, Sérgio S.; LIMA, Solange R. 2009. Evolução e coexistência do
serviço de mensagens SMS em IMS. Atas da CRC 2009 - 9ª Conferência sobre Redes de Computadores, IST - Taguspark, Oeiras, 15-16 Outubro 2009.
LOZINSKI, Zygmunt. 2003. Parlay/OSA – a new way to create wireless services. Disponível em: <ftp://jano.unicauca.edu.co/proyectos/wapcolombia/Parlay_OSA/resources/2003_06_01_Parlay_for_IEC_Wireless.pdf>. Acesso em 14 de junho de 2012.
MAGRIN, Rafael Von Hoonholtz. 2010. Proposta de uma Arquitetura para Sistemas de
Pagamento Móvel. Trabalho de Graduação em Ciência da Computação - Instituto de Informática, Universidade Federal do Rio Grande do Sul, 2010.
NOKIA CORPORATION. Nokia SMS Center 8.0: CIMD Interface Specification- issue 4. Nokia, 2005.
OPEN MOBILE ALLIANCE. 2013. OMA Architecture Working Group: Future plans for
2013 and beyond. Disponível em: <http://openmobilealliance.org/about-oma/work-program/architecture/>. Acesso em 13 de fevereiro de 2013.
______. 2012. OneAPI Profile of ParlayREST Web Services. Disponível em: <http://technical.openmobilealliance.org/API/APIsInventory.aspx>. Acesso em 13 de fevereiro de 2013.
PULIER, Eric; TAYLOR, Hugh. Compreendendo SOA Corporativa. Rio de Janeiro: Editora Ciência Moderna, 2008.
RIBEIRO, Marcello Peixoto. Redes de telecomunicações e teleinformática: um exercício
conceitual com ênfase em modelagem. Rio de Janeiro: Interciência, 2012.
82
ROSS, Frederick L.; STASHLUK, Edward J. . Patent US.6.263.212 - Short Message Service
Center. USA: Alcatel, 2001.
SÁ, André Luís Martins de. 2003. Proposta para implantação de Interconexão entre Redes de
SMS (Short Message Service). Monografia de Bacharel em Ciência da Computação - Instituto de Ciências Exatas e Tecnológicas, Centro Universitário do Triângulo, Uberlândia, 2003.
SILVINO JR, João Bosco. 2002. SMPP: Protocolos e Aplicações. Disponível em: <http://www.inforede.net/Technical/Layer_1/Wireless_Mobile/SMPP_specs_(POR).pdf>. Acesso em 13 de março de 2012.
SOMMERVILLE, Ian. Software Engineering. 9th edition. USA: Pearson Education, Inc., 2011.
SUPERINTENDÊNCIA DE SEGUROS PRIVADOS. 2013. Informações Gráficas de
Mercado. Disponível em: <http://www2.susep.gov.br/menuestatistica/monitormercado/index_chart.asp> Acesso em 24 de fevereiro de 2013.
SVERZUT, José Umberto. Redes GSM, GPRS, EDGE e UMTS: Evolução a caminho da
quarta geração (4G). 3ª edição. São Paulo: Érica, 2011.
THIRD GENERATION PARTNERSHIP PROJECT. 3GPP TR 21.905 v.11.0.1 - Vocabulary
for 3GPP Specifications. 3GPP, 2012.
______. 3GPP TR 22.940 v.10.0.0 - IP Multimedia Subsystem (IMS) messaging. 3GPP, 2011.
______. 3GPP TS 23.002 v.11.2.0 - Network Architecture. 3GPP, 2012.
______. 3GPP TR 23.039 v.5.0.0 - Interface protocols for the connection of SMSCs to SMEs. 3GPP, 2006.
______. 3GPP TS 23.040 v.11.1.0 - Technical realization of the Short Message Service
(SMS). 3GPP, 2012.
______. 3GPP TS 23.204 v.11.2.0 - Support of Short Message Service (SMS) over generic
3GPP Internet Protocol (IP) access. 3GPP, 2012.
______. 3GPP TS 29.002 v.11.4.0 - Mobile Application Part (MAP) specification. 3GPP, 2012.
URBANO, António Carlos Alves. 2006. Modelos peer to peer aplicados a sistemas de
comunicação multimídia moveis. Dissertação de Mestrado em Sistemas de Informação - Escola de Engenharia, Universidade do Minho, Portugal, 2006.
VODAFONE D2 GMBH. SMSC External Machine Interface Description v.4.3d. Germany, 2011.
83
VUONO, Evandro. 2013. Service Delivery Platform: A sua operadora ainda vai ter um... e
logo. Disponível em: <http://www.teleco.com.br/hp/hp_artigos006.asp>. Acesso em 15 de março de 2013.
![Message Of Founders Pt[1]](https://img.document.onl/doc/110x75/55a3f5ce1a28abef718b472c/message-of-founders-pt1.jpg)
