Web Servis Tabanlı Olay Bildirim Özeliklerinin Karşılaştırmalı Bir İncelemesi

Web Servis Tabanlı Olay Bildirim Özeliklerinin Karşılaştırmalı Bir İncelemesi

Özet

Web servis tabanlı olay bildirimi, olay bildirim mekanizmalarının zaman uyumsuz iletişim özelliğini ve Web hizmetleri teknolojilerinin birlikte çalışabilirliği özelliklerini birleştiren yeni bir teknolojidir. Web servislerine dayalı olay bildirim sistemleri, servis odaklı Grid hesaplama için önemli bileşenlerdir. WS-Eventing ve WS-Notification, bu sistemler için iki önemli rekabet mekanismasıdır. Bu yazı, bu mekanizmaların karşılaştırmalı bir çalışmasıdır. Bu araştırmanın odak noktaları, bu iki spesifikasyon arasındaki benzerlikleri ve farklılıkları tanımlamak ve önceki spesifikasyonlardan evrimsel yollarını belirlemek üzerine odaklanıyor. Web hizmetleri tabanlı olay bildirim teknolojisinin olgunluğu için iyi olan geliştirme süreci boyunca rakip Web hizmetleri özelliklerinin birbirinden fikir ve kavramlar aldığını bulduk. Ayrıca, daha önceki etkinlik bildirim sistemlerinden Web servislerine dayalı etkinlik bildirim sistemlerine kadar birçok önemli değişiklik tespit ettik. Sonunda WS-Eventing ve WS-Bildirim özelliklerini destekleyen WS-Messenger projemizi sunmaya çalışacağız.

I.GİRİŞ

Olay bildirim sistemleri, dağıtılmış sistemlerde farklı varlıklar arasında asenkron iletişim sağlar. Web hizmetleri (WS) teknolojileri, heterojen dağıtılmış sistemlerde birlikte çalışabilirlik sorunlarını ele alır. Web hizmetleri tabanlı (WS tabanlı) olay bildirim sistemleri, her ikisinin özelliklerini birleştirir. Bir servis odaklı mimari (SOA) geliştirdiği için bunlar Grid hesaplamanın temel bileşenleri arasındadır. Olay bildirimleri, günlüğe kaydetme, izleme ve denetleme gibi Grid hesaplama uygulamalarında çeşitli amaçlarla dağıtılır. Olası olaylar, hesaplama sonuçları, durum güncellemeleri, hatalar, istisnalar ve benzeri olayları içerir.

WS tabanlı sistemler için standart işlemler ve mesaj formatlarını tanımlamak için çok sayıda rakip özellikler belirtilmiştir. İki önemli rekabet özellikleri arasında Web Hizmetleri Olaylama (WS Eventing) özelliği [1] ve Web Hizmetleri Bildirimi (WS Notification) özellikleri [2-4] bulunur. Bunlar birbirleriyle uyumsuzdurlar. Ortaya çıkmadan önce, CORBA bildirim hizmeti özelliği [5], Java Mesaj Hizmeti (JMS) özelliği [6] ve Açık Grid Hizmetleri Altyapısı’ndaki bildirim özelliği de dahil olmak üzere olay bildirim sistemleri için birkaç başka özellik belirtildi (OGSI) [7]. Aynı zamanda, birlikte işlerlik uyumu sağlamak için olay bildirim sistemleri için arabirimleri tanımlarlar.

WS-Eventing ve WS-Notification özellikleri, [9] da açıklandığı gibi Open Grid Services Architecture (OGSA) [8] ‘in kurulması için kullanılabilir. Bu iki WS tabanlı olay bildirimi özelliği arasındaki farklar nelerdir? Önceki olay bildirim özellikleriyle hangi sorunlar giderilemedi? Bu soruları cevaplamak için, WS-Eventing ve WS-Notification özellikleri arasında WS-Messenger projesindeki deneyimlerimize dayanarak kapsamlı bir karşılaştırmalı çalışma yaptık [10]. Ayrıca, bu iki spesifikasyonun farklı sürümlerini karşılaştırdık ve olay bildirim sistemlerinin evrimsel eğilimlerini bulmak için bunları önceki önemli olay bildirim özellikleriyle karşılaştırdık. Bu yazıda, araştırma sonuçlarımızı sunacağız.

ÇALIŞMA İLE İLGİLİ

[11-13] gibi olay bildirim sistemleri hakkında birçok kaynak mevcuttur. Etkinlik bildirim sistemlerinin farklı projeleri ve mimarilerini tartıştılar. Spesifikasyonlar birden fazla özellik tarafından desteklendiğinden ve olay bildirim sistemlerinin evriminin temsilcileri oldukları için, araştırmamızı büyük spesifikasyonların evrimi üzerine odaklıyoruz.

WS-Eventing ve WS-Bildirim özellikleri, asenkron Web hizmetleri için çok önemli olduğu için çok dikkat gösterdi. Birçok haber makalesi her iki spesifikasyon hakkında da konuştu. Bununla birlikte, bunlar kapsamlı ve ayrıntılı değildir. [14, 15] her bir spesifikasyonu ayrı ayrı tartışıldı. Kısa bir bildiri [16], WS-Eventing’i ve WS Bildiriminin eski sürümünü karşılaştırır. Bununla birlikte, karşılaştırmada WS Bildiriminin eski sürümünde gerekli olan WS-Resource Framework (WSRF) ‘ni tam olarak dikkate almaz ve WS Bildirim’in aboneliği iptal edemediği ve abonelik bildirimlerini gönderemediği uygunsuz sonuçlara ulaşır. Çalışmamız önceki çabalardan farklı olarak aşağıdaki yönlerden farklılık göstermektedir:

• Her iki spesifikasyonun da en yeni sürümlerine dayanmaktadır. WS Bildirim 1.3 sürümünde önemli güncellemeler yaptı. WSRF’ye artık bağımlı değildir ve WS-Eventing’de önceden mevcut olan, örneğin çekme dağıtım mekanizması gibi işlevleri içerir.
• Bu iki özellik arasında kapsamlı bir karşılaştırmadır. Çalışmamız bu iki spesifikasyonun temel işlevlerine odaklanıyor ve karşılaştırmalarımızda yan yana tablolar ve grafikler sunuyor.
• Çalışmamız, bu iki spesifikasyonu tarihi bağlam içinde yerleştirir ve bunları önceki olay bildirimleri ile karşılaştırır. Bu, olay bildirim sistemlerinin evrimini anlamamıza yardımcı olur. Ayrıca, bu iki WS temelli olay bildirim spesifikasyonunun farklı sürümlerini karşılaştırdık ve bu iki spesifikasyonun birbirlerinden öğrenildiğini ve bir yakınsama eğilimi gösterdiğini bulduk.
• Karşılaştırmalarımız, her iki spesifikasyonun uygulanmasında elde ettiğimiz deneyimlerimize dayanmaktadır; böylece, bu iki unsur arasındaki ayrıntılı farklılıkları tespit edebiliyoruz (örneğin, elemanı çevreleyen subscriptionID ile arasındaki fark). WS-Messenger projemiz her iki spesifikasyonu da uygular ve arabuluculuk yapabilir.

Bu yazının geri kalan kısmı aşağıdaki şekilde organize edilmiştir: bölüm III, WS tabanlı olay bildirim sistemlerini ve ilgili spesifikasyonları kısaca tanıtmaktadır. Bölüm IV, WS-Eventing teknik özelliklerinin ve WS-Bildirim özelliklerinin farklı sürümlerinde yapılan önemli değişiklikleri anlatmaktadır. Bölüm V, bu iki spesifikasyonun en son sürümünü karşılaştırır. VI. Bölümde, olay bildirim sistemlerinin evrimsel eğilimlerini önceki olay bildirim özellikleriyle karşılaştırarak analiz edeceğiz. Daha sonra WS-Messenger projemizi VII. Bölümde ve sonuçlarımızı Bölüm VIII’de sunacağız.

III. WEB SERVİS TABANLI OLAY BİLDİRİMİ

Yayın / Abone paradigması [11] dağıtılmış sistemlerde olay yaygınlaştırma için pratik bir modeldir. Bu paradigmada bir abone, bir veya daha fazla aboneye gönderilecek belirli olay türlerine abone olur. Bir olay üreticisi olayları yayınlar. Olaylar, aboneliklere dayalı olarak tüketicilere iletilir. Etkinlik üreticilerini ve etkinlik tüketicilerini ayırmak için bildirim brokerları yayın / abone sistemlerine eklenebilir. Esneklik ve ölçeklenebilirlik sağlar.

Web hizmetleri, heterojen uygulamaları İnternet’te bütünleştirebilir. Bunlar, açık ve yaygın kabul gören bir dizi İnternet standardına dayanıyor. Web hizmetleri teknolojilerinin özellikleri, platformdan bağımsız, programlama dilinden bağımsız ve taşımadan bağımsızdır. Web hizmeti mesajları, esnek ve kolay genişletilebilir bir veri formatını tanımlayan ve neredeyse her platformda desteklenen [18] XML standardını takip etmektedir [18]. XML iletileri SOAP [19] zarfları içinde kapsüllenmiştir. Web Service Description Language (WSDL) [20], Web servislerinin birlikte çalışabilirlik özelliğini etkinleştirmek için mesaj alışverişi için geçerli XML doküman yapılarını tanımlar. Web servis mesajları çeşitli aktarım mekanizmaları kullanılarak taşınabilir. SOAP iletileri oluşturulabilir. Güvenlik, güvenilirlik ve işlem gibi özellikler iletilere, WS-Security [21] gibi ilgili özellikleri kullanarak eklenebilir.

WS tabanlı olay bildirim sistemleri, olay bildirimlerini iletmek ve abonelikleri yönetmek için Web hizmeti teknolojisini kullanır. Bir abone, bir olay üreticisi Web hizmetine SOAP biçimlendirilmiş bir abonelik isteği iletisi gönderir ve belirli türde bildirim iletilerinin bir veya daha fazla olay tüketici Web hizmetine teslim edilmesini ister. Olaylar bir serviste yaratıldığında, diğer servisler SOAP mesaj biçiminde bildirim mesajları alabilir. Olay tüketici Web servislerinin yerleri WS-Adresleme belirtimi [22] kullanılarak belirtilir. Bildirim mesajları aracı yoluyla taşınabilir ve çeşitli ulaşım mekanizmaları kullanılabilir.

WS tabanlı bildirimlerin farklı sağlayıcıları arasında birlikte çalışabilirlik sağlamak için satıcıların, bildirim dağıtımı ve abonelik oluşturma ve yönetimi için ileti biçimleri ve Web hizmeti arayüzlerini tanımlayan bir standart üzerinde anlaşmaları gerekir. İdeal olarak, tüm tedarikçiler tarafından kabul edilen tek bir standart olmasını isteriz. Bununla birlikte, bu alanda üç benzer özellik önerilmiştir: WS-Events [23], WS-Eventing [1] ve WS-Notification [2-4]. WS-Events en eskisidir. 2003 yılının ortalarında HP tarafından oluşturulmuştur. HP, başkalarına katıldı ve WS-Events’in yerini alan WS-Notification’ı önerdi.

WS-Eventing

Web Hizmetleri Olay Sıralaması (WS-Eventing) belirtimi [1], iki yayımlanmış sürüm olan 1/2004 ve 8/2004 sürümlerine sahiptir. İlk sürüm Microsoft tarafından yönetilen 7 Ocak 2004’te yayımlandı. İkinci sürüm Ağustos 2004’te piyasaya sürüldü. Daha kapsamlı satıcı desteği aldı. IBM, Sun ve CA destekçilere bu sürüme için katıldı.

WS-Notification

Web Hizmetleri Bildirimi (WS Notification) belirtimi ilk önce 20 Ocak 2004’te IBM ve Globus İttifakı tarafından başlatılmıştır. Üç  özellikteki bir aileye ve Mart 2004’te bir beyaz sayfaya dönüştürüldü. Bu üç özellik: Web Hizmetleri Tabanı Bildirimi (WS-BaseNotification) belirtimi [2], Web Hizmetleri Aracı Bildirimi (WS-BrokeredNotification) belirtimi [3] ] Ve Web Hizmetleri Konuları (WS-Topics) sürümü [4]. WS-BaseNotification bildirim üreticileri ve bildirim tüketicileri arasındaki temel etkileşimleri tanımlar. WS-BrokeredNotification, bildirim brokerleri için arabirimleri tanımlar. WS-Topic hiyerarşik bir konu alanı tanımlar. WS Bildirim ailesi, Nisan 2004’te standart organizasyon olan OASIS’e [24] sunulmuştur. Globus araç kiti 4.0 [25], WS-BaseNotification’ı uygular.

WS-BaseNotification, mimaride ve işlevlerde WS-Eventing’e çok benzer. Şimdiye kadar 3 büyük versiyona, 1.0, 1.2 ve 1.3’e sahip. Sürüm 1.0 Mart 2004’te ilk WS Bildirim Özelliğini yeniden yapılandırarak yayımlandı. Sürüm 1.2, OASIS’e gönderilen sürümü, 1.0 sürümüne çok benzemektedir. Sürüm 1.3’ün önceki sürümlerden bazı önemli değişiklikler var. Bu yazı hazırlanırken (2/2006) ikinci kamu eleştirisini tamamladı.

WS Bildirim ailesi WS-Resource çerçevesi (WSRF) ile birlikte serbest bırakıldı. Her ikisi de Grid hesaplama topluluğu tarafından geliştirildi. WSRF, Web hizmetleri standartlarıyla Grid hesaplama kaynaklarını yönetmek üzere tasarlanmış bir çerçevedir. OGSI [7] spesifikasyonunun yerine geçer. Sürüm 1.3’den önce, WS Bildirim ve WSRF birbirine bağımlıdır. WS-Bildirimi belirtiminin 1.3 sürümünde, WSRF isteğe bağlı hale gelir.

WS EVENTİNG VE WS-NOTİFİCATİON ÖZELLİKLERİNİN FARKLI VERSİYONLARININ KARŞILAŞTIRILMASI

Bu bölümde, WS-Eventing belirtiminin ve WS-BaseNotification belirtiminin Version 1.0 ve 1.3’ün mevcut iki sürümünü karşılaştıracağız. biz WS-BaseNotification sürüm 1.2’yi işlemeyeceğiz çünkü sürüm 1.0’a çok benzer. Bu karşılaştırmada bulduğumuz ilginç bir gözlem, bu iki özellik birbiriyle yarışıyor olmasına rağmen her bir sürüm güncellemesiyle birbirlerine yakınlaşıyor.

WS-Bildirimi üç spesifikasyona dönüştürüldüğünde ilk yakınsama gerçekleşti. WS-BaseNotification, WS-Eventing’e çok benzer tek bir belirtim olarak ayrılır.

İkinci yakınsama WS-Eventing Ağustos 2004’te güncellendiğinde oldu. (1) Mimari açıdan bakıldığında, WS-Bildiriminin ardından “olay kaynağı” ndan “abonelik yöneticisi” ve “abone” nin “olay havuzundan” ayrıldığını görüyoruz. (2) Ayrıca WS-Notification’in abonelikleri abonelik yöneticileri için kaynak olarak değerlendirmeye yönelik yaklaşımını benimsedi. Ayrı öğeler kullanmak yerine, subscriptionId değerleri, abonelik yöneticilerinin Web hizmetleri adreslerinde regerans parametreleri olarak döndürüldü. (3) Abonelik durumlarını sorgulamak için yeni bir “getStatus” işlemi eklendi. Bu, WSRF’deki getResourceProperties işlemine benzer. (4) Yeni sürüm WS-BaseNotification’da tanımlanan sarılmış bir ileti teslim modunu destekleme olanağını da ekliyor. Bununla birlikte, paketlenmiş bildirim iletilerinin ileti biçimlerini belirtmez. (5) Çekme modu, güvenlik duvarlarının arkasındaki tüketicilere mesajlar dağıtma gibi birçok senaryo için önemli olan bu yeni sürümde eklenmiştir. Hiçbir şartnamenin ilk sürümü çekme dağıtım modunu tanımlamıştır.

Üçüncü yakınsama, WS-BaseNotification’ın önerilen 1.3 versiyonunda devam ediyor. Çekme dağıtımı modu, mutlak zaman yerine süreyi kullanarak abonelik sona erme tarihini belirleme seçeneği ve XPath tabanlı abonelik lehçesi [26] da dahil olmak üzere WS-Eventing’de önceden tanımlanmış çeşitli işlevleri benimser. Önemli bir değişiklik, WSRF’yi “yenileme” ve “Aboneliği iptal etme” işlemlerini sunarak isteğe bağlı hale getirmesi. Ayrıca, konu tabanlı abonelik artık gerekli değildir.

Tablo 1’in üst kısmındaki vurgulanan hücreler, yukarıda bahsedilen gelişmeleri özetlemektedir. Rakip özelliklere sahip olmakla birlikte çalışabilirlik sorunlarına neden olsa da, karşılaştırmalardan görebildiğimiz iyi nokta, bu iki spesifikasyonun kendi eksikliklerini telafi etmek için birbirlerinden fikir almasıdır. Mimari varlıklar ve işlevler her güncelleme ile eklenir, kaldırılır veya değiştirilir. Bu rakip özelliklere sahip olmanın bir yararıdır. WS tabanlı olay bildirim teknolojisinin olgunluğu için uzun vadede iyidir.

Tablo 1. WS-Eventing (WSE) ve WS-Bildirim (WSN) özelliklerinin farklı sürümleri arasındaki karşılaştırmalar.

Ayrıca, tablo 1’in alt kısmındaki vurgulanan hücrelerden bu iki özellikte hala mimaride ve işlevlerde bazı boşluklar olduğunu görebiliriz. Bir sonraki bölümde daha fazla çalışacağız.

WS-Eventing VE WS Notification ARASINDAKİ KARŞILAŞTIRMALAR

Bu bölümde, WS-Eventing’in (2004/08 sürümü) ve WS-Bildiriminin (sürüm 1.3, Public Review Draft 2’nin) en son sürümlerini, mimari, işlevler, ileti gönderme, ileti biçimleri ve komisyoncu destekleri gibi farklı perspektiflerden karşılaştıracağız. .

Genel olarak WS-Eventing, WS-Notification’dan daha kolaydır;WS-Bildirimi, WS-Eventing’den daha fazla özelliklere sahiptir ve tam teşekküllü bildirim sistemlerinde kullanılabilir. Web hizmetleri özellikleri hazırlanabilir olduğundan, hem WS-Eventing hem de WS-Notification sadece anahtar yayın / abone ile ilgili işlevleri tanımlar. Güvenlik, güvenilirlik ve işlem yönetimi gibi diğer işlevler, diğer WS- * belirtimlerine bağlıdır. Örneğin, mesajların güvenli bir şekilde iletilmesini sağlamak için WS-Security [21] kullanılabilir.

Mimari karşılaştırması

WS-Eventing ve WS-BaseNotification hemen hemen aynı WS-tabanlı mimarilere sahiptir. Her ikisi de Yayımla / Abone Ol paradigmasını izliyorlar. Her ikisi de abone ve abonelik yöneticisi varlıklarını tanımlarlar. WS-Eventing’de tanımlanan olay havuzu, WS-BaseNotification’da tanımlanan bildirim tüketici ile karşılaştırılabilir. Her iki spesifikasyonda da, aboneler bildirim tüketicilerinden ayrılmışlardır, böylece bildirim alanındaki tüketicilerin yalnızca alınan mesajları işleyebilmesi gerekecektir. Aracılık yerlerini bilmeleri ve abonelikler oluşturmaları gerekmez. WS-Eventing, yayıncıyı olay kaynağından ayırmaz. WS-Eventing’deki Olay kaynağı WS-BaseNotification’da tanımlanan hem bildirim üreticisi hem de yayıncı işlevlerine sahiptir. Şekil 1 ve Şekil 2, WS-Eventing ve WS-BaseNotification’da tanımlanan varlıkları ve bunların etkileşimlerini gösterir. Kalın çizgiler, Web hizmetleri arayüzlerini belirtir.

Şekil. 1-  WS-Eventing Mimarisi ve İşlemleri

Şekil 2-  WS-BaseNotification Mimarisi ve İşlemleri

İşlev Karşılaştırması

Ayrıca, WS-BaseNotification ve WS-Eventing fonksiyonlarında birçok benzerlik bulabilirsiniz. WS-Eventing, beş Web hizmeti operasyonunu tanımlar: Abone Ol, Yenile, GetStatus, Aboneliği İptal Et ve AbonelikEnd. “Abone Ol” mesajı, bir etkinlik havuzuna abonelik oluşturmak için kullanılır. Abone yöneticilerinden “Yenile”, “GetStatus” ve “Abone Olmama” mesajları mevcut abonelikleri yönetmek için gönderilir. Bir olay kaynağı bir aboneliği beklenmedik şekilde sonlandıracağında “SubscriptionEnd” iletisi oluşturulur.

Abonelik talebinde belirtilen bir adrese gönderilir. Bu adres abonelik talebinde gösterilmezse, bu “AbonelikEndi” mesajı oluşturulmaz.

Tablo 2: İşlev Karşılaştırması

WS-BaseNotification, yukarıdaki beş operasyon için karşılaştırılabilir işlemlere sahiptir. GetStatus ve SubscriptionEnd işlemlerini tanımlamasa da WS-Bildirimi abonelikleri WSRF’de WS-Kaynakları olarak görebildiğinden, bu işlemler isteğe bağlı WS-ResourceFramework (WSRF) ile sağlanabilir. Tablo 2 WS-BaseNotification’ın WS-Eventing’de tanımlanan 5 fonksiyonu nasıl elde ettiğini göstermektedir. WS-Notification, bu beş operasyonun yanı sıra WS-Eventing’den üç operasyon daha tanımlıyor. Bir aboneliği duraklatma ve devam ettirmeyi ve geçerli mesajın nasıl alınacağını (getCurrentMessage) tanımlar.

Mesaj İletim Karşılaştırması

Bu bölümde WS-Eventing ve WS-Notification abonelik taleplerinde mesaj dağıtımının nasıl belirtileceğini ayrıntılı olarak karşılaştıracağız.

Teslim modu: Hem WS-Eventing hem de WS-Bildirimi, bildirim iletileri sağlamak için “push”, “pull” ve “wrapped” modlarını kullanabilir. “Sarılmış(wrapped)” mod, etkin dağıtım için birkaç bildirim mesajını tek bir mesaj içine paketleyebilir. WS-Eventing “push” modunu varsayılan dağıtım modu olarak tanımlar. Diğer dağıtım modlarını desteklemek için bir abonelik mesajındaki “Teslim” uzantı noktasını kullanır. Bildirim mesajı formatları şartnamede tanımlanmamıştır. WS-Bildirimi bir “PullPoint” arabirimini tanımlar, ancak bir abonelik mesajında “çekme” teslim modunu kullanarak belirtemezsiniz. Bir abonelik oluşturmadan önce bir çekme düğmesi oluşturulmalı ve bir yayıncının geleceğinden düzenli bir “push” olayı tüketici olarak kabul edilmelidir.

Filtre: WS Bildirim, üç tür ileti filtresi tanımlar: TopicExpression, ProducerProperties ve MessageContent. Bir abone bu filtrelerin herhangi birini veya tümünü kullanabilir. WS-Eventing, abonelik taleplerinde en fazla bir filtre sağlar. Varsayılan filtre, XPath ifadeleri kullanan, içerik tabanlı bir süzgeçtir. Her iki belirtim de, bir Boolean değerini bir filtreleme ölçütü olarak değerlendiren belirli bir diyalogdaki herhangi bir ifadeyi (xsd: any) kullanabilir. WS-Eventing, yayıncıların ProducerProperties’lerini kullanarak iletileri filtrelemek için bir yol belirtmez.

İleti kapsülleme: WS Bildirim, bildirim iletileri göndermenin iki yolunu tanımlar. Birinci yol, bildirim mesajı içeriğini bir “Bildirim” mesajı öğesine sarmak ve WS-Bildirimi tarafından tanımlanan bilgileri (Konu gibi) eklemektir. İkinci yol, sadece bir “öz bildirim” ileti içeriğini bir SOAP iletisinin gövdesine göndermektir. WS-Eventing sadece ham mesaj yaklaşımını kullanır.

• Mesaj Biçimleri karşılaştırması

Web hizmetleri özellikleri, istek ve yanıt mesajlarını kapsüllemek için SOAP ileti biçimlerini tanımlar. WS-Eventing ve WS-Bildirimleri iki farklı özellik olduğundan, ileti biçimleri farklıdır. İstek ve yanıt SOAP iletilerini karşılık gelen işlemlerde (örneğin abone işlemi) karşılaştırırken birçok farklılık var. Farklılıklar aşağıdaki kategorilerde özetlenebilir:

• Öğe adları veya öznitelik adı farkları: Aynı içeriğin öğe adları veya öznitelik adları farklıdır. Örneğin WS-Eventing, WS-Addressing’te tanımlanan ReferenceParameters öğesini kullanarak bir abonelik yanıt mesajında subscriptionID değerini, WS-BaseNotification bunu WS-Addressing’de tanımlanan ReferenceProperties öğesinde kapsar.
• Alanadı farkı: Bu iki spesifikasyonun alan adları ve spesifikasyonlarda kullanılan bazı alan adları, WS-Addressing alan adı gibi farklıdır.
• Temel özelliklerin sürüm farkı: Bu iki spesifikasyonda kullanılan WS-Addressing sürümleri farklıdır. WS-Bildirimi sürüm 1.3, 2005/08 sürümünü kullanırken, WS-Etkinliği 2004/08 sürümünü kullanır.
• İleti içeriği farkı: Özellikler, SOAP iletilerindeki belirli XML öğeleri için farklı gerekli değerleri tanımlar. Örneğin, SOAP üstbilgilerinin WS-Addressing bölümündeki “action” öğeleri için farklı özellikler tarafından farklı değerler gereklidir.
• SOAP ileti yapıları farkı: Farklı özellikler, farklı SOAP ailetilerindeki XML ileti yapılarını tanımlar. Örneğin, sarılmış bir WSN bildirim iletisi, ileti yükünü yine bir Bildirim öğesinde bulunan bir NotificationMessage öğesinde kapsar. WSE bildirim iletilerinin böyle yapılara gereksinimi yoktur.
• İçerik konum farkı: Aynı anlamsal bilgi, SOAP iletilerindeki farklı konumlarda görünebilir. Örneğin, sarılı bir WS Bildirimi bildirim iletisi, bir WSE bildirim iletisinin SOAP üstbilgisine gerektiğinde yerleştirilmesi gerektiğinde SOAP gövdesinde bir konu öğesi gerektirir.
• Broker Destek Karşılaştırması

WS Bildirim Ağı’ndaki WS-BrokeredNotification belirtimi, bildirim üreticileri ve bildirim tüketicileri arasındaki aracı desteklerini tanımlar. WS-BaseNotification belirtiminin uzantısıdır. Bildirim komisyoncuları, yayıncı kayıtlarını halledebilir ve talep temelli yayıncıları destekleyebilir. Talep tabanlı bir yayıncı, bu mesajlarla ilgilenen tüketiciler olduğunda mesajları yayınlar. Bir bildirim komisyoncusu, her tür mesaj için tüketicilerin sayısını takip edebilir ve talebe dayanarak yayıncılara aboneliklerini duraklatabilir veya devam ettirebilir. WS-Eventing, eventSink ve evnetSource arasında aracı olarak aracı nasıl kullanılacağını tanımlamaz. Bununla birlikte, eventSink arabirimini ve eventSource arabirimini uygulayan bir komisyoncu oluşturmak mümkündür. WS-Eventing’de yayıncı kayıtları veya talep odaklı yayıncılar tanımlanmamıştır.

OLAY BİLDİRİM ÖZELLİKLERİNDEN ÖNCE

WS tabanlı olay bildirim özelliklerinden önce birkaç farklı spesifikasyon, dağıtılmış sistemlerde olay bildirimlerini göndermenin standart bir yolunu tanımlamaya çalışmıştır. WS- Etkinlik ve WS Bildirim özellikleri önceki spesifikasyonlarla çok benzerlik göstermektedir. Ancak, XML biçimi ve XPath filtresi gibi önceki spesifikasyonların kapsamadığı bazı benzersiz sorunları da ele alıyorlar. Bu bölümde, bu iki WS temelli etkinlik bildiriminin duyurulmasından önce önemli olay bildirim teknik özelliklerinin bir incelemesi sunulacak ve bu iki yeni özellikle karşılaştırılacaktır. Karşılaştırmalar, her spesifikasyonun en yeni sürümlerine dayanmaktadır.

CORBA Olay hizmeti belirtimi ve Bildirim hizmeti belirtimi

Ortak Nesne İstek Aracısı Mimarisi (CORBA) [27] spesifikasyonu, 700’den fazla üye firmanın bir konsorsiyumu olan Nesne Yönetimi Grubu (OMG) tarafından geliştirildi. CORBA, dil, işletim sistemi ve satıcıdan bağımsız olarak tasarlanmıştır. Farklı programlama dilleri için ortak arayüzleri tanımlar ve farklı programların Nesne İstek Aracısı (ORB) aracılığıyla iletişim kurmasını sağlar. CORBA, intranet iletişimi için Genel Inter-ORB Protokolü’nü (GIOP) ve ınternet iletişimleri için Internet Inter-ORB Protokolünü (IIOP) kullanır. IIOP, GIOP’un istek ve cevaplarını, her bir bilgisayardaki İnternet’in TCP katmanına eşleştirir. Mesaj yükü, Ortak Veri Gösterimi (CDR) olarak bilinen bir ikili biçimde.

CORBA, CORBA nesneleri arasındaki etkileşimleri desteklemek için Etkinlik servislerini ve Bildirim servislerini tanımlar. Bu hizmetlerin özellikleri, hem arayüzleri hem de CORBA bildirim sistemleri için altta yatan altyapıyı tanımlar. Yayın / abone olma paradigmasına dayanıyorlar. Etkinlik tedarikçileri ve etkinlik tüketicileri olay kanalları vasıtasıyla birbirleriyle iletişim kurar.

CORBA Olay Servisi belirtimi [28] ilk olarak Mart 1995’te tanıtıldı. İstemcileri ve sunucuları ayrıştırmak, böylece sunucuların istemci geri arama kayıtlarının bir listesini tutması gerekmez. Bu spesifikasyona göre, olay tedarikçisi bir CORBA olay servis kanalına olay yayınlamaktadır. Olay tüketici kanaldan olaylar alıyor. Hem “Push” hem de “Pull” modları desteklenir. CORBA olay hizmeti, tedarikçilerle tüketiciler arasında eşzamansız iletişimi sağlar. Onlar şeffaf konumdadır. CORBA Olay Hizmeti, olay yayılımı için basit bir mekanizma tanımlamasına karşın, önemli dezavantajlara sahiptir. Olay filtrelemesine ve Hizmet Kalitesine (QoS) hitap etmez. Tüketici, bir kanaldaki tüm olayları alır.

CORBA Bildirim hizmeti belirtimi [5], CORBA olay hizmeti belirtiminin bir geliştirmesidir. Olay filtreleme ve Hizmet Kalitesi (QoS) için destek ekler. CORBA bildirim hizmeti belirtimi, genel bir olayın iyi yapılandırılmış bir olayla eşlenmesi için iyi tanımlanmış bir veri yapısı sağlayan “Yapısal Olaylar” ı tanıttı. Yapılandırılmış etkinlik verimli filtreleme için yararlıdır. Bildirim hizmetindeki olay filtrelemesi, bir filtre nesnesine dayalıdır. Filtre dili, sözdizimi genişletilmiş Trader Constraint Language’i takip eden bir deyimdir.

CORBA Bildirim özelliği, uygulanması zorunlu olmasa da, tüm uygulamalar tarafından anlaşılması gereken 13 QoS özelliğini tanımlar. Diğer QoS özellikleri genişletilebilir.

CORBA’nın farklı platformlarda ve farklı programlama dillerinde uygulamaları olsa da, gerçek şu ki, CORBA üzerine kurulan herhangi bir çözüm, tek bir satıcının uygulanmasına bağlı olacaktır. Satıcılar ürünlerini her düğümde dağıtmayı ve bu düğümleri entegre etmek için kendi ara katmanlarını kullanmayı sever. Başkalarıyla birlikte çalışabilirlik kazanma teşviklerine sahip değildirler. Farklı satıcılardan gelen uygulamalar, özellikle güvenlik, işlem yönetimi ve performans optimizasyonu söz konusu olduğunda iyi bir şekilde birlikte çalışamazlar [18]. CORBA, dağıtılmış ortamın iyi yönetildiği ve öngörülebilir gecikmelere sahip olduğu intranet ölçeğinde yalnızca birlikte çalışabilirlik sağlayabilir.

JMS Şartnamesi

Java Message service (JMS) [6], Sun Microsystems tarafından oluşturulan bir özelliktir. Bir kurumsal mesajlaşma sisteminin mesajını oluşturmak, göndermek, almak ve okumak için Java programlarının API’lerini açıklar. JMS, J2EE kurumsal uygulamalarında yaygın olarak kullanılmaktadır.

JMS iki mesajlaşma stilini tanımlar: noktadan noktaya mesaj kuyruğu stili ve yayın / abone stili. Ayrıca beş ileti türünü tanımlar: textMessage, byteMessage, mapMessage, streamMessage ve objectMessage.

JMS mesajları verimli filtreleme için başlık alanında iyi tanımlanmış bir yapıya sahiptir. Aboneler ilgi alanlarını, sıra adlarını, konu adlarını veya ileti seçicilerini kullanarak JMS iletilerinde ifade edebilirler. Bir ileti seçici, SQL92 koşullu ifadesinin bir alt kümesi sözdizimi olan bir ifadeyi kullanarak üstbilgi alanlarına dayalı ölçüt seçme yöntemini tanımlar. JMS’de tanımlanan QoS ölçütleri öncelik, sebat, dayanıklılık, işlem ve mesaj sırasıdır.

JMS belirtiminin kısıtlılığı yalnızca Java platformlarında çalışır.

OGSI Spesifikasyonunda Bildirim

Açık Grid Hizmetleri Altyapısı (OGSI) belirtimi [7], Global Grid Forum tarafından oluşturulmuştur. İnternet üzerinden bilgisayar kaynaklarını koordine etmeye çalışan Grid hesaplamayı hedef almaktadır. OGSI, Grid hizmetleri arasında bilgi yaratma, yönetme ve değiş tokuş mekanizmaları tanımlar. OGSI’yi kullanarak çeşitli Grid kaynakları (örneğin CPU’lar, depolama aygıtları, veritabanları) OGSA’da (Açık Grid Hizmetleri Mimarisi) tanımlanan üst düzey hizmetlere tekdüze arayüzler sağlar. Grid servisleri, servis arayüzlerini tanımlamak için WSDL [20] uzantısını kullanır.

Bildirim, OGSI’nin önemli bir parçasıdır. OGSI Bildirimi belirtimi çok basittir. Aynı zamanda yayın / abone olma paradigmasına da dayanıyor. Bir “NotificationSink”, ilgisini çektiği hizmet veri adını (dize) gösteren bir “NotificationSource” aboneliği gönderir. Belirtilen hizmet verisi değiştiğinde “notificationSource” bildirim mesajlarını “notificationSink” e gönderir. Bildirim çerçevesi hem doğrudan hizmetten hizmete bildirim mesajı teslimine hem de aracı teslimat hizmetlerinin entegrasyonuna izin verir [6].

OGSI bildirimi, WS temelli olay bildirimine yönelik bir aracı adımdır. XML belgelerini mesaj yükü olarak kullanır ve HTTP’yi taşıma protokolü olarak kullanır. Ancak, Grid hizmetleri Web hizmetlerinin uzantıları olduğundan, Grid hizmetlerini geliştirmek için yaygın olarak bulunan Web hizmetleri araçlarını kullanmak zordur. Web hizmetleri kaynak çerçevesinin (WSRF) ve WS Bildiriminin Ocak 2004’te kullanıma girmesiyle, Grid topluluğu ve Web hizmetleri topluluğu Web hizmetleri standartlarına yakınsadı. WSRF OGSI’nin yerini almıştır. OGSI Bildiriminin yerini WS Bildirimi alır.

Web servislerine dayalı olay bildirim özellikleriyle karşılaştırma

Tablo 3, bu bölümde tartıştığımız dört spesifikasyonu, WS temelli etkinlik bildirim özellikleri ile karşılaştırmaktadır. Bu karşılaştırmadan, olay bildirim spesifikasyonlarının zaman içinde nasıl geliştiğini görebiliriz. Bu karşılaştırmadaki birkaç gözlem:

Tablo 3: Olay bildirimlerindeki belirtimler arasındaki karşılaştırma

• Etkinlik teslim kapsamı İnternet ölçeğine kadar genişletilmiştir. Mesaj gönderme mekanizması taşımadan bağımsız olarak ilerlemektedir.
• XML tabanlı SOAP mesajları ileti yükleri olarak kullanılır.
• Mesaj filtreleme mekanizması, basit özbe tabanlı konu filtrelemesinden içerik tabanlı XPath filtrelemesine geçiyor.
• Hizmet Kalitesi (QoS) kriterleri güvenilirlik gibi artık şartnamelerde tanımlanmamıştır. Bunun yerine, WS-Güvenilirlik, WS-İşlem gibi diğer WS- * spesifikasyonlarıyla bileşime güveniyorlar.
• Abonelik sonlandırmalarının soft-state yönetimi (zaman aşımı) kullanılır. Etkinlik tüketicileri ile olan bağlantılar her zaman canlı kalmaz.
• Birlikte çalışabilirlik endişeleri ince taneli API düzeyinden daha iri taneli hizmet arabirimlerine ve SOAP iletileri düzeyine kaydırılmıştır. Etkinlik üreticileri, olay tüketicileri ve broker’ları, standart biçimlerdeki SOAP iletilerini kullanarak birbirleriyle birlikte çalışabilir. Aynı satıcının uygulamalarını kullanmaya ihtiyaç duymazlar.

VII. WS-MESSENGER PROJESİ

WS-Messenger projesi, Indiana Üniversitesi’nde devam etmekte olan bir projedir. Heterojen uygulamalar ve platformlar arasında WS tabanlı olay bildirim iletileri gönderen, ölçeklenebilir, güvenilir ve verimli bir WS tabanlı mesaj komisyoncusu yaratmayı amaçlıyor. Hem WS-Eventing hem de WS-Bildirim özelliklerini uygular ve bir arabuluculuk yaklaşımı ile her iki spesifikasyonu da aynı anda destekleyebilir. En iyi bilgimize WS-Messenger, birbiriyle yarışan iki Web hizmetleri spesifikasyonunu destekleyen ve arabuluculuk sağlayan ilk açık kaynak projesidir.

WS-Messenger’da kullanılan arabuluculuk teknikleri, WS-Eventing ve WS-Bildirim özellikleri arasındaki farkları mutabık kılmaktadır. WS-Messenger, gelen SOAP iletilerinin hangi belirtimi otomatik olarak kullandığını tespit eder ve bunları buna göre işler. Tepki mesajları, istek mesajları ile aynı özellikleri izler. Bildirim iletileri gönderirken WS-Messenger, bildirim iletilerinin hedef olay tüketicilerinin beklenen özelliklerini izlediğinden emin olur. Hedef bir olay tüccarının belirtim türü, o bildirim tüketeninin abonelik isteği ileti türüne göre belirlenir. Bu şekilde, bir olay üreticisi olay bildirimlerini WS-Eventing belirtimini veya WS Bildirim Özelliğini kullanarak yayınlayabilir. WS-Messenger, arabuluculuk işlemlerini otomatik olarak gerçekleştirdiğinden etkinlik tüketicileri arasında herhangi bir fark yaratmaz.

Varsayılan ileti filtrelemesinin yanı sıra WS-Messenger, mevcut yayınlama / abone olma sistemlerini temel alınan ileti sistemleri olarak kullanabilen genel bir arabirim sağlar. Bu şekilde, WS-Messenger, mevcut mesajlaşma sistemlerine Web hizmeti arayüzleri sağlar. WS-Messenger mimarisi ve Grid hesaplama projelerindeki uygulaması [10] ‘da sunulmuştur.

VIII. SONUÇLAR

WS tabanlı olay bildirim sistemleri, hizmet odaklı Grid hesaplamanın kilit unsurlarıdır. WS-Eventing ve WS-Bildirimi, bu tür sistemler için birbiriyle yarışan iki spesifikasyondur. Bu yazıda, WS-Messenger projesindeki deneyimlerimize dayanarak bu iki spesifikasyonu yan yana karşılaştırdık. Bunları olay bildirim sistemleri için önceki özellikleri ile kıyaslayarak olay bildirim özelliklerinin gelişimini inceledik ve önceki spesifikasyonlardan WS tabanlı olay bildirim spesifikasyonlarına geçişler tespit ettik.

WS-Eventing ve WS-Notification özellikleri henüz tamamlanmamıştır ve her iki spesifikasyonun gelecekteki güncellenmiş sürümleri olmasını bekliyoruz. Bu iki spesifikasyonun farklı sürümlerini karşılaştırarak, birbirlerinden fikir ve kavramları benimsediklerini ve her güncelleme ile daha olgunlaştıklarını gördük. Her iki spesifikasyona da yakınsama eğilimi görüyoruz. Yakın zamanda, IBM, Microsoft, HP ve Intel’den gelen bir beyaz kağıt [29], WS-Bildirimi’ndeki işlevleri WS-Etkinliği ile bütünleştirecek yeni bir standart WS-EventNotification oluşturmayı önermektedir. Ancak WS-Eventing ve WS-Notification desteklenmeye devam edecektir.

WS-Messenger, WS-Eventing ve WS-Bildirim özelliklerini destekleyen ve arabuluculuk sağlayan devam eden bir projedir. Ayrıca, diğer yayınlama / abone mesajlaşma sistemlerini WS tabanlı olay bildirim sistemleri olarak sarabilme özelliğine de sahiptir.

Bu yazı aşağıda belirtilmiş makalenin çeviri notlarından oluşmaktadır.
Huang, Yi, and Dennis Gannon. “A comparative study of web services-based event notification specifications.” Parallel Processing Workshops, 2006. ICPP 2006 Workshops. 2006 International Conference on. IEEE, 2006.