mercoledì 30 aprile 2008

SOA and AOP make Sense

The discussion about SOA, AOP and OOP in Carlo Pescio Blog, and the subsequent comment by Frank, pointed me out that a sample of Sense could be in help in understanding the way we are able to introduce AOP in SOA infrastructure and instrument an already existent infrastructure.


Actually we have a Sense presentation, called Mobile Workshop, that provides and demonstrate this features. The represented business case is very simple, and has the purpose only to demonstrate the power of Sense platform.

The Workshop: scenario
My editing team produces advertising messages, used to promote products. They create only the content, and the message is saved into a Repository, let's call it an XML database.

Inside my database data are represented in a way similar to:
<content id="1"><title>the title</title>
<description>
Christmas is coming, adopt a tree and leave it its natural environment.
</description>
</content>



Users can see and embed the xml simply via http get or through a webservice.

The xml database is a system already existent in my IT division, and is an external system that doesn’t contain specific logic. It’s a system we need to integrate to.

Business problem:
My business need is to enrich, without modification into the database, the content of that external system to provide a much better user experience. The client should receive the right user experience depending on the device used.

I know, there simply is much way to create HTML from and XML, this is only to introduce and demonstrate some concepts inside Sense platform.

Sense concepts:
Sense is a platform that is able to provide Service Level Agreement to software components (and not only).

Feeling:
Components installed in Sense can be defined to be:
  • internal - deployed and running in the Sense Platform
  • external - external systems, hardware or software, that provides data or logic in my business flow: for example a database server.

Sense is able to Feel external system through special type of connectors that provide Service Level Agreement and metrics, for the external device.

Example Feeling configuration:
<components>
<feeling name="feelCms" protocols="http" mapping="*/feelingExist/*">
...
<invoker class="com.moolidoo.sense.workshop.feeling.ExistFeeling" protocol="http">
...
<sla>
<transitions>
<transition from="HIGH" to="MEDIUM" when="">D{100}">
<transition from="MEDIUM" to="LOW" when="">D{200}">
<transition from="LOW" to="NO_SERVICE" when="">D{300}">
</transition>
<when threshold="NO_SERVICE">
<mock class="com.moolidoo.sense.workshop.feeling.mock.ExistMock">
</mock>


Emotions:
in Sense there is the concept of emotion. An emotion is a “piece of code” that the system call, when something happen and the purpose is to influence other components and the behavior of the system.

In our business case I’m going to use an emotion, bound to the Feeling, to instruments the output of the XML Database with the purpose to enrich the xml, and provide the HTML to customer.

Emotions can be conditioned, and in my sample, there is an emotion per device type, so the system can modify and produce the correct html per calling device.

Example Emotion configuration:
<emotionFilter name="BrowserHtmlLayout" >
<match value="eXistCms.biz" />
<condition expression="invocation:device=html" />
...
</emotionFilter>

<emotionFilter name="NokiaN95Layout" >
<match value="eXistCms.biz" />
<condition expression="invocation:device=NokiaN95" />
...
</emotionFilter>

In a such way, my Sense platform emits information and activates emotion, without change in the Process, based on the invocation device and on the innovated service.

The result is that an external device is Feel and governed in the system, on usage of that Feeling, sense emits Emotion that influence the system itself to provide a new behavior.



In Sense, thanks to concepts like Feelings and Emotions, we enable the developer to apply techniques AOP like to instruments SOA services. Services can be external and are not modified but can be Emotioned.

domenica 27 aprile 2008

Architetture 2.0

Architetture, pensieri.

Passato

In qualità di mentore/trainer/coach su vari progetti mi sono sempre rafforzato. Percepivo le architetture software come un "insieme di componenti, ognuno con un preciso scopo, al fine di risolvere un problema". La percezione era guidata principalmente dalle competenze tecniche, dalle scelte tecnologiche e poi dal problema da affrontare.
Tant'è che nella mia testa, quando si parlava di architetture, era naturale pensare alle infrastrutture JEE, che in qualche modo hanno tutti i componenti che servono per produrre il 90% dei software moderni. La presenza della tecnologia era così forte e preponderante, da poter (e riuscire a) giustificare l'adozione di componenti e tecniche anche se non indispensabili alla corretta soluzione del problema.

Dunque, le architetture le percepivo come la:
suddivisione logica, di componenti software,
hardware e di meccanismi di comunicazione,
al fine di ospitare la soluzione ad una richiesta.

Pensieri:
Ho sempre pensato che l'architetto software è diverso dall'ingegnere del software. La differenza ritengo stia nel fatto che:
  • l'ingegnere giunge alla soluzione, applicando spesso e voltentieri un metodo o una regola, conosciuta, definita e consolidata: si basa e resta nel campo del conosciuto.
  • l'architetto aggiunge alle regole, ai metodi, anche un po' di creatività.
    Ovvero cerca la soluzione utilizzando strumenti e tecniche anche che non gli appartengono, che non sono ancora imparati. La grossa differenza che percepisco è la "visione" per intraprendere una strada che è nuova, che porti alla soluzione e che porti innovazione.
Personalmente mi sono sempre sentito più architetto che ingegnere, sebbene non sia nessuno dei due. Ho sempre fatto fatica a spiegare le mie "soluzioni", perchè spesso derivavano da un modo non convenzionale e sopratutto hanno una parte "ignota" anche a me; cerco di trovare una via, nuova, stimolante e divertente.

Questa differenza mette in luce il fatto che l'architetto ha una visione più "aperta" della soluzione, con un margine ed un aggancio oltre il campo del conosciuto. Certo che la conoscenza cresce con l'esercizio e con il tempo, pertanto questo margine di ignoto, viene colmato dal tempo. E questo rafforza la mia visione di architetto, ovvero qualcuno in grado di dare "futuro" ad una soluzione. Una soluzione che avrà parti consolidate (e dunque vecchie dopodomani) e parti innovative (e dunque moderne dopodomani). Addirittura nelle proposte commerciali, definisco l'architetto un "Time Warp architect", in grado di estendere nel futuro e rendere moderna una soluzione di oggi, anche domani. Questo prevede sicuramente una grande flessibilità, visione, curiosità e sopratutto oggettività rispetto alla tecnologia.

Evoluzione, primo segnale:
Ora, con l'avvento del Social Web, il mio concetto di architettura, fortunatamente, sta di nuovo mutando.
Questa nuova percezione ed evoluzione non è ancora chiara e definita ed andrà a rafforzarsi e comporsi sempre di più con il passare del tempo.

Le architetture non sono solo un sistema di componenti con un ruolo ben preciso, ma sono anche un insieme di comunità, alle quali fornire, ed attingere idee e soluzioni.
La comunità diventa un componente, che estende il componente software, per promuoverlo ed estenderlo nel tempo.
Ora spesso penso, quando disegno una porzione di codice, di cercare supporto oltre che nello strumento anche in uno strumento con una comunità intorno, dalla quale attingere e fornire idee, soluzioni ed esperienze.
Probabilmente i prossimi diagrammi architetturali che produrrò, oltre che avere una suddivisione per componenti e ruoli, avranno anche un altro strato:
  • una suddivisione per comunità dove ogni comunità potrà essere legata ad un solo componente, oppure potrà spaziare in più componenti.

lunedì 21 aprile 2008

Daily Fight: railroad.

Today I need to get the whole picture of a rails application. I'm an old school man, I want papers with box, arrows and description to understand relationship between things.
Nowadays Rails guys, starts coding and usually doesn't produce any Diagram with all the stuff inside. I know, it's mine limit, I'm not able to read, remember, clarify and think on a rails statement like:

class User

  • has_many :friendship
  • has_many :mails
  • has_and_belongs_to_many : items

It is very readeable and of immediate lecture, but I need box and arrow on papers. The Rails community is very active, and a colleque of mine pointed me an old (two years old) gem that provide graphics. First impression was "bLeah, i like UML, this is not UML" ruby guys are so modern... After some reading I discovered diagrams are in Business Object Notation. Ok it is not so spread, but is a common way to describe concepts; an interesting point is that is embedded in Eiffel.

A quick search for BON with google produce "BonMagazine" or "Bonjovi" .
BON doesn't have the commercial success and consensum of UML.

To generate BON diagram i proceed in installing gem railroad. Installation works without any issue. Fast and easy.

Railroad generate files into the DOT format, so you need a particular graph visualization software to see diagrams "graphwiz".

This software provides a way to render railroad-dot files, into svg/ps/gif at your pleasure.
With this installation:
railroad, graphwiz package I'm able to generate graph for "models".


But I want also controllers.
Generating controllers need gem RMagick.
Gem RMagick need ImageMagic. Wow I need the entire WWW to generate a BON diagram!

I'm quite lucky, on my MacBook I have darwin port, ready to work for me, so:
sudo ./port install ImageMagick

It takes a lot, about 20 mins, to download and compile all the stuff to enable ImageMagic.

After successfully installing ImageMagic I can proceed with RMagic gem.
Before installing I need to set my $PATH with ImageConf.
export PATH=$PATH:/opt/local/bin/

ok, let's install rmagic:
gem install rmagick -- --with-opt-lib=/opt/local/lib/ --with-opt-include=/opt/local/include/ --with-opt-dir=/opt/local/bin/

After sucessfull installation, all went fine, no errors I use the irb to check the version of just installed gem and check if really works.
irb -rubygems -r RMagick
>> puts Magick::Long_version
This is RMagick 2.3.0 ($Date: 2008/03/29 15:23:12 $) Copyright (C) 2008 by Timothy P. Hunter
Built with ImageMagick 6.4.0 04/21/08 Q16 http://www.imagemagick.org
Built for ruby 1.8.6

Ok, all works fine, so test your railroad controllers generation:
railroad $* -l -i -a -C | dot -Tgif > controller.gif
railroad $* -l -i -a -M | dot -Tgif > model.gif

Task accomplished: Railroad generates my BON diagrams.
And now, let's start thinking...

venerdì 18 aprile 2008

The magic of Ruby and Rake.

Today is the first day, I ever used rake.

First of all, it's a bit different of other "make" system usally used, in which almost all task are defined within the file. Here I have *a huge* set of premade task, ready to work for me, without the hassole of writing a piece of rake file.

How do you get the list of available tasks ?
Easy. rake --task

Today my big concern was. How to populate an emtpy test/development database, with a lot of yml file and only one Rakefile, with no task inside.
After reading some infos i succeded in:

rake db:migrate
this will create and migrate you empty db, configured into database.yml, using your db/migrate ActiveRecord::Migration provided. Clearly the order is from the first, named 001_xxx.rb to the last.

After migrating all the db, you simply populate it with:
rake db:fixture:load
this works only if you have your "*.yml" files into test/fixtures, and I have been so lucky to have it. For each table you should have your .yml file that define and describe, in the Ruby way, each record.
Get more information about YAML fixture on http://ar.rubyonrails.org/classes/Fixtures.html

And today's task is accomplished. The homepage of my ruby application is ready.