Instalar RMI como serviço e configurar porta?

Programação Java
#1

Hello everybody!!

depois de tempos de ferias de java, eis-me aqui novamente.

bem, estou instalando um programa (servidor) para gerenciamento de projetos desenvolvido em Java (WebApsee, vou começar a utilizar agora, mas parece ser muito bom). Esse programa utiliza o RMI para fazer a comunicação cliente-servidor. Entao, preciso configurar, durante a instalação, o numero da porta de RMI e socket do meu servidor.

O problema:

como eu instalo o RMI no meu servidor como um serviço, de forma que eu consiga obter o numero da porta que ta usando??

:?: :?:

#2

Olá

Dei uma olhada no material deste software paraense e minha impressão é de que é um gerenciador de processos waterfall do tipo bem burocratizado e bem do jeito que as práticas do CMMI adoram. Se realmente for assim, meu melhor conselho para você, dado do fundo do meu coração e diante dos meus 40 anos de experiência no desenvolvimento e no fracasso no desenvolvimento de softwares, é que não perca tempo com isto e concentre seu tempo para aprender SCRUM, LEAN e todas as práticas ágeis que tem muito mais chance de conduzir um projeto de software a algo minimamente funcionável dentro do prazo.

E se o software usa RMI para fazer as conexões, já de cara leva uma nota baixa por mau uso da tecnologia Java. Não é que RMI não funcione. É que há outras alternativas melhores e menos dependentes de aberturas de portas esdrúxulas.

Mas pela documentação o software parece que usa web services. Então sugiro que pergunte a alguém lá do Pará se é RMI ou web service.

Links que eu consultei e que levaram a concluir que este software é um gerenciador de processos waterfall:
http://www2.ufpa.br/cdesouza/teaching/es/WebAPSEE_Telas_UsuarioFinal.pdf
http://www.mct.gov.br/upd_blob/0014/14602.pdf
http://www.mct.gov.br/upd_blob/0019/19592.pdf
http://www.labes.ufpa.br/webapsee/17232.pdf
http://labes.ufpa.br:8080/labes/MostraConteudo.php?idConteudo=73 (aqui fala em web services)

[]s
Luca

#3

uau… obrigada Luca, vou dar uma olhada nesta documentação. :wink:

Mas nosso objetivo realmente é fazer um controle do desenvolvimento do projeto, me pareceu boa a ferramenta em si, mas waterfall nao necessariamente precisa ser a nossa filosofia, mesmo se a ferramenta for adotada, ne.

Mas ainda gostaria de saber: como posso fazer isso?
como instalo o RMI no meu servidor como um serviço, de forma que eu consiga obter o numero da porta que ta usando??
:?: :?: :?:

#4

vc pode acessar tb a lista dos usuários do WebAPSEE: http://groups.google.com.br/group/webapsee-usuarios

#5

Olá Ticianne,

Na instalação do WebAPSEE ele lhe dá a opção de instalar um servidor (Server) e dois clientes (Manager Console e Task Agenda).
Este servidor dele já possui serviços em RMI e ele já inicia um RMI Registry.

Na verdade, o que ele pede é a porta que você deseja que estes serviços estejam disponíveis. As quais já possuem valores default (5001).
Você não precisa “instalar” o RMI, para isso basta que o a Máquina Virtual Java esteja instalada.

Após a instalação, você roda a aplicação do servidor que ele já iniciará os serviços RMI e o Registry…
Isso é transparente ao usuário.

A opção de alterar o número da porta só se aplica se a default (5001) já está sendo utilizada,
ou caso seja bloqueada por firewall.

Não sei se isso responde seu problema…qualquer coisa pode entrar em contato com a equipe do projeto em:

webapsee-usuarios@googlegroups.com (corrigido)

Quanto aos comentários do Luca, o WebAPSEE permite que você defina seus próprios processos, através de um editor gráfico.
Não necessariamente só o cascata…mas pode definir qualquer modelos de processo, inclusive iterativos (através de conexões de feedback, por exemplo)
ou o próprio XP. Isso pode ser feito definindo quais as atividades do seu processo, os artefatos produzidos e recursos e pessoas envolvidas.

Ele tem um apoio a alguns resultados do MPS.BR e CMMI sim. Entretanto, o ambiente é flexível ao ponto de escolher usar certas funcionalidades
ou não. Isso é o caso da Execução Automatizada, Cadastro de Métricas e Estimativas, Integração com CVS, entre outras.

Não diria que é um ambiente burocrático, mas se deseja que todas as informações da sua organização e de seus processos estejam armazenados no
ambiente, claro que o volume de informações é grande e pode exigir um certo esforço inicial para cadastro de algumas informações. E mais,
esse cadastro possa ser realizado conforme for ganhando experiência na utilização, inclusive durante uma execução de um processo.

A escolha por RMI deu-se em função da grande complexidade que envolve um PSEE (classificação do tipo de ferramenta a qual o WebAPSEE está inserido).
Muitos serviços complexos e frequentes são exigidos, o que em outras tecnologias prejudicavam o desempenho. Quanto á versão com webservices,
alguns serviços são disponibilizados via webservice. Entretanto, não foi disponibilizado no último release devido ao aumento significativo do número
de novos serviços que foram implementados somente em RMI.

E em resumo, as referências citadas possuem no máximo exemplos de modelos de processo, não mostram todas as funcionalidades do ambiente.
Para isso, sugiro consultar ou o documento de referência ou o manual do usuário em www.webapsee.com.

Atenciosamente.

#6

Olá

Breno

Obrigado pelas explicações. Folgo em saber que estava errado ao avaliar o software como uma ferramenta para o desenvolvimento em cascata do tipo que se fazia no início da década de 90. E fico feliz também ao saber que ele pode servir para desenvolvimento ágil que acredito ter muito mais chances de se chegar a um projeto de sucesso do que as antigas metodologias extremamente burocráticas e com grande histórico de projetos estourando prazos e orçamentos.

Mas de modo nenhum posso concordar com o uso pesado de RMI em algum projeto desenvolvido neste século. Continuo achando que RMI serve apenas para casos isolados e o único que eu sempre lembro é o de acesso por JMX para monitoração e gerenciamento de processos do sistema.

[]s
Luca

#7

Luca,

Só pra frisar que não estou defendendo o uso de nenhuma tecnologia.
No início do desenvolvimento do WebAPSEE (2004, neste século ainda =P), as tecnologias que hoje
amadureceram bastante não eram tão fáceis de usar e suporte a tráfego de binários e serviços como
data pushing não funcionavam eficientemente…isso inclui a tecnologia de webservices!

Hoje em dia, tem-se uma preocupação muito grande com o uso do RMI no WebAPSEE.
Entretanto, o ambiente possui, hoje, mais de 150 mil linhas de códigos. O esforço para
migrar toda infra-estrutura RMI para outra tecnologia é muito grande e deve ser pensada
cuidadosamente, por mais que a arquitetura possua baixo nível de acoplamento.

Ahh…o LABES (UFPA) aceita colaboradores sim. Afinal, é um projeto opensource =P

Atenciosamente.

#8

Boa noite à todos.

Luca, aproveitando o gancho deste tópico gostaria de colocar algumas questões.
Há algum tempo tenho visto alguns tópicos em que vc comenta e vejo que defende explicitamente o não uso do RMI.
Declaro não ser um extremo conhecedor da tecnologia, até porque tive alguns problemas quando a transmissão de dados era muito grande (dá um erro, inclusive criei um tópico para tal).
Atualmente, não vejo uma solução de integração Java/Java que funcione de maneira mais rápida que o RMI. Talvez algumas tecnologias como o WebService funcionem bem,
utilizem portas padrões e possam ser integradas com outras tecnologias mas para quem quer fazer apenas uma aplicação “distribuída”* talvez seja um tanto lenta.
Digo no caso de colocar um ERP inteiro em um WebService. Quando a concorrência fica grande, ele não pede água por causa do alto índice de I/O?
O problema com o RMI é apenas a questão da porta? É com a questão de integração com sistemas de outras tecnologias ou de outras empresas? Porque eu o vejo funcionando como uma aplicação via rede (local ou internet) como um WebService.
Estou redondamente enganado? Se sim, pq? Então o que pode me trazer a velocidade do RMI com a praticidade do WebService?

Obrigado.

*O distribuída aí é só porque tem uma aplicação entre o cliente e o banco. Mas acho que o conceito vai muito mais além.

#9

Olá

O velho e bom servlet. O servidor de aplicação pode inclusive funcionar embutido. É fácil fazer isto com o Jetty, com o tomcat e recentemente li que o Glassfish também pode funcionar embutido. Google por “tomcat 6 embedded” ou “glassfish embedded”

As mensagens vão do jeito que quiser, inclusive encriptadas se precisar. Só quanto a questão do Data Pushing é que precisa um pouco de esperteza e prática na integração de aplicações possivelmente com o uso de sondas.

Uma outra alternativa é o uso de JMS mas aí já precisa de um servidor que não pode ser embutido. Mas muitas vezes já existe um JBoss ou um Glassfish no projeto e usar JMS é bem fácil. Neste caso o uso do Apache Camel pode ser bem interessante.

Web services tem a sua serventia mas no seu caso não vejo nenhuma a menos do que for acessado por outros sistemas.

Como costumo dizer, RMI foi a resposta da Sun à arquitetura DNA da Microsoft que usava COM e DCOM. Mas isto era no milênio passado.

Concordo que RMI é muito fácil de usar. Este é o motivo por ser tão usado. Mas raramente é bem usado. As pessoas esquecem as drogas que eram o EJBs < 3.0 com as interfaces remotas que usavam RMI por debaixo dos panos.

[]s
Luca

#10

só corrigindo,

o email da lista é: webapsee-usuarios@googlegroups.com

Att.

#11

[quote=Luca]Olá

O velho e bom servlet. O servidor de aplicação pode inclusive funcionar embutido. É fácil fazer isto com o Jetty, com o tomcat e recentemente li que o Glassfish também pode funcionar embutido. Google por “tomcat 6 embedded” ou “glassfish embedded”

As mensagens vão do jeito que quiser, inclusive encriptadas se precisar. Só quanto a questão do Data Pushing é que precisa um pouco de esperteza e prática na integração de aplicações possivelmente com o uso de sondas.

Uma outra alternativa é o uso de JMS mas aí já precisa de um servidor que não pode ser embutido. Mas muitas vezes já existe um JBoss ou um Glassfish no projeto e usar JMS é bem fácil. Neste caso o uso do Apache Camel pode ser bem interessante.

Web services tem a sua serventia mas no seu caso não vejo nenhuma a menos do que for acessado por outros sistemas.

Como costumo dizer, RMI foi a resposta da Sun à arquitetura DNA da Microsoft que usava COM e DCOM. Mas isto era no milênio passado.

Concordo que RMI é muito fácil de usar. Este é o motivo por ser tão usado. Mas raramente é bem usado. As pessoas esquecem as drogas que eram o EJBs < 3.0 com as interfaces remotas que usavam RMI por debaixo dos panos.

[]s
Luca[/quote]

Ok, Luca. Servlets são legais, apesar de ter que colocar mais código que o RMI. É uma opção.
Mas, fazendo alguns testes com o Servlet eu tive o mesmo problema que tive com o RMI.

Ao enviar 100.000 instâncias (serializadas) de um objeto simples, ele se comportou bem.
Mas ao enviar 1.000.000 dá erro.
O problema não é a memória.

Eis a humilde classe de testes

public class Teste implements Serializable{ public int id; public String nome; }

Como fazer para transmitir uma grande massa de informações por servlet?
Confesso que dá saudade do cliente/servidor.

#12

Olá

Do mesmo modo como baixei o ISO do Ubuntu ou do Suse (4,7GB) usando HTTP. Há algo estranho na sua dificuldade e daqui fica difícil advinhar.

[]s
Luca

#13

[quote=Luca]Olá

Do mesmo modo como baixei o ISO do Ubuntu ou do Suse (4,7GB) usando HTTP. Há algo estranho na sua dificuldade e daqui fica difícil advinhar.

[]s
Luca[/quote]

Servidor

[code] protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
ObjectInputStream in = new ObjectInputStream(request.getInputStream());
ObjectOutputStream out = null;

        try {   
            // lendo da entrada   
            Object inObj = in.readUnshared(); // objeto enviado da entrada                     
            Object outObj = null; // objeto que sera enviado a saida   

            int qtd = 1000000;
            WebEstado[] estados = new WebEstado[qtd];
            for (int i = 0; i < qtd; i++){
                estados[i] = new WebEstado();
                estados[i].estadoId = Integer.toString(i);
                estados[i].nome = "X" + i;
            }
            
            outObj = estados;

            // escrevendo na saída   
            out = new ObjectOutputStream(response.getOutputStream());   
            out.writeUnshared(outObj);             
        } catch (Exception e) {   
            e.printStackTrace();   
        } finally {   
            in.close();   
            out.flush();               
            out.close();   
        }   
}[/code]

Cliente

[code] public static void main(String[] args) {
String urlName = “http://localhost:8084/TesteServlet/TesteEstado”;
Object inObj = “input”; // objeto enviado da entrada
Object outObj = null; // objeto que sera enviado a saida
outObj = processar(null, urlName); // faz a coisa
if (outObj == null) {
System.out.println(“nulo???”);
} else {
WebEstado[] estados = (WebEstado[]) outObj;
for (int i = 0; i < estados.length; i++) {
System.out.println(estados[i].estadoId);
}
}
}

public static Object processar(Object inObj, String urlName) {
    Object outObj = null; // objeto que sera enviado a saida

    try {
        URL url = new URL(urlName);
        HttpURLConnection connection = (HttpURLConnection) url.openConnection();
        connection.setDoOutput(true);

        ObjectOutputStream out = new ObjectOutputStream(connection.getOutputStream());
        out.writeUnshared(inObj);
        out.flush();
        out.close();

        byte buffer[] = new byte[1024];
        ByteArrayOutputStream byteOutput = new ByteArrayOutputStream();

        int size = connection.getInputStream().read(buffer);

        while (size > 0) {
            byteOutput.write(buffer, 0, size);
            size = connection.getInputStream().read(buffer);
        }

        connection.getInputStream().close();
        connection.disconnect();

        ByteArrayInputStream byteIn = new ByteArrayInputStream(byteOutput.toByteArray());
        ObjectInputStream in = new ObjectInputStream(byteIn);

        outObj = in.readUnshared();
        byteOutput.close();
        byteOutput.flush();
        byteIn.close();
        in.close();
    } catch (Exception e) {
        e.printStackTrace();
    }

    return outObj;
}[/code]
#14

Desculpe. Esse negócio de ficar analisando código dos outros como quem diz “resolve pra mim” é realmente chato.
Vou dar uma pesquisada. Devo estar fazendo alguma coisa errada.

Muito obrigado.

Inté.

#15

Olá

Nem olhei o código direito mas GET não pode ter este tamanhão.

[]s
Luca

#16

[quote=Luca]Olá

Nem olhei o código direito mas GET não pode ter este tamanhão.

[]s
Luca[/quote]

Pois é. É que a gente fica tentando de várias maneiras (haja pesquisa no Google).
No final eram apenas os parâmetros de memória do TomCat. Tosco né?
Como eu sempre digo: os piores erros são os mais simples.

Inté.

#17

Olá

[quote=marciosantri]No final eram apenas os parâmetros de memória do TomCat. Tosco né?
Como eu sempre digo: os piores erros são os mais simples.[/quote]

Nananinanão…

Agora você precisa dizer o que fez nos parâmetros do Tomcat e se usou GET ou POST.

[]s
Luca

#18

[quote=Luca]Olá

[quote=marciosantri]No final eram apenas os parâmetros de memória do TomCat. Tosco né?
Como eu sempre digo: os piores erros são os mais simples.[/quote]

Nananinanão…

Agora você precisa dizer o que fez nos parâmetros do Tomcat e se usou GET ou POST.

[]s
Luca[/quote]

O código é o mesmo que eu já tinha postado, afinal de contas, mesmo grande ele estava funcionando.
No TomCat, apenas modifiquei os parâmetros -Xms512m -Xmx1024m.

#19

Vc conseguiu resolver Marcio? Fiquei curioso em saber de qual erro se tratava.

#20

Hum… Neste tópico eu estava falando sobre servlets mas o caso era o mesmo do rmi.

Criar uma classe muito simples com apenas um atributo do tipo String. Depois criar 1.000.000 de instâncias desta classe e mandar pela rede (ou via servlet ou via rmi). Nos dois casos estava dando erro. Mas depois descobri que era só aumentar o parâmetro de memória ao abrir a aplicação servidora que resolveu (ao abrir o servidor rmi utilizei os parâmetros -Xms512m -Xmx1024m).

A geração dos objetos foi rápida mas a memória alocada é muito grande. Tenho receio do uso de qualquer um dos tipos para relatórios muito grandes. Neste ponto eu tenho saudades do Delphi (ou C#), com o super leve tipo “record”. Acho até que o Java poderia ter um desses para quando se tratar apenas de parâmetros de comunicação melhores estruturados. Afinal de contas, alocar 1.000.000 de registros de uma só vez é bem mais rápido e menos oneroso que alocar 1.000.000 de instâncias (uma a uma). Mas sobre isto eu já perdi as esperanças.

Eu estou fazendo uns testes com o rmi. Não querendo contrariar o Luca, cuja opinião eu respeito muito, mas no meu caso eu não vejo diferença entre jogar o rmi na porta 80 ou utilizar o HttpService. Achei o rmi melhor estruturado por causa do uso da mesma interface dos dois lados (nomes dos métodos, parâmetros, etc). Mas uma coisa eu tenho que concordar com ele: projetar para rmi não é tão transparente quanto projetar para um HttpService. Se você não tomar cuidado, as conexões e objetos poderão ser mal gerenciados. Isto um TomCat da vida faz meio que automaticamente. Resumindo: acho que rmi não é pra qualquer um.

Inté.