Como já devem saber o MiddleHeaven está sendo utilizado para suportar o site www.javabuilding.com o que significa que funciona

O mecanismo de processamento de requisições HTTP é abstraido das classes de servlets e utilizado por um mecanismo baseado em ação.  Devido à injeção de dependência e injeção de parâmetros apenas precisamos escrever uma classe que atua como controlador/presenter e configurar quais url ela irá responder.  Todas as configurações são feitas em código. A razão para isto é que são configurações dos mecanismos que não mudarão no deploy, por isso não ha necessidade de as deixar em arquivos separados. Uma possivel futura é utilizar scripts groovy e javascript para as configurações mantendo o melhor dos dois mundos.

O foco do MiddleHeaven para GUI é prover um mecanismo comum para web e desktop orientado a componentes, mas enquanto isso não fica pronto com a toolbox de processamento e o processador baseado em ações já dá para fazer alguma coisa.

Junto com isso temos algumas tags próprias para ajudar a criar as páginas, em particular o forEach que aceita qualquer Iterable e não apenas List.

Entretanto o storage toolbox continua sendo remodelado. O problema é a utilização transparente em ambiente multi-thread e a possibilidade de utilizar o hibernate por detrás dos panos. A realidade é que esse não era o objetivo inicial, mas o mecanismo genérico está atrazado. Além disso é um exercicio para o design do toolbox já que será, provavelmente, o mais usado de todos é necessário que esteja bem solto para evoluir.

Por fim , queria deixar um pedido de comentário sobre as toolbox existentes e quais features seriam interessantes, como por exemplo, se deveria mesmo haver suporte ao hibernate.

O projeto Middleheaven continua  a passo curtos. Muita gente tem demonstrado o seu apoio. Obrigado.

A identidade do projeto talvez esteja um pouco nebulosa porque até agora o que ha para mostrar é apenas o código e um conjunto esparso de texto falando de umas coisas chamadas toolboxes. Toolboxes são como pedaços da API, como no JSE temos o JCF ,  I/O e Threads que na realidade se encaixam mas as vemos como partes separadas.

O projeto começou por ser apenas um repositorio de código que eu utilizava repetidamente. Coisas como copia de arquivo e utiltários vários. Depois passou a ser um framework. Um conjunto de coisas prontas, mas complexas. À medida que construia outros frameworks mais simples eu pensava em poder levá-los até ao limite e incorporá-los no framework. Hoje, o MiddleHeaven não é mais um framework e sim uma plataforma de desenvolvimento. Uma arquitetura e design padronizada com partes extensiveis e plugáveis e um conjunto de plugins e extensões já preparadas.

O MiddleHeaven pode-se comparar ao Spring no espirito de facilitar a programação e conexão de partes da aplicação.  Tal como o Spring o MiddleHeaven conta com um motor de injeção automática, mas à diferença do Spring ele não tem definição baseada em XML. Na ralidade não tem porque não foi implementado. O MiddleHeaven delega essa parte a um objeto especifico que pode ser implementado de muitas formas. Por agora, anotações são a base – pode escolher entre as do próprio MiddleHeaven ou as padrão como @Resource.

Ao contrário do Spring que utiliza directamente outros frameworks e não oferece nenhum encaspulamento – no sentido que você ainda tem que saber usar esse outro framework – o MiddleHeaven oferece as suas próprias estruturas e design que pode ser extentido com implementações diversas baseadas em diferentes frameworks de terceiros.  Enquanto que no Spring estes frameworks são le reason de être do motor de injeção, no MiddleHeaven eles são apenas detalhes de implementação que podem mudar ou ser substituidos.

Um outro framework com que poderiamos traçar um comparativo é o JCompany. O JCompany é um framework proprietário com uma versão livre que vai um passo além do Spring oferecendo um certo encapsulamento em torno de APIs de terceiros visando o máximo possivel aderir a padrões de mercado. O JCompany oferece muito já pronto e está mais para aplicação costumizável do que para framework propriamente dito. Contudo o conceito por detrás é muito semelhante ao do MiddleHeaven. A grande diferença é que – além da licença – o MiddleHeaven não corre atrás dos padrões de mercado. Esse é um objetivo explicito. Os padrões serão incorporados quando necessário e normalmente por debaixo dos panos já que todo o conceito do MiddleHeaven é exatamente abstrair toda essa parafernália de padrões e tecnologias que mudam constantemente.

O MiddleHeaven é fortemente baseado, não apenas em padrões , mas também em conceitos. As abstrações do MiddleHeaven tendem a ser ir o mais longe possivel para que possam ser reutilizadas o máximo possivel.  Em alguns pontos isso pode significar menor performance ou uma complexidade extra que o programador considera desnecessária, contudo, é sempre possivel não utilizar o modelo do Middleheaven ou usá-lo parcialmente. O desafio é que o programador goste de usar o modelo do MiddleHeaven porque ele é natural.

Embora eu tenha começado dizendo que o MiddleHeaven está caminhando a passos curtos isso é porque estou me referindo a todas as capacidades que foram sonhadas para ele. Contudo ele já faz muita coisa. Já é possivel desenvolver uma aplicação web no estilo do Spring MVC , o ponto que falta para fechar o ciclo e poder libertar uma versão beta ( ou talvez 0.2-alfa) é a persistencia; que está sofrendo uma remodelação.  Depois vem a parte de interação com o usuário que permitirá aplanar a diferença entre o mundo web e o desktop. Esta é a funcionalidade realmente nova do MiddleHeave,n mas  para chegar lá o básico tem que estar no lugar e ser sólido.

O MiddleHeaven caminha a passos largos para um release que possa ser utilizado para fazer aplicações web basedas em JSP.

Foi adicionada a antevisão da toolbox de bootstrap para que se entenda como o MiddleHeaven carrega e se mantem a sua aplicação isolada. Foi adicionada também a antevisão da toolbox de critérios. Quanto a mim uma das preciosidades do MiddleHeaven que o diferencia de todos os outros frameworks e API por ai. Um cutucada ao Hibernate está inclusa (pun intended).

A mudança de layout é devida à falha do anterior em mostrar o menu ao lado quando na área de páginas.

Enquanto o MiddleHeaven não tem uma nova release, vá absorvendo todos os novos (novos?) conceitos que ele trás.

A plataforma java oferece uma vasto suporte ao conceito de conjuntos (coleções e mapas), mas não tão vasto quanto poderia ser.

A limitação à API de coleções atual é o uso da classe Colections para coisas avanaçadas como ordenação e a falta de suporte a Closures pelo Java. Mesmo se o Java tivesse suporte, depois das discussões para o Java 7 – a closures não ha garantia de que a API de coleções seria alterada.

Mesmo com o suporte a coleções da plataforma falta suporte a outras estruturas - que não sendo coleções – estão relacionadas a teoria de conjuntos como intervalos.

Intervalo

O MiddleHeaven dá suporta a intervalos pela classe Interval definida conjunto de elementos ordenável. Elemento ordenável é todo aquele que implements Comparable ou a que se possa associar um Comparator. Um intervalo pode ser fechado ( tem principio e fim) , aberto ( sem principio ou sem fim) ou vazio ( o principio e o fim são iguais).

A classe Interval suporta várias operações que podem ser feitas sobre ou com intervalos, tais como interseção, união ou verificar se um elemento está no intervalo.

Era importante incluir conceito de intervalo. Isso é especialmente relevante o dominio de tempos e datas (Time Toolbox) onde é comum definir intervalos de tempo. O MiddleHeaven define TimeInterval como uma extensão de Interval aplicada a TimePoint e adiciona operações relacionadas a tempo como a conversão para Period

Range

Um intervalo não é iterável porque ele pode ser aberto. Para ter um objeto semelhante a um intervalo mas que é iterável temos o Range. O objeto Range parece-se muito com um intervalo, mas podemos iterar os elementos através de um Incrementator. Um incrementador permite passar de um elemento ao próximo de uma forma controlada. Por exemplo, para passar de 1 a 2 adicionamos 1, mas para passar de 2009-09-10 a 2009-09-11 temos que obter a proxima data. Não podemos simplesmente adicionar 1.

O incrementador é especialmente relevante para elementos de um conjunto ordenável e denso como os numeros reais, já que para estes tipos de conjunto não podemos determinar qual é o proximo elemento a partir de um elemento dado. Por exemplo, nos numeros reais, a seguir a 1 existe um numero, mas não é 2, nem 1.5, nem 1.1, nem 1.0000001 , nem … Por causa desta impossibilidade matemática, ao criar um Range sobre um conjunto denso é necessário estabelecer o passo através de um incrementador. Por exemplo de 1 em 1, poderiamos iterar de 2 a 5 e teriamos [2, 3 ,4, 5] , mas como passo de 0.5 teriamos [2, 2.5 , 3 , 3.5 , 4 , 4.5 , 5].

Caminhando sobre o conjunto

A API de collections é muito boa usando o padrão Iterator ( um dos padrões GoF) mas falha usando o padrão Visitor (também do GoF) . O padrão visitor é muito util para fazer passar um objeto por todos os elementos da coleção. Assim, a coleção recebe um objeto que visita todos os elementos para um determinado fim. O padrão visitor é muito util porque esconde a iteração do for ou do while e desta maneira deixa a coleção fazer a caminhada pelos elementos como ela quiser ( em tese da forma mais eficiente). O padrão Visitor é aquele que seria utilzado por closures, caso elas existissem para aplicar uma certa logica a cada elementos do conjunto. O MiddleHeaven suporta o conceito por detrás do padrão visitor e introduz as interfaces Walkable e Walker. Um Walkable é um objeto que pode ser “caminhado” por um “caminhante” (Walker) em analogia a que um objeto Iterable pode ser iterado através de um Iterator.

A interface Walker apenas define um método genérico doWith() que pode ser usado para qualquer coisa. Embora o método não defina um retorno explicito, é possivel implementar uma outra classe que implemente esta interface e permita o acesso a um resultado através de outro objeto. Esse é o caso, por exemplo, de NumberAcumulator que extend Acumulator e implementa Walker e permite somar valores continos na coleção.

Aqui utilizámos a classe Real porque NumberAcumulator precisa de um objeto que implemente a estrutura matemática GroupAditive. Real implementa uma forma especial de criar Range O código ficaria assim:

Imprimir os numeros de 1 a 6 mostra um uso mais tradicional do Walker

Em java puro não teria muito ganho porque este Walker é muito simples. Mas se o Walker executar operações complexas (mais de 5 linhas) escrever isso dentro de um for é confuso. colocando isso em uma objeto é possivel definir a logia à parte e de forma genérica. Este é o objetivo, entre outros, de trazer closures para Java. Segundo as tendencias qualquer interface poderia ser substituida por uma closure. Embora closures não venham na versão 7 do Java é quase certo que virão em algum ponto. Enquanto não, as classe anónimas internas terão que servir.O ganho real viria da simplificação da sintaxe com o uso de Closures. Se um dia elas vierem vc poderia escrever assim:

Um outro tipo de Walker importante é aquele que caminha sobre uma arvore. Para este tipo de objetos o MiddleHeaven introduz a interface TreeWalkable que extende Walkable com os métodos eachRecursive() e eachParent(). O método eachRecursive aplica o Walker ao objeto, depois aos filhos e depois aos filhos dos filhos, etc.. O método eachParent() é aplicado ao pai do objeto corrente e depois ao desse , assim até à raiz. TreeWalkable é especialmente útil para estruturas como o sistema de arquivos. ManagedFile da Managed File Toolbox implementa esta interface.

Enumerable

A classe utilitária Collections permite utilizar vários métodos sobre objetos que estendam Collection ou Map. Isso é feito para que os mapas e coleções em Java não tenham que implementar um numero elevado de métodos assim diminuindo a sua área de superfície. Isto é considerado uma boa prática. Contudo é estre,amente chato e ineficiente já que cada implementação não pode otimizar o processo definido pelo contrato do método. Além disso a chamada dos métodos é pouco encadeável o que confunde os programadores iniciantes e frustra os experientes.

Um outro problema com os mapas e coleções em java é a fala de uma interface comum para coleções e mapas.

O MiddleHeaven introduz a interface Enumerable (enumerável). Esta interface serve dois propósitos: 1) o de prover uma interface comum para mapas e coleções e extender o numero de métodos directamente invocáveis sobre os conjuntos.Um Enumerable é uma expanção do conceito de Iterator. Todos os Enumerable são Iterator mas têm mais coisas a oferecer.

A maior parte dos métodos de Enumerable recebem implementações de Classifier. Este é um objeto que dado um objeto de um tipo retorna outro objeto do mesmo ou de outro tipo. Em particular pode retornar um objeto do tipo Boolean. A maior parte dos métodos de Enumerable usam classificadores para boolean excepto map que usa classificadores para qualquer outro objeto. O objeto Classifier pode ser usado como filtro ou como transformador. Por exemplo, usando o método find() é possivel encontrar um objeto que passe no teste do classificador passado como argumento. Tudo isto sem ter que escrever nenhuma instrução for.

Enumerable implementa Walkable e todas as operações com Classifier geram novos conjuntos após aplicar o classificador a todos os elementos do ocnjunto. Os métodos que usam Classifier implementam o padrão Visitor de forma semelhante a Walker, a diferença é que o resultado obtido pelo Walker não é convertido para um outro conjunto, enquanto que os que usam Classifier são.

Com isto o MiddleHeaven extende as interfaces Collection,Set, List e Map implementando Enumerable e mais alguns métodos interessantes. Estes conjuntos são chamados de coleções aumentadas (enhanced) e implementam as interfaces EnhancedCollection, EnhancedSet , EnhancedList e EnhancedMap respectivamente. Para os obter basta invocar CollectionUtils.enhance(). O uso deste método é inivitável em Jaa devido ao fato de não ser possivel adicionar este método nas interfaces já existentes. Criar uma coleção aumentada é muito simples:

Enumerable permite enumerar e iterar sobre um conjunto em uma certa ordem. Mas e que tal obter um elemento aleatóriamente de uma lista ou coleção ? O MiddleHeaven inclui a interface RandomEnumerable. Esta interface define o método random() que seleciona um elmento aleatóriamente da coleção. Isso permite o sorteio de numeros em uma linha de codigo. Por exemplo para sortear os numeros de um dado fariamos:

Porquê

Muitos já tentaram criar bibliotecas alternativas para coleções. A Apache Commons Collections existia mesmo antes da API ser padrão na plataforma Java. Trabalhar com conjuntos é realmente uma facilidade que permite ao mesmo tempo tipagem forte, algoritmos eficientes e simplicidade para trabalhar com muitos objetos simultaneamente. O MiddleHeaven não poderia,portanto, se escusar que dar algum suporte a coleções.

Com o olho no Java 7 e a suposta introdução de closures, as coleções aumentadas teriam um uso mais simples e omnipresente mas mesmo sem a funcionalidade de closures ha muita coisa que é mais fácil de ser feita com o uso destas coleções. Por outro lado, devido à necessidade de suportar intervalos (sobretudo os de tempo) era necessário introduzir classes diferentes mas de forma compatível. Mas um intervalo não é iterável, então foi criado o objeto Range.

Converter qualquer conjunto da plataforma padrão para a biblioteca aumentada é muito simples. Aliás , à exceção de EnhancedArrayList que pode ser usada independente, aumentar uma coleção já existente é a única forma de obter uma coleção aumentada.

Já era hora, eu achei, de criar um novo blog para falar do MiddleHeaven.

Tenho dedicado meu muito escasso tempo livre a este projeto durantes os últimos anos e está na hora de o mostrar ao mundo (e ser criticado por isso …).

O blog em inglês não deslanchou e o site feito pelo maven é pesado para atualizar. A ideias são muito mais fluidas e, contando que a minha equipe jornalística sou eu mesmo é bem mais facil utilizar um blog. A volta ao blog do WordPress em deterimento do Blogstop é que o Wrodpress apresenta a muito útil capacidade de criar páginas estáticas além do blog.

Convido a todos a conhecerem o nosso novo blog para entender e desenvolver o MiddleHeaven.

A seu tempo vou colocar nele os textos já apresentados, em inglês, no blog antigo.
Espero que acabe havendo algum cross-siting entre os dois blogs especialmente em referências a padrões e coisas relacionadas ao Java em si. Isso não era possível com o blog antigo devido à diferença da língua. Espero que isso, também, seja uma vantagem.

Aproveito para informar o estado do projeto. Embora já seja possível criar telas swing e sites jsp ainda falta um pouco para que as peças principais estejam no lugar.  Recentemente integrei o NeoDatis e parece bastante promissor, contudo, leva a uma revisao do modelo de dominio baseado em anotações (sem ORM , não ha necessidade das anotações). Por outro lado, revisei o mecanismo de wiring (injeção automática) para ser possível encontrar pontos de injeção por outras vias que não annotações. Desta forma é possível análises mais dinâmicas. O mecanismo de persistência é o próximo a ser revisto. Espero que após isso uma versão do framework possa ser usada para aplicações web simples (a la Spring / Struts / Vraptor / Mentawai) .

Claro que, para isso, você precisa estar preparado para não usar o Hibernate… será que aguenta ?

Uma versão utilizável do MiddleHeaven já está disponivel. A versão é a 0.0.1 o que significa que é pre-alfa.

Este release não é de produção, nem muito menos está em estado de completo, mas isso é porque estou tomando em consideração todos os toolboxes.  Alguns toolboxes estão 90% terminados e alguns já são utilizáveis mesmo sem estarem completos.

O objetivo é deixar um jar disponível para que as pessoas possam experimentar o MiddleHeaven sem o esforço de baixar tudo do SVN e compilar em casa. Note-se que o MiddleHeaven tem muitas dependências externas. É bom dar uma olhada no arquivo POM dentro do jar.

É claro que nem todos os bugs foram corrigidos, mas tentei deixar corrigidos todos os que encontrei.

O blog de desenvolvimento do MiddleHeaven está aberto aos comentários de todos assim como os foruns.

Ha quase um ano o MiddleHeaven nasceu, mas a sua evolução anda um pouco lenta devido a minha falta de disponibilidade para trabalhar nele. Então vou fazer algumas alterações.

Primeiro, decidi criar um outro blog para falar do MiddleHeaven. Isto porque: a) não caberia neste blog pessoal falar com detalhe desse asunto e; b) precisava atingir uma comunidade maior e por isso decidi escrever o blog em inglês. O meu blog pessoal é em português por escolha e não caberia misturar as duas línguas.

No blog de desenvolvimento vou falar da estrutura, conceitos , idéias e trade-offs por detrás do MH e espero que isso ajude mais pessoas a entender OO e Java e me ajude a vislumbrar onde fiz a escolha errada.

O blog do MiddleHeaven não é pessoal, por isso, espero que no futuro possam existir mais pessoas colaborando com conteúdo para ele (em tese, os mesmos que colaboram com o código).

Convido a todos que estão interessados no projeto a seguir o novo blog.

Os artigos sobre exceções e coleções foram atualizados. Ao de coleções adicionei um fluxo de decisão de interfaces e implementações de coleções. São abrangidos os principais casos. Notei que existe pouco entendimento das diferenças entre cada implementação, então espero que isto ajude a clarificar as coisas. Um terceiro, prometido, artigo sobre exceções está na forja … segura firme.

Adicionei um novo artigo sobre as palavras reservadas do Java. Curiosamente nunca tinha parado para pensar que true, false e null são palavras reservadas. O estranho é que no site da Sun só se listam as palavras-chave e não as palavras reservadas. Acho estranho porque o conceito de palavra reservada é mais lato que o de palavra-chave.

Não tenho tido tempo para comentar sobre o projeto MiddleHeaven mas ele continua em desenvolvimento (alfa). Estou com alguns problemas logísticos para decidir onde colocar o código “official”. O sourceforge parecia bom, mas a conexão é lenta demais. O Google Code parece bem mais rápido mas não dá para usar o site que o Maven produz (dá?). No sourceforge tenho também o problema de não conseguir atualizar o ViewCVS que no Google Code funciona perfeitamente. Quem quiser dar uma olhada pode fazê-lo no Google Code, embora o código esteja menos atualizado.

Como saberão estou – no meu pouco tempo livre – envolvido no projeto MiddleHeaven. Umas das capacidades mais interessantes do Middleheaven é ganhar independência de plataforma através do uso de serviços. Como comentei antes, “serviço” é uma modelo que está em alta e que parece fornecer encapsulamento, isolamento e desacoplamento por definição. Adicionamos a isso a programação para interfaces e os mecanismos de meta-programação (reflection, bytecode-rewrite) e temos um mecanismo muito poderoso para adicionar funcionalidade no sistema.

Ao trabalhar com serviços existem algums detalhes que precisam ser suportados por um framework. Primeiro, tem que existir uma forma de obter o serviço. Tudo bem que não sabemos qual a implementação do serviço – e não nos interessa – mas temos que a obter em algum momento. O padrão básico para isto é o Registry. A idéia é que a implementação é registrada “antes” e “depois” o serviço é recuperado. Esta mecânica existe em vários frameworks baseados em serviços como JMX ou OSGi. Este simples requisito (obter a implementação) é mais complexo do que parece. Acontece que um mesmo serviço pode funcionar diferentemente conforme algum parâmetro e podemos estar interessados em usar mais do que um serviço do mesmo tipo. Por exemplo, um serviço de dicionário tem vários tipos: um para cada língua. Ao pegar o serviço a interface não basta. É preciso (algumas vezes) adicionar algums parâmetros na busca. Dessa forma, é possivel dizer “obtenha a implementação do serviço dicionário para o francês” e depois repetir “obtenha a implementação do serviço para o inglês” e com isso construir um código que testa se uma certa palavra é homografa entre as línguas (como por exemplo weekend). Um mecanismo baseado em serviços tem que ser capaz de suportar diferentes “sabores” de um mesmo serviço. Até aqui parece simples. Basta passar os parâmetros durante a procura. Mas quais parâmetros são permitidos para cada serviço? Precisamos saber? Versão é um parâmetro?

O outro ponto é que usar um Registry para obter os serviços torna o código dependente do próprio registro e da forma de o acessar. Um mecanismo melhor seria usar injeção de dependência. Mas para ser realmente prático, uma implementação de um mecanismo destes teria que ser feito com base em anotações (compare Guice com Spring e veja a diferença entre usar anotações e XML). Isso é interessante porque não mais tenho que me preocupar com o mecanismo de procura , apenas espeficico o que quero. Algo assim:

@Wire @ServiceParams(“language=fr_FR”) Dicionario dicionarioFrances;
@Wire @ServiceParams(“language=en_UK”) Dicionario dicionarioIngles;

O mecanismo de injeção faria algo como

ServiceRegistry.getService(Dicionario.class, serviceProperties )

em que serviceProperties seria um mapa populado pela instrospeção de @ServiceParams.
Um mecanismo de injeção não demora a construir, embora demore a maturar para resolver problemas como referência cíclica e outros. Ou seja, em tese, não é pedir muito que o MiddleHeaven inclua um mecanismo de injeção e permita ao objetos pedir “Hey! MiddleHeaven, wire it to me!”

Tudo muito bem, mas existe ainda um outro fator nesta história. Decidir quais implementações dos serviços devem ser usadas. Esta decisão depende de vários fatores. Serviços de infra como transações e comunicação remota dependem do contexto em que a aplicação corre. Dentro de um container jee é apenas adaptar o serviço provido pelo próprio container, enquanto que em standalone precisamos de implementar o próprio mecanismo ou delegar a alguma biblioteca de terceiros. A aplicação também pode decidir que precisa de um certo serviço ( por exemplo, serviço de reports). Esse serviço tem que estar presente para a aplicação funcionar, mas não é essencial nem utilizado sempre e nem depende do contexto. Além desses, temos serviços externos como serviços de cotação ou B2B que a aplicação usuará.

A este ponto deve estar pensando que já ouvi esta conversa em relação a SOA. SOA é orientado a comunicar sistema fora do mesmo “processo de negocio”. Mas podemos trazer o conceito para dentro e utilizar um design baseado em componentes que funcionam como serviços uns dos outros. Claro que isso é mais facil dito que feito.

Como os serviços necessários à aplicação podem ser adicionadas conforme necessário eles podem também ser removidos ou subtituídos (especialmente os de terceiros) quando necessário. Isto pode significar que depois que a variável foi connectada à implementação, a implementação muda. E muda em runtime. O objeto que a variável aponta não é mais válido. Obviamente isto implica no uso do padrão Observer mas como não há interação com o registro de serviços, o próprio mecanismo de injeção tem que conter alguma lógica especial ou melhor, ser possível injetar alguma lógica especial no mecanismo de injeção . Ou seja, temos que aliar AOP com o mecanismo de injeção para trabalhar com serviços errantes.

Indo mais fundo no problema, a apliação em si mesma pode ser entendida como um conjunto de serviços. Normalmente chamamos as partes de um aplicação de módulos. A idéia é criar uma aplicação criando um conjunto de módulos. Um módulo “principal” contém o coração da aplicação. O que esse módulo faz (o seu serviço) depende de outros módulos e/ou pode ser estendido por outros modulos.

Um exemplo classico são os ERP. Uma compra gera um conjunto de eventos de negócio. Cada módulo (contabilidade, financeiro, etc..) enxerga esse evento de forma diferente e o processa de forma diferente. Para um sistema básico a implementação do módulo pode simplesmente ignorar o evento ou apenas persisti-lo para tratamento posterior. Um módulo mais avançado não apenas produziria informação com base no evento, como ainda disponibilizaria seus serviços para serem consultados por outros modulos/sistemas (via webservice, por exemplo). Um módulo mais avançado poderia alterar o serviço de UI da aplicação para incluir mais telas que permitem ao usuário interagir com o módulo, e alterar o serviço de permissões para restringir o acesso dos usuários. Os módulos seriam então configuradores de serviços, conscientes dos outros módulos de que eles dependem e fornecendo novos serviços para serem consumidos por outros módulos, aplicações ou sistema.

Esta é a idéia por detrás do MiddleHeaven como um framework orientado ao negócio. A aplicação é apenas mais um serviço, composto por outros serviços. O detalhe agora é saber como colocar tudo isto no mesmo caldeirão e funcionar.

A minha idéia era, como comentei antes, utilizar frameworks como o OSGi ou o ainda não estreado Java Module System para cuidar da localização e registro de serviços, mas hoje parece-me que esse mecanismos podem não ser compativeis e/ou não seguir o caminho necessário para o MiddleHeaven. Ou serem mais abrangentes que esse caminho. Enfim, abstrair esses mecanismo parece uma boa idéia para manter a independência do MiddleHeaven mas parece complicado demais…

Uma das mais inimitáveis características do ser humano é ser capaz de reconhecer padrões. Não apenas padrões de cor, forma ou som, mas também padrões em idéias, conceitos e abstrações. A matemática não seria possível sem essa capacidade.

Venho elaborando descrições do padrões mais importantes (a lista não pode ser exaustiva porque existem bastantes ) em orientação a objetos em java hoje em dia. Claro que a implementação é naturalmente orientada para java, mas os padrões em si mesmos são abstratos e podem ser implementados em qualquer linguagem O.O. ( a maioria, pelo menos).

Os padrões são resultado da estricta e repetida aplicação do Principio de Separação de Responsabilidade e são, na realidade, uma expressão utilitária desse principio.

Espero apresentar uma vasta gama de padrões (pelo menos os usados no MiddleHeaven) mas não é um trabalho rápido devido ao imenso numero de padrões que existem.

Muitas coisas aconteceram desde a ultima mensagem. Esta vida corrida demanda demais.

O projeto Middleheaven continua. Um dos seus pontos fortes é o uso de serviços para fornecer funcionalidade. Serviços são interfaces que estabelecem contratos. A sua implementação é desconhecida, apenas sabemos que funciona. Desta forma a aplicação pode ser totalmente isolada de mecanismos de infraestrutura e, até, de outras aplicações sem que ela saiba.

A ideia de usar serviços veio da api de JMX que é complemente orientada a componentes de serviço: os MBeans. Com o passar do tempo eu queria aumentar o nível e ser capaz de dizer que o serviço x depende do y de forma que o sistema tomasse conta da organização e avisasse quando o serviço não está disponível. Este controle de dependência mostrou-se muito complexo.

Perquisando na net encontrei uma coisa chamada OSGi framework. Também baseado no conceito de serviço com implementações separadas surge a ideia de o incorporar ao MiddleHeaven. Existem várias implementações do OSGi framework e escolhi o Apache Felix para começar. Contudo existe uma JSR (JSR 277) prevista para breve que faz algo semelhante. Por isso ainda não decidi qual dos mecanismo adotar. O JSR 277 promete ser o novo padrão java muito em breve, mas o OSGi já existe hoje. O OSGi framework tem alguns problemas como classloading que o novo padrão pretende resolver.

WebServices e SOA são outras ideias que nos levam a um mecanismo de serviços como componentes, mas agora de forma remota. A implementação do serviço pode ser remota com a API de webservices fazendo a ponte. A famosa consulta de cep poderia muito bem se aproveitar disto.

Parece-me que o MiddlHeaven está no bom caminho no que toca a usar serviços como peças fundamentais para prover funcionalidades …

Decidi trocar o host do MiddleHeaven para o SourceForge já que o Java.net não oferece a simplicidade de um webserver onde colocar a documentação e outras coisas. Como o projeto usa o Maven o site é criado e colocado online automáticamente.

Esta configuração do Maven é uma mão na roda quando está certa, mas é um complexo de configurar tudo da forma que se quer… O codigo está online

Depois de muito , muito, tempo prepando o terreno decidi que é hora de lançar o projeto.

A minha ideia original era trabalhar no projeto até ter uma fundação sólida para depois o libertar como open source. Mas devido ao pouco tempo que disponho decidi lançar por partes, conforme vai ficando pronto. A base de código contém tudo, mas apenas algumas partes são utilizáveis.

A ideia por detrás do MiddleHeaven não é criar um framework web, nem mais um framework.É criar um Business Framework. Um framework orientado aos negocios. A diferença fundamental para outros frameworks é que visa implementar um conjunto de padrão de aplicação além dos comuns padrões de projeto. A ideia é fazer o sistema depender de um único framework e o framework depender de um conjunto de outros frameworks de infraestrutura. Por exemplo, abstrair se o log é feito no Log4J ou não, se a persistencia é feita em banco de dados , e em qual, se o sistema correm em JBoss, Tomcat ou standalone, etc…

Em certa forma é uma implementação prove of concept mas espero que seja funcional.