As one of the final moves before our incoming public release, a first version of a fully functional Eclipse editor is being developed. This is called Wind Domain Object Editor and has syntax coloring, content assistant, compilation error markers, and some other minor details.

Here is a first screenshot of its syntax coloring

As a requeriment, Wind Platform must provide a simple and easy way to do Domain Object's persistence. Given it's modularity, is also natural that we can have different kinds of persistence just by plugging another bundle that implements it. At the first moment there is only one kind of storage available, and it is Hibernate. 

For each Domain Object a Plain Old Java Object (Class) is created when the user application is being initialized. This class recieves Hibernate Annotations in order to map it's attributes into columns from a relational database. Of course, a java class must be loaded into a classloader, and Wind Platform takes advantage of OSGi, where each bundle has an independent classloader, to create these java classes using user application's classloader. This provides detachment between Wind Applications.

The diagram bellow illustrates the responsibility of each bundle in the Storage System (click to enlarge)

The highlighted box represents an user application (Wind Application). It depends on wind-app-controller to register itself as a Wind Application. That means, at startup wind-app-controller reads all Domain Objects definitions in order to generate necessary metadata to run user app. On the other side, App depends on hibernate-jars because it need to be able to import javax.persistence.* for object-relation mapping matters. The box called wind-storage has the responsibility to provide an abstraction layer for every other bundle interacting with the Storage System. All sorts of persistent implementation lays behind wind-storage. The diagram shows 3 boxes depending on wind-storage: wind-storage-hibernate, wind-cache and storage-x. The last two are just illustrative, but wind-storage-hibernate is already a real implementation, it depends on hibernate-jar and realizes wind-storage API.

Concluding, every request of any persistent operation is addressed to wind-storage, that provides a common interface and abstraction of the real implementation. This way, we leave the door open for any other kind of persistence that come to be needed in the future.  

I'm pleased to announce that Wind Platform now has support for Groups and Folder.

It is possible to have groups inside folders and groups inside groups, although it is not possible to have folders inside folders. Here is an example of how to create folders:

folder personal "Personal Info"{
 visible: true
 sequence: 1
}

The properties available for folders speak for themselves

To create a group you must write:

Group address "Address"{
 x: 1
 y: 5
 presentation_type: group
 folder: personal
}

Once a folder is an attribute, the properties available for groups are the same available for attributes. In this case, we say that this attribute has a presentation type of group and is placed inside "personal" folder. To place an attribute inside a group you must use "parent_group" property, as shown:

String street "Street"{
 x: 1
 y: 1
 parent_group: address
}

And, of course, you can put an attribute inside a folder by doing: 

String name "Nome"{
 x: 1
 y: 1
 folder: personal
}

This screenshot demonstrates how it looks

These two articles discuss the importance of two technologies used by Wind Platform. OSGi is the lowest level of the platform and provides the much nedded modularity. Because of this every bundle of the platform, including Wind App Bundles, can be installed, started or stoped on the fly.  Besides, different implementations of the same bundle can be installed in order to fullfil diferent needs.

The other article shows the Eclipse RCP, which provides a nice and also modular infrastructure for the presentation layer.

See it by yourself:

OSGi
RCP

Devido a modularidade tida como fundamento na plataforma, é possível criar diferentes implementações da camada de apresentação (e outras camadas, como a de persistência). A primeira implementação e atualmente a principal foi construída utilizando Eclipse RAP, no entanto, agora está em desenvolvimento uma nova interface gráfica utilizando Vaadin. O objetivo dessa nova implementação é servir como opção e não substir a camada existente. Abaixo o primeiro screenshot da nova camada!

The basic architecture behind Wind Platform is demonstrated by the following graphic

OSGi

OSGi is a module system specification maintained by the OSGi Alliance. Perhaps, the most famous implementation of the specification is Equinox, developed by the Eclipse Foudation, it is the base of Eclipse IDE. Applications or components, coming in the form of bundles, can be remotely installed, started, stopped, updated and uninstalled without requiring a reboot; management of Java Classes is specified in detail and each bundle has its own classloader. Application life cycle management (start, stop, install, etc.) is done via APIs. The service registry allows bundles to detect the addition of new services, or the removal of services, and adapt accordingly.

All this makes OSGi a natural choice as base of the platform. New applications can be installed by simple putting a new jar into a directory. Once the application starts it is available to interact and contribute to the already installed ones. If, for some reason, a application is stopped or uninstalled, the others can immediately adapt without any crashes.

Many Application Servers, such as JBoss, Websphere, Virgo, Weblogic, WSO2, begin to support deployment of OSGi Bundles by using a implementation of the spec.

Spring DM
Wind platform is composed by various separated bundles. To make they talk to each other Spring DM manage common Spring Beans (it is the same as you are used to, via XML) and exposes as OSGi Services through an interface. Then we have the same advantages of using Spring to manage our beans and inject the dependencies, but it covers separated bundles. In other words, Spring DM acts like a loose coupling glue. Like Post-it glue.

Wind Platform Bundles
Here is where we've been working for over a year.
Above the OSGi layer lays the Wind Platform Bundles. Those are the componentes responsible of get you application up and running. They are tied together by the Spring DM.
The following is a brief description of each Wind Bundle.

wind-lang
wind-lang is responsible for parsing the Domain Objects and create a in-memory representation of the Domain Model. It defines a grammar using Antlr in order to generate the parser.

wind-app-controller
When a Wind Application is identified, wind-app-controller register and make it available to the other components. Besides that, it controlls the application lifecyle and execution of the business rules. 

wind-common
Common and useful classes.

wind-faces
wind-faces is a graphic user interface built on top of Eclipse RAP. It is notified by wind-app-controller when something change in the application registry (this can be a Domain Object or an Application added, removed or updated) and update de view.

wind-lib
Common jars used by the platform, antlr, hibernate, etc..

Provided Bundles
The difference between a Wind Platform Bundle and a Provided Bundle is that the second one is built using the Wind tecnology, specifing Domain Objects and Business Rules. Currently there is only one provided bundle. Wind Preferences, is responsible for giving the user a UI for setting up common preferences.

User Bundles (Wind Applications)
This is the applications created by the user that runs on the platform and uses all it goodies. User Bundles, or so called Wind Applications, are OSGified bundles containing Domain Objects and Business Rules.

Every topic discussed here will be presented separately with more details in upcoming posts

Este vídeo mostra como configurar um ambiente de desenvolvimento para Wind Platform. Configure o ambiente e veja a plataforma com seus próprios olhos.

Dica: Assista em tela cheia.

As Aplicações corporativas atuais são indiscutivelmente sofisticadas e utilizam tecnologias de ponta. No entanto, um software corporativo que não resolve o problema de negócio não é útil para ninguém, não importa quanta tecnologia foi utilizada na construção. Dessa forma, para construirmos um software de qualidade (não me refiro a bugs), que realmente traga valor para o negócio em questão, devemos nos ater ao problema que se pretende resolver com este software.

Como desenvolvedores, tendemos a nos preocupar mais com a complexidade técnica do que com o problema a ser resolvido em si. A verdade é que ninguém patrocina um software apenas por que ele foi construído com Ajax, JPA, BPM, etc. Para o patrocinador o sucesso não é medido pela baixa quantidade de bugs em produção, mas sim pelo retorno ($) que este proporciona.

A filosofia Domain Driven Design (DDD) diz respeito a voltar a atenção ao problema que se pretende resolver, desenvolvendo assim um Modelo de Dominio, e mantendo o foco na complexidade das regras de negócio que são intrínsecas ao domínio em que o software está inserido.

De maneira geral, podemos dizer que em um software corporativo temos dois grandes pilares que o sustentam. Um Modelo de Dominio e Regras de Negócio. O modelo de domínio determina a estrutura dos dados. Por outro lado, as regras de negócio determinam como esses dados são manipulados afim de se obter um resultado. 

Tomando como exemplo um sistema para controle de passageiros, um modelo de dominio contém (a grosso modo) as entidades Passageiro, Voo, Origem e Destino. Para que um passageiro seja capaz de pegar um voo em seu local de origem e chegar ao seu local de destino é preciso que existam regras de negócio capazes de manipular o dominio produzindo tal resultado.

O dominio do software deve ser o principal foco de atenção da equipe. Pessoas que entendem de negócio e pessoas entendem de tecnologia devem utilizar uma linguagem comum, com os mesmos termos e conceitos, para abstrair um cenário real e transformá-lo em software.

A Wind Platform está sendo desenvolvida para que as equipes que desenvolvem software corporativo possam realmente voltar seus esforços para a criação de um bom modelo de dominio e de suas respectivas regras de negócio.

Existem muitos fatores que tornam um software complexo, e o objetivo da Wind Platform é possibilitar que a tecnologia não seja um deles.