Aplicação Clint/Server - Java ou Delphi?

Olá

A aplicação é cliente/servidor tradicional? Então faça em FoxPro, Delphi, Cobol ou VB. Com Java não há sentido em arquitetura cliente/servidor.

Com Java fazemos aplicações distribuídas com cliente que SÓ mostra dados que solicita e recebe (view). Toda a camada de negócios (model) fica em um ou mais servidores por trás da camada intermediária de controle (controller).

Ser web ou não tanto faz, é só uma questão de configurar corretamente o endereço IP do servidor.

[]s
Luca

Discordo!

Concordo que Delphi e VB são mais produtivos pra criar e produzir telinhas.
Mas Java tem se mostrado bastante bom nessa área também.

Olá

Na arquitetura cliente/servidor tradicional, o lado cliente acessa a camada de negócios e a base de dados. Aqui no GUJ em dezenas de mensagens já reiterei que para mim isto está fora de moda.

É claro que ainda tem gente cometendo este desatino e dando tiros no pé. Há um outro tópico de hoje onde o cara está desesperado para fazer suas telas acessarem a base de dados.

Jamais diria que o Java não serve para fazer aplicações com muitas telas pois trabalhei com várias aplicações deste tipo. Uma delas completamente pioneira, quando trabalhei com ela há alguns anos atrás, funcionava com jsdk 1.1.6 e era linda. Por ser pioneira foi apresentada como caso de sucesso em várias palestras. Uma outra tem mais de 100 telas, toda componentizada, mais de 1200 classes e é uma applet.

[]s
Luca

Sou do tipo: se tem tempo, faça tudo direitinho, senao, apela pro jeito mais rapido

Se hoje em dia houvesse alguma IDE voltada a trabalhar com estrutura client server, acho que mta gente teria aplicativos assim, ja que nao tem, faz-se tudo separado, bonitinho, pra distribuir na rede.

Se eu nao tivesse tempo, eu faria tudo acessando direto ( client server na veia :twisted: ) mas bem separado pra que no futuro isso possa ser facilmente alterado para acessar o model pela web ou ejb, que seja

neh não ?! :roll:

Corrijam-me se eu estiver dizendo bobagem, mas RMI não seria o cara para isso?

[]s

RMI serve sim.

Vc faz a casca (visual) em Swing e o model (Negócio) sendo acessado remotamente via RMI.

Os acessos aos EJBs trabalham com RMI.

“prog”:

Corrijam-me se eu estiver dizendo bobagem, mas RMI não seria o cara para isso?
[]s

eu tbm não sei pq o tumulto.

EJB seria mais legal :D:D:D

eu só a 3 dias que leio algumas coisas sobre java,

mas estão a esquecer-se de algo muito importante,

primeiro que java é um linguagem, bastante avançado em relação a muitas outras, e é algo mais sofisticado e que actualmente vejo como uma linguagem de futuro…

depois tão a esquecer a portabilidade da linguagem, se querem fazer um software cliente/servidor, terá que se reparar que este software poderá ser usado em MAc, win32, UniX…

delphi estará preso ao win32, a não ser que queria escrever todo o código novamente em kylix…

“ncosta”:

delphi estará preso ao win32, a não ser que queria escrever todo o código novamente em kylix…

Apesar de odiar Delphi, se as versões forem comptíveis você não tem que reescrever, mas sim recompilar.

As ferramentas hoje permtiem qeu agluémd esenvovla uma cosia bem melhor que um 2-camadas bizonho em pouquíssimo tempo, apto à expansão e com todos os opcionais.

Se formos falar em protabildiade, um WebService permitira ao sistema ser acessado por muito mais maneiras que RMI ou formatos nativos.

Mas, na verdade, não importa o que seja utilizado para fazer RPC, desde que sejam segudias boas práticas e se larguem vícios defasados há mais de dez anos.

Não é boa idéia concentrar tudo no servidor em algunsc asos, as estações hoje são tão poderosas que transformá-las em meros exibidores de HTML é umd esperdício enorme, o ponto é saber distribuir responsabilidades. Um cliente deve processar o que lhe diz respeito.

Integrar cliente através da persistência semrpe foi um dos mairoes problemas em sistemas distribuídos, e semrpe foi muito utilizado porque ‘fica pronto rápido’. É claro que só quando o sistema cresce alguém percebe que vait er qe jogar tudo fora e fazer um novo, porque agora os clietnes estão com problemas de sincronização.

Aí surgem os gênios que colocam toda a lógica da aplicação em Stored Procedures. Assim fica centralizado… Ora, se é assim, por que não dar o consoel de adminsitrador pro usuário? Ou fazer algo tipo M$ Access?

Não dá para produzir sistemas em 2004 com idéias de 1990…

[]s

é pcalcado, nisto voce esta coberto de razões sobre o pensamento antigo com as novas tecnicas… eu sou uma prova disto.

Ja Apanhei para aprender PHP, na parte de Classes, e olha que são simples comparadas com Java.

Eu tenho quase o mesmo problema do Marcelo, tenho uma Aplicação antiga e quero convertela para linguagens mais modernas.

Tem coisas que na Web Não da para fazer, tem coisas que na Web se facilita muito com relação a desenvolvimento.

o ponto que estou chegando é mesclar tecnologias, desenvolver a parte de Cadastros e controles utilizando o Navegador mesmo e o PHP (pensei no JSP mas infelizmente não funciona em todos os Servers) e algumas coisas utilizar o Java para a Parte de Impressão e seguraça, pois no Navegador tem algumas limitações.

Não sei ainda se o Caminho é este, gostaria de até opinioes de como criar um Sistema de Medio/Grande Porte com estas tecnologias.

Se alguem tem alguma experiencia ou conhece alguem que ja tenha tido.

Por falar em integrar PHP com Java…

Eu integrei um site em PHP com uma aplicação Java usando WebServices. No site eu disponibilizei webservices utilizando um pacotinho chamado NUSoap e consumo os webservices normalmente pelo Java usando Axis.

Tudo funcionou redondinho.

Tem suas limitações. Essa era uma integração simples, não requeria autenticação nem muita segurança, que é ponto fraco dos webservices.

[]'s

Eu acho que o Delphi é uma tecnologia bem madura para a arquitetura client/server e o Java está começando agora a ser usado no desktop.
Apesar desta maturidade do Delphi a plataforma Java nos proporciona possibilidades de implementação e distribuição que seriam complicadas em Delphi ou VB.
A grande vantagem do Delphi ou VB em relação ao Java no desktop é que as telas e formulários ficam prontos mais rápido, apesar do código gerado e até a própria cultura de código dos programadores destas linguagens serem contestáveis, pois o código é orientado a eventos e o nivel de acoplamento beira a insanidade.
Por outro lado, hoje no Java, temos APIs que facilitam (muito) a nossa vida quanto a construção de formulários e telas comerciais, assim como o JGoodies Forms Framework, que é muiiiiito bom.
Gosto da arquitetura Swing -> HttpClient -> Servlet Controller -> EJBs
pois nos livra de lidar com RMI e acesso a EJBs de forma remota. Assim vc pode ter os tiers geograficamente distribuídos e com os clients desktop acessando-os de forma segura. Para distribuição da aplicação client o Java Web Start é uma ótima pedida, pois já que temos um web-server nos provendo dados e lógica de negócios. Acho que aplicações web tem seu lugar garantido, mas não gosto da idéia de ‘tudo tem que ser Web’, pois tem coisas que só o desktop faz por vc.
Aposto todas as minhas fichas em aplicações rich-clients em Java, pois a plataforma está evoluindo muito neste rumo.

Puxa, até que envim um que fala que não estou dando tiro no pé.

eu não discuto, pois não conheço o JAVA tão bem como o pessoal daqui, então concordo parcialmente com tudo, eu programo a 21 Anos em C, a pouco tempo, uns quatro anos, programo em PHP para a Internet…

A solução que criei é para uma empresa com 12 Filiais, a aplicação de Cadastro foi feita em PHP e esta na Web, então todos as Filiais tem acesso a esta aplicação os Bancos de Dados são integrados, com acessos restritos de Parceiros Internacionais deu para fazer uma Aplicação até que boa.

A Parte cliente tive que aprender Delphi, esta parte faz somente a impressão dos Formularios de Conhecimento Aereo, Invoices, Manifests, entre outros, que é praticamente impossivel de se fazer pela Web;

Eu buscava Java justamente para estas aplicações que fiz com o Delphi, pois ja tinha lido sobre Java Web Start, e acho que facilitaria as filiais que tem autorização para estas impressões fazerem este acesso e impressão.

Sei que para muitos aqui é uma coisa Basica, mas para mim ainda é um bicho de sete cabeças, como não tenho muito tempo para estudos, pensei em ver se achava um codigo que faria acesso a uma base de dados SQL e imprimisse os relatorios em Impressoras matriciais, dai implementava as minhas necessidades, com base no exemplo.

Ainda acho algo que me guie para isto.

Pessoal,

Vamos simplificar, alguém conhece alguma IDE p/ trabalhar com JAVA em “client/server” e também “web”???

Já ouvi falar muito bem do Eclipse, ele é voltado p/ Web, não é mesmo?
O que vocês acham???

IMPORTANTE: Meu objetivo é client/server, ok?

Abraço

Marcelo Ribeiro

Ok, simplificando:

• client/server é uma arquitetura arcaica, pelo menos no estilo muitos clientes para um server dono-do-mundo

• Qualquer IDE java, incluindo o Kate ou o bloco de notas, vai te dar o que é preciso. Se você está pensando em fazer formuláriozinhos e tacar código nos onClick da vida, você pode a) mudar seu modo de pensar e parar de fazer estas coisas medonhas ou b) tentar outra plataforma (Delphi.Net?)

• Eclispe é voltado para escrever código, se é para web ou não depende de quem usa

[]s

Oi…

Acho que comparações não se aplicam, Java e Delphi são dois mundos diferentes.

Quanto a conhecer um, bem tem o Jbuilder, da propria Borland.

e tem mais por ai, tem um que chama GENEXUS, que cria a aplicação e cria o Codigo fonte em C++ ou JAVA.

entre outros que tem por ai, basta Garimpar.

Deixando de lado a discussao a respeito da arquitetura da coisa toda, existem diversas opcoes de IDE: Netbeans, Eclipse+plugins, JBuilder, etc. Em geral voce precisara de uma quantidade razoavel de RAM para rodar legal essas ferramentas (mas tambem… qual IDE hoje em dia nao eh assim?).

Marcio Kuchma

bem, a arquitetura cliente-servidor ta ultrapassada, vcs disseram

que outras opções existem para quem quer uma solução que a arquitetura cliente-servidor resolve? :roll:

“microfilo”:

bem, a arquitetura cliente-servidor ta ultrapassada, vcs disseram

que outras opções existem para quem quer uma solução que a arquitetura cliente-servidor resolve? :roll:

Olha isso aqui [Wikipedia rlz ]

[]s