Loading ...
Sorry, an error occurred while loading the content.

RES: [riojug] Dúvida de implementação

Expand Messages
  • Leonardo Lima
    ... Já tinha pensado nesta idéia da camada, Ou seja essa camada ficaria no servidor correto ? Como eu faria isso? Essa é a grande dúvida rsrsrsrs Obrigado
    Message 1 of 12 , Oct 5, 2005
    • 0 Attachment

      > O jeito mais simples, creio, é criar uma camada entre seus clientes e

      > a persistência. Para atualizar algo, seus
      clientes entram em contato
      > com essa camada, que envia uma mensagem aos
      outros clientes sobre o
      > fato.

       

      Já tinha pensado nesta idéia da camada,

      Ou seja essa camada ficaria no servidor correto ?

       

      Como eu faria isso?

      Essa é a grande dúvida rsrsrsrs

       

      Obrigado

       

      -----Mensagem original-----
      De: riojug@yahoogroups.com [mailto:riojug@yahoogroups.com] Em nome de Phillip Calçado
      Enviada em: quarta-feira, 5 de outubro de 2005 17:42
      Para: riojug@yahoogroups.com
      Assunto: Re: [riojug] Dúvida de implementação

       

      Oi,

      On 10/4/05, Carlos Angelim <cangelim@...> wrote:
      > O hibernate já está cuidando disso pra vc, desde que, claro, o objeto
      > que vc estiver consultando/editando esteja acoplado a sessão do hibernate.

      Mas como fazer isso num sistema distribuído com essas características?

      Leonardo, primeiro vamos tentar pensar em objetos, não no banco de
      dados (que só é onde os objetos são salvos).

      Se você tem objetos independentes nas máquinas clientes e acessa o
      SGBD diretamente em cada uma, então está na hora de você sair do
      clietne/servidor e começar a utilizar n-tiers :) (foi uma piada, as
      pessoas resolviam este problema com 2 camadas, não sei como, mas
      resolviam).

      O jeito mais simples, creio, é criar uma camada entre seus clientes e
      a persistência. Para atualizar algo, seus clientes entram em contato
      com essa camada, que envia uma mensagem aos outros clientes sobre o
      fato.

      Se você precisa que as máquinas sejam independentes, pdoe pensar numa
      estrutura P2P ou multicast, as máquinas ficam escutando uma porta com
      um socket e toda vez que uma atualiza algo avisa as outras.

      Existem algumas implementações de cache distribuídos já prontas para
      isso, a melhor solução vai depender do tamanho e requisitos do seu
      sistema.

      []s


      --
      Phillip Calçado
      http://www.fragmental.com.br
      ICQ: 1110nine38six5
      M$N: pcalcado@...
      Y!: pcalcado@...
      Crux Sacra Sit Mihi Lux

    • Romano J M Silva
      Se você for usar um servidor de aplicação, como JBOSS, você pode usar Message Beans.
      Message 2 of 12 , Oct 5, 2005
      • 0 Attachment
        Se você for usar um servidor de aplicação, como JBOSS, você pode usar
        Message Beans.

        Leonardo Lima wrote:

        >> O jeito mais simples, creio, é criar uma camada entre seus clientes e
        >> a persistência. Para atualizar algo, seus clientes entram em contato
        >> com essa camada, que envia uma mensagem aos outros clientes sobre o
        >> fato.
        >
        >
        >
        > Já tinha pensado nesta idéia da camada,
        >
        > Ou seja essa camada ficaria no servidor correto ?
        >
        >
        >
        > Como eu faria isso?
        >
        > Essa é a grande dúvida rsrsrsrs
        >
        >
        >
        > Obrigado
        >
        >
        >
        > -----Mensagem original-----
        > *De:* riojug@yahoogroups.com [mailto:riojug@yahoogroups.com] *Em nome
        > de *Phillip Calçado
        > *Enviada em:* quarta-feira, 5 de outubro de 2005 17:42
        > *Para:* riojug@yahoogroups.com
        > *Assunto:* Re: [riojug] Dúvida de implementação
        >
        >
        >
        > Oi,
        >
        > On 10/4/05, Carlos Angelim <cangelim@...> wrote:
        >> O hibernate já está cuidando disso pra vc, desde que, claro, o objeto
        >> que vc estiver consultando/editando esteja acoplado a sessão do
        > hibernate.
        >
        > Mas como fazer isso num sistema distribuído com essas características?
        >
        > Leonardo, primeiro vamos tentar pensar em objetos, não no banco de
        > dados (que só é onde os objetos são salvos).
        >
        > Se você tem objetos independentes nas máquinas clientes e acessa o
        > SGBD diretamente em cada uma, então está na hora de você sair do
        > clietne/servidor e começar a utilizar n-tiers :) (foi uma piada, as
        > pessoas resolviam este problema com 2 camadas, não sei como, mas
        > resolviam).
        >
        > O jeito mais simples, creio, é criar uma camada entre seus clientes e
        > a persistência. Para atualizar algo, seus clientes entram em contato
        > com essa camada, que envia uma mensagem aos outros clientes sobre o
        > fato.
        >
        > Se você precisa que as máquinas sejam independentes, pdoe pensar numa
        > estrutura P2P ou multicast, as máquinas ficam escutando uma porta com
        > um socket e toda vez que uma atualiza algo avisa as outras.
        >
        > Existem algumas implementações de cache distribuídos já prontas para
        > isso, a melhor solução vai depender do tamanho e requisitos do seu
        > sistema.
        >
        > []s
        >
        >
        > --
        > Phillip Calçado
        > http://www.fragmental.com.br
        > ICQ: 1110nine38six5
        > M$N: pcalcado@...
        > Y!: pcalcado@...
        > Crux Sacra Sit Mihi Lux
        >
        >
        >
        > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
        > Rio Java Users Group www.riojug.org
        > E-mail dos Moderadores riojug-owner@yahoogroups.com
        >
        > Patrocínio: Quality Software, SENAC-Rio CIT, Locaweb
        > Apoio: Java Magazine, SQL Magazine
        > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
        > Participe também das outras listas do RioJUG:
        > SCJP (groups.yahoo.com/group/scjp_riojug)
        > SCWCD (groups.yahoo.com/group/scwcd_riojug)
        > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
        >
        >
        >
        > SPONSORED LINKS
        > Basic programming language
        > <http://groups.yahoo.com/gads?t=ms&k=Basic+programming+language&w1=Basic+programming+language&w2=C+programming+language&w3=Computer+programming+languages&w4=The+c+programming+language&w5=C+++programming+language&w6=List+of+programming+languages&c=6&s=193&.sig=aLlETYEcZKW67uFZnuZPPw>
        > C programming language
        > <http://groups.yahoo.com/gads?t=ms&k=C+programming+language&w1=Basic+programming+language&w2=C+programming+language&w3=Computer+programming+languages&w4=The+c+programming+language&w5=C+++programming+language&w6=List+of+programming+languages&c=6&s=193&.sig=n4wEVXDpIBKogo8e_G77cw>
        > Computer programming languages
        > <http://groups.yahoo.com/gads?t=ms&k=Computer+programming+languages&w1=Basic+programming+language&w2=C+programming+language&w3=Computer+programming+languages&w4=The+c+programming+language&w5=C+++programming+language&w6=List+of+programming+languages&c=6&s=193&.sig=KFl1CeQi7jrKmsK4WD6ygQ>
        >
        > The c programming language
        > <http://groups.yahoo.com/gads?t=ms&k=The+c+programming+language&w1=Basic+programming+language&w2=C+programming+language&w3=Computer+programming+languages&w4=The+c+programming+language&w5=C+++programming+language&w6=List+of+programming+languages&c=6&s=193&.sig=lU9w7-4UlGPB4LjDy84c2Q>
        > C programming language
        > <http://groups.yahoo.com/gads?t=ms&k=C+++programming+language&w1=Basic+programming+language&w2=C+programming+language&w3=Computer+programming+languages&w4=The+c+programming+language&w5=C+++programming+language&w6=List+of+programming+languages&c=6&s=193&.sig=dtKotXT1Ne2N9AO_aEbPFQ>
        > List of programming languages
        > <http://groups.yahoo.com/gads?t=ms&k=List+of+programming+languages&w1=Basic+programming+language&w2=C+programming+language&w3=Computer+programming+languages&w4=The+c+programming+language&w5=C+++programming+language&w6=List+of+programming+languages&c=6&s=193&.sig=0shmxLBHwrZWcSjC3QvZAA>
        >
        >
        >
        > ------------------------------------------------------------------------
        > YAHOO! GROUPS LINKS
        >
        > * Visit your group "riojug
        > <http://groups.yahoo.com/group/riojug>" on the web.
        >
        > * To unsubscribe from this group, send an email to:
        > riojug-unsubscribe@yahoogroups.com
        > <mailto:riojug-unsubscribe@yahoogroups.com?subject=Unsubscribe>
        >
        > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
        > Service <http://docs.yahoo.com/info/terms/>.
        >
        >
        > ------------------------------------------------------------------------
        >
      • Phillip Calçado
        Oi, ... Dois tipos de solução, como falei: centralizada num servidor ou P2P. Num servidor, absta você fazer seus clientes ao invés de se comunica com o
        Message 3 of 12 , Oct 5, 2005
        • 0 Attachment
          Oi,

          On 10/5/05, Leonardo Lima <lplima@...> wrote:
          > Ou seja essa camada ficaria no servidor correto ?


          Dois "tipos" de solução, como falei: centralizada num servidor ou P2P.

          Num servidor, absta você fazer seus clientes ao invés de se comunica
          com o SGBD se comunciar com o servidor, passando objetos serializados,
          por exemplo. Você pode pesquisar por RMI, Stateless Session Beans com
          interfaces remotas, Burlap/Hessian e SOAP/REST.

          Na outra hipótese, você pode manter mais ou menos a mesma estrutura,
          mas as máquinas fazem um multicast para um endereço conhecido avisando
          que algo foi alterado, sem servidor.

          []s

          --
          Phillip Calçado
          http://www.fragmental.com.br
          ICQ: 1110nine38six5
          M$N: pcalcado@...
          Y!: pcalcado@...
          Crux Sacra Sit Mihi Lux
        • Leonardo Lima
          Comecei a ler sobre RMI vou ler sobre os outros para tomar uma decisão. Pelo pouco que li RMI parece ser uma boa solução O servidor é centralizado ( eu
          Message 4 of 12 , Oct 5, 2005
          • 0 Attachment

            Comecei a ler sobre RMI vou ler sobre os outros para tomar uma decisão.

            Pelo pouco que li RMI parece ser uma boa solução

             

            O servidor é centralizado ( eu acho rsrsrsrs)

             

            Pergunta q pode ser bem idiota...

            Existe algum meio de ASP.NET “conversar” com o Java ?

            Pois neste sistema o BD

            Também será alimentado via Web, ou seja a camada do servidor teria q comunicar

            Essa mudança aos clientes...

             

            Obrigado + uma vez

             

            -----Mensagem original-----
            De: riojug@yahoogroups.com [mailto:riojug@yahoogroups.com] Em nome de Phillip Calçado
            Enviada em: quarta-feira, 5 de outubro de 2005 19:08
            Para: riojug@yahoogroups.com
            Assunto: Re: [riojug] Dúvida de implementação

             

            Oi,

            On 10/5/05, Leonardo Lima <lplima@...> wrote:
            > Ou seja essa camada ficaria no servidor correto ?


            Dois "tipos" de solução, como falei: centralizada num servidor ou P2P.

            Num servidor, absta você fazer seus clientes ao invés de se comunica
            com o SGBD se comunciar com o servidor, passando objetos serializados,
            por exemplo. Você pode pesquisar por RMI, Stateless Session Beans com
            interfaces remotas, Burlap/Hessian e SOAP/REST.

            Na outra hipótese, você pode manter mais ou menos a mesma estrutura,
            mas as máquinas fazem um multicast para um endereço conhecido avisando
            que algo foi alterado, sem servidor.

            []s

            --
            Phillip Calçado
            http://www.fragmental.com.br
            ICQ: 1110nine38six5
            M$N: pcalcado@...
            Y!: pcalcado@...
            Crux Sacra Sit Mihi Lux

          • Geraldo Xexeo
            Tenho estudado soluções P2P na UFRJ, são bastante interessantes, mas é bem mais difícil programar. Além disso, essa questão de ter um sistema P2P
            Message 5 of 12 , Oct 6, 2005
            • 0 Attachment
              Tenho estudado soluções P2P na UFRJ, são bastante interessantes, mas é
              bem mais difícil programar. Além disso, essa questão de ter um sistema
              P2P formando um banco de dados virtual em cima do banco de dados é um
              problema sério. Acho que a melhor solução será por meio de usar um
              modelo C/S multi-camada.

              Claramente, você tem requisitos que devem ser bem definidos para então
              escolher uma arquitetura.

              Me parece que seu principal problema, até agora, é detectar uma mudança
              na base e replicá-la para os clientes (mudança de dados gerando mudança
              na interface).

              Dependendo do que é possível para você, uma solução seria usar o JMS ou
              MessageBeans. A sua aplicação, ou pelo menos o controle de persistência
              dela, realmente dita ficaria rodando no servidor. Os objetos seriam
              observados por beans observadores que teriam registrados os clientes
              conectados e mandariam mensagens para eles.

              Já viu que complica, ou seja, o servidor tem que manter quem estar
              conectado. Também pode funcionar com o cliente indo de tanto em tanto
              tempo pegar o que mudou.

              Basicamente, você deveria encontrar tudo que precisa no J2EE, mas o
              problema é que para isso terá que usar muito mais que J2EE feijão com
              arroz.

              Esse problema, porém, é comum em qualquer sistema acessado por mais de
              uma pessoa. Sempre (C/S ou P2P) haverá a questão de existir, na mão de
              alguém, um objeto que não está no estado correto. Talvez tratar isso ao
              nível da aplicação seja mais fácil.

              Por exemplo, você pode proibir que um objeto seja salvo se seu estado
              atual não for igual ao estado antigo da cópia do objeto que está com o
              cliente.

              Porém, se você deseja monitorar algo, talvez a melhor solução seja, como
              disse o Philipe, o multi-cast para os cliente registrados, que eu
              tentaria implementar com JMS. Também depende dos seus requisitos de
              tempo e segurança, já que no JMS não há uma garantia de tempo de
              entrega, pelo que eu me lembre. Clientes registrados porém são um
              problema para você, pois se eles sairem do ar você pode se ferrar
              tentando falar com eles. Sempre é melhor que toda comunicação parta
              sempre do cliente.

              Espero que esses comentários possam ajudá-lo.

              Xexéo









              Phillip Calçado wrote:

              > Oi,
              >
              > On 10/5/05, Leonardo Lima <lplima@...> wrote:
              > > Ou seja essa camada ficaria no servidor correto ?
              >
              >
              > Dois "tipos" de solução, como falei: centralizada num servidor ou P2P.
              >
              > Num servidor, absta você fazer seus clientes ao invés de se comunica
              > com o SGBD se comunciar com o servidor, passando objetos serializados,
              > por exemplo. Você pode pesquisar por RMI, Stateless Session Beans com
              > interfaces remotas, Burlap/Hessian e SOAP/REST.
              >
              > Na outra hipótese, você pode manter mais ou menos a mesma estrutura,
              > mas as máquinas fazem um multicast para um endereço conhecido avisando
              > que algo foi alterado, sem servidor.
              >
              > []s
              >
              > --
              > Phillip Calçado
              > http://www.fragmental.com.br
              > ICQ: 1110nine38six5
              > M$N: pcalcado@...
              > Y!: pcalcado@...
              > Crux Sacra Sit Mihi Lux
              >
              >
              > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
              > Rio Java Users Group www.riojug.org
              > E-mail dos Moderadores riojug-owner@yahoogroups.com
              >
              > Patrocínio: Quality Software, SENAC-Rio CIT, Locaweb
              > Apoio: Java Magazine, SQL Magazine
              > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
              > Participe também das outras listas do RioJUG:
              > SCJP (groups.yahoo.com/group/scjp_riojug)
              > SCWCD (groups.yahoo.com/group/scwcd_riojug)
              > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
              >
              >
              > ------------------------------------------------------------------------
              > YAHOO! GROUPS LINKS
              >
              > * Visit your group "riojug
              > <http://groups.yahoo.com/group/riojug>" on the web.
              >
              > * To unsubscribe from this group, send an email to:
              > riojug-unsubscribe@yahoogroups.com
              > <mailto:riojug-unsubscribe@yahoogroups.com?subject=Unsubscribe>
              >
              > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
              > Service <http://docs.yahoo.com/info/terms/>.
              >
              >
              > ------------------------------------------------------------------------
              >
            • Leonardo Lima
              Eu já tenho + ou – em mente como vai funcionar vcs estão ajudando p/ caramba. ... Concordo com vc, mas também não gosto muito da solução do cliente
              Message 6 of 12 , Oct 6, 2005
              • 0 Attachment

                Eu já tenho + ou – em mente como vai funcionar vcs estão ajudando p/ caramba.

                 

                > Clientes registrados porém são um

                > problema para você, pois se eles sairem do ar
                você pode se ferrar
                > tentando falar com eles. Sempre é melhor que
                toda comunicação parta
                > sempre do cliente.

                Concordo com vc, mas também não gosto muito da solução do cliente ficar verificando o servidor toda hora.

                Acho q mesmo q o cliente saia do ar, a idéia da camada me parece melhor.

                Acho q um tratamento para este caso resolveria o problema

                 

                Leonardo

                 

                 

                -----Mensagem original-----
                De: riojug@yahoogroups.com [mailto:riojug@yahoogroups.com] Em nome de Geraldo Xexeo
                Enviada em: quinta-feira, 6 de outubro de 2005 12:34
                Para: riojug@yahoogroups.com
                Assunto: Re: [riojug] Dúvida de implementação

                 


                Tenho estudado soluções P2P na UFRJ, são bastante interessantes, mas é
                bem mais difícil programar. Além disso, essa questão de ter um sistema
                P2P formando um banco de dados virtual em cima do banco de dados é um
                problema sério. Acho que a melhor solução será por meio de usar um
                modelo C/S multi-camada.

                Claramente, você tem requisitos que devem ser bem definidos para então
                escolher uma arquitetura.

                Me parece que seu principal problema, até agora, é detectar uma mudança
                na base e replicá-la para os clientes (mudança de dados gerando mudança
                na interface).

                Dependendo do que é possível para você, uma solução seria usar o JMS ou
                MessageBeans. A sua aplicação, ou pelo menos o controle de persistência
                dela, realmente dita ficaria rodando no servidor. Os objetos seriam
                observados por beans observadores que teriam registrados os clientes
                conectados e mandariam mensagens para eles.

                Já viu que complica, ou seja, o servidor tem que manter quem estar
                conectado. Também pode funcionar com o cliente indo de tanto em tanto
                tempo pegar o que mudou.

                Basicamente, você deveria encontrar tudo que precisa no J2EE, mas o
                problema é que para isso terá que usar muito mais que J2EE feijão com
                arroz.

                Esse problema, porém, é comum em qualquer sistema acessado por mais de
                uma pessoa. Sempre (C/S ou P2P) haverá a questão de existir, na mão de
                alguém, um objeto que não está no estado correto. Talvez tratar isso ao
                nível da aplicação seja mais fácil.

                Por exemplo, você pode proibir que um objeto seja salvo se seu estado
                atual não for igual ao estado antigo da cópia do objeto que está com o
                cliente.

                Porém, se você deseja monitorar algo, talvez a melhor solução seja, como
                disse o Philipe, o multi-cast para os cliente registrados, que eu
                tentaria implementar com JMS. Também depende dos seus requisitos de
                tempo e segurança, já que no JMS não há uma garantia de tempo de
                entrega, pelo que eu me lembre. Clientes registrados porém são um
                problema para você, pois se eles sairem do ar você pode se ferrar
                tentando falar com eles. Sempre é melhor que toda comunicação parta
                sempre do cliente.

                Espero que esses comentários possam ajudá-lo.

                Xexéo









                Phillip Calçado wrote:

                > Oi,
                >
                > On 10/5/05, Leonardo Lima <lplima@...> wrote:
                > > Ou seja essa camada ficaria no servidor correto ?
                >
                >
                > Dois "tipos" de solução, como falei: centralizada num servidor ou P2P.
                >
                > Num servidor, absta você fazer seus clientes ao invés de se comunica
                > com o SGBD se comunciar com o servidor, passando objetos serializados,
                > por exemplo. Você pode pesquisar por RMI, Stateless Session Beans com
                > interfaces remotas, Burlap/Hessian e SOAP/REST.
                >
                > Na outra hipótese, você pode manter mais ou menos a mesma estrutura,
                > mas as máquinas fazem um multicast para um endereço conhecido avisando
                > que algo foi alterado, sem servidor.
                >
                > []s
                >
                > --
                > Phillip Calçado
                > http://www.fragmental.com.br
                > ICQ: 1110nine38six5
                > M$N: pcalcado@...
                > Y!: pcalcado@...
                > Crux Sacra Sit Mihi Lux
                >
                >
                > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                > Rio Java Users Group    www.riojug.org
                > E-mail dos Moderadores  riojug-owner@yahoogroups.com
                >
                > Patrocínio: Quality Software, SENAC-Rio CIT, Locaweb
                > Apoio: Java Magazine, SQL Magazine
                > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                > Participe também das outras listas do RioJUG:
                > SCJP (groups.yahoo.com/group/scjp_riojug)
                > SCWCD (groups.yahoo.com/group/scwcd_riojug)
                > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                >
                >
                > ------------------------------------------------------------------------
                > YAHOO! GROUPS LINKS
                >
                >     *  Visit your group "riojug
                >       <http://groups.yahoo.com/group/riojug>" on the web.
                >       
                >     *  To unsubscribe from this group, send an email to:
                >        riojug-unsubscribe@yahoogroups.com
                >       <mailto:riojug-unsubscribe@yahoogroups.com?subject=Unsubscribe>
                >       
                >     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                >       Service <http://docs.yahoo.com/info/terms/>.
                >
                >
                > ------------------------------------------------------------------------
                >


              • Geraldo Xexeo
                Acabei de lembrar que coisa que você pode tentar é uma arquitetura de agentes. Meus alunos estão em luta sobre se os Aglets são melhores ou a plataforma
                Message 7 of 12 , Oct 6, 2005
                • 0 Attachment
                  Acabei de lembrar que coisa que você pode tentar é uma arquitetura de
                  agentes.

                  Meus alunos estão em luta sobre se os Aglets são melhores ou a
                  plataforma JADE (que é baseada em um padrão).

                  Xexéo
                Your message has been successfully submitted and would be delivered to recipients shortly.