“Olaylara Dayalı” bir sisteme karşı “İleti İletme” sisteminin esası

Sorum şu ki biraz azalmamış bir bakış açısıyla geliyor.

Bir " olay geçiren " sisteme karşı bir " mesaj ileten " sistemin göreceli değerleri nelerdir ?

Neden biri birini diğerinden seçsin? Güçlü ve zayıf yönleri nelerdir?

Sadece "teoride" değil, "pratikte" de bilmek istiyorum.

DÜZENLE:

Belirli bir sorun :

Küçük ölçekli servisler gibi davranabilen takılabilir bileşenlerden oluşan bir sistem kurmak istiyorum (her biri küçük bir görevi yerine getirir veya bir miktar bilgi sağlar).

Hizmetler şunları yapabilir:

• bir servisin çıktısının bir diğerinin girişlerinden biri olarak hareket edebilmesi için
• önceki bir cümle içerisinde belirtildiği gibi belirli bir girdi-çıktı ilişkisi olmadan bir hizmetin başka biri tarafından yerine getirilebilmesi için muhafaza hiyerarşilerine sahip olmaları

Sistemin amacı, başka bir sistemdeki düşük seviyeli olayların tek bir akışını daha yüksek seviye bilgi ve fonksiyonelliğe dönüştürmek ve ek olarak, tek bir olay serisi sağlayan diğer sisteme geri bir kanal sağlamaktır.

Bu yeterli olmazsa daha fazla ayrıntı sağlayabilirim.

Biraz daha etrafa baktıktan sonra. Bu ve bu muhtemelen durumumu daha iyi açıklıyor.

Bu durum için uygun olabilir gibi görünüyor: http://akka.io/

Tecrübelerime göre, tek belirgin fark, çoğu mesaj geçen sistemde, mesajın göndereni, mesajın alıcısının kim olduğunun farkında (ve genellikle de beyan eder).

Bu nedenle, bir etkinlik oluşturmak yerine, etkinlik gerçekleştiği için herhangi bir kişi, göndericiyi hedef alan alıcı (lar) veya mantıksal alıcı grubunun kimliğini tanımlar ve ardından mesajı doğrudan onlara gönderir veya bir mesaj simsarından geçirir. (işletim sistemi olay tabanlı bir sistemde bir ileti aracısı olarak görülebilir).

Açıkçası, Telastyn'in C # 'nin etkinliklerini uygulamasından bahsettiği bir konu var, ancak yine de farklı iş parçacıkları üzerinde çalışan kendi pub / alt modelinizi oluşturabilirsiniz.

Bu elmalar ve portakallar:

Bir Event Driven sistemi, mesajlar olarak iletilen olaylara (bu bağlamdaki mesajlar, paylaşılmayan ve değiştirilemeyen verilerdir ) olaylara büyüdükçe tepki verebilir . Bu tamamen mimari bir tasarımdır.

Bir Mesaj İletme sistemi , mesajları oluşturan ve ileten olaylar tarafından yönetilebilir . Bu tamamen bir uygulama tasarımıdır.

İkisi birbirini dışlayan değil.

Örnek: Olaya dayalı bir tasarımı , Erlang'daki gibi bir mesaj iletme ortamı da olabilecek herhangi bir dilde uygulayabilirsiniz .

"İleti aktarma" ile "olaya dayalı" arasındaki karışıklığın büyük kısmı mimari ve uygulama detayları ile ilgilidir. Aslında işletim sistemi kullanan olay odaklı sistemler gördüm (ve yazdım) uygulamaları için mesajlar verdim. Sanırım gerçekten mimari fikirlerden bahsediyorsunuz.

Birçok insanın zaten “mesaj iletmeyi” ve “olaya dayalı” ifadelerini belirttiği gibi, belirsizlikten kaçınmak için yeterince iyi bir terim yoktur.

Bir "olay geçiren" sisteme karşı bir "mesaj iletme" sisteminin göreceli değerleri nelerdir?

İleti geçişi

Bir "mesaj geçiyor" sistemi derken, bir nesnenin belirli bir başka nesneye mesaj gönderdiği bir sistemden bahsettiğinizi tahmin ederek başlayacağım. Bu paradigmaya dayanan bir sistem düşündüğümde, genellikle bir şeyi tespit eden bir nesnenin bir şey hakkında söylenmesi gerekenleri bildiği bir sistem düşünüyorum. (Nasıl bildiğini, sadece bildiğini belirtmiyorum.)

Bu tür mimarlık, üreticilerin ve tüketicilerin iyi bildiği sistemler için çok iyidir. Bir mesajın üreticisi onu kimin alması gerektiğini bilir ya da tüketici mesajı kimin alacağını bilir.

Bir bankacılık başvurusu yazıyorsanız, işlemlerinizi kime gönderdiğinizi ve kime geldiklerini gerçekten bilmek isteyebilirsiniz.

Etkinlik Tabanlı

"Olay temelli" bir sistem söylerken düşündüğünüz diğer sistem, bir nesnenin kendisine (kimin varsa) cevap vereceğini bilmeden bir "olay" oluşturduğu sistemdir.

Bu tür etkinlik odaklı mimari, üreticinin etkinliği kimin tükettiği veya tüketicinin etkinliği kimin ürettiği ile ilgilenmediği umrunda olmadığı sistemler için çok iyidir.

Genel olarak, bu sistemler, tüketiciler ve üreticiler arasındaki ilişkiyi bilmediğiniz ve ilişkinin dinamik olmasını beklediğiniz yerlerde mükemmeldir.

Bunu kullandığım bir sistem, uygulamanın gerçekte çalışma zamanında yüklenen dinamik olarak yapılandırılmış modüllerden (eklentiler) oluştuğu bir sistemdi. Bir modül yüklendiğinde, önem verdiği olaylara kaydolurdu. Sonuç, işlevselliği genişletmenin çok kolay olduğu bir sistemdi.

Mesela, normal şartlarda RA cevabına neden olan A durumunun yükselmiş bir Olay EA diyelim. RA cevabına neden olan nesne sadece EA olayını almak için kaydedildi ve geldiğinde ona etki etti. Şimdi, EA'ya RA_1 adlı yeni bir yanıt eklemek istediğimizi varsayalım. Bunu yapmak için, EA arayan ve RA_1 yanıtını üreten yeni bir nesne ekliyoruz.

İşte birkaç örnek (terminolojinizi kullanarak):

• "message Passing" : Patronunuz size zaman çizelgenizi doldurmanızı söyler.
• "olay odaklı" : Bölüm sekreteri, zaman çizelgelerinin bugün geleceğini hatırlatan herkese bir e-posta gönderir.

SOA'da Komuta Mesajları ve Etkinlik Mesajları konseptine sahipsiniz . Her ikisine de ihtiyaç var.

Bununla birlikte, komut mesajlarının alıcı uç noktaya daha yüksek bir davranışsal bağlanması vardır, çünkü açıkça bir noktadan bazı işlevleri gerçekleştirmesini istemektedir. Belirli bir uç noktaya bağlı olması gerekmez (bu, çalışma zamanında yapılandırılabilir veya belirlenebilir).

Öte yandan, olay mesajlarının gönderen / alıcı arasında davranışsal bir birleşimi yoktur, çünkü gönderenin alıcının mesajla ne yapacağına dair bir fikri yoktur. Eğer bile bilmiyor kimse olayı abone.

Daha fazla bilgi için, servis otobüs sitemi burada incelemek için bekliyoruz: http://www.servicebus.co.za

Tecrübelerime göre, ikisi arasındaki en büyük fark, mesaj geçiş sistemindeki mesajların birinci sınıf nesneler olmasına rağmen olay odaklı sistemlerdeki olaylar çok daha basit. Mesajlar bilgi taşıma eğilimindedir ve bu bilgiler dönüştürülebilir, saklanabilir, alınabilir ve yeniden gönderilebilir. Olaylar, hemen tüketilen ve daha sonra atılan daha küçük ve daha odaklı bilgi parçaları taşır. Bir olay kaynağından doğrudan bir veya daha fazla olay havuzuna gönderilme eğilimindeyken, mesajlar birçok alıcı arasında daha sık yönlendirilir ve rota boyunca herhangi bir noktada dönüştürülebilir / çevrilebilir / sarılabilir veya başka şekilde işlenebilir. Benzer teknolojiler kullanıyorlar (otobüsler, sıralar, filtreler vb.) Ama gerçekten farklı canavarlar.

Pratik bir bakış açısına göre, mesajlar tipik olarak gönderenin adres alanından alıcının adres alanına kopyalanan (veya başka şekilde değişmez bir nesne olması zorunlu olan) bir bellek bloğu olarak uygulanır, bu yüzden hemen iş parçacığı güvenliği elde edersiniz.

Göndereni geçen mesajların bazılarında alıcıyı belirtmek zorundadır, ancak bazı durumlarda bir posta kutusuna sadece mesaj gönderebilir ve herhangi biri bu posta kutusundaki mesajları dinleyebilir, bu nedenle ne kadar sıkışık olduklarına dair bir esneklik vardır. Elbette, sözleşmenin "Bu etkinlik gerçekleştiğinde bu posta kutusuna bir ileti göndereceğim" olduğu bir posta kutunuz olabilir .

Olaylar durumunda, bir delege kaydettiriyor veya etkinliğin sahibiyle geri arama yapıyorsunuz. Nesneye yönelik programlamada bu, olay sahibinin olayı almak için kaydedilen nesneye referans tutması anlamına gelir. Bu, bazen hangi nesnenin olay işleyicisinin kaydını kaldırmayı unuttuğunu anlamaya çalışırken, defter tutma kabuslarına yol açabilir. Hedef, artık yararlı bir şey yapmıyor olsa bile, etkinlik sahibi çöp toplanana kadar hedefin çöp toplanamayacağı anlamına gelir.

Şahsen, Windows GUI programlama vb. Olayların size zorlandığı durumlar dışında olayların üzerinden geçen mesajları seçerdim.