ARGH! O projeto em Swing que eu tava foi cancelado (alguem consegue advinhar pq? :roll:) e agora o lance por aqui parece ser, erhm, Delphi. Sei que muita gente ai no GUJ ja se matou pra fazer esse tipo de integracao, e eu mesmo jah dei palpite pra cacete nessa area, entao com certeza vcs conseguem elencar as maiores dores de cabeca, e as diquinhas valiosas de sempre… pode ser?
Ainda nem decidimos se a gente vai fazer usando WebServices, Sockets puros ou CORBA (+ IIOP, + inferninho). Entao, qqer tipo de link tb eh bem-vindo!
Acredito que sua aplicação não deve ser do tipo daqueles antigos programas de arquitetura obsoleta como o pacote Office da poderosa que roda tudo na mesma máquina. Sendo assim, deve haver possibilidade de enviar POSTs e GETs a partir de sua aplicação Delphi. Caso afirmativo, porque não fazer o lado servidor com servlet recebendo as transações de um servidor de aplicações qq? Ao invés de enviar objetos, envie apenas os dados.
Mandou bem… estamos pensando em fazer um XML-RPC de pobre aqui, usando XStream do lado Java, e alugma lib qqer de XML pra Delphi (como eu nao conheco picas de Delphi, fica dificil pra mim dar palpite nessa area). Provavelmente vamos usar a velha duplinha “GETs pra pegar, POSTs pra mandar”, e trafegar XMLzinhos pra la e pra ca. O que seria estupido, se a gente tivesse fazendo a coisa pela internet, mas como eh rede local, ninguem se importa com largura de banda… e CPU tem de sobra de qualquer jeito
Mesmo assim, outras sugestoes sao bem-vindas (e, louds, corba ate podia ser uma boa ideia, mas levando em consideracao que nao tem uma gota de know-how sobre corba lah, sua sugestao foi jogada de canto por enquanto, mas nao tah completamente descartada)
Sei bem o que é usar XML na troca de mensagens por HTTP/HTTPS pois trabalho aplicações que fazem exatamente assim. Não há nenhum problema em mandar XML pela Internet. Os problemas do XML são os seguintes:
a) performance tanto no cliente como principalmente num servidor com milhares de clientes.
b) tamanho do parser quando é necessário fazer download na Internet com JWS ou Java Plugin
A grande vantagem de enviar objetos serializados nas mensagens é fazer o sistema bastante genérico e os métodos que enviam e recebem mensagens não precisam saber o que estão enviando e recebendo. Fica bem elegante e rápido de codificar.
Em termos de performance melhor seria ser menos genérico na codificação para ser mais específico na execução. Em outras palavras, escrever métodos diferentes para objetos diferentes ao invés de usar reflection. Mas mesmo assim me parece bastante interessante o tal de XStream que eu não conhecia.
Corba tem suas vantagens. Principalmente se vc tiver usando j2ee, manda teus session beans usarem IIOP e pronto, toda merda ta por conta do pessoal do delphi! Usar full blown corba é muita locura, de deixar qualquer um maluco, gerenciar um ORB não é tão agradavel quando 1 container j2ee.
Já que vc vai utilizar XML sobre HTTP, pq não utilizar webservices duma vez? Usando Axis/JAX-RPC é moleza escrever o código do lado do java.
Tem que se levar em conta quão thin os clientes vão ser, alem dos requisitos de performance e tudo mais.
Minha opinião é q vc simplesmente deveria desenvolver todos servidor usando SOA com stateless session beans e deixar o pessoal do delphi acessar isso via corba ou web-services.
Louds, penso que a gente sempre deve balancear onde devemos economizar. Se a aplicação tem muitos clientes e precisa de bom desempenho as vezes é melhor uma solução feita com um pouco mais atenção na fase de desenvolvimento.
O uso de web services tal como sugeriu pode ser prático mas em alguns casos há o risco do retrabalho para atender aos requisitos de performance.
XML sobre http/https precisa apenas de jsse e um parser. O resto é puro Java. Já com Axis/JAX-RPC pode aparecer um monte de intermediários na troca de mensagens. Se as especificações do projeto não forem muito exigentes em termos de throughput então não haverá problemas em usar soluções elegantes porém de baixo desempenho.
Louds, penso que a gente sempre deve balancear onde devemos economizar. Se a aplicação tem muitos clientes e precisa de bom desempenho as vezes é melhor uma solução feita com um pouco mais atenção na fase de desenvolvimento.
O uso de web services tal como sugeriu pode ser prático mas em alguns casos há o risco do retrabalho para atender aos requisitos de performance.
XML sobre http/https precisa apenas de jsse e um parser. O resto é puro Java. Já com Axis/JAX-RPC pode aparecer um monte de intermediários na troca de mensagens. Se as especificações do projeto não forem muito exigentes em termos de throughput então não haverá problemas em usar soluções elegantes porém de baixo desempenho.
[]s
Luca[/quote]
Cuidado ai com falsas premissas. Usar xml sobre http não vai ser tão mais rápido que usar WS sobre http, que por sinal tb é xml sobre http.
Agora, qual a diferença? Bom, usando WS voce acaba tendo que usar schemas, que é bem pesadinho, mas ninguem seria louco de mandar xml ser pelo menos um DTD, ou seja, o ganho é mínimo.
Em seguida vem o (un)marshalling dos dados, aqui voce usa um esquema feito sobre medida.
Moral da historia, não acho que o ganho em performance vai ser realmente significativo, vale lembrar que tem toda maquinaria do http/ssl que usam bastante recursos.
Com WS ou corba, vc vai ter bem menos trabalho, evitando os passos de projetar um modelo de xml, escrever o marshaller, etc.
Na prática não precisa nada disso. Falei em envio de dados por XML sobre HTTP/HTTPS e não em envio de objetos. Na verdade o uso do XML nem chega a ser necessário. Podia ser usado um protocolo posicional daqueles bem antiquados. A diferença em não enviar objetos é que cada transação precisa conhecer seu contéudo e novas transações exigem novos métodos específicos.
Melhor desempenho versus facilidade de desenvolvimento esta é a questão. Imagine um aplicativo em execução em 1000 terminais, cada terminal enviando 100 transações/dia, distribuídas de modo não uniforme ao longo do dia (com horários de pico). Na hora que o bicho pegar seu patrão vai mandar refatorar tudo e provavelmente “web services” vai para o saco. Melhor começar logo enxutinho (sem esquecer que otimização precoce também é ruim).
