Enterprise Integration Patterns

Aşağıdaki adreste Enterprise Integration Pattern’leri anlatan kitabı bulabilirsiniz. Kitap linki

Daha önceki yazılarımızda tasarım ve mimari örüntülerden bahsetmiştik. Buradaki örüntüler ise mimari örüntüler/stiller içerisindeki iletişim kısmında yer alan örüntülerdir. 1'den fazla uygulamanın birlikte nasıl mesaj alışverişi yapacağı üzerine oluşturulmuş Entegrasyon örüntüleridir. Yani bir sistem içerisinde yer alan uygulamaların nasıl birbirleri ile entegre olacağı tanımlanmaya çalışılır.

Uygulamalar birbirleri ile 4 şekilde haberleşirler.

Dosya Transferi: Bir uygulama dosyaya yazar. Diğer uygulama’da bu dosyayı okur. Dosya adresi ve formatı konusunda iki uygulamanın anlaşmış olması gerekir. Dosyanın ne zaman yazılacağı, ne zaman okunacağı ve ne zaman silinebileceği konusunda uygulamaların anlaşmış olması gerekmektedir.

Paylaşılmış Ortak Veritabanı: Uygulamalar aynı veritabanı üzerindeki aynı tablolardaki veriler üzerinden çalışır. Bir uygulama yazar , bir diğeri okur.

Uzak Procedure Çağırma (RPC): Başka bir uygulamadaki metodu çağırma SOAP buna bir örnektir. Diğer uygulamadan function call nesnesi xml dönüştürülüp karşıdaki uygulamaya gönderilir. Karşıdaki uygulama yine bu nesneyi method ve nesneye dönüştürüp karşıdaki fonksiyonu trigger eder. Bu işlem senkron bir işlemdir.

Mesajlaşma: Bir uygulama ortak bir mesaj kanalı üzerinden mesajını yayınlar. Diğer uygulamalar ilerleyen süre içerisinde bu kanaldan mesajı alır ve kullanırlar. Mesajı gönderen ve alanın mesaj kanalı ve formatı konusunda anlaşmış olmaları gerekir. Bu işlem asenkron olarak gerçekleştirilebilir.

Yukarıda bahsettiğim kitap Mesajlaşma üzerinde durarak Mesajlaşma örüntülerini anlatmıştır.

TERMİNOLOJİ

Message(Mesaj): Uygulamalar arasında gönderilen/alınan veri paketleridir. Mesaj header/body kısmından oluşur. Header kısmında genellikle kimin gönderdiği, kim/kimlere gönderdiği, veri içeriği ve formatı hakkında bilgiler taşır.

Channel (Kanal): Mesajın uygulamalar arasında taşındığı kuyruk yapıları ve sunuculardır.

Sender/Producer: Mesajı kuyruğa koyan, oluşturan.

Receiver/Consumer: Mesajı kuyruktan alan, kullanan ve silen.

Mesajlaşma Sistemlerini Neden Kullanıyoruz ?

Uzak İletişim: Bir verinin/fonksiyonun/olayın mesaj ile kaplanarak serialize edilip diğer uygulamaya geçirilmesi oldukça zahmetli ve problemli bir işlemdir. Bu tip bir zahmete katlanmanız için uzak bilgisayarlarla iletişim ihtiyacınız olması gerekir. Aynı makine üzerinde bu tip işlemler yapıyorsanız ortak bellek , ortak collection yapıları ile bu iletişimini halledebilirsiniz.

Platform/Dil: Uygulamayı geliştiren ekipler farklı platformları Linux, Windows, Unix ve aynı zamanda farklı dilleri C++, Java, Phyton vb.. kullanmış olabilirler. Bu durumda mesajlaşma hiç bir ortamın kendi yapısını bozmadan iletişimini sağlar.

Asenkron: Uygulamalar aynı anda birbirleri ile iletişmek için müsait olmayabilirler. X zamanında gönderici mesajı göndermek için müsaitken alıcı bunun için uygun olmayabilir. Bu durumda mesajların kanallarda beklemesi gerekmektedir. Gönderici ve alıcı uygulamalarının birbirleri ile iletiştikleri kısımları asenkron olarak geliştirmeleri gerekmektedir.

Değişken Zamanlama: Uygulamaların bazılarında isteği bulunanın cevap beklemesi ve bunun sonucunda diğer işlemleri geçebilmektedir. Ama arka planda yapılacak işlem çok uzun sürecek işlemler ise mesajı alan kısım bunu işliyorum şeklinde bir cevap dönerek mesajları batch olarak uzun bir süreçte işleyebilir, bu sayede uygulamalar işlemlerin bitmesini beklemeden diğer işlemlerine geçebilir.

Throttling: RPC senkron olmasından dolayı istemci sistemlerin alıcı uygulamayı dar boğaz ettiği durumlar için oldukça iyi mesajlaşma sistemi oldukça uygun bir yöntemdir.

Güvenilir İletişim: Bazen alıcı sistemin çökmesi veya ağ problemlerinden dolayı RPC fonksiyonu çalışmaz ve işlem yapılamadan yarım kalabilir. Mesajlaşlaşma sistemlerinde mesajın atomic bir veri olarak tutulduğundan bir kopyasının diskte tutulması, replikasının tutulması sayesinde iletişim kaybı veya mesaj kaybı yaşanmaz.

Offline Çalışma: Bazen iletişim olmadan tüm çalışmaların local’e kaydedilmesi sonrasında bağlantı kurulduğunda senkronizasyon yapma ihtiyacı olabilir. Bu durumda tüm işlemler client kuyrukta tutularak iletişim kurulduğunda diger sistemlere aktarılabilir.

Mediation: Mediator örüntüsünde olduğu gibi. Tüm entegrasyonun merkezi bir yerden yönetiliyor olması sayesinde sonradan sisteme katılacak bir uygulamanın diğer uygulamarı bilmesi gerekmez. Sadece mesajlaşma sistemine entegre olması yeterli olacaktır.

Thread Management: Mesajlaşma sistemi bloklanan threadlerin sayısının atmasınıda engelleyerek, uygulamaların kilitlenmesini engellemiş olur.

Örüntüler

İlerleyen yazılarda aşağıdaki örüntülerden ve resimden daha detaylı bahsedeceğim.

Okumaya Devam Et 😃

Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.