L’altro giorno tornando a casa trovo accanto alla porta un avviso di un pacco non recapitato proveniente dagli Stati Uniti. La prima cosa che mi è venuta in mente è stata: “maledetti autovelox, ci sono anche là!” visto che ad Agosto ho fatto un giro nella West Coast percorrendo 4000km in macchina! Il giorno dopo mi portano il pacco e vedo subito che è un po’ troppo grande per contenere una multa. Lo apro e c’è la sorpresa: una bella accusa di violazione di alcuni brevetti da parte di Lodsys per la mia applicazione Folder Organizer lite.

I Design Pattern (soluzioni progettuali generali a un problema ricorrente) sono molto inportanti nel software, a prescindere dal linguaggio di programmazione. In questo post vediamo insieme l’utilizzo del Builder Pattern in Java come alternativa all’utilizzo dei costruttori in overloading. L’obiettivo è quello di rimpiazzare costruttori poco leggibili e scomodi da utilizzare con una classe che si preoccupa della creazione dell’oggetto, fornendo metodi appropriati per i parametri e la validazione.

Riprendiamo e concludiamo il filone dei Message Driven Bean (MDB) che avevamo iniziato in due post precedenti: in uno più teorico, avevamo descritto la struttra asincrona dei MDB che ricevono e inviano messaggi JMS, con riferimento a qualche pattern architetturale; nel secondo avevamo invece messo mano al codice, in particolare su come implementare il Request/Reply pattern basato sul Correlation ID. Come promesso, vediamo adesso cosa bisogna fare per implementare invece il pattern basato su Message ID.

37Signals è una azienda di informatica abbastanza piccola (per scelta!) ma che sta facendo grandi cose nel mondo del software. Dall’esperienza accumulata negli ultimi 10 anni sono nati due libri molto interessanti, il primo è Rework. Manifesto del nuovo imprenditore minimalista. Come avere successo con poche risorse (in inglese è Rework. Change the way you work forever). Il secondo libro si intitola Getting Real ed è disponibile gratuitamente nel sito ufficiale

La risposta alla domanda “quale è la differenza fra ejb stateful e stateless?” sembra evidente: gli stateful mantengono lo stato e possono essere usati per il classico carrello della spesa mentre gli stateless non avendo uno stato possono essere usati per implementare dei servizi. Ma siamo sicuri che la risposta è così semplice? Per quanto viene mantenuto lo stato di un ejb stateful? Per la durata della sessione web? Proviamo a fare un po’ di chiarezza in questo post.

In un post precedente abbiamo introdotto un po’ di teoria che sta dietro ai Message Driven Bean (MDB): è importante conoscere l’architettura su cui si basano questi strumenti perché è molto diversa dai componenti sincroni con cui siamo soliti lavorare (leggi Session Beans). La teoria è importante perché ci permette di capire cosa accade dietro le quinte (e soprattutto perché si scrive un certo codice), ma se non vediamo come si mette in pratica serve a ben poco!