Web service, standard per l'affidabilità

Un gruppo di giganti del settore sviluppa una nuova specifica che, se approvata a standard, potrà essere impiegata da chiunque per migliorare l'affidabilità dello scambio di dati tra applicazioni web

Roma - Alcuni grandi player del settore informatico hanno sottoposto al gruppo di standardizzazione OASIS una specifica, chiamata WS-ReliableMessaging (WS-RM), studiata per migliorare l'affidabilità delle transazioni dati fra web server.

La specifica, promossa fra gli altri da IBM, BEA Systems, Microsoft e Tibco Software, potrebbe giocare un ruolo cruciale nella diffusione dei web service all'interno di settori come quello finanziario e sanitario. Il suo scopo è infatti quello di assicurare che le informazioni scambiate tra web server arrivino alla giusta destinazione senza subire alterazioni.

"Questa specifica consente alle aziende di essere sicure che un messaggio sia stato consegnato almeno una volta, solo una volta e nell'ordine specifico", ha spiegato Diane Jordan, program manager for emerging Internet standards di IBM. "Senza un sistema capace di garantire l'ordine in cui arrivano i messaggi, diventa difficile per le applicazioni sapere se tutti gli oggetti sono arrivati a destinazione e nessuno sia stato duplicato".
Se ad esempio un client perde temporaneamente la connessione durante il corso di una transazione, WS-RM fa sì che il messaggio venga ritrasmesso una sola volta e in base alla priorità a lui assegnata.

Le applicazioni che utilizzeranno questa specifica potranno scegliere un determinato livello di qualità del servizio (quality of service, QoS), e saranno in grado di appoggiarsi a questo protocollo per verificare lo stato dell'invio e della ricezione.

Se l'OASIS approverà il WS-RM, e lo includerà nella famiglia di standard per i web service nota come WS*, la specifica potrà essere utilizzata liberamente da ogni azienda senza il pagamento di alcuna royalty.
TAG: mondo
11 Commenti alla Notizia Web service, standard per l'affidabilità
Ordina

  • Indigo lo userà? Sarebbe molto comodo, anche
    se nella beta che ho io ancora non ce ne sono
    tracce.
    non+autenticato


  • - Scritto da: Anonimo
    >
    > Indigo lo userà? Sarebbe molto comodo, anche
    > se nella beta che ho io ancora non ce ne sono
    > tracce.

    http://www.c-sharpcorner.com/Code/2004/May/Reliabl...
    non+autenticato
  • E' impossibile essere sicuri che un messaggio sia stato consegnato una e una sola volta, qualunque sia il protocollo utilizzato.

    E' un problema classico.
    non+autenticato

  • - Scritto da: Anonimo
    > E' impossibile essere sicuri che un messaggio sia
    > stato consegnato una e una sola volta, qualunque
    > sia il protocollo utilizzato.
    >
    > E' un problema classico.

    Non è impossibile in senso teorico. Noi siamo abituati a ragionare in termini di TCP/IP che rappresenta una pila di protocolli molto semplici, che devolvono gran parte del lavoro ai terminali in gioco, ragion per cui tutta una serie di problemi relativi ad es. al trasferimento affidabile devono essere risolti su pile protocollari costruite SOPRA TCP/IP. I Web Services riguardano proprio questo.
    non+autenticato

  • - Scritto da: Anonimo
    > E' impossibile essere sicuri che un messaggio sia
    > stato consegnato una e una sola volta, qualunque
    > sia il protocollo utilizzato.
    >
    > E' un problema classico.

    E' impossibile senza la collaborazione di tutti e due, questo dice la teoria. Ossia chi spedisce non può garantire "once & only once" se il ricevente non collabora.
    In realtà è abbastanza banale implementarlo, basta che per il time to live del messaggio il ricevente mantenga un identificativo dei msg ricevuti e scarti i duplicati ricevuti (sliding window)
    Qualsiasi middleware di messaggistica lo fa out-of-the-box e anche TCP lo fa (a dun livello molto più basso)
    Ora si parla di estendere la cosa ai web-services (è da un po' che si parla di ReliableMessaging)
    non+autenticato
  • - Scritto da: Anonimo
    > (è da un po' che si parla di ReliableMessaging)

    Oh penso che si possa scrivere staccato (se non addirittura in ItalianoOcchiolino )
    non+autenticato
  • Il protocollo credo si chiami WS-ReliableMessage e sia una proposta congiunta IBM-Microsoft-BEA per la standardizzazione.
    non+autenticato

  • - Scritto da: Anonimo
    > - Scritto da: Anonimo
    > > (è da un po' che si parla di ReliableMessaging)
    >
    > Oh penso che si possa scrivere staccato (se non
    > addirittura in ItalianoOcchiolino )

    ReliableMessaging è il nome della specifica
    non+autenticato
  • ...così come è scritto l'articolo sembri chissà cosa.

    In realtà la specifica è praticamente inutile in tutti i contesti in cui i servizi utilizzano protocolli di trasposto sopra TCP (ossia il 99,9% dei casi) che già svolge questa funzione.

    Solo una semplice estensione per portare web service affidabili nell'altro 0,1% delle soluzioni.

    bye brain
    non+autenticato

  • - Scritto da: Anonimo
    > In realtà la specifica è praticamente inutile in
    > tutti i contesti in cui i servizi utilizzano
    > protocolli di trasposto sopra TCP (ossia il 99,9%
    > dei casi) che già svolge questa funzione.
    >

    TCP fornisce soltanto un servizio con connessione punto-punto. Le tecnologie basate su Web-Services riguardano l'interoperabilità tra partner differenti (in termini di piattaforme hardware/software) e quindi devono fornire "qualcosa in più" del semplice TCP. La famiglia di protocolli della serie WS-* fornisce un numero elevato di funzionalità che discuterne qui sarebbe troppo oneroso e riguardano: la politica dei trasferimenti, la sicurezza, le transazioni atomiche, l'indirizzamento, il trasferimento affidabile... questi protocolli possono essere combinati tra loro (come dei mattoni) per fornire funzionalità inimmaginabili negli strati inferiori della pila protocollare. Inoltre i messaggi che vengono scambiati tra WS non sono vincolati ad uno specifico protocollo di trasporto. Molto utilizzato è http (che funziona su tcp), ma un generico messaggio può attraversare anche tratti su protocolli differenti. Si capisce come sia fondamentale un protocollo affidabile che lavori al di sopra (ad es.) di http e che riesca a gestire in maniera ESPLICITA i messaggi SOAP (ricordiamo che tcp riguarda i segmenti e non ha alcuna conoscenza del tipo di messaggi che vi viaggiano sopra).
    non+autenticato
  • bla bla!
    venendo all'osso! ma insomma dove e come usi i web services senza tcp?

    Casi di uso prego non chiacchere!
    Altrimenti siamo alle solite (complicazione del semplice attraverso l'inutile!)
    Bye
    non+autenticato