Si sente spesso dire che con i Web service si è “reinventata” la ruota. Questo perché il paradigma del computing distribuito (in opposizione a quello centralizzato) è già utilizzato da tempo, incarnato all’interno di Corba (Common object request broker …
Si sente spesso dire che con i Web service si è “reinventata”
la ruota. Questo perché il paradigma del computing distribuito (in opposizione
a quello centralizzato) è già utilizzato da tempo, incarnato all’interno
di Corba (Common object request broker architecture), J2Ee (Java 2 enterprise
edition) o Dcom (Distributed com). Tuttavia, questi approcci tradizionali sfruttano
la creazione di una fitta rete di relazioni strettissime tra i singoli componenti.
Cosa questa, che li rende poco flessibili e ne impedisce il riutilizzo in contesti
differenti, a causa di codifiche dei dati estremamente rigide, che pongono non
pochi problemi nelle interazioni tra applicazioni diverse. Le Soa, invece, incoraggiano
la creazione di applicazioni altamente flessibili e facilmente riutilizzabili,
separando l’implementazione del servizio dalle interfacce applicative.
Questo significa, in sostanza, che tali architetture permettono una scalabilità
virtualmente infinita dei servizi e dei partecipanti. Ma significa, altresì,
che potranno essere attivate invocazioni dei singoli servizi sia sincrone (ovvero
contestuali) che asincrone. Infine, questo si traduce soprattutto nell’implementazione
di “legami deboli” tra le applicazioni, in modo che qualsiasi cambiamento
intervenga sull’implementazione del servizio, avvenga con la garanzia
dell’isolamento, senza cioè che questo si rifletta sugli altri
servizi dell’architettura.
