lundi 1 octobre 2007

Exemplo de uso de EJB

Vamos criar neste exemplo um simples componente que converte um valor em dólares para reais.Para realizar o exemplo, utilizamos NetBeans versão 6.0 e Sun Java System Application Srever 9.0. Supomos que para seguir esse exemplo, você possua conhecimento de Java e esteja habituado ao uso do NetBeans.

Após certifica-se que o NetBeans esta configurado junto com o servidor . Crie um novo projeto no NetBeans e selecione Enterprise e depois EJBModule. Coloque o nome de EJBModuleConversor e escolha o servido do J2EE como servidor de aplicação.

Após a criação do projeto, clique com o botão direito sobre o projeto EJBModuleConversor e selecione New->SessionBean. Coloque o nome de Conversor e selecione interface Remote. Atribua um nome ao pacote (conversor) e selecione finish. Duas classes foram geradas para implementar o seu SessionBean: ConversorRemote e ConversorBean.

A classe ConversorRemote possui a anotação @Remote para indicar que ela representa a interface remota do componente. Nesta interface, devem ser declarados os métodos a serem implementados pelo SessionBean (i.e., ConversorBean) e que serão acessíveis através do contêiner. Após a geração a classe ConversorRemote contém o seguinte código:

package conversor;

import javax.ejb.Remote;

/**

* This is the business interface for Conversor enterprise bean.

*/

@Remote

public interface ConversorRemote {

}

Vamos alterar esse código adicionado a descrição de um “serviço” de conversão de moedas. O método calcularConversão:

@Remote

public interface ConversorRemote {

public double calcularConversao(double d);

}


Altere o código da classe ConversorBean para que ele implemente o método de conversão e exporte o componente com o nome de ejb/Conversor. No fim, ele deve ficar assim:

package conversor;

import javax.ejb.Stateless;

@Stateless (mappedName="ejb/ConversorDeMoedas")

public class ConversorBean implements conversor.ConversorRemote {

/** Creates a new instance of ConversorBean */

private double tax;

public ConversorBean() {

tax=1.8;

}

public double calcularConversao(double d) {

return d*tax;

}}

Esse código indica que o componente é do tipo Stateless SessioBean e que ele pode ser localizado através do nome ejb/Conversor. Compile o projeto e instale no servidor Sun Java Application Server. Para realizar esta tarefa, clique com o botão direito sobre o projeto e selecione Deploy. As ultimas linhas do console do Sun Java Application Server devem ser:

**RemoteBusinessJndiName: ejb/ConversorDeMoedas; remoteBusIntf: conversor.ConversorRemote

LDR5010: All ejb(s) of [EJBModuleConversor] loaded successfully!


Agora vamos criar um cliente para este componente. Crie um novo projeto e selecione Enterprise Aplication Client. Coloque o nome de ConversorDeMoedasCliente. Selecione com o botão direito as propriedades do novo projeto (Properties). Selecione Libraries e depois clique em Add Jar/Folder. Navegue até a pasta onde se encontrar o .jar do componente Conversor (EJBModuleConversor.jar). Após a criação do projeto e da configuração dos imports, modifica o método main da classe Main até obter o seguinte código:


public static void main(String[] args) {

InitialContext ctxt;

try {

ctxt=new InitialContext();

ConversorRemote clienteCR=(ConversorRemote)ctxt.lookup("ejb/ConversorDeMoedas");

System.out.println("#########################");

System.out.println("10 dolares equivalem à "+clienteCR.calcularConversao(10)+" reais ");

System.out.println("#########################");

} catch (NamingException ex) {

ex.printStackTrace();

}}


Aceite os imports necessários e compile a aplicação. Execute o cliente (Run Project) e você deve obter o seguinte resultado:

#########################

10 dólares equivalem à 18.0 reais

#########################


Pequena explicação

O cliente acessa o componente através do contêiner. Para isso, uma instância da classe InitialContext é usada. O método lookup é invocado com o nome publicado pelo componente servidor (i.e.,“ejb/ConversorDeMoedas”). Uma referência do objeto é repassada pelo contêiner ao objeto clienteCR. Esta referência permite o acesso ao método remoto calcularConversao.

Enterprise Java Beans

Enterprise Java Beans é uma arquitetura de componentes Java para o desenvolvimento e implantação (deployment) de aplicações distribuídas. Um componente EJB possui como principais características a portabilidade e a escalabilidade. Ele pode ser escrito uma única vez e ser executado em diferentes plataformas (i.e., sistemas operacionais) através dos contêiners EJB ( e.g., J2EE Web Server, JBoss). Um contêiner, por sua vez, gerencia os aspectos não-funcionais de uma aplicação comercial (enterprise application): controle de transações, segurança, persistência, distribuição de carga e gestão do ciclo de vida. Essas características do contêiner permitem ao desenvolvedor se concentrar nas funcionalidades da sua aplicação, em especial, nos aspectos ligados a camada de negócio do sistema de informação.

O contêiner EJB fornece funções para o controle do ciclo de vida de um componente, como, por exemplo: implantação, ativação, desativação e desinstalação de um componente EJB. Além disso, a comunicação entre um componente EJB e “o mundo externo” ao componente é realizado através de interfaces controladas pelo contêiner.


Modelo de Componente EJB

Um Enterprise Java Bean é um componente caixa-preta distribuível (distributed black-box component) que executa em um contêiner EJB. Um componente EJB fornece seus “serviços” ou métodos através de interfaces. Os clientes de um EJB utilizam o componente desconhecendo os detalhes de como os métodos deste são implementados. Por exemplo, em um acesso remoto, um cliente de um componente requisita ao contêiner EJB o acesso à interface remota do componente provedor do serviço. O contêiner cria uma instância do componente requisitado e intercepta todas as “mensagens” entre o cliente e o componente provedor do serviço. Esta indireção é que permite ao contêiner controlar o ciclo de vida de um componente e realizar as operações não funcionais descritas anteriormente

O modelo de componente EJB suporta basicamente os seguintes tipos de enterprise beans:

  • Stateless SessionBeans. Os Beans de sessão são idealizados para realizar a comunicação entre a camada de interface com usuário e a camada de negócio de um sistema. Os beans de sessão sem estado (sem memória) são instanciados uma única vez pelo contêiner e são compartilhados por todas os clientes do componente. Assim, eles devem ser usados como “bibliotecas de funções” que recebem toda a informação necessária para sua execução através de seus parâmetros. São exemplos de Stateless Session Beans: uma classe para checar se usuário está logado e uma classe que fornece um conversor de moedas.

  • Stateful SessionBeans. Para esse tipo de Bean de sessão, o contêiner criará uma instância para cada cliente. Desta forma, um Stateful Bean pode conter variáveis e objetos que guardem/acumulem informação sobre a sessão de comunicação entre cada cliente e o “provedor” do serviço. Um exemplo simples que ilustra o uso de Stateful Bean é o « carrinho de compras » de um site de vendas. Cada sessão (e.g., cada navegador de um usuário) conterá sua própria instância do carrinho e este acumulará as compras de cada usuário durante toda a duração da sessão.

  • EJB Web Services Components. Componentes EJB à serem transformados em Web Services (Stateless beans neste caso).

  • Bean Managed Persistence (BMP) entity beans. Uma das principais funções de sistemas de informações é a manipulação de dados. Os entity beans foram conceptualizadas para facilitar a escrita de código que manipula informação à ser persistida/acessada em/de um banco de dados relacional. No caso dos BMP entity beans, o código de persistência esta contido no próprio entity bean. Assim, o desenvolver escreve o código de persistência que mapeia o objeto em uma ou mais tuplas de uma base relacional.

  • Container Managed Persistence (CMP) entity beans. Um contêiner EJB pode gerenciar ele mesmo a persistência de objetos. Neste caso, os entity beans a serem mapeados automaticamente pelo contêiner em uma base de dados são chamados de CMP entity beans.

Modelo de Conexão/Comunicação de componente EJB (“glue code” or Connection Model)

Os componentes EJB se conectam através de suas interfaces remota e local. No caso de uma comunicação remota, o componente utiliza RMI para concretizar a passagem de mensagens entre os componentes. Durante a invocação de um método, os parâmetros e o resultado da função são serializados e passados por valor entre os componentes.

Para obter acesso a um serviço de um componente, o cliente utiliza os métodos lookup do contêiner e informa o nome do serviço que deseja acessar (i.e., o nome da interface publicada pelo componente). O contêiner, por sua vez, acessa a JNDI (Java Name Directory Interface) para obter acesso ao componente provedor do serviço. O uso da JNDI garante a independência de localização, característica desejável em sistema distribuídos para facilitar a integração entre sistemas.

  • A interface remota de um componente EJB pode ser acessada de dois modos:

  • Síncrono (Tight Coupling Synchronous Connection). O cliente do componente envia uma requisição ao contêiner para obter acesso a uma determinada interface. Após o acesso concedido, o cliente invoca o método desejado e resta em estado de bloqueio até o obter o resultado do método remoto. Assim, a aplicação cliente resta bloqueada até que o componente remoto termine a execução do serviço requisitado.

  • Assíncrono (Loosely Coupled Asynchronous Communication). Este modo de comunicação permite uma melhor vazão (throughput) do sistema. Um componente cliente em modo assíncrono requisita um serviço através de uma fila de mensagens JMS (Java Message Service). Desta forma, o contêiner notificará ao cliente quando sua requisição estiver sido processada. Assim, o cliente não precisa continuar bloqueado em quanto o serviço remoto é executado.


Modelo de Implantação do EJB (Deployment Model)

Os componentes EJB, assim como os Java Beans, podem ser distribuídos em arquivos .jar. Para sua execução, ele são encapsualdos em .ear ( J2EE application file). Na versão EJB 2.*, um componente contém um arquivo XML de descrição de suas interfaces (Deployment Descriptor-DD). Na versão EJB 3.*, toda a descrição do componente esta contida em seu próprio código Java. Anotações, isto é meta-dados, descrevem o tipo de componente, seu nome de mapeamento e quais são suas interfaces remotas.

Uso de anotação na versão 3.0 facilita a construção de componentes EJB e diminui sensivelmente o número de arquivos de configuração de um sistema baseado em EJB.

Principais Vantagens e Desvantagens de EJB

Vantagens

+ Portabilidade dos componentes entre plataformas ( e.g;, entre sistemas operacionais)

+ Suporte a distribuição

+ Gestão do ciclo de vida de um componente pelo contêiner

Desvantagens

- Um componente EJB é dependente de uma linguagem de programação. Ou seja, somente pode ser acessado normalmente por clientes escritos em JAVA. Esta uma das desvantagens se compararmos EJB com CORBA e Web Services.

- A extensa configuração é facilmente passível de erro. O uso de anotações da versão 3.0 combinado com as novas IDEs de desenvolvimento Java ( NeteBEans 6.0 e Eclipse) facilitam.

- A reconfiguração dinâmica não é suportada nativamente pelos contêiners, mas pode ser realizada usando alguns procedimentos adicionais.


POC / COP

Uma das partes principais da minha tese é relacionada a proposição de um modelo de componentes sensível ao contexto que possa ser aplicado para o desenvolvimento de sistemas pervasivos. Para construir esta proposição, eu realizei alguns estudos sobre modelos de componentes existentes. Então irei compartilhar neste blog alguns resumos sobre as tecnologias e os modelos de componentes que estudei. Esses resumos são rascunhos em português de minhas anotações e contém minha opinião pessoal em algumas avaliações. O primeiro POST é sobre Enterprise Java Beans e contém alguns codigos exemplos.

Motivação do Blog

Este blog não é um blog de sexo, onde podemos encontrar fotos da Britney Spears, Paris Hilton, Barbara Paz nuas... Muitos menos, ver vídeos polêmicos do youtube com Cicarelli e afins. A idéia deste blog é que eu possa compartilhar e divulgar meus trabalhos e artigos científicos.

Alguns posts serão em inglês e francês dependendo do avanço do meu trabalho de pesquisa.

Outros posts irão ilustrar rascunhos dos meus estudos durante a minha tese e podem ser de alguma forma importantes para alguém que esteja iniciando em programação para componentes, nos sistemas sensíveis ao contexto ou na anotação semântica de multimídias.

vendredi 7 septembre 2007

Adaptation de services pervasifs et sensibles au contexte

short paper
poster

Le développement de systèmes pervasifs et sensibles au contexte est une thématique récurrente dans les projets de recherche actuels dans le domaine de l’informatique ambiante (Ricquebourg et al., 2006) et des applications mobiles, comme par exemple, les guides de tourisme (Schwinger et al., 2006). Malgré ces progrès rapides, de nombreux défis scientifiques et techniques subsistent qui doivent être relevés afin de permettre la mise à disposition des services pervasifs aux utilisateurs nomades. Parmi ces défis, nous pouvons citer: (1) la difficulté de capturer le contexte d’utilisation en situation réelle, sans dégrader la performance et les ressources du système (telles que la batterie des capteurs, le réseau), (2) la faible exploitation des informations de haut niveau (la connaissance) sur le contexte, et (3) le manque de méthodes permettrant d’adapter le comportement de services à l’hétérogénéité des dispositifs mobiles (DM) et à l’évolution du contexte du système. Afin que les services pervasifs soient d’avantage opérationnels, nous proposons une infrastructure logicielle répartie dotée de fonctionnalités d’acquisition, de gestion et de diffusion d’informations contextuelles et capable d’aider le concepteur à gérer et adapter l’exécution des services du système.


Reference:
Windson Viana. Adaptation de services pervasifs et sensibles au contexte. Forum Jeunes Chercheurs . Inforsid 2007

PhotoMap: annotations spatio-temporelles automatiques de photos personnelles pour les utilisateurs nomades

draft PDF

L’augmentation croissante de la quantité de photos numériques personnelles rend
les processus d’organisation, de recherche et de visualisation de plus en plus difficiles. Les outils d’annotation manuels existants demandent trop de temps disponible des utilisateurs pour effectuer l’annotation. L’annotation automatique de photos à l’aide de dispositifs mobile est donc la solution émergeante pour faciliter la gestion d’images personnelles. Cet article propose un système, appelé PhotoMap, pour l’annotation automatique et pour la visualisation spatio-temporelles de collections de photos prises par un utilisateur nomade. PhotoMap utilise des nouvelles technologies du Web Sémantique pour inférer des informations sur les photos et améliorer les processus de visualisation et de consultation futures. Cet article présente une démonstration d'utilisation de l'application PhotoMap lors d’une promenade touristique réalisée à Grenoble.

Reference:
Windson Viana, José Bringel, Jérôme Gensel, Marlène Villanova Oliver, Hervé Martin. PhotoMap: annotations spatio-temporelles automatiques de photos personnelles pour les utilisateurs nomades.Actes de la Conférence Québéco-Française pour le Développement de la Géomatique (CQFD-Géo). Juin 2007, Clermont-Ferrand.


XMobile: a MB-UID environment for semi-automatic generation of adaptive applications for mobile devices

draft PDF


Ubiquitous Computing promises seamless access to information anytime, anywhere with different and heterogeneous devices. This kind of environment imposes new challenges to software development. For example, information and user interface should be adapted according to contextual characteristics such as user, environment, and access device. In case of device adaptation, the development challenge is related to the heterogeneity of the devices, which requires software engineers to create different versions for each type of device and every platform. This paper proposes a MB-UID (Model-Based User Interface Development) approach for semi-automatic generation of adaptive applications for mobile devices. An environment, called XMobile, offers a device-independent user interface framework and a code generation tool for providing fast development of multi-platform and adaptive applications according to device and platform features. A case study is also presented to illustrate how the environment can be used for constructing an application for heterogeneous devices with different network connectivity modes.

Reference:
Windson Viana, Rossana Andrade. XMobile: a MB-UID environment for semi-automatic generation of adaptive applications for mobile devices. Journal of Systems and Software. 2007