MuleSoft - Katır Projesi

Katır projesinin arkasındaki motivasyonlar şunlardı:

programcılar için işleri daha basit hale getirmek için
uygulama düzeyinde bir mesajlaşma çerçevesinden kurumsal çapta yüksek düzeyde dağıtılabilir bir çerçeveye ölçeklenebilen hafif ve modüler çözüm ihtiyacı.

Mule ESB, olay odaklı ve programlı bir çerçeve olarak tasarlanmıştır. Olay güdümlüdür çünkü mesajların birleşik gösterimi ile birleştirilmiştir ve takılabilir modüller ile genişletilebilir. Programatiktir çünkü programcılar, özel mesaj işleme veya özel veri dönüşümü gibi bazı ek davranışları kolayca ekleyebilir.

Tarih

Katır projesinin tarihsel perspektifi şu şekildedir:

SourceForge projesi

Katır projesi, Nisan 2003'te SourceForge projesi olarak başlatıldı ve 2 yıl sonra ilk versiyonu yayınlandı ve CodeHaus'a taşındı. Evrensel Mesaj Nesnesi (UMO) API, mimarisinin merkezinde yer alıyordu. UMO API'nin arkasındaki fikir, mantığı birleştirirken onları temeldeki taşımalardan izole etmekti.

Sürüm 1.0

Nisan 2005'te çok sayıda nakliye içeren piyasaya sürüldü. Bunu takip eden diğer birçok sürümün ana odak noktası, hata ayıklama ve yeni özellikler eklemekti.

Sürüm 2.0 (İlkbahar 2'nin Kabulü)

Konfigürasyon ve kablolama çerçevesi olarak Bahar 2, Katır 2'de benimsendi, ancak gerekli XML konfigürasyonunun ifade gücünün olmaması nedeniyle büyük bir aşırı taşıma olduğunu kanıtladı. Bu sorun, XML Şeması tabanlı yapılandırma İlkbahar 2'de kullanıma sunulduğunda çözüldü.

Maven ile Bina

Hem geliştirme hem de dağıtım zamanlarında Katır kullanımını basitleştiren en büyük gelişme, Maven kullanımı oldu. 1.3 sürümünden itibaren Maven ile inşa edilmeye başlandı.

Katır Kaynağı

2006 yılında, MuleSource, "görev açısından kritik kurumsal uygulamalarda Mule kullanarak hızla büyüyen topluluğun desteklenmesine ve etkinleştirilmesine yardımcı olmak için" dahil edildi. Katır Projesi için kilit dönüm noktası olduğunu kanıtladı.

Mule ESB'nin rakipleri

Aşağıda, Mule ESB'nin başlıca rakiplerinden bazıları verilmiştir -

WSO2 ESB
Oracle Hizmet Veriyolu
WebSphere Message Broker
Aurea CX Platformu
Fiorano ESB
WebSphere DataPower Ağ Geçidi
Workday İş Süreci Çerçevesi
Talend Enterprise Hizmet Veriyolu
JBoss Enterprise Service Bus
iWay Servis Yöneticisi

Katır Çekirdek Konsepti

Tartışıldığı gibi, Mule ESB, hafif ve oldukça ölçeklenebilir Java tabanlı bir kurumsal hizmet veriyolu (ESB) ve entegrasyon platformudur. Uygulamalar tarafından kullanılan çeşitli teknolojilerden bağımsız olarak, Mule ESB, uygulamaların kolay entegrasyonunu sağlayarak veri alışverişi yapmalarına olanak tanır. Bu bölümde, böyle bir entegrasyonun gerçekleşmesi için Mule'nin devreye giren temel konseptini tartışacağız.

Bunun için yapıtaşlarının yanı sıra mimarisini de anlamamız gerekiyor.

Mimari

Mule ESB'nin mimarisi, aşağıdaki şemada gösterildiği gibi, Taşıma katmanı, Entegrasyon katmanı ve Uygulama katmanı olmak üzere üç katmana sahiptir -

Genel olarak, Katır dağıtımını yapılandırmak ve özelleştirmek için gerçekleştirilebilecek üç tür görev vardır:

Hizmet Bileşeni Geliştirme

Bu görev, mevcut POJO'ların veya Bahar Fasulyelerinin geliştirilmesini veya yeniden kullanılmasını içerir. POJOs, get ve set yöntemlerini, bulut bağlayıcılarını oluşturan özniteliklere sahip bir sınıftır. Öte yandan Spring Beans, mesajları zenginleştirmek için iş mantığını içerir.

Hizmet Düzenleme

Bu görev temel olarak mesaj işlemcisini, yönlendiricileri, dönüştürücüleri ve filtreleri yapılandırmayı içeren hizmet arabuluculuğunu sağlar.

Entegrasyon

Mule ESB'nin en önemli görevi, kullandıkları protokoller ne olursa olsun çeşitli uygulamaların entegrasyonudur. Bu amaçla Mule, mesajların çeşitli protokol konektörlerinde alınmasına ve gönderilmesine izin veren taşıma yöntemleri sağlar. Katır, mevcut birçok taşıma yöntemini destekler veya özel bir taşıma yöntemi de kullanabiliriz.

Yapı taşları

Katır konfigürasyonu aşağıdaki yapı taşlarına sahiptir -

Bahar fasulyesi

Bahar çekirdeklerinin ana kullanımı servis bileşeni oluşturmaktır. Spring servis bileşenini oluşturduktan sonra, bir konfigürasyon dosyası üzerinden veya konfigürasyon dosyanız yoksa manuel olarak tanımlayabiliriz.

Ajanlar

Temelde Anypoint Studio'da Mule Studio'dan önce oluşturulan bir hizmettir. Bir sunucuyu başlattığınızda bir aracı oluşturulur ve sunucuyu durdurduğunuzda yok edilir.

Bağlayıcı

Protokollere özgü parametrelerle yapılandırılmış bir yazılım bileşenidir. Esas olarak bir protokolün kullanımını kontrol etmek için kullanılır. Örneğin, bir JMS bağlayıcısı, birConnection ve bu bağlayıcı, gerçek iletişimden sorumlu çeşitli kuruluşlar arasında paylaşılacaktır.

Global Yapılandırma

Adından da anlaşılacağı gibi, bu yapı taşı genel özellikleri ve ayarları belirlemek için kullanılır.

Global Uç Noktalar

Bir akışta birçok kez kullanılabilen Global Öğeler sekmesinde kullanılabilir -

Global Mesaj İşlemcisi

Adından da anlaşılacağı gibi, bir mesajı veya mesaj akışını gözlemler veya değiştirir. Transformatörler ve filtreler, Global Mesaj İşlemci örnekleridir.

Transformers- Bir transformatörün ana görevi, verileri bir formattan diğerine dönüştürmektir. Global olarak tanımlanabilir ve çoklu akışlarda kullanılabilir.

Filters- Hangi Katır mesajının işleneceğine karar verecek olan filtredir. Filtre, temel olarak bir mesajın işlenmesi ve bir hizmete yönlendirilmesi için karşılanması gereken koşulları belirtir.

Modeller

Aracıların aksine, stüdyoda oluşturulan mantıksal bir hizmet gruplamasıdır. Tüm hizmetleri belirli bir model içinde başlatma ve durdurma özgürlüğüne sahibiz.

Services- Hizmetler, iş mantığımızı veya bileşenlerimizi saran hizmetlerdir. Ayrıca bu hizmet için özel olarak Yönlendiricileri, Uç Noktaları, transformatörleri ve filtreleri yapılandırır.

Endpoints- Servislerin gelen (alan) ve giden (gönderen) mesajlar üzerinde çalışacağı bir nesne olarak tanımlanabilir. Hizmetler uç noktalar aracılığıyla birbirine bağlanır.

Akış

Mesaj işlemci, bir kaynak ile hedef arasındaki bir mesaj akışını tanımlamak için akışları kullanır.

Katır Mesaj Yapısı

Tamamen Katır Mesaj Nesnesi altına sarılmış bir Katır mesajı, Katır akışları aracılığıyla uygulamalardan geçen verilerdir. Yapı Katırının mesajı aşağıdaki diyagramda gösterilmektedir -

Yukarıdaki diyagramda görüldüğü gibi Katır Mesajı iki ana bölümden oluşur -

Üstbilgi

Aşağıdaki iki özellikle temsil edilen mesajın meta verilerinden başka bir şey değildir -

Inbound Properties- Bunlar, mesaj kaynağı tarafından otomatik olarak ayarlanan özelliklerdir. Kullanıcı tarafından manipüle edilemez veya ayarlanamazlar. Doğada, gelen özellikler değişmezdir.

Outbound Properties- Bunlar, gelen bir mülk gibi meta verileri içeren ve akış sırasında ayarlanabilen özelliklerdir. Katır ile otomatik olarak veya bir kullanıcı tarafından manuel olarak ayarlanabilirler. Doğası gereği, giden özellikler değişebilir.

İleti, bir akışın giden uç noktasından taşıma yoluyla farklı bir akışın gelen uç noktasına geçtiğinde, giden özellikler gelen özelliklere dönüşür.

İleti, bağlayıcı yerine bir akış ref aracılığıyla yeni bir akışa iletildiğinde giden özellikler, giden özellikler olarak kalır.

Yük

Mesaj nesnesi tarafından taşınan asıl iş mesajına yük adı verilir.

Değişkenler

Bir mesajla ilgili kullanıcı tanımlı meta veriler olarak tanımlanabilir. Temel olarak değişkenler, onu işleyen uygulama tarafından kullanılan bir mesajla ilgili geçici bilgi parçalarıdır. Mesajlarla birlikte hedefine iletilmesi amaçlanmamıştır. Aşağıda verildiği gibi üç tiptedirler -

Flow variables - Bu değişkenler yalnızca içinde bulundukları akış için geçerlidir.

Session variables - Bu değişkenler, aynı uygulama içindeki tüm akışlar için geçerlidir.

Record variables - Bu değişkenler yalnızca bir grubun parçası olarak işlenen kayıtlar için geçerlidir.

Ekler ve Ekstra Yük

Bunlar, her seferinde mesaj nesnesinde görünmesi gerekmeyen mesaj yükü hakkında bazı ekstra meta verilerdir.