Perché non esiste un linguaggio orientato ai servizi?

Perché < il 5% del codice sta effettivamente definendo un servizio, e direi una quantità di tempo notevolmente inferiore. Una volta definita l'interfaccia, è in gran parte fatta. Il resto del tempo viene speso in OO (o in alternative) rendendo le cose funzionanti .

In parole semplici, non è una grande vittoria creare un linguaggio specializzato per quella piccola parte del problema. Se mai, avere due lingue (una per il servizio e una per l'implementazione / il consumo) richiede solo maggiore complessità di integrazione.

[modifica per i chiarimenti OP che è il layout dell'applicazione interna, non il limite dell'applicazione]:

L'obiettivo principale di avere un tale layout di servizio è di avere punti di contatto sottili tra i servizi. La mia ragione originale rimane (imo) e aggiungo a questa risposta il fatto che relativamente pochi problemi si adattano bene a una struttura applicativa interna basata sul servizio. Quindi non solo stai affrontando una piccola parte del problema, ma una percentuale inferiore di problemi in generale.

I linguaggi funzionali sono molto orientati al servizio nel loro nucleo. Invece di creare oggetti e chiamare funzioni su di essi, si creano funzioni e si passano loro messaggi. Erlang è un ottimo esempio di questa tecnica perché, anche al di là degli aspetti funzionali del linguaggio, ha una comunicazione inter-processo e persino inter-macchina integrata nel suo core framework che consente di inviare messaggi a un processo remoto come se fosse un processo locale .

Anche altri linguaggi come Scala, Clojure e F # offrono una semantica "orientata al servizio". Il problema non è che non esistono, è che la popolazione generale ha paura di loro e quindi non sono così popolari.

L'orientamento al servizio era / è una risposta architettonica ai problemi di integrazione. L'integrazione è idealmente una soluzione all-inclusive che si adatta a qualsiasi lingua, prodotto, dispositivo, risorsa esistente in un quadro più ampio.

Non c'è bisogno di qualche nuova lingua, dato che il molto problema riguarda l'uso di troppe lingue , il che causa un costo elevato di interoperabilità.

Tuttavia, è stato introdotto un tipo di linguaggio, il linguaggio di definizione del servizio Web. WSDL è meta lingua di S.O.A. (e c'è un altro abbandonato per REST chiamato WADL)

Girerò la domanda e chiedo "come sarebbe un linguaggio SO?"

Come vengono scritti quei contratti tra i moduli?
Come si eseguirà la meccanica fondamentale dell'operazione?

I servizi orientati sono una proprietà dell'applicazione, non necessariamente la lingua utilizzata. Il servizio è un costrutto che si basa su una funzione. La funzione è un costrutto che si basa sulla meccanica di un linguaggio di programmazione per tradurre l'operazione in istruzioni eseguibili della macchina.

BPEL è un possibile esempio di un linguaggio SO, ma è di altissimo livello e si basa su moduli disponibili per l'utilizzo. Questi moduli sono a loro volta scritti in lingue non BPEL, quindi è possibile eseguire il lavoro (ovvero tradotti nella lingua della macchina).

Grande Q e mi ha dato una buona riflessione.

Offro una risposta alla mia domanda per vedere quante persone sono d'accordo e in disaccordo.

Alcune possibilità:

• Sembra difficile costruire un linguaggio SO. Principalmente a causa della separazione dell'attuazione dei servizi e della loro composizione. Ci sono un paio di soluzioni accademiche che ho sentito all'università (nessun riferimento, scusate) ma non sembra farlo nel settore. Ma lo considero una scusa, non una vera ragione. Anche i linguaggi OO e i compilatori sono piuttosto difficili da implementare, tuttavia esistono soluzioni sul mercato da molto tempo.

• I programmatori usano le lingue OO per SO perché non capiscono OO e lo usano in modo sbagliato. Dico male perché ci sono due concetti fondamentali in OO che contraddicono SO:

  1. La funzionalità passa alla classe in cui si trovano i dati su cui lavorano. Codice e dati sono accoppiati nello stesso modulo. Non è in stile OO avere classi separate che funzionano sui dati di altre classi. Questo è l'approccio Tools-and-materials di Züllighofen (WAM) che corrisponde al paradigma SO.

  2. Gli oggetti creano altri oggetti e formano reti di oggetti. Possono creare gerarchie o qualsiasi relazione complessa. I servizi formano sempre reti piane composte dall'esterno. I servizi di solito hanno solo un'istanza (Singleton) mentre gli oggetti vengono istanziati ogni volta che esiste l'entità che rappresentano. I record in SO non sono collegati in rete.

• Alcune funzionalità di OO sembrano simili a SO, o possono essere utilizzate per facilitare ciò che è necessario per SO, quindi è utile usare un linguaggio OO.

  1. Il principio di inversione delle dipendenze in OO è simile al modo in cui i servizi sono composti esternamente.

  2. Gli oggetti Singleton sono come servizi, le fabbriche di oggetti sono come locatori di servizi.

  3. OO ha anche interfacce che sono simili alle interfacce di servizio.

  4. L'ereditarietà delle classi può essere simile (la stessa?) all'eredità di servizi e record.

• OO e SO sono utili per diversi tipi di problemi. Quindi in ogni applicazione si è tentati di utilizzare entrambi i paradigmi qui o là. Avere una lingua separata ostacolerebbe il passaggio tra i due all'interno dello stesso programma.

• SO non è solo un paradigma di programmazione ma anche un comportamento del programma: i servizi Web, i componenti del sistema operativo ecc. sono COSI ma non è necessario che siano scritti in un linguaggio SO necessariamente. Questo tipo di "componenti binari" è molto naturale e di successo. Ma è una cosa diversa: è come i programmi comunicano tra loro, non come il programma comunica internamente. Immagino che le persone lo mescolino abbastanza spesso.