Temel konseptler. SOAP mesaj yapısı. XML web hizmetleri. SABUN protokolü
SABUN (Basit Nesne Erişimi protokol) istemci ile sunucu arasında standartlaştırılmış bir mesaj aktarım protokolüdür. Genellikle HTTP(S) ile birlikte kullanılır ancak diğer uygulama katmanı protokolleriyle (SMTP ve FTP gibi) da çalışabilir.
SOAP'ı test teknikleri açısından test etmek, diğer API'lerle çalışmaktan temel olarak farklı değildir, ancak ön hazırlık (protokol teorisi açısından) ve test için özel araçlar gerektirir. Bu makalede, hem SOAP testçisi (çoğunlukla bir görevi belirledikten sonra "neyi kavraması gerektiği" konusunda hiçbir fikri olmayan) ve Test uzmanlarının bilgilerini değerlendirmek ve öğrenme için planlar geliştirmek zorunda kalan bir yönetici.
Teorik temel
SOAP'ın bir protokol olduğu gerçeği büyük önem test için: protokolün kendisini, temel aldığı "birincil" standartları ve protokolleri ve (gerektiğinde) mevcut uzantıları incelemeniz gerekir.
XML
XML, HTML'ye benzer bir biçimlendirme dilidir. SOAP aracılığıyla gönderilen/alınan herhangi bir mesaj, verilerin uygun şekilde yapılandırıldığı ve okunması kolay bir XML belgesidir; örneğin:
Makale yazmayı unutmayın!
XML hakkında daha fazla bilgiyi w3schools veya codenet (Rusça) adresinden edinebilirsiniz. Ad alanlarının açıklamasına dikkat ettiğinizden emin olun (XML'deki öğeleri açıklarken çakışmaları çözme yöntemi) - SOAP'ta bunların kullanılması gereklidir.
XSD
Çalışırken, olası XML belgelerinin standartlaştırılmış bir açıklamasına sahip olmak ve bunları doldurmanın doğruluğunu kontrol etmek her zaman uygundur. Bunun için bir XML Şema Tanımı (veya kısaca XSD) vardır. Test cihazı için XSD'nin iki ana özelliği, veri türlerinin tanımlanması ve olası değerlere kısıtlama getirilmesidir. Örneğin, önceki örnekteki öğe isteğe bağlı hale getirilebilir ve XSD kullanılarak 255 karakterle sınırlandırılabilir:
...
...
SABUN uzantıları
Çalışmanızda, SOAP standartlarının WS-* gibi çeşitli "uzantıları" ile de karşılaşabilirsiniz. En yaygın olanlardan biri, şifrelemeyle çalışmanıza olanak tanıyan WS-Security'dir ve elektronik imzalar. Çoğunlukla, hizmetinizi kullanma haklarını yönetebileceğiniz bir WS Politikası onunla birlikte kullanılır.
WS-Security kullanımına bir örnek:
Bu uzantıların hepsi oldukça karmaşık yapılardır ve her SOAP hizmetinde kullanılmayan; SOAP testinde uzmanlaşmanın ilk aşamasında bunları ayrıntılı olarak incelemek pek alakalı olmayacaktır.
Aletler
Zaten anladığınız gibi, SOAP ciddi bir konudur, onunla çalışmak için teoriyi ve çok sayıda standardı bilmeniz gerekir. Uygulamada, bu tür bir karmaşıklık çok somut işçilik maliyetlerine yol açacaktır (örneğin, her seferinde bir not defterindeki şemaya bakmak ve kıvrılma istekleri göndermek gerekli olacaktır). Bu nedenle SOAP ile çalışmayı kolaylaştıracak araçlar oluşturulmuştur.
XML/XSD düzenleyicileri
İyi bir test uzmanı, teste dokümantasyon yazma aşamasında başlar, bu nedenle şemaları kontrol etmek için özel editörlerin kullanılması uygundur. En ünlü ikisi Oxygen (çapraz platform) ve Altova'dır (yalnızca Windows); ikisi de ücretli. Bu çok güçlü programlar Analistler tarafından hizmetleri açıklarken aktif olarak kullanılanlar.
Uygulamamda editörlerin üç özelliğinin faydalı olduğu ortaya çıktı: XSD görselleştirme, XSD'ye dayalı XML oluşturma ve XSD'de XML doğrulama.
1. XSD görselleştirmesişemanın görsel temsili için gerekli olup, gerekli öğelerin ve niteliklerin yanı sıra mevcut kısıtlamaları hızlı bir şekilde izole etmenize olanak tanır. Örneğin, bir CheckTextRequest isteği için metin öğesi gereklidir ve üç özelliğin tümü isteğe bağlıdır (seçenekler özelliğinin varsayılan değeri sıfır olarak ayarlanmıştır).
Şemada çok fazla tür ve kısıtlama olduğunda görselleştirme gereklidir. Yalnızca ihtiyacınız varsa ve özel editörlere para ödemek istemiyorsanız, ücretsiz alternatifler (JDeveloper gibi) düşünülebilir.
2. XSD'ye dayalı XML oluşturma Bir mesajın geçerli bir örneğini görmek istediğinizde kullanışlıdır. Bunu, mesajın olası tamamlanmasını hızlı bir şekilde denemek ve kısıtlamaların nasıl çalıştığına ilişkin nüansları kontrol etmek için kullanıyorum.
3. Özelliği 2. maddeden kullandıktan sonra şunları yapmak faydalıdır: XSD'ye karşı XML doğrulaması- yani mesajın doğruluğunu kontrol edin. 2. ve 3. özellikler birlikte, hizmetin kendisi geliştirilme aşamasındayken bile XSD'deki zorlu kusurları yakalamanıza olanak tanır.
Test Aracı - SoapUI
SOAP testi neredeyse her zaman SoapUI kullanmayı içerir. Bu aracın kullanımı hakkında çeşitli kaynaklarda (,) okuyabilirsiniz, ancak en etkili olanı resmi belgeleri okumak olacaktır. SoapUI yeterliliğinin 8 koşullu seviyesini ayırt ediyorum:
Seviye 1 - İstek gönderebilirim
WSDL'ye dayalı bir projeyi nasıl oluşturacağınızı öğrenin. SoapUI sizin için gerekli tüm istekleri oluşturabilir; doldurmalarının doğruluğunu kontrol etmeniz ve "Gönder" düğmesini tıklamanız yeterlidir. Geçerli sorgular yapma sanatında ustalaştıktan sonra, hatalara neden olan geçersiz sorgular yapma sanatında da ustalaşmalısınız.
Seviye 2 - Test Paketleri ve Test Senaryoları yapabilirim
Mini otomatik testler yapmaya başlayın. Test paketleri ve test senaryoları komut dosyaları oluşturmanıza olanak tanır API testi, sorgular için veri hazırlayın ve alınan yanıtı beklenen yanıtla otomatik olarak kontrol edin. İlk başta yalnızca sorgu koleksiyonları olarak kullanılabilirler. Örneğin bir hatanız varsa ve düzeltme sonrasında hızlı bir şekilde kontrol etmek istiyorsanız, hata talepleri için özel olarak ayrı bir test paketi ayırabilirsiniz.
Seviye 3 – İddialar yazabilir
Test senaryolarında uzmanlaştıktan sonra, bunları nasıl otomatik olarak doğrulanabilir hale getireceğinizi öğrenmeniz faydalı olacaktır. Bundan sonra artık cevapla ilgili bilgiyi “gözlerinizle” aramanıza gerek kalmayacak: otomatik kontrol vakalar yeşil (eğer test geçilirse) veya kırmızı (eğer geçilmezse) olarak işaretlenecektir. SoapUI çok çeşitli olası kontroller (iddialar) sağlar, ancak en kullanışlı ve basit olanı İçerir ve İçermez'dir. Onların yardımıyla, alınan yanıtta belirli bir metnin varlığını kontrol edebilirsiniz. Bu kontroller aynı zamanda normal ifade aramalarını da destekler.
Seviye 4 - İddialarda XPath ve/veya XQuery'yi kullanma
Selenium kullanan kullanıcı arayüzüne biraz aşina olanlar için XPath dili tanıdık bir şeydir. Kabaca söylemek gerekirse XPath, bir XML belgesindeki öğeleri aramanıza olanak tanır. XQuery, XPath'ı dahili olarak kullanabilen benzer bir teknolojidir; bu dil çok daha güçlü, SQL'e benziyor. Bu dillerin her ikisi de Onaylarda kullanılabilir. Onların yardımıyla yapılan kontroller daha hedefe yönelik ve istikrarlıdır, dolayısıyla vakalarınız daha güvenilir olacaktır.
Seviye 5 – özel adımları kullanarak karmaşık testler yazabilir
Test senaryoları yalnızca bir istek değil, birden fazla istek de içerebilir (örneğin, "varlık oluşturma" → "varlığı dışa aktarma" standart kullanıcı senaryosunu taklit etmek istediğinizde). Talepler arasında aşağıdakiler gibi başka özel adımlar da olabilir:
- Mülkler ve Mülk Transferi (verilerin yeniden kullanılmasına ve istekler arasında aktarılmasına yardımcı olun);
- JDBC İsteği (veritabanından veri almak için kullanılır);
- Koşullu Git (bir test senaryosunda dallar veya döngüler oluşturmanıza olanak sağlar);
- TestCase'i çalıştırın (bazı tipik sorguları ayrı test senaryolarına yerleştirmenize ve gerektiğinde bunları çağırmanıza yardımcı olur).
Seviye 6 - Groovy komut dosyalarını kullanma
SoapUI, Groovy komut dosyalarını çeşitli yerlere yazmanıza olanak tanır. En basit durum, $(=) eklemelerini kullanarak sorgunun kendisinde veri oluşturmaktır. Bu eklentileri her zaman kullanıyorum:
- $(=new Date().format("yyyy-AA-gg'T'HH:dd:ss"))– geçerli tarih ve saati gerekli formatta eklemek için;
- $(=java.util.UUID.randomUUID())– iyi biçimlendirilmiş rastgele bir GUID eklemek için.
Tam komut dosyaları vakalarda ve testlerde adım olarak kullanılabilir. Bir noktada, beşinci seviyedeki birkaç özel adımın aynı anda tek bir komut dosyasıyla değiştirilebileceğini göreceksiniz.
Seviye 7 - MockServices'i kullanma
WSDL'yi temel alan SoapUI, Mock nesneleri oluşturabilir. Sahte nesne, bir hizmetin en basit simülasyonudur. "Mocks" yardımıyla, hizmet gerçekten test için kullanılabilir hale gelmeden önce bile test senaryolarını yazmaya ve hata ayıklamaya başlayabilirsiniz. Ayrıca geçici olarak kullanılamayan hizmetler için "taslak" olarak da kullanılabilirler.
Seviye 8 - tanrı SoapUI
Ücretli ve ücretli arasındaki farkı biliyor musunuz? ücretsiz sürümler SoapUI'yi kullanın ve kodda SoapUI API'sini kullanın. Eklentileri kullanır ve vakaları komut satırı ve/veya CI aracılığıyla çalıştırırsınız. Test senaryolarınız basit ve bakımı kolaydır. Genel olarak bu enstrümanda "köpeği yediniz". SoapUI'da bu seviyede uzmanlaşan biriyle konuşmayı çok isterim. Eğer öyleyseniz lütfen yorum bırakın!
Programlama Dilleriyle Test Etme
Groovy-wslite kullanılarak YandexSpeller API'sine yapılan bir isteğin nasıl göründüğüne dair bir örnek vereceğim:
wslite.soap'u içe aktarın.*
def istemcisi = new SOAPClient("http://speller.yandex.net/services/spellservice?WSDL")
def yanıt = client.send(SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
vücut (
CheckTextRequest("lang": "ru", "xmlns":"http://speller.yandex.net/services/spellservice") (
metin("hata")
}
}
}
"error" == Response.CheckTextResponse.SpellResult.error.s.text()'i iddia edin
"1" olduğunu iddia edin == [e-posta korumalı]()
Bildiğim kadarıyla henüz SOAP testi için üst düzey çerçeveler (Rest-assured gibi) yok, ancak yakın zamanda ilginç bir araç ortaya çıktı - karate . Bununla birlikte, SOAP ve REST'i test etmek için durumları Salatalık / Salatalık gibi senaryolar şeklinde tanımlayabilirsiniz. Birçok testçi için karateye yapılan referans ideal çözümçünkü bu tür senaryolar, yazma ve destekleme vakalarının karmaşıklığı açısından, SoapUI kullanmakla kendi SOAP test çerçevenizi yazmak arasında ortada bir yerde yer alacaktır.
Çözüm
SOAP'u kendiniz için bu şekilde test etmek istemeniz pek olası değildir (REST ile yapabileceğiniz gibi). Bu ciddi durumlarda kullanılan ağır bir protokoldür. kurumsal çözümler. Ancak ağırlığı aynı zamanda testçiye de bir hediyedir: Kullanılan tüm teknolojiler standartlaştırılmıştır, iş için yüksek kaliteli araçlar vardır. Testi yapan kişi için gerekli olan tek şey, bunları inceleme ve kullanma arzusudur.
Bir test uzmanı için gerekli becerilerden oluşan aynı kontrol listesini bir araya getirelim. Dolayısıyla, SOAP hizmetlerini test etmeye yeni başlıyorsanız aşağıdakileri bilmeniz ve kullanabilmeniz gerekir:
- wsdl.
- SABUN.
- XML / XSD editörleri (XSD görselleştirme düzeyinde).
- SoapUI 1. seviyede.
Gördüğünüz gibi asıl odak noktası öğrenme standartlarıdır; SoapUI'da sadece istekleri yerine getirebilmek yeterlidir. SOAP testine daldıkça daha ciddi beceri ve bilgi gerektirecek görevlerle karşılaşacaksınız ancak her şeyi bir anda öğrenmeye çalışmamalısınız. Çok daha önemli olan, gerçekleştirilen görevlerin karmaşıklık düzeyinin artırılmasındaki tutarlılıktır. Bu tavsiyeye uyarak bir gün bu alanda iyi bir uzman olduğunuzu anlayacaksınız!
Genel olarak bugün standart XML veri alışverişi protokolleri vardır:
- XML-RPC- bir paket iletirsiniz ve sunucuda hangi yöntemi aramak istediğinizi belirtirsiniz.
- DİNLENMEK- sunucuda bazı nesneler var. Her nesne bazı tanımlayıcılarla karakterize edilir. Her öğenin kendi URL'si vardır. Herhangi bir öğeyle şunları yapabilirsiniz: ekleme, silme, güncelleme, seçme. İstediğiniz isteği sunucuya göndermeniz yeterlidir (örneğin, falanca öğeyi ekleyin). İstemci-sunucu değişimi JSON veya XML tabanlıdır.
SOAP, RPC'ye (Hizmet Odaklı Mimari, birbirleriyle etkileşime giren gevşek bağlı hizmetler kümesi) dayanmaktadır. RPC'nin temel avantajı, ağ kaynaklarının (giriş noktaları) az miktarda olması ve çok sayıda yöntemin kullanılmasıdır. Bu avantajına rağmen RPC, birçok dezavantajı olan eski bir protokoldür:
- XML-RPC mesajını doğrulayamazsınız. Eski protokol, şemaların (veri doğrulama yöntemleri) XML'de standartlaştırılmasından önce oluşturulmuştu. Onlar. Sunucu istekleri kabul ettiğinden, bu isteklerin kendisi için olduğundan ve verilerin tutarsız olmadığından emin olmalıdır. XML-RPC'de bunun için veri türleri bildirilir, ancak bu bir veri türü kontrolüdür ve veri tutarlılığı (gerekli tüm parametreleri içeren bir yapı aldığınız) kontrol edilmez.
- Birleşik mesajlar oluşturamazsınız.
- Uzay ve zamanı kullanamazsınız (RPC'nin oluşturulmasından sonra ortaya çıktı).
- Mesajı genişletemezsiniz, yani. ek bilgi ekleyin.
Tüm bu eksiklikler XML Şeması'nda giderilmiştir. Bu endüstri standardıdır XML açıklamaları belge. Onlar. keyfi verileri modellemenin bir yoludur. Bir XML şeması, bir modeli (öğeler ve nitelikler arasındaki ilişkiler ve yapıları), veri türlerini (veri türlerini karakterize eder) ve kelime dağarcığını (öğelerin ve niteliklerin adları) tanımlayabilir.
XML-RPC'nin tüm eksikliklerinden yola çıkarak SOAP protokolünü oluşturdular.
SABUN(Simle Nesne Erişim Protokolü) - bir nesneye (giriş noktası) erişim protokolü. Günümüzde dağıtılmış uygulamalar oluşturmak için ana endüstri standardıdır.
XML-RPC dilinin bir uzantısıdır. Onlar. şu prensip üzerine inşa edilmiştir: 1 giriş noktası ve herhangi bir yöntem. Taşıma açısından protokolün kendisi (verilerin nasıl aktarılacağı) geniş bir seçenek sunar: SMTP, FTP, HTTP, MSMQ.
SOAP, XML Web Hizmetlerinin (XML Web Hizmetleri) uygulanmasının merkezinde yer alır. SOAP'ın dezavantajı öğrenmenin zor olmasıdır.
SOAP, istemci ile sunucu arasındaki (senkron ve asenkron) mesaj alışverişine dayanır. Her mesaj veri hakkında bilgi taşır (hangi verinin iletildiği/alındığı). SOAP, XML şemalarını kullanarak mesajın tüm yapısını önceden açıklar: mesajda ne olmalı, nasıl iletilecek. Bu, sunucuyu tanımadan orada neler olduğunu anlamayı mümkün kılar ve sunucunun bu mesajın kendisi için olup olmadığını kontrol etmesine olanak tanır.
XML Şeması
Bir şemanın amacı veri yapısını tanımlamaktır; neyimiz var. Tüm veriler basit ve karmaşık türlere (skalerler ve yapılar) ayrılmıştır. Basit bir tür (dize, sayı, boolean, tarih) hiçbir zaman içinde hiçbir şey içermez. Bir yapı (nesne) özellikler içerebilir.
Temel SABUN İşlemleri
- Yalnızca basit istemci-sunucu bilgi alışverişi değil. Ancak sunucunun otomatik olarak tanınması ve bu sunucunun aranması, yani. istemcinin sunucu hakkında hiçbir şey bilmemesi bile mümkündür. Onlar. istemci önce bir sunucu arar, uygun hizmetleri bulur, orada hangi yöntemlerin bulunduğunu, sunucuda neler olduğunu anlar ve ona çağrı yapar.
- Sunucu, istemcinin bu sunucuyu bulabilmesi için bilgilerini (konum, hangi yöntemleri desteklediği) yayınlar. Yayın UDDI dizininde gerçekleşir.
SOAP mesajlarının yapısı:
- SOAP Zarfı (zarf) - bu, mesajın tamamını içerir. Başlık ve gövdeden oluşur.
- SABUN Başlığı - Ek Bilgiler(örneğin yetkilendirme).
- SABUN Gövdesi (gövde) - mesajın kendisi.
- SOAP Arızası (hata) - hataları sunucudan istemciye aktarmanın bir yolu.
WSDL
WSDL(Web Hizmetleri Açıklama Dili) - Web hizmetleri açıklama dili. SABUN'da kullanılır. Bu her şeyi açıklayan bir tür belgedir: hangi ad alanlarının kullanıldığı, hangi veri şemalarının kullanıldığı, sunucunun istemciden ne tür mesajlar beklediği, hangi zarfların hangi yönteme ait olduğu, genel olarak hangi yöntemlerin mevcut olduğu, hangi adrese gönderileceği, vesaire. Aslında WSDL bir web servisidir. Müşterinin bu belgenin içeriğini incelemesi yeterlidir, sunucu hakkında her şeyi zaten biliyor.
Herhangi bir sunucu WSDL'yi yayınlamalıdır.
WSDL bloklardan oluşur:
- Hizmetin kendisinin tanımı, yani. giriş noktası, port belirtilir.
- Yöntem biçimi. Giriş noktası işlemlere bağlıdır, yani. hangi yöntemleri destekliyor? Çağrının türünü, iletim yöntemini belirtin. Her yöntemin içinde, verilerin hangi biçimde iletildiğinin - SOAP biçiminde bir açıklaması vardır.
- Bir mesaja bağlama yöntemleri.
- Mesajların kendilerinin açıklaması.
Basit Nesne Erişim Protokolü (SOAP) Farklı uygulama sistemleri arasında mesajların İnternet üzerinden iletilmesine ilişkin kuralları tanımlayan XML tabanlı bir protokoldür. Esas olarak uzaktan prosedür çağrıları için kullanılır. SOAP başlangıçta HTTP'nin "üzerinde" çalışacak şekilde tasarlandı (SOAP'ın Web uygulamalarına entegre edilmesini kolaylaştırmak için), ancak artık SMTP gibi diğer aktarım protokolleri de kullanılabilir.
Diyelim ki internette bir uygulama erişim hizmeti oluşturuyorsunuz; Tüketiciler bu hizmetle bilgi aktararak etkileşime girerler. Sunucularınız verileri işler ve sonuçları tüketicilere iletir. Sistemle iletişim kurmanın en iyi yolu nedir?
Özel bir istemci/sunucu uygulaması oluşturabilir ve tüketicilerin hizmetinize erişmeleri için özel bir istemci programı kullanmalarını zorunlu kılabilirsiniz. Ancak İnternet işine girme konusunda ciddiyseniz, mümkün olan tüm istemci platformlarında (Windows, Macintosh, Unix, Linux vb.) çalışan bir istemci oluşturmanız gerekecektir. birçok farklı istemci yazın.
Peki buna nasıl tepki verirsiniz? Web'i kullanma? Böyle bir çözüm elbette oldukça kabul edilebilir, ancak tarayıcının uygulanmasına sıkı sıkıya bağlıdır ve yine böyle bir çözüm için gelen ve giden bilgilerin yanı sıra verileri biçimlendirmek ve paketlemek için bir altyapı oluşturmanız gerekecektir. değişme. Karmaşık uygulamalar için Java veya ActiveX'i seçebilirsiniz, ancak bu durumda bazı kullanıcılar, açıkça aşırı bant genişliği gereksinimleri ve yetersiz güvenlik nedeniyle hizmetlerinizi reddedecektir.
Gerekli olan tek şey, uygulama verilerinin paketlenmesini basitleştiren ve bilginin içeriğine uyarlanabilen XML kullanarak Web üzerinden aktaran basit bir protokoldür. Böylece hem gönderenin hem de alıcının herhangi bir mesajın içeriğini kolaylıkla yorumlayabilmesini sağlar. Aynı zamanda HTTP Web protokolünü aktarım olarak kullanarak, güvenlik duvarlarının koruma düzeyini düşürme ihtiyacını da ortadan kaldırmak mümkün olacaktır.
İyi tanımlanmış Basit Nesne Erişim Protokolü (SOAP), ana bilgisayarların uygulama nesnelerini uzaktan arayabildiği ve sonuçları döndürebildiği basit bir "birleştirici" protokoldür. SABUN teklifleri minimum set Bir uygulamanın mesaj göndermesine izin veren koşullar: Bir istemci, bir program nesnesini çağırmak için bir mesaj gönderebilir ve bir sunucu bu çağrının sonuçlarını döndürebilir.
SOAP oldukça basittir: mesajlar, SOAP komutlarını içeren XML belgeleridir. Teorik olarak SOAP uygulamalar için herhangi bir aktarım protokolüne bağlanabilirken, genellikle HTTP ile birlikte kullanılır.
Kennard Scribner, kitabın ortak yazarı SOAP'ı Anlamak: Yetkili Çözüm(Macmillan USA, 2000), SOAP'ın bir yöntemi çağırmak için gereken bilgileri (argüman değerleri ve işlem kimlikleri gibi) XML formatına dönüştürerek çalıştığını söylüyor.
Veriler HTTP veya başka bir aktarım protokolünde kapsüllenir ve genellikle sunucu olan hedefe iletilir. Bu sunucu, SOAP verilerini paketten çıkarır, gerekli işlemleri gerçekleştirir ve sonuçları SOAP yanıtı olarak döndürür.
Scribner, SOAP'ın, Java'nın Uzaktan Yöntem Çağırma protokolü veya CORBA'nın Genel Inter-ORB Protokolü gibi, uzaktan prosedür çağrısı protokolü olarak davrandığını belirtti.
HTTP ve XML neredeyse her yerde kullanıldığından Scribner, SOAP'ın tartışmasız günümüzde var olan en ölçeklenebilir uzaktan prosedür çağrısı protokolü olduğunu söylüyor. SOAP, eksiksiz bir nesne mimarisi olarak hareket edecek şekilde tasarlanmamıştır.
SOAP, Java'daki, Dağıtılmış Bileşen Nesne Modeli ve CORBA'daki Uzaktan Yöntem Çağırma'nın yerine geçmez; bu modellerden herhangi biri tarafından kullanılabilecek kurallar önermektedir. SABUN tam bir çözüm değildir. Nesne aktivasyonunu veya güvenliğini desteklemez. Scribner'a göre, SOAP tasarımcıları "kullanıcıların bu kodu protokolün bir parçası haline getirmek yerine SOAP'un üzerine oluşturarak bu kodu kendilerinin ekleyeceğinden eminler".
Şekilde, bir ana bilgisayarın belirli bir hisse senedinin fiyatı için bir teklif hizmetini sorguladığı SOAP 1.1 spesifikasyonundan alınan bir örnek gösterilmektedir. SOAP isteği bir HTTP POST'a gömülüdür ve istek gövdesi istek türünü ve stok karakter parametresini belirtir. Yanıt ayrıca tek bir dönüş değeriyle (34,5 inç) bir HTTP yanıtında kapsüllenmiş bir XML nesnesi sağlar. bu durum).
SABUN Özellikleri
SOAP ile geliştiriciler, mevcut uygulamalara yönelik programları çağırmak için SOAP mesajları yazabildiği kadar hızlı bir şekilde Web hizmetleri oluşturabilir ve ardından bu uygulamaları basit Web sayfalarına ekleyebilir. Ancak geliştiricilerin, SOAP çağrılarını özel uygulamalarda kullanma ve diğer kişilerin Web sayfalarına aktarılabilecek uygulamalar oluşturma, böylece zaman alıcı ve maliyetli geliştirme sürecinden kaçınma fırsatları da vardır.
Understanding SOAP kitabının diğer yazarı Mark Stever'e göre, Microsoft'un yaklaşmakta olan .Net platformuyla tam olarak amaçladığı şey bu. “Burası SOAP'un tüm görkemiyle parladığı yer. Geliştiricilere potansiyel uyumsuzluklar konusunda endişelenmelerine gerek kalmadan uygulamalar geliştirmeleri için gerçekten harika bir yol sunuyor” diyor.
SABUN örneği
Aşağıdaki örnek, bir müşterinin belirli bir hisse senedi için en son fiyat teklifleri için istek göndermesine olanak tanıyan GetLastTradePrice adlı bir SOAP isteğini göstermektedir.
POST/StockQuote HTTP/1.1
ev sahibi: www.stockquoteserver.com
içerik türü: metin/xml; karakter kümesi = "utf-8"
İçerik Uzunluğu: nnnn
SABUNAksiyonu:"Bazı URI"
İlk beş satır (HTTP başlığının bir kısmı) mesaj tipini (POST), ana bilgisayarı, yük tipini ve uzunluğunu belirtir ve SOAPAction başlığı SOAP isteğinin amacını belirtir. SOAP mesajının kendisi bir XML belgesidir; önce bir SOAP zarfı, ardından SOAP ad alanını ve varsa niteliklerini belirten bir XML öğesi gelir. Bir SOAP zarfı, bir başlık (ancak bu durumda değil) ve ardından bir SOAP gövdesi içerebilir. Örneğimizde gövde GetLastTradePrice talebini ve kendisi için en son fiyatların talep edildiği hisse senedi sembolünü içermektedir. Bu sorguya verilecek yanıt aşağıdaki gibi görünebilir.
HTTP/1.1 200 Tamam
içerik türü: metin/xml; karakter kümesi = "utf-8"
İçerik Uzunluğu: nnnn
Yine ilk üç satır HTTP başlığının bir parçasıdır; SOAP mesajının kendisi, orijinal isteğe verilen yanıtı içeren, GetLastTradePriceResponse etiketli ve dönüş değerini (bizim durumumuzda 34.5) içeren bir zarftan oluşur.
SABUN Nedir?
SOAP, Basit Nesne Erişim Protokolü (Basit Nesne Erişim Protokolü) anlamına gelir. Umarım makaleyi okuduktan sonra sadece kafanız karışır: "Bu garip isim nedir?"
Mevcut haliyle SOAP, bir ağ üzerinden uzaktan prosedür çağrısı (RPC) yöntemidir. (Evet, aynı zamanda belgeleri XML olarak iletmek için de kullanılır, ancak şimdilik bunu atlayacağız.)
Hadi çözelim. Belirli bir hisse senedi (hisse senedi sembolü) için hisse senedi fiyatını döndüren bir hizmetiniz olduğunu düşünün. Verileri Nasdaq sitesine gönderir ve döndürülen verilere göre üretir. HTML gerekli sonuç. Ayrıca diğer geliştiricilerin kendi uygulamalarında kullanabilmesi için bu hizmeti internet üzerinden fiyat teklifleri hakkında bilgi bulan bir bileşen haline getiriyorsunuz. Bir gün Nasdaq sayfalarının düzenini değiştirene kadar harika çalışıyor. Bileşenin tüm mantığını gözden geçirmeniz ve onu kullanan tüm geliştiricilere güncellemeler göndermeniz gerekir. Ve onların da tüm kullanıcılarına güncelleme göndermeleri gerekiyor. Bu durum az çok düzenli olarak gerçekleşirse, geliştirici arkadaşlarınız arasında birçok düşman edinebilirsiniz. Ve bildiğiniz gibi programcılar arasında şakalar kötüdür. Yarın ofisteki öğütücüden en sevdiğiniz kedinin fotoğrafını çekmek istemezsiniz, değil mi?
Ne yapalım? Bakalım... ihtiyacınız olan tek şey, girdi olarak bir hisse senedi fiyatını (string tipinde) alan ve bir hisse senedi teklifi (float veya double tipinde) döndürecek bir fonksiyon sağlamaktır. Peki geliştiricilerinizin bir şekilde bu işlevi web üzerinden çağırmasına izin vermek daha kolay olmaz mıydı? Harika! Benim için de yeni bir haber, yıllardır bunu yapan COM, Corba ve Java var… Doğru olan doğru, ancak bu yöntemler kusursuz değil. Uzaktan kurulum COM önemsiz değil. Ayrıca güvenlik duvarında mümkün olduğu kadar çok bağlantı noktası açmanız gerekir. sistem yöneticisi yeterince bira alamıyorum. Evet ve tüm kullanıcıları unutmalısınız işletim sistemleri Windows hariç. Ancak sonuçta Linux kullanıcıları da bazen borsayla ilgileniyor.
Linux kullanıcıları DCOM kullanıyorlarsa her şey kaybolmaz; daha fazlası burada: http://www.idevresource.com/com/library/res/articles/comonlinux.asp.
Corba ve Java hakkında fazla bir şey söyleyemem, bu nedenle alıştırma olarak okuyuculara bu yaklaşımların eksilerini bulmalarını öneriyorum.
SOAP, böyle bir uzaktan aramayı ve sonucun döndürüleceği formu tanımlamanıza olanak tanıyan bir standarttır. Bu nedenle, işlevinizi ağ üzerinden kullanılabilen bir uygulamada barındırmanız ve çağrıları SOAP paketleri biçiminde almanız gerekir. Bundan sonra girişi doğrularsınız, işlevinizi çalıştırırsınız ve sonucu yeni bir SOAP paketinde döndürürsünüz. Tüm süreç HTTP üzerinden yürütülebilir, dolayısıyla güvenlik duvarında çok sayıda bağlantı noktası açmanıza gerek kalmaz. Basit mi?
Bu makale ne hakkında
Bu, Agni Software'de SOAP üzerine yazdığımız bir dizi makalenin ilkidir. Bu yazımda sizlere SOAP'ın ne olduğu ve SOAP sunucusu ile haberleşen bir uygulamanın nasıl yazılacağı hakkında fikir vermeye çalışacağım.Sabun ve XML
Eğer SOAP size hala basit geliyorsa XML ekleyelim. Artık bir işlev adı ve parametreleri yerine, sanki kafanızı karıştırmak için tasarlanmış gibi oldukça karmaşık bir XML zarfı elde ediyoruz. Ama korkma. Daha fazlası gelecek ve SOAP'ın karmaşıklığını anlamak için resmin tamamını görmeniz gerekiyor.XML'in ne olduğunu bilmiyorsanız öncelikle buradaki XML makalemi okuyun: http://www.agnisoft.com/white_papers/xml_delphi.asp.
Tüm SOAP paketlerinde XML biçimi. Bu ne anlama geliyor? Görelim. Bu fonksiyona bir göz atın (Pascal):
function GetStockQuote(Sembol: string) : double; Harika görünüyor ama sorun şu ki Pascal. Ne işe yarar basit tanım bir Java geliştiricisi için mi? Veya VB ile çalışan biri için mi? Herkesin, hatta VB programcılarının bile anlayabileceği bir şeye ihtiyacımız var. Bu yüzden onlara aynı bilgileri (parametreler, hisse senedi fiyatları vb.) içeren XML verin. Temelde işlevinize yapılan bir çağrı olan ve herhangi bir platformdaki herhangi bir uygulamanın anlayabilmesi için XML'e sarılmış bir SOAP paketi oluşturursunuz. Şimdi SOAP çağrımızın neye benzediğine bakalım:
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
Bilgilendirici, değil mi? SABUN gözlerimizin önünde basitleşiyor. Tamam, şaka bir yana. Şimdi sizlere bu SOAP çağrısını nasıl anlamanız gerektiğini anlatmaya çalışacağım.
Etiket şifre çözme
Gözünüze çarpan ilk etiketBir sonraki etiket
Listedeki bir sonraki etiket –
Ad alanlarıyla ilgili bir ek not: Ad alanı, bir XML etiketini nitelendirmenize olanak tanır. Örneğin aynı prosedürde aynı isimde iki değişkene sahip olamazsınız ancak bunlar iki farklı prosedürdeyse sorun yoktur. Dolayısıyla bir prosedür, içindeki tüm adlar benzersiz olduğundan bir ad alanıdır. Benzer şekilde, XML etiketleri ad alanlarının kapsamındadır, dolayısıyla bir ad alanı ve etiket adı verildiğinde, onu benzersiz bir şekilde tanımlayabiliriz. NS1'imizi kopyalarından ayırmak için bir ad alanını URI olarak tanımlayacağız. Yukarıdaki örnekte NS1, urn:xmethods-quotes'a işaret eden bir takma addır.
Ayrıca encodingStyle niteliğine de dikkat edin; bu nitelik, SOAP çağrısının nasıl serileştirildiğini belirtir.
Etiketin içinde
xsi:type="xsd:dize"
Bu, kabaca XML'in türleri nasıl tanımladığıdır. (Teknoloji hakkında genelleme yaparken "yaklaşık olarak" kelimesini ne kadar akıllıca kullandığıma dikkat edin; bu, makale yayınlandıktan sonra değişebilir.) Bu tam olarak ne anlama geliyor: xsi ad alanında tanımlanan ve etikette tanımlandığını fark ettiğiniz tür
Etiketin içinde
Sonunda düzgün insanlar gibi tüm etiketleri kapattık.
Böylece SOAP sunucusuna yapılan çağrıyı tanımlayan SOAP paketini bulduk. XML ayrıştırıcıları, kırmızı bir düğme ve MIR uzay istasyonunu kullanan SOAP sunucusu bu çağrının kodunu çözer ve bir hisse senedi fiyatına ihtiyacınız olduğunu belirler. Gerekli teklifi anında bulur ve size şu formda geri gönderir:
Çoğu ticari sunucu, son hissenin hangi para biriminde ve hangi fiyattan satın alındığı gibi çok daha fazla bilgi döndürür. Ve belki de hisse fiyatı daha kesin olacaktır.
Bu şekilde SOAP sunucusunun ne beklediğini ve ne döndüreceğini biliyoruz. Peki bu bilgiyi NASIL gönderiyorsunuz? Herhangi bir ulaşım kullanılabilir. En çok aydınlatılan HTTP'dir. HTTP'nin detaylarına girmeyeceğim, bilmeyenler için tarayıcınızın ziyaret ettiğiniz sitelerle iletişim kurmak için kullandığı şeydir.
gerekli HTTP isteğişöyle görünecek:
POST /StockQuote HTTP/1.1
Ana bilgisayar: www.stockquoteserver.com
İçerik Uzunluğu: nnnn
SOAPAction: "Bazı URI"
Sabun istek paketi burada... Dikkat edilmesi gereken diğer tek şey SOAPAction başlığıdır. Bu başlık isteğin amacını belirtir ve gereklidir. Her SOAP sunucusu sınırsız sayıda işleve sahip olabilir ve hangi işlevin çağrıldığını belirlemek için SOAPAction başlığını kullanabilir. Güvenlik duvarları ve çoklayıcılar da içeriği bu başlığa göre filtreleyebilir.
gelen SOAP yanıtı HTTP sunucularışöyle görünecek:
HTTP/1.1 200 Tamam
İçerik Türü: metin/xml; karakter kümesi = "utf-8"
İçerik Uzunluğu: nnnn
Soap Response paketi burada... Neden HTTP? İlk önce, ağ yöneticileri SOAP çağrıları için çok sayıda ayrı bağlantı noktası açmanıza gerek yok... web sunucusu çağrıları gayet iyi işleyebilir çünkü Bağlantı noktası 80 genellikle gelen istekleri almak üzere herkese açıktır. Diğer bir avantaj ise web sunucularının CGI, ISAPI ve diğer yerel modülleri kullanarak genişletilebilirliğidir. Bu genişletilebilirlik, diğer web içeriğini etkilemeden SOAP isteklerini işleyen bir modül yazmanıza olanak tanır.
Bu kadar
Umarım bu makale SOAP'a biraz ışık tutmaya yardımcı olmuştur. Hala buradaysanız ve bu konu hakkında daha fazlasını okumak istiyorsanız yazarın sitesini ziyaret edin: http://www.agnisoft.com/soap
şapkalar 23 Temmuz 2013, 13:09
PHP'de SOAP istemci-sunucu uygulaması yazma
- PHP
- öğretici
Herkese selam!
Öyle oldu ki Son zamanlarda Web servisleri geliştirmeye başladım. Ancak bugünkü konu benimle ilgili değil, SOAP 1.2 protokolünü temel alarak kendi XML Web Servisimizi nasıl yazabileceğimizle ilgili.
Umarım konuyu okuduktan sonra şunları yapabileceksiniz:
- bir web uygulamasının kendi sunucu uygulamasını yazın;
- bir web uygulamasının kendi istemci uygulamasını yazın;
- kendi web hizmeti açıklamanızı (WSDL) yazın;
- istemci tarafından sunucuya aynı türden veri dizileri gönderilir.
1 Sorun bildirimi
1.1 Sınırlar
Başlangıçta konunun sonunda elde edeceğimiz sonuçla ilgilenmeyi öneriyorum. Yukarıda da duyurduğumuz gibi sms mesaj göndermek için bir servis yazacağız, daha doğrusu SOAP protokolünü kullanarak farklı kaynaklardan mesaj alacağız. Bundan sonra sunucuya hangi biçimde geldiklerini ele alacağız. Sağlayıcıya daha fazla gönderilmek üzere mesajları sıraya alma süreci maalesef birçok nedenden dolayı bu yazının kapsamı dışındadır.
1.2 Hangi veriler değiştirilecek?
Tamam, sınırlarımız var! Yapılması gereken bir sonraki adım, sunucu ve istemci arasında hangi veri alışverişini yapacağımıza karar vermektir. Bu konuda uzun süre daha akıllı olmamayı ve ana soruları hemen kendiniz cevaplamayı öneriyorum:- Bir aboneye SMS mesajı göndermek için sunucuya hangi minimum verilerin gönderilmesi gerekir?
- İstemcinin ihtiyaçlarını karşılamak için sunucudan gönderilmesi gereken minimum veri miktarı nedir?
- sayı cep telefonu, Ve
- SMS metni.
- SMS mesajının gönderildiği tarih.
- Mesaj tipi.
Ama yine de bir şeyi unuttum! Biraz daha düşünürsek, istemcinin sunucuya aynı anda bir SMS mesajı veya belirli sayıda SMS mesajı gönderebileceğini belirtmekte fayda var. Başka bir deyişle, bir veri paketinde birden sonsuza kadar mesaj bulunabilir.
Sonuç olarak, bir SMS mesajı göndermek için aşağıdaki verilere ihtiyacımız olduğunu anlıyoruz:
- Cep telefonu numarası,
- sms metni,
- bir aboneye SMS mesajı gönderme zamanı,
- mesaj tipi.
Birinci soruyu cevapladık, şimdi ikinci soruyu cevaplamak gerekiyor. Ve belki de biraz hile yapmama izin vereceğim. Bu nedenle, sunucudan yalnızca değeri aşağıdaki anlama gelen boole verileri göndereceğiz:
- DOĞRU - paket sunucuya başarıyla ulaştı, kimlik doğrulamayı geçti ve sms sağlayıcısına gönderilmek üzere sıraya alındı
- YANLIŞ - diğer tüm durumlarda
Bu, sorun bildiriminin açıklamasını tamamlıyor! Ve son olarak, en ilginç kısma geçelim - bu SABUN'un ne tür tuhaf bir canavar olduğunu bulacağız!
2 SABUN Nedir?
Genel olarak, başlangıçta SOAP'ın ne olduğu hakkında hiçbir şey yazmayı planlamadım ve kendimi gerekli spesifikasyonları içeren w3.org sitesine olan bağlantıların yanı sıra Wikipedia bağlantılarıyla sınırlamak istedim. Ancak en sonunda bu protokol hakkında kısa bir referans yazmaya karar verdim.Ve hikayeme, bu veri alışverişi protokolünün, antipodu REST (Temsili Durum Transferi, temsili durum transferi) olan RPC (Uzaktan Prosedür Çağrısı) paradigmasına dayanan bir protokol alt kümesine ait olduğu gerçeğiyle başlayacağım. Bununla ilgili daha fazla bilgiyi Wikipedia'da okuyabilirsiniz, makalelere bağlantılar konunun en sonundadır. Bu makalelerden şunu anlamamız gerekiyor: “RPC yaklaşımı, az miktarda ağ kaynağını büyük miktar yöntemler ve karmaşık protokol. REST yaklaşımında, yöntemlerin sayısı ve protokolün karmaşıklığı ciddi şekilde sınırlıdır ve bu da çok sayıda bireysel kaynağa yol açabilir." Yani bizimle ilgili olarak bu, RPC yaklaşımı durumunda sitede her zaman hizmete bir giriş (bağlantı) olacağı ve verilerle birlikte ilettiğimiz gelen verileri işlemek için hangi prosedürün çağrılacağı anlamına gelir, REST yaklaşımıyla sitemizde her biri yalnızca belirli verileri kabul eden ve işleyen çok sayıda giriş (bağlantı) bulunur. Eğer okuyan biri bu yaklaşımların farkını daha da kolay anlatmayı biliyorsa, yorumlara yazmayı unutmayın!
SOAP hakkında bilmemiz gereken bir sonraki şey, bu protokolün aktarımla aynı XML'i kullanmasıdır ki bu bir yandan çok iyidir, çünkü. cephaneliğimiz, sunucu tarafından alınan verilerin otomatik olarak doğrulanmasına olanak tanıyan, bir XML belgesinin yapısını açıklayan bir dil olan (Wikipedia sayesinde!) XML-Şema adı verilen bu işaretleme diline dayanan teknoloji yığınının tam gücünü anında içerir. müşterilerden.
Artık SOAP'ın uzaktan prosedür çağrısını uygulamak için kullanılan protokol olduğunu ve aktarım olarak XML'i kullandığını biliyoruz! Wikipedia'daki makaleyi okursanız, oradan bunun yalnızca HTTP ile eşleştirilmekle kalmayıp herhangi bir uygulama katmanı protokolü üzerinden de kullanılabileceğini öğrenebilirsiniz (maalesef bu konuda yalnızca HTTP üzerinden SOAP'ı ele alacağız). Ve tüm bunların en çok neyi hoşuma gidiyor biliyor musun? Tahmin yoksa sana bir ipucu vereceğim - SABUN!… Zaten tahmin de yok mu?… Wikipedia'daki makaleyi kesinlikle okudun mu?… Genel olarak sana daha fazla işkence etmeyeceğim. Bu nedenle hemen cevaba geçeceğim: “SOAP (İngilizce'den. Basit Nesne Erişim Protokolü - basit bir protokol nesnelere erişim; spesifikasyon 1.2'ye kadar)". Bu satırın öne çıkan kısmı italiktir! Tüm bunlardan ne gibi sonuçlar çıkardığınızı bilmiyorum, ancak şunu görüyorum - bu protokol hiçbir şekilde "basit" olarak adlandırılamayacağından (ve görünüşe göre w3 bile bununla aynı fikirde), o zaman sürüm 1.2'den beri olmaktan çıktı tamamen şifresi çözüldü! Ve SABUN olarak tanındı, sadece SABUN ve nokta.
Tamam, kusura bakmayın, biraz yana kaydım. Daha önce de yazdığım gibi XML aktarım olarak kullanılıyor ve istemci ile sunucu arasında çalışan paketlere SOAP zarfları adı veriliyor. Zarfın genel yapısını düşünürsek, size çok tanıdık gelecektir çünkü HTML sayfasının yapısına benzer. Bir ana bölümü var - Zarf bölümleri içeren başlık Ve Vücut, veya Arıza. İÇİNDE Vücut veri iletilir ve zarfın zorunlu bir bölümüdür. başlıkİsteğe bağlı. İÇİNDE başlık yetkilendirme veya web hizmeti prosedürlerinin giriş verileriyle doğrudan ilgili olmayan herhangi bir veri iletilebilir. Profesyonel Arıza Herhangi bir hata durumunda sunucudan istemciye gelmesi dışında söylenecek özel bir şey yok. 
SOAP protokolü hakkındaki genel bakış hikayem burada bitiyor (istemcimiz ve sunucumuz nihayet onları birbirleriyle nasıl çalıştıracaklarını öğrendiklerinde zarfların kendilerine ve yapılarına daha ayrıntılı olarak bakacağız) ve yeni bir SOAP arkadaşı hakkında başlıyor. isminde WSDL(Web Hizmetleri Açıklama Dili). Evet, evet, çoğumuzu bu protokol üzerinde kendi API'mizi alıp uygulama girişiminden korkutan şey budur. Sonuç olarak, genellikle taşıma aracı olarak JSON ile tekerleğimizi yeniden icat ediyoruz. Peki WSDL nedir? WSDL, web servislerini tanımlamak ve bunlara erişmek için kullanılan bir dildir. XML dili(c) Vikipedi. Bu tanımdan bu teknolojinin tüm kutsal anlamı sizin için netleşmiyorsa, o zaman onu kendi kelimelerimle anlatmaya çalışacağım!
WSDL, müşterilerimizin sunucuyla normal şekilde iletişim kurmasına olanak sağlayacak şekilde tasarlanmıştır. Bunun için “*.wsdl” uzantılı dosyada aşağıdaki bilgiler anlatılmaktadır:
- Hangi ad alanlarının kullanıldığı,
- Hangi veri şemalarının kullanıldığı,
- Web hizmetinin istemcilerden ne tür mesajlar beklediğini,
- Hangi verinin hangi web servis prosedürlerine ait olduğu,
- Web servisin hangi prosedürleri içerdiği,
- Müşteri web servis prosedürlerini nasıl çağırmalı,
- Müşteri çağrılarının hangi adrese gönderilmesi gerektiği.
3 XML Şemasına Giriş
Artık SOAP'ın ne olduğu, içinde ne olduğu hakkında çok şey biliyoruz ve onu ne tür bir teknoloji yığınının çevrelediğine dair genel bir bakışa sahibiz. Çünkü her şeyden önce SOAP, istemci ile sunucu arasındaki etkileşimin bir yöntemidir ve dil bunun için bir aktarım olarak kullanılır. XML işaretlemesi, o zaman bu bölümde XML şemaları aracılığıyla otomatik veri doğrulamanın nasıl gerçekleştiğini biraz anlayacağız.Şemanın asıl görevi işleyeceğimiz verinin yapısını tanımlamaktır. XML şemalarındaki tüm veriler aşağıdakilere bölünmüştür: basit(skaler) ve karmaşık(yapılar) türleri. Basit türler aşağıdaki türleri içerir:
- astar,
- sayı,
- boole,
- Tarihi.
Fazla ileri gitmemenizi ve sms mesajımız için bir XML şeması yazmanızı öneriyorum! Aşağıda sms mesajının xml açıklaması bulunmaktadır:
Karmaşık tip şemamız şöyle görünecek:
Bu girdi şu şekildedir: bir değişkenimiz var " İleti" tip " İleti" ve " adında karmaşık bir tür var İleti" sıralı bir dizi öğeden oluşur " telefon" tip sicim, « metin" tip sicim, « tarih" tip tarihSaat, « tip" tip ondalık. Bu türler basittir ve şema tanımında zaten tanımlanmıştır. Tebrikler! Az önce ilk XML Şemamızı yazdık!
Bence elementlerin anlamı " eleman" Ve " karmaşık Tür» her şey az çok sizin için netleşti, bu yüzden artık bunlara odaklanmayacağız ve hemen besteci unsuruna geçmeyeceğiz « sekans". Besteci öğesini kullandığımızda " sekans» İçerisindeki elemanların her zaman şemada belirtilen sırada olması gerektiğini ve hepsinin zorunlu olduğunu bildiririz. Ama umutsuzluğa kapılmayın! XML Şemalarında iki besteci öğesi daha vardır: seçenek" Ve " Tümü". Besteci seçenek" İçinde listelenen öğelerden birinin ve bestecinin olması gerektiğini belirtir " Tümü» – listelenen öğelerin herhangi bir kombinasyonu.
Hatırlarsınız konunun ilk bölümünde paketin sms mesajlarının birden sonsuza kadar iletilebileceği konusunda anlaşmıştık. Bu nedenle, bu tür verilerin XML şemasında nasıl bildirildiğini anlamayı öneriyorum. Genel yapı paket şöyle görünebilir:
Böyle karmaşık bir türün şeması şöyle görünecektir:
İlk blok, “karmaşık türün tanıdık bildirimini içerir” İleti". Dikkat ederseniz, " içinde yer alan her basit türde İleti”, yeni nitelikli özellikler eklendi” dkOluşur" Ve " maxOccurs". İsminden tahmin etmek zor olmadığından ilki ( dkOluşur) verilen dizinin " türünden en az bir öğe içermesi gerektiğini belirtir telefon», « metin», « tarih" Ve " tip”, sonraki ( maxOccurs) niteliği bize dizimizde böyle bir öğenin en fazla olduğunu bildirir. Sonuç olarak, herhangi bir veri için şemalarımızı yazdığımızda, bunları nasıl yapılandıracağımız konusunda bize en geniş seçenek sunulur!
Şemanın ikinci bloğu "öğesini bildirir" mesajListesi" tip " Mesaj Listesi". Şu açık ki" Mesaj Listesi' en az bir öğe içeren karmaşık bir türdür ' İleti”, ancak bu tür öğelerin maksimum sayısı sınırlı değildir!
4 WSDL'nizi yazma
WSDL'nin web hizmetimiz olduğunu hatırlıyor musunuz? Umarım hatırlarsın! Biz bunu yazarken, küçük web servisimiz onun üzerinde yüzecek. Bu yüzden hile yapmamanızı öneririm.Genel olarak bizim için her şeyin doğru çalışması için istemciye doğru MIME türüne sahip bir WSDL dosyası aktarmamız gerekiyor. Bunu yapmak için web sunucunuzu buna göre yapılandırmanız yani *.wsdl uzantılı dosyalar için MIME türünü aşağıdaki satıra ayarlamanız gerekir:
Uygulama/wsdl+xml
Ancak pratikte genellikle HTTP başlığını PHP aracılığıyla gönderdim " metin/xml»:
Header("Content-Type: text/xml; karakter kümesi=utf-8");
ve her şey harika çalıştı!
Sizi hemen uyarmak istiyorum, basit web servisimizin oldukça etkileyici bir açıklaması olacak, bu yüzden paniğe kapılmayın çünkü. Metnin çoğu zorunlu sudur ve bir kez yazıldığında bir web servisinden diğerine sürekli olarak kopyalanabilir!
WSDL XML olduğundan, ilk satırda doğrudan bunun hakkında yazmanız gerekir. Bir dosyanın kök öğesi her zaman " olarak adlandırılmalıdır tanımlar»:
Genellikle WSDL 4-5 ana bloktan oluşur. İlk blok bir web servisinin tanımı, diğer bir deyişle giriş noktasıdır.
Burada şöyle bir hizmetimiz olduğu yazıyor: " SMS Hizmeti". Prensip olarak, WSDL dosyasındaki tüm adlar sizin tarafınızdan dilediğiniz şekilde değiştirilebilir, çünkü kesinlikle hiçbir rol oynamazlar.
Bundan sonra bunu web servisimizde beyan ederiz " SMS Hizmeti" " adı verilen bir giriş noktası ("liman") var SmsServicePort". İstemcilerden sunucuya gelen tüm istekler bu giriş noktasına gönderilecektir. Ve " öğesinde belirtiyoruz adres» istekleri kabul edecek bir işleyici dosyasına bağlantı.
Bir web hizmeti tanımladıktan ve bunun için bir giriş noktası belirledikten sonra, desteklenen prosedürleri buna bağlamamız gerekir:
Bunun için y'nin hangi işlemlerle ve hangi biçimde çağrılacağını listeler. Onlar. liman için SmsServicePort» « adında bir bağlama SmsServiceBinding", çağrı türüne sahip olan" rpc” ve aktarım protokolü (aktarım) olarak HTTP kullanılır. Böylece HTTP üzerinden RPC çağrısı yapacağımızı burada belirtmiş olduk. Bundan sonra hangi prosedürleri açıklayacağız ( operasyon) web hizmetinde desteklenir. Yalnızca tek bir prosedürü destekleyeceğiz - " SMS gönder". Bu prosedür sayesinde harika mesajlarımız sunucuya gönderilecektir! İşlem ilan edildikten sonra verilerin hangi formda iletileceğinin belirtilmesi gerekmektedir. Bu durumda standart SOAP zarflarının kullanılacağı belirtiliyor.
Bundan sonra prosedürü mesajlara bağlamamız gerekiyor:
Bunu yapmak için bağlamamızın ("bağlama") " türünde olduğunu belirtiriz SmsServicePortType" ve öğenin içinde " bağlantı noktası türü» aynı tür adı ile prosedürlerin mesajlara bağlanmasını belirtin. Ve böylece, gelen mesaj (istemciden sunucuya) " olarak adlandırılacaktır. SmsTalebi gönder"ve giden (sunucudan istemciye)" SmsYanıt gönder". WSDL'deki tüm adlar gibi, gelen ve giden mesajların adları da isteğe bağlıdır.
Şimdi mesajların kendisini tanımlamamız gerekiyor; giren ve çıkan:
Bunu yapmak için öğeleri ekliyoruz " İleti» isimlerle « SmsTalebi gönder" Ve " SmsYanıt gönder" sırasıyla. Bunlarda girişe, yapısı veri tipine uygun bir zarf gelmesi gerektiğini belirtiyoruz " Rica etmek". Bundan sonra sunucudan veri türünü içeren bir zarf döndürülür - " Cevap».
Şimdi biraz yapmamız gerekiyor; bu türlerin açıklamalarını WSDL dosyamıza ekleyin! Peki sizce WSDL gelen ve giden verileri nasıl tanımlıyor? Sanırım uzun zamandır her şeyi anladınız ve bunu XML şemalarının yardımıyla kendinize söylediniz! Ve kesinlikle haklı olacaksın!
Bizi tebrik edebilirsiniz! İlk WSDL'miz yazıldı! Ve hedefimize ulaşmaya bir adım daha yaklaştık.
Daha sonra PHP'nin kendi dağıtılmış uygulamalarımızı geliştirmemiz için bize neler sağladığıyla ilgileneceğiz.
5 İlk SOAP sunucumuz
Daha önce PHP'de bir SOAP sunucusu oluşturmak için yerleşik SoapServer sınıfını kullanacağımızı yazmıştım. Herşey için daha fazla eylemler benimkinin aynısı oldu, PHP'nizi biraz değiştirmeniz gerekecek. Daha da kesin olmak gerekirse, "php-soap" uzantısının kurulu olduğundan emin olmanız gerekir. Bunu web sunucunuza nasıl koyacağınızı en iyi resmi PHP web sitesinde okumaktır (referanslara bakın).Her şey yüklenip yapılandırıldıktan sonra “dosyayı oluşturmamız gerekecek” smsservice.php» aşağıdaki içeriğe sahip:
setClass("SoapSmsGateWay"); //Sunucuyu başlat $sunucu->tanımlayıcı();
“ini_set” işleviyle çizginin üstünde ne olduğunu umarım açıklamaya gerek yoktur. Çünkü sunucudan istemciye hangi HTTP başlıklarını göndereceğimizi tanımlar ve ortamı yapılandırır. "ini_set" satırında, WSDL dosyasının önbelleğe alınmasını devre dışı bırakıyoruz, böylece dosyada yaptığımız değişiklikler istemcide anında etkili olur.
Şimdi sunucuya geliyoruz! Gördüğünüz gibi SOAP sunucusunun tamamı yalnızca üç satır uzunluğunda! İlk satırda SoapServer nesnesinin yeni bir örneğini oluşturuyoruz ve WSDL web servis açıklamamızın adresini onun yapıcısına aktarıyoruz. Artık bunun barındırma kökünde bir dosyada yer alacağını biliyoruz. konuşan isim « smsservice.wsdl.php". İkinci satırda SOAP sunucusuna istemciden gelen zarfı işleyebilmesi ve zarfı yanıtla birlikte geri gönderebilmesi için hangi sınıfın çekilmesi gerektiğini söylüyoruz. Tahmin edebileceğiniz gibi, tek yöntemimiz bu sınıfta anlatılacak. SMS gönder. Üçüncü satırda sunucuyu başlatıyoruz! Her şey, sunucumuz hazır! Bu nedenle hepimizi tebrik ediyorum!
Şimdi bir WSDL dosyası oluşturmamız gerekiyor. Bunu yapmak için, önceki bölümden içeriğini kopyalayabilir veya özgürce davranıp biraz "şablon" oluşturabilirsiniz:
";
?>
Bu aşamada ortaya çıkan sunucunun tam olarak bize uyması gerekiyor çünkü. kendisine gelen zarfları kaydedip ardından gelen verileri sakin bir şekilde analiz edebiliyoruz. Sunucudan herhangi bir şey alabilmemiz için bir istemciye ihtiyacımız var. Öyleyse onlarla devam edelim!
6 SOAP istemcisi yolda
Öncelikle clienti yazacağımız bir dosya oluşturmamız gerekiyor. Her zamanki gibi, onu ana bilgisayarın kökünde oluşturacağız ve adını vereceğiz " client.php”ve içine şunu yazıyoruz: mesajListesi = yeni MesajListesi(); $req->messageList->message = yeni Mesaj(); $req->messageList->message->telefon = "79871234567"; $req->messageList->message->text = "Mesaj 1'i test edin"; $req->messageList->message->date = "2013-07-21T15:00:00.26"; $req->messageList->message->type = 15; $client = new SoapClient("http://($_SERVER["HTTP_HOST"])/smsservice.wsdl.php", array("soap_version" => SOAP_1_2)); var_dump($client->sendSms($req));
Nesnelerimizi tanımlayalım. WSDL'yi yazdığımızda, sunucuya giren zarf için içinde üç varlık tanımlandı: Rica etmek, Mesaj Listesi Ve İleti. Buna göre sınıflar Rica etmek, Mesaj Listesi Ve İleti bu varlıkların PHP betiğimizdeki yansımalarıdır.
Nesneleri tanımladıktan sonra bir nesne oluşturmamız gerekiyor ( $talep), sunucuya gönderilecektir. O zaman gelin bizim için en değerli iki satır! SABUN müşterimiz! İster inanın ister inanmayın, ancak bu, sunucumuzun istemciden mesaj dökmeye başlaması ve ayrıca sunucumuzun bunları başarıyla alıp işlemesi için yeterlidir! Bunlardan ilkinde SoapClient sınıfının bir örneğini oluşturup WSDL dosyasının konumunun adresini yapıcısına aktarıyoruz ve SOAP protokolü sürüm 1.2'yi kullanarak çalışacağımızı parametrelerde açıkça belirtiyoruz. Bir sonraki satırda yöntemi çağırıyoruz SMS gönder nesne $müşteri ve sonucu anında tarayıcıda görüntüleyin.
Hadi çalıştıralım ve sonunda ne elde ettiğimizi görelim!
Sunucudan aşağıdaki nesneyi aldım:
Object(stdClass) public "status" => boolean true
Ve bu harika çünkü. artık sunucumuzun çalıştığından ve sadece çalışmakla kalmayıp aynı zamanda istemciye bazı değerleri de döndürebildiğinden eminiz!
Şimdi sunucu tarafında ihtiyatlı bir şekilde tuttuğumuz loga bakalım! İlk bölümünde sunucuya giren ham verileri görüyoruz:
Bu zarf. Artık neye benzediğini biliyorsun! Ancak ona sürekli hayranlık duymakla ilgilenmemiz pek mümkün değil, bu yüzden nesneyi günlük dosyasından seri durumdan çıkaralım ve her şeyin yolunda olup olmadığını görelim:
Object(stdClass) public "messageList" => object(stdClass) public "mesaj" => object(stdClass) public "telefon" => string "79871234567" (uzunluk=11) public "text" => string "Test mesajı 1 " (uzunluk=37) public "date" => string "2013-07-21T15:00:00.26" (uzunluk=22) public "type" => string "15" (uzunluk=2)
Gördüğünüz gibi nesne doğru bir şekilde seri durumdan çıkarıldı ve bu konuda hepimizi tebrik etmek istiyorum! Sonra bizi daha ilginç bir şey bekliyor! Yani, müşteri tarafından sunucuya bir sms mesajı değil, bütün bir paket (daha kesin olmak gerekirse, üç tam) göndereceğiz!
7 Karmaşık Nesneleri Gönderme
Bir sürü mesajı sunucuya tek bir pakette nasıl gönderebileceğimizi düşünelim. Muhtemelen en kolay yol, messageList öğesinin içinde bir dizi düzenlemek olacaktır! Hadi yapalım:// sunucuya gönderilecek bir nesne oluşturun $req = new request(); $req->messageList = new MesajListesi(); $msg1 = yeni Mesaj(); $msg1->telefon = "79871234567"; $msg1->text = "Mesaj 1'i test edin"; $msg1->tarih = "2013-07-21T15:00:00.26"; $msg1->tür = 15; $msg2 = yeni Mesaj(); $msg2->telefon = "79871234567"; $msg2->text = "Mesaj 2'yi test edin"; $msg2->tarih = "2014-08-22T16:01:10"; $msg2->tür = 16; $msg3 = yeni Mesaj(); $msg3->telefon = "79871234567"; $msg3->text = "Mesaj 3'ü test edin"; $msg3->tarih = "2014-08-22T16:01:10"; $msg3->tür = 17; $req->messageList->mesaj = $msg1; $req->messageList->mesaj = $msg2; $req->messageList->mesaj = $msg3;
Günlüklerimiz aşağıdaki paketin istemciden geldiğini gösteriyor:
Ne saçmalık dedin? Ve bir bakıma haklı olacaksın çünkü. Client'tan hangi nesnenin çıktığını öğrendiğimiz gibi, sunucumuza da aynı formda bir zarf şeklinde geldi. Doğru, sms mesajları XML'de ihtiyacımız olan şekilde serileştirilmedi - öğelere sarılmaları gerekiyordu İleti, değil Yapı. Şimdi böyle bir nesnenin yönteme hangi biçimde geldiğini görelim. SMS gönder:
Object(stdClass) public "messageList" => object(stdClass) public "mesaj" => object(stdClass) public "Struct" => array (size=3) 0 => object(stdClass) public "phone" => string "79871234567" (uzunluk=11) public "text" => string "Test mesajı 1" (uzunluk=37) public "tarih" => string "2013-07-21T15:00:00.26" (uzunluk=22) public " type" => string "15" (uzunluk=2) 1 => object(stdClass) public "phone" => string "79871234567" (uzunluk=11) public "text" => string "Test mesajı 2" (uzunluk= 37) public "date" => string "2014-08-22T16:01:10" (uzunluk=19) public "type" => string "16" (uzunluk=2) 2 => object(stdClass) public "phone " => string "79871234567" (uzunluk=11) public "text" => string "Test mesajı 3" (uzunluk=37) public "tarih" => string "2014-08-22T16:01:10" (uzunluk= 19) public "type" => string "17" (uzunluk=2)
Bu bilgi bize ne veriyor? Sadece seçtiğimiz yol doğru değil ve "Sunucuya nasıl girebiliriz" sorusuna cevap alamadık. doğru yapı veri?" Ancak umutsuzluğa kapılmamanızı ve dizimizi türe göre şekillendirmeye çalışmanızı öneririm. bir obje:
$req->messageList->message = (object)$req->messageList->message;
Bu durumda başka bir zarf alacağız:
Yöntemin içine girdi SMS gönder nesne aşağıdaki yapıya sahiptir:
Object(stdClass) public "messageList" => object(stdClass) public "mesaj" => object(stdClass) public "BOGUS" => array (size=3) 0 => object(stdClass) public "phone" => string "79871234567" (uzunluk=11) public "text" => string "Test mesajı 1" (uzunluk=37) public "tarih" => string "2013-07-21T15:00:00.26" (uzunluk=22) public " type" => string "15" (uzunluk=2) 1 => object(stdClass) public "phone" => string "79871234567" (uzunluk=11) public "text" => string "Test mesajı 2" (uzunluk= 37) public "date" => string "2014-08-22T16:01:10" (uzunluk=19) public "type" => string "16" (uzunluk=2) 2 => object(stdClass) public "phone " => string "79871234567" (uzunluk=11) public "text" => string "Test mesajı 3" (uzunluk=37) public "tarih" => string "2014-08-22T16:01:10" (uzunluk= 19) public "type" => string "17" (uzunluk=2)
Bana gelince, o zaman “terimlerin yerlerindeki değişiklikten toplam değişmez” (c). Ne SAHTE, Ne Yapı Henüz hedefimize ulaşamadık! Ve bunu başarmak için, bu anlaşılmaz isimler yerine yerlimizin olduğundan emin olmalıyız. İleti. Ancak bunun nasıl başarılacağını yazar henüz bilmiyor. Bu nedenle yapabileceğimiz tek şey fazla kaptan kurtulmak. Başka bir deyişle, artık bunun yerine şundan emin olacağız: İleti oldu SAHTE! Bunu yapmak için nesneyi aşağıdaki gibi değiştirin:
// sunucuya gönderilecek bir nesne oluşturun $req = new request(); $msg1 = yeni Mesaj(); $msg1->telefon = "79871234567"; $msg1->text = "Mesaj 1'i test edin"; $msg1->tarih = "2013-07-21T15:00:00.26"; $msg1->tür = 15; $msg2 = yeni Mesaj(); $msg2->telefon = "79871234567"; $msg2->text = "Mesaj 2'yi test edin"; $msg2->tarih = "2014-08-22T16:01:10"; $msg2->tür = 16; $msg3 = yeni Mesaj(); $msg3->telefon = "79871234567"; $msg3->text = "Mesaj 3'ü test edin"; $msg3->tarih = "2014-08-22T16:01:10"; $msg3->tür = 17; $req->messageList = $msg1; $req->messageList = $msg2; $req->messageList = $msg3; $req->messageList = (object)$req->messageList;
Aniden şanslıyız ve plandan vazgeçeceğiz doğru isim? Bunu yapmak için gelen zarfa bakalım:
Evet mucize gerçekleşmedi! SAHTE- kazanamayacağız! Geldi SMS gönder bu durumda nesne şöyle görünecek:
Object(stdClass) public "messageList" => object(stdClass) public "BOGUS" => dizi (boyut=3) 0 => object(stdClass) public "phone" => string "79871234567" (uzunluk=11) public " text" => string "Test mesajı 1" (uzunluk=37) public "tarih" => string "2013-07-21T15:00:00.26" (uzunluk=22) public "type" => string "15" (uzunluk) =2) 1 => object(stdClass) public "phone" => string "79871234567" (uzunluk=11) public "text" => string "Test mesajı 2" (uzunluk=37) public "tarih" => string " 2014-08-22T16:01:10" (uzunluk=19) public "type" => string "16" (uzunluk=2) 2 => object(stdClass) public "phone" => string "79871234567" (uzunluk= 11) public "text" => string "Test mesajı 3" (uzunluk=37) public "tarih" => string "2014-08-22T16:01:10" (uzunluk=19) public "type" => string " 17" (uzunluk=2)
Dedikleri gibi - "Neredeyse"! Bu (biraz üzücü) notu sessizce tamamlamayı ve kendimiz için bazı sonuçlar çıkarmayı öneriyorum.
8 Sonuç
Sonunda buraya geldik! Şimdi ne yapabileceğinize karar verelim:- web hizmetiniz için gerekli WSDL dosyasını yazabilirsiniz;
- SOAP protokolünü kullanarak sunucu ile iletişim kurabilen kendi istemcinizi sorunsuz bir şekilde yazabilirsiniz;
- SOAP aracılığıyla dış dünyayla iletişim kuran kendi sunucunuzu yazabilirsiniz;
- istemcinizden sunucuya aynı türdeki nesnelerin dizilerini gönderebilirsiniz (bazı kısıtlamalarla).
- yerel sınıf SoapClient, XML'de aynı türdeki veri yapılarının doğru şekilde nasıl serileştirileceğini bilmiyor;
- bir diziyi XML'e serileştirirken ürettiği ekstra elemanİsim ile Yapı;
- bir nesneyi XML'e serileştirirken, adında fazladan bir öğe oluşturur. SAHTE;
- SAHTE daha az kötülük Nasıl Yapı zarfın daha kompakt olması nedeniyle (zarfın XML başlığına fazladan ad alanı eklenmez);
- ne yazık ki SoapServer sınıfı zarf verilerini XML şemamızla otomatik olarak doğrulamaz (belki diğer sunucular da doğrulamaz).