Protetto: [BigData&NoSQL] Log Management: un caso d’uso di Big Data e di Operational Intelligence

Il contenuto è protetto da password. Per visualizzarlo inserisci di seguito la password:

[Race for children] Corse e passeggiata non competitiva MonteSacro-Valle dell’Aniene

Domenica 10 Maggio 2015 si svolgerà l’evento Race for Children, una corsa di 12 km (cross) e passeggiata di 2 km in zona Montesacro e nella Riserva Naturale della Valle dell’Aniene.

Race for Children 2015

Il ritrovo è alle ore 7.30 presso la Pineta di Ponte Nomentano. La partenza è alle ore 9.30 presso Piazza Sempione. La quota di iscrizione è di 10 euro (con pacco gara e t-shirt tecnica), sia per la corsa che per la passeggiata, interamente devoluti al progetto “Una casa per i i bimbi“.

Iscrizioni presso ItalSport, via di Priscilla 73 oppure la mattina della corsa entro le 8,30.

Link al sito dell’evento: www.robertaforchildren.org

Di seguito il percorso della corsa.


Mappa Race for Children 2015

Service-level requirements: soddisfare i requisiti non funzionali di una architettura software

L’architetto software è la figura professionale che ha l’obiettivo fondamentale di progettare l’architettura di un sistema software nel rispetto dei requisiti non funzionali (NFR)Di seguito, riporto un elenco generale di accorgimenti o best practices che occorre, o conviene, seguire per rispettare i requisiti di base quali performance, availability, reliability, extensibility, manageability, maintainability security.

Il seguente elenco è stato estratto da una lista di quesiti utili alla certificazione di JEE Architect (Oracle) che sto conseguendo; esso non è esaustivo e copre casi piuttosto generali. 

 

Come si può soddisfare la scalabilità del sistema (scalability)?

  • Creando una architettura ridondante, con l’applicazione di tecniche di clustering. I tier dovrebbero essere ridondanti: web tier, application tier, database, LDAP e load balancer, componenti di rete, ecc;
  • Load balancing: è la tecnica che permette di redirigere una richiesta ad uno dei tanti server disponibili in base ad un predeterminato algoritmo di load balancing. Il vantaggio è redistribuire il carico su differenti macchine, con prestazioni non eccessive, invece di avere una singola macchina ad alte prestazioni che gestisca tutte le richieste. In questo modo si risparmia sui costi e si ottimizza l’uso delle risorse computazionali. Per implementare il load balancing occorre scegliere l’appropriato algoritmo in base alle performance e alla disponibilità richieste. Un tipico algoritmo è il round-robin;
  • Riducendo il traffico di rete usando pattern, come DTO e Session Façade, ad esempio;
  • Valutando se scalare verticalmente o orizzontalmente (vertical scaling horizontal scaling). Per scalare un sistema occorre inserire hardware aggiuntivo: scalare verticalmente significa aggiungere risorse addizionali alla macchina, come processori, memoria o dischi; invece, scalare orizzontalmente significa aggiungere altre macchine all’architettura esistente, aumentando la capacità complessiva di sistema. La prima soluzione è più semplice, poiché non ha impatto sull’architettura: infatti, per scalare orizzontalmente l’architettura deve essere predisposta per supportare una cluster-based configuration e progettata in modo che i suoi componenti non dipendano dalla macchina su cui vengono eseguiti. La scelta, comunque, dipende dal costo dell’hardware richiesto per raggiungere i requisiti di performance e di scalabilità fissati col cliente;
  • Disegnando l’architettura in maniera modulare (modularity): conviene separare il sistema in componenti auto-consistente per poter scalare singolarmente le sue parti (web, business, integration tier, ad esempio);
  • Stateless architecture. Conviene utilizzare EJB di tipo stateless: l’utilizzo di stateful session bean comporta una scelta progettuale “povera” dal punto di vista della scalabilità. Inoltre, lo stato conversazionale dovrebbe essere mantenuto lato web (con l’uso di HttpSessionURL rewriting)
  • Usando un connection pooling per le connessioni al database. Inoltre, conviene minimizzare l’utilizzo di long transaction (in generale, l’uso delle transazioni dovrebbe avvenire solo se effettivamente necessario)

 

Come si possono ottimizzare le performance di un sistema?

  •  Attraverso la ridondanza (redundancy). La capacità del sistema può crescere attraverso il vertical scaling e solitamente viene definita height. La ridondanza è la dimensione che viene calcolata in base al numero di istanze configurate per svolgere in modo sincronizzato lo stesso lavoro (ad esempio, attraverso il load balancing): tale dimensione cresce quando si scala orizzontalmente e viene definita width. La ridondanza può migliorare le performance del sistema, oltre all’availability, alla reliability, alla scalability e alla extensibility, ma può comportare un peggioramento della security e della manageability.
  • Introducendo un meccanismo di caching dei dati, in modo da ridurre l’overhead computazionale e limitando il numero di richieste concorrenti. Si potrebbe introdurre un timeout sulle operazioni long-lasting, specialmente quelle che riguardano l’accesso a servizi esterni. In questo modo si migliora il system throughput.
  • Il caching si può introdurre anche grazie all’utilizzo di pattern, come Service Locator e Value List Handler, oppure Session Facade e DTO, che permettono di ridurre il traffico di rete, permettono di esporre servizi “a grana grossa” (course-grained services) che consentono di ridurre il round-trip time all’atto della chiamata ai servizi di business;
  • L’utilizzo delle transazioni deve essere effettuato solo se espressamente richiesto. In generale, peggiorano le performance complessive del sistema, ma ovviamente non si può evitare di utilizzarle, essendo necessarie per garantire la consistenza e l’integrità dei dati. Vanno valutati i singoli casi e fatte delle scelte, trovando il giusto trade-off;
  • Session management. Le specifiche Servlet consigliano di spostare la gestione della sessione lato web, attraverso l’uso della classe HttpSession. La memorizzazione degli oggetti in sessione deve essere ragionata: salvare oggetti onerosi, come collezioni di risultati di ricerca, è un conosciuto problema denominato “performance and scalability anti-pattern”. Conviene ridurre, dunque, i dati in sessione ed effettuare aggiornamenti “a grana grossa” (course grained update).
  • L’utilizzo di un algoritmo di load balancing, come Sticky sessionconsente di avere effetti benefici sulle performance e consente di evitare di avere frequenti sincronizzazioni di dati in sessione. Lo svantaggio è sulla availability: l’utente perde la sessione, ma il failover è più veloce. L’utilizzo di un elastic load balancing e di uno short duration time di sessione avita di avere una perdita di sessione.
  • Utilizzando Java Persistence API (JPA) in modalità lazy, in modo da evitare di caricare dati inutili in modo massivo quando si effettuano le query sui dati;
  • La replicazione passiva (passive replication) consente di avere un sistema poco sovraccarico e di evitare frequenti sincronizzazioni tra i nodi replicati.

 

Come si può soddisfare il requisito della disponibilità del sistema (availability)?

  • Realizzando una architettura ridondante; tutti i tier dovrebbero essere ridondanti (web tier, application tier, database, load balancer, componenti di rete, ecc.). Prevedendo ridondanzafailoverun componente singolo può essere indisponibile e avere un impatto negativo sulla reliability, ma il servizio continua ad essere disponibile grazie alla ridondanza;
  • Dunque, conviene prevedere un clustering con failover usando un hot stand-by server (con capacità extra), ossia un componente secondario che si attiva solo in caso di necessità (soluzione che comporta una spesa aggiuntiva per un componente che potrebbe non essere utilizzato se non in caso di inattività dei componenti principali – occorre valutare se conviene sostenere tale costo, con la garanzia di avere una architettura disponibile in caso di fallimento);
  • Prevedendo una configurazione in clustering e scegliendo un cluster software che permetta di amministrare il server group, rilevando softwarehardware failure e di gestire il failover, restartando i servizi in caso di fallimento. La configurazione two-node clusters (symmetric and asymmetric) è quella più comune: quella simmetrica prevede che entrambi i cluster siano attivi nello stesso istante, invece, quella asimmetrica prevede la presenza di un stand-by failover server.
  • Prevedendo una replicazione passiva (passive replication), dove lo stato dei componenti secondari viene sincronizzato con quello del componente principale, in caso di fallimento. Per il database, si potrebbe optare per una replicazione attiva (active replication), dove i componenti cluster sono tutti principali e si sincronizzano per gestire il carico (in questo modo non si ha una capacità extra inattiva in condizioni normali di funzionamento). Tuttavia, la replicazione attiva è onerosa poiché la sincronizzazione e il coordinamento tra i componenti aggiungono un certo overhead e complessità al sistema;
  • Attraverso la definizione di un piano di Disaster Recovery e di Service-Level Agreements (SLA) per i sistemi esterni da integrare. La definizione delle SLA deve essere concordata con il cliente e fissata in modo chiaro anche per il sistema che si intende progettare.


Come si garantisce il requisito di sicurezza del sistema (security)?

  • Con la ridondanza delle componenti di sistema, diminuisce anche la sicurezza. Questo perché potenzialmente si hanno più punti di vulnerabilità nel sistema;
  • Application security: la sicurezza applicativa si potrebbe soddisfare attraverso il transport level security (come SSL/TLS EAS 256 bit) o attraverso un message level security (come ad esempio, WS-Security). Inoltre, a livello applicativo occorrerebbe prevedere sempre una input validation, filtrando gli input inseriti dagli utenti sulle interfacce web, risolvendo ad esempio il problema del cross site scripting, e prevedendo un packet filtering firewall per evitare attacchi DDoS;
  • Si potrebbe prevedere una zona demilitarizzata (DMZ) per il web e per il business tier, in modo da proteggersi da attacchi esterni, usando il protocollo HTTPS, web server operanti come reverse proxy, una business DMZ accessibile solo attraverso web server “trusted”. Anche al database si dovrebbe accedere soltanto attraverso application server “trusted”.
  • Inoltre, applicando il principle of least privilege, secondo il quale si dovrebbe accedere solo alle informazioni e alle risorse necessarie. Tale principio prevede che utenti, amministratori, programmi, sistemi, ecc. dovrebbero possedere solamente i privilegi necessari per eseguire uno specifico task. Il principio dei privilegi minimi è un importante principio per limitare l’esposizione agli attacchi e per minimizzare i danni;  
  • Per l’integrazione di servizi esterni occorrerebbe utilizzare protocolli come SSL. Ad esempio, per l’accesso a Web Services si potrebbe utilizzare JAX-WS over SSL, in modo da sfruttare il message-level data integrity, grazie all’XML Signature, e il message-level and transport confidentiality, utilizzando l’encryption (WS-Security Specification)
  • Creando una architettura che separi i componenti funzionali o prevedendo delle security zone per ciascun componente: se un componente viene violato, viene compromesso solo tale componente e non tutti gli altri presenti nel sistema (punti di isolamento);
  • Con l’utilizzo di filtri (filter), componenti server-side ospitati dal web container, che permettono di intercettare le richieste in entrata prima che vengano ricevute dai rispettivi componenti target. I filtri sono utili per pre-processare le richieste, permettendo, ad esempio, di loggare eventi o validare le richieste (security checks);
  • Sfruttando la sicurezza messa a disposizione come servizio da un EJB container, facilmente configurabile anche a run-time;
  • Prevedendo un meccanismo di authorization (soltanto un utente valido e autenticato ha gli appropriati diritti per accedere ai dati e alle funzionalità di sistema), confidentiality (assicurando che i dati e le funzionalità di sistema siano protetti da accesso non autorizzati), integrity (assicurando che i dati di sistema non siano modificati o che ci siano interferenze da parte di componenti terzi, malintenzionati e non) e authentication (assicurando che l’identità di un utente che accede al sistema sia valida e corretta e che non possa essere impersonificata o compromessa in alcun modo). Per garantire tali requisiti, si potrebbe sfruttare Java Authentication and Authorization (JAAS);
  • Prevedendo un declarative security model, dove le regole di autorizzazione sono definite attraverso un file XML (deployment descriptor). Nel caso in cui occorra gestire una sicurezza “role-based” particolare, è possibile definire un programmatic security model.

 

Come si garantisce l’affidabilità (reliability) di un sistema?

  • La reliability assicura l’integrità e la consistenza dell’applicazione e di tutte le sue transazioni. Inoltre, definisce l’abilità di un sistema o di un componente di funzionare sotto determinate condizioni per un periodo di tempo specificato. E’ possibile garantire l’affidabilità del sistema utilizzando la ridondanza (redundancy): quando un server non risponde, altri possono lavorare al suo posto;
  • Utilizzando load balancing, failover e clustering;
  • Lo sticky session ha effetti negativi sulla reliability perché l’utente perde la sessione. Per ridurre tale effetto occorre prevedere uno short time session e un elastic load balancing
  • Anche la replicazione passiva ha un effetto negativo sulla reliability, perché ci potrebbe essere un tempo di indisponibilità del sistema (down time) in caso di fallimento e conseguente attivazione dello stand-by server.

 

Come si garantisce l’estensibilità del sistema (extensibility)?

  • Avere un sistema flessibile significa che l’aggiunta di funzionalità o la modifica di quelle esistenti non hanno impatto sull’architettura del sistema. Tale misura dipende da come il sistema è stato progettato e da quanto precisi sono stati i service-level requirements stabiliti con il cliente. I principi base che occorre coprire per garantire la flessibilità del sistema sono: low coupling, interfaces encapsulation.
  • L’applicazione deve essere progettata rispettando il separation of concernsconviene prevedere differenti layer (presentation, business e data access layer). Ogni layer è debolmente accoppiato con gli altri (loose coupling), grazie all’utilizzo di pattern, interfacce, ereditarietà, incapsulamento e best practices della programmazione ad oggetti;
  • Utilizzando pattern per separare l’applicativo in concern e layer: ad esempio, utilizzando DAO, Value List Handler, Front Controller, MVC, Service to Worker;
  • Progettando un object model di alta qualità: basta applicare i principi della programmazione ad oggetti e i design pattern (ad esempio, l’MVC pattern disaccoppia i componenti di user interface dai componenti di business logic);
  • Definendo un service level agreement (SLA) con il cliente e cercando di anticipare le modifiche applicative; attraverso la definizione di SLA è possibile definire uno scope di progetto chiaro e preciso e anticipare inaspettate modifiche al sistema. Occorrerebbe identificare le possibili “changed area” del sistema (ad esempio, la tecnologia di user interface utilizzata) e isolare tali aree in componenti coerenti: in questo modo, si può prevenire che la propagazione degli effetti dei cambiamenti abbia sensibili ripercussioni in tutto il sistema;
  • La ridondanza (redundancy) e la modularità (modularity) consentono di migliorare anche l’estensibilità del sistema;

 

Come si garantisce la manageability del sistema?

  • La manageability è l’abilità di gestire il sistema per assicura di averlo in salute, grazie al monitoraggio dei QoS requirements (scalability, reliability, availability, performance, security). Inoltre, un’alta manageability consente di cambiare la configurazione del sistema per migliorare la QoS dinamicamente senza impattare l’architettura del sistema stesso;
  • La ridondanza ha effetti negativi sulla manageability e non solo sulla sicurezza;
  • Sticky session ha effetti negativi sulla manageability;
  • Utilizzando Java Management Extensions (JMX) e prevedendo differenti livelli di logging per monitorare condizioni di errore, fatali o di warning durante il funzionamento dell’applicativo;
  • Scegliendo un software idoneo di load balancer per il cluster management.

 

Come si garantisce la maintainability del sistema?

  • La maintainability è la capacità di correggere difetti nelle funzionalità esistenti senza impatti su altri componenti del sistema. Tale misura non si valuta a tempo di deploy, ma quando si progetta l’architettura e viene garantita se si rispettano i principi di low coupling, modularity e documentation. Grazie alla modularity, ogni layer è debolmente accoppiato agli altri (loosely coupling), e sfruttando i principi di separation of concerns, i design pattern, le interfacce e le best practices della programmazione ad oggetti, è possibile fare in modo che il sistema sia più manutenibile;
  • Grazie ad una buona documentazione dell’applicativo (architecture diagrams, Interface agreements con i sistemi esterni, class diagrams, sequence diagrams, Java doc, ecc.);
  • Utilizzando lo Standard JEE Stack, con tecnologie come JSF, EJB, JPA, JAAS, JTA in modo da manutenere una soluzione standard e non “specific vendor”. Ad esempio, i componenti JSF si possono riutilizzare e la stessa tecnologia JSF è definita “toolable”, grazie al supporto di IDE maturi come Eclipse, Netbeans e IntelliJ.

Gita fuori porta a Orvieto-Civita di Bagnoregio-Bolsena

Questo week-end ci siamo fatti una bella gita “fuori porta”, a pochi km da Roma. Abbiamo visitato Orvieto, Civita di Bagnoregio e Bolsena. Condiviso qui alcune foto scattate e vi consiglio di visitare questi posti magnifici, ricchi di storia, tradizione e buona cucina.

Orvieto2015

 

Pozzo di San Patrizio - Orvieto Duomo di Orvieto LaBadia Orvieto Civita di Bagnoregio Civita di Bagnoregio Civita di Bagnoregio Bolsena

[JBoss&EJB] EJB remoti: come effettuare la lookup da client JBoss

In questo articolo, descrivo come effettuare una lookup da un client JBoss verso un servizio EJB (Enterprise Java Bean) remoto, esposto su una macchina differente dal client stesso.

Queste sono le tecnologie utilizzate in questo tutorial:

ejb_lookup

Il nostro EJB remoto di test è il seguente:

@Stateless
@Remote(TestService.class)
@TransactionManagement(TransactionManagementType.BEAN)
public class TestServiceBean implements TestService {

       public methodTest(){

           //code implementation here

       }

}

Il precedente EJB remoto verrà esposto su un application server installato su una macchina differente (che chiamerò destination server). Di seguito, divido le attività di configurazione in due: configurazione destination server e configurazione client server.

 

Configurazione destination server

Sull’application server su cui è deployato l’EJB remoto, occorre semplicemente creare un utente applicativo, per mettere in sicurezza la chiamata remota (security realm). Utilizziamo lo script add-user.sh (o .bat, se siete su Windows), presente in ${JBOSS_HOME}/bin, per creare l’utente ejb (con password test):

add-user JBoss

Dopo aver creato l’utente su JBoss, basta startare l’AS e deployare il servizio remoto.

 

Configurazione client server

Il grosso della configurazione va fatta sul client che deve richiamare l’EJB remoto.

Nel file di configurazione di JBoss, standalone.xml (o domain.xml), occorre eseguire quanto segue:

  • creare il security realm sul client server
   <management>
        <security-realms>
            ...
            <security-realm name="ejb-security-realm">
                <server-identities>
                    <secret value="dGVzdA=="/>
                </server-identities>
            </security-realm>
        </security-realms>

Dove in secret c’è la password (test) codifica in BASE-64.

  • creare l’outbound-socket-binding sul client server
 <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        ...
        <outbound-socket-binding name="remote-ejb">
            <remote-destination host="127.0.01" port="4447"/>
        </outbound-socket-binding>
     </socket-binding-group>

Dove al posto dell’indirizzo IP 127.0.0.1 potete inserire quello della macchina remota del destination server (la porta di default del remoting è la 4447, a meno che non l’abbiate cambiata).

  • creare un remote-outbound-connection che usa l’outbound-socket-binding
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
....
            <outbound-connections>
                <remote-outbound-connection name="remote-ejb-connection" outbound-socket-binding-ref="remote-ejb" security-realm="ejb-security-realm" username="ejb">
                    <properties>
                        <property name="SASL_POLICY_NOANONYMOUS" value="false"/>
                        <property name="SSL_ENABLED" value="false"/>
                    </properties>
                </remote-outbound-connection>
            </outbound-connections>
        </subsystem>

Dove in corrispondenza dell’attributo username c’è l’utente di test che abbiamo creato sul destination server.

Lato configurazione del client server abbiamo terminato.

Di seguito, si riportano gli interventi da fare sull’applicazione client (client application), per poter richiamare il servizio remoto:

  • inserire nel classpath dell’applicazione client il file jboss-ejb-client.xml 
<jboss-ejb-client xmlns="urn:jboss:ejb-client:1.0">
    <client-context>
        <ejb-receivers>
            <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection"/>
        </ejb-receivers>
    </client-context>
</jboss-ejb-client>

Infine, per effettuare la lookup remota in modo programmatico, ecco un esempio di una classe client di test:

import javax.naming.Context;
import java.util.Hashtable;
import javax.naming.InitialContext;
 
...
public void invokeOnBean() {
        try {
            final Hashtable props = new Hashtable();
            // setup the ejb: namespace URL factory
            props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
            // create the InitialContext
            final Context context = new javax.naming.InitialContext(props);
 
            // Lookup
            final TestService bean = (TestService) context.lookup("ejb:" + "myapp" + "/" + "myejb" + "/" + "" + "/" + "TestService" + "!" + it.francescoficetola.ejb.TestService.class.getName());
 
            // invoke on the bean
            final String greeting = bean.test();
 
 
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
}

Nota. Quando si deploya l’EJB remoto, il JNDI name viene automaticamente registrato dall’application server. Ad esempio, per gli EJB stateless, il JNDI name è come questo:

ejb:jboss-as-ejb-remote-app/TestServiceBean!it.francescoficetola.ejb.TestService

Come si riporta in questo articolo (EJB invocations from a remote client using JNDI), ecco la regola per la generazione del JNDI name:

ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<fully-qualified-classname-of-the-remote-interface>

Poiché in app-namemodule-name mi venivano registrati anche i numeri di versione dei moduli applicativi (dopo aver buildato con Maven), ho effettuato un override dei loro valori in questo modo:

  • per settare l’app-name, ho inserito l’application-name nel file application.xml dell’EAR in cui è deployato l’EJB remoto:

<application-name>myapp</application-name>

  • per settare il module-name, occorre inserire nel classpath del modulo EJB (nella directory META-INF) il file ejb-jar.xml:
<ejb-jar xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/ejb-jar_3_2.xsd"
    version="3.2">
    <module-name>myejb</module-name>
</ejb-jar>

 

Riferimenti:

Un paese, Calabritto

Calabritto pre-Terremoto 1980Quando il mio paese (Calabritto) cominciò a sorgere, v’era un’osteria, nella quale abitava una donna, di nome Britta. Al disotto, passava una via mulattiera. I mulattieri chiamavano sempre la padrona, perché portasse loro qualche cosa da mangiare. Cala, Britta. La donna morì e, in suo ricordo, il paese, che s’ingrandì, si chiamò Càlabritto.

[Tratto da “Storie irpine” di Claudio Corvino]

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2015/01/01/un-paese-calabritto/.

iParcheggiatori: estratto dell’intervista ad Antonio Puledda sul funzionamento dell’app

Estratto dell’intervista all’amico Antonio Puledda in cui spiega, alla trasmissione “diMartedì” in onda su La7 il 18 Novembre scorso, il funzionamento dell’app iParcheggiatori. So soddisfazioni! 🙂

iParcheggiatori: intervista su La7

Il “ricco” mestiere del parcheggiatore abusivo

[Tratto da L’Indro – L’approfondimento Quotidiano Indipendente (30 Ottobre 2014) – Il ‘ricco’ mestiere del parcheggiatore abusivo]

Il confine tra folclore e illegalità è una linea sempre molto sottile allorquando si parla di Napoli e dei suoi mille mestieri. Il parcheggiatore abusivo tra questi occupa senz’altro un posto di rilievo. Il giro di affari mosso dal settore vale diversi milioni di euro. Singole aree di sosta possono rendere infatti anche 40 mila euro al mese. Un business gestito interamente dalla camorra.

Secondo l’ultimo rapporto in materia stilato dai Vigili Urbani qualche tempo fa,  Piazza Arcangelo Scacchi, alle spalle di piazza Nicola Amore, è controllato dalla famiglia Macor per conto dell’ex clan Misso. Solo per la sosta degli ‘abbonati’ entra una cifra mensile di circa 12mila euro. Ma l’area, dove si lavora anche di notte, riesce a fruttare almeno 40mila euro. Piazza Santo Sepolcro, all’altezza dell’Università Suor Orsola Benincasa lungo il corso Vittorio Emanuele è controllata dal clan Di Biase. In questo caso le entrate ammontano a 15mila euro al mese. Il Rione Luzzati, nelle mani del clan Mazzarella, rende 25mila euro al mese e molte delle auto in sosta sono di residenti costretti a pagare per lasciare l’auto e non temere ritorsioni.

Ma per chi volesse avere un elenco dettagliato e aggiornato in tempo reale del fenomeno a Napoli come nel resto d’Italia è possibile consultare i dati dal sito web iparcheggiatori.it. Nel solo capoluogo partenopeo a oggi sono 627 i parcheggiatori senza permesso che si sono appropriati di intere zone della città (l’intera Lombardia ne ha 22), cifra che sale a 1036 se si considera l’intera regione Campania che neanche a dirlo detiene il primato, seguita da Sicilia con  213 e Lazio 158. I numeri così come ci spiega l’ideatore del sito Pasquale Mauriello: Sono forniti direttamente dagli utenti. Chiunque si imbatta in una di queste figure può tranquillamente segnalare il luogo, la tipologia di parcheggiatore, aggressivo o accomodante, unitamente al costo della tariffa”. I l servizio reso dal sito, realizzato grazie anche all’apporto di Fabio Ranieri, Antonio Puledda, Michele Palantamura, Francesco Ficetola e Sara Guidotti è stato accolto con estremo favore dal Comune di Napoli che ha deciso di collaborare fornendo i dati degli interventi da parte dei vigili urbani per cercare di arginare il fenomeno.

Diversificate a seconda delle zone il denaro estorto dai parcheggiatori. “Mediamente si va da 1 a 3 euro a sosta” senza contare naturalmente gli eventi speciali come ad esempio le partita del Napoli, in quel caso l’obolo da versare può salire anche a 5 euro. “Il fenomeno è più diffuso di quanto si possa credere” argomenta Mauriello. Una condotta che più che assurgere a innocuo elemento caratterizzante la città sembra essere diventata un vero e proprio lavoro. “La differenza” argomenta questo giovane praticante avvocato con il gusto dell’innovazione  “è che prima trattavasi di casi più isolati, dettati principalmente dal bisogno di lavoro di pochi, quasi folclore in una città che ha fatto di quest’ultimi da sempre il proprio biglietto da visita, oggi invece è una vera e propria professione”.

Difficile dargli torto. Di recente un parcheggiatore abusivo intervistato da una nota radio locale ha dichiarato di versare alla camorra dai 100 ai 500 euro a seconda della zona da lui occupata. Somme a cui vanno aggiunte i guadagni personali che possono essere pari o persino superiori. Cifre apparentemente iperboliche ma che possono tranquillamente considerarsi arrotondate per difetto.  Il costo per stare tranquilli ed evitare ritorsioni ai danni dell’auto si aggira infatti da 1 euro a salire, cifra che può arrivare anche a 5 euro in caso di eventi speciali come le partite casalinghe del Napoli calcio.

Un fenomeno difficile da debellare. “Il grande problema” continua Mauriello “è che al momento non esiste una specifica figura di reato. Un parcheggiatore abusivo al di là di una sanzione amministrativa che difficilmente pagherà perché nel 90% dei casi risulta nullatenente è perseguibile solo per estorsione. Quest’ultimo reato però non è facilmente dimostrabile, in quanto comunque richiede un ruolo attivo da parte della ‘vittima’,  in questo caso l’automobilista, che il più delle volte preferisce pagare ed evitare altri grattacapi”.

Diverso l’approccio al problema da parte dei cittadini. “Premesso che la figura del parcheggiatore abusivo vive e prospera proprio perché ci sono automobilisti pronti a pagare, c’è da registrare un atteggiamento diversificato da parte dei giovani sempre più refrattari a pagare per un qualcosa che in fondo gli spetta di diritto. Altro discorso invece vale per gli anziani, più tolleranti e sempre meno insofferenti verso un fenomeno che vivono come uno dei tanti aspetti folcloristici della città”.

Già, Napoli e il suo folclore, croce e delizia di una città incapace di accettare le regole del vivere civile anche quando a farne le spese sono per primi i suoi stessi abitanti.

 

[JMS&JBoss] Configurazione delle code JMS su JBoss 7

hornetQIn questo tutorial condivido la configurazione delle code JMS su JBoss 7, utilizzando HornetQ Servermodulo già presente nelle versioni 7.x di JBoss.

Nel file standalone.xml in ${JBOSS_HOME}/standalone/configuration (o nel file domain.xml, se è questo il file utilizzato per la configurazione di JBoss), aggiungere ciò che segue:

  • Inserire il modulo messaging nelle estensioni di JBoss (se non c’è), ossia all’interno del tag <extensions>.:
<extension module="org.jboss.as.messaging"/>
  • Per configurare l’hornetQ server e registrare i JNDI name delle code (sia queue che topic), occorre aggiungere un subsystem all’interno del tag <profile>:
<subsystem xmlns="urn:jboss:domain:messaging:1.4">
 <hornetq-server>
 <persistence-enabled>true</persistence-enabled>
 <security-enabled>false</security-enabled>
 <journal-file-size>102400</journal-file-size>
 <journal-min-files>2</journal-min-files>

 <connectors>
 <netty-connector name="netty" socket-binding="messaging">
 <param key="host" value="${jboss.bind.address}"/>
 </netty-connector>
 <netty-connector name="netty-throughput" socket-binding="messaging-throughput">
 <param key="host" value="${jboss.bind.address}"/>
 <param key="batch-delay" value="50"/>
 </netty-connector>
 <in-vm-connector name="in-vm" server-id="0"/>
 </connectors>

 <acceptors>
 <netty-acceptor name="netty" socket-binding="messaging"/>
 <netty-acceptor name="netty-throughput" socket-binding="messaging-throughput">
 <param key="batch-delay" value="50"/>
 <param key="direct-deliver" value="false"/>
 </netty-acceptor>
 <in-vm-acceptor name="in-vm" server-id="0"/>
 </acceptors>

 <security-settings>
 <security-setting match="#">
 <permission type="send" roles="guest"/>
 <permission type="consume" roles="guest"/>
 <permission type="createNonDurableQueue" roles="guest"/>
 <permission type="deleteNonDurableQueue" roles="guest"/>
 </security-setting>
 </security-settings>

 <address-settings>
 <address-setting match="jms.queue.testQueue">
 <dead-letter-address>jms.queue.DLQ</dead-letter-address>
 <expiry-address>jms.queue.ExpiryQueue</expiry-address>
 <redelivery-delay>0</redelivery-delay>
 <max-delivery-attempts>5</max-delivery-attempts>
 <max-size-bytes>10485760</max-size-bytes>
 <address-full-policy>BLOCK</address-full-policy>
 <message-counter-history-day-limit>10</message-counter-history-day-limit>
 </address-setting>
 
 <address-setting match="jms.queue.DLQ">
 <max-delivery-attempts>5</max-delivery-attempts>
 <max-size-bytes>10485760</max-size-bytes>
 <address-full-policy>BLOCK</address-full-policy>
 <message-counter-history-day-limit>10</message-counter-history-day-limit>
 </address-setting>
 </address-settings>

 <jms-connection-factories>
 <connection-factory name="InVmConnectionFactory">
 <connectors>
 <connector-ref connector-name="in-vm"/>
 </connectors>
 <entries>
 <entry name="java:/ConnectionFactory"/>
 </entries>
 <client-failure-check-period>2147483646</client-failure-check-period>
 <connection-ttl>-1</connection-ttl>
 <reconnect-attempts>-1</reconnect-attempts>
 </connection-factory>
 <connection-factory name="RemoteConnectionFactory">
 <connectors>
 <connector-ref connector-name="netty"/>
 </connectors>
 <entries>
 <entry name="RemoteConnectionFactory"/>
 <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
 </entries>
 <ha>true</ha>
 <block-on-acknowledge>true</block-on-acknowledge>
 <retry-interval>1000</retry-interval>
 <retry-interval-multiplier>1.0</retry-interval-multiplier>
 <reconnect-attempts>-1</reconnect-attempts>
 </connection-factory>
 <pooled-connection-factory name="hornetq-ra">
 <transaction mode="xa"/>
 <connectors>
 <connector-ref connector-name="in-vm"/>
 </connectors>
 <entries>
 <entry name="java:/JmsXA"/>
 </entries>
 <client-failure-check-period>2147483646</client-failure-check-period>
 <connection-ttl>-1</connection-ttl>
 <reconnect-attempts>-1</reconnect-attempts>
 </pooled-connection-factory>
 </jms-connection-factories>

 <jms-destinations>
 <jms-queue name="testQueue">
 <entry name="queue/TestQueue"/>
 <entry name="java:jboss/exported/jms/queues/TestQueue"/>
 </jms-queue>
 <jms-topic name="testTopic">
 <entry name="topic/MyTopic"/>
 </jms-topic>
 </jms-destinations>
 </hornetq-server>
</subsystem>
  • Aggiungere i seguenti messaging port nel tag <socket-binding-group>:
<socket-binding name="messaging" port="5445"/>
<socket-binding name="messaging-throughput" port="5455"/>
  • Immediatamente sotto il tag subsystem <subsystem xmlns=”urn:jboss:domain:ejb3:1.4″> (e prima del tag session-bean) aggiungere quanto segue:
<mdb>
    <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
     <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
</mdb>
  • Sempre in <subsystem xmlns=”urn:jboss:domain:ejb3:1.4″>, controllare che in pools ci sia quanto sottolineato di seguito (altrimenti aggiungerlo):
<pools>
    <bean-instance-pools>
          <strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
          <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
     </bean-instance-pools>
</pools>

NOTA 1: la porta mappata nel socket-binding (nell’esempio , la porta 5445) non deve avere restrizioni di rete.

NOTA 2. Per evitare la seguente eccezione:

11:56:54,753 WARN  [org.hornetq.jms.server] (ServerService Thread Pool — 52) HQ122017: Tried to correct invalid “host” value “0.0.0.0” for “netty” connector, but received an exception.: java.net.UnknownHostException: XXXXXXX: XXXXXXXX

Occorre mappare sul file etc/hosts la seguente regola:

0.0.0.0  HOSTNAME

Dove HOSTNAME è il nome macchina (valore restituito lanciando il comando hostname da terminale).

TEST: per verificare la correttezza della configurazione delle code JMS, basta restartare il server e verificare che non ci sia nessuna eccezione sul log server.log.

 

Configurazione delle code JMS in ambiente clusterizzato (Clustering HornetQ)

hornetq-ha-cluster

Aggiungere alla configurazione precedente quanto segue (solo in ambiente clusterizzato):

<server name="xyz" xmlns="urn:jboss:domain:1.1">
  <profile>
    ...
    <subsystem xmlns="urn:jboss:domain:messaging:1.1">
      <hornetq-server>
        ...
        <connectors>
          <netty-connector name="netty" socket-binding="messaging"/>
          ...
          <netty-connector name="server2-connector" socket-binding="messaging-server2"/>
          <netty-connector name="server3-connector" socket-binding="messaging-server3"/>
        </connectors>
        ...
        <cluster-connections>
          <cluster-connection name="default-cluster-connection">
            <address>
              jms
            </address>
            <connector-ref>
              netty
            </connector-ref>
            <retry-interval>
              500
            </retry-interval>
            <forward-when-no-consumers>
              true
            </forward-when-no-consumers>
            <static-connectors>
              <connector-ref>
                server2-connector
              </connector-ref>
              <connector-ref>
                server3-connector
              </connector-ref>
            </static-connectors>
          </cluster-connection>
        </cluster-connections>
        ...
      </hornetq-server>
    </subsystem>
    ...
  </profile>
  <socket-binding-group name="standard-sockets" default-interface="public">
    ...
    <socket-binding name="messaging" port="5445"/>
      ...
      <outbound-socket-binding name="messaging-server2">
        <remote-destination host=”#Indirizzo_Cluster_1” port="5445"/>
      </outbound-socket-binding>
      <outbound-socket-binding name="messaging-server3">
        <remote-destination host=”#Indirizzo_Cluster_2” port="5445"/>
      </outbound-socket-binding>
  </socket-binding-group>
</server>

NOTA. Sostituire gli indirizzi IP in remote-destination (in outbound-socket-binding) con quello dei nodi cluster JBoss (così come su evidenziato e commentato).

Riferimento: Clustering HornetQ – Red Hat Documentation

Escher a Roma: mostra al Chiostro del Bramante

I bellissimi capolavori di Maurits Cornelis Escher saranno in mostra a Roma al Chiostro del Bramante dal 20 settembre e fino al 22 febbraio 2015.

IMG_0033.JPG

IMG_0032.JPG

Questa è la sua opera che più mi piace: Drawing hands

IMG_0036.JPG