Yazılım mimarisinde kalıp: komisyoncu kalıbı

Adanali

Active member
Yazılım mimarisinde kalıp: komisyoncu kalıbı


  1. Yazılım mimarisinde kalıp: komisyoncu kalıbı

Modeller, modern yazılım geliştirme ve yazılım mimarisinde önemli bir soyutlamadır. İyi tanımlanmış terminoloji, açık belgeler sunar ve en iyisinden öğrenirler. Aracı Kalıbı, uzaktan hizmet çağrılarıyla etkileşime giren dağıtılmış yazılım sistemlerini yapılandırır. İletişimleri, sonuçlarını ve istisnaları koordine etmekten sorumludur.







Rainer Grimm, uzun yıllardır yazılım mimarı, ekip lideri ve eğitim yöneticisi olarak çalışmaktadır. C++, Python ve Haskell programlama dilleri üzerine makaleler yazmaktan hoşlanır, aynı zamanda sık sık uzmanlık konferanslarında konuşmaktan da keyif alır. Modernes C++ blogunda yoğun bir şekilde C++ tutkusundan bahsediyor.













“Pattern-Oriented Software Architecture, Volume 1” kitabındaki Broker Modeli, dağıtılmış sistemlerin birçok sorununu çözmeye yardımcı olur. Bu, örneğin doğru servis sağlayıcıyı bulmak, onlarla güvenli bir şekilde iletişim kurmak, doğru programlama dilini kullanmak veya hataları ele almak olabilir. Bu yazıda ayrıntılara girmeyeceğim. Sadece komisyoncu modeline kabaca bir genel bakış sağlamak için tasarlanmıştır. Daha fazla bilgi “Model yönelimli yazılım mimarisi, cilt 1” kitabında bulunabilir.

komisyoncu


Kapsam

  • Karmaşık bir yazılım sistemi, bir dizi ayrıştırılmış ve etkileşimli alt sistem olarak tasarlanmalıdır.
  • Kullanılan hizmet müşteriye karşı şeffaf olmalıdır.
  • Bunun aşağıdaki sonuçları vardır:
    • Tüm alt sistemler birbirleriyle bir süreçler arası iletişim protokolü (IPC) aracılığıyla iletişim kurmalıdır.
    • Bir alt sistem uygun hizmetini bulmalıdır.
    • Hizmetler yönetilmelidir.
Çözüm


  • Hizmet sağlayıcıyı ve hizmet kullanıcısını bir araya getiren bir komisyoncu tanıtın.
  • Hizmet sağlayıcı aracıya kaydolur.
  • İstemci aracıya bir talepte bulunur ve aracı daha sonra aracıyı hizmet sağlayıcıya bağlar.
  • Aracı, basit bir API aracılığıyla alt sistemlerin iletişim kurması, bulunması ve yapılandırılması için altyapı sağlar.
yapı

Komisyoncu beş bileşenden oluşur:














Client

  • Uygulama işlevselliğini uygulayın ve
  • aracılığıyla sunucuya istek gönderme clientseitig Proxy.
clientseitig Proxy

  • Belirli sistem işlevlerini kapsüller,
  • müşterinin dilini konuşun e
  • müşteri ve komisyoncu arasındaki ortalama.
Server

  • Hizmetleri uygulamak ve
  • komisyoncu ile kayıt olur.
serverseitig Proxy

  • çağrı sunucusu hizmetleri,
  • sunucunun dilini konuşun
  • sisteme özgü işlevleri kapsar e
  • sunucu ve komisyoncu arasındaki ortalama.
Broker

  • Sunucuları kaydedin ve silin,
  • mesajları ve hataları iletir e
  • sunucuları bulun.
Broker mimarisinin başka ilginç yönleri de var.

Arayüz tanımlama dili


Tipik olarak, sunucu tarafından sunulan hizmetler bir Arayüz Tanımlama Dili’nde (IDL) tanımlanır. İstemci tarafı proxy’si ve sunucu tarafı proxy’si için temel oluşturur. İşte iki tipik adım:

  1. Belirli bir programlama dili için saplama ve iskelet oluşturmak üzere programlama dilinden bağımsız IDL’yi kullanma. Bu genellikle farklı programlama dilleri için mümkündür.
  2. Saplama ve iskelete dayalı istemci tarafı proxy’si ve sunucu tarafı proxy’sinin uygulanması.
IDL ayrıca aracı içinde kaydedilebilir, böylece aracı, istemci tarafı tarafından istendiğinde uygun sunucu tarafı proxy’sini bulabilir.

Broker mimarisinin avantajı, örneğin farklı programlama dilleri konuşsalar bile istemciler ve sunucuların birbirleriyle iletişim kurabilmeleridir.

Buraya kadar Broker modelinin statik yapısını anlattım. Şimdi istemci ve sunucu arasındaki etkileşime bakacağım.

Müşterinin bir isteği var

Bir müşteri bir hizmeti kullanmak isterse, aracıdan talep eder. İkincisi, hizmet arabirimini uygulayan istemci tarafı proxy’sini döndürür. İstemci tarafı proxy, verileri önbelleğe almayı, işlemler arası iletişimi veya veri hazırlamayı (sıralama/seri hale getirme) işler. Sunucuyu geri çağıran sunucu tarafı proxy’sine bağlanır. Sunucu tarafı proxy’si, istemci tarafı proxy’sine benzer bir göreve sahiptir: verileri hazırlar ve sunucunun dilini konuşur. Sunucu, işlev çağrısının sonucunu döndürdüğünde, istemci tarafı ile iletişim kuran sunucu tarafı proxy’sini çağırır.

Sunucu oturum açar

Sistemin başlatılması sırasında aracı başlatılır ve olay döngüsüne girer. Sunucu başlatılır ve aracıya kaydolur. Sunucu, aracıdan kayıt onayını alır ve olay döngüsüne girer.

Ek aracılar

Bazen birden fazla komisyoncu vardır. Bir aracı daha sonra hizmet talebini başka bir aracıya iletebilir. Bu gelişmiş mimaride, her aracının iki protokolü desteklemesi gerekir. İstemci tarafı proxy’si ve sunucu tarafı proxy’si için bir dahili protokol ve diğer aracı için bir harici protokol.

Broker mimarilerinin birçok örneği vardır.

örnekler


SunRPC:


program rpcgen bir arabirim açıklamasından verileri dönüştürmek için saplama, iskelet ve bir XDR dosyası oluşturur. rpcgen C’de uzak işlevleri çağırmak için bir API sunar.

Yöntem çağrısını kaldır (RMI):

ONLAR rmic-Derleyici, bir Java sunucu arayüzünden taslaklar ve iskeletler üretir. SunRPC’deki fonksiyon referanslarından farklı olarak, bunlar nesne referanslarıdır. Java 5’ten başlayarak, taslaklar ve iskeletler dolaylı olarak Java Sanal Makinesi tarafından oluşturulur.

Ortak Nesne İstek Aracısı (CORBA) mimarisi:

CORBA, arayüz açıklaması için IDL’yi kullanır. IDL’nin sözdizimi C++ odaklıdır. CORBA, RMI benzeri nesneler kullanır. standartlaştırılmış uygulamaları IDL2Language Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I ve Python için derleyiciler mevcuttur.

Basit Nesne Erişim Protokolü (SOAP):

Arayüz tanımlama dili olarak Web Service Definition Language (WSDL) kullanılmaktadır. WSDL, metin tabanlı bir protokoldür (XML). Bu protokol yalnızca bildirimsel değil, aynı zamanda veri iletiminin türünü ve bir hizmeti de belirtir.

Java, C++, Python, Perl, … dillerinde bir wsdl2Compiler kod üreteci vardır.

  • C++ uygulaması: gSOAP
Avantajlar ve dezavantajlar


Avantajlar

  • Aracı aracılığıyla istemcinin ve sunucunun konumunun bağımsızlığı.
  • İstemci, sunucu uygulama değişikliklerinden bağımsızdır.
  • IDL değişiklikleri kolayca uygulanabilir, bu nedenle istemcide ve sunucuda yalnızca küçük değişiklikler gerekir.
  • İstemci ve sunucu yerel işlevsellik kullanmadığından aracıyı başka bir sisteme taşımak kolaydır.
  • Programlama dili derleyicisi için bir IDL varsa, diğer programlama dillerini konuşan istemcileri veya sunucuları eklemek yeterince kolaydır.
  • Mevcut broker mimarisinden yararlanabildikleri için yeni hizmetler kolayca eklenebilir.
  • SOAP, metin tabanlı bir protokoldür; bu, UNIX tabanlı komut satırı araçlarıyla iletişimlerin analiz edilmesini veya metin gönderen basit bir programın uygulanmasını oldukça kolay hale getirir.
Dezavantajları

  • Birçok dolaylı bağlantı (istemci -> müşteri tarafı temsilcisi -> komisyoncu -> sunucu tarafı temsilcisi -> sunucu), veri sağlama ve süreçler arası iletişim nedeniyle, performans genellikle yetersizdir; İstemci tarafı proxy’si ile sunucu tarafı proxy’si arasındaki ilk iletişimden sonra, her iki bileşen de genellikle aracı aracı olmaksızın birbirleriyle doğrudan konuşur.
  • Parçaların iletişimi birçok bileşene bağlıdır ve bu nedenle hata durumunda düzeltilmesi zordur; SOAP’tan farklı olarak, diğer protokoller ikili
Sıradaki ne?


Model Görünüm Denetleyicisi (MVC), klasik mimari kalıplardan biridir. Bir kullanıcı arabiriminin program mantığını tek tek model, görünüm ve denetleyici bileşenlerine ayırır. Model, uygulama verilerini ve kurallarını yönetir. Görünüm, verileri işler ve denetleyici, kullanıcıyla etkileşime girer. Bir sonraki yazımda MVC’yi tanıtacağım.


(rm)



Haberin Sonu
 
Üst