Estou com uma solicitação para desenvolver uma aplicação onde:
A interface: será em swing (pois o objetivo é uma performace na digitação);
As regras de negocios ficará no servidor de aplicação e o mesmo se comunicará com o Banco de dados.
Duvidas:
Qual estrutura usar?
Servidor de aplicação apenas irá rodar o dados enviados pelo swing, mais isso é possivel, por onde começar?
Por qual cominho devo seguir minhas pesquisas? quais API´s?
Qual servidor de aplicação usar?
Bom, vou falar de uma forma muitíssima simplificada minha opinião.
Cliente: smart client swing contendo lógica de apresentação
Server: lógica de negócio / integração com base de dados em uma aplicação Java EE utilizando EJBs, etc.
Comunicação do client com o server via RMI-IIOP (mais performático) ou web services.
Bom, é apenas um ponto de partida. Você vai precisar pesquisar em mais detalhes sobre isso (a não ser q alguém poste algo mais completo aqui). Mas seria interessante você citar o ambiente que esse sistema rodará (quem são os clientes, quantos são, de onde eles acessam, etc), pois talvez se for algo pequeno e local, talvez seja exagero um servidor de aplicações e uma arquitetura tão robusta.
Olha…como o client é uma aplicação stand alone (app swing), creio q ficar colocando um monte de framework que n agrega valor à necessidade só agrega complexidade desnecessária. Um servidor Java EE já te oferece suporte ORM (JPA) e comunicação remota via RMI-IIOP. Você não precisa adicionar Spring + Hibernate à sua arquitetura, pois isso n te trará ganhos maiores do que vc já tem, pelo contrário, vc teria mais coisas p aprender. Em relação ao Hibernate, pode ser até q a implementação de persistência do servidor q vc pretende usar já seja Hibernate, porém tente utilizar os recursos baseados na especificação para manter sua aplicação portável. Há determinadas situações que te fazem usar algo específico da implementação, porém depende de cada necessidade.
Não precise estudar RMI puro. A tecnologia EJB/Java EE já abstrai isso p vc. No máximo vc vai precisar aprender a fazer lookup de beans remotos (e entender o custo de uma chamada remota para o desempenho da sua aplicação).
Estude EJB (isso inclui JPA). Recomendo o 3.0 ou 3.1, caso você queira usar os recursos da última versão.
Swing, é claro;
Opcional: design patterns básicos (sei lá, Service Locator, DAO, MVC, Business Delegate, etc), se quiser acrescentar mais qualidade ao código da sua aplicação.
Me desculpe mas swing não é justificativa para performance
Tecnologia de camada de visão nunca entrou no rool dos gargalos de uma solução…
Como vc me explicaria isso?
[quote] - As regras de negocios ficará no servidor de aplicação e o mesmo se comunicará com o Banco de dados.
[/quote]
Quem disse isso? Por que? Qual é sua justificativa para essa decisão?
[quote]Servidor de aplicação apenas irá rodar o dados enviados pelo swing, mais isso é possivel, por onde começar?
Por qual cominho devo seguir minhas pesquisas? quais API´s?[/quote]
Sim…vc pode usar SOCKET, RMI, SOAP, REST ou EJB.
Dai depende da qual tecnologia para comunicação remota sua aplicação vai decidir usar…(caso realmente exista a necessidade disso…)
Me desculpe mas swing não é justificativa para performance
Tecnologia de camada de visão nunca entrou no rool dos gargalos de uma solução…
Como vc me explicaria isso?
Cara é o seguinte, o aplicativo é para um ambiente de digitação!
vc já tentou digitar muito, muito rapido usando um browser?
então cara é isso, com o swing conseguimos que a digitação seja o mais rapido possivel respondendo para o digitador!
- As regras de negocios ficará no servidor de aplicação e o mesmo se comunicará com o Banco de dados.
Quem disse isso? Por que? Qual é sua justificativa para essa decisão?
Como a aplicação será distribuida, queremos garantir a segurança do desemvolvimento, não permitindo que alguem possa quebrar o jar e ver as regras de negocios!
Cara essas perguntas são para ajudar?
Se sim, como posso ter um modo que tenha uma grande performace?
Tanto para digitar, quanto para processar as informações?
O que vc indica com seus anos de experiencias?
[quote]Cara é o seguinte, o aplicativo é para um ambiente de digitação!
vc já tentou digitar muito, muito rapido usando um browser?
então cara é isso, com o swing conseguimos que a digitação seja o mais rapido possivel respondendo para o digitador!
[/quote]
Se o navegador não tiver que tratar HTTP Full, não existe problema. Caso tiver, usa AJAX. Ttenho sistemas web com muito texto sendo digitado o dia o todo e o único problema que eu tenho é o tempo de time-out. O usuário fica digitando um texto comprido e a sessão http dele expira, fora isso tudo ok.
Qual o seu cenário que o navegador impede a rápida digitação? favor compartilhe conosco.
[quote]Como a aplicação será distribuida, queremos garantir a segurança do desemvolvimento, não permitindo que alguem possa quebrar o jar e ver as regras de negocios!
[/quote]
Existe muitos justificativas para se usar EJB e esse que vc citou não é uma delas, alias é a primeira vez q escuto essa justificativa. Ou seja, EJB não foi criado esse fim ai que vc justificou…
Usar EJB é umas maiores dores de cabeça de uma corporação…nos na verdade fazermos de tudo para não usar…só em casos extremos mesmo, quando não tem outra forma.
Meios de evitar esse a pessoa de ver a regra de negocio não existe…mas qual é o problema de alguem ver a regra caso a pessoa saiba voltar um .class para .java? O que vc supõe que aconteça?
Alias, se vc vender a solução para um cliente no qual vc não deseje que veja o código, o EJB container vai estar dentro da empresa dele não vai? Ele terá sim acesso ao se JAR ejb. Ou vc vai centraliza-lo fora da empresa?
[quote]Cara essas perguntas são para ajudar?
O que vc indica com seus anos de experiencias?
[/quote]
É claro q sim amigo…justamente, to vendo vc decidir as coisas com justificativas incoerentes…
Vc não pediu ajuda numa arquitetura? Arquitetos trabalham em cima de requisitos e decisões coerentes…
[quote]Se sim, como posso ter um modo que tenha uma grande performace?
Tanto para digitar, quanto para processar as informações?
[/quote]
Existem algumas abordagens numa arquitetura geral para se melhorar a performance de uma solução, as mais básicas são:
Uso de pooling.
Por exemplo, EJB tem chamadas remotas…chamadas remotas são os maiores vilões de performance.
Colocar todos os requisitos na mesa, suposições, cenários, etc…
Implementar cases que comprovem alguma ideia, suposição ou “achometro”.
Tomar decisões coerentes embasadas.
Se quiser cair no código ja com sua arquitetura ai ok…bola pra frente…
Mas se vc quiser um parâmetro, minha maior solução hoje é bancaria financeira e esta sendo usado por 10 mil clientes no parana. Temos uma media de 1 mil pessoas simultâneas 24 hs por dia fazendo mais de 90 mil acessos mês com uma media de 20 mil transações…sem nada nada de EJB…e muito pelo contrario…ainda to longe de precisar dele.
Fernando
Seguinte, os problemas que encontramos para digitação, é o seguinte, quando temos arquivos muito grande p ser digitado, por exemplo uma apostila que será informado apenas os codigos (isso pode ser apenas numeros) que foram informados (exemplo bem basico do que acontece hoje, o caso é pior). Teria que quebrar as paginas para carregar mais rapido os campos para poderem ser respondidos. Isso perderiamos perfomance do digitador.
Por isso estamos estudando para buscar uma solução em que o digitador possa chegar no seu maximo para digitação.
[quote]Existe muitos justificativas para se usar EJB e esse que vc citou não é uma delas, alias é a primeira vez q escuto essa justificativa. Ou seja, EJB não foi criado esse fim ai que vc justificou…
[/quote]
Ok! porem a questão é a seguinte, o mercado desse cliente é muito concorrido. E qualquer brexa na segurança, vasou informação, o que não pode acontecer porque são sigilosas.
Por isso não podemos deixar vazar as informações que podem comprometer seus clientes. Se vazar as formulas dos processamentos os concorrentes podem utilizar as ideias.
Cara só p/ resumir - mercado é concorrido! $$
Se vc puder me ajudar por onde começar a pesquisar para atender essas necessidades e quais melhores tecnologia usar para resolver isso.
[quote]Seguinte, os problemas que encontramos para digitação, é o seguinte, quando temos arquivos muito grande p ser digitado, por exemplo uma apostila que será informado apenas os codigos (isso pode ser apenas numeros) que foram informados (exemplo bem basico do que acontece hoje, o caso é pior). Teria que quebrar as paginas para carregar mais rapido os campos para poderem ser respondidos. Isso perderiamos perfomance do digitador.
Por isso estamos estudando para buscar uma solução em que o digitador possa chegar no seu maximo para digitação.
[/quote]
Ainda não entendi kkkkk. Detalhe: eu não falei para vc NÃO usar camada de visão desktop e usar uma web. Eu falei que sua justificativa estava incoerente.
[quote]Ok! porem a questão é a seguinte, o mercado desse cliente é muito concorrido. E qualquer brexa na segurança, vasou informação, o que não pode acontecer porque são sigilosas.
Por isso não podemos deixar vazar as informações que podem comprometer seus clientes. Se vazar as formulas dos processamentos os concorrentes podem utilizar as ideias.
Cara só p/ resumir - mercado é concorrido! $$ [/quote]
Então segurança numa corporação não esta relacionado com uso de EJB ou tecnologia A, ou B
Segurança é um processo que envolve - cultura(pessoas) + infra(hardware) + processos(funcionamento e politica) + tecnologia. Uma brecha numa camada destas pode comprometer tudo.
Me coloco a disposição para trocar ideias sobre seu cenário, caso contrario…boa sorte na aventura !!!
Acho que o caminho é este mesmo. Realmente, por mais que tu consiga ser veloz num browser, sempre perderá para um instant-client, visto que o tempo de renderização do HTML é maior do que uma app desktop - então se isso é realmente um requisito importante, vai tranquilo.
E, sim, vale a pena centralizar as regras de negócio, separando-as do client num servidor. Isso é uma boa prática e EJB é uma boa alternativa neste cenário, visto que atualmente, é uma arquitetura JEE madura e sem mais problemas.
Da uma olhada no Genesis, é um framework interessante que integra todas as tecnologias que tu citou (EJB, Swing) e, ainda facilita bastante a aplicação de boas práticas (MVC, Arquitetura modularizada).
Aplicações stand-alone tem o fator “distribuição” para se pensar tbm. Centralizando suas regras de negócio / processamento em um servidor de aplicação vc reduz a possibilidade ou frequência da distribuição de novos releases.
Para mim tem poucos requisitos e as decisões ainda não estão consistentes. Ou seja, é possível cumprir todos os requisitos citados, sem usar nada do que foi selecionado.
Segue ai um mapa minimo de requisitos para se possa decidir algo ainda bem por cima:
Funcionais:
Quais são os processos (casos de uso) da solução?
Quem inicia cada processo?
Quais são as regras existente em cada um?
Em quem ou aonde termina cada processo?
Quais são os atores (pessoas, maquinas, sistemas) da solução?
Não-funcionais:
A solução sera vendida, alugada ou para uso da propria corporação?
A solução estara disponível somente dentro da corporação (intranet)?
A solução estara disponível fora da corporação (intranet)? Por que?
Existe prognóstico de futuramente ser disponibilizado publicamente fora da corporação (internet)? Por que e quando?
A solução sera instalada em uma infra local, remota, propria ou locada? Existe restrições?
Qual o prognóstico da média de usuários totais habilitados?
Existe prognóstico de aumento dessa media de usuários habilitados? A partir do que isso pode acontecer?
Qual o prognóstico da média de usuários simultaneos usando a solução?
Existe prognóstico de aumento dessa media de usuários simultaneos? A partir do que isso pode acontecer?
Quantas transações por mês? (Qual é o volume total das ocorrências dos casos e usos.)
Qual é o tipo de de regras de negócio - simples, média, complexas? Recursivas?
Quais tipos de dispositivos eletronicos serão udadas para acessar a solução? Por que?
Terá integrações com sistemas externos, parceiros ou legados? Para que? Como sera feito? Existe restrições?
Terá integrações com maquinários? Quais? Como sera feito? Existe restrições?
Não-funcionais implicitos obrigatórios:
Confidencialidade
Integridade
Escalabilidade
Disponibilidade
Confiabilidade
Auditoria
Performance
Responsividade
Sem estas respostas totalmente esclarecidos não tem como se arquiteturar nada…
Marcelo
Para isso estamos pensando em utilizar o JAVA WEB START (jws).
Com isso podemos garantir que a versão que o cliente estará usando será a mais atual, podendo ser feito atualizações do client!