Yazılım mimarisindeki modeller: Broker modeli

Adanali

Active member
Yazılım mimarisindeki modeller: Broker modeli


  1. Yazılım mimarisindeki modeller: Broker modeli

Modeller, modern yazılımın geliştirilmesinde ve yazılımın mimarisinde önemli bir soyutlamadır. Açıkça tanımlanmış terminoloji, temiz dokümantasyon ve öğrenme en iyisinden sunarlar. Broker modelinde yapılandırılmış dağıtılmış yazılım sistemleri, uzak hizmet çağrıları ile etkileşime girer. İletişim koordinasyonundan, sonuçlarının ve istisnalarının sorumludur.










Rainer Grimm yıllardır yazılım mimarı, ekip ve eğitim müdürü olarak çalıştı. C ++ programlama dilleri, Python ve Haskell hakkında makaleler yazmayı seviyor, ancak uzman konferanslarla konuşmayı da seviyor. Modern C ++ blogunda, C ++ tutkusuyla yoğun bir şekilde ilgileniyor.













“Modellere yönelik yazılım mimarisi, Cilt 1” kitabının broker modeli, dağıtılmış sistemlerin birçok zorluğunu çözmeye yardımcı olur. Bu, örneğin, doğru servis sağlayıcısını bulmak, onunla güvenli bir şekilde iletişim kurmak, doğru programlama dilini kullanmak veya hataları yönetmek için olabilir. Bu makaledeki ayrıntıları girmeyeceğim. Sadece komisyoncu modeline yaklaşık bir genel bakış vermelidir. Daha fazla bilgi “Pain odaklı Yazılım Mimarisi, Cilt 1” kitabında mevcuttur.

Komisyoncu


Kapsam

  • Karmaşık bir yazılım sistemi, bir dizi çıkarılmış ve etkileşen alt sistemler olarak tasarlanmalıdır.
  • Kullanılan hizmet müşteri için şeffaf olmalıdır.
  • Bunun aşağıdaki sonuçları vardır:
    • Tüm alt sistemler, bir Ter Tür İşlem İletişim Protokolü (IPC) aracılığıyla birlikte iletişim kurmalıdır.
    • Bir alt sistem doğru hizmetini bulmalıdır.
    • Hizmetler yönetilmelidir.
Çözüm



  • Servis sağlayıcıyı ve hizmet kullanıcısını bir araya getiren bir broker tanıtın.
  • Servis sağlayıcı broker ile kayıtlar.
  • Müşteri, onu servis sağlayıcıya bağlayan komisyoncuya bir talepte bulunur.
  • Broker, basit bir arılar aracılığıyla alt sistemlerin iletişim, araştırma ve yapılandırılması için altyapı sağlar.
yapı

Broker beş bileşenden oluşur:















Client

  • Uygulamanın işlevselliğini uygular e
  • Sunucuya istekler gönder clientseitig Proxy.
clientseitig Proxy

  • Capselt Sistemi -Kayalı İşlevler,
  • Müşterinin dilini konuşur e
  • müşteri ve komisyoncu arasında aracılık etti.
Server

  • Uygulanan hizmetler e
  • Brokeri kaydedin.
serverseitig Proxy

  • Sunucu hizmetlerini arayın,
  • Sunucunun dilini konuş
  • Capselt Sistemi -Kaymatik İşlevler E
  • sunucu ve komisyoncu arasında iletilir.
Broker

  • Kaydedilmiş sunucu ve raporlar
  • Mesajları ve hataları iletir e
  • Sunucuyu bulun.
Broker mimarisinin başka ilginç yönleri de var.

Arayüzün dil tanımı


Genellikle sunucu tarafından sunulan hizmetler, arayüzün (IDL) tanımı dilinde tanımlanır. Proxy ClientSeitgen ve sunucu proxy için tabandır. İşte iki tipik adım:

  1. Belirli bir programlama dili için şemayı ve iskeleti oluşturmak için IDL'yi programlama dilinden bağımsız kullanın. Bu genellikle farklı programlama dilleri için mümkündür.
  2. Sapı ve iskelete dayalı olarak sunucu yardımcısı ve sunucu yardımcısının uygulanması.
IDL, komisyoncunun içinde de kaydedilebilir, böylece komisyoncu istemci tarafında istenirse sunucunun mengene hakkını bulabilir.

Broker mimarisinin avantajı, örneğin farklı programlama dilleri konuşsa bile müşterilerin ve sunucuların birbirleriyle iletişim kurabilmeleridir.

Şimdiye kadar broker modelinin statik yapısını tanımladım. Şimdi istemci ve sunucu arasındaki etkileşimi inceleyeceğim.

Müşterinin bir isteği var

Bir müşteri bir hizmet kullanmak istiyorsa, brokerden bunu sorar. İkincisi, hizmet arayüzünü uygulayan müşteri vekili iade eder. Müşterinin temsilcisi -Verilerin ara depolamasını, süreçler arasındaki iletişimi veya verilerin hazırlanmasını (marshalling/serileştirme) yönetir. Sunucuyu arayan sunucu milletvekiline bir bağlantı kurar. Sunucu temsilcisinin müşteri yardımcısına benzer bir görevi vardır: Verileri hazırlayın ve sunucunun dilini konuşur. Sunucu işlev çağrısının sonucunu döndürdüğünde, istemci tarafı ile iletişim kuran sunucusunu çağırır.

Sunucu kaydeder

Sistemin başlatılması sırasında broker başlar ve olay döngüsüne girer. Sunucu komisyoncuyu başlatır ve kaydeder. Sunucu, teyit onayını komisyoncudan alır ve olay döngüsüne girer.

Ek broker

Bazen bir komisyoncudan daha fazlası vardır. Bu nedenle bir broker hizmet gereksinimini başka bir komisyoncuya devredebilir. Bu ileri mimaride, her broker iki protokolü desteklemelidir. Müşteri yardımcısı ve sunucu yardımcısı için dahili bir protokol ve diğer komisyoncu için harici bir protokol.

Broker mimarisinin birçok örneği var.

Örnekler


SUNRPC:


Program rpcgen Verilerin dönüştürülmesi için saplama arayüzünün, iskeletlerin ve bir XDR dosyasının açıklaması ile oluşturulur. rpcgen C'de uzaktan işlev çağrıları için bir API sunar.

Uzak Yöntemin Çağrımı (RMI):

. rmic-Compiler, Java'daki bir sunucu arayüzünden saplama ve iskeletler üretir. SUNRPC'deki fonksiyonel referansların aksine, bunlar nesnelere referanslardır. Java 5'ten, Stubs ve iskeletler Java Sanal Makinesi tarafından dolaylı olarak üretildi.

Ortak Nesne Yanıt Broker Mimarisi (CORBA):

Corba, IDL'yi arayüzün açıklaması için kullanır. IDL'nin sözdizimi C ++ 'a yönlendirilir. Corba, RMI nesnelerine benzer kullanır. Standartlaştırılmış uygulamalar IDL2Language Derleyiciler ADA, C, C ++, Lisp, Smallalk, Java, Cobol, PL/I ve Python için mevcuttur.

Basit Nesne Erişim Protokolü (SOAP):

Web hizmetinin (WSDL) tanımı dili, arayüz açıklamasının bir dili olarak kullanılır. WSDL metin tabanlı bir protokol (XML). Bu protokol sadece bildirici değil, aynı zamanda veri iletiminin türünü ve bir hizmeti de belirtir.

Java, C ++, Python, Perl, …

  • C ++ Uygulaması: GSOAP
Avantajlar ve dezavantajlar


Avantajlar

  • Aracı istemci ve sunucudan bağımsızdır.
  • İstemci, sunucudaki uygulamadaki değişikliklerden bağımsızdır.
  • IDL'deki değişiklikler kolayca uygulanabilir, böylece istemci ve sunucuda yalnızca düşük ayarlamalar gereklidir.
  • İstemci ve sunucu belirli sistem işlevlerini kullanmadığı için komisyoncuyu başka bir sisteme getirmek kolaydır.
  • Diğer programlama dillerini konuşan müşteriler veya sunucular, programlama dili derleyicisi için bir IDL varsa eklemek için yeterince kolaydır.
  • Mevcut komisyoncunun mimarisini kullanmak mümkün olduğundan yeni hizmetler kolayca eklenebilir.
  • Sabun metin tabanlı bir protokoldür; Unix'e dayalı kontrol satırı araçlarıyla iletişimi analiz etmeyi veya metni gönderen basit bir program uygulamayı kolaylaştırır.
Dezavantajlar

  • Çok sayıda dolaylı (istemci -> istemci temsilcisi -Id -> Broker -> Sunucu -Temsilci -> Sunucu) nedeniyle, işlemler arasında veri ve iletişim temini, performans genellikle yeterli değildir; Müşteri tarafındaki milletvekilleri ile sunucu tarafındaki milletvekilleri arasındaki ilk iletişim yapıldıktan sonra, her iki üye de ara broker olmadan doğrudan aralarında konuşur.
  • Tarafların iletişimi birçok bileşene bağlıdır ve bu nedenle hata durumunda hata ayıklamak zordur; Sabun aksine, diğer protokoller ikili
Sırada ne var?


Model Görünüm Denetleyicisi (MVC) klasik mimari motiflerden biridir. Bir kullanıcı arayüzünün programının mantığını tek tek bileşenlerin modeline, görünümüne ve denetleyicisine böler. Model, uygulamanın verilerini ve kurallarını yönetir. Görünüm verileri temsil eder ve denetleyici kullanıcı ile etkileşime girer. Bir sonraki makalemde MVC'yi sunacağım.


(RME)




Ne yazık ki, bu bağlantı artık geçerli değil.

Boşa harcanan eşyalara olan bağlantılar, 7 günlük daha büyükse veya çok sık çağrılmışsa gerçekleşmez.


Bu makaleyi okumak için bir Haberler+ paketine ihtiyacınız var. Şimdi yükümlülük olmadan bir hafta deneyin – yükümlülük olmadan!
 
Üst