Vemos diariamente muitos profissionais referindo-se a serviços, e para isso, valendo-se de diversas expressões parecidas, porém não iguais. A dúvida para quem é iniciante é sempre inevitável: A final, qual a diferença de “Spring MVC”, “Spring Plataform”, “Spring Framework” e somente “Spring”.
No desenvolvimento de uma aplicação, Spring é o que exatamente? Um meddleware? Um application Server? Deve ou pode ser usado em conjunto com um Application Server tal como JBoss ou Glassfish ? Quando usar uma coisa ou outra?
Executarei as classes remotamente ou localmente em minha aplicação? Para executar remotamente é impressindível um JBoss ou Glassfish ou o Spring tem funcionalidades suficientes para isso?
Vou explicar melhor: Estou iniciando um projeto. É de médio porte e acredito que poderia ser feito client/server (a princípio). Ao menos no início, atenderia. Ele terá uma interface GUI Swing, em princípio. Estou elegendo OpenSwing como framework para suportar o View.
Porém, gostaria de escrever a aplicação em uma arquitetura MVC, pra futuramente adicionar interfaces Web. Porém até o momento tem que ser Swing obrigatoriamente.
Entretanto, preciso de escalabilidade nesta aplicação, pois ela pode crescer bastante e Client/Server vir a se tornar uma limitante. Neste caso seria interessante dividir a aplicação em 3 camadas. Seria necessário um JBoss ou Glassfish para tonar minhas classes e tranzações remotas?
A
amhfilho
O uso de servidores de aplicação é recomendável porque eles oferecem uma série de recursos padrão para aplicações empresariais. Não há nenhum problema em desenvolver client-server tradicional, mas você vai desenvolver toda a camada de conexão RMI pra chamar métodos remotos? Você vai ter que programar uma série de coisas de mais baixo nível que os servidores de aplicação já trazem prontos, através de APIs e bibliotecas.
O Spring é um framework destinado a aplicações enterprise que oferece uma série de funcionalidades que complementam e facilitam ainda mais o desenvolvimento, além do que ele traz uma série de boas práticas de arquitetura que podem ser facilmente utilizadas pela sua aplicação. Com o Spring você não precisa trabalhar com um container EJB pesado, como o JBoss ou Glassfish, pois ele já traz uma série de recursos que estes servidores implementam.
Como você menciona que deseja uma interface Swing e depois uma Web utilizando os mesmos componentes de negócio, eu recomendaria uma arquitetura 3 camadas. Você pode ter a regra de negócio com POJOS, EJBs ou componentes Spring, para a camada de serviços ou aplicação e depois uma camada Swing apenas com a tela e código de manipulação de eventos. Isto é só uma possibilidade.
Recomendo que você estude um pouco mais este tema, o livro do Martin Fowler - Patterns of Enterprise Applications é um ótimo começo.
Qualquer coisa posta aí.
M
MWAdriano
amhfilho:
O uso de servidores de aplicação é recomendável porque eles oferecem uma série de recursos padrão para aplicações empresariais. Não há nenhum problema em desenvolver client-server tradicional, mas você vai desenvolver toda a camada de conexão RMI pra chamar métodos remotos? Você vai ter que programar uma série de coisas de mais baixo nível que os servidores de aplicação já trazem prontos, através de APIs e bibliotecas.
O Spring é um framework destinado a aplicações enterprise que oferece uma série de funcionalidades que complementam e facilitam ainda mais o desenvolvimento, além do que ele traz uma série de boas práticas de arquitetura que podem ser facilmente utilizadas pela sua aplicação. Com o Spring você não precisa trabalhar com um container EJB pesado, como o JBoss ou Glassfish, pois ele já traz uma série de recursos que estes servidores implementam.
Como você menciona que deseja uma interface Swing e depois uma Web utilizando os mesmos componentes de negócio, eu recomendaria uma arquitetura 3 camadas. Você pode ter a regra de negócio com POJOS, EJBs ou componentes Spring, para a camada de serviços ou aplicação e depois uma camada Swing apenas com a tela e código de manipulação de eventos. Isto é só uma possibilidade.
Recomendo que você estude um pouco mais este tema, o livro do Martin Fowler - Patterns of Enterprise Applications é um ótimo começo.
Qualquer coisa posta aí.
Uma dúvida: Eu poderia escrever componentes da minha aplicação com Spring+ORM na camada de negócio como se fosse um servidor de aplicação aguardando por chamadas remotas? Daí eu teria a camada View acessando dados remotamente ? Seria mais ou menos isso? Tipo, o Swing seria o View (rodando em um computador terminal, com uma JVM)… Conectaria em minha aplicação rodando em outra JVM em outro computador (atravéz de RESTFull ou SOAP, RMI ou outro) com classes “controllers” e componentes Spring que por sua vez acessaria o modelo atravéz de um ORM, Hibernate? Desse jeito fica mais leve que com um JBoss ou GlassFish da vida?
Me ajuda se viajei na batatinha, ou se é mais ou menos por aí…
[]s.
A
amhfilho
É mais ou menos isso. A vantagem do Spring é que ele traz imbutido uma série de facilidades encontradas em Servidores JEE, no entanto você pode usar um container leve como Jetty ou Tomcat. (eu acho que no próprio Spring tem um container também).
Uma arquitetura 3 camadas clássicas, segundo o livro do Fowler (tópico “The Three Principal Layers”):
Presentation: Toda a parte de interação com o usuário, aqui vai ter as telas Swing, as classes controladoras de evento, o HTML, o JSP, seus Servlets e ManagedBeans do JSF ou Actions do Struts
Domain: Todo o código relacionado à regra de negócio. Procure desenvolver esta camada apenas com POJOS, sem colocar código de infra-estrutura (banco de dados, mensageria, acesso a arquivos, rede, etc)
Data source: Todo o código de acesso à banco de dados, mensageria, gerenciadores de transação, web services. (muitas vezes aqui encontramos o bom e velho DAO)
Hoje em dia com os sistemas utilizando ORM (Hibernate , JPA) , colocamos as anotações de banco de dados nas classes de Domain. Isto facilita muito o desenvolvimento mas dá uma leve “violada” nas regras clássicas. Nada que não se justifique com o ganho de produtividade, aliado às boas regras de anotar as classes e não estender nem implementar, o que causa um baixo acoplamento. Tem mais um trecho do Fowler interessante, que coloco na íntegra:
Para um ponto de partida prático, abra sua IDE e crie 3 projetos , um para cada camada: um projeto Java puro para Domain, um projeto JPA para Data Source e um projeto Web para presentation. Desenvolva com o mínimo de dependências de código entre eles. Para começar acho esta abordagem interessante.
Esta é a arquitetura clássica, por qual muitos sistemas foram desenvolvidos e continuam até hoje. Você pode partir daí. Hoje já se utilizam arquiteturas 4 camadas que algumas vezes se tornam mais eficientes.
Eu recomendaria que você lesse alguns artigos do Philip (http://blog.fragmental.com.br/) sobre arquitetura de sistemas, apesar de ele estar falando mais de Agile no momento ou do Guerra na Mundo Java, que é um arquiteto nato. Tem bastante coisa no blog da caelum também.
M
MWAdriano
Vou tentar sim… Mas outra dúvida surgiu… Eu nunca fiz uma aplicação Web (fiz umas coisinhas JSP a muuuito tempo atráz - em 2001 - mas usava Resin com JCreator) e hoje eu uso o Netbeans 6.9 para aplicações Swing. Quando eu vou iniciar no Netbeans um “Projeto Web” ele obrigatoriamente não me deixa seguir o Wizard do novo projeto sem selecionar um servidor de aplicação registrado na IDE (JBoss ou Glassfish). Mas se eu vou apenas utilizar o Spring direto e sem usar servidor de aplicação, como “pular” essa parte?
[]s.
F
fabiopreti
Adriano,
Creio que você está confundindo um pouco o conceito.
Toda aplicação WEB feita em java precisa de um WEB Container para rodar, seja ele considerado “LEVE” (Jety, Tomcat, etc) ou pesado (Jboss, GlassFish).
Normalmente oque diferencia essa classificação de leve ou pesado para um container é se ele implementa ou não as especificações da SUN para o JEE (Java Enterprise Edition). Em caso afirmativo, o servidor de aplicação precisa ser um WEB Container + EJB Container (como o JBOSS e o GLASSFISH são).
Resumindo, mesmo que você não vá usar EJBs (portanto não vai precisar de um EJB Container) você sempre irá precisar de um WEB Container.
Att
M
MWAdriano
Sim… Realmente eu confundi, porque não percebi que podia escolher o Tomcat e outros containers Web. Achei que ele só aceitava containers EJB obrigatoriamente.
