Please enable JavaScript.

Coggle requires JavaScript to display documents.

Service Discovery Particolare naming system per sistemi mobili, in cui…

- - - - Si registra presso un Service Broker, fornendo i dettagli dei servizi/risorse che vuole esporre
    - - scarica il Proxy Object associato al servizio
        
        ad ogni servizio è associato uno specifico Java Service Proxy Object, che contiene tutto ciò che c'è da sapere sul servizio/risorsa
        
        supera limitazioni della creazione di stub/skeleton a runtime
      - fa richiesta di lookup al Service Broker
      - usa il Proxy Object per accedere a servizi/risorse, interagendo direttamente col Service Provider
      - non conosce nulla sui servizi/risorse scoperti
    - - naming server a cui il client invia richieste di lookup per accedere a risorse/servizi locali
      - possiede una tabella dei Service Attributes, con le descrizioni dei servizi (tipo/interfacce)
  - - - assegnazione risorse al client per un certo time interval
        
        client rinnova con un'altro lookup quando scade, se vuole
      - registrazione di servizi/risorse
        
        scartati dalla tabella del Service Broker quando scade
        
        si può anche farla fornendo al client un Proxy Object persistente, inviando aggiornamenti espliciti sullo stato della risorsa associata
        
        traffico di messaggi elevato
        
        non sempre una risorsa può segnalare la sua de-registrazione prima di non essere più disponibile
    - - scalabilità
        
        tramite organizzazione in comunità/federazioni delle risorse
        
        comunità diverse possono collegarsi fra di loro tramite servizio di lookup
      - ridondanza a livello di infrastruttura
      - fault-tolerance
      - affidabilità
- - - - trasmette periodicamente dei messaggi di advertising contenenti risorse/servizi con i rispettivi URL
      - riceve le richieste di lookup dagli UA
      - nodi che vogliono offrire si registrano presso il SA
    - - repository locale di servizi offferti in una località.
        
        elabora le query di discovery ricevute dagli UA
        
        caching dei messaggi di advertising
      - Incrementa le performance di SLP e coordina diversi SA
    - - scopre risorse/servizi lato client, facendo richieste in multicast a più Service Agent
      - intermediario per il client
        
        non sa nulla di protocolli e interfacce del SA
        
        fa una richiesta generica di lookup all'UA
- - - - richiesta tramite Address Resolution Protocol (ARP), per vedere se è già stato preso. Se sì, ne sceglie un altro random
  - - - chi riceve il msg, risponde in unicast con l'URL da cui scaricare DDF
    - - contiene l'URL da cui scaricare il Device Description File (DDF)
        
        DDF: file XML che descrive le risore/servizi offerti da un dispositivo. Include
        
        URL per la sottoscrizione agli eventi e la ricezione di notifiche
        
        URL per il Service Description File (SDF), più specifico del DDF e scaricato dinamicamente dal Control Point qualora ne volesse sapere di più o non conoscesse le interfacce del servizio
  - - - messaggi espressi in XML e formattati secondo standard GENA
        
        includono solo le variabili modificate per ragioni di ottimizzazione
      - quando cambia una variabile, tutti i CP abbonati vengono notificati
    - - variabile di stato da leggere/modificare
      - operazione da eseguire + parametri
    - - notifiche inviate/ricevute tramite HTTP su TCP/IP o multicast UDP
  - - - il bridge non sa distinguerle e non sa dove instradare i messaggi
      - SOLUZIONE: identifico un nodo tramite combo di IP+ID della località di cui fa parte
        
        bridge deve mantenere tabella di forwarding con IP e ID dei nodi