Projeto MiddleHeaven - Sergio Taborda

Assuntos Gerais
#1

[size=18]Projeto MiddleHeaven[/size]

[color=blue]Gostaria de Saber se alguém, chegou a usar esse projeto e se fez alguma implementação achei interessante mas não sei como utiliza-lo.[/color]

:arrow: http://middleheaven.wordpress.com/about/

Por Sergio Taborda,

Depois de alguns anos usando e construindo frameworks a partir de bibliotecas de terceiros fiquei cançado de repetir sempre as mesma coisa.

A ideia por detrás do Middleheaven é construir um framework sobre o qual aplicações possam ser construídas independentemente do ambiente onde elas irão ser executadas ou qual o tipo de apresentação ao usuário. Desde aplicações web servidas por navegadores, a aplicações desktop standalone com controle de licença a aplicaçãoes desktop distribuidas ou a integrações de serviços.

Por baixo dos panos muitas bibliotecas de terceiros e aderência aos padrões da plataforma Java atuais (o MiddleHeaven aponta para funcionar em Java 7) conferem a solidez necessária.

Por isso, o Middleheaven será o único framework que você irá precisar.

Quando as tecnologias mudarem ou os padrões mudarem, quando novas formas de fazer e distribuir software na plataforma Java forem criadas a suas aplicações não serão re-escritas. Simplesmente mudar o jar do Middleheaven e voilá.

Assim, o objetivos primários do Middleheaven são:

* Minimizar todo o esforço de implementação de requisitos não funcionais - implementar requisitos comuns, mas não padronizados, como a possibilidade de upload de arquivos em sites, é chato retirando foco do verdadeiro objetivo da aplicação.
* Minimizar a dependencia de bibliotecas de terceiros - a sua aplicação depende fortemente das classes do Middleheaven mas não depende de classe fora dele. Assim, quando o Middleheaven decidir utilizar uma biblioteca de terceiros diferente , ou quando a biblioteca usada for alterada pelos seus desenvolvedores isso não terá impacto nenhum na sua aplicação.
* Minimizar a re-implementação de padrões de negocio. Padrões de aplicação já consagrados são incluidos desde o principio como o padrão Money. Além disso esses padrões são incluidos dentro de um contexto de modo a permitir o máximo de reuso e flexibilidade.

Estas permissas são levadas ao extremo e expressas directamente em features especificas:

* MVC Universal: A sua logica de controle de apresentação é totalmente desacoplada da tecnologia usada para a apresentação. Isto permitirá que aplicações Middleheaven tenham interfaces web e desktop simultaneamente controladas pelo mesmos objetos de apresentação.
* Acesso Ubiquo a Dados: Acesso a dados pode ser feito de qualquer nodo do sistema e para qualquer tipo de armazenamento.  Um coração fortemente orientado ao dominio é provido de acesso a repositorios de dados em bancos de dados relacionais, bancos de dados orientados a objectos, arquivos XML e outros mecanismos especiais como acesso remoto de dados.
* Estrutura forte para tratamento de quantidades. Datas, tempos, intervalos, dinheiro , medidas e conversões estão no coração do Middleheaven.
* Mecanismo de injeção automática de dependências
* Mecanismo de bootstrap para que uma mesma aplicação funcione em diferentes ambientes e o ambiente possa injetar as suas proprias implementações dos serviços primários.
* Aplicações desenvolvidas em módulos individuais e interdependentes como resolução automática de dependencias.
* Carregamento ?a quente? de serviços de modulos de aplicação
* Mecanismo de autenticação e autorização.

Dado o vasto campo que o projeto MiddleHeaven visa abraçar não é possivel fazê-lo de um só vez. Para isso as funcionalidades do MiddleHeaven são divididas em Caixas de Ferramentas ( Toolboxes) para que seja mais simples organizar o conjunto de funcionalidades. Estas toolboxes não necessáriamente se mapeiam para pacotes de classes, mas normalmente é isso que acontece.

#2

gostaria de saber quantas pessoas tem desenvolvendo essse mega super monstro ^^

quantos são na equipe ?? é um projeto muito ambicioso…

acompanho muito os artigos do sergio, mas o middle como era tudo em ingles, ficava dificil, agora vou guardar um tempo amanha pra ler sobre os toolboxs ^^

#3

Realmente impressionante o escopo do projeto.

Eu particularmente fico com receio desses projetos que visam ‘resolver todos os problemas’, embora esse parece mais sólido dos que eu vi antes.

Infelizmente estou sem tempo livre atualmente mas tenho grande interesse por ver uma aplicação prática desse projeto.

Se vc for fazer um teste Márcio, por favor poste os resultados e suas experiências com o Framework.

Abs

#4

[quote=GraveDigger]Realmente impressionante o escopo do projeto.

Eu particularmente fico com receio desses projetos que visam ‘resolver todos os problemas’, embora esse parece mais sólido dos que eu vi antes.

Infelizmente estou sem tempo livre atualmente mas tenho grande interesse por ver uma aplicação prática desse projeto.

Se vc for fazer um teste Márcio, por favor poste os resultados e suas experiências com o Framework.

Abs[/quote]
Eu estou meio que viajando nesse MiddleHeaven, abaixei o arquivo jar mas pelo que me pareceu ou que pude já entender é que o ToolBox visa ser objetos que absorvido em determinado FrameWorks se encaixa como um plugin que já resolve aplicações como aplicativos desacoplados e independente de plataforma.
Gostaria de ver a maneira algo como em um screencast ou algo que seja mais pratico para entender, tanto que o uso de JPA é descartado em questão de performance de persistencia no argumento do Sergio Taborda. Gostaria de melhores explicações ou mais fontes de informação em um contexto pratico.

Abrass

#5

[quote=Lavieri]gostaria de saber quantas pessoas tem desenvolvendo essse mega super monstro ^^

quantos são na equipe ?? é um projeto muito ambicioso…

acompanho muito os artigos do sergio, mas o middle como era tudo em ingles, ficava dificil, agora vou guardar um tempo amanha pra ler sobre os toolboxs ^^[/quote]
Mas veja, é o Sergio que esta fazendo ou uma equipe, quem esta por tráz desse projeto.

#6

Pelo blog, ele está só por enquanto, mas está procurando pessoas que o ajudem.

#7

Pelo blog, ele está só por enquanto, mas está procurando pessoas que o ajudem.[/quote]

Tem algo pratico ai, tem muita teoria você chegou a usar o Jar, usou a ToolBoxes é isso que quero entender, acho que esse projeto pode dar um upgrade para um start melhor a usar esses controladores como Vraptor, Mentawai entre outros frameworks que ele mesmo diz que produzem melhores resultados, para uso desses aplicativos que ele vem escrevendo, quero um exemplo mesmo que seja um Hello World, estou meio que viajando…

#8

Duvido que alguem esteja usando o MiddleHeaven já que nem está pronto. A versão que foi liberara (que já está desatualizada) era para testes e para sentir o felling. Se existe alguem por ai usando o MH neste estágio, por favor, não o faça.

A equipe sou eu, eu próprio e mim mesmo. O objetivo é realmente interessar mais pessoas, mas realmente não é uma coisa que me preocupa. O problema é que o MH foi criado uma uma série de diretivas que precisam ser respeitadas a cada design e isso é complicado de orquestrar com 1 fazendo, imagine-se com mais.

Realmente só agora cheguei em um estágio em que posso fazer aplicações web simples ( à lá VRaptor/Menta, etc…) mas o escopo é maior que esse.
Houve um tempo “perdido” na toolbox de quantidades ( toolbox é um nome que significa “área do framework” , alguns chamam de modulos, mas como “modulo” tem outro significado - representa uma parte de uma aplicação - tive que arranjar outro nome) . Quando isso ficar mais ou menos redondo teremos exemplos de uso.

A toolbox de injeção (wiring) está sendo remodelada agora proque havia muita coisa dispersa relativa a criação de objetos. O de persistencia tam precisa umas alterações.

sim, é um projeto enorme que realmente visa resolver todos os (meus) problemas. não vou enganar ninguem dizendo o contrário.
O desenvolvimento é lento porque tudo tem que ser bem pensado para respeitar várias diretrizes, boas práitcas , etc… além do constrangimento de só ir sendo feito no meu tempo “livre”.

Ainda não é hora de o usar, mas é hora de o entender. É para isso que criei o novo blog.

#9

Apenas uma pergunta, se posso fazê-la: Ao que percebi, muitas das implementações que estão para serem feitas e outras que já estão “terminadas” são coisas que existem já no mercado. Seria uma junção de frameworks ou está tudo sendo criado do ZERO?
Grato

#10

[quote=djemacao]Apenas uma pergunta, se posso fazê-la: Ao que percebi, muitas das implementações que estão para serem feitas e outras que já estão “terminadas” são coisas que existem já no mercado. Seria uma junção de frameworks ou está tudo sendo criado do ZERO?
Grato[/quote]

ambas as coisas. As funcionalidades já existem quase todas no mercado mas não de forma integrada. Sim, outras bibliotecas são usadas por baixo dos panos (Commons Upload , Commons VFS , entre outras) mas ao programar para o MH vc são usa essas bibliotecas, vc nem saberia que estão lá ( se não olhasse o o classpath :wink: ) A ideia é que a implementação interna do MH pode mudar para usar outras bibliotecas ou implementar do zero as coisas, mas sem nunca forçar a aplicação escrita como MH a mudar tb. Pense no MH como : o MH é para aplicações o que a JVM é para a um .class.

“integrada” não singnifica " coloca tudo junto e bate" como no Spring, singifica que funciona junto sem que vc saiba.

#11

Acho que todos podem colaborar com o MiddleHeaven, incluse estou lendo também o Blog em Inglês, mas partindo do principio que você diz que o desenvolvimento é lento e é necessários pensar em regras e diretrizes que devam ser colocadas corretamente, como então pensar em termos de colaboração ao mesmo projeto, vamos ter que esperar ao primeiro Release Beta, a idéia me pareceu muito interessante mas a pratica ela é ainda distante de ser.

#12

[quote=sergiotaborda][quote=djemacao]Apenas uma pergunta, se posso fazê-la: Ao que percebi, muitas das implementações que estão para serem feitas e outras que já estão “terminadas” são coisas que existem já no mercado. Seria uma junção de frameworks ou está tudo sendo criado do ZERO?
Grato[/quote]

ambas as coisas. As funcionalidades já existem quase todas no mercado mas não de forma integrada. Sim, outras bibliotecas são usadas por baixo dos panos (Commons Upload , Commons VFS , entre outras) mas ao programar para o MH vc são usa essas bibliotecas, vc nem saberia que estão lá ( se não olhasse o o classpath :wink: ) A ideia é que a implementação interna do MH pode mudar para usar outras bibliotecas ou implementar do zero as coisas, mas sem nunca forçar a aplicação escrita como MH a mudar tb. Pense no MH como : o MH é para aplicações o que a JVM é para a um .class.

“integrada” não singnifica " coloca tudo junto e bate" como no Spring, singifica que funciona junto sem que vc saiba.[/quote]
Quando falou do Spring foi bem o que pensei. No que este framework teria que o Spring não tem ou é melhor se tem?

#13

[quote=djemacao][quote=sergiotaborda]
“integrada” não singnifica " coloca tudo junto e bate" como no Spring, singifica que funciona junto sem que vc saiba.[/quote]
Quando falou do Spring foi bem o que pensei. No que este framework teria que o Spring não tem ou é melhor se tem?
[/quote]

O Spring é o que mais se aproxima do MH. A diferença principal é que o Spring é um motor de injeção em primeiro lugar. Ele não é uma framework. Por exemplo, se vc quer ter acesso a dados vc pode usar o hibernate , o ibatis ou jdbc puro… vc usa o frameowrk de acesso a dados X. O Spring apenas fornece classes para ser fácil injetar X, mas ele não esconde que vc está usando X, então se X mudar , vc tem que mudar seu codigo, e provavelmente passar a usar uma versão diferente do Spring. O Spring é uma cola para peças já feitas mas as deixa visiveis. O middleheaven não é uma cola. É uma plataforma para criar aplicações. A plataforma fornece serviços necessários às aplicações. Tanto serviços de “código” como injeção automática , serviços de infra como envio de email acesso a dados e serviços de negocio como o serviço de atlas , controle de licença e implementações de padrões de aplicação como money e account.

O objetivo é que possa ser possível criar uma aplicação relativamente complexa em pouco tempo, mas sem ferir boas práticas ou ter que depender de bibliotecas externas diretamente. Este principio de encapsulamento de tecnologias é que é a grande diferença.

Por exemplo, para acesso a dados ( baseado em modelo de dominio) vc usa um DomainStore e um StoreKeeper. O storeKeepe representa o objeto que realmente escreve e lê. Vc pode escolher uma que usa banco de dados (semelhante ao hibernate) um que usa apenas a memoria ( para testes) , um que é um banco de dados de objetos ( estou testando o neodatis) ou um que é uma interface remota para um outro Storekeeper em outro lugar (no servidor, por exemplo. Assim vc pode ter partes da aplicação distrbuidas mas sempre com uma arquitetura semelhante. Por isso seria fácil tornar uma aplicação swing standalone em uma distribuida via JWS como AS central bastando mudar algumas peças ( serviços) na configuração da injeção. )

Mas veja um exemplo de um teste:

package org.middleheaven.storage;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;

import java.io.File;

import org.junit.Test;
import org.middleheaven.domain.DomailModelBuilder;
import org.middleheaven.domain.DomainClasses;
import org.middleheaven.domain.DomainModel;
import org.middleheaven.io.repository.ManagedFile;
import org.middleheaven.io.repository.ManagedFileRepositories;
import org.middleheaven.storage.criteria.Criteria;
import org.middleheaven.storage.criteria.CriteriaBuilder;
import org.middleheaven.storage.odb.ObjectStoreKeeper;


public class TestODB {

	
	@Test
	public void testSimpleAdd(){
		ManagedFile dataFile = ManagedFileRepositories.resolveFile(new File("./objdata.data"));
		ObjectStoreKeeper keeper = new ObjectStoreKeeper(dataFile);
		
		final DomainModel model = new DomailModelBuilder().build(
				new DomainClasses().add(Subject.class)
		);
		
		DataStorage ds = new DomainDataStorage(keeper , model);

		// read all
		Criteria<Subject> c = CriteriaBuilder.search(Subject.class).all();
		
		Query<Subject> q=  ds.createQuery(c);
		
		long previous = q.count();
		
		Subject to = new Subject();
		to.setName("Name");
		
		Subject to2 = ds.store(to);
		
		assertNotNull(to2.getIdentity());
		assertEquals(previous+1,q.count());
	}
}

Veja que não importei nada que não fosse do MH (excepto o Junit por razões obvias). Essa é a grande diferença.
Se no futuro resolver implementar o ObjectStoreKeeper com outra tecnologia que não o NeoDatis, este código não muda nada. A ideia de que o código da aplicação não deve mudar quando a tecnologia muda é um dos objetivos principais do MH. Isso não acontece com o Spring. Fora que com o Spring vc ainda tem que conhecer os outros frameworks e saber e entender como as coisas encaixam.

#14

Obrigado Sérgio,

É exatamente o que eu queria saber. Sei que o Spring não está tudo a mão e que realmente precisa conhecer os demais frameworks. Mas agora outra pergunta: o que vai estar por trás do seu framework?
Quando utilizar um determinado pacote, para IoC por exemplo, quem estará lá? O mesmo para JPA e por ai vai.

PS: O Spring eu considero um framework sim, porém, não um completo e nem complexo. Embora ele tenha começado com injeção, hoje ele faz o “glue” de muitas coisas coisas. Mas como já disse, cada uma dessas “coisas” dependem do conhecimento específico para “encaixar” tudo.

Grato pela resposta.

#15

Se está à espera que eu responsa alguma coisa da ultima moda , vou ter que o desiludir.
O IoC automático é feito pelo próprio MH. Aliás esta é uma parte que eu não tinha introduzido no principio porque pensei que era apenas um jeito de facilitar as coisas, mas cheguei À conclusão que é mais que isso. Veja, o MH é um framework, o que significa que é necessária cumprir algumas regras para que ele entenda onde está o ponto inicial da sua aplicação. Mas ao mesmo tempo a aplicação é entendida como um conjunto de modulo que significa que não ha 1 aplicação e sim um enxame de modulos que juntos são a aplicação. Eles têm dependencias entre si e existiria um serviço de inicialização da aplicação. Até ai tudo bem, só que cheguei a reconhecer que isso é exactamente o que o injetor faz. No incio a ideia era mais orientada no estilo OSGI , mas o OSGI tem uma implementação baseada em java 1.2/1.4 o que singinifica nada de generics ou annotations. Existe um serviço OSGi ( de que não me lembro o nome agora) que faz injeção via XML. É bem legal. Mas isso o spring tb faz e eu sempre achei um saco.
Poderia usar o Guice - que eu acho muito melhor desenhado que o spring - mas ele usa anotações. Ele não vai entender as anotações dos outros. Como eu já falei aqui no GUJ anotações também são pontos de dependencia tal como extender interfaces. Para mim, não ha diferença. Ai teriamos um lock-in com o Guice o que a diretiva principal do MH impede. Então,tive que arranjar um sistema de injeção que pudesse ler qualquer tipo de informação de onde injetar as coisas. Annotações é legal, mas XML é uma opção para algumas coisas ou quem sabe no futuro tem outras opções ? ( uma que quero ainda experimentar é configuração via groovy ) O ponto é que sendo o MH desenhado para entender qualquer forma , qualquer forma pode ser usada.
Um atenção especial vai sempre para a plataforma java e o que já é padrão nela. Isso com certeza terá um suporte out-of-box ( como jpa e @Resource ) até onde for possivel, mas o “motor” por detrás dos panos tenta não se prender nesses detalhes. E é por isso que é muito lento desenvolver o MH porque ha muita coisa a pensar e a tomar em consideração.

Por outro lado o MH tem a diretiva de ser um isolador de tecnologias o que significa que ele não pode abraçar nenhuma em particular. Logo ele pode prover um serviço que se encaixe com a tecnologia X mas não pode ser baseado na tecnologia X.
Assim, JPA não é o foco do MH, já que ele conta com o seu próprio suporte a persistência. A persistencia do MH é baseada em duas coisas : Modelo de Dominio e Modelo de Persistência. O modelo de dominio diz o que a sua aplicação faz/é e o de persistencia apenas diz ao Storekeeper como guardar os dados do dominio, é especifico por StoreKeeper e alguns não precisam dele.

Logo, se vc tiver um JPAKeeper , vc terá um modelo de persistencia lido directamente das anotações JPA. O problema com o o JPA (na versão atual) é que é extremamente direcionado a banco de dados e o DataStorage do MH é agnóstico. Eles são incompativeis.
O MH usa objetivos de Critério (Criteria) e o JPA não tem nada como isso. Claro que poderia traduzir o objeto para a linguagem do JPA ( que é SQL) mas vai dai, traduz direto para SQL e para o banco e esquece JPA. E isso tem vantagens e desvantagens adicionais.

O MH baseia-se no padrão DomainStore que é mais geral que apenas para banco de dados e é isso que marca a diferença.
Vc pode injetar diferentes keepers conforme o contexto ( swing / web , alone/ distribuido) da aplicação e o ambiente ( homologaçao, produção , teste, desenvolvimento) .

As api que o MH usa são realmente de “baixo-nivel” por assim dizer. Mas ha algumas de alto nivel que realmente são insuperáveis por agora. Para reports temos o JasperReport e para gráficos o JFreeChart. Apesar da jasperreposts ser uma biblioteca muito bem desenhada que não é vinculada ao uso de banco de dados ( o que é excelente) a api da jfreechart é muito mais complexa do que deveria, mas é a que apresenta uma maior variedade de gráficos. Contudo o MH encapsula estas duas bibliotecas para prover valor às aplicações de negócios. A de reports é a unica em que vc precisa conhecer a ferramenta , mas aqui vc usa o IReport e deixa o resto conta do MH.

A parte de segurança vai ser própria tb , mas integrável com JAAS ( não são todas?) e segue um pouco a linha do Acegi. A diferença é que o Acegi foi fortemente pensado no ambiente web, mas não em ambiente isolado (acesso à conta do windows?). JNDI tb tem que estar presente, embora por baixo de um serviço MH e assim vai. No desktop temos swing como principal mas com um mecanismo de renderização que permite escolher qualquer tecnologia que vc quiser. AWT e SWT podem ser candidatos tb. SWT é especialmente importante para permitir criar plugins do eclipse. Para web teremos três niveis de interface (4 se contarmos ajax) um é o web arroz-com-feijao que todo mundo conhece no estilo strusts/spring mvc/ mentawai/ vraptor e afins … com muito mais forte suporte a injeção de parâmetros qeue spring e total independência da api de servlets O que permitirá embutir servidores web em aplicações standalone que queiram prover web-services ( por exemplo o emule usa algo semelhante)
Algumas taglibs para ajudar e tudo isso que vcs já conhecem. Porquê ? porque é o tipo de interface mais simples de construir ( básicamente é encapsular a api de servlets)
Depois temos a interface REST. Esta é especialmente desenvolvida para coisas remotas e distribuidas. Pode ser para web/services,mas pode ser simplesmente para responder a algum ajax. Ainda está em fase de desenho.Por fim temos a interface tipo desktop ( que é o objetivo principal) . A ideia aqui é sendo que o sistema de renderização aceita qq coisa como Swing, AWT etc… porque não HTML ? Então aqui caimos um pouco num esquema semelhante ao JSF mas com a possibilidade da mesma interface poder ser renderiza no browser ou no swing ( claro que " a mesma" só é verdade para alguns elementos básicos , mas que para a maioria das aplicações é suficiente e sempre temos a possibilidade de adicionar mais widgets a ambas as paltaformas de maneira a ter aplicações mais ricas) . Portanto, MVC2 para sites, Rest para integração e a outra para aplicações corporativas mais viradas para intranet.

Isso é apenas um cheirinho. Tem muito mais coisa. Não cabe num post e este já tá enorme. No blog abordarei tudo isto a seu tempo, com mais detalhe.

#16

Obrigado Sérgio pelas respostas. Vejo que seu projeto é audacioso e bem complexo.

#17

Esse projeto do Sergio Taborda, veio a ser muito útil agora nesse momento, acho que vai ajudar muito as pessoas a entenderem a como desenvolver até quem sabe novas soluções que venha agregar recursos ao MiddleHaven, nessa narrativa que vem dar maior detalhe e diretamente bem explicado eu espero que tenha algo funcional em breve pra fazer algumas implementações ao menos incial.
Agora é aguardar, de muitos os projetos que surgiu aqui na certa esse é o mais completo e expressivo trabalho.

abrsss

#18

Aguardar? O projeto é muito ambicioso e o Sérgio tá precisando de gente! Se você tá querendo tanto usar o framework, vai ficar aí de braços cruzados esperando? É a oportunidade perfeita de contribuir com um projeto open source!
Se eu pudesse me comprometer nesse momento, eu me ofereceria pra ajudar, mas ano de monografia é fogo…

#19

Aguardar? O projeto é muito ambicioso e o Sérgio tá precisando de gente! Se você tá querendo tanto usar o framework, vai ficar aí de braços cruzados esperando? É a oportunidade perfeita de contribuir com um projeto open source!
Se eu pudesse me comprometer nesse momento, eu me ofereceria pra ajudar, mas ano de monografia é fogo…[/quote]

Boa! Bacana tnaires!

Nós aqui no Brasil precisamos adquirir essa cultura! Se achar um projeto open-source bacana, começar a colaborar! Principalmente se este projeto está no começo
e tá precisando de ajuda!

[]'s

#20

Aguardar? O projeto é muito ambicioso e o Sérgio tá precisando de gente! Se você tá querendo tanto usar o framework, vai ficar aí de braços cruzados esperando? É a oportunidade perfeita de contribuir com um projeto open source!
Se eu pudesse me comprometer nesse momento, eu me ofereceria pra ajudar, mas ano de monografia é fogo…[/quote]
O Sergio o esta muito afinado tecnicamente ao FrameWork, ajudar a desenvolver o MiddleHeaven nesse momento é melhor buscar entendimento, no contexto que já se pronunciou o mesmo, ainda esta em fase pre-Alfa, então creio que se houver maior interesse de colaboração é necessário ter fontes e especificação adequada para fazer algo de forma coletiva,no presente momento o blog passa a ser a minha referência e orientação.