Dağıtık Hizmetlerdeki Etkileşimler Üzerine Düşünceler

Network Working Group Jack Haverty (MIT) Request for Comments: 722 Eyl 1976 NIC #36806

I. ÖZET

Bu makale, dağıtık hizmetlerin tasarımıyla ilgili bazı konuları ele almaktadır. Özellikle, ağ üzerindeki çeşitli konumlarda bir hizmeti destekleyen programlar arasındaki etkileşimlerin özellikleriyle ilgilenmektedir. Sunulan fikirler, büyük ölçüde ARPANET üzerindeki çeşitli hizmet protokolleriyle [Kaynak 1] elde edilen deneyimlerden türetilmiştir.

Programlar arasındaki etkileşimlere ilişkin bir model geliştirilmiştir. Güvenilir ve tepkisel hizmetlerin kurulmasını teşvik eden ve basitleştiren bu modelin öne çıkan özellikleri belirlenmiştir. Bu ikililikler, çeşitli ARPANET protokolleriyle yaşanan sorunlar ve bu protokolleri kullanarak bir hizmeti yerine getiren programların tasarımı ve bakımı sırasında edinilen deneyimlerle gerekçelendirilmiştir.

Bu model bir şablon olarak kullanılarak, olası bir etkileşim protokolünün genel mimarisi sunulmaktadır. Bu mekanizma, belirli hizmetler için protokollerin inşa edileceği bir temel sağlar; uygulanması ve bakımı kolay, müşteriye güvenilir ve tepkisel görünen hizmetlerin oluşturulma sürecini basitleştirir. Bu sunum, referanslardan birinde tanımlanan RRP adlı böyle bir protokolün belirli bir örneğine giriş olarak hizmet etmeyi amaçlamaktadır.

II. GENEL BAKIŞ VE TERİMLER

Bu makale, bir ağ hizmetini destekleyen iki programın etkileşimini ele almaktadır. Bu tür uygulamaların bir sınıfının etkileşimlerine ilişkin bir model geliştirmekte ve uygulamaların istenen hedefleri ve özellikleri üzerine bazı düşünceler içermektedir. Model, posta işleme sistemleri için bir öneriden [Kaynak 2] türetilmiştir. Tanıtıldığı şekliyle terminoloji, büyük harf kullanımıyla vurgulanmaktadır.

Bilgisayar ağlarının birçok kullanımı, insan müdahalesi veya gözetimi olmaksızın, doğrudan programlar arasında iletişimi içerir. Buna örnek olarak gelişmiş bir posta işleme sistemi ya da çok konumlu herhangi bir veritabanı yöneticisi verilebilir.

Bu tür programlar SUNUCU (SERVER) olarak adlandırılacaktır. Bunlar, gerekli iletişim ve eşzamanlamayı sağlayan bir mekanizmanın kullanıcılarıdır. Sunucuların gerçekleştirdiği belirli yetenek HİZMET (SERVICE) olarak adlandırılacaktır. Belirli bir hizmet için sunucular birden fazla dilde yazılabilir, farklı türde bilgisayarlarda çeşitli sistem ortamlarında çalışabilir. Hizmeti kullanan varlık MÜŞTERİ (CUSTOMER) olarak adlandırılacaktır.

Sunucular, iki sunucunun iletişim halinde olduğu dönemler olan KARŞILAŞMALAR (ENCOUNTER) sırasında etkileşir. Bir karşılaşma, bir sunucunun başka bir sunucu ile çift yönlü bir iletişim bağlantısı olan bir KANAL (CHANNEL) kurmasıyla başlar. Sunucular arasındaki etkileşim, kanal üzerinden bilgi alışverişiyle gerçekleştirilir. Bu tür bir alışverişte kullanılan kurallar, etkileşime ilişkin PROTOKOLLER (PROTOCOLs) tarafından tanımlanır.

Bu makalenin teması, etkileşimlerin görece basit olduğu ve birçok olası hizmet için temel olarak kullanılabilecek belirli bir süreç etkileşimleri sınıfı için bir modeldir. Bu kategoriye uyan hizmetler, burada tanımlanan İSTEK-YANIT DİSİPLİNİ (REQUEST-REPLY DISCIPLINE) ile modellenebilecek bir biçimde etkileşir.

Sunucuların uygulanmasının kolaylığı ve işletim güvenilirliğiyle ilgili konuları ele alan bir dizi kılavuz ve hedef geliştirilmiştir. Bu kılavuzlar, uygun hizmetlere özgü protokollerin oluşturulmasına yardımcı olmak için kullanılabilir.

Buna ek olarak, sunulan kılavuzlar, bu tür hemen hemen her hizmet için inşa edilecek bir protokolde ortak olacak ilkel ve işletimsel kavramlar çıkarılarak, genel bir süreç etkileşim protokolü için temel olarak kullanılabilir.

Bu fikirlerden yola çıkarak, her bir hizmete özgü ilkel eklenerek belirli hizmetler için genişletilecek bir temel sağlayan bir protokol oluşturulabilir. RRP [Kaynak 4], böyle olası protokollerden biridir. Sunucular arasındaki etkileşimi denetlemek için temel ilkelleri ve bu ilkellerin hizmete özgü işlemleri içerecek şekilde genişletilmesine yönelik bir mekanizma sağlar.

Buradaki tartışma, öncelikle RRP’nin tasarımının temelini açıklamayı ve hizmetlerin tasarımına ilişkin bazı genel konuları sunmayı amaçlamaktadır.

III. İSTEK-YANIT DİSİPLİNİ

Bu tartışma kapsamında ele alınan hizmet sınıfı, etkileşimleri aşağıdaki şekilde gerçekleştirilebilen hizmetlerdir.

İki sunucu, bazı harici yollarla bir kanal kurmuştur. Sunucular arasındaki tek bir etkileşim, İSTEKÇİ (REQUESTER) olarak adlandırılan sunucunun bir istek göndermesiyle başlar. Bu isteği alan sunucu, yani YANITLAYICI (RESPONDER), bir YANIT (REPLY) gönderir. İstekçi, yanıt dizisini yorumlayarak isteğin başarılı olup olmadığını, başarısız olup olmadığını ya da kısmen başarısız olup olmadığını belirler ve uygun eylemi gerçekleştirir. Bu olaylar dizisi bir DEĞİŞİM (EXCHANGE) olarak adlandırılır. Bu, basit tek işlemcili bir işletim sistemindeki bir alt yordam çağrısına benzer.

Bu modele program etkileşiminin İSTEK-YANIT DİSİPLİNİ adı verilir. Bunun yalnızca program davranışına ilişkin bir model olduğu ve örneğin uzun gecikmeli durumlarda verimlilik için bazı isteklerin ardışık hatlar (pipelining) halinde işlenmesini gerektiren hizmetleri zorunlu olarak dışlamadığı belirtilmelidir. Aslında, çoğu ağ hizmeti bu tür önlemleri gerektirir; ancak etkileşimleri yine de istek-yanıt modeline indirgenebilir.

Herhangi bir anda, taraflardan biri etkileşimin denetimine sahiptir ve etkileşimin EFENDİSİ (MASTER) olarak adlandırılır. Diğer taraf ise KÖLE (SLAVE) olarak adlandırılır. En basit durumlarda, istekçi her zaman efendidir; ancak RRP [Kaynak 4] gibi belirli uygulamalarda bu her zaman geçerli değildir.

IV. BİR ETKİLEŞİM MEKANİZMASININ ÖZELLİKLERİ

Bir etkileşim mekanizmasında istenen aşağıdaki özellikler kümesi; mesaj hizmetleri, dosya aktarımı, Datacomputer ve uzaktan iş girişi uygulamaları gibi çeşitli ARPANET uygulamalarında program iletişimiyle edinilen deneyimlerin sonucudur.

Bu tür sistemleri geliştirmeye çalışırken, sistemlerin üzerine inşa edildiği altyapıda arzu edilen bazı nitelikler tekrar tekrar ortaya çıkmıştır. Bu özellikler, sunucuların yazılmasını ve hata ayıklanmasını kolaylaştıracak, güvenilirliği koruyacak ve hizmet kesintilerinden kaçınırken müşteri gereksinimlerine tepkisel hizmetler sunulmasını sağlayacaktır.

Etkileşim mekanizmasında arzu edilen nitelikler, ilişkili hizmetlerde meydana getirmeleri amaçlanan etkilerin tartışılmasıyla birlikte sunulmaktadır. Bu tartışmanın basit hizmetler sınıfıyla ilgili olduğu ve daha karmaşık uygulamalar için uygun olmayabileceği özellikle vurgulanmalıdır.

1. Sunucular, işlev gördükleri bilgisayar sistemlerindeki farklılıklara rağmen, verinin yapısını ve anlamsal içeriğini koruyarak veriyi kesin bir biçimde aktarabilmelidir.
2. İletişim bağlantısının özelliklerinden kaynaklanan eşzamanlama ve zamanlama sorunları, hizmetin kendisine özgü olabilecek sorunlardan yalıtılmalı ve ayrı olarak ele alınmalıdır.
3. Hizmetler, kullanıldıkça ve geliştikçe genişletilmiş yetenekler sunmak isteyebileceğinden, hizmet protokolünün evrim geçirmesini sağlayacak bir mekanizma içermelidir.
4. Sunucu olarak işlev gören çeşitli programlar eşzamanlı geliştirmelerden geçebileceğinden, farklı yeteneklere sahip sunucuların güvenilir biçimde etkileşmesini ve en azından daha önce var olan hizmet düzeyini korumasını sağlamak için dikkatli olunmalıdır.
5. Olanakların genişletilmesine yönelik mekanizmalar, yeni yetenekler tanıtıldığında sunucuların değiştirilmesini gerektirmekten kaçınmalı; ancak yeni ya da deneysel bir hizmet sunmaya istekli bakım sorumlularının ilerlemesini de engellememelidir.

Bu nitelikler üç kategoriye ayrılabilir: veri kesinliği (1), süreç eşzamanlaması (2) ve hizmetin geliştirilmesi (3, 4, 5). Her biri, izleyen bölümlerde ayrı ayrı ele alınacaktır. Her niteliğin önemi ve ilişkili hizmet özellikleri üzerindeki etkisi, mevcut ve geçmiş hizmetlerle ilgili bazı sorunlara atıflarla birlikte verilecektir.

Bu hususlar birçok olası hizmet için ortak olduğundan, etkileşim protokolünün bunları mümkün olduğunca kendi mekanizması içinde içermesi uygundur. Bu, dikkatlice tasarlanmış olmaları halinde, bu özellikleri etkileşim altyapısından devralan hizmetlerin uygulanmasına olanak tanır.

V. KESİN VERİ AKTARIMI

Veri aktarımındaki kesinlik, bir verinin gönderici tarafındaki örneğinde bulunan anlamsal ve yapısal bilgilerin, ilgili sistemlerde tamamen farklı biçimlerde temsil ediliyor olsa bile, alıcının veriye ilişkin görüntüsünde yeniden üretilmesine olanak tanır.

Programların güçlü ve güvenilir yetenekler sunabilmesi için, ilgili hizmet açısından anlamlı olan verileri kullanarak etkileşebilmesi gerekir. Etkileşim mekanizması, hizmetlerin kendi ilgili veri türlerini tanımlamasına ve bu tür öğeleri verimli ve kesin biçimde aktarmasına izin vermelidir. Bu olanak, veri için bir "standart" sağlar ve hizmet tasarımcılarının hizmetin kendisiyle ilgili daha üst düzey konulara odaklanmasına imkân tanır.

Belirli bir türdeki veriler, bağlama ihtiyaç duymadan bu tür olarak tanınabilir olmalıdır. Mekanizma ayrıca, yeni veri türlerinin, bu verilerin anlamını yorumlayamasalar bile, eski sunucular tarafından hatasız biçimde ele alınmasına izin vermelidir.

Bu özellikler, hizmetlerin çalışmak için ihtiyaç duydukları soyut veriler cinsinden tasarlanmasına olanak tanır ve çeşitli makineler içinde temsil edildiği belirli biçimlerle ilgili sürekli ayrıntılı kaygıları ortadan kaldırır.

Örneğin, sunucuların belirli bir tarihi tanımlayan bir veriyi aktarması gerekebilir; bu veri, sistemler içinde farklı biçimlerde temsil edilebilir. Veri aktarım mekanizması, böyle bir veriyi katı bir bit ya da karakter düzeni olarak değil, başlı başına bir tarih olarak aktarabilmelidir.

Örneğin, mevcut FTP tabanlı posta sistemlerinde, iletiler sıklıkla önemli anlamsal içeriğe sahip bilgiler içerir; ancak bu bilgiler siteler arasında aktarılırken kaybolur ya da belirsizleşir. Buna bir örnek, basit bir karakter akışına çevrildiğinde bir dosya belirtiminin kimliğini fiilen tamamen yitirmesidir. İnsanlar genellikle bu tür akışları dosya adları olarak tanıyabilir; ancak bunu güvenilir biçimde yapan bir program geliştirmek çoğu zaman son derece zor, zaman alıcı ve verimsizdir. Sonuç olarak, ilgili dosyaların otomatik olarak getirilmesi gibi müşteriye sunulması kolay olması gereken hizmetler zor ve güvenilmez hale gelir.

Tarih ve saat gibi bazı verilerin ele alınmasında, belirli bir bağlamda görüldüğünde tarih ya da saat olarak tanınabilecek özel bir karakter deseni tanımlanarak bir miktar başarı elde edilmiştir. Bu durumların her biri, ilgili tekil veri için bir biçim tanımlanarak, ayrı ayrı ele alınmıştır. Genel olarak, biçim bir ölçüde verinin belirli bir bağlamda yer almasına bağlıdır ve bu bağlam dışında tanımlanabilir olacak kadar benzersiz değildir.

Belirli bir hizmet, verinin aktarılma biçimini tanımlayan protokollerin titizlikle belirtilmesi yoluyla veri kesinliğini sağlayabilir. Bununla birlikte, bu gereksinim yeterince yaygındır; bu nedenle veri kesinliği sağlayan bir olanağın etkileşim mekanizmasının kendisine dâhil edilmesini düşünmek uygundur.

Bunun başlıca etkisi, hizmet tasarımcılarını genellikle en az ilgi çekici ancak son derece kritik olan veri gösterimine ilişkin çok düşük düzeyli ayrıntıları düşünme zorunluluğundan kurtararak, güvenilir ve tepkisel hizmetlerin tasarlanmasını kolaylaştırmak olacaktır. Veri aktarım mekanizmasını yalıtarak, bu mimari aynı zamanda uygulamaların modülerliğini teşvik eder; bu da hizmetleri uygulamak veya değiştirmek için gereken maliyeti ve süreyi azaltabilir.

VI. SÜREÇ EŞZAMANLAMASI

Birçok hizmette karşılaşılan önemli bir sorun kaynağı, görece düşük bant genişliğine ve yüksek gecikmeye sahip bir iletişim bağlantısı üzerinden etkileşen sunucuların eşzamanlamasını içermiştir.

Çoğu hizmetteki etkileşimler, bir komut gönderilmesini ve bir yanıtın beklenmesini içerir. Belirli bir komutun ortaya çıkarabileceği yanıt sayısı sıklıkla değişkendir ve genellikle tüm yanıtların ulaşıp ulaşmadığını belirlemenin bir yolu yoktur. Programlar, önceki bir isteğin yanıtları tamamlanmadan yeni bir isteği kolayca gönderebilir ve bir yanıtın yanlış bir istekle eşleştirilmesi sonucu eşzamanlamayı kaybedebilir. Her sunucu programı, beklenmeyen bir yanıtın daha sonraki bir komut verildikten sonra gelmesi durumunda toparlanabilecek şekilde son derece dikkatli tasarlanmalıdır.

Güvenilir işletim için, her yanıtın en azından isteğin bir noktada doğrulandığı anlamında bir karşılık oluşturmasının her zaman gerekli olduğu unutulmamalıdır. Hiçbir hizmet, önceki bir isteğin başarısına bağlı olan dosya silme gibi kritik bir işlemi, bu istek doğrulanmadıkça gerçekleştirmemelidir. Mevcut protokollerde yanıt oluşturmadığı görünen istekler, daha sonraki bir isteğin onaylanmasıyla dolaylı olarak doğrulanmış sayılabilir. Bu tür protokoller çalışsa da, arzu edilenden daha opaktır ve sonuç olarak uygulanmaları daha zordur.

Protokollerin bu özellikleri, zaman aşımı ya da kabul edilebilir derecede yüksek bir durumda doğruluğu güvence altına almak için yeterli gecikmeler gibi, etkileşim için geçici yöntemlerin uygulanmasına sıklıkla yol açmıştır. Çoğu zaman bu, protokolün kullanımında deneyim kazanıldıkça hangi komutların sorun çıkarmaya daha yatkın olduğunun görülmesiyle programların dikkatlice ayarlanmasını gerektirmiştir. Bu tür yöntemler genellikle istenenden daha az tepkisel, daha az güçlü ya da daha az verimli ve kurulması ile bakımı pahalı hizmetlerle sonuçlanır.

Buna ek olarak, hizmetlere yönelik protokol tanımları sıklıkla eksik olmuştur; belirli bir komut için ortaya çıkabilecek yanıtların listesi ya hatalıdır ya da hiç yoktur. Bu durum, akıllı bir sunucu geliştirmeye çalışan programcının işini büyük ölçüde karmaşıklaştırır. Çoğu durumda, her bir örnekte hangi yanıtların yaygın olduğunun deneyimle görülmesiyle sunucular zaman içinde yavaş yavaş iyileştirilir.

Yukarıda belirtilen eşzamanlama sorunları, hizmetin işletiminin doğal bir parçası olarak ortaya çıkanlara ek olarak vardır. Dolayısıyla eşzamanlama sorunları iki sınıfa ayrılabilir: hizmetin doğasında bulunanlar ve etkileşim mekanizmasının kendisiyle ilişkili olanlar.

Güvenilir ve tepkisel sunucuların geliştirilmesi, etkileşim mekanizması ve protokollerin dikkatli tasarımıyla desteklenebilir. Komutlar ile yanıtlar arasında belirsizliğe yer bırakmayan, tamamen tanımlanmış bir eşleme arzu edilir. İki tür eşzamanlama konusu ayrı ayrı ele alınabilir. Kendi eşzamanlamasını yöneten bir etkileşim mekanizması, hizmet tasarımcılarının kullanması için bir temel olarak sağlanabilir; güvenilir hizmetlerin tasarımını teşvik eden ilkeller sunarak, düşük düzeyli, protokolden türeyen sorunlara ilişkin kaygıları ortadan kaldırır.

Makul bir etkin bant genişliğine ulaşmak için, etkileşimde bulunan programların genellikle tam çift yönlü (full-duplex) biçimde çalışmasına izin vermek arzu edilir. Herhangi bir anda çoğu zaman önemli miktarlarda veri iletim halindedir. Bu durum, paralelliği devreye sokarak etkileşimle ilişkili sorunları büyütür. Etkileşim mekanizması, bu sorunları ele almanın yollarını sağlayacak şekilde yapılandırılabilir ve ayrıca paralellikten yararlanan sunucuların geliştirilebileceği bir temel oluşturabilir.

Bu sorunların birçoğu, en etkin hizmetler dışındakiler için dikkate alınmayı gerektirecek kadar karmaşıktır. Sonuç olarak, yukarıda belirtildiği gibi, hizmetler çoğu zaman işleyişlerindeki verimsizlikler yoluyla sorunlardan kaçınacak şekilde oluşturulur. Böyle hizmetler tarafından kullanılmak üzere bir etkileşim mekanizması ve ilkel işlemler sağlanması, tüm sorunları ayrıntılı biçimde ele alacak kaynaklara sahip olmayan basit hizmetler tarafından bile etkin etkileşimi teşvik edecektir.

VII. HİZMET GELİŞTİRME

Bir hizmeti uygulayan belirli programlar birden fazla kuruluş tarafından eşzamanlı olarak geliştirilirken ya da birçok dağıtık sahada bakım görürken, birbirinden farklı sunucuların uyumluluğuna ilişkin pek çok sorun ortaya çıkabilir.

Bu durum, bir hizmetin uygulanmasının ilk aşamasında olduğu kadar, sorunları gidermek veya hizmeti genişletmek amacıyla protokoller değiştirildiğinde de ortaya çıkar. Neredeyse her etkileşim protokolü, yeni yetenekler eklemek için zaman zaman değiştirilir. TELNET protokolü ve posta başlığı biçimleri buna iki özel örnektir.

Çoğu durumda, temel protokolde değişikliklerin görünmez bir biçimde uygulanmasını sağlayacak herhangi bir olanak yoktu. Bunun birkaç sonucu olmuştur.

Birincisi, ilgili bakım sorumlularının çoğunluğu değişikliklerle ilgilenmediği ve dolayısıyla ilgili programları değiştirmek için çaba göstermeye istekli olmadığı sürece bir protokolü değiştirmek çok zordur. Bu durum önceki örneklerde yaşanmıştır, çünkü herhangi bir değişiklik zorunlu olarak tüm sunucuları etkiler. Bu nedenle ilgili hizmetler sıklıkla durgunlaşır ve müşteriye görünürde basit bir iyileştirme sunmak bile uygunsuz derecede zor hale gelir.

İkincisi, protokoller çoğunluğun iradesiyle değiştiğinde, mevcut sunucular aniden karşı tarafın yeni bir dil konuştuğunu fark ettiklerinde çoğu zaman çalışmayı durdurur ya da düzensiz davranır. Bu durum, hizmet müşterileri için olduğu kadar, etkilenen çeşitli sahalardaki sunucuların bakımını yapanlar için de aynı derecede rahatsız edicidir.

Bu sorunlar, etkileşim protokollerinin dikkatli tasarımıyla kolayca önlenebilir ya da en azından önemli ölçüde azaltılabilir. Özellikle, etkileşim mekanizmasının kendisi, sorunu tamamen ortadan kaldıracak şekilde yapılandırılabilir ve geriye yalnızca belirli hizmet işlemleriyle ilişkili sorunlar bırakılabilir.

Etkileşim altyapısının kendisine ait mekanizmaların, mevcut sunucular için kesinlikle görünmez olacak bir biçimde iyileştirilebilmesi ya da genişletilebilmesi için etkileşim düzeni yapılandırılmalıdır.

1. Hiçbir sunucu, müşterileri için önemsiz olan bir değişikliği uygulamak zorunda bırakılmamalıdır.
2. Hiçbir sunucu, istekli bir ortakla etkileşime girerken yeni bir olanaktan yararlanması engellenmemelidir.
3. Yeni bir protokol olanağı kullanıma sunulduğunda hizmet hiçbir şekilde olumsuz etkilenmemelidir.

Tek bir hizmetin birçok sahada farklı sunucu programları tarafından sağlandığı durumlarda, çeşitli sahaların kendileri için uygun bir düzeyde katılım gösterebilmesi arzu edilir. Yeni bir sunucu programı, protokolün yalnızca basit mekanizmalarını kullanarak hızla katılabilmeli ve istenildiğinde daha gelişmiş, güçlü veya verimli etkileşime doğru evrilebilmelidir. Gelişmiş veya deneysel özelliklerden yararlanmak isteyen sahalara, bu özelliklerin başkaları tarafından da uygulanmasını zorunlu kılmadan bu imkân tanınmalıdır. Tersine, asgari düzeyde katılmak isteyen sahalar, başkalarının gelişmiş özellikleri kullanmasını engellememelidir. Tüm durumlarda, çeşitli sunucuların, her iki tarafça da desteklenen en yüksek düzeyde etkileşimi sürdürebilmesi gerekir.

Amaç, hem güvenilirliği hem de yukarı ve aşağı yönde uyumluluğu koruyan evrimsel bir sistemdir. Protokolün kendisi bu özelliklere sahip olmalı ve bu nitelikleri devralan hizmet etkileşim protokollerinin tanımlanabilmesi için mekanizmalar sağlamalıdır.

VIII. BİR ETKİLEŞİM MEKANİZMASININ YAPILANDIRILMASI

Daha önce sunulan nitelikler, belirtilen sorunlardan kaçınan hizmetlerin uygulanması için en azından bir başlangıç noktası sağlamalıdır. Bu belgenin geri kalanı, bir etkileşim mekanizmasının olası belirli bir mimarisine ilişkin konuları ele almaktadır.

Tasarım mimarisi, hizmete özgü uzlaşımları etkileşimin kendisine ait olanlardan ayırır. İstek-yanıt modelinin altyapısını gerçekleştiren bir etkileşim protokolü sağlanır ve veri hassasiyeti, eşzamanlama ve geliştirme sorunlarının ele alınmasını içerir. Bu protokol herhangi bir hizmete özgü değildir; bunun yerine, belirli bir hizmet protokolünün üzerine inşa edildiği, hizmet tarafından tasarlanan istekler ve yanıtlar biçiminde ilkel işlemler sunar.

Belirli bir hizmet için gerçek bir uygulama, etkileşim protokolünün kodunu hizmetin kendisiyle birleştirebilir ya da etkileşim protokolü, müşterisi uygulanmakta olan hizmet olan bir "hizmet" olarak sağlanabilir.

Bu tasarım mimarisinin hedefleri aşağıdadır.

1. İstek-yanıt disiplinini izleyen hizmetler tarafından kullanılacak genel bir etkileşim mekanizmasının sağlanması. Hizmetler, protokollerini bu mekanizmanın ilkel işlemlerini temel alarak tasarlayacaktır.
2. ETKİLEŞİM MEKANİZMASININ GENİŞLETİLEBİLİRLİĞİ. Etkileşim mekanizması, mevcut sunucuları etkilemeden, yalnızca yeni özellikleri kullanmak isteyenler için istenildiği gibi genişletilebilir.
3. SUNUCU GENİŞLETİLEBİLİRLİĞİ. Sunucular en temel ilkel işlemler kullanılarak uygulanabilir. Daha sonra, katı bir istek-yanıt yapısına özgü bazı verimsizlikleri ortadan kaldırmak amacıyla ek yeteneklerden yararlanacak şekilde genişletilebilirler.
4. HİZMET GENİŞLETİLEBİLİRLİĞİ. İlkel işlemler, yeni özellikleri kullanmak istemedikleri sürece mevcut sunucuları hiçbir şekilde etkilemeden bir hizmetin istenildiği gibi genişletilmesine olanak tanır.
5. SUNUCU UYUMLULUĞU. Belirli bir uygulamaya ait sunucular kümesi içinde, farklı karmaşıklık düzeylerinde çalışan farklı sunuculara sahip olmak ve yine de herhangi iki sunucunun başarılı biçimde etkileşime girebilme yeteneğini korumak mümkündür.

Bu hedefler iki temel tasarım alanını içerir. Birincisi, etkileşim mekanizmasının kendisi bu hedefleri karşılayacak şekilde tasarlanır. İkincisi ise, belirli hizmet protokollerinin, hedefleri karşılamak için gerekli nitelikleri devralabilmesi adına yapısına ilişkin kılavuzların gerekli olmasıdır.

IX. SORUNUN BÖLÜMLERE AYRILMASI

Etkileşim mekanizmasının kendisi tanımlanırken, sorun iki ayrı ilgi alanı ayrı ayrı ele alınarak basitleştirilebilir.

1. Kanal tarafından iletilen verinin özellikleri ve biçimi tanımlanabilir.
2. Etkileşimi tanımlamak için kullanılan uzlaşımlar, kanal tarafından desteklenen mevcut veri açısından tanımlanabilir.

Bu belge kapsamında, kanalın veri repertuarı ve özelliklerinin [Referans 3]'te açıklandığı ve bir ekte özetlendiği varsayılmaktadır. Sunucular arasındaki etkileşime ilişkin tartışmalar, yalnızca ilkel ve anlamsal veri öğelerinin soyut kavramlarını kullanacak, böylece etkileşim konularını veri biçimleri ve iletişim ayrıntılarından yalıtarak sorunu basitleştirecektir.

Ayrıca, burada sunulan fikirleri izleyen bir mekanizmanın gerçek uygulaması modüler bir biçimde gerçekleştirilebilir; kanalın kendisiyle ilgili kod, etkileşim davranışıyla ilgili koddan ayrıştırılabilir.

Etkileşim mekanizması, hizmet tasarımcısına, yine mevcut veri öğeleri cinsinden tanımlanmış ilkel işlemler sunar. Hizmet tasarımcıları, zorunlu olmamakla birlikte, etkileşimleri yalnızca bu veriler cinsinden tanımlamaya teşvik edilir.

X. İLKEL İŞLEMLER

Etkileşim mekanizması, iki sunucu arasında bir kanalın [Referans 3] var olduğunu varsayar. Etkileşimi gerçekleştirmek için iki yeni anlamsal veri türü tanımlanır. Bunlar, şaşırtıcı olmayan bir şekilde, CONTROL REQUEST ve CONTROL REPLY olarak adlandırılır. Bu veri öğelerinin her biri en az iki unsur içerir.

1. TYPE öğesi, belirli bir istek veya yanıt türünü tanımlar.
2. SEQUENCE öğesi, yanıtları karşılık gelen isteklerle eşleştirmek için kullanılır.

Başka öğeler de bulunabilir. Bunların yorumlanması, yer aldıkları istek veya yanıtın belirli türüne bağlıdır.

Etkileşim protokolünün kendisi, denetim istekleri ve denetim yanıtları cinsinden tanımlanır. Asgari uygulama düzeyi olarak çok az sayıda istek ve yanıt türü tanımlanır. Daha gelişmiş sunucular tarafından kullanılmak üzere, hizmete ek yetenekler kazandırmak ya da yalnızca işletim verimliliğini artırmak amacıyla ek istek ve yanıt türleri de tanımlanır.

İki ek veri öğesi daha tanımlanır; bunlara USER REQUEST ve USER REPLY adı verilir. Bunlar, istekler ve yanıtlar gibi yapılandırılmıştır, ancak çeşitli türler, hizmetin işleyişinde ihtiyaç duyduğu ilkel işlemleri uygulamak üzere hizmetin kendisi tarafından tanımlanır.

Denetim ve kullanıcı istekleri ile yanıtları, genel olarak yalnızca REQUEST ve REPLY olarak anılır.

Etkileşim protokolü, istek-yanıt modelinin temelini oluşturan ve daha önce belirtilen hedefleri karşılamaya çalışan birkaç özelliğe sahiptir.

1. Her istek bir yanıt doğurur.
2. Her yanıt, önceki bir istekle açık biçimde ilişkilidir.
3. Her sunucu, karşı taraftan daha fazla veri beklenip beklenmediği gibi etkileşimin durumunu her zaman bilir.
4. Protokol tanımı, her istek için olası yanıtların numaralandırılmasını içerir. Hizmet protokolleri de kullanıcı istekleri ve kullanıcı yanıtları için aynı yaklaşımı izlemeye teşvik edilir.
5. Bilinmeyen türde istek alan sunucular, isteği fiilen reddeden bir yanıt verir. Bir protokolün gelişmiş özelliklerini kullanmaya çalışan sunucular, önceki hizmet düzeyini korumak için mümkün olduğunda isteklerini daha basit terimlerle "yeniden ifade eder".

Asgari uygulama, etkileşimi neredeyse tamamen istek-yanıt disiplini doğrultusunda destekler.

Asgari yapılandırmaya yönelik genişletmeler iki nedenle tanımlanır. Birincisi, katı istek-yanıt disiplini modeli, içerdiği gecikmeler nedeniyle yüksek hacimli durumlarda verimsizdir. Bu sorunu ele almak için çeşitli genişletmeler tanımlanır. Dolayısıyla, etkileşim böyle bir disipline dayansa da, etkileşimi mutlaka bu biçimde uygulamak zorunda değildir. İkincisi, hizmetler tarafından kullanılmak üzere bazı standart süreç eşzamanlama işlemleri sağlayan ek ilkel işlemler tanımlanır.

Burada sunulan protokol mimarisi, ilişkili bir belgede [Referans 4] ayrıntılı olarak tanımlanmıştır.

Ek I — Kanal

Aşağıdaki tartışma, daha fazla ayrıntı için başvurulması gereken [Referans 3]'te sunulan fikirlerin bir özetidir.

İki sunucu arasındaki iletişim bağlantısı KANAL olarak adlandırılır. Kanallar çift yönlü iletişim yetenekleri sağlar ve genellikle tam çift yönlüdür. İlgili programlar, kendi uygulama gereksinimlerine göre, bir tür başlangıç bağlantı protokolü kullanarak kanalı kurar.

Kanal, sunucular arasında bir arayüz görevi görür. INTEGER, STRING, FILE PATH NAME gibi, anlamları ilgili programcılar tarafından bilinen soyut veri öğelerini taşır. Kanalın kullanıcıları birbirinden farklı bilgisayar ortamlarında çalışabileceğinden, iletişim yalnızca bu tür soyut veri öğeleri cinsinden tanımlanır; bunlar kanalda taşınan bilginin atomik birimleridir. Her sahada kanalı uygulayan program, veriyi, ilgili iletişim bağlantısına uygun bir kodlanmış iletim biçimi ile bilgisayarın kendisinde uygun olan iç temsil biçimi arasında dönüştürür.

Kanal protokolü, ilgili hizmet için anlamsal değeri olan çeşitli veri öğesi türlerinin tanımlanmasına yönelik bir mekanizma sağlar; örneğin, kullanıcı adı, küme, hece, cümle ve belirli hizmet için ilgi çekici diğer veri öğeleri. Kanal, bu tür kullanıcı tanımlı verilerin ana bilgisayardan ana bilgisayara taşınması için bir mekanizma sunar.

Kanal, farklı koşullarda kullanılacak bir veya daha fazla ayrı kodlama mekanizmasıyla gerçekte uygulanabilir. Başlangıçta, kanal altyapısı MSDTP [Referans 3] gibi tek bir mekanizmaya dayanan ilkel bir olanak sağlayacaktır.

Bu mekanizma, gerçek hat tipi ağ bağlantılarının varlığına bağlı değildir; bağlantı odaklı mimarilerin aksine, ileti-odaklı bir iletişim mimarisi gibi başka ortamlarda da çalışacaktır ve aslında böyle bir ortam için daha doğal biçimde yapılandırılmıştır.

XI. KAYNAKLAR

1. Network Information Center, ARPANET Protocol Handbook, Nisan 1976.
2. Broos, Haverty, Vezza, Message Services Protocol Proposal, Aralık 1975.
3. Haverty, Jack, Message Services Data Transfer Protocol, NWG RFC 713, NIC 34729, Nisan 1976.
4. Haverty, Jack, RRP, A Process Communication Protocol for Request-Reply Disciplines, NWG RFC 723, NIC 36807, (yayınlanacak).