Perché non esiste un linguaggio orientato ai servizi?

Modificare:

Per evitare ulteriore confusione: Sto non parlando di servizi web e così via. Sto parlando di strutturare le applicazioni internamente, non di come comunicano i computer. Riguarda i linguaggi di programmazione, i compilatori e come viene esteso il paradigma della programmazione imperativa.

Originale:

Nel campo della programmazione imperativa, abbiamo visto due paradigmi negli ultimi 20 anni (o più): orientato agli oggetti (OO) e orientato ai servizi (SO) aka. basato su componenti (CB).

Entrambi i paradigmi estendono il paradigma della programmazione imperativa introducendo la propria nozione di moduli. OO li chiama oggetti (e classi) e consente loro di incapsulare insieme dati (campi) e procedure (metodi). SO, al contrario, separa i dati (record, bean, ...) dal codice (componenti, servizi).

Tuttavia, solo OO ha linguaggi di programmazione che supportano nativamente il suo paradigma: Smalltalk, C ++, Java e tutti gli altri compatibili con JVM, C # e tutti gli altri compatibili con .NET, Python ecc.

SO non ha una tale lingua madre. Esiste solo su linguaggi procedurali o linguaggi OO: COM / DCOM (binario, C, C ++), CORBA, EJB, Spring, Guice (tutto Java), ...

Questi framework SO soffrono chiaramente del supporto mancante dei loro concetti nella lingua madre.

• Iniziano a utilizzare le classi OO per rappresentare servizi e record. Questo porta a progetti in cui esiste una chiara distinzione tra classi che hanno solo metodi (servizi) e quelle che hanno solo campi (record). L'ereditarietà tra servizi o record viene quindi simulata per ereditarietà delle classi. Tecnicamente, non è tenuto così rigorosamente, ma in generale i programmatori sono invitati a fare in modo che le classi svolgano solo uno dei due ruoli.
• Usano linguaggi esterni aggiuntivi per rappresentare le parti mancanti: IDL, configurazioni XML, annotazioni nel codice Java o persino DSL incorporato come in Guice. Ciò è particolarmente necessario, ma non limitato a, poiché la composizione dei servizi non fa parte del codice del servizio stesso. In OO, gli oggetti creano altri oggetti, quindi non è necessario per tali strutture, ma per SO c'è perché i servizi non istanziano o configurano altri servizi.
• Stabiliscono un effetto di piattaforma interna sopra OO (EJB iniziale, CORBA) in cui il programmatore deve scrivere tutto il codice necessario per "guidare" SO. Le classi rappresentano solo una parte della natura di un servizio e molte classi devono essere scritte per formare un servizio insieme. Tutta quella piastra della caldaia è necessaria perché non esiste un compilatore SO che lo farebbe per il programmatore. Questo è proprio come alcune persone lo hanno fatto in C per OO quando non c'era C ++. Basta passare il record che contiene i dati dell'oggetto come primo parametro alla procedura che è il metodo. In un linguaggio OO questo parametro è implicito e il compilatore produce tutto il codice di cui abbiamo bisogno per le funzioni virtuali ecc. Per SO, questo è chiaramente mancante.
• Soprattutto i nuovi framework utilizzano ampiamente AOP o introspezione per aggiungere le parti mancanti in un linguaggio OO. Questo non porta l'espressività del linguaggio necessaria ma evita il codice della piattaforma della caldaia descritto nel punto precedente.
• Alcuni framework utilizzano la generazione del codice per produrre il codice della piastra della caldaia. I file di configurazione in XML o le annotazioni nel codice OO sono la fonte di informazioni per questo.

Non tutti i fenomeni che ho menzionato sopra possono essere attribuiti alla SO, ma spero che mostri chiaramente che c'è bisogno di un linguaggio SO. Poiché questo paradigma è così popolare: perché non ce n'è uno? O forse ce ne sono alcuni accademici ma almeno l'industria non ne usa uno.

Perché <5% del codice sta effettivamente definendo un servizio, e direi una quantità di tempo sostanzialmente inferiore. Una volta definita l'interfaccia, è in gran parte fatta. Il resto del tempo è trascorso in OO (o alternative) per far funzionare le cose .

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

[modifica per chiarire i PO che è il layout interno dell'applicazione, non il limite dell'applicazione]:

L'obiettivo principale di disporre di un tale layout di servizio è di avere sottili punti di contatto tra i servizi. La mia ragione originale è ancora valida (imo) e aggiungo a questa risposta il fatto che relativamente pochi problemi si adattano bene a una struttura di applicazione 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. 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 tra processi e persino tra macchine integrata nel suo framework di base che consente di inviare messaggi a un processo remoto come se fosse un processo locale .

Altre lingue come Scala, Clojure e F # forniscono anche 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 è necessaria una nuova lingua, in quanto il problema è avere già troppe lingue , il che comporta costi di interoperabilità elevati.

Tuttavia, è stato introdotto un tipo di linguaggio, il linguaggio di definizione del servizio Web. WSDL è il meta linguaggio di SOA (e ce n'è un altro abbandonato per REST chiamato WADL)

Girerò la domanda e chiederò "come sarebbe una lingua SO?"

Come verrebbero scritti quei contratti tra i moduli?
Come verrebbero eseguite le meccaniche fondamentali dell'operazione?

Orientato ai servizi è una proprietà dell'applicazione, non necessariamente il linguaggio utilizzato. 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 dalla macchina.

BPEL è un possibile esempio di linguaggio SO, ma è di livello molto elevato e si basa sui moduli disponibili per essere utilizzati. Questi moduli sono a loro volta scritti in linguaggi non BPEL in modo da poter eseguire il lavoro (ovvero tradotto in linguaggio macchina).

Grande Q e mi ha dato un buon momento di riflessione.

Offrirò 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 tra l'implementazione dei servizi e la loro composizione. Ci sono un paio di soluzioni accademiche di cui ho sentito parlare all'università (nessun riferimento, scusate) ma non sembra entrare nel settore. Ma lo considero una scusa, non una vera ragione. Anche i linguaggi e i compilatori di OO sono piuttosto difficili da implementare, ma ci sono soluzioni sul mercato da molto tempo.

• I programmatori usano i linguaggi 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à va alla classe in cui si trovano i dati su cui lavorano. Codice e dati sono accoppiati nello stesso modulo. Non è uno stile OO avere classi separate che funzionano sui dati di altre classi. Questo è l'approccio per strumenti e materiali (WAM) di Züllighofen che corrisponde al paradigma SO.

  2. Gli oggetti creano altri oggetti e formano reti di oggetti. Possono creare gerarchie o qualunque relazione complessa. I servizi formano sempre reti piatte 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 di dipendenza 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 localizzatori di servizi.

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

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

• OO e SO sono utili per diversi tipi di problemi. Quindi in tutte le applicazioni è allettante usare il paradigma 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 SO ma non devono necessariamente essere scritti in un linguaggio SO. 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.