Neden hizmet odaklı bir dil yok?

Düzenle:

Ayrıca Karışıklığı önlemek için: Ben am değil web hizmetleri ve bu tür bahsediyor. Uygulamaları dahili olarak yapılandırmaktan bahsediyorum, bu bilgisayarların nasıl iletişim kurduğundan değil. Programlama dilleri, derleyiciler ve zorunlu programlama paradigmasının nasıl genişletildiği ile ilgilidir.

Orijinal:

Zorunlu programlama alanında, son 20 yılda (veya daha fazla) iki paradigma gördük: nesne yönelimli (OO) ve hizmet yönelimli (SO) aka. bileşen tabanlı (CB).

Her iki paradigma da kendi modül kavramlarını sunarak zorunlu programlama paradigmasını genişletir. OO onlara nesneleri (ve sınıfları) çağırır ve hem verileri (alanları) hem de prosedürleri (yöntemleri) birlikte kapsüllemelerine izin verir. SO, aksine, verileri (kayıtlar, fasulye, ...) koddan (bileşenler, hizmetler) ayırır.

Bununla birlikte, yalnızca OO'nun paradigmasını yerel olarak destekleyen programlama dilleri vardır: Smalltalk, C ++, Java ve diğer tüm JVM uyumlu, C # ve diğer tüm .NET uyumlu, Python vb.

SO'nun böyle bir ana dili yoktur. Sadece yordamsal dillerin veya OO dillerinin üzerinde ortaya çıkar: COM / DCOM (ikili, C, C ++), CORBA, EJB, Bahar, Guice (tüm Java), ...

Bu SO çerçeveleri, kavramlarının eksik ana dil desteğinden açıkça muzdariptir.

• Hizmet ve kayıtları temsil etmek için OO sınıflarını kullanmaya başlarlar. Bu, yalnızca yöntemi olan (hizmetler) ve yalnızca alanları olan (kayıtlar) sınıflar arasında açık bir ayrımın olduğu tasarımlara yol açar. Hizmetler veya kayıtlar arasında kalıtım, daha sonra sınıfların kalıtımı ile simüle edilir. Teknik olarak, kesinlikle katı tutulmaz, ancak genel olarak programcılar, iki rolden sadece birini oynamak için sınıflar yapmak için tavsiye edilir.
• Eksik kısımları temsil etmek için ek harici diller kullanırlar: IDL'ler, XML yapılandırmaları, Java kodundaki ek açıklamalar ve hatta Guice'deki gibi gömülü DSL. Bu özellikle gereklidir, ancak bunlarla sınırlı değildir, çünkü hizmetlerin bileşimi hizmet kodunun kendisinin bir parçası değildir. OO'da, nesneler başka nesneler oluşturur, böylece bu tür tesislere gerek kalmaz, ancak SO için hizmetler diğer hizmetleri başlatmaz veya yapılandırmaz.
• Programcının SO'yu "sürmek" için gerekli olan tüm kodları yazması gereken OO (erken EJB, CORBA) üstünde bir iç platform etkisi oluştururlar. Sınıflar bir hizmetin doğasının sadece bir bölümünü temsil eder ve birlikte bir hizmet oluşturmak için birçok sınıf yazılmalıdır. Tüm bu kazan plakası gereklidir, çünkü programcı için yapacak bir SO derleyicisi yoktur. Bu, bazı insanların C ++ olmadığında OO için C'de yaptığı gibi. Sadece nesnenin verilerini ilk parametre olarak tutan kaydı yöntem olan prosedüre geçirirsiniz. OO dilinde bu parametre örtüktür ve derleyici sanal işlevler vb. İçin ihtiyaç duyduğumuz tüm kodu üretir. SO için bu açıkça eksiktir.
• Özellikle daha yeni çerçeveler, eksik parçaları bir OO diline eklemek için AOP veya içgözlemi kullanır. Bu, gerekli dil ifadesini getirmez, ancak önceki noktada açıklanan kazan platform kodundan kaçınır.
• Bazı çerçeveler, kazan plakası kodunu üretmek için kod üretmeyi kullanır. XML'deki yapılandırma dosyaları veya OO kodundaki ek açıklamalar bunun için bilgi kaynağıdır.

Yukarıda bahsettiğim tüm fenomenler SO'ya atfedilemez, ancak umarım bir SO diline ihtiyaç olduğunu açıkça gösterir. Bu paradigma çok popüler olduğundan: neden bir tane yok? Ya da belki bazı akademik olanlar da vardır ama en azından endüstri bir tane kullanmaz.

Çünkü kodun <% 5'i aslında bir hizmeti tanımlıyor ve ben daha az zaman harcıyorum. Arayüz tanımlandıktan sonra büyük ölçüde yapılır. Zamanın geri kalanı OO'da (veya alternatiflerde) işlerin işe yaraması için harcanır .

Basitçe söylemek gerekirse, sorunun bu küçük dilimi için özel bir dil yapmak büyük bir kazanç değildir. Eğer bir şey varsa, iki dilin olması (biri hizmet için ve diğeri uygulama / tüketim için) ek entegrasyon karmaşıklığı ister.

[OP'lerin uygulama sınırına değil dahili uygulama düzenine ilişkin açıklaması için düzenleyin]:

Böyle bir servis düzenine sahip olmanın temel amacı, servisler arasında ince temas noktalarına sahip olmaktır. Benim asıl nedenim hala devam ediyor (imo) ve bu cevaba, nispeten az sayıda sorunun kendilerine hizmet tabanlı bir iç uygulama yapısına uygun olduğu gerçeğini ekliyor. Yani sadece problemin küçük bir dilimini değil, genel olarak daha düşük bir sorun yüzdesini ele alıyorsunuz.

İşlevsel diller özünde çok hizmet odaklıdır. Nesneler oluşturmak ve üzerlerinde işlevler çağırmak yerine, işlevler oluşturur ve bunlara mesajlar iletirsiniz. Erlang bu tekniğin en iyi örneğidir, çünkü dilin işlevsel yönlerinin ötesinde bile, çekirdek çerçevesine yerleşik süreçler arası ve hatta makineler arası iletişim yerel bir süreçmiş gibi uzak bir sürece mesaj göndermenizi sağlar .

Scala, Clojure ve F # gibi diğer diller de "hizmet odaklı" anlambilim sağlar. Sorun var olmamaları değil, genel nüfusun onlardan korkması ve bu yüzden popüler olmamaları.

Hizmet Odaklılık, entegrasyon sorunlarına mimari bir cevaptı. Entegrasyon ideal olarak mevcut herhangi bir dili, ürünü, cihazı ve kaynağı daha büyük bir resme sığdıran her şey dahil bir çözümdür.

Yeni bir dile ihtiyaç yoktur, çünkü asıl sorun zaten çok fazla dile sahip olmaktır , bu da birlikte çalışabilirlik maliyetinin yüksek olmasına neden olmaktadır.

Ancak, bir tür dil tanıtıldı, web hizmeti tanımlama dili. WSDL, SOA'nın meta dilidir (ve RAD için WADL adında terk edilmiş başka bir dil vardır)

Soruyu tersine çevireceğim ve "SO dili neye benzeyecek?" Diye soracağım.

Modüller arasındaki sözleşmeler nasıl yazılır?
Operasyonun temel mekaniği nasıl yürütülür?

Odaklı hizmetler, kullanılan dil değil, uygulamanın özelliğidir. Hizmet, bir işleve dayanan bir yapıdır. İşlev, işlemi makinenin yürütülebilir yönergelerine çevirmek için bir programlama dilinin mekaniğine dayanan bir yapıdır.

BPEL, SO dilinin olası bir örneğidir, ancak çok üst düzeydir ve kullanabileceği modüllere dayanır. Bu modüller sırayla BPEL dışı dillerde yazılır, böylece çalışma yapılabilir (makine diline çevrilir).

Büyük Q ve bana iyi bir anın yansımasını verdi.

Kaç kişinin katılıp katılmadığını görmek için kendi soruma bir cevap vereceğim.

Bazı olasılıklar:

• Bir SO dili oluşturmak zor görünüyor. Çoğunlukla hizmetlerin uygulanmasının ve bileşimlerinin ayrılması nedeniyle. Üniversitede duyduğum birkaç akademik çözüm var (referans yok, özür dilerim), ancak endüstride bunu yapmıyor gibi görünüyor. Ama bunu gerçek bir neden değil, bir bahane olarak görüyorum. OO dillerinin ve derleyicilerin uygulanması da oldukça zordur, ancak piyasada uzun zamandır çözümler vardır.

• Programcılar SO için OO dillerini kullanır, çünkü OO'yu anlamıyor ve yanlış bir şekilde kullanıyorlar. Yanlış söylüyorum çünkü OO'da SO ile çelişen iki temel kavram var:

  1. İşlevsellik, üzerinde çalıştıkları verinin bulunduğu sınıfa gider. Kod ve veriler aynı modülde birleştirilir. Diğer sınıfların verileri üzerinde çalışan ayrı sınıflara sahip olmak OO stili değildir. Bu, Züllighofen'in SO paradigmasına uyan Araç-gereç yaklaşımıdır (WAM).

  2. Nesneler başka nesneler oluşturur ve nesnelerin ağlarını oluşturur. Hiyerarşiler veya karmaşık ilişkiler kurabilirler. Hizmetler her zaman dışarıdan oluşan düz ağlar oluşturur. Hizmetlerin genellikle yalnızca bir örneği (Singleton) bulunurken, nesneler temsil ettikleri varlık olduğu kadar somutlaştırılır. SO'daki kayıtlar ağlara bağlı değildir.

• OO'nun bazı özellikleri SO'ya benzer veya SO için gerekenleri kolaylaştırmak için kullanılabilir, böylece bir OO dili kullanmak kullanışlı olur.

  1. OO'daki bağımlılık-ters çevirme ilkesi, hizmetlerin harici olarak oluşturulma şekline benzer.

  2. Singleton nesneleri hizmetler gibidir, nesne fabrikaları servis bulma araçları gibidir.

  3. OO ayrıca servis arayüzlerine benzer arayüzlere sahiptir.

  4. Sınıfların mirası, hizmetlerin ve kayıtların mirası ile aynı olabilir (aynı?).

• OO ve SO farklı tür problemler için faydalıdır. Yani her uygulamada buradaki ya da oradaki paradigmayı kullanmak caziptir. Ayrı bir dile sahip olmak, aynı programdaki ikisi arasında geçiş yapmayı engelleyecektir.

• SO sadece bir programlama paradigması değil, aynı zamanda bir program davranışıdır: web hizmetleri, işletim sistemi bileşenleri vb. SO'dur, ancak mutlaka bir SO dilinde yazılmasına gerek yoktur. Bu tür "ikili bileşenler" çok doğal ve başarılı. Ama bu farklı bir şey: programların kendi aralarında nasıl iletişim kurdukları değil, programların birbirleriyle nasıl iletişim kurdukları. Sanırım insanlar bunu yeterince karıştırıyorlar.