Mengapa tidak ada bahasa yang berorientasi layanan?

Edit:

Untuk menghindari kebingungan lebih lanjut: Saya tidak berbicara tentang layanan web dan semacamnya. Saya berbicara tentang penataan aplikasi secara internal, ini bukan tentang bagaimana komputer berkomunikasi. Ini tentang bahasa pemrograman, kompiler dan bagaimana paradigma pemrograman imperatif diperluas.

Asli:

Di bidang pemrograman imperatif, kami melihat dua paradigma dalam 20 tahun terakhir (atau lebih): berorientasi objek (OO), dan berorientasi layanan (SO) alias. berbasis komponen (CB).

Kedua paradigma memperluas paradigma pemrograman imperatif dengan memperkenalkan gagasan mereka sendiri tentang modul. OO memanggil mereka objek (dan kelas) dan memungkinkan mereka merangkum data (bidang) dan prosedur (metode) secara bersamaan. JADI, sebaliknya, memisahkan data (catatan, kacang, ...) dari kode (komponen, layanan).

Namun, hanya OO yang memiliki bahasa pemrograman yang mendukung paradigma tersebut: Smalltalk, C ++, Java dan semua yang kompatibel dengan JVM lainnya, C # dan semua yang lainnya .NET-compatibles, Python dll.

SO tidak memiliki bahasa ibu seperti itu. Ini hanya muncul di atas bahasa prosedural atau bahasa OO: COM / DCOM (biner, C, C ++), CORBA, EJB, Spring, Guice (semua Java), ...

Kerangka kerja SO ini jelas menderita dari dukungan bahasa asli yang hilang dari konsep mereka.

• Mereka mulai menggunakan kelas OO untuk mewakili layanan dan catatan. Ini mengarah ke desain di mana ada perbedaan yang jelas antara kelas yang hanya memiliki metode (layanan) dan yang memiliki bidang saja (catatan). Warisan antara layanan atau catatan kemudian disimulasikan oleh pewarisan kelas. Secara teknis, ini tidak dijaga dengan ketat tetapi pada umumnya programmer disarankan untuk membuat kelas untuk memainkan hanya satu dari dua peran.
• Mereka menggunakan bahasa eksternal tambahan untuk mewakili bagian yang hilang: IDL, konfigurasi XML, Anotasi dalam kode Java, atau bahkan DSL yang disematkan seperti di Guice. Ini sangat diperlukan, tetapi tidak terbatas pada, karena komposisi layanan bukan bagian dari kode layanan itu sendiri. Dalam OO, objek membuat objek lain sehingga tidak perlu untuk fasilitas seperti itu tetapi untuk SO ada karena layanan tidak instantiate atau mengkonfigurasi layanan lain.
• Mereka membangun efek platform dalam di atas OO (EJB awal, CORBA) di mana programmer harus menulis semua kode yang diperlukan untuk "mendorong" SO. Kelas hanya mewakili sebagian dari sifat layanan dan banyak kelas harus ditulis untuk membentuk layanan bersama. Semua pelat ketel itu diperlukan karena tidak ada SO kompiler yang akan melakukannya untuk programmer. Ini seperti beberapa orang melakukannya dalam C untuk OO ketika tidak ada C ++. Anda hanya meneruskan catatan yang menyimpan data objek sebagai parameter pertama ke prosedur yang merupakan metode. Dalam bahasa OO parameter ini implisit dan kompiler menghasilkan semua kode yang kita butuhkan untuk fungsi virtual dll. Untuk SO, ini jelas hilang.
• Terutama kerangka kerja yang lebih baru secara ekstensif menggunakan AOP atau introspeksi untuk menambahkan bagian yang hilang ke bahasa OO. Ini tidak membawa ekspresi bahasa yang diperlukan tetapi menghindari kode platform boiler yang dijelaskan pada poin sebelumnya.
• Beberapa kerangka kerja menggunakan pembuatan kode untuk menghasilkan kode pelat ketel. File konfigurasi dalam XML atau anotasi dalam kode OO adalah sumber informasi untuk ini.

Tidak semua fenomena yang saya sebutkan di atas dapat dikaitkan dengan SO tetapi saya harap itu jelas menunjukkan bahwa ada kebutuhan untuk bahasa SO. Karena paradigma ini sangat populer: mengapa tidak ada? Atau mungkin ada beberapa yang akademis tetapi setidaknya industri tidak menggunakannya.

Karena <5% kode sebenarnya mendefinisikan layanan, dan saya berpendapat jumlah waktu yang jauh lebih sedikit. Setelah antarmuka didefinisikan, sebagian besar dilakukan. Sisa waktu dihabiskan di OO (atau alternatif) membuat semuanya berfungsi .

Sederhananya, itu bukan kemenangan besar untuk membuat bahasa khusus untuk sepotong kecil masalah. Jika ada, memiliki dua bahasa (satu untuk layanan dan satu untuk implementasi / konsumsi) hanya meminta tambahan kompleksitas integrasi.

[edit untuk klarifikasi OPs bahwa itu adalah tata letak aplikasi internal, bukan batas aplikasi]:

Tujuan utama memiliki tata letak layanan tersebut adalah memiliki titik kontak yang tipis di antara layanan. Alasan asli saya masih memegang (imo) dan menambah jawaban itu fakta bahwa relatif sedikit masalah cocok dengan diri mereka sendiri terhadap struktur aplikasi internal yang berbasis layanan. Jadi Anda tidak hanya menangani sebagian kecil dari masalah, tetapi secara keseluruhan persentase masalah yang lebih rendah.

Bahasa fungsional sangat berorientasi layanan pada intinya. Alih-alih membuat objek dan memanggil fungsi pada mereka, Anda membuat fungsi dan menyampaikan pesan kepada mereka. Erlang adalah contoh utama dari teknik ini karena bahkan di luar aspek fungsional dari bahasa itu memang memiliki komunikasi antar-proses dan bahkan antar-mesin yang dibangun ke dalam kerangka intinya memungkinkan Anda untuk mengirim pesan ke proses jarak jauh seolah-olah itu adalah proses lokal .

Bahasa lain seperti Scala, Clojure, dan F # juga menyediakan semantik "berorientasi layanan". Masalahnya bukan bahwa mereka tidak ada, itu karena masyarakat umum takut pada mereka sehingga mereka tidak sepopuler itu.

Orientasi Layanan adalah / adalah jawaban arsitektur untuk masalah integrasi. Integrasi idealnya adalah solusi menyeluruh yang sesuai dengan bahasa, produk, perangkat, sumber daya apa pun yang ada menjadi gambaran yang lebih besar.

Tidak perlu untuk beberapa bahasa baru, karena masalahnya adalah tentang memiliki terlalu banyak bahasa , yang menyebabkan biaya interoperabilitas yang tinggi.

Namun, ada satu jenis bahasa yang diperkenalkan, bahasa definisi layanan web. WSDL adalah bahasa meta SOA (dan ada satu lagi yang ditinggalkan untuk REST bernama WADL)

Saya akan membalikkan pertanyaan dan bertanya "seperti apa bahasa SO?"

Bagaimana kontrak antar modul tersebut ditulis?
Bagaimana mekanisme dasar operasi dijalankan?

Berorientasi layanan adalah properti aplikasi, belum tentu bahasa yang digunakan. Layanan adalah konstruksi yang bergantung pada suatu fungsi. Fungsi ini adalah konstruksi yang bergantung pada mekanisme bahasa pemrograman untuk menerjemahkan operasi menjadi instruksi yang dapat dieksekusi mesin.

BPEL adalah contoh yang mungkin dari bahasa SO, tetapi tingkatannya sangat tinggi dan bergantung pada modul yang tersedia untuk digunakan. Modul-modul tersebut pada gilirannya ditulis dalam bahasa non-BPEL sehingga pekerjaan dapat dilakukan (alias diterjemahkan ke dalam bahasa mesin).

Q hebat dan memberi saya refleksi momen yang baik.

Saya akan menawarkan jawaban untuk pertanyaan saya sendiri untuk melihat berapa banyak orang yang setuju dan tidak setuju.

Beberapa kemungkinan:

• Tampaknya sulit untuk membangun bahasa SO. Sebagian besar karena pemisahan implementasi layanan dan komposisinya. Ada beberapa solusi akademik yang saya dengar di universitas (tidak ada referensi, maaf) tetapi tampaknya tidak berhasil masuk ke dalam industri. Tapi saya menganggap ini sebagai alasan, bukan alasan sebenarnya. Bahasa dan kompiler OO juga cukup sulit untuk diimplementasikan, namun ada solusi di pasar untuk waktu yang lama.

• Pemrogram menggunakan bahasa OO untuk SO karena mereka tidak mengerti OO dan menggunakannya dengan cara yang salah. Saya katakan salah karena ada dua konsep dasar dalam OO yang bertentangan dengan SO:

  1. Fungsionalitas pergi ke kelas tempat data itu berada di mana mereka bekerja. Kode dan data digabungkan bersama dalam modul yang sama. Bukan gaya OO untuk memiliki kelas terpisah yang bekerja pada data kelas lain. Itu pendekatan Alat-dan-bahan Züllighofen (WAM) yang cocok dengan paradigma SO.

  2. Objek membuat objek lain dan membentuk jaringan objek. Mereka dapat membuat hierarki atau hubungan rumit apa pun. Layanan selalu membentuk jaringan datar yang terdiri dari luar. Layanan biasanya hanya memiliki satu instance (Singleton) sedangkan objek akan dipakai sesering entitas yang mereka wakili ada. Rekaman dalam SO tidak terhubung dalam jaringan.

• Beberapa fitur OO terlihat mirip dengan SO, atau dapat digunakan untuk memfasilitasi apa yang dibutuhkan untuk SO sehingga berguna untuk menggunakan bahasa OO.

  1. Prinsip dependensi-inversi dalam OO mirip dengan cara layanan disusun secara eksternal.

  2. Objek singleton seperti layanan, objek pabrik seperti pencari layanan.

  3. OO juga memiliki antarmuka yang mirip dengan antarmuka layanan.

  4. Warisan kelas dapat serupa (sama?) Dengan warisan layanan dan catatan.

• OO dan SO berguna untuk berbagai jenis masalah. Jadi di setiap aplikasi tergoda untuk menggunakan paradigma di sini atau di sana. Memiliki bahasa yang terpisah akan menghambat perpindahan keduanya dalam program yang sama.

• SO tidak hanya paradigma pemrograman tetapi juga perilaku program: layanan web, komponen sistem operasi dll. SO tetapi tidak perlu ditulis dalam bahasa SO. "Komponen biner" semacam ini sangat alami dan sukses. Tapi itu hal yang berbeda: ini adalah bagaimana program berkomunikasi satu sama lain, bukan bagaimana program berkomunikasi secara internal. Saya kira orang cukup sering mencampuradukkannya.