You are currently browsing the category archive for the ‘Techies’ category.

SCA fornisce un modello di programmazione per la costruzione di applicazioni e di soluzioni basate su una Service Oriented Architecture. Il modello si basa sull’idea che le funzionalità di business possono essere composte a partire da una serie di servizi, che vengono assemblati insieme per creare soluzioni che servono un particolare requisito di business. Queste soluzioni sono definite Composite Applications, e sono rappresentate graficamente da Assembly Models. Le composite application possono contenere sia nuovi servizi creati specificamente per la applicazione che servizi esistenti offerti da sistemi e applicazioni esistenti, riusati come parti della composizione. La figura seguente mostra un esempio di assembly model per una composite application.

SCA assembly model

SCA Assembly Model (cliccare sulla figura per ingrandire)

Il modello di programmazione SCA è uno standard in via di formalizzazione a cura della iniziativa Open Composite Services Architecture (OpenCSA) di OASIS. SCA standardizza le informazioni scambiate tra differenti tools, assicurando che i servizi e i componenti che costituiscono un’applicazione vengano modellati, rappresentati e descritti in modo coerente. La coerenza significa che i servizi costruiti in strumenti differenti, usando differenti paradigmi di programmazione possono facilmente essere riusati e portati velocemente in produzione, aiutando le organizzazioni a realizzare l’efficacia promessa da SOA.

BEA usa SCA come standard per facilitare lo scambio di informazioni tra i prodotti BEA, come ALSB, ALDSP, ALBPM, WLS, WLP, WLI e Tuxedo-SALT. BEA ha intenzione di utilizzare SCA anche per facilitare scambio di informazioni con prodotti di terze parti.

Ciò significa che servizi fornite da piattaforme per data services, da service bus, da strumenti per business process modeling, etc. possono essere catturati e rappresentati in un formato comune, e poi riusati facilmente per comporre altre applicazioni di business.

Il Service Assembly Modeler
Il Service Assembly Modeler (SAM) di BEA supporta la composizione e la visualizzazione di applicazioni composite. La composizione avviene in un ambiente di sviluppo basato su Eclipse. In questo ambiente il gruppo di sviluppo può assemblare rapidamente applicazioni composite riusando servizi che esistono già, o creando nuovi servizi. SAM consente agli sviluppatori di vedere il modello di assemblaggio delle applicazioni composite, così come la definizione in linguaggio XML della composizione.

AquaLogic Enterprise Repository (ALER) consente alle organizzazioni di gestire le applicazioni composite e i servizi riusabili. I gruppi di sviluppo possono sottomettere le loro applicazioni composite in ALER direttamente da SAM. ALER fornisce visibilità alle applicazioni e ai servizi esistenti, tracciabilità tra le applicazioni composite e le loro dipendenze, dati analitici che misurano il riuso e facilitano la analisi di impatto.

Il Service Assembly Modeler (SAM) è un plug-in per Eclipse che fornisce strumenti per lavorare con i modelli di assemblaggio SCA per i servizi compositi. SAM viene distribuito con AquaLogic Enterprise Repository (ALER) e altri prodotti della famiglia BEA AquaLogic.

Si può usare SAM per:

  • Rendere compatibili con SCA le applicazioni AquaLogic esistenti e poi creare service assembly model basati su queste applicazioni.
  • Visualizzare composizioni SCA e altri artefatti di tipo service assembly model.
  • Sottomettere modelli in AquaLogic Enterprise Repository (ALER).

Links

Introduzione a SCA:
http://en.wikipedia.org/wiki/Service_component_architecture
http://weblogs.java.net/blog/meeraj/archive/2008/01/introducing_ser.html

Prodotti BEA:
http://e-docs.bea.com/aler/docs30/pdf/SAMhelp.pdf
http://www.bea.com/framework.jsp?CNT=pr01891.htm&FP=/content/news_events/press_releases/2007
http://ecommerce.bea.com/showproduct.jsp?family=WLS&major=10.3SCA&minor=-1

Specifiche:
L’attuale insieme delle specifiche SCA sul sito OSOA comprende:
SCA Assembly Model
SCA Policy Framework
SCA Java Client & Implementation
SCA BPEL Client & Implementation
SCA Spring Client & Implementation
SCA C++ Client & Implementation
SCA Web Services Binding
SCA JMS Binding

Annunci

La gestione degli aspetti di Authentication, Authorization ed Accounting (AAA) riveste un’importanza fondamentale per la sicurezza sia delle applicazioni usate all’interno dell’azienda stessa che di quelle utilizzate per proporre servizi alla propria clientela.

Questo a maggiore ragione in questi ultimi anni in cui la legge sulla privacy ha introdotto ulteriori requisiti e spostato la sicurezza da un solo concetto di difesa per chi eroga un servizio ad un meccanismo di difesa di chi usa quel servizio e come tale è costretto a fornire dati sensibili.

Le attuali soluzioni di Identity Management che implementano le funzioni di AAA hanno risolto egregiamente gli aspetti di Autenticazione che, tramite il Single Sign-On, permettono inoltre di unificare e centralizzare il controllo e la profilazione degli utenti.

Questo non è vero per quanto riguarda l’Autorizzazione soprattutto se questa è intesa come gestione dell’entitlement (cosa un utente è abilitato a fare) di tipo totalmente centralizzata, fortemente granulare e con alto gradi di dinamicità.

Ad oggi molto spesso la gestione dell’entitlement è implementata all’interno della singola applicazione rendendo difficile, se non impossibile la gestione dell’Autorizzazione in una architettura orientata ai servizi, dove l’applicazione non conosce a priori il contesto nel quale il servizio che offre viene “consumato”.

Ma cosa si intende esattamente per Entitlement?

La parola entitlement, specialmente se tradotta dal dizionario, può significare cose diverse a persone diverse. In questo contesto, per entitlement si intende un insieme di privilegi che governano quello che l’utente di una applicazione è abilitato a fare.

Un entitlement è la relazione tra una risorse dell’applicazione (o in forma più astratta un oggetto di business) e l’insieme di utente/gruppo/ruolo, rappresentata secondo una struttura gerarchica.

ALES fig1

Gli entitlement:

  • sono soggetti ad una massima proliferazione;
  • necessitano di considerare diverse informazioni di contesto prima di effettuare una decisione;
  • devono essere consistenti all’interno dell’infrasttuttura e all’insieme delle applicazioni;
  • devono essere allineati con i sistemi di Identity Management;
  • devono evolvere indipendentemente dalle applicazioni e dai servizi;

Tuttavia….

ad oggi la maniera più comune di implementare gli entitlements è cablarli nel codice dell’applicazione!!!

Per rispondere a questa esigenza BEA ha sviluppato la soluzione BEA AquaLogic Enterprise Security che permette di esternalizzare, unificare e semplificare la gestione delle politiche di autorizzazione ovvero degli entitlement.

La figura seguente mostra un esempio di applicazione di trading. Questa applicazione può essere usata da differenti tipologie di utenti, ma solo gli utenti che sono traders possono fare operazioni di acquisto/vendita. Inoltre, i traders posso operare solo per gli specifici conti per i quali sono autorizzati e solo fino ad uno specifico importo per ogni definito per ogni conto.

ALES fig2

 

Come si può vedere nel secondo caso, la decisione è rimossa dall’applicazione e valuta a runtime dal motore di BEA AquaLogic Enteprise Security.

Utilizzando BEA AquaLogic Enterprise Security all’interno della propria infrastruttura si possono quindi definire le linee guida con cui devono essere sviluppate le applicazioni per quanto riguarda la funzionalità di gestione dell’Autorizzazione, ovvero:

  • nessuna policy cablata nel codice
  • nessuna policy dipendente da un file di configurazione
  • scrittura del codice uniforme verso un unico layer per la gestione della sicurezza

Come funziona AquaLogic Enteprise Security in dettaglio?
Al prossimo post…

artofperformancemonitoring.jpg 

Per aiutarvi ad ottenere le prestazioni ottimali dai vostri sistemi sono oggi disponibili molti strumenti di Monitoraggio e Analisi.

Tuttavia non vi saranno di aiuto o potrebbero additrittora contribuire ad accrescere i problemi prestazionali se usati in modo improprio.

Per ottenere le prestazioni ottimali dalle vostre applicazioni WebLogic, dovrete guardare al di là degli strumenti automatizzati e rispondere ad alcune domande relative al vostro business.

Questo post (ne seguiranno altri sullo stesso tema) vuole evidenziare le domande che ogni cliente dovrebbe chiedersi quando si analizzano problemi prestazionali.
Ovviamente la lista di domande possibili è potenzialmente infinita, ma vorrei evidenziare le motivazioni più comuni per cui sorgono problemi prestazionali.

Tante variabili e sempre poco tempo….
E’ importante notare che l’analisi prestazionale è un’arte, più che una scienza esatta. Buone prestazioni sono raggiungibili con compromessi e bilanciamenti ragionati. 

Cosa volete ottenere?
Queste sono alcune delle ragioni, rilevate dalle mie esperienze con Clienti con problemi sorti durante la messa a punto dell’Application Server.
– Avere migliori tempi di risposta
– Raggiungere o superare i Service Level Agreement
– L’efficienza della JVM (Java Virtual Machine)
– Capire perchè il sistema rallenta ad una certa ora il venerdi pomeriggio
– Durante i test tutto “girava” alla perfezione, ora che l’applicazione è in produzione invece sembra essere molto lenta nelle esecuzioni

“Forse perchè…”, “rivediamo le configurazioni…”, “proviamo a fare…” non sono ovviamente risposte accettabili.

Queste domande meritano una risposta puntuale.
 

Chi deve essere soddisfatto delle prestazioni?
Rassegnatevi al fatto che non potrete rispondere a tutte le richieste di aumento prestazionale che arrivano dal management o dagli utenti di business della vostra Azienda.

Dovrete esculdere i problemi che risultano ad di là della vostra capacità o autorità di intervento.

Risorse finanziarie ridotte, disponibilità limitata di risorse adeguate, politiche aziendali, e infrastrutture informatiche limitate sono alcune delle barriere che potreste incontrare. In questo caso potreste avere poca o nessuna possibilità di intervento.

Focalizzatevi sull’elenco di elementi su cui potete avere sicuramente un impatto positivo, ed eliminate quelli che non potete modificare.
Con questa lista considerate da quali elementi potete partire subito, i problemi che, se risolti, potrebbero portare un maggiore beneficio alla vostra Azienda, e il costo per indirizzare ogni problema..

Prima di partire, dovreste anche individuare “chi” state cercando di soddisfare, e quindi date una priorità alla vostra lista.

Nella prossima puntata… “Cosa misurare???”

Una caratteristica utile di Weblogic Server, dalla versione 9 in poi, è il cosiddetto production redeployment: una strategia di deployment delle applicazioni web che consente la coesistenza di due versioni dell’applicazione, garantendo il rilascio di una nuova release senza interrompere il servizio offerto agli utenti. E’ utile per la correzione di bug o per l’aggiunta di nuove funzionalità, senza dover chiudere l’applicazione nè aggiungere server ridondanti per redirigere il traffico durante la sostituzione.

Quando la nuova versione viene attivata, la vecchia viene mantenuta in funzione dal server finchè le sessioni utente già attive vengono completate oppure vanno in time out: nel frattempo la nuova versione comincia a servire tutte le nuove richieste. La figura seguente mostra come le richieste http vengono gestite da WLS:

Side by side deployment

Gli utenti che stavano navigando non subiscono alcun effetto dell’attivazione della nuova versione, quindi non è necessario pianificare finestre temporali di rilascio, magari di notte o nel week end come a volte si è costretti a fare. Versioni successive delle applicazioni possono essere storicizzate sui server, per cui è sempre possibile tornare indietro ad una versione precedente con la stessa modalità trasparente agli utenti. Inoltre, se una nuova versione viene attivata in Administration Mode, questa diviene visibile solo sul canale di amministrazione di WLS: ciò consente di eseguire test di corretto funzionamento prima dell’apertura al normale traffico utente.

test della nuova versione in administration mode

Le operazioni di deployment e di attivazione delle versioni possono, come tutte le operazioni di amministrazione, essere eseguite attraverso la console web di WLS, attraverso script ANT o WLST, programmi java o strumenti esterni di configuration management. Alcuni tipi di applicazione non possono essere gestiti con questa modalità di rilascio, che è limitata a web applications e enterprise applications: vedere la documentazione online di WLS per i dettagli.

Un bel post apparso sul blog Manageability, descrive i 5 prossimi trend per sviluppatori Java, Lo trovate qui.

Attualmente, nell’industria del software il Supporto Clienti rientra in una delle seguenti categorie: il supporto proattivo e il supporto reattivo.Il supporto proattivo (in BEA è rappresentato dal livello di Supporto deniminato Mission Critical) rappresenta un approccio intensivo alla risoluzione dei problemi di sistema individuati, prima che questi ultimi provochino tempi elevati di inattività o influiscano sulla produttività e sul business dei Clienti. Con il supporto proattivo si controllano i sistemi e interviene sulla causa principale di un problema prima che si aggravi.Il supporto reattivo, al contrario, risolve i problemi dopo che essi hanno già avuto qualche impatto sulle applicazioni e sul business, cercando di eliminare il problema esistente e di ripristinare il normale funzionamento del sistema.Tuttavia, sia il modello di supporto proattivo che quello reattivo lasciano talvolta i Clienti insoddisfatti.  Entrambi i tipi di supporto possono risultare dispendiosi, sia in termini di tempo che di denaro; infatti entrambi i modelli implicano che il problema si verifichi prima che sia possibile intervenire. L’identificazione e la risoluzione dei problemi esistenti possono richiedere un numero maggiore di ore di lavoro e di impiego di risorse.BEA sa che i sistemi complessi rappresentano il centro nevralgico delle aziende dei Clienti, che non possono certo affidarsi solo a questi modelli di supporto “guasto/riparazione”. I nostri Clienti richiedono sempre di più un supporto continuo (24 ore al giorno, sette giorni su sette), in grado di identificare i potenziali problemi prima che si verifichino.Necessitano inoltre di un paradigma di supporto assolutamente affidabile.BEA ha quindi indicato una nuova tipologia di supporto, che ha chiamato “preventivo“.BEA Guardian è la risposta di BEA alle esigenze precedenti, individuate grazie ad approfondite ricerche e analisi sul campo. (Scaricate le analisi di Forrester Research)Le ricerche eseguite da BEA indicano che oltre il 40% dei problemi sono dovuti a errori di configurazione e amministrazione.L’identificazione dei problemi di configurazione e amministrazione e l’elaborazione dei relativi report garantiscono che l’implementazione disponga di patch, impostazioni di configurazione e altri attributi corretti. BEA Guardian notifica persino gli eventuali conflitti di configurazione con le best practice applicate da BEA.BEA Guardian è uno strumento intuitivo per il supporto di sistema preventivo, progettato per individuare i potenziali problemi prima che questi richiedano l’intervento del personale di supporto IT o influiscano negativamente su operazioni e clienti.BEA Guardian consente inoltre di ottimizzare le implementazioni e le operazioni giornaliere.Se l’installazione di BEA Guardian dispone di connettività Internet, è anche possibile trarre vantaggio dalla creazione diretta di Chiamate (CASI) al BEA Customer Support, nonché dagli aggiornamenti automatici.Per saperne di più e per scaricare documenti e prodotto visitate la pagina “BEA Guardian” sul sito www.bea.com

Non è un blog, è una brochure!” Questo è stato il commento di un amico che ha letto Caffè con BEA e sigh, io sarei tra i colpevoli. In effetti nel mio post precedente ho parlato e dato un giudizio positivo di un prodotto BEA, WebLogic Integration. Chiedo venia, purtroppo posso parlare di ciò che conosco. Per tentare di farmi perdonare, vi propongo un’altra riflessione, certo basata su WLI (vedi sopra) ma applicabile a tutti i prodotti dello stesso tipo.Spesso mi sono imbattuto in clienti che mi chiedevano: perchè dovrei usare un motore di processi ? Ecco, secondo me, le ragioni per utilizzarlo e quelle per farne a meno:I motivi del SI

  1. si sviluppa più in fretta (perchè i wizard mi nascondono le complessità delle interfacce da usare)
  2. si fà l’integration test più in fretta (perchè il debug di front-end e back-end è integrato)
  3. la gestione dello stato dei processi è già pronta e non richiede ulteriore sviluppo
  4. il monitor dei processi in produzione è già pronto e non richiede ulteriore sviluppo
  5. è più semplice modificare l’applicazione quando è già in produzione

I motivi del NO

  1. non ho controllo del codice perchè uso molti wizard e componenti già pronti
  2. non posso realizzare certi trucchi, perchè lo strumento me lo impedisce
  3. vorrei poter controllare alcuni dettagli dei processi in esecuzione, mentre lo strumento me ne visualizza altri

Le due liste non sono esaustive, anzi vi esorto a completarle o a modificarle secondo la vostra esperienza. Per quanto mi riguarda, e qui rischio l’ennesima stroncatura, i sostenitori della seconda lista finiscono spesso per riscriversi un process engine quasi per intero e dunque, io che sono di natura un pigro, mi chiedo: non era meglio prenderlo già pronto? 😉

Tempo fa partecipai ad un avvincente progetto di integrazione: inserimmo un “bus” per lo scambio di messaggi fra le diverse applicazioni di una SIM (Società di Intermediazione Immobiliare) e grazie a questo “strano oggetto” i traders ed i loro capi potevano vedere informazioni tra loro correlate ma che risiedevano in sistemi differenti ed isolati. Le modifiche avvenivano in tempo reale ed i dati erano dunque sempre aggiornati.

Ma non fu questa la parte che più piacque al cliente. L’iniziativa ebbe successo grazie alla rapidità con la quale l’IT riusciva a realizzare le richieste dell’utente finale. Oltre naturalmente, all’affidabilità del sistema, che non perdeva un messaggio.

Se, dopo quasi dieci anni, cito ancora quell’esperienza è perchè il confronto con la realtà di oggi appare ancora istruttivo: le interfaccie di comunicazione fra il bus e le applicazioni da integrare venivano sviluppate a mano di volta in volta, partendo da un set di librerie proprietarie. Non esisteva il concetto di processo o di orchestrazione. Il mapping dei dati era realizzato con uno strumento visuale che alimentava un motore esterno al bus. Forse ciò che è cambiato meno da allora ad oggi è la trasformazione dei messaggi. Eravamo già ad uno stadio evoluto, anche se non utilizzammo standards come XML.

In un progetto più recente che ho potuto osservare da vicino, il system integrator ha semplificato la componente di integrazione ed introdotto l’uso di un motore di processi utilizzando WebLogic Server e WebLogic Integration. Il bus comunica con le applicazioni via SOAP, RMI o JDBC, ed ha integrato la componente di processo consentendo la creazione di nuove funzionalità basate su quelle offerte dei sistemi esterni.

WebLogic Integration ha fatto la parte del leone. Ha consentito l’integrazione delle applicazioni e lo sviluppo dei processi in pochissimo tempo. L’infrastruttura di test inclusa nel prodotto ha ridotto i tempi di collaudo e le funzionalità del motore hanno sollevato il system integrator dall’onere di dover sviluppare da sé la logica di stato e persistenza di messaggi e di processi.

wliworkbench.jpg

Naturalmente non solo BEA Systems offre strumenti di questo tipo. Ma ciò che voglio evidenziare, al di là dei prodotti utilizzati, è il progresso avvenuto in questo campo. Si programmano sempre meno le interfaccie di comunicazione (che son sempre state una materia ostica, nello sviluppo e nel collaudo) e si riduce sempre di più il tempo di realizzazione di nuove funzionalità, grazie all’uso dei process engine come WebLogic Integration.

Oggi affronto un progetto d’integrazione con grande serenità, convinto che l’adozione di WebLogic Integration sollevi il team da molto lavoro inutile, elimini le cause di tanti errori e consenta di raggiungere l’obiettivo con tempi certi e, cosa più importante, con la soddisfazione del cliente.

 

Attenzione!

Questo sito non è piu' aggiornato. Vieni a trovarci sul nuovo Caffe' con BEA

Disclaimer

I post su questo blog rappresentano i pensieri personali dei singoli autori e non rappresentano le posizioni ufficiali di BEA Systems. Se scrivete commenti, essi saranno rivolti solo ai singoli autori e non a BEA Systems. Le immagini ed i filmati possono essere tratti da Internet: qualore violassero eventuali diritti di autore, segnalatelo subito a pfurini@bea.com.