Mickaël’s Weblog

I had a look at jBoss and wanted to validate its capabilities from a PaaS perspective.

First I prefer to have a kind of factory which includes the minimum software and tools to start. This does not include you JDK that should already be installed. This factory will include Eclipse (I use version Europa Winter (Java EE) 3.2 that you can download here) , maven2 (2.0.8 downloadable here) and jBoss (4.2.2 downloadable here ). I also create a folder in this factory for the eclipse workspace.

Install factory

I suggest to backup it, to reuse a copy of it for each project. Create a folder named factory. Download Eclipse, maven 2 and jboss. Then create a folder for eclipse workspace. You should have something like:

Here are some files (eclipse, vars) to put in the folder factory that will setup environment variables.
Add also a shortcut that will launch a command prompt and use the environement variables setup in vars.bat. Here his the value of the shortcut:

C:\WINDOWS\system32\cmd.exe /k “”vars.bat”"

(you should change only the windows folder according to your machine installation).
Now, update the vars.bat file for the line pointing to your JDK, the other lines should not be changed.

Done, yoiur factory is ready. Next step is to create and build your project.

Project and build creation

Create a folder named as you want (I will use C:\PaaS. Then copy the factory folder there (the factory folder is a sub folder of PaaS).

I’ve created a jBoss/Seam project containing : a webclient (for presentation logic of my application), a separated ejb folder (for business logique of my application), an ear to contain the projects.

Unzip this file mycompany.zip into the PaaS folder (mycompany should be asub folder of PaaS).

This project is based on MySql as RDBMS. You do not need to install it to make this sample working as this sample does not include any access to the database. bitewise, it will requires the jdbc driver. Here is the jdbc driver I used for MySql 5.1.6. I did not handle to include it in the factory, so you have to copy it into the lib folder of the jBoss deployment (factory > jboss-4.2.2.GA > server > default > lib).

Execute short cut that is in factory folder, it should launch a command prompt. Go in mycompany folder and execute folowing command line:

mvn clean install

Use Eclipse as IDE

Execute folowing command line:

mvn eclipse:eclipse -DdownloadSources=true -DdownloadJavaDosc=true

Execute eclipse.bat that will launch eclipse with the right workspace. I then suggest you to declare the jBoss server.

Now import projects that are in mycompany folder. Deploy it and check it works.

Deployment

Go in platform folder and execute folowing command line:

mvn jboss:harddeploy

Go in http://localhost:8080/webclient …should be ok !!

Conclusion

There are 3 important points in that sample:

• usage a factory to bootstrap a new project (I think this is the right direction for a PaaS approch, even if that requires lot more work…this is only a prototype…not more),
• the maven2 pom.xml files which demonstrate how to separate business logic, presentation…and can be extended easily to host morte than one application,
• the IDE is nicely included into the picture through maven, and the IDE is NOT the build process.

I will improve it and create a dedicated page on this blog and post updates using regular posts.

If you try it and have any question or see any problem, feel free to add a comment.

…is a valid option to write a full software entreprise stack?

Even if JBoss is not listed in my CV, I had recently a looked at it to check its capabilities as of environemtn for a full software entreprise stack (I may update my CV now even if we do not use it…but I made some prototyping with it and have a clear view of its capabilities).

First, what we need?

• container for decoupled applications
• persistance
• UI (web 2.0 would be a plus)
• engines as workflow and scripting
• scallable
• …and more

Back to some fundamentals…

I had AOP

AOP that SoC ?

Beyond AOP…

I had a AOP

Their are 2 ortogonal (I like orthogonality ) concpets: OOP and AOP.

OOP (Object Oriented Programing) is a software technic which is based on the concept of object (attributs and methodes) and inheritency (a car is a vehicul which is a tranportation mode…etc).

AOP (Aspect Oriented Programing) is a software technic ortogonal to OOP which help in “doing repetitive stuff” amongs objects in a simple manner as for example: logging, security, transaction management…etc (always the same examples).

In our case, the AOP is the entry point to get more…

AOP that SoC ?

AOP can also be used to do SoC (that I like too). SoC is Seperation Of Concern. The idea is to deintroduce decoupling between layers and services of the application stack. The trend is to use AOP as a support to do SoC.

Beyond AOP…

AOP as support to do decoupling…

• some says IoC (Invertion of Control) … technical detail
• some says DI (Dependency Injection) … I hate this wording
• through a Service locator … Yes that’s it !

A service locator allows you to access services (transversal as logging, or not as an application) without bothering with wirering (managing dependencies) and creation (resolution).

You just request a specific service to your AOP system.

Back to jBoss…

So what jBoss is proposing?

• Application Container: jBoss AS
• Service Locator : jBoss IoC + ejb
• Web UI : jBoss Seam (+ ajax4Jsf or RichFaces or IcesFaces for the Web 2.0)
• Workflow engine: jBoss Seam + jBoss jBPM
• Scripting engine: jBoss Seam + groovy
• Rule engine: jBoss Seam + drool
• Wizard engine: jBoss Seam conversation context
• Persistance: jBoss + JPA + hibernate

It’s preatty amazing how jBoss is exhaustive. I may miss some important features … but that’s a good start.

I’m having at look a GRails 1.0.1. I get a little problem after setup and here is a little trick to help you if you encounter the same kind of problem.

So I installed version 1.0.1 that you can download here. I’ve set up the environment variables and launched “grails” on the command line.

At that point I get some weird message as “Xxxx was unexpected at this time”. This was due to my JAVA_OPTS. To find the problem, just setup the DEBUG environment variable to anything you want.

This way you will see the content of the batch command executed and will be able to find the root cause of your problem.

You can have a look at it …but use firefox as the web site has some display problems on IE (or maybe this is due to my IE configuration).

Finaly the famous Rails framework enter in java world, that should provide excellent reasons to no more see this RubyOnRails video:

[youtube:http://www.youtube.com/watch?v=PQbuyKUaKFo]

Robert Cooper talked about why he hates BPM products but love BPM: XML is not a programming language! I fully agree on this assertion and you can read about a post (in French) I’ve written on this.

This is true for BPM, but also for many enterprise software (see this post from Ayende about what is an enterprise software): they pretend/tend to be highly customizable to be able to match the enterprise processes without requiring high development skills…this usually true, but the drawback is the maintenance, upgrade and evolution capabilities which are usually also very poor.

I think Designer Oriented Architecture for non-techy (non-techy does not mean “no skill” at all…see later in this post) is not compatible with maintenance, upgrade and evolution capabilities. For the rest of this post and as I’m lasy, I will talk only about maintenance but you can replace by “maintenance, upgrade and evolution”. The incompatibility is simply due to the fact that a non-programmers have in fact development skills but are Morts (see Jemremy’s post which I totally agree on), meaning they have to build/customize applications to fulfil some requirements and they learn/use only what they need to do this: “Mort is a developer who only learns just what he needs to complete his project, on the project”.

Microsoft Visual Studio and .Net framework are addressing this very well. This is in itself not a bad thing, but it prevent maintenance. Evan Hoff catch it in his post. Clearly: Designer Oriented Architecture goes against maintainability…and Enterprise Softwares (or BPM products) have not yet understood this. Today, I’ve seen high level requirements for new Enterprise Software platform for an external company with 3 requirements inside the same slide: “Easy to build quality application” (where quality means testability and maintainability), “High level of extensibility without preventing upgrade” and “Ease tayloring, configure and manage applications”.

I can understand people that are looking for a Ferrari able to do cross over and consuming less than 1liter of fuel per 100 kilometre…but I’m doubtful on the success of the search.

Quality, maintenance, ease of upgrade, evolution capabilities are just incompatible with tayloring done by Mort.

Reading an interesting post from Dwhittaker, I think the problematic is broader. It appears through the question on how should I build my entity from the DAO object. To my opinion, the DAO object should be as much simple as possible…not smart at all. The best is to generate it using byte code generation for example using annotation in the real entity object for example, buit this should be addressed into another post
If the DAO object is generated, then the entity (or value object) can be build by generic code using reflection for example. Then the “real” question raise: what about information lost during the entity creation. Let me explain with a very simple example: waht about the Id of the DAO object? It has absolutely no sense in the entity object, but is required when the application push back the entity object to the persistence layer to store changes. This topic is highlighted in this post of Ayende and expose another example: detection of changes.

The problem is about keeping track of information on an object (the entity) without exposing it. more over, this object can be moved from a process to another (or webservice). This sounds very close to the state in ASP net pages, which provide a very good answer. So, I wouold advocate to store a state in the entity object that is crypted and reused by the persistence layer.

Avec l’émergence de l’AOP (Aspect Oriented Programming) et l’IoC (Invertion of Control), on voit fleurir de plus en plus de développement reposant sur l’utilisation d’XML au plus près du code. L’inconvénient majeur (d’où ce billet) que j’y vois est l’utilisation abusive de XML (voire HTML…je vais détaillé un peu plus loin) pour remplacer du code Java ou d’un autre langage. Je ne nie absolument pas la valeur que représente l’IoC, ce qui m’interroge c’est: Pourquoi vouloir utiliser un support tel que le XML pour fraire de la programmation alors qu’il n’est absolument pas fait pour cela. Cela va au delà du couple XML/IoC, on peut parler de HTML/Fit ou encore XML/BPELJ. Lier des composants ou process de haut niveau entre eux de manière découplée avec une configuration en XML à tout a fait du sens. Cependant, plus l’intégration entre ces composant devient intriquée, plus la configuration devient complexe, in-maintenable, sensible aux moindres changement. Pour le BPEL, c’est la même chose, quand l’interaction entre les process devient complexe au point de devoir faire des boucles, il est temps de se demander si on ne doit pas plutôt utiliser un vrai langage de programmation qui se chargera de masquer cette complexité. Dernier exemple: HTML/Fit, qui est un framework de test permettant a des “business analyst” ou “Ingénieurs Qualité” d’écrire des tests en HTML pour valider une fonctionnalité. Cela fonctionne très bien, jusqu’a moment ou une voit apparaitre quasiment des lignes de code dans les ligne de tableau Fit. Il est alors grand temps d’écrire une fiterie de plus haut qui va masquer ce pseudo-code, sinon il faudra être développeur pour pouvoir écrire un test…et c’est exactement l’inverse qui est recherché.

D’une manière générale, laissons aux langages de programmation la responsabilité de cacher la complexité…ou tout simplement les détails d’implémentation, et laissons au XML (ou HTML) la configuration de haut niveau compréhensible à tout le monde.

This post is the third of a serie of posts on persistance stack.

In the previous posts, I describe my humble opinion of the layering for a persistance stak for an entreprise application (for smaller application, there is no problem to mix or get ride of layers). Most of the folks talking about a persistance layer are often forgot to talk about the various services that are providing a strong added value to the applications build on top of it. So, this post is dedicated to some of these services. I’m not saying I will be exhaustive (because I simply do not know all of the potential servics that a persistance stack could provide) but I will try to go beyond what I usually see on this topic.

What is a persistance stack service?

I should;maybe say: why are they so often forgotten? I think this is because we start to deals with business requirements that are not so attractive to technical folks that prefer challenge on the core of the persistance stack. IMHO, a persistance service is an engine that can fulfill extra business requirement from a persistance perspective. That means it’s not mandatory at all from a persistance stack to provide such services as they can be provided through the applciations themselves. The huge benefit to integrate them in the persistance stack is to allow consistent and rapide application development without derundancy in code.

In this post i will details services as query language, scripting, database creation and upgrade, workflow engine, archiving, versioning and partitioning. Some of this service are low level services … I mean they require access to the lower layers of the stack (even if their configuration can be localised in the same area than configuration of higher level services).

Query language

Even if lot’s of persistance stack provide a query language, I do not concider it as a core service of the persistence stack as these persistance framework are usually presenting it as a tuning step or a way to workaround the regular usage of the framework for complexe request. Despite this, this is probably the persistance service having the strongest capabilities and is often a requirement for the other services as partitioning for example. The aim is provide a query pseudo SQL to the framework. I don’t think the key feature of this service is to provide an RDBMS independante query language…I’m sure most of you won’t agree. To me the key feature is to provide a way to provide to the application administrator a way to go beyond the application limitations…if it’s RDBMS independant: great, but we all know that even if SQL is a standard, all implementations are differents and I don’t talked about opitimization! This service is so powerful that it should be

Partitioning

This service is a low level service, that means it’s customization requires the user to use the Query Language as it expose more the database schema than business objectes. Partitioning is a way of doing segregation on (read or write) access to entities (I should say main record of entities). This is tipically a where statement.

Workflow Engine

The persistence layer will trigger this engine to handle integrity check and process steps.

Cette question refait encore surface (cf billet sur slashdot). Il est incroyable de voir tant de guerres de chapelles avec des arguments totalement loin de la vraie problématique. La question classique est “En quoi l’assembleur peut apporter quoi que ce soit alors que tout le monde utilise un langage de haut niveau style Java ou C#?”.

Primo, tout le monde n’utilise pas ce genre de langages et l’assembleur est parfois totalement indispensable dans certains domaines (drivers, pixel shader,…etc). Secundo, même en dehors de ces domaines, l’assembleur ou plus précisément des connaissances en assembleur sont très utiles. On peut sans problème coder sans avoir la moindre connaissance de l’assembleur…c’est vrai, mais il assez impressionnant de voir comment des Bac+5 se plantent sur des problèmes simples genre listes chainées. Ensuite, quand arrivent les problèmes de performances, consommation mémoire, un développeur qui ne sait absolument pas comment cela se passe en interne, sera complètement démuni. On pourrait re-phraser la question initiale en :”Quel est l’intéret de connaitre les pointeurs quand on programme en Java ou C#?”. La réponse est la même: on peut faire sans, mais on se casse les dents sur des bugs tout bêtes et on tombent sur des problèmes de consommation mémoire.

En conclusion, le langage assembleur n’est plus vraiment utilisé (saufs domaines spécifiques a ne pas négliger) mais sa connaissance (ou tout du moins la connaissance des méandres internes des langages de haut niveau) permettent d’éviter beaucoup de problèmes. Les développeurs ayant cette connaissance ont aussi en général un très bon niveau algorithmique et savent optimiser et coder correctement. Ce n’est donc pas indispensable mais reste la preuve d’un niveau élevé.

This post is the second of a set of post on the same topic starting here.

Where do I put business logic?

I’ve seen this question raised a lot of times by developers who are dealing with management applications using a persistence stack. This question is simple and legitimate but the answer is a little bit trickier.

First statement: there are different kinds of business logic which have to be in different layers. Business logic is itself fuzzy and quit large. To some extreme some could argue that the entities definition is part of the business logic, even the primary keys as a way to uniquely retrieve an entity. To the other end, a business process is considered as a kind of business logic. I personally think the business logic is wide but exclude the example I just mentioned.

Even if an entity has obviously some business inside its definition, its only data, so no logic at all. For the primary keys, I consider that a exposing primary keys is a mistake that prevent evolution and prevent implementation of high level technical services as archiving for example. The best is to expose 2 attributes per entity for retrieval: one which is human readable (as the ID of an employee) and another one which will be used for application integration. The idea is that these “IDs” are not varying from a system to another, or during the life cycle of the entities (except for exclusive business reasons), in the contrary of an internal primary key which could vary over time.

Bitwise, you can consider that the mandatoryness of an attribute (or validation) are part of the business logic. I agree some could argue it’s exclusively a data modelling concern. That’s not totally wrong but I think there is a mismatch between engine location and configuration. The engine location is of course in the data modelling layer but as this is part of the business logic (from my point of view) this should be configured in the same area as the other business logic: in the configuration. I will address the problematic of configuration later on. At the same level you have other business logics as: right management, partitioning and entity validity (broader than attributes validity).

Back to the initial question: where do I put my business logic? IMHO, the best is to define it in a set of configuration files and let the entities delegate to the appropriate engine. This provides a flexible approach (separation between the configuration and the engine) which is also generic (usage of an engine). This question is not totally addressed by this approach and hides the real problematic: scope of business logic.

The scope of the business logic is far more meaningful and key for a persistence stack. There are at least 3 different scopes:

• entity attributes
• entity
• application
• inter-applications

The entity attribute scope is for example the scope for validation/mandatoryness of the attribute PONumber in a purchase order for example. The entity scope is for example the global amount of a purchase order which is supposed to be the sum of the amount of the purchase order lines. The application scope is supposed to address the internal workflows to the application as the approval workflow of a user request for example. The inter application scope will address business logic between applications as between the requesting application/service and the catalogue application/service.
You will notice the “entity” word is ambiguous: does a purchase order line is an entity or not? IMHO, from a strict business perspective, I don’t think so, even if it’s convenient. I think a DAO can be considered as entity as soon as it has it’s own validity in the business: does not make sense to talk about a purchase order line outside of the scope of a purchase order. This distinction is sometimes used for value objects versus DAO. I personally prefer use entity and DAO and have both of them in separate layers: Data Access Layer (or data modelling layer) and Domain Layer.