Basit Nesne Erişim Protokolü (SOAP) - genel açıklama. WSDL, SABUN ve REST nedir?
Bir önceki bölümde tartışıldığı gibi, Web servisleri istemcilerle ve kendi aralarında mesaj göndererek iletişim kurar. XML dili. Bu XML uygulamasının etiketleri, XML belgesi için biçimlendirme kuralları ve belgelerin değiştirilme sırası SOAP protokolü tarafından tanımlanır. SABUN protokolü Microsoft ve Userland'da Dave Winer liderliğindeki bir geliştirme ekibi tarafından 1998 yılında oluşturuldu. Protokolün adı - "Basit Nesne Erişim Protokolü" - orijinal amacını yansıtır - uzak nesnelerin yöntemlerine erişmek. Protokolün amacı değişti, artık Web hizmetleri ile gevşek bağlı dağıtılmış uygulamaların bileşenleri arasındaki tüm etkileşimler için bir protokol haline geldi. Artık çok basit değil ve nesneler hakkında hiçbir şey söylemiyor. Birçok geliştirici, önceki kısaltmayı bırakarak buna "Hizmet Odaklı Mimari Protokolü" adını vermeyi teklif eder. Bu girişimleri durdurmak için SOAP 1.2 spesifikasyonu, "SOAP" kelimesinin artık hiçbir şekilde kodunun çözülmeyeceğini belirtir.
1999 yılı sonunda protokolün geliştirilmesi W3C konsorsiyumuna (http:// www.w3.org/).
Mayıs 2000'de konsorsiyum, SOAP 1.1 sürümünü yayınladı. SOAP protokolü kullanılarak yazılan bir mesaj, ad alanlarını aktif olarak kullanan bir XML belgesi olarak biçimlendirilir. SOAP 1.1 XML öğesi adları, http://schemas.xmlsoap.org/soap/envelope/ tanımlayıcısına sahip ad alanına başvurur.
SOAP 1.2'nin ikinci sürümünün bir taslağı 2001'de yayımlandı, o sırada ad alanı http://www.w3.org/2001/06/soap-envelope idi.
SOAP sürümünü belirleyenin 1.1 veya 1.2 sayısı değil, ad alanı tanımlayıcısı olduğunu unutmayın. Sunucu SOAP mesajını dikkate almayacak ve fark ederse bir hata mesajı döndürecektir.
ad alanı uyuşmazlığı
Ben bu satırları yazarken, SOAP 1.1 hala çalışıyor. Sürüm 1.2, hazırlık aşamasından çıkamaz, ancak hali hazırda örneğin SOAP::Lite, Apache SOAP 2.3, Apache Axis'te kullanılmaktadır. Bu nedenle, bu bölümde, 1.2 sürümünü sunacağım ve 1.1 sürümünden farklılıklarını belirteceğim.
Şartname çalışan sürüm SOAP her zaman http://www.w3.org/TR/SOAP/ adresinde saklanır. Bu adreste yer alan belgeler, çalışan sürüm değiştirildiğinde yenileri ile değiştirilir.
SOAP'ın taslak sürümü sürekli olarak güncellenir ve ad alanı tanımlayıcısı değişir. Bu yazının yazıldığı sıradaki en yeni taslak sürüm, http://www.w3.org/TR/soapl2-partl/ adresinde saklanıyordu ve kullandığı ad alanı şuydu: http://www.w3.org/2002/06/soap- mektup. SOAP 12 spesifikasyonunun iki bölümden oluştuğunu unutmayın: 1. bölüm ve 2. bölüm. Spesifikasyonun ikinci kısmı - uygulama - karmaşık veri türlerini yazmak için kurallar içerir. Spesifikasyonun bir partO bölümü daha vardır - SOAP 1.2 kurallarına göre oluşturulmuş mesaj örnekleri.
SOAP mesaj yapısı
Spesifikasyon, bir SOAP mesajını şu şekilde tanımlar: XML belgesi Belge türü bildirimi veya işleme yönergeleri içermeyen A. Bu XML belgesinin kök elemanına denir
ve diğer ön ekli nitelikler. Kök öğe, mesaj başlığını içeren isteğe bağlı bir öğe ve bir gerekli öğe içerir.
, mesajın içeriğinin yazıldığı yer. Sürüm 1.1'e gövdeden sonra izin verilir yazmak keyfi unsurlar, adlarının önüne eklenmelidir. Sürüm 1.2, öğeden sonra herhangi bir şey yazmayı yasaklar . Kısaca, bir SOAP mesajının genel yapısı şöyledir: xmlns:env="http://www.w3.org/2002/06/soap-envelope"> < ! - Блоки заголовка -> eleman Bunun nedeni, bir SOAP mesajının birden çok SOAP sunucusundan veya aynı sunucudaki birden çok uygulamadan geçebilmesidir. Bu uygulamalar mesajın başlık bloklarını önceden işler ve birbirlerine iletir. Tüm bu sunucular ve/veya uygulamalar, SOAP düğümleri olarak adlandırılır. SOAP spesifikasyonu, bir mesajı bir sunucu zincirinden geçirmek için kurallar tanımlamaz. Bunun için Microsoft WS-Routing gibi başka protokoller geliştirilmektedir. aktör özniteliği hedef SOAP düğümünü belirtir - zincirin sonunda başlığı bütünüyle işleyecek düğüm. Anlam aktör özniteliği, başlığı alacak ilk sunucunun başlığı işleyeceğini belirtir.Actor özniteliği, o bloğu işleyen düğümü belirterek ayrı başlık bloklarında görünebilir. İşlemden sonra, blok SOAP mesajından kaldırılır. 1.2 sürümünde aktör özniteliği, rol özniteliğiyle değiştirilmiştir, çünkü bu SOAP sürümünde her düğüm bir veya daha fazla rol oynar. Şu ana kadarki belirtim, üç SOAP düğümü rolü tanımlıyor. http://^^.w3.org/2002/06/soap-envelope/role/ultimateReceiver rolü, başlığı işleyecek olan nihai hedef düğüm tarafından oynanır. http://www.w3.org/2002/06/soap-envelope/role/next rolü, bir ara düğüm veya hedef düğüm tarafından oynanır. Böyle bir düğüm başka ek roller oynayabilir. http://www.w3.org/2002/06/soap-envelope/role/none rolü herhangi bir SOAP düğümü tarafından oynanmamalıdır. Dağıtılmış uygulamalar, ihtiyaçlarına göre bu rollere başka roller ekleyebilir, örneğin, kontrol eden bir ara sunucu tanıtabilir. elektronik imza ve bu rolü onun için bir URI dizesiyle tanımlayın. Rol özniteliğinin değeri, bu başlık bloğunun amaçlandığı düğümün rolünü gösteren herhangi bir URI dizesi olabilir. Bu öznitelik için varsayılan değer boş değerdir, yani yalnızca bir çift tırnak veya http://\vw\v.w3.org/2002/06/soap-envelope/rale/ultimateReceiver URI dizesidir. Rol özniteliğinin değeri, bloğun aynı dize tarafından belirtilen rolü oynayan düğüm tarafından işlenmesi gerektiğini belirtir. Başka bir öğe özelliği SOAP 1.2'de o sayısı yerine false kelimesini, 1 sayısı yerine de true kelimesini yazmanız gerekiyor. Başlık gövdesinde Listeleme 3.1. Tek bloklu başlık xmlns:t="http://some.com/transaction" env:role= "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver" env:mustUnderstand="1"> Başlık bloklarında iç içe geçmiş öğeler artık blok olarak adlandırılmaz. Rol, aktör ve mustunderstand niteliklerini içeremezler. eleman Hata mesajı SOAP sunucusu, aldığı SOAP mesajını işlerken bir hata fark ederse, işlemeyi durduracak ve SOAP mesajını, gövdesine bir öğe yazacağı istemciye gönderecektir. SOAP 1.1 sürümünün eleman gövdesinde yazılan mesajda, Aşağıdaki iç içe öğelerle açıklanan dört bölüm vardır. Hata kodu Hata tanımlaması Hatanın yeri Hata detayları Örneğin: xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> SOAP sürüm 1.2, öğenin içeriğini Açıklandığı gibi değiştirdi ad alanı http://www.w3.org/2002/06/soap-envelope, iki gerekli öğeye ve üç isteğe bağlı öğeye sahiptir. Zorunlu unsurlar. Hata kodu hata nedeni İsteğe bağlı öğeler. ? ? ? Liste 3.2, prosedürü yürütmeye çalışırken oluşan hata mesajını gösterir. Hata, prosedür bağımsız değişken adlarının SOAP mesajında yanlış yazılması ve prosedürün bunları anlayamamasıdır. Listeleme 3.2. Hata mesajı xmlns:env="http://www.w3.org/2002/06/soap-envelope" xmlns:rpc='http://www.w3.org/2002/06/soap-rpc'> xmlns:e="http://www.example.org/faults"> Hata türleri Hata kodlarının listesi sürekli değişiyor ve genişliyor. Sürüm 1.1, dört tür hata tanımlar. VersionMismatch - Ad alanı tanınmıyor. Belki güncelliğini yitirmiştir veya adı yanlış yazılmıştır. MustUnderstand - 1 değeriyle mustUnderstand özniteliğiyle işaretlenmiş bir başlık bloğu, belge şemasında tanımlanan sözdizimine uymuyor. İstemci - Mesajı içeren XML belgesi bozuk ve bu nedenle sunucu onu işleyemiyor. İstemci mesajı değiştirmelidir. Sunucu - sunucu, kendi dahili nedenlerinden dolayı doğru şekilde kaydedilmiş bir mesajı işleyemez. Sürüm 1.2, beş tür hata tanımlar. VersionMismatch - Ad alanı tanınmıyor. Belki güncelliğini yitirmiştir veya adı yanlış yazılmıştır veya mesaj, o ad alanında tanımlanmamış bir XML öğesi adıyla karşılaşmıştır. Sunucu, öğeyi yanıt başlığına yazar MustUnderstand - mustunderstand özniteliği true olarak ayarlanmış olarak işaretlenmiş bir başlık bloğu, belge şemasında tanımlanan sözdizimine uymuyor. Sunucu, öğeleri yanıt başlığına yazar DataEncodingUnknown - mesajda anlaşılmaz veriler bulundu, belki bilinmeyen bir kodlamayla yazılmışlardır. Gönderen - Mesajı içeren XML belgesi bozuk ve bu nedenle sunucu onu işleyemiyor. İstemci mesajı değiştirmelidir. Alıcı - sunucu, kendi dahili nedenlerinden dolayı doğru şekilde kaydedilmiş bir mesajı işleyemiyor, örneğin gerekli XML ayrıştırıcısı eksik. Sunucu, bu tür hatalara kendi hata türlerinden bazılarını ekleyebilir. Genellikle standart türleri detaylandırırlar ve bunlarla ilgili mesajlar öğelerde görünür ? Listeleme 3.3. VersionMismatch türünde bir hata mesajı içeren sunucu yanıtı xmlns:env="http://www.w3.org/2002/06/soap-envelope"> xmlns:upg="http://www.w3.org/2002/06/soap-upgrade"> xmlns:nsl="http://www.w3.org/2002/06/soap-envelope"/> xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/> Liste3.4. MustUnderstand gibi bir hata mesajı içeren sunucu yanıtı xmlns:t='http://some.com/transaction' /> Bir veya daha fazla zorunlu başlık anlaşılmadı Edebiyat: Khabibullin I. Sh. Java kullanarak Web servislerinin geliştirilmesi. - St. Petersburg: BHV-Petersburg, 2003. - 400 s.: hasta. SABUN dağıtılmış bir bilgi işlem ortamında yapılandırılmış mesajları değiş tokuş etmek için XML kullanan metin tabanlı bir protokoldür. Başlangıçta, SOAP esas olarak uzaktan prosedür çağrısını (RPC) uygulamaya yönelikti ve adı bir kısaltmaydı: Basit Nesne Erişim Protokolü - nesnelere erişmek için basit bir protokol. Artık protokol, keyfi mesajları değiş tokuş etmek için kullanılıyor. XML biçimi, sadece prosedür çağrıları için değil. resmi şartname En son sürüm Protokolün 1.2 sürümü, SOAP adını hiçbir şekilde deşifre etmez. SOAP, XML-RPC protokolünün bir uzantısıdır. SABUN herhangi bir protokol ile kullanılabilir uygulama katmanı: SMTP, FTP, HTTP, vb. Ancak, bu protokollerin her biriyle etkileşiminin ayrı ayrı tanımlanması gereken kendine has özellikleri vardır. Çoğu zaman, SABUN HTTP üzerinden kullanılır. SOAP, web hizmetleri teknolojisinin dayandığı standartlardan biridir. Web servisleri ve müşterileri arasındaki iletişim, XML formatındaki mesajlar aracılığıyla yapılır. SOAP (Basit Nesne Erişim Protokolü), web servislerini seçmek için bir mesajlaşma protokolüdür. SOAP mesajı client tarafından gönderilen parametreleri veya servis tarafından gönderilen bir dönüş değerini içerdiğinden, SOAP formatının RPC (Remote Procedure Call) teknolojisi için ideal olduğunu söyleyebiliriz. SOAP formatını kullanmanın faydaları: · Daha esnek veri türleri. Başlıklar ve uzantılar için destek: Kusurlar: · Mesajları aktarmak için SABUN kullanmak, seslerini artırır ve işlem hızını azaltır. Hızın önemli olduğu sistemlerde, istek parametrelerinin normal HTTP parametreleri olarak iletildiği HTTP üzerinden doğrudan XML belgeleri göndermek daha yaygındır. SABUN bir standart olmakla birlikte, çeşitli programlar genellikle uyumsuz bir formatta mesajlar üretir. Örneğin, bir AXIS istemcisi tarafından üretilen bir sorgu, WebLogic sunucusu tarafından anlaşılmayacaktır. şapkalar 23 Temmuz 2013, 13:09 Herkese selam! Umarım konuyu okuduktan sonra şunları yapabilirsiniz: Yine de bir şeyi unuttum! Biraz daha düşünürsek, istemcinin sunucuya bir defada bir veya belirli sayıda SMS mesajı gönderebileceğini belirtmekte fayda var. Başka bir deyişle, bir veri paketinde birden sonsuza kadar mesaj olabilir. Sonuç olarak, bir SMS mesajı göndermek için aşağıdaki verilere ihtiyacımız olduğunu anlıyoruz: İlk soruyu cevapladık, şimdi ikinci soruyu cevaplamak gerekiyor. Ve belki biraz hile yapmama izin vereceğim. Bu nedenle, sunucudan yalnızca değeri aşağıdaki anlama gelen boole verileri göndereceğiz: Bu, sorun bildiriminin açıklamasını tamamlar! Ve son olarak, en ilginç kısma geçelim - bu SABUN'un ne tür bir tuhaf canavar olduğunu anlayacağız! Ve hikayeme, bu veri alışverişi protokolünün, antipodu REST (Temsili Durum Aktarımı, temsili durum aktarımı) olan sözde RPC (Uzaktan Prosedür Çağrısı) paradigmasına dayalı 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 sayıda ağ kaynaklarıİle büyük miktar yöntemler ve karmaşık protokol. REST yaklaşımıyla, yöntemlerin sayısı ve protokolün karmaşıklığı ciddi şekilde sınırlıdır, bu da çok sayıda bireysel kaynağa yol açabilir.” Yani, bizimle ilgili olarak, bu, sitede RPC yaklaşımı durumunda, hizmete her zaman 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. sitemizdeki REST yaklaşımıyla birlikte, her biri yalnızca belirli verileri kabul eden ve işleyen birçok giriş (bağlantı) vardır. Okuyan biri bu yaklaşımlardaki farkı nasıl daha kolay açıklayacağını biliyorsa, yorumlara yazdığınızdan emin olun! SOAP hakkında bilmemiz gereken bir sonraki şey, bu protokolün bir aktarım olarak aynı XML'i kullanmasıdır, bu bir yandan çok iyidir, çünkü. anında, teknoloji yığınının tam gücü verilen dil biçimlendirme, yani XML Şeması - bir XML belgesinin yapısını açıklayan bir dil (Wikipedia sayesinde!), Bu, sunucuya gelen istemcilerden gelen verileri otomatik olarak doğrulamanıza olanak tanır. Artık SOAP'ın uzaktan prosedür çağrısını gerçekleştirmek için kullanılan protokol olduğunu ve aktarım olarak XML kullandığını biliyoruz! Wikipedia'daki makaleyi okursanız, oradan herhangi bir uygulama katmanı protokolü üzerinde kullanılabileceğini ve yalnızca HTTP ile eşleştirilemeyeceğini de öğrenebilirsiniz (maalesef bu konuda yalnızca HTTP üzerinden SABUN'u ele alacağız). Ve tüm bunlarda en çok neyi seviyorum biliyor musun? Tahmin yoksa, sana bir ipucu vereceğim - SABUN!… Zaten tahmin 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 özelliği italiktir! Tüm bunlardan hangi 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 buna katılıyor), o zaman sürüm 1.2'den beri olmaktan çıktı. hiç şifresi çözüldü! Ve SABUN olarak bilinmeye başlandı, sadece SABUN ve nokta. Pekala, kusura bakmayın, biraz yana kaydı. Daha önce yazdığım gibi, XML bir aktarım olarak kullanılır ve istemci ile sunucu arasında çalışan paketlere SOAP zarfları denir. Zarfın genelleştirilmiş yapısını ele alırsak, o zaman size çok tanıdık gelecektir, çünkü bir HTML sayfasının yapısına benzer. Bir ana bölümü vardır - zarf bölümleri içeren başlık Ve Vücut, veya Arıza. İÇİNDE Vücut veriler 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 girdi verileriyle doğrudan ilgili olmayan diğer veriler iletilebilir. profesyonel Arıza herhangi bir hata durumunda sunucudan istemciye gelmesi dışında söylenecek özel bir şey yoktur. SOAP protokolüyle ilgili genel bakış hikayem burada sona eriyor (müşterimiz ve sunucumuz nihayet bunları birbiriyle nasıl çalıştıracağını öğrendiğinde zarfların kendilerine ve yapılarına daha ayrıntılı olarak bakacağız) ve SOAP arkadaşı hakkında yeni bir hikaye başlıyor. isminde WSDL(Web Hizmetleri Açıklama Dili). Evet, evet, API'mizi alıp uygulama girişiminden çoğumuzu korkutan şey tam da bu. bu protokol. Sonuç olarak, genellikle JSON ile tekerleğimizi bir ulaşım aracı olarak yeniden keşfederiz. Peki, WSDL nedir? WSDL, XML (c) Wikipedia diline dayalı olarak web servislerini tanımlamak ve bunlara erişmek için kullanılan bir dildir. Bu tanımdan, bu teknolojinin tüm kutsal anlamı sizin için netleşmiyorsa, o zaman onu kendi kelimelerimle açıklamaya çalışacağım! WSDL, müşterilerimizin sunucuyla normal şekilde iletişim kurmasını sağlamak için tasarlanmıştır. Bunun için “*.wsdl” uzantılı dosyada aşağıdaki bilgiler anlatılmaktadır: Şemanın asıl görevi, işleyeceğimiz verilerin yapısını açıklamaktır. XML şemalarındaki tüm veriler, basit(skaler) ve karmaşık(yapılar) türleri. Basit türler aşağıdakileri içerir: Uzağa gitmemeyi ve sms mesajımız için bir XML şeması yazmayı öneriyorum! Aşağıda sms mesajının xml açıklaması yer almaktadır: Bence elementlerin anlamı " eleman" Ve " karmaşıkTür» her şey sizin için az çok netleşti, bu yüzden artık bunlara odaklanmayacağız ve hemen besteci öğesine geçeceğiz « sekans". Birleştirici elemanını kullandığımızda " sekans» İçerisinde yer alan unsurların her zaman şemada belirtilen sırada olması gerektiğini ve ayrıca tamamının 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", içinde listelenen öğelerden birinin ve bestecinin olması gerektiğini belirtir" Tümü» – listelenen öğelerin herhangi bir kombinasyonu. Hatırlarsanız konunun ilk bölümünde paketin birden sonsuza kadar sms mesajı 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: Şemanın ikinci bloğu " öğesini bildirir. mesajListesi" tip " Mesaj Listesi". 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! Genel olarak, her şeyin bizim için doğru çalışması için, istemciye doğru MIME türüne sahip bir WSDL dosyası aktarmamız gerekir. 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 Header("Content-Type: text/xml; charset=utf-8"); Sizi hemen uyarmak istiyorum, basit web hizmetimizin 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ıktan sonra sürekli olarak bir web hizmetinden diğerine kopyalanabilir! WSDL XML olduğundan, ilk satırda doğrudan onun hakkında yazmanız gerekir. Bir dosyanın kök elemanı her zaman " olarak adlandırılmalıdır. tanımlar»:
Bundan sonra, web servisimizde beyan ederiz " SMS Hizmeti" adı verilen bir giriş noktası ("bağlantı noktası") vardır. SmsServicePort". İstemcilerden sunucuya gelen tüm isteklerin gönderileceği yer burasıdır. Ve öğede belirtiyoruz " adres» istekleri kabul edecek bir işleyici dosyasına bağlantı. Bir web servisi tanımladıktan ve onun için bir giriş noktası belirledikten sonra, desteklenen prosedürleri buna bağlamamız gerekir:
Bundan sonra, prosedürü mesajlara bağlamamız gerekiyor:
Şimdi mesajların kendilerini tanımlamamız gerekiyor, yani. giren ve çıkan:
Şimdi biraz yapmamız gerekiyor - bu türlerin açıklamasını WSDL dosyamıza ekleyin! Ve WSDL'nin gelen ve giden verileri nasıl tanımladığını düşünüyorsunuz? 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!
Her şey yüklendikten ve yapılandırıldıktan sonra, “ dosyasını oluşturmamız gerekecek. smsservice.php» aşağıdaki içerikle: setClass("SoapSmsGateWay"); //Sunucuyu başlat $server->handle(); Şimdi sunucuya geliyoruz! Gördüğünüz gibi, tüm SOAP sunucusu sadece üç satır uzunluğunda! İlk satırda SoapServer nesnesinin yeni bir örneğini oluşturuyoruz ve WSDL web servis açıklamamızın adresini yapıcısına iletiyoruz. Artık, barındırma kökünde bir dosyada bulunacağını biliyoruz. konuşan isim « smsservice.wsdl.php". İkinci satırda SOAP server'a client'tan gelen zarfı işlemek için hangi class'ı çekmesi gerektiğini söylüyoruz ve zarfı cevap ile geri getiriyoruz. Tahmin edebileceğiniz gibi, tek yöntemimiz bu sınıfta açıklanacaktır. sms gönder. Üçüncü satırda sunucuyu başlatıyoruz! Her şey, sunucumuz hazır! Bununla hepimizi tebrik ediyorum! Şimdi bir WSDL dosyası oluşturmamız gerekiyor. Bunu yapmak için, ya içeriğini önceki bölümden kopyalayabilir ya da özgürlükleri alıp onu biraz "şablonlayabilirsiniz": ";
?>
mesajListesi = yeni MesajListesi(); $req->messageList->message = yeni Mesaj(); $req->messageList->message->phone = "79871234567"; $req->messageList->message->text = "Mesaj 1'i test et"; $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)); Nesneleri tanımladıktan sonra bir nesne oluşturmamız gerekiyor ( $req), sunucuya gönderilecek. O zaman bizim için en değerli iki satıra gelin! SOAP müşterimiz! İster inanın ister inanmayın, ancak bu, sunucumuzun istemciden gelen mesajları 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 yaratıyoruz ve WSDL dosyasının konumunun adresini yapıcısına iletiyoruz ve parametrelerde SOAP protokolü sürüm 1.2'yi kullanarak çalışacağımızı açıkça belirtiyoruz. Bir sonraki satırda yöntemi çağırıyoruz sms gönder nesne $müşteri ve sonucu hemen tarayıcıda görüntüleyin. Sunucudan aşağıdaki nesneyi aldım: Object(stdClass) genel "durum" => boolean true Şimdi sunucu tarafında ihtiyatlı bir şekilde tuttuğumuz loga bir göz atalım! İlk bölümünde sunucuya giren ham verileri görüyoruz:
Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "phone" => string "79871234567" (uzunluk=11) public "text" => string "Test mesajı 1 " (uzunluk=37) genel "tarih" => dize "2013-07-21T15:00:00.26" (uzunluk=22) genel "tür" => dize "15" (uzunluk=2) // sunucuya gönderilecek bir nesne yarat $req = new Request(); $req->messageList = new MessageList(); $msg1 = yeni Mesaj(); $msg1->telefon = "79871234567"; $msg1->text = "Mesaj 1'i test et"; $msg1->tarih = "2013-07-21T15:00:00.26"; $msg1->tür = 15; $msg2 = yeni Mesaj(); $msg2->telefon = "79871234567"; $msg2->text = "Mesaj 2'yi test et"; $msg2->tarih = "2014-08-22T16:01:10"; $msg2->tür = 16; $msg3 = yeni Mesaj(); $msg3->telefon = "79871234567"; $msg3->text = "Mesaj 3'ü test et"; $msg3->tarih = "2014-08-22T16:01:10"; $msg3->tür = 17; $req->messageList->mesaj = $msg1; $req->messageList->mesaj = $msg2; $req->messageList->mesaj = $msg3;
Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "Struct" => array (size=3) 0 => object(stdClass) public "phone" => string "79871234567" (uzunluk=11) genel "metin" => string "Test mesajı 1" (uzunluk=37) genel "tarih" => dize "2013-07-21T15:00:00.26" (uzunluk=22) genel " type" => string "15" (uzunluk=2) 1 => nesne(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 => nesne(stdClass) genel "telefon " => string "79871234567" (uzunluk=11) genel "metin" => dize "Test mesajı 3" (uzunluk=37) genel "tarih" => dize "2014-08-22T16:01:10" (uzunluk= 19) public "type" => string "17" (uzunluk=2) $req->messageList->message = (object)$req->messageList->message;
Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "BOGUS" => array (size=3) 0 => object(stdClass) public "phone" => string "79871234567" (uzunluk=11) genel "metin" => string "Test mesajı 1" (uzunluk=37) genel "tarih" => dize "2013-07-21T15:00:00.26" (uzunluk=22) genel " type" => string "15" (uzunluk=2) 1 => nesne(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 => nesne(stdClass) genel "telefon " => string "79871234567" (uzunluk=11) genel "metin" => dize "Test mesajı 3" (uzunluk=37) genel "tarih" => dize "2014-08-22T16:01:10" (uzunluk= 19) public "type" => string "17" (uzunluk=2) // sunucuya gönderilecek bir nesne yarat $req = new Request(); $msg1 = yeni Mesaj(); $msg1->telefon = "79871234567"; $msg1->text = "Mesaj 1'i test et"; $msg1->tarih = "2013-07-21T15:00:00.26"; $msg1->tür = 15; $msg2 = yeni Mesaj(); $msg2->telefon = "79871234567"; $msg2->text = "Mesaj 2'yi test et"; $msg2->tarih = "2014-08-22T16:01:10"; $msg2->tür = 16; $msg3 = yeni Mesaj(); $msg3->telefon = "79871234567"; $msg3->text = "Mesaj 3'ü test et"; $msg3->tarih = "2014-08-22T16:01:10"; $msg3->tür = 17; $req->messageList = $msg1; $req->messageList = $msg2; $req->messageList = $msg3; $req->messageList = (nesne)$req->messageList;
Object(stdClass) public "messageList" => 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 "date" => 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) genel "tür" => dize "16" (uzunluk=2) 2 => nesne(stdClass) genel "telefon" => dize "79871234567" (uzunluk= 11) public "text" => string "Test mesajı 3" (uzunluk=37) public "date" => string "2014-08-22T16:01:10" (uzunluk=19) public "type" => string " 17" (uzunluk=2) 10 yanıt WSDL, bir web servisini tanımlayan bir XML belgesidir. Aslında web servis tanımlama dili anlamına gelmektedir. SOAP, uygulamalar arasında belirli bir protokol (HTTP veya SMTP gibi) üzerinden bilgi alışverişine izin veren XML tabanlı bir protokoldür. Basit Nesne Erişim Protokolü anlamına gelir ve bilgi iletmek için mesajlaşma biçimi olarak XML kullanır. REST mimari bir tarzdır ağ sistemleri ve temsili bir devletin devrini savunur. Kendi başına bir standart değildir, ancak HTTP, URL, XML vb. standartları kullanır. Ne zaman birisi SOAP/WSDL'den bahsetse xml'de tanımlanan nesneleri ve sınıfları düşünüyorum... "SABUN'u herhangi bir PHP sınıfı gibi kullanıyorsunuz. Ancak bu durumda, sınıf yerelde yok. dosya sistemi uygulamalar, ancak http üzerinden erişilen uzak bir ana bilgisayarda."... "Başka bir PHP sınıfı olarak bir SOAP hizmeti kullanmayı düşünürsek, o zaman WSDL belgesi tüm bunların bir listesidir. mevcut yöntemler ve sınıf özellikleri. Ve ne zaman birisi REST hakkında konuşsa, aklıma POST, GET ve DELETE gibi HTTP komutları (istek yöntemleri) gelir. Örnek: basit kelimelerle bir hesap makinesi web hizmetiniz varsa. WSDL: WSDL, uygulayabileceğiniz veya bir istemciye gösterebileceğiniz işlevlerden bahseder. Örneğin: toplama, çıkarma, çıkarma vb. SABUN: burada SABUN kullanarak aslında doDelete(), doSubtract(), doAdd() gibi eylemler gerçekleştirirsiniz. Yani SOAP ve WSDL elma ve portakaldır. Onları karşılaştırmamalıyız. Her ikisinin de kendi işlevleri vardır. Neden SOAP ve WSDL kullanıyoruz: platformdan bağımsız veri alışverişi için. DÜZENLEME: Normal günlük yaşamda: WSDL: Bir restorana gittiğimizde menü öğelerini görüyoruz, bu WSDL. Proxy sınıfları:Şimdi, menü öğelerine baktıktan sonra kararımızı veriyoruz (sırayla ilgili görüşümüzü işleyerek): Yani, temel olarak WSDL belgesine dayalı Proxy sınıfları yapıyoruz. SABUN: O zaman menüye göre yemek siparişi verdiğimizde: SOAP kullanılarak yapılan servis yöntemlerini çağırmak için proxy sınıfları kullanmamız ima edilir. :) SABUN → SABUN (Basit Nesne Erişim Prototipi), makineler arası iletişim için tasarlanmış bir uygulama protokol katmanıdır. Protokol, standart kuralları tanımlar. Belirli bir protokolü kullanan tüm taraflar, protokolün kurallarına uymalıdır. TCP gibi, taşıma katmanında çözer. SOAP protokolü, uygulama düzeyinde anlaşılacaktır (SOAP'ı destekleyen herhangi bir uygulama - Axis2, .Net). WSDL → SOAP mesajı SoapEnevelope-> SoapHeader ve SoapBody'den oluşur. Mesaj formatının ne olacağını tanımlamıyor mu? hangi tüm aktarımlar (HTTP, JMS) desteklenir? bu bilgi olmadan. Bir SOAP mesajı oluşturmak için belirli bir web servisini kullanmak isteyen herhangi bir müşteri için bu zordur. Yapsalar bile, her zaman işe yarayacağından emin olmayacaklar. WSDL bir cankurtarandır. WSDL (Web Hizmetleri Açıklama Dili), bir SOAP mesajı için işlemleri, mesaj formatlarını ve taşıma verilerini tanımlar. REST → REST (Representation State Transfer) taşımaya dayalıdır. Eylemlere odaklanan SOAP'tan farklı olarak, REST daha çok kaynaklarla ilgilidir. REST, kaynakları bir URL (örnek -http://(serverAddress)/employees/employeeNumber/12345) kullanarak bulur ve şunlara bağlıdır: taşıma protokolü(HTTP-GET, POST, PUT, DELETE, ... ile) kaynakları yürütme eylemleri için. REST hizmeti, URL'ye göre kaynağı bulur ve taşıma eylemi fiiline göre eylemi gerçekleştirir. Daha çok mimari bir tarz ve gelenekler. SOAP, Basit (sic) Nesne Erişim Protokolü anlamına gelir. HTTP üzerinden XML göndererek uzak nesnelere uzaktan prosedür çağrıları yapmak amaçlandı. WSDL, bir Web Hizmetleri Açıklama Dilidir. Bir ".wsdl" uç noktası ile biten bir istek, isteği ve kullanımın bekleyebileceği yanıtı açıklayan bir XML mesajı temsiliyle sonuçlanacaktır. Hizmet ile müşteri arasındaki sözleşmeyi açıklar. REST, hizmetlere mesaj göndermek için HTTP kullanır. SOAP bir özelliktir, REST bir stildir. Karmaşık bir şeyi "sadece" anlamayacaksın. WSDL, bir web servisini tanımlamak için XML tabanlı bir dildir. İletileri, işlemleri ve hakkında bilgileri açıklar. ulaşım ağı Hizmet tarafından kullanılan. Bu web hizmetleri tipik olarak SOAP kullanır, ancak diğer protokolleri de kullanabilir. WSDL, program tarafından okunur ve bu nedenle, web hizmetini başlatmak için gereken istemci kodunun tamamını veya bir kısmını oluşturmak için kullanılabilir. SOAP yönelimli web servislerini "kendi kendini tanımlayan" olarak adlandırmanın anlamı budur. REST, WSDL ile hiç ilgili değildir. Wikipedia, "Web Hizmetleri Açıklama Dili, web hizmetlerini açıklamak için bir model sağlayan XML tabanlı bir dildir" diyor. Başka bir deyişle, javadoc'un java'yı ifade etmesi gibi, WSDL de bir web hizmetini ifade eder. Ancak, WSDL ile ilgili en güzel şey, yazılım WSDL kullanarak istemci ve sunucu oluşturabilir.. Gerekli bir iç içe öğe içerir<:value>bir hata kodu ve isteğe bağlı iç içe öğe ile 
Temel protokol kavramları:
SOAP mesajını gönderen taraf SOAP gönderen, alan taraf ise SOAP alıcı olarak adlandırılır. Bir SOAP mesajının orijinal göndericiden son alıcıya kadar izlediği yola mesaj yolu denir. İleti yolu, orijinal göndereni, son alıcıyı ve 0 veya daha fazla SOAP aracısını içerir. SOAP protokolleri tarafından tanımlanan kurallara göre mesajları işleyen varlıklara SOAP düğümleri denir. SOAP düğümleri arasındaki değiş tokuşa katılan temel bilgi birimine SOAP mesajı denir - bu, kök elemanın SOAP sarmalayıcısına sahip bir XML belgesidir.PHP'de bir SOAP istemci-sunucu uygulaması yazmak
Öyle oldu ki son zamanlarda web servislerinin geliştirilmesine dahil oldum. Ancak bugün konu benimle ilgili değil, SOAP 1.2 protokolünü temel alan kendi XML Web Servisimizi nasıl yazabileceğimizle ilgili.
Tahmin edebileceğiniz gibi, tüm sihir ile yapılacak PHP kullanarak ve yerleşik SoapClient ve SoapServer sınıfları. Tavşan olarak sms mesajları göndermek için bir servisimiz olacak. 1 Sorun bildirimi
1.1 Sınırlar
Başlangıçta, konunun sonunda elde edeceğimiz sonucu ele almayı öneriyorum. Yukarıda da duyurulduğu üzere sms mesajları göndermek için bir servis yazacağız daha doğrusu SOAP protokolünü kullanarak farklı kaynaklardan mesajlar alacağız. Bundan sonra, sunucuya hangi biçimde geldiklerini ele alacağız. İletileri sağlayıcıya daha fazla göndermek için kuyruğa alma işlemi maalesef birçok nedenden dolayı bu yazının kapsamı dışındadır. 
1.2 Hangi veriler değiştirilecek?
Pekala, sınırlarımız var! Yapılması gereken bir sonraki adım, sunucu ile istemci arasında hangi verileri değiş tokuş edeceğimize karar vermektir. Bu konuda, uzun süre daha akıllı olmamayı ve ana soruları hemen kendiniz için yanıtlamayı öneriyorum:
Bir şey bana bunun için aşağıdakileri göndermenin gerekli olduğunu söylüyor:
Prensip olarak, bu iki özellik göndermek için yeterlidir, ancak bana öyle geliyor ki, sabah saat 3'te veya 4'te size doğum günü selamları içeren bir sms geliyor! Şu anda, beni unutmadıkları için herkese çok minnettar olacağım! Bu nedenle, sunucuya da göndereceğiz ve
Sunucuya göndermek istediğim bir sonraki şey
Bu parametre zorunlu değildir, ancak patrona haberlerimizden kaç müşterimizi "memnun ettiğimizi" hızlı bir şekilde söylememiz ve ayrıca bu konuda bazı güzel istatistikler çizmemiz gerekirse, bizim için çok yararlı olabilir. 
2 SABUN nedir?
Genel olarak, başlangıçta SOAP'ın ne olduğu hakkında hiçbir şey yazmayı planlamadım ve kendimi w3.org sitesine gerekli özelliklere sahip bağlantıların yanı sıra Wikipedia bağlantılarıyla sınırlamak istedim. Ama en sonunda bu protokol hakkında kısa bir referans yazmaya karar verdim. 
Görüldüğü gibi, verilen dosya ve tüm web servisi var. İstemcide WSDL dosyasının adresini belirterek, herhangi bir web hizmeti hakkında her şeyi bileceğiz! Sonuç olarak, web servisinin kendisinin nerede olduğu hakkında kesinlikle hiçbir şey bilmemize gerek yok. WSDL dosyasının yerini bilmek yeterlidir! Yakında SABUN'un boyandığı kadar korkutucu olmadığını öğreneceğiz (c) Rus atasözü. 3 XML Şemasına Giriş
Artık SOAP'ın ne olduğu, içinde ne olduğu hakkında çok şey biliyoruz ve onu çevreleyen ne tür bir teknoloji yığınına dair bir genel bakışa sahibiz. Her şeyden önce, SOAP bir istemci ile sunucu arasındaki bir etkileşim yöntemi olduğundan ve dil bunun için bir aktarım olarak kullanılır. XML işaretlemesi, ardından bu bölümde, XML şemaları aracılığıyla otomatik veri doğrulamanın nasıl gerçekleştiğini biraz anlayacağız.
İçinde uzantı olmayan çok basit bir şey. Antipodu karmaşık karmaşık tiplerdir. Herkesin aklına gelen karmaşık bir türün en basit örneği nesnelerdir. Örneğin, bir kitap. Kitap şu özelliklerden oluşur: yazar, İsim, fiyat, ISBN numarası vesaire. Ve bu özellikler sırayla hem basit tipler hem de karmaşık olabilir. Ve XML şemasının görevi onu tanımlamaktır.
Karmaşık tip şemamız şöyle görünecek:
Bu giriş ş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şan" 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!
Böylesine karmaşık bir türün şeması şöyle görünür:
İlk blok, “ karmaşık türün tanıdık bildirimini içerir. İleti". Fark ederseniz, o zaman her basit türde " İleti”, yeni uygun nitelikler eklendi” min oluşur" Ve " maxOccurs". Adından da tahmin etmek zor olmadığı için ilk ( min oluşur), verilen dizinin " türünden en az bir öğe içermesi gerektiğini belirtir. telefon», « metin», « tarih" Ve " tip”, sonraki ( maxOccurs) özniteliği bize dizimizde böyle bir öğeden en fazla bir tane olduğunu bildiriyor. Sonuç olarak, herhangi bir veri için şemalarımızı yazdığımızda, onları nasıl yapılandıracağımız konusunda bize en geniş seçenek sunulur!4 WSDL'nizi yazmak
WSDL'nin bizim web servisimiz olduğunu hatırlıyor musunuz? Umarım hatırlarsın! Biz yazarken, küçük web servisimiz üzerinde yüzecek. Bu yüzden hile yapmamanı öneririm.
Ancak pratikte, HTTP üstbilgisini genellikle PHP aracılığıyla gönderirdim " metin/xml»:
ve her şey harika çalıştı!
Genellikle WSDL 4-5 ana bloktan oluşur. İlk blok, bir web servisinin veya başka bir deyişle bir giriş noktasının tanımıdır.
Burada bir hizmetimiz olduğu yazıyor - " SMS Hizmeti". Prensip olarak, WSDL dosyasındaki tüm adlar sizin tarafınızdan istediğiniz şekilde değiştirilebilir, çünkü kesinlikle hiçbir rol oynamazlar.
Bunu yapmak için hangi işlemlerin ve hangi biçimde y'nin çağrılacağını listeler. Onlar. liman için SmsServicePort» adlı bir bağlama « SmsServiceBağlama", arama türüne sahip " rpc” ve HTTP, aktarım protokolü (taşıma) olarak kullanılır. Bu nedenle uygulayacağımızı burada belirtmiş olduk. RPC çağrısı HTTP üzerinden. Bundan sonra, hangi prosedürleri açıklıyoruz ( operasyon) web hizmetinde desteklenir. Yalnızca bir prosedürü destekleyeceğiz - " sms gönder". Bu prosedür sayesinde harika mesajlarımız sunucuya gönderilecek! Prosedür açıklandıktan sonra, verilerin hangi biçimde iletileceğini belirtmek gerekir. İÇİNDE bu durum standart SOAP zarflarının kullanılacağını belirtti.
Bunu yapmak için, bağlamamızın ("bağlama") " türünde olduğunu belirtiriz. SmsServicePortType" ve elemanda " bağlantı noktası türü» aynı tür adıyla, prosedürlerin mesajlara bağlanmasını belirtin. Bu yüzden, beklenmeyen mesaj(istemciden sunucuya) " sms isteği gönder" ve giden (sunucudan istemciye)" SmsYanıtı gönder". WSDL'deki tüm isimler gibi, gelen ve giden mesajların isimleri isteğe bağlıdır.
Bunu yapmak için öğeleri ekliyoruz " İleti» isimlerle « sms isteği gönder" Ve " SmsYanıtı gönder" sırasıyla. Onlarda, girdiye yapısı veri türüne karşılık gelen bir zarfın gelmesi gerektiğini belirtiyoruz " Rica etmek". Bundan sonra, sunucudan veri türünü içeren bir zarf döndürülür - " Cevap».
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 sağladığı şeylerle 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. Diğer tüm eylemlerin benimkiyle aynı şekilde gerçekleşmesi için PHP'nizi biraz ayarlamanız gerekecek. Daha 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 şekilde resmi PHP web sitesinde okuyun (referanslara bakın).
"ini_set" işleviyle satırın ü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 hemen etkili oluyor.
Bu aşamada ortaya çıkan sunucu tamamen bize uygun olmalı çünkü. ona gelen zarfları kaydedebilir ve ardından gelen verileri sakince analiz edebiliriz. Sunucuda herhangi bir şey alabilmemiz için bir istemciye ihtiyacımız var. Öyleyse onlarla devam edelim!6 SOAP istemcisi yolda
Öncelikle client yazacağımız bir dosya oluşturmamız gerekiyor. Her zamanki gibi, onu ana bilgisayarın kökünde oluşturacağız ve ona " client.php”ve içine şunu yazıyoruz:
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 PHP betiğimizde bu varlıkların yansımalarıdır.
Hadi çalıştıralım ve sonunda ne elde ettiğimizi görelim!
Ve bu harika, çünkü. Artık sunucumuzun çalıştığından ve sadece çalışmakla kalmayıp aynı zamanda istemciye bazı değerler de döndürebildiğinden eminiz!
Bu zarf. Şimdi nasıl göründüğünü biliyorsun! Ancak, ona sürekli hayranlık duymakla ilgilenmemiz pek olası değil, bu yüzden nesneyi günlük dosyasından seri durumdan çıkaralım ve bizim için her şeyin yolunda olup olmadığına bakalım:
Gördüğünüz gibi, nesne doğru bir şekilde seriden çıkarıldı, bununla hepimizi tebrik etmek istiyorum! Ardından, daha ilginç bir şey bizi bekliyor! Yani, müşteri tarafından sunucuya bir sms mesajı değil, bütün bir paket göndereceğiz (daha kesin olmak gerekirse, üç bütün)!7 Karmaşık Nesneleri Gönderme
Bir sürü mesajı sunucuya tek bir pakette nasıl gönderebileceğimizi düşünelim. Muhtemelen en basit bir şekilde messageList öğesinin içinde bir dizi organizasyonu olacak! Hadi yapalım:
Günlüklerimiz, aşağıdaki paketin istemciden geldiğini gösteriyor:
Ne saçmalık diyorsun? Ve bir anlamda haklı olacaksın, çünkü. clienttan hangi cismin çıktığını öğrendiğimiz gibi zarf şeklinde birebir aynı şekilde sunucumuza geldi. Doğru, sms mesajları XML'de ihtiyacımız olan şekilde seri hale getirilmedi - öğ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:
Bu bilgi bize ne veriyor? Sadece seçtiğimiz yolun doğru olmadığını ve “Sunucuda doğru veri yapısını nasıl elde edebiliriz?” Sorusuna bir cevap alamadık. Ama umutsuzluğa kapılmamanızı ve dizimizi türe dönüştürmeye çalışmanızı öneririm. bir obje:
Bu durumda, başka bir zarf alacağız:
yönteme girdi sms gönder nesne aşağıdaki yapıya sahiptir:
Bana gelince, o halde “terimlerin yerlerinin değişmesinden toplamları değişmez” (c). Ne SAHTE, Ne yapı Henüz hedefimize ulaşmadık! Ve bunu başarmak için, bu anlaşılmaz isimler yerine yerlimizin olduğundan emin olmalıyız. İleti. Ancak bunu nasıl başaracağını yazar henüz bilmiyor. Bu nedenle, yapabileceğimiz tek şey fazladan konteynırdan kurtulmaktır. Başka bir deyişle, artık bunun yerine İleti oldu SAHTE! Bunu yapmak için nesneyi aşağıdaki gibi değiştirin:
Aniden şanslıyız ve plandan çekileceğiz doğru isim? Bunun için gelen zarfa bakalım:
Evet, mucize olmadı! SAHTE- kazanamayacağız! Geldi sms gönder bu durumda nesne şöyle görünecektir:
Dedikleri gibi - "Neredeyse"! Bu (biraz üzücü) notta, sessizce toparlamayı ve kendimiz için bazı sonuçlar çıkarmayı öneriyorum.8 Sonuç
Sonunda buraya geldik! Şimdi ne yapabileceğinize karar verelim:
Ayrıca küçük araştırmamız sırasında kendimiz için bazı keşifler yaptık: