Sistema de Inscricoes Remotas

Breve explicação do que são Web Applications Frameworks

Tipicamente este tipo de frameworks proporcionam suporte para funções tais como:

• Navegação entre as diversas páginas da aplicação.
  
• Construção de formulários que aceitem dados do utilizador.
  
• Criação de vistas para a exposição de informação para o utilizador final.
  
• Fornecer acesso ao processamento dos dados e aos próprios dados através de JavaBeans e Enterprise JavaBeans.
  
• Fornecer acesso às Base de Dados para incorporar informação directamente dos Sistemas de Gestão de Bases de Dados.
  
• Utilização de serviços de directório como o JNDI (Java Naming and Directory Interface) e LDAP (Lightweigth Directory Access Protocol).
  
• Providenciar acesso seguro e não seguro através de mecanismos de autenticação.
  

Exemplos de tais frameworks:

Struts	É um framework open-source do projecto Jakarta. Foi desenhada para o desenvolvimento de aplicações web através da Java Servlet API e JSP. O embrulho providenciado por este framework disponibiliza um conjunto integrado de componentes reutilizávies. Este conjunto inclui um controlador de servlets, uma biblioteca de rótulos JSP específicos e classe utilitárias. Os componentes servem para criar UIs (User Interface) que podem ser aplicadas a qualquer ligação web.
JATO	É um framework para aplicações web baseado nos standards J2EE ajustado para o desenvolvimento de aplicações web empresariais. O JATO combina os conceitos familiares com os projectos frequentemente usados. Os conceitos familiares incluem eventos da aplicação, display fields, hierarquias de componentes.
JavaServer Faces	JavaServer Faces propõe definir um conjunto standard de rótulos JSPs e classes Java. Este conjunto visa simplificar a criação de interfaces gráficas de utilizador (GUIs - graphical user interface) para aplicações web em Java. Para tal a tecnologia JavaServer Faces define complexos forms HTML e outros elementos GUI comuns. Além disso, possibilita que as ferramentas e terceiros (empresas que desenvolvam componentes) se focalizem numa única framework para o desenvolvimento de páginas JSP e servlets. Tem como intenção preencher a lacuna entre os programadores de GUI toolkits convencionais e os programadores de GUIs para a web. Espera fornecer APIs (Application Programming Interface) familiares para os diversos componentes gráficos, para o estado dos componentes e para o processamento de input e de apresentação (rendering). É ainda proposto o suporte compreensivo para a internacionalização e simples validação para dados.

Neste momento ando a estudar algumas tecnologias/arquitecturas para usar como interfaces gráficas e não só.

Diversos componentes que ando a estudar:

• Java Servlet Technology
  
• JavaServer Pages Technology
  
• Java Web Services Developer Pack
  
• Java API for XML Processing
  
• JavaServer Faces
  
• Struts
  
• JATO
  
• Tomcat Java Servlet and JSP container
  

Vivas a todos!
Como o Rui tinha referido houve uma divisão de tarefas.
Eu fiquei com a responsabilidade de estudar frameworks para o apoio ao desenvolvimento de interfaces web.

NOTA: Fiquei entusiasmado com a delegação feita, mas depois de um pouco de investigação verifiquei que afinal tinha um mundo para estudar. lol :).

Depois de experimentar o meu primeiro Entity Bean eis que me surge este problema: Como garantir que um CMP Entity Bean use o identificador gerado pelo SGBD? Afinal de contas no ejbcreate tenho que fazer set à primary key! E agora como faço? A resposta é simples: usa-se uma classe utilitaria que gera identificadores e esquece lá o autonumber do sgbd. (O Pointbase nem suporta!)

Nestes últimos dias tenho andado a experimentar correr um JUnit muito simples, que limita-se a criar um Entity Bean e a testar pesquisar pela chave primária. Conseguir fazer correr a servlet do JUnitEE foi uma "tourada" pois após dica de um colega, apercebi-me que não se pode ter espaços no inicio e fim da descrição de um descritor de deployment.

Depois dessa "tourada" não conseguia nem por nada conseguir fazer com que o meu CMP Entity Bean escrevesse na BD. Hoje finalmente percebi o que se passava. Não posso fazer o mapeamento para o Sun One App Server usando o nome (JNDI) jdbc mas sim para um Persistent Manager. É caso pra dizer que isto é um grande pincel. (perdoem-me a linguagem)

Ate perceber que o problema era com a BD (inicialmente tive a feliz ideia de tentar integrar o SQL Server 2000) levei alguns dias. Após perceber que com o SQL Server não tinha qualquer suporte (razões obvias) optei por usar o Pointbase, que apesar de ser limitado (ainda não percebi muito bem no que, mas é o que a Sun vende) serve para o gasto.

Hoje, finalmente consegui ter os testes a correr a 5 estrelas e a falharem por razões que esperava falhar.

A experimentar fazer testes com o JUnitEE e a pensar no modelo de dados físico (modelo entidade associação).

Ando também a experimentar as diversas relações dos Entity Beans em Container Managed Persistence, baseando-me no livro "Enterprise Entity Beans" da O'reilly. Os Entity Beans que tenho usado já são alguns que muito provavelmente irão ser usados no projecto. Ando a modelar os utilizadores.

Um dado importante: O servidor aplicacional usado.

Eu andei a ver quais os disponiveis e tive em conta dois: JBoss e Sun Application Server 7.

Pessoalmente estou a usar o da Sun porque tem uma integração "directa" com o Sun One Studio. Experimentei o JBoss e gostei também, apesar de sentir que tenho mais controlo usando o SAS7.

Ainda não falei com o Nuno sobre isto, mas parece-me que ele também irá optar pelo da Sun para ambos usarmos o mesmo.

Após algumas conversas, chegamos à conclusão que não é produtivo andarmos os dois (eu e o nuno) a vermos o mesmo problema (camada de dados, serviços de dados) pelo que decidimos dividir tarefas:

- Estudar Entity Beans e ir avançando no modelo/serviços de dados
- Estudar frameworks de apoio ao desenvolvimento de interfaces web, nomeadamente JSFaces e Struts e Session Beans.

Eu (Rui) fiquei encarregue da primeira tarefa, o Nuno da segunda.

A minha opinião é que estamos finalmente a caminhar no sentido mais produtivo, visto que o nuno esta a desenvolver de cima para baixo, e eu de baixo para cima. Logo vamo-nos encontrar. :)

Para testar EJB's (nomeadamente eu com os Entity Beans) vamos usar uma framework chamada JUnit.

O JUnit permite executar uma pilha de testes, definidas por nós e verificar quais os problemas que ocorreram. É uma ajuda bastante útil que complementando com as ferramentas de debugging vão permitir-nos criar ejb's á "prova de fogo"

O JUnitEE é a versão da framework JUnit para testar código de lado servidor.

Como prometido aqui estão os diversos diagramas UML do modelo de dados.

O NetBeans é um projecto opensource, penso que da Sun, e trata-se de um editor Java feito em Java, também bastante extensivel.

O SunOne é o NetBeans mas para o desenvolvimento em J2EE.

Resumindo: O SunOne é a escolha ideal para quem quer desenvolver em J2EE. Permite o controlo total sobre os EJB's existem varios wizards que permitem criar EJB's a partir de sources já existentes, pode-se dar uma tabela numa BD que ele gera logo Entity Beans e permite a alteração dos descritores antes de fazer o deployment.

Para fazer deploy basta um click que este trata de compilar, gerar os JAR's, WAR's e EAR's e coloca-los no servidor aplicacional (J2EE). Muito importante também é o facto de ser possivel fazer debug de EJB's!

É possivel fazer a validação dos EJB's com uma ferramenta incluida, permite controlar o servidor aplicacional (Start, Stop, Deploy, Undeploy, etc) , permite fazer querys a uma qualquer Base de dados com driver JDBC. Enfim é para mim o melhor ambiente disponivel.

Contras:
- É em Java e é bastante pesado
- Não tem uma ferramenta UML mas visto que o Together faz reverse engineering das sources não é grande problema

O Eclipse é um IDE, penso que opensource, da IBM que só por si não faz nada.

Para usar o Eclipse é necessario instalar uma serie de plugins, inclusive para desenvolver em Java.

À partida adorei o Eclipse. Era muito simples, muito flexivel, coisa que os outros não o eram, e permitiam configurar tudo. Tudo mesmo.

Encontrei vários plugins para se desenvolver sobre J2EE mas todos, que tinham wizard's, para desenvolver EJB's usam uma tecnologia chamada XDoclet.

O que é o XDoclet?

Quem já desenvolveu em Java e sabe o que é o JavaDoc pode encontrar logo uma anologia. Assim como o javadoc esta para escrever a documentação de um projecto através de tags no source code, o XDoclet está para desenvolver EJB's através de tags num unico ficheiro.

Todos os plugins que encontrei, usam XDoclet. Eu não gosto de XDoclet porque teria que aprender mais uma "linguagem" para escrever EJB's. Mais, eu gosto de ter controlo sobre o descritor e as interfaces de cada EJB. Com o XDoclet não tenho qualquer controlo sobre as interfaces ou o descritor. Tudo é descrito no Bean.

Não me interpretem mal. O XDoclet é bastante poderoso, e pode tornar o desenvolvimento de EJB's bastante rapido. Mas é necessário aprender primeiro todas as tags (ou pelo menos as principais) para escrever um EJB.

O que eu quero mesmo, é um wizard que me gere o descritor e as interfaces Remotas e Locais e que me permita editar sobre os mesmas. Ate agora só o Together me satisfez parcialmente.

Conclusão: O Eclipse é a escolha ideal para quem vai fazer um projecto em Java. Existem inclusive plugins para UML ao estilo to Together. Infelizmente no que diz respeito a J2EE ou sabes XDoclet ou sabes XDoclet :)

Para muitos colegas meus, é a ferramenta idela para Java. Eu só experimentei fazer um pequeno projecto para me tentar ambientar e não gostei.
Li muito sobre desenvolvimento J2EE sobre o IntelliJ e pareceu-me interessante, mas como também não gostei do ambiente por achar pouco intuitivo não investi muito.

A ferramenta de eleição da Borland, de nada tem a ver com o Together. Não sei se sou só eu, mas não gosto do ambiente. Não é intuitivo, não é facil de se usar e sinceramente não gostei simplesmente.

Não fiz grandes testes sobre desenvolvimento em J2EE pelo que descartei logo esta hipotese.

A ferramenta que mais me agradou, pessoalmente, foi o Together Control Center 6.1 pois permite desenhar EJB's visualmente e é a ferramenta que temos usado ate ao momento para os nossos diagramas UML.
Infelizmente o Together tem os seus contras:
- Não permite a edição dos descritores XML antes de efectuar-se o deploy num servidor
- Não é possivel fazer reverse engineer dos descritores, ou seja só podemos modificar os descritores no together e logo não podemos usar outro editor externo.
- O deploy implica fazer sempre 3 a 4 passos num wizard, e considerando que para testar qualquer coisa é necessario efectuar um deploy no servidor, esta não é uma solução boa.

No entanto, criar EJB's no together é extremamente simples pelo que ele gera o código todo e sabe fazer reverse engineer através das sources dos EJB's. Logo não foi uma solução que pusemos logo de parte. Bastava apenas haver um editor que permitisse fazer edição dos descritores e deploy mais rapidamente.

Quem já programou em Java e C# sabe que existem diferenças entre ambas as linguagens. Mas não é só entre linguagens que as diferenças são relevantes! Enquanto que a Microsoft tem um ambiente de desenvolvimente totalmente integrado (Visual Studio .NET) para o C#, já o Java não é o mesmo. Existem n ambientes de desenvolvimento, uns melhores que os outros (leia-se mais completos) que resolvem mais ou menos o problema de quem desenvolve sobre a plataforma J2EE.

Os últimos 15 dias, têem sido gastos á procura de um ambiente de desenvolvimento que nos permita desenvolver sem nos preocuparmo-nos com determinados pormenores de quem desenvolve em J2EE.

Então tomamos como base de partida para o nosso ambiente de desenvolvimento o seguinte:
- Queremos poder escrever código usando intellisense
- Usar wizards que nos permita desenvolver EJB's rapidamente
- Permita ter acesso a todas as caracteristicas de um EJB, ou seja editar o descritor XML atraves do editor
- Visualizar e editar os vários descritores XML
- Fazer deploy sobre o servidor rapidamente
- Fazer debug dos nossos EJB's.
- Usar uma ferramenta, preferencialmente integrada no ambiente, de UML q permita desenhar EJB's.

Experimentamos todas as ferramentas que existem no mercado, ou seja as seguintes:
- IntelliJ
- JBuilder
- Together Control Center 6.1
- Eclipse com diversos plugins para J2EE e UML
- NetBeans / SunOne Studio

Nos últimos dois meses, Dezembro e Janeiro, temos andado a desenhar o modelo de dados que irá dar suporte ao SIR.

Já temos algo bastante consistente, e após uma reunião com os nosso coordenadores ajustamos os últimos pormenores.

Dentro em breve colocaremos os diagramas UML online para o modelo de dados do SIR.

O proximo passo será desenhar os Entity Beans que representam o nosso serviço de dados.

Já lá vão dois meses desde o último post e muita coisa aconteceu entretanto!

Ficou decidido que vamos usar a plataforma J2EE para o SIR!

Porquê? Porque quando aprendemos o que era o J2EE na disciplina de Arquitectura de Sistemas Distríbuidos descobrimos que esta assenta que nem uma luva no nosso projecto.

O J2EE é uma especificação, que define uma plataforma aplicacional que disponibiliza sete serviços primários:
- Transacional
- Concorrencia
- Segurança
- Persistencia
- Distribuição
- Nomes e Directorias
- Mensages Assíncronas

Existem varios vendedores (vendors) de servidores aplicacionais como a Oracle, Sun, IBM, etc.

Para quem quiser saber mais sobre o que é o J2EE (Java 2 Enterprise Edition) consulte o seguinte link

Há duas semanas realizou-se mais uma reunião com os orientadores do projecto.
Sem dúvida que essa reunião foi a mais importante até ao momento.
Discutimos o enunciado do projecto, que contém (algo de que eu não tinha ideia da importância) a análise de requisitos, no que se refere às entidades e termos.
Da observação efectuada ao relatório apresentado foi-nos, de novo, chamada a atenção para a clareza. Também se discutiu os requisitos que são essenciais para o funcionamento básico do sistema.
A grande surpresa da reunião foi a divulgação da possível utilização da arquitectura J2EE para suporte do projecto. A outra opção será a arquitectura .NET.

Nesta reunião foi avaliada a análise de requisitos realizada.
Definiram-se algumas metas para continuar o projecto, como é o caso de definir um diagrama de classes que correspondesse à interacção das entidades presentes no sistema, bem como as representasse (as entidades).
Foi-nos chamada a atenção para a clareza da exposição do conteúdo. Ou seja, a informação produzida sofre de umas lacunas no que se refere à clareza.