Arquitetura de Desenvolvimento

Preciso de ajuda!

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?

Obrigado

Thread.start() Membro desde: 21/01/2008 13:45:00 Mensagens: 42 Offline

Mateus,

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.

Boa sorte,

JavaBaby Membro desde: 13/09/2011 07:17:01 Mensagens: 95 Offline

Amigo eu indicaria a vc usar RMI.

Acho que o RMI-IIOP irá me atender mesmo!
Estou estudando!

Alguém terial algum tutorial para indicar?
Estou seguindo esse:
http://javafree.uol.com.br/artigo/847574/Invocacao-Remota-de-Metodos-RMI-no-TIGER.html

spring + jpa / hibernate, hibernate, jdbc (se não confiar no poder ORM) + doc para ajudar futuras manutenções + melhor codificação possível.

O spring fara a parte RMI + transações de forma praticamente transparente.

flws

Thread.start() Membro desde: 21/01/2008 13:45:00 Mensagens: 42 Offline

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.

This message was edited 1 time. Last update was at 29/11/2011 17:42:19

Ah, em relação ao que estudar:

- 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.

Espero ter te ajudado com informações úteis.

Marcelo!
Muito obrigado pelas dicas!
Já estou montando um prototipo para verficar se atenda as nessecidades do cliente!

Obrigado pela ajuda!

Galera, uma coisa que eu esqueci, é o seguinte:

- Performace!

Isso será acessado por mais 300 pessoas!
Será que suportaria?

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

- A interface: será em swing (pois o objetivo é uma performace na digitaçã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?

- 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?

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?

Sim....vc pode usar SOCKET, RMI, SOAP, REST ou EJB.

Qual servidor de aplicação usar?

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?

Obrigado pela ajuda!

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

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!

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.

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!

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?

Cara essas perguntas são para ajudar?
O que vc indica com seus anos de experiencias?

É 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.....

Se sim, como posso ter um modo que tenha uma grande performace?
Tanto para digitar, quanto para processar as informações?

Existem algumas abordagens numa arquitetura geral para se melhorar a performance de uma solução, as mais básicas são:
- Reduzir ao máximo interações/invocações remotas sincronizadas (SGDB, MOM, WS, FILE SYSTEM, MAINFRAME etc)
- Uso de cache, evitando de invocação remotas sincronizadas (SGDB, MOM, WS, FILE SYSTEM, MAINFRAME etc)
- Preferir comunicação assíncronas com recursos externos (SGDB, MOM, WS, FILE SYSTEM, MAINFRAME etc)
- Uso de AJAX para web.
- Processos mutltthread para desktop (nativo).
- Reduzir lock de recursos.
- Algoritmos mais eficientes para cada contexto.
- Uso de pooling.
Por exemplo, EJB tem chamadas remotas...chamadas remotas são os maiores vilões de performance.

O que vc indica com seus anos de experiencias?

1. Colocar todos os requisitos na mesa, suposições, cenários, etc..
2. Implementar cases que comprovem alguma ideia, suposição ou "achometro".
3. 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.

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.

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.

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....

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.

Obrigado pela ajuda!

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

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.

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.

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! $$

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).

Notícias, artigos e o maior fórum brasileiro sobre Java