Artigo Java Magazine 64 - Aplicações Corporativas com jCompany Free

Figura 1. Dimensões do jCompany Developer Suite com segmento do jCompany Free em destaque.

Como ilustra a Figura 1, a suíte comercial ataca a questão da produtividade também por outras dimensões além do framework integrador disponibilizado no jCompany Free. Porém, o jCompany Full Stack Framework, área em destaque na Figura 1, agrega grande valor ao desenvolvimento Java EE, visto que engloba a generalização radical de código MVC2 monótono (Boiler-Plate). As demais dimensões são:

·          jCompany IDE: plugins Eclipse geradores de artefatos "não-Java" como formulários Web, configurações XML, properties, anotações (metadados), etc. (Importante: o jCompany é eminentemente uma solução OO. Este módulo não traz geradores de códigos Java, mas somente de artefatos não generalizáveis, como JSPs e descritores);

·          jCompany Test For Developer: framework integrador de "última milha" para Testes de Unidade;

·          jCompany Patterns & Methods: documentos de "padrões e métodos" para modelagem e especificação (Modelo de Classes, Casos de Uso, Estados e Interfaces com o Usuário);

·          jCompany Configuration Management: gerência de configuração que embala, pré-configura e evolui mais de 40 produtos Open-Source distintos em uma única versão, sendo mais de 20 somente na parte framework.

O conhecimento do que está fora da versão GPLv3 é importante para quem inicia no jCompany Free, pois grande parte da documentação disponível considera as demais dimensões da versão comercial (especialmente do jCompany IDE). O livro "Tirando o Máximo do Java EE 5 Open-Source com jCompany Developer Suite", por exemplo, disponível em eBook no site da Powerlogic (www.powerlogic.com.br), pode ser útil, uma vez que o desenvolvedor reconheça esta distinção e busque formas alternativas de substituir as dimensões não incluídas.

Arquitetura do jCompany Free

O jCompany Full-Stack Framework é considerado um framework integrador de penúltima milha devido ao seu posicionamento na pilha da arquitetura de software corporativa recomendada, ficando acima de um grande número de frameworks “de base” reutilizados (inclusive integradores de mais “baixo nível”, como o JBoss Seam) e abaixo de uma camada chamada Bridge, para contextualizações corporativas, espaço destinado à empresa cliente. Veja o esboço mais macro da arquitetura na Figura 2.

Figura 2. Arquitetura preconizada pelo jCompany Free.

Perceba que este esquema introduz dois aspectos sutis, mas bastante significativos, que maximizam o reuso e a padronização em uma arquitetura de software com base em produtos Open-Source, quando se fala em aplicações comerciais que manipulam formulários em larga escala:

·          Uma camada “c” reutilizada, que permite o repasse da responsabilidade pela prospecção, integração, evolução, homologação e manutenção conjunta dos mais de 20 frameworks de base para a comunidade do jCompany Free. Esta é a “penúltima milha da arquitetura”;

·          Uma camada “d” de responsabilidade da empresa, que isola as implementações de negócio (representadas em "e") da arquitetura de base do jCompany Free e viabiliza que a empresa evolua ou altere qualquer padrão integrado de alto nível, generalizado na base. Esta é a “última milha da arquitetura”, ou seja, depois dela começamos a pensar em casos de uso e regras de negócio.

Deste modo, viabilizamos o reuso com maior abstração: o arquiteto parte de um patamar bem mais alto do que partiria de um Spring ou JBoss Seam, por exemplo, reutilizando uma arquitetura de base opinativa, que define padrões em nível de caso de uso, incluindo formulários completos, seqüência de controle MVC generalizada e padrões de programação para extensão. Quando preciso, o arquiteto pode evoluir as definições de arquitetura para uma empresa ou para um portfólio específico de projetos por exceção, implementando variações a estes padrões na camada Bridge.  

Por sua vez, os desenvolvedores trabalham de forma inteiramente desacoplada do jCompany Free (nenhum “import”!), trabalhando sobre uma arquitetura contextualizada, que reduz sensivelmente a quantidade de códigos Java e a variabilidade indesejável[1] na camada de negócio, como veremos. Quando preciso, ele também pode usar todos os recursos que os frameworks de base disponibilizam, interceptando as diversas partes do código através de “Template Methods” ou sobre-escrevendo alguma funcionalidade do framework inteiramente.

Sob outro ângulo, a arquitetura MVC2[2] implementada pelo jCompany Free tem a organização ilustrada pela Figura 3.

Figura 3. Arquitetura MVC2 do jCompany Free.

Ela mostra as camadas típicas de um desenvolvimento MVC2, que o leitor já deverá conhecer. Para nosso perfil alvo de aplicações, a camada mais nobre costuma ser a de Domínio, que conterá classes em sua maioria persistentes e que representam entidades do negócio.

No jCompany Free a camada de Domínio é ortogonal, isto é, pode ser acessada por todas as outras camadas da arquitetura, e suas classes seguem o padrão “Entity Beans” da JPA, conforme definido no Java EE 5. POJOs são visíveis por todas as camadas do MVC2, evitando-se DTOs ou hierarquias paralelas e redundantes de dados. Por sua vez, estas entidades não dependem de outras camadas, sendo as mais estáveis da arquitetura. Em um próximo artigo desta série, veremos ainda que estas classes irão conter regras encapsuladas – e não somente dados, como os antigos Value Objects (VOs) dos Blue Prints J2EE, viabilizando uma programação Domain-Driven Design (DDD) conciliada com abordagens distribuídas (ex.: SOA).

Se nos aprofundarmos na arquitetura interna de cada camada, veremos que o jCompany Free ainda categoriza classes, em cada camada, definindo claramente seus papéis na arquitetura. Para tanto, utiliza sufixos padrões (customizáveis em nível de aplicação ou global) como Action, Controller, Facade, Service, AS (Application Service), DAO, Entity e Helper. Cada uma destas categorias já costuma conter código generalizado e evoluído por cinco anos para contemplar uma série de situações típicas (Manutenções de ciclo de vida de agregações de objetos e diversas variações relacionadas, em sua maior parte).

Cada classe genérica, em cada camada, permite programação via DP Template Method (com herança) ou DP Strategy (via Interface), ambas para codificação “por exceção”. Não temos espaço no primeiro artigo para esta discussão, o que fica então para uma continuação.

Frameworks “de base” reutilizados

Os principais frameworks de base integrados, evoluídos e homologados pelo jCompany Free estão relacionados na Tabela 1, segmentados por camada MVC2.