Tecnologias para aplicações distribuídas

Programação Arquitetura
#1

Olá,

estou prestes a desenvolver um sistema em que vários clientes java remotos precisam consultar o estado de um servidor central também desenvolvido em java. A UI dos clientes java precisa ser desktop, provavelmente SWING mesmo. Gostaria de saber quais são as possíveis soluções tecnológicas para este problema? Inicialmente me vem à cabeça WebServices, mas fiquei na dúvida se talvez não existe um outro meio mais rápido, sendo velocidade um requisito necessário no sistema.

Obrigado.

#2

Bom dia,

 Depende do/dos protocolo(s)  aceites pelo servidor Java :

 pode ser um servidor SOCKET, um servidor RMI , um servidor CORBA, um servidor HTTP, um servidor de aplicações web (Jetty, Tomcat ...),  um servidor de WS (SOAP, REST, Apache CXF), um servidor JBoss, GlassFish (EJB Remote), etc ... 

 O mais simples e rápido talvez  seja um cliente SWING <-------HTTP-----> Servlet do servidor de aplicações web (Jetty, Tomcat ...)

Na minha opinião JETTY é melhore que TOMCAT …

#3

quando se fala em comunicação HTTP me vem à cabeça o uso de WebServices (WS), que era a minha ideia inicial. Vc sugere a comunicação direta através de mensagens HTTP? sem as abstrações de WS (SOAP por exemplo)?

#4

segue as opções

  • socket
  • RMI
  • EJB
  • SOAP
  • REST

Veja os pros e contras de cada uma delas.

#5

Bom dia,

O conceito de Web Services (WS) é um pouco mais complicado do que parece. 

Todo mundo fala sobre Web Services, mas ninguém fala da mesma coisa.

O conceito foi definido e implementado no contexto de [b]Web Services Activity[/b] no W3C.

Existem várias tecnologias por trás dos serviços web  ou Web Services (WS) :

----> Serviços Web de tipo Representational State Transfer (REST) : expõem totalmente funcionalidades como um conjunto de recursos (URI) identificáveis ​​e acessíveis pela sintaxe e semântica do protocolo HTTP. Web Services REST são baseados em arquitetura web e seus padrões básicos: HTTP, URI.

----> Serviços Web WS-* expõem esses recursos na forma de serviços executáveis ​​remotamente. Especificações são baseadas em SOAP e WSDL e UDDI para transformar os problemas de integração herdadas do mundo Middleware para fins de interoperabilidade. Estes Serviços Web WS-* também são definidos de acordo com o tipo de arquitetura SOA.
O consórcio ebXML usou para automatizar o intercâmbio entre empresas no quadro do famoso B2B.

Nota : XML-RPC pode ser usado em vez de SOAP.

SOAP não está ligado ao HTTP

Definições e acrônimos :

SOAP (Simple Object Access Protocol)
WSDL (Web Service Description Language)
UDDI (Universal Description Discovery and Integration)
SOA (Service Oriented Architecture)

Plataformas para Web Services (WS) :

—> JAX-WS que é a implementação de referência do Java EE é de código aberto e integrado no GlassFish e utilizado em outros ambientes.
—> Apache CXF Fusão entre XFire (CodeHaus) e Celtix (Objectweb)

Conclusão

   Não é necessário o uso de [b]WS-*[/b] com o [b]SOAP [/b] ou [b]XML-RPC[/b] numa relação cliente-servidor simples. Já que é mais para SOA e B2B e arquiteturas distribuídas  ,  etc ...
   
  O que pode ser interessante é usar o [b]REST [/b] e mensagens JSON ou XML . 

  Mas ainda mais fácil para uma arquitetura cliente-servidor é simplesmente usar HTTP para acessar um Servlet. 

 Usar SOCKET também pode ser uma opção.

Tem também outras opções mais complicadas para aplicações distribuídas

  • RMI, JINI, GigaSpaces
  • EJB
  • CORBA , JavaIDL
  • JGroups
  • GridGain
  • Terracotta

etc …
etc …

#6

O HTTP tem uma vantagem que os outros protocolos não têm : passa por firewalls. Só isso vai poupar um monte de dor de cabeça.
Quando a SOAP , é um canhão para matar moscas. REST é melhor. Mais simples e mais direto (e continua sendo webservice na mesma). A vantagem do REST é que não necessáriamente o resultado tem que ser xml, pode até ser binário. Isto é util quando vc precisa por exemplo fazer um report. Vc faz o report no servidor e manda já feito para o cliente.

A velocidade da aplicação não depende das tencologias, depende de como vc as usar e especificamente de onde vc coloca a carga. Algumas coisas são mais rápidas se rodarem no servidor (acesso massivo a dados como os reports, por exemplo), outras melhor no ciente (valiação de input, por exemplo).

Dê também uma olhada no JWS que é um protocolo para vc pode instalar as aplicações remotamente (demelhante aos apps tão famosos agora). A pessoa pode acessar um site (já que vc terá um servidor isto deve ser fácil de prover) e lá terá um link que irá instalar a aplicação. Vc pode até turbinar este site (de uma página só na realidade) para detectar se o cara tem o java instalado na máquina dele e se não tiver instalar o java e depois a aplicação. É bastante util porque o proprio usuário pode fazer a instalação.

#7