Migração para Web de
um sistema integrado de
provisão e cadastro de
recursos
João Pedro Codeço Proença
Mestrado Integrado em Engenharia de Redes e Sistemas Informáticos
Departamento de Ciência de Computadores 2013
Orientador
André Figueiredo Medas, DSCB/OMP/PW, Portugal Telecom SI Coorientador
Manuel Eduardo Correia, Professor Auxiliar, Faculdade de Ciências da Universidade do Porto
Todas as correções determinadas pelo júri, e só essas, foram efetuadas. O Presidente do Júri,
Porto,
palavras-chave Migração de uma aplicação para Java usando Seam; Software
de gestão de rede de telecomunicações; Vantagens de usabilidade na
Web.
resumo Este relatório é referente ao projeto de estágio realizado na PT SI (Portugal Telecom Sistemas de Informação). O objetivo do projeto consistiu em migrar uma aplicação responsável pela gestão da rede de cobre, uma aplicação já com alguns anos, que para além de ter uma
interface muito confusa, exige que esta seja instalada em todas as
máquinas dos colaboradores que a pretendam usar. Foi substituída a arquitetura cliente-servidor Windows, por uma arquitetura Web em Java e usou-se a framework Seam 2.2.2, garantindo que a usabilidade fosse melhorada.
keywords Migrating an application to Java using Seam; Management
software telecommunications network; Advantages of usability on the Web.
abstract This report is about the project accomplished in PT SI (Portugal Telecom – Information Systems). The goal of the project was to migrate an application, responsible for managing the copper network, an application that has already a few years, which has a confusing interface, that requires to be installed in all employees machines that want to use it. Windows client-server architecture was replaced by a Web architecture in Java using Seam 2.2.2 framework, ensuring that usability had been improved.
Índice
LISTA DE FIGURAS………..….…….……..………..………...vii LISTA DE ABREVIATURAS……….………..….…….……..………...…………...ix 1. INTRODUÇÃO ... 1 2. APLICAÇÃO EXISTENTE ... 3 2.1 APLICAÇÃO... 3 2.2 ÁREAS DE INFLUÊNCIA ... 4 2.3 REDE DE ACESSO ... 6 2.4 EQUIPAMENTO DE COMUTAÇÃO ... 6 2.5 ATRIBUIÇÃO DE RECURSOS ... 7 2.6 MORADAS ... 8 2.7 INTERFACES ... 92.8 ARQUITETURA DE REDE INTERNA ... 11
2.9 ARQUITETURA DE REDE PARA APLICAÇÕES EXTERNAS... 14
3. PROGRAMAS E TECNOLOGIAS USADAS ... 16
3.1 ECLIPSE ... 16
3.2 JBOSS SEAM 2.2.2 ... 17
3.2.1 WebLogic 10.3.4... 18
3.2.2 JSF – JavaServer Faces ... 18
3.2.3 EJB – Enterprise JavaBeans ... 19
3.2.4 Richfaces... 20
3.2.5 Arquitetura Richfaces ... 21
3.3 PIE(PROGRESSIVE INTERNET EXPLORER) ... 23
3.4 ALLFUSION GEN E GUARDIEN ... 23
3.5 RUMBA,MAINFRAME EDITION ... 24
3.6 GOOGLE MAPS JAVASCRIPT API V3 ... 24
3.6.1 Geocoding API ... 26 3.6.2 Directions API ... 26 4. IMPLEMENTAÇÃO E RESULTADOS ... 27 4.1 PROJETO NO ECLIPSE ... 28 4.1.1 Entity ... 28 4.1.2 Session ... 29 4.1.3 Utils ... 30
4.1.4 WebContent ... 30
4.2 MÓDULO INTERFACES ... 32
4.3 MÓDULO MORADAS ... 41
4.3.1 Roteiro ... 42
4.3.2 Certificação de moradas ... 58
4.4 MÓDULO EQUIPAMENTO DE COMUTAÇÃO ... 65
4.5 PROBLEMAS E ATRASOS QUE SURGIRAM ... 68
5. CONCLUSÕES ... 70
5.1 O QUE FAZIA DIFERENTE... 70
5.2 TRABALHO FUTURO ... 70
6. REFERÊNCIAS BIBLIOGRÁFICAS ... 72
7. ANEXOS ... 74
7.1 ANEXO AUTENTICAÇÃO ... 74
7.2 ANEXO LISTARGRUPODEREDES ... 75
7.3 ANEXO MAPAGOOGLE ... 76
7.4 ANEXO XMLGEOCODING ... 78
7.5 ANEXO COORDENADASGEOGRAFICAS ... 79
Lista de Figuras
Figura 1 - Ecrã principal da aplicação... 4
Figura 2 - Exemplo de áreas de influência... 5
Figura 3 - Interfaces, criação de mensagem ... 10
Figura 4 - Diagrama de rede interna, pré-existente e implementada ... 11
Figura 5 - Diagrama de rede para aplicações externas ... 14
Figura 6 – Fluxo de processamento de um evento [18] ... 21
Figura 7 – Sequência de processamento do pedido [18] ... 22
Figura 8 - Sequência de processamento da resposta [18] ... 22
Figura 9 - Google Maps vs Bing Maps ... 25
Figura 10 – Lacunas no layout ... 31
Figura 11 – Aplicação, menu pincipal ... 32
Figura 12 – Aplicação, critérios de pesquisa de mensagens ... 32
Figura 13 – Web, critérios de pesquisa de mensagens ... 33
Figura 14 – Aplicação, lista de mensagens ... 34
Figura 15 – Web, lista de mensagens ... 34
Figura 16 – Aplicação, detalhes de uma mensagem ... 35
Figura 17 – Web, detalhes de uma mensagem ... 36
Figura 18 – Web, detalhes de uma mensagem (buffer) ... 36
Figura 19 – Web, criação de mensagem pelo buffer ... 36
Figura 20 – Aplicação, criação de mensagem ... 37
Figura 21 – Web, criação de mensagem ... 38
Figura 22 – Aplicação, janela dos tipos de registo ... 39
Figura 23 – Web, página dos tipos de registo ... 39
Figura 24 – Web, página dos tipos de interface (Regras Atributos) ... 40
Figura 25 – Aplicação, página inicial do módulo moradas ... 41
Figura 26 – Web, página inicial do módulo moradas ... 42
Figura 27 – Web, página inicial do roteiro ... 43
Figura 28 – Aplicação, pesquisa de códigos postais ... 44
Figura 29 – Web, Google Maps na página do roteiro ... 45
Figura 30 – Web, calculo de percursos pelo Google Maps ... 46
Figura 31 – Aplicação, criação do código postal ... 47
Figura 32 – Web, criação do código postal ... 47
Figura 33 – Aplicação, detalhes do código postal ... 48
Figura 35 – Web, tab mapa no código postal ... 50
Figura 36 – Web, associar localidade e arruamento a código postal ... 51
Figura 37 – Web, detalhes da localidade ... 52
Figura 38 – Aplicação, detalhes do arruamento ... 53
Figura 39 – Web, detalhes do arruamento... 54
Figura 40 – Aplicação, seleção de arruamento para listar prédios ... 55
Figura 41 – Aplicação, listagem de prédio de um determinado arruamento ... 56
Figura 42 – Web, marcar cooredenadas de um prédio ... 57
Figura 43 – Web, Unidades de Alojamento de um prédio ... 58
Figura 44 – Aplicação, pesquisa de pedidos de certificação ... 59
Figura 45 – Web, pesquisa de pedidos de certificação ... 60
Figura 46 – Web, certificação de arruamento ... 61
Figura 47 – Web, certificação de arruamento (identificação) ... 62
Figura 48 – Web, certificação de prédio, UAL e código postal ... 63
Figura 49 – Web, certificação concluida ... 64
Figura 50 – Passos da certificação de um UAL c/CP7... 64
Figura 51 – Aplicação e Web, menu inicial dos módulos ... 65
Figura 52 – Aplicação, janela principal do módulo de comutação ... 65
Figura 53 – Web, página principal do módulo de comutação... 66
Lista de Abreviaturas
AB - Action Block
AJAX - Asynchronous Javascript and XML API - Application Programming Interface BO - Business Optimization
BPM - Business Process Management CICS - Customer Information Control System COBOL - COmmon Business Oriented Language GUI - Graphical User Interface
HTTP - Hypertext Transfer Protocol
IDE - Integrated Development Environment IP - Internet Protocol
JSON - JavaScript Object Notation OLTP - Online Transaction Processing PHP - PHP Hypertext Preprocessor PROC - Procedure Step
PT - Portugal Telecom SI - Sistemas de Informação SOA - Service Oriented Architecture SQL - Structured Query Language TCP - Transmission Control Protocol
TUXEDO - Transactions for Unix, Extended for Distributed Operations WEB - World Wide Web
XHTML - eXtensible Hypertext Markup Language XML - eXtensible Markup Language
1. Introdução
Cada vez faz mais sentido que os programadores usem a Web (World Wide Web) para criarem as suas aplicações, pois assim conseguem que esta esteja acessível a todos aqueles que a queiram usar, à distância de um clique. No entanto, nem sempre isto é possível quando estamos a falar de aplicações muito complexas. A aplicação em causa é responsável pela gestão e manutenção da rede, equipamentos de comutação e atribuição de recursos. Centraliza todo o sistema de informação de suporte à rede numa única aplicação, tem centenas de janelas espalhadas por vários módulos que estão muito confusas para o utilizador e por isso, surgiu a necessidade de se pensar numa solução Web que, entre outras coisas, simplificasse a interação da aplicação com o utilizador. Ao fazer esta migração os utilizadores não vão necessitar mais de ter a aplicação instalada nos seus computadores e de se preocuparem com
updates. Os updates na Web são feitos automaticamente e por isso, o utilizador que
acede ao site tem sempre acesso à última versão disponibilizada. Com a aplicação na Web, os utilizadores poderão usá-la em qualquer sítio que estejam com acesso à internet, sem que para isso tenham que ter um computador com Windows instalado.
A migração da aplicação foi feita apenas do lado do cliente, apesar de terem sido feitas algumas alterações do lado do servidor no decorrer do trabalho, alterações essas necessárias devido a problemas de incompatibilidade da arquitetura existente com a Web, como por exemplo o case-sensitive nas flags. Implementou-se de raiz toda a camada Web do sistema, mantendo as funcionalidades atuais, pois todas elas são importantes para o uso da aplicação. Foram ainda implementadas outras funcionalidades que faziam falta aos utilizadores, como por exemplo a interação com o Google Maps.
Depois de ter lido toda a documentação do software, comecei por fazer a migração do módulo Interfaces, responsável por criar e simular mensagens das
interfaces existentes na aplicação. É o módulo que tem menor quantidade de janelas,
grande parte do código está do lado servidor e, por isso, o código cliente torna-se mais simples. Já com algum know-how passei para o módulo Moradas, um dos principais módulos da aplicação, responsável pela gestão e certificação de moradas. Este módulo, ao contrário do outro, tem a estrutura do lado do cliente um pouco mais complexa e, por isso levou mais tempo a ser migrado. O último módulo a ser migrado
foi o de Equipamentos de Comutação, é um dos mais importantes pois foi dos primeiros módulos criados para a aplicação. No processo de migração, utilizei software disponível e licenciado pela Portugal Telecom, assim como ferramentas open source.
Neste relatório começo por explicar para que serve a aplicação, dando uma breve introdução sobre os seus principais módulos, explico como está estruturada a rede, apresento um diagrama da sua arquitetura atual e de como ficou após a migração. Ainda neste capítulo, defino todos os intervenientes no diagrama de rede e descrevo a função de cada um. No seguinte, falo sobre os programas e tecnologias que estudei e usei, justificando a sua utilização. Segue-se a implementação e os resultados, onde mostro alguns pedaços de código Java que acho mais importante que sejam evidenciados; explico de que maneira é que o Java faz a interação com os servidores e proxys, que funcionalidades foram mudadas ou criadas, o que fiz para melhorar a usabilidade da aplicação (um dos principais objetivos da migração), de que maneira é que novos serviços como o Google Maps foram integrados e quais os problemas que apareceram durante o desenvolvimento. Por fim, concluo com uma apreciação global do projeto desenvolvido, o que correu bem e o que correu mal, dou referência a algum trabalho que não foi feito por falta de tempo, desenvolvimentos passiveis de serem feitos no futuro e aquilo que agora, no fim do estágio, me parece que podia ter sido melhor desenvolvido ou ser feito de forma diferente.
2. Aplicação Existente
No primeiro mês de estágio, durante cerca de 15 dias, tive uma formação com um colega de equipa que me ajudou a conhecer a aplicação. Com base no que aprendi nessa formação, nas próximas secções, vou explicar em que consiste a aplicação e para que servem os seus módulos mais importantes.
2.1 Aplicação
Esta aplicação surgiu da necessidade de uniformizar o Sistema de Informação de suporte à gestão da rede de acesso da Portugal Telecom. Quando é feito o pedido de um serviço na rede de cobre da PT, é esta aplicação que trata de satisfazer esse pedido com todos os equipamentos necessários. Antes da sua criação, todo o sistema estava espalhado por diversas aplicações. Na altura da sua criação foram definidos alguns objetivos, como:
Uniformizar e assegurar todos os processos de gestão e manutenção da Rede, equipamento de comutação e atribuição de recursos;
Converter todos os dados para o novo sistema, mantendo as estruturas da rede e respectivas codificações durante o periodo de transição;
Garantir a flexibilidade necessária para adaptação da evolução tecnológica e das exigências do mercado;
Criar um modelo de interfaces que interajam de forma simples com outras aplicações.
Figura 1 - Ecrã principal da aplicação
Como podemos ver na figura 1, para além do módulo Interfaces, existem outros 11 módulos diferentes, uns mais importantes do que outros, mas todos eles necessários para que o sistema cumpra os objetivos para o qual foi criado. De seguida, explico as características daqueles que são indispensáveis para a gestão da rede.
2.2 Áreas de Influência
O módulo de Áreas de Influência tem como objetivo associar a morada de instalação de uma requisição, com as infraestruturas da rede por onde vão ser fornecidos os serviços aos clientes.
Área de Influência consiste na localização das infraestruturas da rede e definição de áreas onde os elementos de rede se situam e onde podem servir. Quando é recebida uma requisição, uma das etapas é a Localização. Em função da morada de instalação é determinada qual a Área da Central e os elementos de rede do tipo
terminal (ultimo ponto da rede que liga ao cliente) que podem satisfazer a requisição. Para a escolha é usada a zona geográfica para a qual o elemento de rede terminal atende preferencialmente. Este módulo é capaz de obter a localização automaticamente, ou seja, sem intervenção humana.
Para que seja melhor entendido, vou proceder à análise da seguinte figura:
Figura 2 - Exemplo de áreas de influência
Na figura 2 pode-se ver a definição de duas áreas de influência, 1 e 2, onde são associadas moradas a elementos de rede. Em 3, quando é recebida uma requisição de uma morada de instalação, que corresponde à Área de Influência previamente criada para a morada Avenida da Boavista 35, é automaticamente associada ao Elemento de Rede PSD 1 pertencente a Área de Central 99AR51, ou seja, é este Elemento de Rede que vai ser usado para atender a requisição.
Em suma, os processos implementados neste módulo são a criação, alteração e remoção de Áreas de Influência que fazem uso de outros três módulos.
Moradas – Cadastro das localizações reais;
Rede de Acesso – Gere o cadastro dos elementos que constituem a rede;
Equipamento de comutação – Cadastro dos elementos de rede e áreas
de centrais associadas.
2.3 Rede de Acesso
Quando falamos em Rede de Acesso estamo-nos a referir a todos os componentes que constituem a Rede Local, ou seja, todos os elementos entre a central e o cliente que são da responsabilidade de gestão da Portugal Telecom, quer se encontrem no exterior ou interior de edifícios de cliente.
Este módulo tem como objetivo gerir o cadastro dos vários elementos que constituem a rede. Aqui, também é controlada a disponibilidade e capacidade existente para pedidos de ligação à rede telefónica, sendo estes geridos pelo módulo de Atribuição de Recursos. Também é possível vermos a topologia da rede assim como as suas características técnicas, facilitando a deteção da necessidade de novos projetos.
De uma forma mais objetiva, este módulo é capaz de fazer o seguinte:
Registo de todos os Elementos de Rede (morada, capacidades e dados específicos);
Gestão das ligações entre Elementos de Rede; Criação, alteração e eliminação de ligações par a par.
2.4 Equipamento de Comutação
Equipamentos de Comutação foi o terceiro e último módulo a ser migrado durante o estágio, e inclui todos os equipamentos que possibilitam os serviços de comutação indispensáveis à comunicação entre clientes. Aqui é assegurada a informação de cadastro dos equipamentos de comutação, fazendo a associação de um número, que permite ao cliente o acesso ao serviço pedido e à porta ou canal da placa capaz de fornecer esse serviço, dependendo das suas características, capacidades e disponibilidades.
Este módulo é responsável por gerir a informação dos seguintes componentes: Área de Central – Zona onde estão associados os equipamentos de
comutação assim como os elementos de rede, por onde são fornecidos os serviços;
Comutador – Presta serviço de comutação às Unidades de Atendimento
às quais está ligado, fornecendo os caminhos para a comunicação entre clientes;
Unidades de Atendimento - É o conjunto de equipamentos de atendimento de cliente que são servidos pelo mesmo Comutador. Podem ser locais, quando estão junto do seu comutador, ou remotas. Esta distingue o equipamento que é servido por comutadores diferentes na mesma Área Central, ou que são servidos pelo mesmo comutador mas estão remotizados;
Placas e Portas de Unidades de Atendimento – Hardware de uma
determinada tecnologia capaz de fornecer Serviços de Suporte. Uma placa tem dois atributos: Prateleira e Posição. A Posição é definida por um endereço chamado de Porta, cada Porta pode ter vários canais;
Informação de Numeração – Informação sobre números cuja marcação
dá acesso a determinados serviços.
2.5 Atribuição de Recursos
Quando é recebida uma requisição de cliente nas aplicações de atendimento da Portugal Telecom a solicitar a instalação, alteração ou remoção de um ou mais serviços, estas são registadas como requisições. Estas requisições contêm todas as caraterísticas dos serviços assim como a morada de instalação.
A aplicação recebe estas requisições e o seu módulo de Atribuição de Recursos é responsável por calcular o caminho da Rede de Acesso que está disponível, desde a morada de instalação até ao Comutador, atribuindo um ou vários números ao cliente para o acesso aos Serviços pedidos. Quando a Atribuição de Recursos está concluída, essa informação é enviada de volta para a aplicação de atendimento e esta vai ser responsável por instalar os recursos identificados. Depois da instalação deve ser enviada a informação de satisfação do cliente para a aplicação, para que haja uma atualização de cadastro. O módulo Regras é quem decide como
devem ser processadas as requisições quando chegam, se devem ser cativadas1 manualmente ou automaticamente.
Podemos então concluir que este módulo é responsável pelas seguintes fases: Reconhecer qual o Elemento de Rede Terminal em melhores condições,
para satisfazer o serviço pedido pelo cliente;
A partir do Elemento de Rede Terminal, identificar o encaminhamento da Rede de Acesso até ao comutador. Na central é identificado o equipamento de comutação e um ou mais números adequados ao fornecimento de determinado serviço;
Nos casos em que não é possível proceder à cativação, devido a insuficiências de infraestrutura, são emitidas mensagens com os motivos, para que se proceda a uma intervenção manual;
Se a intervenção manual não for possível, as requisições passam a ser tratadas no sub-módulo “Gerir Lista de Espera” podendo ou não existir intervenções diretas no terreno. Neste sub-módulo são simuladas mais uma vez as ordens de cativação;
Por fim, quando é concluída a instalação, recebe a atualização de cadastro, como referido em cima.
2.6 Moradas
O módulo Moradas foi o segundo módulo a ser migrado, e é aqui que é feita a gestão de Arruamentos, Códigos Postais, Localidades, Apartados, Agrupamento de Arruamentos, Prédios, Unidades de Alojamento (ex. apartamentos), Edifícios e Moradas Internacionais. Os pedidos de clientes para a instalação de novos serviços e alteração ou remoção de serviços já existentes, são recolhidos através de canais de atendimento. As moradas de requisição são enviadas para o módulo Moradas, e aí serão validadas/certificadas. A resposta é enviada de volta para a aplicação de
1
Identificação do encaminhamento de rede que melhor se adequa ao serviço solicitado. Neste processo são escolhidos os elementos de rede e os equipamentos necessários.
atendimento e a requisição é assim satisfeita. Grande parte da base de dados é fornecida pelos CTT.
O módulo Áreas de Influência usa a informação armazenada neste módulo para a localização automática de recursos de rede, através da morada da requisição.
2.7 Interfaces
O módulo Interfaces foi o primeiro módulo a ser migrado, tem como principal funcionalidade criar e simular mensagens das interfaces existentes na aplicação (cerca de 70). Também é possível criar, alterar ou remover interfaces, mensagens de erro, permissões de utilizadores e gerir os valores permitidos. Este módulo é usado apenas para testes, por isso é que não aparece no menu principal da aplicação (fig. 1).
Suponhamos que queríamos testar a certificação no módulo Moradas, sem este módulo teríamos que pedir a uma aplicação de atendimento que enviasse uma requisição para a aplicação, o que é perfeitamente desnecessário. Basta para isso, criar uma mensagem neste módulo com os registos e atributos necessários à certificação de uma morada, incluindo a sua origem, e executa-la. Depois de executada, ela vai aparecer no módulo Moradas como se tivesse sido enviada por uma aplicação externa.
Figura 3 - Interfaces, criação de mensagem
Na figura 3, podemos ver uma mensagem a ser criada. Temos a interface que vamos usar, neste caso a GII027 (Interfaces Pedido de Certificação de Morada), o tipo de interface, os registos disponíveis para serem adicionados à mensagem, os registos que já foram adicionados e os atributos com os valores que lhe dei de cada registo. Neste caso só preciso de dois registos, o primeiro (GIIE027PC) para descrever a morada e o segundo (GIIE027XX) apenas serve para identificar o fim da mensagem.
Para além das principais funcionalidades, o módulo também nos permite consultar o registo da mensagem, o histórico, a resposta e alterar o estado.
2.8 Arquitetura de rede interna
Na figura 4 está representado o diagrama da arquitetura de rede para a aplicação.
MainFrame
Proc AB AB AB DB2 Proc Proc AB ProcJAVA / SEAM
Proxy Proxy Proxy
Allfusion Gen GuardIEn
Browser
TCP/IP
CICS
Listener ListenerWindows
AB AB GUI (Proc) C++ GUI (Proc) C++ AB Client Manager (COBOL / SQL) (COBOL / SQL) (COBOL / SQL) (COBOL / SQL)Toda a aplicação original foi programada no Allfusion Gen; esta ferramenta tem uma linguagem própria e é responsável pela geração dos proxys Java, dos PROCs (Procedure Step) e dos ABs (Action Block). Depois da geração é usada uma aplicação chamada build to para compilarmos o código, tanto das janelas da aplicação Windows como os proxys da aplicação Web.
Os PROCs são programas usados para analisar um conjunto de dados e produzir outputs diferentes. Recebem os dados enviados pelo utilizador, chamam os ABs para alterar e interpretar esses dados e devolvem o resultado ao utilizador. Os ABs são chamados pelos PROCs e por outros ABs. Tratam os dados recebidos e caso seja necessário, podem interagir com a base de dados tanto para consulta de informação como para alterações e remoções de dados. Os dados são alterados consoante a função do AB e no fim são devolvidos ao PROC.
Quando um cliente numa máquina Windows solicita alguma requisição pela aplicação, esta é enviada para o Client Manager instalado na máquina e depois reencaminhada por uma ligação TCP/IP (Transmission Control Protocol/Internet Protocol) para o MainFrame usando sockets. O MainFrame é um computador de grandes dimensões e tem como principal linguagem o COBOL (COmmon Business Oriented Language). Na sua maioria, são usados em grandes empresas como é o caso da Portugal Telecom. Um computador destes pode substituir centenas de servidores mais pequenos. Para serem acedidos logicamente usam-se terminais que emulam o sistema operativo do MainFrame. No meu caso usei o RUMBA, um software para Windows. O MainFrame da empresa usa z/OS, um sistema operativo de 64 bits criado pela IBM e que suporta funcionalidades como o CICS (Customer Information Control System) e DB2. Este SO trata um elevado número de informações contínuas, com grande estabilidade e segurança. [1]
No MainFrame existe uma componente chamada CICS, um monitor de transações que é usado para processamentos Batch e para atividades online. Quando existem transações que são efetuadas em vários passos, o CICS tem que saber que se um desses passos falhar então os outros todos também têm que falhar para garantir consistência nos dados. Suporta milhares de transações por segundo e fornece escalabilidade a muito baixo custo por transação. Quando surgiu, apenas era usado em MainFrames da IBM com sistemas operativos z/OS e z/VSE, hoje em dia já é usado noutros sistemas. [2]
O CICS contem um listener que recebe a requisição e vai procurar nos seus registos qual é a transação que vai usar para chamar determinado programa, com base nos dados recebidos. Ou seja, se o cliente estiver a consultar os detalhes de um Arruamento na aplicação, o listener vai chamar a transação que diz respeito ao PROC que permite a consulta dessa informação. O PROC vai chamar os ABs para estes tratarem dos dados recebidos e solicitar informação à base de dados, caso seja preciso. Tanto os PROCs como os ABs foram gerados em COBOL e SQL (Structured Query Language) no caso dos que precisam de consultar a base de dados DB2.
DB2 é um sistema de gestão de base de dados relacionais que trabalha no MainFrame, feito pela IBM. A linguagem utilizada é SQL e é usado em empresas que necessitam de transformar grandes quantidades de dados em informação de negócio. Inicialmente este sistema de base de dados apenas trabalhava em MainFrames da IBM, mais tarde foi alargado para sistemas UNIX e Windows. Como já foi dito o MainFrame trabalha com z/OS, e o DB2 para este sistema além de ser usado para suportar operações críticas em áreas de negócios, permite também uma grande performance OLTP (Online Transaction Processing)2. DB2 para z/OS tem algumas caraterísticas exclusivas como a segurança multi-nível, compressão a nível de
hardware e tabelas com tamanhos muito grandes. [3] [4]
Para a nossa aplicação Web funcionar, a arquitetura do lado de fora do MainFrame foi um pouco alterada. A aplicação Web é mantida num servidor WebLogic, o browser do cliente comunica com este servidor. Em vez de termos um
client manager responsável por receber as requisições e reencaminha-las, temos os proxys que basicamente têm a mesma função e comunicam com o cliente através do
protocolo HTTP (Hypertext Transfer Protocol). Um proxy é um intermediário entre o cliente e o servidor. Neste caso, a função do proxy é receber uma requisição da aplicação Web e reencaminha-la para o CICS no MainFrame via protocolo TCP/IP através de sockets. A resposta é recebida de igual forma, o MainFrame envia para o
2
proxy e este para o cliente. Quando o proxy envia a requisição para o MainFrame todo
o processo é executado da mesma forma que na arquitetura anterior.
2.9 Arquitetura de rede para aplicações externas
Quando as aplicações externas comunicam com a aplicação, a arquitetura é diferente. APPs Externas
T
I
B
C
O
(xml)
T
U
X
E
D
O
AB Proc AB AB DB2CICS
TCP/IP TCP/IP Lis
ten
er
Proc
Figura 5 - Diagrama de rede para aplicações externas
Temos três novos componentes na figura 5. As aplicações externas são aplicações que necessitam, por exemplo, de vir certificar moradas à nossa aplicação. O cliente vai a uma loja e pede que um determinado serviço seja instalado em sua casa. O funcionário da loja tem uma aplicação que vai verificar se a morada do cliente se encontra certificada na nossa aplicação. Caso não se encontre, vai tentar certifica-la. As aplicações externar comunicam com o TIBCO via TCP/IP.
O TIBCO é um software que gere informações, processos e decisões em tempo real. Permite a comunicação entre softwares que são incompatíveis e pode ser usado localmente ou em nuvem. TIBCO fornece um middleware3 que faz com que o acesso aos dados possa ser feito por vários sistemas ao mesmo tempo. [5]
3
Um mediador entre o software e as várias aplicações. Usa-se para transferir dados entre programas que usam protocolos diferentes.
Atua em três áreas críticas [6]:
SOA (Service Oriented Architecture) - Uma arquitetura orientada a serviços. Estes serviços são acessíveis através de interfaces que são disponibilizadas através de webservices. Os serviços não são mais do que funcionalidades das várias aplicações.
BPM (Business Process Management) – Faz a gestão completa e consistente dos fluxos de processos das empresas.
BO (Business Optimization) – Converte fluxos de dados em informações criticas, disponibilizando-as a clientes e parceiros.
As aplicações externas invocam um webservice do TIBCO, que recebe a mensagem em formato XML (eXtensible Markup Language) e converte-a para um
buffer. [5] O buffer é enviado para um middlewareno MainFrame também por TCP/IP. Este middleware é o TUXEDO (Transactions for Unix, Extended for Distributed Operations), que gere transações distribuídas em computadores e tem uma plataforma muito escalável para desenvolver, implementar e gerir aplicações críticas para a missão [7].
O TUXEDO recebe o buffer e reencaminha-o para o listener que existe no CICS. A partir daqui todo o processo é igual ao anterior, ou seja, o listener escolhe a transação que invoca o programa que a mensagem deseja chamar, este chama os ABs, os ABs podem chamar outros ABs ou ir buscar informação à base de dados. A resposta é enviada no sentido inverso, em buffer para o TIBCO e este converte-a em XML para ser lida pela aplicação externa. Ao longo do processo existem mensagens de confirmação para verificar o sucesso ou insucesso relativamente à entrega das mensagens entre os componentes.
3. Programas e Tecnologias Usadas
A minha participação na escolha das tecnologias foi pouca, ou quase nenhuma, pois na proposta de estágio referia quais eram aquelas que seriam utilizadas. Nunca tinha trabalhado com a maior parte destas tecnologias por isso, aproveitei o período de tempo desde a confirmação do estágio até ao primeiro dia de trabalho, para tirar pequenos cursos online acerca destas tecnologias. Quando cheguei à empresa a minha equipa já tinha criado a base do projeto no Eclipse, e por isso algumas das ferramentas já estavam a ser usadas. Mesmo não tendo participado na escolha, procurei saber junto da minha equipa a razão de terem sido escolhidas aquelas tecnologias e não outras e, é isso que explico nas próximas secções.
3.1 Eclipse
Eclipse é uma ferramenta open source, foi o ambiente de desenvolvimento usado para este projeto. Este IDE (Integrated Development Environment) é escrito em Java e é usado, principalmente, para desenvolver aplicações nesta linguagem. No entanto, através de plugins é possível escrever noutras linguagens como por ex. COBOL, C, C++, Ruby, PHP (PHP Hypertext Preprocessor), entre outras. Foi na IBM que surgiu este projeto, que mais tarde decidiu torná-lo open source. [8]
Para o projeto necessitei de instalar vários plugins no eclipse:
SVN – O Subversion é um sistema de controlo de versões onde toda a história de um projeto é armazenada num servidor. Foi usado também o
plugin Subclipse, para manipular todas as ações do SVN, tornando o
desenvolvimento mais ágil. Com este plugin integrado no eclipse é possível, por exemplo, fazer com que o nosso projeto volte a uma determinada data sem perder tudo o que foi feito antes e após essa data. É também muito útil para quando é um projeto de equipa, pois permite que cada elemento da equipa esteja a trabalhar no mesmo código e que façam
commit para o servidor quando essa alteração estiver pronta. Os outros
elementos podem atualizar a sua versão do código fazendo update. [9] Jboss Tools – É um conjunto de plugins para integrar os produtos da
JBOSS no eclipse. Tem vários módulos, vou falar apenas daqueles que foram essenciais para o meu projeto [10]:
Visual Page Editor – Um editor que suporta HTML, JSF e bibliotecas de componente como o Richfaces, que também foi usado no projeto. Com este editor podemos estar a escrever o nosso código e pré visualizá-lo numa outra janela.
Seam Tools – Necessário para criar por exemplo os projetos
Seam. Tem caraterísticas como permitir auto complementação e
refatoriza código Seam.
Jboss AS Tools – Para interagir com os servidores, no meu caso Weblogic. Facilita o start e o stop do servidor e tem ferramentas que possibilitam o deploy de qualquer projeto.
Oracle WebLogic Server Tools – Este conjunto de plugins oferece ferramentas que facilitam o desenvolvimento e implementação de aplicações com o Oracle WebLogic Server.
3.2 Jboss Seam 2.2.2
O Jboss Seam é uma framework para aplicações Web desenvolvidas em Java. Escolhemos esta framework porque a Portugal Telecom já tinha uma licença da Red Hat, licença essa que entre outras vantagens nos fornecia suporte. Além disso existe outro projeto na empresa que também está a usar esta framework, havendo assim a possibilidade de partilha de conhecimento. A versão 2.2.2 era a versão que estava mais estável na altura em que se começou o projeto.
Com o Seam o desenvolvimento de aplicações Java EE torna-se mais fácil, alinha as especificações do Java Server Faces e Enterprise Java Beans, formando um modelo unificado de componentes, para facilitar o desenvolvimento de aplicações que usem as duas especificações. Esta framework foi criada para simplificar a parte arquitetural e de utilização das APIs (Application Programming Interface), fazendo com que o programador use classes simples anotadas, muitos componentes visuais e pouco XML. Pode ser usada com qualquer servidor aplicacional compatível com Java EE 5.0; neste projeto foi usado o WebLogic. [10] [14]
3.2.1 WebLogic 10.3.4
WebLogic é um servidor aplicacional de Web J2EE4. Contem várias ferramentas para implementar o ambiente de programação em Java, incluindo JSP, Servlets e EJB. Podia-se ter usado outro servidor, como por exemplo o JBOSS, no entanto, a maior parte das aplicações Java que existem na Portugal Telecom usam WebLogic como servidor e, por isso seria lógico que não se mudasse o paradigma. JBOSS é freeware e é recomendado para aplicações que não tenham um grande número de utilizadores em simultâneo. Já o WebLogic implica maiores gastos, mas é a melhor opção para quando queremos ter escalabilidade em aplicações com um grande número de utilizadores. [12] Usou-se a versão 10.3 porque no manual do Seam, é esta a versão que é utilizada para mostrar os exemplos e, por isso, pareceu aquela que estaria mais estável para trabalhar com esta framework [13].
3.2.2 JSF – JavaServer Faces
Uma framework MVC [26] de aplicações Web baseada em Java, como o nome indica. A versão atual é a 2.0, no entanto neste projeto usou-se a 1.2 pois o BEA Weblogic foi servidor aplicacional e, no manual do Seam apenas existe documentação para a integração do JSF 1.2 para este tipo de servidor [13].
Até então, as ações do sistema eram controladas através da submissão de formulários. A ideia principal deste framework é separar cada parte de uma página em componentes, que se controlam a si próprios e que podem despoletar eventos integrando-se com outros componentes. Com este modelo baseado em componentes, as páginas Web ficam mais complexas por causa da separação de responsabilidades. São disponibilizadas uma serie de tags JSP que são usadas para chamar alguns componentes. Os eventos do lado do cliente são manipulados pelos eventos do lado do servidor. Utiliza Ajax (Asynchronous Javascript and XML) em alguns componentes para que as diferentes ações sejam executadas mais rapidamente e de maneira eficiente. Para além de Ajax, as folhas de estilo CSS e comandos JavaScript podem
4
também ser integrados. No entanto, esta framework é um pouco confusa e pesada em XML. O Seam veio revolucionar esta tecnologia, pois substitui a configuração XML por um conjunto de anotações, reduzindo assim as linhas de código e tornando-o mais produtivo. [14]
O JSF não foi feito para ter uma estrutura completa para aplicações Web, mas fornece uma API orientada a eventos e uma biblioteca de componentes que servem de estrutura para construir uma framework mais completa. Ou seja, o Seam é uma
framework que usa como base o JSF e, por isso se pode dizer que se completam. [15]
3.2.3 EJB – Enterprise JavaBeans
É um componente da plataforma J2EE. Tem como objetivo simplificar o desenvolvimento de aplicações Java, é do tipo servidor e é executado no container5 do servidor da aplicação. A última versão é a 3.1 e, a grande diferença das versões anteriores, como a 2.1, para esta versão, está nas anotações Java que não existiam. Seam é o primeiro modelo de programação que permite o uso de anotações Java 5 desde as entities de persistência até à UI. Estas anotações diminuem a quantidade de código e permitem-nos deixar de lado configurações em ficheiros XML que, até à data, eram precisas para tarefas comuns de programação; não querendo dizer que o Seam não use XML [14]. Existem três tipos de EJBs [16]:
Entity Beans – Este tipo refere-se a um objeto que está persistido numa base de dados. Por exemplo, uma classe Arruamento que tenha um ID, um nome, um indicativo e um título, se estiver com a anotação @Entity, é uma entity bean.
Session Beans – Executa um procedimento que venha do lado do cliente, no nosso caso vindo do código XHTML (eXtensible Hypertext Markup Language). Suponhamos que temos uma opção no nosso website que nos permite criar um Arruamento, depois de preenchermos todos os campos necessários, temos um botão que chama um método do nosso managed
5
Um objeto que tem outros objetos dentro. Estes podem ser removidos ou adicionados ao Container durante o tempo de execução.
bean que vai executar uma série de validações se forem necessárias, e
que posteriormente chama um outro método que contem a lógica de ligação ao proxy para que guarde a informação na base de dados. O bean pode ter dois tipos de estados:
@Stateful – Mantém o estado durante uma sessão com o cliente. Útil para processos de checkout (carrinho de compras), conseguindo-se assim manter o estado de onde o cliente está em determinado momento.
@Stateless – Estes não têm nenhum estado associado. No entanto, o acesso a uma determinada instância do Bean é apenas para um cliente de cada vez. Quando há acesso ao mesmo Bean por vários clientes em simultâneo, essas solicitações são enviadas cada uma para uma instância diferente. Um dos casos onde este tipo pode ser usado é quando temos uma opção no nosso website do tipo “Receber noticias sobre futuras atualizações”, ao clicar aqui é chamado um método que vai adicionar o utilizador à nossa base de dados. Este é um processo one-off pois, ao contrário do processo de
checkout, aqui não precisamos de vários passos para executar esta
ação.
Message Driven Beans – Envia mensagens de modo assíncrono entre EJBs. Este tipo não foi usado na nossa aplicação, pois não temos ações que necessitem de um bean deste tipo.
3.2.4 Richfaces
Esta a secção foi escrito baseando-me num livro sobre JBoss RichFaces 3.3 [17] e na sua documentação [18]. RichFaces é uma biblioteca open-source da JBoss que permite a fácil integração das nossas aplicações que usam JavaServer Faces com AJAX. Esta biblioteca não só aumenta os recursos AJAX, como também melhora outras áreas da aplicação, assim como a usabilidade, a performance, os recursos dinâmicos, o skinning (podemos facilmente alterar o visual da aplicação) e ajuda no desenvolvimento de componente do JSF.
Figura 6 – Fluxo de processamento de um evento [18]
Como se pode ver na figura 6, o programador pode definir um qualquer evento na página JSF que chama uma solicitação AJAX, assim como as áreas da página que esta solicitação vai atualizar. A solicitação AJAX muda os dados no servidor de acordo com o evento do cliente e este devolve a resposta. Como é tudo controlado do lado do servidor, além do estado da página ser mantido no servidor, o programador não precisa de escrever código JavaScript.
3.2.5 Arquitetura Richfaces
A arquitetura é composta por duas bibliotecas: A4j – Utilizado em todos os controlos AJAX. Rich – Para usar os componentes do RichFaces.
A arquitetura inclui 4 elementos essenciais da framework:
Ajax Filter – Os filtros devem ser registados no ficheiro web.xml. Na figura 7 é
Figura 7 – Sequência de processamento do pedido [18]
No primeiro caso (o superior) todo o JSF é codificado e o filtro não analisa a resposta antes de enviar para o cliente. Já no segundo caso (o inferior), nem toda a região é codificada, tudo depende da área da região AJAX e o filtro analisa a resposta antes de esta chegar ao cliente.
Como mostra a figura 8, quando é pedido um recurso, o filtro do RichFaces vai verificar se esse recurso não se encontra em cache. No caso de existir, é enviado de volta para o cliente, caso contrário o Resource Builder regista o pedido e só depois será enviado.
Ajax actions components – São os componentes de ação, e são usados para
enviar requisições Ajax do lado do cliente. Ex. <a4j:commandButton> e <a4j:commandLink>.
AjaxContainer – É uma interface que se refere a uma área na página JSF que
vai ser descodificada, durante uma requisição.
JavaScript engine – Um motor de JavaScript que é executado do lado do
cliente. Com base nas respostas AJAX ele vai saber como atualizar cada área de uma página JSF.
3.3 PIE (Progressive Internet Explorer)
PIE é uma biblioteca JavaScript. Os diferentes browsers que existem são uma dor de cabeça para qualquer programador. O uso de CSS3 no front-end de websites as vezes torna-se complicado devido à incompatibilidade de renderização entre os
browsers. Cantos arredondados, sombras, gradientes, transparência entre outros, são
algumas das propriedades que ficam bem no design de um website mas que precisam de ser ajustadas aos vários browsers como é o caso do Internet Explorer, o mais usado dentro da Portugal Telecom. Para ajudar na renderização foi usado JavaScript, neste caso o PIE. Não é preciso perceber muito de JavaScript para usar o PIE, pois a aplicação deste é simples e baseada na hospedagem de alguns ficheiros no servidor e na chamada destes por parte da classe ou ID correspondente no CSS. [19]
3.4 Allfusion Gen e GuardIEn
Toda a aplicação existente foi gerada com o Alfusion Gen, um ambiente de desenvolvimento para conceção, implementação e manutenção de aplicações escaláveis. O Allfusion Gen faz geração de código livre de erros para todo o tipo de soluções, seja a lógica da aplicação, infraestruturas de comunicação, servidores Web
e browser interfaces. Sempre que há alterações, estas apenas exigem um pequeno esforço, visto que todas as mudanças são feitas a nível do modelo e não do código. Isto permite que as empresas mudem rapidamente para outros ambientes, como J2EE, sem serem especialistas nesses ambientes e sem precisarem de reescrever o código. Existe uma maior flexibilidade na escolha de um melhor ambiente, e dá a possibilidade às empresas de fazer investimentos em tecnologias que já estão implementadas. [20]
O GuardIEn é um software que suporta e gere os modelos do Alfusion Gen. É essencial para as empresas controlarem as aplicações desenvolvidas pelo Alfusion Gen e que, ao mesmo tempo, necessitam de reduzir o overhead desse controlo. Antes de uma determinada encomenda entrar em produção, passa por vários estados, sendo que essas fases são controladas no GuardIEn. No meu projeto foi essencial para consultar o código dos servidores e dos clientes. Também me foi útil para gerar os servidores, pois para fazermos o trace das entradas e das saídas de um determinado servidor, caso ele não esteja gerado com trace ativo, é necessário que ele seja gerado novamente.
3.5 RUMBA, MainFrame Edition
O RUMBA é um emulador de terminal usado para se ligar e utilizar informação do MainFrame que, neste caso é da IBM e tem o sistema operativo z/OS. Garante uma ligação segura e uma grande fiabilidade. Por vezes o código gerado pelo Allfusion Gen não é suficientemente explícito para percebermos quais são os parâmetros de entrada e de saída de um determinado servidor e, por isso, durante o meu projeto, usei várias vezes esta ferramenta para fazer trace aos servidores. [21]
3.6 Google Maps JavaScript API v3
Esta API [22] permite incorporar o Google Maps num website. A versão 3 veio trazer maior rapidez na consulta de mapas. Existe uma grande quantidade de ferramentas que permite manipular e adicionar conteúdo aos mapas.
Antes de usar a API do Google, consultei a documentação de outras duas APIs para escolher aquela que melhor se iria adequar ao que era preciso para o meu projeto. A indecisão estava entre o Google Maps, Bing Maps e Sapo Maps. Decidi pôr
de parte o Sapo Maps pois a sua documentação está muito resumida, não tem nada que se assemelhe ao Street View da Google e as ferramentas de manipulação são muito mais reduzidas. Visto que, no meu projeto era interessante a vista de rua, fiz alguns testes no Streetside do Bing e no Street View da Google e cheguei à conclusão que este tipo de visualização no mapa estava indisponível para grande parte dos locais no Bing Maps, pelo menos em Portugal.
Figura 9 - Google Maps vs Bing Maps
A figura 6 é referente à Avenida Visconde de Barreiros, umas das avenidas mais conhecidas na Maia, sendo que a vista de rua está disponível no Google Maps, mas não no Bing Maps.
A escolha acabou por cair no Google Maps pois, para além do que já foi dito e apesar da documentação do Bing Maps também estar bastante boa, a do Google está mais completa, com muitos exemplos de código. Um outro motivo que também pesou na minha escolha foi o facto de nos fóruns de discussão, cerca de 70% dos tópicos
sobre este assunto são acerca do Google Maps e, por isso, seria mais fácil resolver eventuais problemas que pudessem surgir comuns a outros utilizadores.
Em complemento desta API, usei dois serviços fundamenteis, a Geocoding API e Directions API.
3.6.1 Geocoding API
Este serviço permite fazer a conversão de endereços (Avenida Visconde de Barreiros) em coordenadas geográficas (37,445342 -122,023213), que podem ser usadas para adicionar marcadores a um mapa, num determinado local. Existe a geocodificação reversa, que também foi usada no meu projeto, que é o processo inverso quando queremos converter coordenadas em endereços. As respostas HTTP de geocodificação podem vir em formato JSON (JavaScript Object Notation) ou XML, um exemplo de um pedido de coordenadas da Avenida Visconde de Barreiros é o seguinte:
http://maps.googleapis.com/maps/api/geocode/json?address=Avenida +Visconde+Barreiros,Maia,&sensor=false
O endereço, para além de devolver as coordenadas desta rua, neste caso em formato JSON, dá-nos também outras caraterísticas como o código postal. [23]
3.6.2 Directions API
Esta API permite calcular percursos entre localizações através de solicitações HTTP. É possível escolher vários tipos de transporte assim como especificar a origem, destino e pontos de passagem. [24]
4. Implementação e Resultados
Ao longo do estágio foram migrados três módulos: Interfaces, Moradas e Equipamento de Comutação. A escolha destes módulos não foi por acaso, analisei o grau de dependência de todos os módulos e cheguei à conclusão que estes eram aqueles que menos dependiam de outros, por isso seria lógico iniciar a migração aqui. Durante o início da implementação, além de ter tido uma pequena formação acerca da aplicação, também me foi aconselhado um documento [25] acerca de redes de acesso que me ajudou a perceber muito melhor a aplicação, revi alguns conceitos que falei em cadeiras de redes de telecomunicações, durante o curso, e aprendi outros. Como foi referido num dos capítulos anteriores, existe uma ferramenta responsável por gerar todo o código dos clientes e servidores, o Allfusion Gen. Cada um destes módulos tem dezenas, por vezes centenas de janelas clientes; foi necessário ler o código de todas essas janelas para perceber exatamente a função de cada uma. Estes clientes recebem os parâmetros dados pelo utilizador e, de acordo com a ação pretendida, chamam o ou os servidores responsáveis por manipular esses parâmetros. Os servidores recolhem essa informação e devolvem aos clientes o resultado. Esse resultado pode ser calculado apenas com base no código do servidor ou, caso seja preciso, chamam a base de dados para submeter ou recolher informação. Apesar de a migração ter sido feita do lado do cliente, os códigos dos servidores também tiveram que ser lidos para saber quais os parâmetros que estes recebem no input para devolver o output desejado.
A GUI (Graphical User Interface) da aplicação existente é muito confusa e pouco intuitiva. Um dos principais motivos para a criação deste projeto, para além de evitar que a aplicação fosse instalada em todas as máquinas dos utilizadores, foi fazer com que se conseguisse com o menor número de cliques e no menor tempo possível despoletar uma ação sem tornar a aplicação ainda mais confusa. Nas próximas secções, começo por explicar como é que o projeto está estruturado no eclipse em relação às classes existentes, e de que maneira a arquitetura Model-View-Controller [26] foi seguida. Mostro também algum código Java e JavaScript mais relevante usado em cada um dos módulos. Através de printscreens feitos nas duas aplicações (Windows e Web), vou fazer comparações para se perceber onde é que foi possível ganhar usabilidade. À medida que fui implementando as funcionalidades da aplicação
foram surgindo alguns problemas, na última secção falo sobre esses problemas e como é que se resolveram.
4.1 Projeto no eclipse
Foi criado no eclipse um projeto Seam com o nome org.ptsi.sigraweb em que vários pacotes, pastas e ficheiros de configuração foram criados automaticamente. Existem três pacotes fundamentais onde estão as classes do projeto e o WebContent que contem as páginas Web.
4.1.1 Entity
Aqui, como o nome indica, estão as entidades. Existem cerca de 50 entidades diferentes em cada módulo. Por exemplo, um equipamento no módulo da comutação tem vários atributos: id, endereço, tráfego_lido, tráfego_máximo_permitido, data_estado etc… Esses atributos estão todos definidos nestas classes com os respetivos getters e setters. Para definir uma classe como sendo uma entity no Seam, basta adicionarmos a tag @Entity no início do código, depois dos imports.
Para além deste tipo de classes temos as classes das interfaces. Estas classes têm centenas de funções que são chamadas pelos beans, e são responsáveis por fazer todo o tipo de ligações com os servidores através dos proxies. No anexo listarGrupoDeRedes, está uma função de uma das classes interfaces que lista o grupo de redes do módulo de comutação. Esta função envia os dados para o input do servidor responsável por esta listagem, através dos parâmetros que estão na string “connectionString”. Esses dados podem ser nulos se o utilizador quiser a listagem de todos eles, ou podem conter dados se quiser filtrar os resultados. Depois o servidor devolve um array de resultados e, através de um ciclo for, é guardado o output noutro
array que é devolvido ao bean, que chamou esta função.
Uma vez que o código é gerado, os detalhes da comunicação são transparentes para quem desenvolve. A autenticação na aplicação é feita por uma classe que também está neste pacote. Essa classe tem a função do anexo Autenticação que é responsável por enviar o id e password do utilizador para o proxy. Essa função vai retornar true se as credenciais estiverem corretas ou false caso o contrário.
4.1.2 Session
Para fornecer os dados aos diferentes componentes das páginas Web é necessário criar os managed beans e, é neste pacote que eles são criados. Um
managed bean para além de fornecer os dados para as páginas, recebe os dados
submetidos pelo utilizador e trata os diferentes eventos.
Listagem 1
O utilizador fez a pesquisa de um grupo de redes na página Web, então essa pesquisa despoletou uma ação no bean. A função ‘pesquisar’ da listagem 1, chama a função do anexo listarGrupoDeRedes que está na classe “InterfacesListagem” no pacote entity e guarda o resultado num array previamente criado “listaGrupoDeRedes”.
Anteriormente, com JavaServer Faces, sempre que quiséssemos criar um
bean teríamos que o registar num ficheiro de configuração chamado faces-config.xml.
Com o Seam não precisamos de fazer isso, basta adicionar anotações nas classes
managed beans, como é possível ver na listagem 1 “@Name(“grupoRedesBean”)”.
Quando usamos esta anotação, o bean passa a ser gerido pelo Seam por isso, além de ser um managed bean passa também a ser um Seam Component.
@Name("grupoRedesBean") public class GrupoDeRedesBean { public String pesquisar() {
grupoRedesSelecionado = new GruposRedes(); fechaTudo(); if(!filtro.getId_string().equals("")) { filtro.setId(Integer.valueOf(filtro.getId_string())); } else { filtro.setId(0); } listaGrupoDeRedes = InterfacesListagem.listarGrupoDeRedes(filtro); return "/Comutacao_grupoRedes.xhtml"; }}
4.1.3 Utils
Este pacote tem apenas uma classe, a do leitor de configurações. Esta classe é responsável por ler o conteúdo do ficheiro de configurações onde está o endereço do MainFrame. Essa informação vai ser passada a todas as funções das classes das
interfaces, para que estas consigam comunicar com os servidores através dos proxies,
como acontece na função do anexo listarGrupoDeRedes.
4.1.4 WebContent
É neste diretório que estão todas as páginas Web em formato XHTML, as folhas de estilo CSS, os ficheiros JavaScript e as imagens do projeto. Usou-se um sistema de template Web chamado Facelets, uma tecnologia do JavaServer Faces que foi idealizada com o objetivo de gerar uma árvore de componentes. Todas as páginas Web têm uma estrutura semelhante à da listagem 2.
Listagem 2
<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:s="http://jboss.com/products/seam/taglib" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html" xmlns:rich="http://richfaces.org/rich" xmlns:a4j="http://richfaces.org/a4j" template="layout/template.xhtml">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" />
<ui:define name="body">
CONTEUDO AQUI
</ui:define>
Para escrever uma página com Facelets, é necessário declarar quais a taglibs que vamos usar. Para cada taglib diferente usa-se namespaces6 distintos. Na listagem 3 definiram-se alguns namespace, cada um associado a uma taglib, como por exemplo: Facelets, HTML (do JSF), Core (do JSF) entre outros.
Uma das grandes vantagens do Facelets é a possibilidade de criarmos uma página layout para a aplicação. Nessa página são definidas partes comuns à maioria das páginas como é o caso das cores, fontes, estilos e CSS. Outra vantagem é a criação de lacunas no layout principal. Isto, permite que tenhamos cabeçalhos e rodapés iguais em todas as páginas e que, o seu conteúdo principal seja definido pelo utilizador nas páginas que usam o layout.
Figura 10 – Lacunas no layout
Como mostra na figura 10, na página de layout definimos o nome para a lacuna usando a tag “insert”: <ui:insert name=”body”/>. Na página que contém o conteúdo das lacunas, usamos a tag “define” para preencher a lacuna definida, como é possível ver na listagem 2. Por fim, o Facelets faz a montagem do resultado final para ser apresentado ao utilizador.
6
Namespaces no xml são como pacotes no Java, permitem que duas tags com o mesmo nome sejam interpretadas de maneiras diferentes, consoante o namespace a que ela pertence.
4.2 Módulo Interfaces
O módulo dos Interfaces, como expliquei no capítulo da aplicação existente, foi o primeiro módulo a ser migrado. Este módulo não estava inserido na aplicação principal, apesar de fazer parte dela. Na migração foi-me pedido que o juntasse aos outros pois não fazia sentido estar separado.
Figura 11 – Aplicação, menu pincipal
Quando se faz o login na aplicação, aparece a janela da figura 12 com a janela da figura 11 por baixo. Ou seja, o utilizador é logo reencaminhado para a pesquisa de mensagens e, se quiser fazer outra operação diferente, tem que fechar duas janelas, a de pesquisa e a de listagem de mensagens, para ter acesso ao menu das outras funcionalidades. Na aplicação Web, depois do utilizador fazer o login, é reencaminhado para uma página de pesquisa de mensagens mas, ao mesmo tempo tem acesso ao menu das restantes funcionalidades, como mostra a figura 13. É possível também fazer logout em qualquer página, bastando clicar no botão sair, ao contrário do que acontece na aplicação original em que o utilizador tem que fechar as janelas todas abertas se pretender sair da aplicação.
Figura 13 – Web, critérios de pesquisa de mensagens
Na aplicação, a pesquisa de mensagens por interface apenas mostra o nome da interfaces (fig. 12), o que obriga o utilizador a saber à partida qual é a função de cada uma delas. Se o utilizador não souber, terá que ir a outro menu ver a sua descrição. Na aplicação Web, essa descrição é mostrada na combo box junto ao nome da interface (fig. 13), facilitando assim o processo de pesquisa.
Na lista de mensagens existe um submenu dessa mesma lista. Esse menu tem demasiados botões, muitos deles desnecessários, com funções que já não existem (fig. 14). Para sabermos a função de cada botão, se não a identificarmos pelo ícone, temos que passar o rato por cima e esperar que apareça a legenda na parte inferior da janela. Na aplicação Web fiz uma “limpeza” desses botões, tirando aqueles que
estavam a mais, e a descrição de cada botão passou a aparecer instantaneamente no próprio botão assim que o rato é passado por cima (fig. 15).
Figura 14 – Aplicação, lista de mensagens
Figura 15 – Web, lista de mensagens
Na figura 14 está disponível também um menu principal, para além do menu das mensagens. A maior parte das ações desse menu são repetidas no menu das
mensagens. Por isso, na aplicação Web essas incongruências foram removidas mostrando apenas um menu (fig. 15). Ações como ver ou editar mensagens, que antes estavam no menu, foram passadas para a própria lista. Para pesquisar uma nova mensagem na aplicação, antes teríamos que clicar num dos botões do menu que ia abrir a janela de pesquisa. Na Web a opção de pesquisa está sempre disponível na mesma página, através de uma aba horizontal.
Quando vemos os detalhes de uma mensagem, é aberta uma janela com toda a informação dessa mensagem assim como os seus registos (fig. 16). O utilizador pode não querer ver tanta informação ao mesmo tempo por isso, na Web essa informação é dividida através de abas. A primeira contém são os detalhes da mensagem e as outras os detalhes dos registos (fig. 17).
Figura 17 – Web, detalhes de uma mensagem
Na Web existe uma nova aba chamada buffer, esta aba existe para alimentar uma das novas funcionalidades da aplicação (fig. 18). O utilizador pode querer criar uma mensagem igual a uma que já exista. Para isso, basta copiar o texto do buffer da mensagem e colá-lo numa nova página que permite criar uma mensagem através do
buffer (fig. 19).
Figura 18 – Web, detalhes de uma mensagem (buffer)
Ao criar a mensagem pelo buffer, o utilizador pode apenas criar ou criar e submeter a mensagem. Foi necessário criar um novo servidor que recebesse o buffer e o percebesse, para preencher a tabela das mensagens na base de dados com os valores corretos. O processo de criar uma nova mensagem estava um pouco confuso na aplicação. Como é possível ver na figura 20, o utilizador tem que escolher a
interface, depois mais abaixo o tipo de interface, clicar nos registos disponíveis que
quer adicionar à mensagem, passá-los para a lista de registos associados e alterar os valores dos atributos. Esta última ação implica que seja aberta uma nova janela por cada atributo que se altere.
Figura 20 – Aplicação, criação de mensagem
Na Web apenas é mostrada aquela informação que o utilizador tem que escolher em determinado momento, ou seja, se o utilizador ainda não escolheu a
interface que vai usar, não é necessário mostrar a parte dos tipos de interface e dos
registos. Isto é feito através de Ajax, á medida que o utilizador clica nas opções, pedidos Ajax são enviados para atualizar partes da página. Existe um registo em todas as mensagens que indica o seu fim, é o registo terminado em “XX”. Esse registo passou a ser adicionado automaticamente ao fim da mensagem. Alguns registos têm um predecessor que é configurado na janela de tipos de registo, por isso quando um registo desses é adicionado, o seu predecessor também terá que ser, o que não acontecia na aplicação anterior. Para além disso, existe um algoritmo que vai fazer com que os registos se posicionem na lista de registos disponíveis numa ordem correta, ou seja, quando existe um registo que tem um predecessor então esse registo deve aparecer depois do seu predecessor.
Figura 21 – Web, criação de mensagem
Na figura 20 é possível ver que cada registo tem dezenas de atributos, por isso abrir uma janela para alterar cada um desses atributos é um pouco demorado. Como mostro na figura 21, esse problema foi solucionado. Temos a lista de atributos e basta clicar na coluna do valor do atributo que queremos alterar. Para passarmos ao próximo atributo ou clicamos na coluna ou carregamos na tecla TAB.
Outros menus como “Tipos de Registo” (fig. 22) e “Tipos de Interface” também tinham o problema de alteração de valores em novas janelas, que entretanto foi solucionado na Web (fig. 23).
Figura 22 – Aplicação, janela dos tipos de registo
Figura 23 – Web, página dos tipos de registo
Esta solução de mostrar tudo na mesma janela através de Ajax, em vez de abrir novas janelas para cada ação, facilita a interação da aplicação com o utilizador, mas nem sempre é possível fazer isso. Quando temos tabelas com muitas colunas, é
necessário organizar a página de maneira a que a informação não fique misturada. O exemplo da figura 24 é um desses casos.
Figura 24 – Web, página dos tipos de interface (Regras Atributos)
Esta tabela (fig. 24), das regras dos atributos, deriva de uma outra tabela dos “Tipos de Interface”. Era impossível mostrar toda a informação numa única página por isso, através de AJAX, quando o utilizador chama esta tabela, a aplicação esconde as outras deixando a janela mais limpa.
