SOAP

SOAP (Simple Object Access Protocol - Basit Nesne Erişim Protokolü), Service-oriented Architecture felsefesini pratiğe uyarlayan iki interface'den biridir. Üzerinde bulunan Universal Description Discovery and Integration (UDDI) ile birlikte hizmet yönelimli mimarinin pratikte kullanılmasını mümkün kılar.

Bütün SOAP mesajlarının içinde olduğu elemandır. SOAP mesajına ilişkin XML belgesinin root elemanı olmak zorundadır. Envelope elemanı içinde Body veya Header gibi elemanlar bulunur. Envelope elemanının içinde her zaman bir Body elemanı vardır fakat Header elemanı olmak zorunda değildir. SOAP mimarisine göre eğer Envelope elemanı içinde Header elemanı varsa bu eleman Envelope elemanının içindeki ilk eleman olmalıdır. Soap kullanan mimarilerde kesinlikle erişim protokolü olarak TCP kullanılmalıdır.

SOAP mesajlarındaki Header elemanını HTML standartlarında bulunan etiketlerine benzetebiliriz. Header bölümü metot çağrımı ile doğrudan ilişkili değildir. Header bölümü ile meta-data dediğimizi bilgiler gönderilir.

Body elemanı SOAP mesajının en önemli kısmını oluşturur. Body bölümünde web metodunun adı ve metodun parametrik bilgileri XML formatında gönderilir. Cevap mesajında ise metodun geri dönüş değeri Body bölgesine eklenir. Metodun parametrik yapısının bu şekilde XML formatında yazılmasına SOAP Serialization denir. Son olarak hata mesajlarında ise Body bölümünde hatanın adı ve tanımı gibi bilgiler bulunur.

SOAP isteklerinin oluşturulması ve yanıtların işlenmesi kolaydır. İlk olarak, bir müşteri tarafından bir XML belgesi kullanılarak bir hizmet talebi oluşturulur. Ardından, bir SOAP istemcisi, XML belgesini bir SOAP sunucusuna gönderir. Sunucu SOAP mesajını aldığında, mesajı istenen sunucu tarafı uygulamaya bir hizmet çağrısı olarak gönderir. İstemci için istenen parametreleri, dönüş değerlerini ve verileri içeren bir yanıt, önce SOAP istek işleyicisine ve ardından istekte bulunan istemciye döndürülür. Hem SOAP istekleri hem de yanıtları, Güvenli Köprü Metni Aktarım Protokolü (HTTPS) veya HTTP gibi benzer bir protokol kullanılarak taşınır.

SOAP işlemlerinin ne yapabileceğine dair bir örnek olarak, bir uygulama, gerçek bir emlak fiyat veritabanı gibi web hizmetleri etkinleştirilmiş bir sunucuya bir SOAP isteği gönderebilir ve arama için parametreleri içerebilir. Sunucu daha sonra, örneğin fiyatlar, konum, özellikler gibi sonuç verileri ile bir SOAP yanıtı (bir XML biçimli belge) döndürür. Oluşturulan veriler, standartlaştırılmış bir makine-parselenebilir formatta geldiği için, istek gönderen uygulama doğrudan entegre edebilir.

SOAP, XML-RPC'nin bir devamı olarak evrimlese de, Web Service Addressing'den (WS-Adressing) taşıma ve etkileşim tarafsızlığını ve zarf/başlık/gövdeyi başka yerlerden (muhtemelen WDDX'den) ödünç almaktadır.

SOAP, nesne erişim protokolü olarak tasarlandı ve Dave Winer, Don Box, Bob Atkinson ve Mohsen Al-Ghosein tarafından Microsoft için hazırlandı ve XML-RPC olarak Haziran 1998'de Frontier 5.1'in bir parçası olarak piyasaya sürüldü. İki kişi Atkinson ve Al-Ghosein, Microsoft'ta çalışıyordu. Özellik, 13 Eylül 1999'da IETF'ye sunulana kadar herhangi bir yerde yayınlanmadı. Don Box'a göre, bunun sebebi Microsoft'taki politikalardı. Microsoft'ın tereddüdü nedeniyle, Dave Winer XML-RPC'yi 1998 yılında gönderdi.

Gönderilen Internet Taslağı, RFC durumuna ulaşmadı ve bu nedenle "web standardı" olarak kabul edilmiyor. 1.1 sürümü, 8 Mayıs 2000'de W3C Notu olarak yayınlandı. Ancak 1.1 sürümü W3C önerisi olarak kabul edilmediğinden, "web standardı" olarak kabul edilemez. Ancak, 1.2 sürümü, 24 Haziran 2003'te W3C önerisi olarak kabul edildi.

SOAP spesifikasyonu, Dünya Çapında Ağ Konsorsiyumu'nun XML Protokol Çalışma Grubu tarafından yönetiliyordu ve grup 10 Temmuz 2009'da kapatıldı. SOAP, başlangıçta "Simple Object Access Protocol" (Basit Nesne Erişim Protokolü) olarak adlandırıldı, ancak standardın 1.2 sürümü bu kısaltmayı bıraktı.

SOAP ilk olarak tanıtıldıktan sonra, WSDL, XSD ve UDDI'ye dayanan daha karmaşık bir web hizmetleri kümesinin altındaki katman haline geldi. Bu farklı hizmetler, özellikle UDDI, çok daha az ilgi göstermiştir, ancak bunların takdir edilmesi, SOAP'un beklenen rolünün, web hizmetleri nasıl evrimleştiğine göre nasıl olduğunun tam bir anlayışını sağlar.

Bu, bir SOAP göndericisi ile bir SOAP alıcısı arasında değiş tokuş edilen bilginin biçimlendirme ve işlem kurallarını formalize eden ve yöneten bir dizi kuraldır.

Bir SOAP mesajının yolu boyunca, tüm düğümler belirli bir role sahip olurlar. Düğümün rolü, aldığı mesaj üzerinde gerçekleştirdiği eylemi tanımlar. Örneğin, "hiçbiri" rolü, hiçbir düğümün SOAP başlığını herhangi bir şekilde işlemeyeceği ve sadece mesajı yol boyunca ileteceği anlamına gelir.

Bir SOAP mesajı, bir ağ üzerinde aktarılması için diğer protokollerle birlikte çalışması gerekir. Örneğin, bir SOAP mesajı, mesajları aktarmak için bir alt katman protokolü olarak TCP'yi kullanabilir. Bu bağlar, SOAP protokol bağı çerçevesinde tanımlanmıştır.

SOAP yalnızca bir mesajlaşma çerçevesi sağlar. Ancak, güvenilirlik, güvenlik vb. gibi özellikler eklemek için genişletilebilir. SOAP çerçevesine özellik eklerken izlenmesi gereken kurallar vardır.

SOAP üzerine genişletilen herhangi yeni özelliği tanımlayan SOAP başlığı hakkındaki anlamsal özellikler koleksiyonudur. Bir modül, sıfır veya daha fazla özelliği gerçekleştirmesi gerekir. SOAP, modüllerin belirli kurallara uymasını gerektirir.

Bir SOAP başlığı birden fazla blok içerebilir ve her biri başlık içinde ayrı bir hesaplama bloğudur. Genel olarak, SOAP rol bilgisi, yoldaki düğümleri hedeflemek için kullanılır. Bir başlık bloğu, SOAP rolü, SOAP düğümü tarafından işletilen bir rolün adı ise, bir SOAP düğümüne hedeflenir.

SMTP ve HTTP, SOAP'un taşıma yöntemi olarak kullanılan geçerli uygulama katmanı protokolleridir, ancak HTTP, bugünün internet altyapısı ile iyi çalıştığı için daha geniş kabul görmüştür; özellikle, HTTP ağ güvenlik duvarlarıyla iyi çalışır. SOAP ayrıca basit veya karşılıklı kimlik doğrulama ile HTTPS üzerinden de kullanılabilir (bu, uygulama düzeyinde HTTP ile aynı protokoldür, ancak altında şifreli bir iletişim protokolü kullanır); bu, WS-I Temel Profil 1.1'de belirtildiği gibi web servis güvenliği sağlamak için önerilen WS-I yöntemidir.

Bu, GIOP/IIOP veya DCOM gibi diğer dağıtılmış protokollere göre bir avantajdır, bunlar genellikle güvenlik duvarları tarafından filtrelenir. Bazı uygulamaların desteklediği bir başka seçenek de SOAP'un AMQP üzerinden kullanılmasıdır. SOAP'un, gönderen ve alıcı düğümlerin bilgisine ihtiyaç duyan makinelerde yapılandırılan güvenlik haklarından etkilenmeyen bir avantajı da vardır. Bu, SOAP'un DCOM ile mümkün olmayan bir şekilde gevşek bir şekilde eşleştirilmesine izin verir. Ayrıca SOAP üzerinden UDP OASIS standardı da vardır.

SOAP'un tarafsızlık özelliği, herhangi bir taşıma protokolüyle kullanıma uygun olduğunu açıkça belirtir. Uygulamalar genellikle bir taşıma protokolü olarak HTTP kullanır, ancak diğer popüler taşıma protokolleri de kullanılabilir. Örneğin, SOAP ayrıca SMTP, JMS ve mesaj kuyrukları üzerinden de kullanılabilir.

SOAP, HTTP post/cevap alışverişleriyle birleştirildiğinde, mevcut güvenlik duvarları ve proxy'ler üzerinden kolayca tüneller oluşturur ve bu nedenle HTTP post/cevap alışverişleri işlemek için mevcut olan yaygın hesaplama ve iletişim altyapılarının değiştirilmesini gerektirmez.

Standart uygulama ve varsayılan SOAP/HTTP bağlama kullanıldığında, XML bilgi kümesi XML olarak serileştirilir. Gömülü ikili nesnelerle XML'in özel durumunda performansı artırmak için Mesaj İletim Optimizasyon Mekanizması tanıtılmıştır.

HTTP'ye güvenerek bir taşıma protokolü olarak ve Web Hizmetleri Adresleme veya Kurumsal Servis Otobüsü kullanılmadığında, etkileşen tarafların rolleri sabittir. Yalnızca bir taraf (istemci), diğerinin hizmetlerini kullanabilir.

SOAP, adı önerdiği kadar "basit" değildir. Protokolün ayrıntılı olması, XML'in yavaş ayrıştırma hızı ve standartlaştırılmış bir etkileşim modelinin olmaması, HTTP protokolünü daha doğrudan kullanan hizmetlerin hakimiyetine neden oldu. Örneğin, REST.

Protokol-özgür olması nedeniyle, SOAP, REST'in Uniform Interface veya önbellekleme gibi protokol özgü özelliklerinden ve optimizasyonlarından yararlanamaz - bunları yeniden uygulamak zorunda kalır (örneğin WS-Addressing ile olduğu gibi).