ITLAB – Laboratorio IT

SOA (Service Oriented Architecture), Web 2.0, Open Source e Java.

  • Feed

    Feed ITLAB

  • Chi sono

    Mi chiamo Andrea Gumina. Sono laureato in Scienze dell'Informazione e lavoro per un'azienda di consulenza IT. Da qualche anno mi occupo di integrazione di sistemi, di SOA (Service Oriented Architecture) da poco meno di tre.

  • Bookmarks

  • Licenza

  • Statistiche

Registry e Repository SOA: ricerche

Pubblicato da Andrea Gumina su 5 Giugno 2008

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

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

Lascia un commento

XHTML: Puoi usare questi tag: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>