Arquivo Discussoes de Programacao e Tecnologia 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.
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 …
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)?
segue as opções
Veja os pros e contras de cada uma delas.
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
etc …
etc …
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.