Phil Wilkins | Bulut Geliştirici Öncüsü, Oracle | Aralık 2022
Yazılımın başka yazılımlarla konuşması gerekir. Bazen bir uygulamanın bir bölümündeki yazılımların hizmet talep etmesi veya uygulamanın başka bir bölümüyle veri alışverişi yapması gerekir. Yahut bir uygulama tümüyle farklı bir uygulamadan hizmet talep etmek veya veri alışverişi yapmak zorunda kalır.
Bu iletişim türleri için kullanılan iki tipik mekanizma vardır: uygulama programlama arayüzleri (API'ler) ve mesajlaşma.
API'ler ve mesajlaşma arasındaki farklar bazen kafa karıştırıcı olabilir. Çünkü terimler çok belirsiz biçimlerde kullanılır. API kısaltmasının kendisi açık bir anlam ifade eder. Ancak aşağıda açıklayacağımız nedenlerden dolayı, bu terim farklı anlamlar aldı. Mesajlaşma, neredeyse her sistemden sisteme iletişimi kapsayacak şekilde, genellikle çok geniş anlamlarda kullanılan bir terimdir. API'lerin ve mesajlaşmanın ne anlama geldiğini netleştirelim.
Geniş açıdan bakıldığında, bir API, yazılımın hizmet isteklerini nasıl alabileceğini ve bunlara nasıl yanıt verebileceğini tanımlayan sözleşmedir. Bu sözleşme yazılım geliştiricileri tarafından belirlenir.
Kulağa kolay mı geliyor? Bir bakıma öyle. Ancak pratikte, konuşmanın gidişatına bağlı olarak API'nin zımni anlamı değişebilir. Kısaltmayı açacak olursak, API, bir yazılım parçasının başka bir yazılım parçası ile etkileşim kurabileceği arayüz veya "sözleşme" demektir. Bazen bir API hakkındaki konuşmalar üst düzey mimari tanımlarına odaklanır. Bazen çok ayrıntılı olabilir ve geliştiricilerin API'yi uygulamasına ilişkin belirli yöntemlerin detaylarını içerir.
API'lerle ilgili bazı kitap ve makalelerde API'ler bir kapı olarak tanımlanır. API'nin özellikleri kapıyı ifade eder. Örneğin, otomatik olarak açılan bir market kapısı veya ultra güvenli bir banka kasası kapısı olabilir. Bir uygulamanın sözleşmesi -kapının özellikleri- aşağıdakiler gibi konuları ele almanıza yardımcı olmalıdır:
API'ler yazılımın servis isteklerini nasıl göndereceğine ve alacağına ilişkin koşulları tanımlarken mesajlaşma, bir sistemden diğerine bilgi gönderme sürecidir. Anahtar kelime, işlemdir.
Bunu şu şekilde düşünün:
Mesajlaşma, hizmet istek sahibinden hizmet sağlayıcısına (genellikle aracı olarak bilinen bir üçüncü taraf kullanarak) bazı bilgi bloklarını iletme sürecidir.
Gerçek dünyadan bir benzetme kullanmak için bir müşteriye kısa mesaj gönderen bir şirketi düşünün. Mobil operatörün mesajı gönderebilmesi için hizmet sağlayıcının, alıcının telefon numarasını bilmesi gerekir. Bununla birlikte, veri yükü, operatörün açısından bakınca herhangi bir şey olabilir. Operatörün, metin mesajınızın İngilizce, İspanyolca, Japonca veya emoji olup olmadığını bilmesi gerekmez.
Mesajlaşma, mesajı göndericiden müşteriye iletmek üzere arka planda yürütülen tüm eylemleri ifade eder.
Siz ve müşterinizin, mesajlaşma sürecinin nasıl çalıştığını anlamanız gerekmez. Operatörlerin ve akıllı telefon üreticilerinin işlerini düzgün yaptıklarına güvenirsiniz. Aynı şekilde, operatörün yükü anlaması gerekmez. Yalnızca doğru kişiye teslim edildiğinden ve bozulmadığından veya değişmediğinden emin olması gerekir.
Teknolojinin getirdiği sınırlara uygun olduğu sürece, çoğu mesajlaşma platformunun veri yükünün ne olduğuyla ilgilenmediğini yine söyleyelim. Benzetmeye geri dönecek olursak, akıllı telefonlar ve mobil operatörler metninizin İngilizce mi yoksa emoji mi olduğunu umursamaz.
API'ler, API platformları ve API yönetimi bileşimi hakkında daha fazla bilgi edinin.
Kurumsal yazılım sistemleri, birden fazla ayrı yürütülebilir süreçten oluşturulur. Bu nedenle, işlemler arası iletişim (IPC) gerektirir. Buradaki iletişimler karmaşık olabilir. Bir işlemi gerçekleştirmek için çok sayıda ayrıntılı biçimlenmiş veriyle birçok API çağrısı yapılabilir. Bir iş gereksinimini karşılamak için bu işlemlerin dikkatle düzenlenmesi ve doğru şekilde tamamlanması gerekir.
Örneğin, bir müşterinin satın alma siparişini düşünün. İşlemin müşteri veritabanına erişmesi; envanter veritabanını, muhasebe sistemini, fatura oluşturan sistemi ve kredi kartı masraf sistemini sorgulaması; envanteri ve müşteri hesabını ayarlaması; bir ambar isteği oluşturması ve bir sevkiyat isteği başlatması gerekir. Bunların tümü doğru sırada yapılmalı ve doğru şekilde tamamlanmalıdır.
Geçmişte bu etkileşimler, dosya sistemi veya veritabanı gibi bir tür paylaşılan depolama alanı kullanılarak gerçekleştiriliyordu. Ancak, daha modern kurumsal sistemlerde süreçler doğrudan birbiriyle iletişim kurarak süreci hızlandırabilir ve sorunları ortadan kaldırabilir (örneğin, siparişinizin gerektirdiği stok, önceki siparişlere zaten tahsis edildiyse).
İletişimimizin eşzamanlı veya eşzamansız yapıda olduğunu söyleyebiliriz. Eşzamanlı iletişim, bir iletişimde yer alan tüm tarafların bulunması ve yeniden gönderim yapabilmesi gerektiği anlamına gelir. Sipariş örneğimizde, elektronik ödemelere dahil olan sistemler gerçek zamanlı etkileşim için kullanılabilir olmalıdır. Diğer durumlarda, iletişim eşzamansız olabilir ve iletişim kurmak isteyen sistemlerden oluşan tarafların aynı anda bulunması gerekmez. Birbirimize e-posta yazmak bu şekilde çalışır. Eşzamansız çalışan bir iletişim için, bilgi alışverişini sağlamak üzere bir aracıya ihtiyaç duyarız.
Bu karmaşık kurumsal mesajlaşma sistemleri farklı çeşitlerde veya örüntülerde gelir:
Hizmet yolu. Hizmet yolu, farklı süreçler arasında tutkal görevi görür ve yukarıda bahsedilen karmaşık işlemde olduğu gibi, bu süreçler arasında orkestrasyon gerçekleştirir. Hizmet yolu sistemleri genellikle, veri yüklerini bir formattan diğerine çevirme (metin mesajlaşma benzetmemizde İngilizce'den Fransızca'ya), mesajları mesaj içeriğine göre yönlendirme, hatta karmaşık işlemin durumuna göre bazı kararlar alma gibi katma değerli özellikler içerir. Örneğin, A ve B görevleri paralel olarak yapılabilir; B görevi başarıyla tamamlanmışsa C görevi gerçekleştirilir; B görevi başarısız olursa D görevi gerçekleştirilir; D görevi başarısız olursa insan müdahalesi gerekir.
Hizmet yolu tarzı mesajlaşma, sağlayıcılar ve tüketiciler arasındaki "kanal"da mesajların yönlendirilmesi ve çizelgeleme açısından eklenen bilgiler nedeniyle bazen akıllı kanal kullanımı olarak açıklanmaktadır. Buna orkestrasyon da denir.
Hizmet yolu için eşanlamlı terim mesaj yoludur. Bu teknolojiler hizmet odaklı mimari (SOA) çözümleri haline gelmeye başladığında, mesaj yolları ile hizmet yolları arasında bazı farklar vardı. Bugün arada anlamlı bir fark kalmadı. Doğrusu ikisinin de adı sadece yol olarak kısaltıldı.
Web hizmetleri:Bu terimin en geniş anlamıyla web hizmetleri, genellikle TCP ve HTTP protokollerini (veya HTTPS ve HTTP/2 gibi varyasyonları) kullanarak iki işlem arasındaki doğrudan eşzamanlı iletişimi ifade eder. Tüketici ve istemci noktadan noktaya bağlantılar olarak gerçekleştirilir (sağlayıcı ucunun birden fazla eşzamanlı istemci bağlantısını desteklemesi yaygın olsa da). İki işlem arasında proxy'ler (ağ güvenlik duvarlarından API ağ geçitlerine ve web önbelleklerine) ve ağ (anahtarlar ve yönlendiriciler) aracıları olabilir, ancak sağlayıcı da tüketici de bunlardan haberdar olmaz.
Mesaj aracıları:Mesaj aracıları mesaj sağlayıcısı ile mesaj tüketicisi arasındaki aracılardır ve hem hizmet yollarında hem de web hizmetlerinde ortak yanları vardır.
Aracılar, mesajların göndereni ile alıcıları arasında bulunur, iletilen mesajı alır ve alıcılar tarafından tüketilene kadar saklarlar. Bu, mesajın, alıcının o sırada bulunup bulunmadığı konusunda endişelenmeden iletilebileceği anlamına gelir. Sonuç olarak, bu tür iletişim genellikle eşzamansız veya "gönder ve unut" olarak tanımlanır. Çünkü aracı çalıştığı sürece mesajın bir noktada teslim edileceğinden emin olabilirsiniz.
Web hizmetlerine benzerliği, istemci ve aracı arasındaki bağlantının noktadan noktaya bağlantı olarak temsil edilmesinden kaynaklanır. Mesaj aracısı işlevsel olarak görünmezdir.
Servis yoluna benzerliği ise aracının katma değerli bir hizmet sunmasından gelir ve alıcılar bağlanana kadar alınan mesajları tutabilir. Daha sağlam bir servis yolunun aksine, mesaj aracısı basit şeyleri anlamak dışında minimum zekaya sahiptir. Örneğin hangi hedeflerin belirli bir mesajı almak isteyebileceğini ve hedef mesajı zamanında tüketmezse ne yapacağını bilmez.
Aracılı iletişim stili, akıllı olmayan kanal şeklinde açıklanmaktadır. Aracılar minimum zekaya sahip olduğu için bir mesajın gönderilmesi veya alınması gerektiğinde uç noktaların neye ihtiyaç duyduğunun anlaşılması gerekir. Bu stil koreografi olarak tanımlanır (bir hizmet yolunun daha akıllı orkestrasyonunun aksine).
Veri akışı bu tartışma için oldukça özelleştirilmiş bir mesajlaşma biçimi olarak görülebilir, ancak bazı veri akışı teknolojileri bir veri işleme unsurunu destekleyebilir. Bu bağlamda akış, IPC teknolojisi yoluyla sürekli etkinlik akışını, web hizmetlerinin veya mesaj aracılarının iletişimi uygulayıp uygulamadığına bakılmaksızın aynı hedef(ler)e gönderme eylemini açıklar. (Çok nadiren servis yolları kullanılır çünkü bir servis yolunun ekstra zekasına gerek duyulmayacağı kadar hızlı akan çok fazla veri vardır.)
Bir akıştaki sürekli veri akışına ek olarak, genellikle neredeyse gerçek zamanlı veya düşük gecikmeli bir bağlantı bekler. Netflix gibi hizmetlerin geleneksel olarak video akışı olarak adlandırıldığı gerçeğini düşündüğünüzde bu sürpriz olmayacaktır. Sağlayıcıdan yeni video bitleri gönderilirken veya bir mesaj aracısı videoyu bir formattan diğerine dönüştürürken video içeriğinin durmasını ve başlamasını kesinlikle istemezsiniz.
Web hizmeti akışı için yaygın teknolojiler WebSockets, gRPC akışları ve GraphQL aboneliklerdir. Aracılı mesajlaşma akışları söz konusu olduğunda (Kafka gibi teknolojiler), bazen aracının iletilen olayların "kesit"ine bakmak için çalışmasından yararlanabilirsiniz. Bu, akışın kendisi hakkındaki bilgiler dahil olmak üzere değerli içgörüler toplamanıza yardımcı olur. Bu nedenle akış analitiği terimi kullanılır.
Akış analizlerinde uygulanan mantık karmaşık olsa da, mesaj aracısı karar almadığı veya mesajları değiştirmediği için aracı akıllı olarak kabul edilmez. Bu tür akış analitiği olanakları genellikle Kafka Streams gibi teknolojilerle uygulanır.
API'leri ve mesajlaşma sistemlerini tanımlamak kolaydır ancak ayrıntıları ve teknik özellikleri çok karmaşıktır. Belirsizliğe yer yoktur. Bu da doğru sektör standartlarına ve belgelere gerçek bir ihtiyaç doğurur. İdeal olarak bu standartların en iyi uygulanma yoludur.
Bu, özellikle API'ler için on yıldan uzun süredir gelişim alanı oldu. Sektör, bir web hizmeti türü olan ve muhtemelen modern kurumsal yazılımlarda kullanılan en yaygın API türleri olan REST tabanlı API'ler için OpenAPI spesifikasyonunu benimsedi.
API'ler (ve akış) ile, mesajların ve iletilerinin yönlerini tanımlamak ve açıklamak için bir dizi ek standart getirilir. Bunlar arasında protokol arabellekleri (Protobuf olarak da bilinir ve gRPC ile kullanılır) ve daha yakın zamanda kullanılmaya başlanan GraphQL, JSON Schema ve YAML yer alır.
Eşzamansız mesajlaşma alanında, son birkaç yılda birçok mesajlaşma gereksinimini karşılamak üzere OpenAPI ve diğer değişen standartların fikirlerin uyarlayan AsyncAPI adlı bir tanım etrafında birleşmek için başarılı çabalar görüldü.
Modern dağıtılmış uygulamalar, bazen aynı sunucularda çalıştırılan, bazen de çalışmayan ayrı yazılım parçalarına sahip bir hizmet koleksiyonu olarak uygulanır. API'ler, bu yazılım parçalarının hizmet istemek veya bilgi alışverişi yapmak için birbirleriyle konuşması için bir yol sağlar. Mesajlaşma sistemleri, eşzamansız iletişimleri kolaylaştıran altyapıyı ve API çağrıları için akıllı aracıları sağlar. Bunlar çok basit (akıllı telefon mesajları gibi) veya son derece karmaşık (karmaşık çok adımlı iş işlemleri için orkestrasyon gibi) olabilir. API kullanarak birbirleriyle doğrudan iletişim kuran dağıtılmış hizmetlerden söz etmemize gerek bile yok. Neyse ki değişen teknikler ve standartlar, veritabanı çağrılarından akış ortamına kadar her konuda API'lerin kullanılmasına olanak tanır. Ayrıca bu API'ler ve mesajlaşma standartları değişmeye ve ilerlemeye devam ederek, modern dağıtılmış yazılım mimarilerine daha hızlı, daha kolay ve daha güvenli bir geçiş sağlıyor.