Arquitetura de Desenvolvimento

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,

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

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.

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?

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.

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?

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!

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!

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?
O que vc indica com seus anos de experiencias?

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

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

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.

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…

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!

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.

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

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.

Vejamos os fatos:

Requisitos mencionados:

• performance
• ser acesso por mais de 300 usuários.
• usuário tem que digitar rápido os textos.
• arquivo fonte não pode ser acessado.

Decisões tecnologias

• EJB
• camada de visão swing.

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!