L’orientamento ai servizi è inevitabile

Da circa due settimane è in atto una bagarre senza fine a seguito dell’articolo “Soa is dead, long live services” pubblicato da Anne Thomas Manes sul blog di Burton Group: la SOA (Service Oriented Architecture), come sinora fatta in buona parte dei casi, è dichiarata morta; l’orientamento ai servizi, invece, necessario e inevitabile, ora più che mai.

—-><—-

Per approfondire:

• InfoQ – Debate: Is SOA Dead?
• Service Architecture – SOA: In a recession its even more about the services
• SOA Infrastructure Blog – Goodbye SOA, we hardly knew you
• Service-Oriented Architecture – Manes: let’s get more ‘concrete’ about service orienting
• Ajaxonomy – Is SOA Dead?
• ZapThink – Research: The Rumors of SOA’s Demise…

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!

SOUI: Service Oriented UI Architecture

La presentazione che Jeff Haynie condivide su Slideshare.net definisce la “Service Oriented UI Architecture” (interfacce utente – applicazioni lato client – che eseguono la logica, mantengono la sessione e consumano servizi senza stato – API lato server) e introduce brevemente Appcelerator: un framework Open Source con cui implementare questo modello.

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!

Registry e Repository SOA: ricerche

In un articolo precedente (Registry e Repository SOA: interfacce UDDI) descrivevo come un registry-repository SOA sia deputato tra l’altro a:

• censire e catalogare servizi (chi offre cosa, con quali interfacce e dove)

• mantenere i documenti delineati dal SOA Reference Model di Oasis (descrizioni delle funzioni, effetti, policy, contratti, ecc.)

Lasciavo intuire, inoltre, la necessità, sopratutto in fase di progettazione, di poter eseguire ricerche.

Un registry-repository esposto secondo le specifiche UDDI gestisce:

• nomi logici e chiavi (del servizio, di chi lo offre, delle interfacce, dei punti di accesso e delle etichette)

• etichette (i tModel, a loro volta etichettati da altri tModel, assegnati al servizio, a chi lo offre e ai punti di accesso)

• riferimenti (URL contenute in tModel) a documenti vari (ad esempio interfacce, descrizioni, policy, contratti, ecc.)

Le ricerche, quindi, implicano conoscenza, almeno sommaria, di chi offre cosa o del modello di catalogazione (la tassonomia, rappresentata con le etichette). In alcuni casi (ad esempio quando si ignora la catalogazione adottata o si ha solo una vaga idea di cosa cercare), queste modalità possono essere insufficienti.

Di grande valore può essere la ricerca a testo libero sui documenti. Poter ricercare all’interno di queste informazioni (funzioni, effetti, interfacce, strutture dei messaggi, policy, ecc.) da buona certezza di trovare cosa si cerca (riduce il rischio, ad esempio, di duplicare l’esistente). Purtroppo la specifica UDDI non prevede questo tipo di ricerca: il registry-repository può implementarla esponendola solo al suo interno (interfacce utente, sopratutto, o API proprietarie).

Meno potente, diversa, ma prevista dalla specifica è la ricerca attraverso etichette. Usate come folksonomy (si veda, ad esempio, SOA Infrastructure Blog: Folksonomies In The Enterprise), come tassonomia o come compromesso tra le due, individuano insiemi di servizi. Presuppone un attento studio propedeutico (è necessario trovare una classificazione semplice, adatta, poco rigida ed efficace).

—-><—-

Hai trovato questo post interessante? Sottoscrivi il feed completo e partecipa alla discussione