PHP'de bir SOAP istemci-sunucu uygulaması yazma. SABUN nedir

  • 29.07.2019

10 cevap

WSDL, bir web hizmetini açıklayan bir XML belgesidir. Aslında web servis tanımlama dili anlamına gelir.

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 aktarımı için mesajlaşma biçimi olarak XML kullanır.

REST, ağ bağlantılı sistemlerin mimari tarzıdır ve temsili durum aktarımını ifade eder. Kendi başına bir standart değildir, ancak HTTP, URL, XML vb. Standartları kullanır.

Birisi SOAP / WSDL'den her bahsettiğinde, xml'de tanımlanan nesneleri ve sınıfları düşünüyorum ...

"SOAP'ı tıpkı herhangi bir PHP sınıfı gibi kullanıyorsunuz. Ancak bu durumda, sınıf yerel uygulama dosya sisteminde değil, http üzerinden erişilen uzak bir ana bilgisayarda var." ... "SOAP kullanmayı düşünürsek- başka bir PHP sınıfı olarak hizmet, ardından WSDL belgesi, sınıfın tüm kullanılabilir yöntemlerinin ve özelliklerinin bir listesidir. "

Ve ne zaman birisi REST hakkında konuşsa, POST, GET ve DELETE gibi HTTP komutlarını (istek yöntemleri) düşünüyorum.

Örnek: Basit bir ifadeyle, bir hesap makinesi web hizmetiniz varsa.

WSDL: WSDL, uygulayabileceğiniz veya istemciye sunabileceğiniz işlevsellik hakkında konuşuyor. Örneğin: toplama, çıkarma, çıkarma vb.

SABUN: SOAP kullanarak, aslında doDelete (), doSubtract (), doAdd () gibi eylemleri 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: platformda bağımsız veri alışverişi yapmak için.

DÜZENLEME: Normal günlük yaşamda:

WSDL: Restorana gittiğimizde menü öğelerini görüyoruz, bu WSDL.

Proxy sınıfları: Şimdi, menü öğelerine baktıktan sonra, zihnimizi oluşturuyoruz (sırayla ilgili görüşümüzü işliyoruz): Yani temel olarak Proxy sınıflarını WSDL belgesine göre yapıyoruz.

SABUN: Daha sonra menüye dayalı olarak yemek sipariş ettiğimizde: SOAP kullanılarak yapılan servis yöntemlerini çağırmak için proxy sınıfları kullandığımız anlamına gelir. :)

SOAP → SOAP (Basit Nesne Erişim Prototipi), makineden makineye iletişim için oluşturulmuş 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 çözülür. SOAP, uygulama düzeyinde anlaşılacaktır (SOAP - Axis2, .Net'i destekleyen herhangi bir uygulama).

WSDL -\u003e SABUN mesajı SoapEnevelope-\u003e SoapHeader ve SoapBody'den oluşur. Mesaj formatının ne olacağını tanımlamıyor mu? hangi tüm aktarımlar (HTTP, JMS) destekleniyor? bu bilgi olmadan. Belirli bir web servisini kullanmak isteyen herhangi bir müşteri için bir SOAP mesajı oluşturmak zordur. Yapsalar bile, her zaman işe yarayacağından emin olmayacaklar. WSDL bir cankurtarandır. WSDL (Web Hizmeti Açıklama Dili), bir SOAP mesajı için işlemleri, mesaj biçimlerini ve aktarım verilerini tanımlar.

REST -\u003e REST (Durum Aktarımını Görüntüle) taşıma tabanlıdır. Eylem odaklı olan SOAP'tan farklı olarak, REST daha çok kaynaklarla ilgilidir. REST, kaynakları bir URL kullanarak bulur (örnek -http: // (sunucuAdresi) / çalışanlar / çalışanNumarası / 12345) ve kaynakları alma eylemleri için taşıma protokolüne (HTTP-GET, POST, PUT, DELETE, ... ile) bağlıdır. . REST hizmeti, kaynağı URL'ye göre bulur ve eylemi taşıma eylemi fiiline göre gerçekleştirir. Daha çok mimari bir tarz ve geleneklerdir.

SOAP, Basit (sic) Nesne Erişim Protokolü anlamına gelir. HTTP üzerinden XML göndererek uzak nesnelere uzaktan yordam çağrıları yapmak amaçlanmıştır.

WSDL, bir web hizmeti açıklama dilidir. ".Wsdl" uç noktası ile biten bir istek, kullanımın bekleyebileceği isteği ve yanıtı açıklayan bir XML mesajının gönderilmesine neden olur. Hizmet ile müşteri arasındaki sözleşmeyi açıklar.

REST, hizmetlere mesaj göndermek için HTTP kullanır.

SABUN bir şartname, REST bir stildir.

Karmaşık bir şeyi "sadece" anlamayacaksınız.

WSDL, bir web hizmetini açıklamak için XML tabanlı bir dildir. Servis tarafından kullanılan mesajları, işlemleri ve taşıma ağı bilgilerini açıklar. Bu web hizmetleri genellikle SOAP kullanır, ancak başka protokoller de kullanabilir.

WSDL, bir program tarafından okunabilir ve bu nedenle web hizmetini çağırmak için gereken istemci kodunun tamamını veya bir kısmını oluşturmak için kullanılabilir. Bu, SOAP yönelimli web servislerine "kendi kendini tanımlayan" demenin anlamıdır.

REST, WSDL ile hiçbir şekilde ilişkili 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, WSDL, javadoc java kitaplığını ifade ettiği için web hizmetini ifade eder.

Bununla birlikte, WSDL ile ilgili çok güzel bir şey, yazılımın WSDL kullanarak istemci ve sunucu oluşturabilmesidir.

Lirik kısım.

Dışarıdan erişilebilir olması gereken belirli bir sistemi uyguladığınızı veya uyguladığınızı hayal edin. Şunlar. iletişim kurmanız gereken belirli bir sunucu var. Örneğin bir web sunucusu.

Bu sunucu birçok eylemi gerçekleştirebilir, veritabanıyla çalışabilir, diğer sunuculara bazı üçüncü taraf isteklerini gerçekleştirebilir, bazı hesaplamalar yapabilir, vb. iyi bilinen senaryosuna göre yaşamak ve muhtemelen geliştirmek (yani geliştiricilerin senaryosuna göre). Bir kişi böyle bir sunucuyla iletişim kurmakla ilgilenmez, çünkü resimlerle ve diğer kullanıcı dostu içeriklerle güzel sayfalar veremeyebilir / vermek istemeyebilir. Çalışmak ve isteklere veri yayınlamak için yazılır ve çalışır, bunların insan tarafından okunabilir olmasına aldırmadan, müşteri bunları kendisi halleder.

Bu sunucuya atıfta bulunan diğer sistemler, bu sunucudan alınan verileri kendi takdirine bağlı olarak - işlemek, biriktirmek, istemcilere yayınlamak vb. İçin - halihazırda elden çıkarabilir.

Bu tür sunucularla iletişim kurmanın seçeneklerinden biri SOAP. SOAP xml mesajlaşma protokolü.

Pratik kısım.

Bir web hizmeti (bu, sunucunun sağladığı ve istemcilerin kullandığı şeydir), sunucuyla açıkça yapılandırılmış mesajlarla iletişim kurmayı mümkün kılar. Gerçek şu ki, web hizmeti herhangi bir veriyi kabul etmiyor. Web hizmeti, kurallara uymayan herhangi bir mesaja bir hata ile cevap verecektir. Bu arada hata, net bir yapıya sahip xml biçiminde de olacaktır (bu, mesajın metni için doğru değildir).

WSDL (Web Hizmetleri Açıklama Dili). Web hizmeti için mesajların oluşturulma kuralları da xml kullanılarak açıklanmıştır ve ayrıca açık bir yapıya sahiptir. Şunlar. bir web hizmeti bir yöntemi çağırma yeteneği sağlıyorsa, istemcilere bu yöntem için hangi parametrelerin kullanıldığını bildirmelidir. Web hizmeti, Method1 yöntemi için bir parametre olarak bir dize bekliyorsa ve dizenin Param1 adına sahip olması gerekiyorsa, bu kurallar web hizmeti açıklamasında belirtilecektir.

Parametre olarak sadece basit tipler değil, aynı zamanda nesneler, nesne koleksiyonları da aktarılabilir. Nesnenin açıklaması, nesnenin her bir bileşeninin açıklamasına indirgenmiştir. Bir nesne birkaç alandan oluşuyorsa, her alan hangi tür, ad (olası değerler) olarak tanımlanır. Alanlar ayrıca karmaşık bir türde olabilir ve bu, türlerin açıklaması basit olanlarla bitene kadar devam eder - string, boolean, sayı, tarih ... Ancak, bazı belirli türler basit olabilir, istemcilerin yapabilmesi önemlidir. İçlerinde hangi değerlerin bulunabileceğini anlayın.

İstemciler için, web servisinin url'sini bilmek yeterlidir, wsdl her zaman orada olacaktır, bu sayede bu web servisinin sağladığı yöntemler ve parametreleri hakkında fikir edinebilirsiniz.

Tüm bu çanların ve ıslıkların avantajları nelerdir:

  • Çoğu sistemde, yöntemler ve türler otomatik olarak tanımlanır. Şunlar. sunucudaki programcının bu yöntemin bir web servisi üzerinden çağrılabileceğini ve wsdl açıklamasının otomatik olarak oluşturulacağını söylemesi yeterlidir.
  • İyi yapılandırılmış bir açıklama, herhangi bir sabun müşterisi tarafından okunabilir. Şunlar. web hizmeti ne olursa olsun, müşteri web hizmetinin hangi verileri kabul ettiğini anlayacaktır. Bu açıklamaya göre, müşteri sözde nesne sınıflarının kendi iç yapısını oluşturabilir. bağlama "ve. Sonuç olarak, web hizmetini kullanan programcı şöyle bir şey yazmalıdır (sözde kod):

    Yeni Kullanıcı: \u003d TSoapUser.Create ("Vasya", "Pupkin", "odmin"); soap.AddUser (YeniKullanıcı);

  • Otomatik doğrulama.

    • xml doğrulaması. xml iyi biçimlendirilmiş olmalıdır. geçersiz xml - müşteriye hemen bir hata, onu çözmesine izin verin.
    • şema doğrulaması. xml belirli bir yapıya sahip olmalıdır. xml şemaya uymuyor - hemen müşteriye bir hata, anlamasına izin verin.
    • veri doğrulama, sabun sunucusu tarafından gerçekleştirilir, böylece veri türleri, kısıtlamalar açıklamayla eşleşir.
  • Yetkilendirme ve kimlik doğrulama ayrı bir yöntemde uygulanabilir. doğal olarak. veya http yetkilendirmesi kullanarak.
  • Web servisleri hem soap protokolü üzerinden hem de http üzerinden yani istekleri alma yoluyla çalışabilir. Yani, basit veriler (yapı yok) parametre olarak kullanılıyorsa, o zaman basitçe www.site.com/users.asmx/GetUser?Name\u003dVasia veya post edin 'i çağırabilirsiniz. Ancak, bu her yerde ve her zaman değil.
  • ... wikipedia'ya bakın

Ayrıca birçok eksileri var:

  • Mantıksız derecede büyük mesaj boyutu. Eh, burada xml'nin doğası öyledir ki, format gereksizdir, ne kadar çok etiket olursa, o kadar fazla bilgi kullanılmaz. Artı sabun kendi fazlalığını ekler. İntranet sistemleri için trafik sorunu internetten daha az akut olduğundan, yerel ağlar için sabun daha çok talep görmektedir, özellikle Sharepoint'in başarılı bir şekilde (ve bazı kısıtlamalarla) iletişim kurabileceğiniz bir sabun web hizmeti vardır.
  • Web hizmeti açıklamasının otomatik olarak değiştirilmesi tüm istemcileri bozabilir. Pekala, herhangi bir sistemde olduğu gibi, eski yöntemlerle geriye dönük uyumluluk desteklenmiyorsa, her şey düşecek ...
  • Eksi değil, dezavantaj. Yöntemleri çağırmak için tüm eylemler atomik olmalıdır. Örneğin, bir alt bölümle çalışarak, bir işlem başlatabilir, birkaç istek gerçekleştirebilir, sonra geri alabilir veya tamamlayabiliriz. Sabunda işlem yoktur. Bir istek, tek cevap, konuşma bitmiştir.
  • Sunucu tarafında ne olduğunun açıklamasını anlamak oldukça zor olabilir (her şey benim tarafımdan doğru mu?), İstemcide ne var (burada bana ne yazılmıştır?). İstemci tarafıyla ilgilenmem ve sunucu programcısını verilerinin yanlış tanımlandığına ve hiçbir şey anlayamadığına ikna etmem gerekti, çünkü otomatik oluşturma ve o da olduğu gibi yapmamalı, bu bir yazılım işi. Ve hata doğal olarak yöntemin kodundaydı, programcı bunu basitçe görmedi.
  • Uygulama, web hizmetleri geliştiricilerinin bu web hizmetlerini kullanan insanlardan çok uzak olduğunu göstermektedir. Herhangi bir isteğe yanıt olarak (dışarıdan geçerli) anlaşılmaz bir "Hata 5. Her şey kötü" hatası gelebilir. Her şey geliştiricilerin vicdanına bağlı :)
  • muhtemelen henüz bir şey hatırlamadım ...

Örnek olarak açık bir web servisi belavia var:

  • http://86.57.245.235/TimeTable/Service.asmx - giriş noktası, üçüncü taraf geliştiriciler için yöntemlerin bir metin açıklaması da vardır.
  • http://86.57.245.235/TimeTable/Service.asmx?WSDL - alınan ve döndürülen verilerin yöntemlerinin ve türlerinin wsdl açıklaması.
  • http://86.57.245.235/TimeTable/Service.asmx?op\u003dGetAirportsList - bir xml isteği ve bir xml yanıtı örneğiyle belirli bir yöntemin açıklaması.

Aşağıdakiler gibi bir isteği manuel olarak oluşturabilir ve gönderebilirsiniz:

POST /TimeTable/Service.asmx HTTP / 1.1 Ana Bilgisayar: 86.57.245.235 İçerik Türü: metin / xml; charset \u003d utf-8 İçerik-Uzunluk: uzunluk SOAPAction: "http://webservices.belavia.by/GetAirportsList" ru

cevap gelecek:

HTTP / 1.1 200 Tamam Tarih: Pzt, 30 Eylül 2013 00:06:44 GMT Sunucu: Microsoft-IIS / 6.0 X-Powered By: ASP.NET X-AspNet-Sürümü: 4.0.30319 Önbellek Kontrolü: özel, maks. -age \u003d 0 İçerik Türü: metin / xml; charset \u003d utf-8 İçerik-Uzunluk: 2940

Shl Daha önce, Aeroflot web hizmeti açıldı, ancak 1C, 8ku'ya sabun desteği ekledikten sonra, bir grup 1c beta testçisi onu başarıyla bıraktı. Şimdi orada bir şeyler değişti (adresleri bilmiyorum, ilgilenirseniz arama yapabilirsiniz).
ZZY Sorumluluk Reddi. Bana ev düzeyinde söyledi. Tekme atabilirsin.

SABUNdağı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. SOAP başlangıçta öncelikle Uzaktan Yordam Çağrısı'nı (RPC) uygulamak için tasarlanmıştı ve adı bir kısaltmaydı: Basit Nesne Erişim Protokolü. Protokol artık sadece prosedür çağrıları için değil, keyfi XML mesajlarını değiş tokuş etmek için kullanılıyor. Protokolün en son sürüm 1.2'sinin resmi özelliği, SOAP adını hiçbir şekilde deşifre etmez. SOAP, XML-RPC protokolünün bir uzantısıdır. SOAP, herhangi bir uygulama düzeyindeki protokol ile kullanılabilir: SMTP, FTP, HTTP, vb. Ancak, bu protokollerin her biriyle etkileşiminin ayrı ayrı tanımlanması gereken kendi özellikleri vardır. Çoğu zaman SOAP, HTTP üzerinden kullanılır. SOAP, web hizmetleri teknolojisinin dayandığı standartlardan biridir. Web servisleri ve müşterileri arasındaki iletişim XML 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'ın Uzaktan Prosedür Çağrısı (RPC) teknolojisi için ideal olduğunu söyleyebiliriz çünkü SOAP mesajı istemci tarafından sağlanan parametreleri veya servis tarafından gönderilen bir dönüş değerini içerir.

SABUN kullanmanın faydaları:

· Daha esnek veri türleri.

Başlıklar ve uzantılar için destek:

Dezavantajları:

· Mesajları aktarmak için SOAP kullanmak, mesajların ses düzeyini 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 XML belgelerinin doğrudan HTTP üzerinden gönderilmesi daha yaygındır.

· SOAP bir standart olmasına rağmen, farklı programlar genellikle mesajları uyumsuz formatlarda üretir. Örneğin, bir AXIS istemcisi tarafından oluşturulan bir istek WebLogic sunucusu tarafından anlaşılmayacaktır.

Temel protokol kavramları: SOAP mesajını gönderen taraf SOAP göndericisi olarak adlandırılır ve alan taraf SOAP alıcısıdır. SOAP mesajının orijinal göndericiden son alıcıya gittiği yola mesaj yolu denir. Mesaj yolu, bir orijinal gönderen, bir nihai alıcı ve 0 veya daha fazla SOAP aracısı içerir. Mesajları belirli SOAP protokollerinin kurallarına göre işleyen nesnelere SOAP düğümleri denir. SOAP düğümleri arasındaki değiş tokuşa katılan temel bilgi birimi bir SOAP mesajı olarak adlandırılır - bu, kök eleman etrafında bir SOAP sarmalayıcısı olan bir XML belgesidir.

SOAP (Basit Nesne Erişim Protokolü) istemci ve sunucu arasında mesaj aktarımı için standartlaştırılmış bir protokoldür. Genellikle HTTP (S) ile birlikte kullanılır, ancak diğer uygulama katmanı protokolleriyle (örneğin, SMTP ve FTP) çalışabilir.
SABUN testi, test teknikleri açısından temelde diğer API'lerle çalışmaktan farklı değildir, ancak ön hazırlık (protokol teorisi açısından) ve özel test araçları gerektirir. Bu makalede, hem bir SOAP testçisi (bir problem belirledikten sonra "neyi kavrayacağını" bilmeyen) hem de zorlanan bir yönetici için eşit derecede faydalı olacak, gerekli bilgi ve becerilerden oluşan küçük bir kontrol listesi oluşturmak istiyorum. test uzmanlarının bilgilerini değerlendirmek ve eğitim için planlar geliştirmek.

Teorik temel

SOAP'ın bir protokol olduğu gerçeği, test için önemlidir: 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 olan bir XML belgesidir, örneğin:



Julia
Natasha
Hatırlatma
Bir makale yazmayı unutmayın!

XML hakkında daha fazla ayrıntı w3schools veya codenet (Rusça) adresinde bulunabilir. Ad alanlarının açıklamasına (XML'deki öğeleri açıklarken çatışmaları çözme yöntemi) dikkat ettiğinizden emin olun - SOAP'ta bunların kullanımı gereklidir.

XSD
Çalışırken, olası XML belgelerinin standartlaştırılmış bir tanımına sahip olmak ve bunların doğru doldurulup doldurulmadığını kontrol etmek her zaman uygundur. Bunun için XML Şema Tanımı (veya kısaca XSD) var. XSD'nin bir test cihazı için iki ana özelliği, veri türlerinin açıklaması ve olası değerlere kısıtlamaların 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ı
Ayrıca çalışmanızda çeşitli SOAP "uzantıları" ile karşılaşabilirsiniz - WS- * gibi standartlar. En yaygın olanlardan biri, şifreleme ve elektronik imzalarla çalışmanıza izin veren WS-Security'dir. Çoğunlukla, hizmetinizi kullanma haklarını yönetebileceğiniz WS-Policy onunla birlikte kullanılır.

WS-Security kullanma örneği:


Alice
6S3P2EWNP3lQf + 9VC3emNoT57oQ \u003d
YF6j8V / CAqi + 1nRsGLRbuZhi
2008-04-28T10: 02: 11Z

Bu uzantıların tümü, her SOAP hizmetinde kullanılmayan oldukça karmaşık yapılardır; SABUN testini öğrenmenin ilk aşamasında bunları ayrıntılı olarak incelemek, muhtemelen alakalı olmayacaktır.

Araçlar

Zaten anladığınız gibi, SOAP ciddi bir iştir, onunla çalışmak için teoriyi ve sayısız standardı bilmeniz gerekir. Uygulamada, bu tür bir karmaşıklık çok önemli işçilik maliyetlerine yol açacaktır (örneğin, her seferinde bir not defterinde diyagrama bakmak ve istekleri curl ile göndermek gerekli olacaktır). Bu nedenle, SOAP ile çalışmayı kolaylaştırmak için araçlar oluşturulmuştur.

XML / XSD Editörleri
İyi bir test cihazı, dokümantasyonu yazma aşamasında test etmeye başlar, bu nedenle devreleri kontrol etmek için özel düzenleyiciler kullanmak uygundur. En ünlü ikisi Oxygen (çapraz platform) ve Altova'dır (yalnızca Windows); ikisi de ücretli. Bunlar, analistlerin hizmetleri tanımlarken aktif olarak kullandıkları çok güçlü programlardır.

Benim pratiğimde, editörlerin üç özelliğinin yararlı olduğu ortaya çıktı: XSD görselleştirme, XSD'den XML oluşturma ve XSD'ye karşı XML doğrulama.

1. XSD görselleştirme Diyagramın görsel bir temsili için gereklidir, bu da gerekli öğeleri ve öznitelikleri ve mevcut kısıtlamaları hızlı bir şekilde izole etmenize olanak tanır. Örneğin, CheckTextRequest için metin öğesi gereklidir ve üç özniteliğin tümü isteğe bağlıdır (options özniteliği varsayılan olarak sıfır olarak ayarlanmıştır).

Şemada birçok tür ve kısıtlama olduğunda görselleştirme gereklidir. Yalnızca buna ihtiyacınız varsa ve özel düzenleyiciler için ödeme yapmak istemiyorsanız, ücretsiz alternatifleri düşünebilirsiniz (JDeveloper gibi).

2. XSD'ye dayalı XML üretimi geçerli bir mesaj örneği görmek istediğinizde kullanışlıdır. Bir mesajı nasıl dolduracağımı çabucak denemek ve kısıtlamaların nasıl çalıştığına dair nüansları kontrol etmek için kullanıyorum.

3. Özelliği 2. noktadan kullandıktan sonra, yapmakta fayda var xSD'ye göre XML doğrulaması - yani mesajın doğruluğunu kontrol edin. Birlikte, özellikler 2 ve 3, hizmetin kendisi geliştirme aşamasındayken bile XSD'deki zorlu kusurları yakalamanıza izin verir.

Test aracı - SoapUI

SABUN testi neredeyse her zaman SoapUI kullanmak anlamına gelir. Bu aracın kullanımı hakkında farklı kaynaklardan (,) okuyabilirsiniz, ancak en etkili yol resmi belgeleri okumaktır. SoapUI yeterliliğinin 8 koşullu seviyesini ayırt ediyorum:

Seviye 1 - İstek gönderebilirim
WSDL tabanlı bir proje oluşturmayı öğrenin. SoapUI sizin için gerekli tüm talepleri oluşturabilir; sadece doldurma işlemlerinin doğruluğunu kontrol etmeniz ve "Gönder" düğmesine basmanız yeterlidir. Doğru sorgular oluşturma becerilerini geliştirdikten sonra, hatalara neden olan yanlış sorgular oluşturma sanatında ustalaşmalısınız.

Seviye 2 - Test Paketleri ve Test Durumlarını yapabilirim
Mini otomatik testler yapmaya başlayın. Test paketleri ve test senaryoları, API test komut dosyaları oluşturmanıza, istekler için veri hazırlamanıza ve beklenen yanıtı otomatik olarak kontrol etmenize olanak tanır. İlk başta, yalnızca sorgu koleksiyonları olarak kullanılabilirler. Örneğin, bir kusurunuz varsa ve düzelttikten sonra hızlı bir şekilde kontrol etmek istiyorsanız, özellikle kusur talepleri için ayrı bir test kiti seçebilirsiniz.

Seviye 3 - İddia yazabilir
Test senaryolarında ustalaştıktan sonra, bunları otomatik olarak nasıl kontrol edilebilir hale getireceğinizi öğrenmeniz faydalı olacaktır. Bundan sonra, artık "gözlerinizle" yanıtla ilgili bilgi aramanıza gerek kalmayacak: otomatik bir kontrol varsa, vakalar yeşil (kontrol geçildiyse) veya kırmızı (geçmediyse) olarak işaretlenecektir. . SoapUI geniş bir olası iddia kümesi sağlar, ancak en uygun ve basit olanları İçerir ve İçermez. Onların yardımıyla, alınan yanıtta belirli bir metnin varlığını kontrol edebilirsiniz. Bu kontroller ayrıca normal ifade aramalarını da destekler.

Seviye 4 - Onaylarda XPath ve / veya XQuery kullanma
Selenium ile kullanıcı arayüzüne biraz aşina olanlar için XPath tanıdık bir şeydir. Kabaca konuşursak, XPath bir XML belgesindeki öğeleri aramanıza izin verir. XQuery, XPath'i dahili olarak kullanabilen benzer bir teknolojidir; bu dil çok daha güçlü, SQL'e benziyor. Bu dillerin ikisi de İddialarda kullanılabilir. Onların yardımı ile yapılan kontroller daha hedefli ve kararlıdır, bu nedenle davaları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, aynı zamanda birkaç istek de içerebilir (örneğin, standart bir kullanıcı senaryosunu "bir varlık oluştur" → "bir varlığı dışa aktar" gibi benzetmek istediğinizde). İstekler arasında başka özel adımlar olabilir, örneğin:

  • Özellikler ve Mülk Aktarımı (verileri yeniden kullanmaya ve istekler arasında aktarmaya yardımcı olur);
  • JDBC İsteği (veritabanından veri almak için kullanılır);
  • Koşullu Goto (bir test durumunda dallar veya döngüler oluşturmanıza olanak sağlar);
  • TestCase'i çalıştırın (bazı tipik sorguları ayrı test durumlarına getirmeye ve gerektiğinde onları çağırmaya yardımcı olur).

Seviye 6 - Groovy komut dosyalarını kullanma

SoapUI, çeşitli yerlerde Groovy komut dosyaları yazmanıza izin verir. En basit durum, $ (\u003d) ekler kullanarak sorgunun içinde veri üretmektir. Her zaman bunun gibi ekler kullanırım:

  • $ (\u003d yeni Tarih (). format ("yyyy-AA-gg'T'HH: mm: ss")) - geçerli tarih ve saati gerekli formatta eklemek için;
  • $ (\u003d java.util.UUID.randomUUID ()) - doğru şekilde oluşturulmuş rastgele bir GUID eklemek için.

Tam komut dosyaları, vakalarda ve kontrollerde adımlar olarak kullanılabilir. Bir noktada, beşinci seviyeden birkaç özel adımın aynı anda tek bir komut dosyasıyla değiştirilebileceğini göreceksiniz.

Seviye 7 - MockServices kullanma
WSDL tabanlı SoapUI, Sahte nesneler oluşturabilir. Sahte, bir hizmetin en basit simülasyonudur. Taklitleri kullanarak, hizmet gerçekten test için kullanılabilir olmadan önce bile test senaryoları yazmaya ve hata ayıklamaya başlayabilirsiniz. Geçici olarak kullanılamayan hizmetler için saplama olarak da kullanılabilirler.

Seviye 8 - Tanrı Sabunu UI
SoapUI'nin ücretli ve ücretsiz sürümleri arasındaki farkı biliyorsunuz ve kodunuzda SoapUI API'sini kullanıyorsunuz. Eklentileri kullanır ve komut satırı ve / veya CI aracılığıyla vakaları çalıştırırsınız. Test durumlarınız basit ve bakımı kolaydır. Genel olarak, bu enstrümanda "köpeği yediniz". Bu seviyede SoapUI konusunda uzmanlaşan biriyle konuşmaktan mutluluk duyarım. Eğer böyle iseniz - yorumlarda aboneliğinizi iptal edin!

Programlama dilleriyle test etme

Groovy-wslite kullanılarak YandexSpeller API'sine yapılan bir isteğin neye benzediğine dair bir örnek vereceğim:

ithal wslite.soap. *
def client \u003d new SOAPClient ("http://speller.yandex.net/services/spellservice?WSDL")
def response \u003d client.send (SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
vücut (
CheckTextRequest ("lang": "ru", "xmlns": "http://speller.yandex.net/services/spellservice") (
metin ("diken")
}
}
}
"hata" \u003d\u003d response.CheckTextResponse.SpellResult.error.s.text () onaylayın
"1" \u003d\u003d response.CheckTextResponse.SpellResult.error. @ code.text () onaylayın

Bildiğim kadarıyla, SOAP'ı test etmek için henüz yüksek seviyeli çerçeveler (Rest-Assured gibi) yok, ancak son zamanlarda ilginç bir araç ortaya çıktı - karate. SABUN ve DİNLENME test durumlarını Salatalık / Kornişon gibi komut dosyaları olarak tanımlamak için kullanılabilir. Birçok testçi için karate'ye geçmek ideal bir çözüm olacaktır, çünkü vakaların yazılması ve sürdürülmesinin karmaşıklığı açısından bu tür senaryolar, SoapUI kullanmakla kendi SOAP test çerçevenizi yazmak arasında bir yerde olacaktır.

Sonuç

Muhtemelen SABUN'u sadece kendiniz için test etmek istemeyeceksiniz (REST ile yapabileceğiniz gibi). Ciddi kurumsal çözümlerde kullanılan ağır bir protokoldür. Ancak ağırlığı aynı zamanda test uzmanına bir armağandır: kullanılan tüm teknolojiler standartlaştırılmıştır, iş için yüksek kaliteli araçlar vardır. Test edenin tek yapması gereken, onları öğrenme ve kullanma arzusudur.

Bir test uzmanı için gerekli becerilerin kontrol listesini bir araya getirelim. Öyleyse, SOAP servislerini test etmeye yeni başlıyorsanız, bilmeniz ve kullanabilmeniz gerekir:

  • WSDL.
  • SABUN.
  • XML / XSD düzenleyicileri (XSD oluşturma düzeyinde).
  • 1. düzeyde SoapUI.

Gördüğünüz gibi, asıl odak noktası standartlar üzerinde çalışmaktır, SoapUI'de sorguları yürütmek oldukça basittir. SABUN testine kendinizi kaptırırken, daha ciddi beceri ve bilgi gerektiren görevlerle karşı karşıya kalacaksınız, ancak her şeyi bir anda öğrenmeye çalışmamalısınız. Gerçekleştirilen görevlerin karmaşıklık düzeyini artırmada tutarlılık çok daha önemlidir. Bu tavsiyenin ardından bir gün bu alanda iyi bir uzman olduğunuzu anlayacaksınız!

Brett McLaughlin Çeviri: Ilya Chekmenev

SOAP bir Basit Nesne Erişim Protokolüdür. Onu daha önce hiç duymadıysanız, medeniyetten uzak bir vahşi doğada yaşıyor olmalısınız. Web programlamada tüm öfke haline geldi ve en son nesil web geliştirmede bu tür fanatizmle kullanılan web servislerinin ayrılmaz bir parçası oldu. NET, Microsoft'un beyin çocuğu veya eşler arası "devrim" hakkında bir şeyler duyduysanız, SOAP kullanan teknolojileri duymuşsunuzdur (ne olduğunu bilmeseniz bile). Bir tane yok ama iki MSDN destek sitesinde (http://msdn.microsoft.com/) binlerce sayfaya sahip olan Apache ve Microsoft'tan SOAP uygulamaları.

Bu yazıda size SOAP'un ne olduğunu ve web programlama paradigmasının evriminde neden bu kadar önemli bir rol oynadığını anlatacağım. Bu, temel bilgileri atlamanıza ve doğrudan SOAP araç setine atlamanıza yardımcı olacaktır. Ardından, mevcut SOAP projelerine hızlı bir genel bakış sunacağım ve Apache uygulamasının derinliklerine dalacağım. Bu makale SOAP'ın tam resmini yeniden oluşturma iddiasında değil, kitabım Java & XML 2nd Edition pek çok boşluğu doldurdu. Bu makaleyi okuduktan sonra ortaya çıkan birçok sorunun cevabını kitapta bulacaksınız.

Giriş

Öncelikle, SABUN'un ne olduğunu anlamanız gerekir. W3C Görüşünün tamamını (ve çok uzun) http://www.w3.org/TR/SOAP adresinden okuyabilirsiniz. Sonra, tüm saçmalıkları çözüp attıktan sonra, SOAP'ın sadece bir protokol olduğunu anlarsınız. Bu basit bir protokoldür (onu kullanmak için yenisini yazmaya gerek yoktur), dağıtılmış bir mimarinin bir noktasında bilgi alışverişi yapmanın gerekli olduğu fikrine dayanır. Ek olarak, aşırı yükleme olasılığının olduğu ve işlem süreçlerinde zorlukların olduğu sistemler için bu protokol oldukça faydalıdır çünkü hafiftir ve minimum miktarda kaynak gerektirir. Son olarak, tüm işlemlerin HTTP üzerinden gerçekleştirilmesine izin verir, bu da bir güvenlik duvarı gibi zor şeyleri atlamayı ve düşünülemez sayıda bağlantı noktasının soketleri dinlemesini engellemeyi mümkün kılar. Önemli olan, bunu fark etmenizdir ve diğer her şey ayrıntılardır.

Elbette bu detayları bilmek istersiniz ve onları görmezden gelmeyeceğim. SOAP belirtiminin üç temel bileşeni vardır: bir SOAP zarfı, bir dizi şifreleme kuralı ve istek ile yanıt arasında bir iletişim aracı. SABUN mesajını normal bir mektup gibi düşünelim. Zarfların içinde posta pulu ve ön yüzlerinde adres yazılı olan bu eski şeyleri hala hatırlıyor musunuz? Bu benzetme, SABUN kavramını bir "zarf" olarak daha iyi görselleştirmenize yardımcı olacaktır. Şekil 12-1, SOAP süreçlerini bu benzetme biçiminde tasvir etmektedir.

Şekil 12-1. SOAP mesaj süreci

Bu resmi göz önünde bulundurarak, SOAP spesifikasyonunun üç bileşenine bakalım. Bu kavramı en iyi şekilde temsil eden örnekler vererek her birini kısaca açıklayacağım. Bu üç temel bileşen SABUNU çok önemli ve anlamlı kılmaktadır. Hata işleme, çeşitli şifreleme desteği, parametre serileştirme ve SOAP'ın çoğu durumda HTTP üzerinden çalışması, onu diğer dağıtılmış protokol çözümlerinden daha çekici kılar. SOAP, kitabımda daha ayrıntılı olarak ele aldığım diğer uygulamalarla yüksek derecede birlikte çalışabilirlik sağlar. Şimdilik SOAP'ın temel unsurlarına odaklanmak istiyorum.

Zarf

SABUN zarfı, mektup zarfına benzer. Alıcı ve gönderen hakkındaki bilgilerin yanı sıra mesajın kendisiyle ilgili bilgiler de dahil olmak üzere ana SOAP bölümünde şifrelenecek mesaj hakkında bilgiler içerir. Örneğin, bir SOAP zarf başlığı bir mesajın nasıl işlenmesi gerektiğini gösterebilir. Bir uygulama bir mesajı işlemeye başlamadan önce, mesajı işleyip işleyemeyeceği de dahil olmak üzere mesajla ilgili bilgileri ayrıştırır. Standart XML-RPC çağrılarındaki durumun aksine (hatırlayın? XML-RPC mesajları, şifreleme, vb. Her şey tek bir XML parçasında birleştirilir), SOAP ile, mesaj hakkında bir şeyler öğrenmek için mevcut işlem gerçekleşir. Tipik bir SOAP mesajı, alıcıya mesajı işlemede yardımcı olmak için bir şifre stili de içerebilir. Örnek 12-1, bir kodlama spesifikasyonu ile biten bir SOAP zarfını göstermektedir.

Örnek 12-1: SABUN Zarfı

Soapbox http://www-106.ibm.com/developerworks/library/x-soapbx1.html

Gördüğünüz gibi, şifreleme zarfın içinde ayarlanmıştır, bu da uygulamanın karar vermesine izin verir (özniteliğin değerini kullanarak encodingStyle), öğede bulunan gelen mesajı okuyup okuyamayacağı Vücut... SOAP zarfının ad alanının doğru olduğundan emin olun, aksi takdirde iletinizi alan SOAP sunucuları bir sürüm uyuşmazlığı hatası verir ve onlarla etkileşim kuramazsınız.

Şifreleme

SOAP'ın ikinci önemli öğesi, özel veri türlerini şifreleme yeteneğidir. RPC'de (ve XML-RPC'de), şifreleme yalnızca indirdiğiniz XML-RPC araç setinde desteklenen önceden tanımlanmış veri türleri üzerinde gerçekleştirilebilir. Diğer veri türlerini şifrelemek, RPC sunucusunu ve istemcisini kendiniz değiştirmenizi gerektirir. SOAP ile, XML Şeması yeni veri türlerini belirtmek için oldukça kolay bir şekilde kullanılabilir (yapıyı kullanarak complexTypekitabımın 2. Bölümünde tartışıldı) ve bu yeni türler, ana SOAP bölümünün bir parçası olarak XML'de temsil edilebilir. XML Şeması ile entegrasyon sayesinde, bir SOAP mesajındaki her türlü veriyi bir XML Şemasında mantıksal olarak tanımlayarak şifreleyebilirsiniz.

Telefon etmek

Bir SOAP çağrısının nasıl çalıştığını anlamanın en iyi yolu, onu XML-RPC gibi aşina olduğunuz bir şeyle karşılaştırmaktır. Hatırlarsanız, XML-RPC çağrısı Liste 12-2'de gösterilen kod parçacığı gibi görünür.

Örnek 12-2. XML-RPC'de arama

// Kullanılan XML işleyicisini (ayrıştırıcı) belirtin XmlRpc.setDriver ("org.apache.xerces.parsers.SAXParser"); // XmlRpcClient'e bağlanmak için sunucuyu belirtin client \u003d new XmlRpcClient ("http://rpc.middleearth.com"); // Parametreler oluştur Vektör parametreleri \u003d new Vector (); params.addElement (flightNumber); params.addElement (numSeats); params.addElement (creditCardType); params.addElement (creditCardNum); // Boolean buyTickets talep et \u003d (Boolean) client.execute ("ticketCounter.buyTickets", parametreler); // Yanıtı işle

Uçak bileti sipariş etmek için en basit programı oluşturdum. Şimdi, SOAP'ta aramayı gösteren Örnek 12-3'e bir göz atın.

Örnek 12-3. SOAP Çağrısı

// Parametreler oluştur Vektör parametreleri \u003d new Vector (); params.addElement (yeni Parametre ("flightNumber", Integer.class, flightNumber, null)); params.addElement (yeni Parametre ("numSeats", Integer.class, numSeats, null)); params.addElement (yeni Parametre ("creditCardType", String.class, creditCardType, null)); params.addElement (yeni Parametre ("creditCardNumber", Long.class, creditCardNum, null)); // Çağrı nesnesi oluştur Call call \u003d new Call (); call.setTargetObjectURI ("urn: xmltoday-havayolu-biletler"); call.setMethodName ("buyTickets"); call.setEncodingStyleURI (Sabitler.NS_URI_SOAP_ENC); call.setParams (parametreler); // Çağrı Yanıtı res \u003d call.invoke (yeni URL ("http://rpc.middleearth.com"), ""); // Yanıtı işle

Gördüğünüz gibi, nesnenin temsil ettiği gerçek çağrı Telefon etmek, hafızada yerleşiktir. Çağrının hedefini, çağrının yöntemini, kodlama stilini, parametreleri ve bu örnekte sunulmayan diğer birçok parametreyi belirlemenize olanak tanır. XML-RPC yönteminden daha esnektir ve XML-RPC'de dolaylı olarak tanımlanan çeşitli parametreleri açıkça belirtmenize olanak tanır. Bu makalenin ilerleyen kısımlarında, SOAP'un geçersiz istekleri nasıl işlediği, hata hiyerarşisi ve tabii ki döndürülen çağrı sonuçları dahil olmak üzere çağrı süreci hakkında daha fazla bilgi edineceksiniz.

Bu kadar kısa bir girişten sonra, bu komik şeyle ilgilenecek kadar çok şey biliyorsunuz. Şimdi size kullanacağım SABUN uygulamasını tanıtmama izin verin. Neden onu seçtiğimi açıklayacağım ve bazı kod örneklerini ele alacağım.

Özelleştirme

Artık kavram hakkında temel bir anlayışa sahip olduğunuza göre, eğlenceli kısma geçme zamanı: programlama. Bunu yapmak için, ilk bakışta göründüğünden daha kolay bulunabilecek uygun bir proje veya ürüne ihtiyacınız var. SOAP yetenekleri sağlayan bir Java projesine ihtiyacınız varsa, uzun süre aramanıza gerek kalmaz. Ticari ve ücretsiz olmak üzere iki ürün grubu bulunmaktadır. Kitabımda olduğu gibi ticari ürünlerden bahsetmekten kaçınacağım. Bu hiç de kötü oldukları için değil (tersine bazıları güzel), çünkü herhangi bir okuyucunun verilen örneklerden herhangi birini denemesini istiyorum. Bu, birçok ticari ürünün sahip olmadığı kullanılabilirlikten kaynaklanmaktadır. Bunları kullanmak için ödeme yapmanız veya indirdikten sonra sınırlı bir süre için geçici olarak kullanmanız gerekir.

Böylelikle açık kaynak projelere sorunsuz bir şekilde yaklaştık. Bu alanda sadece bir ürün isimlendirebilirim: Apache SOAP. Http://xml.apache.org/soap adresinde bulunur ve Java için SOAP araç seti sağlar. Bu yazının yazıldığı sırada, Apache web sitesinden indirebileceğiniz 2.2 sürümü çıktı. Bu makale için örneklerde kullanacağım versiyon budur.

Diğer alternatifler

Apache SOAP'u kurmaya ve yapılandırmaya geçmeden önce, aklınıza gelmiş olabilecek birkaç soruyu yanıtlayacağım. Kanımca ticari ürünleri kullanmama nedenlerimi oldukça net anlattım. Ancak aklınıza başka açık kaynak projeleri veya kullanmak isteyebileceğiniz ilgili projeler geliyor olabilir ve onlar hakkında hiçbir şekilde yorum yapmadığıma şaşırıyorsunuz.

IBM SOAP4J'e ne dersiniz?

Alternatifler listesinde ilk olarak IBM'den bir uygulama var: SOAP4J. IBM'in çalışması, tıpkı IBM XML4J'nin şimdi Apache Xerces XML Ayrıştırıcı Projesi olarak bilinen şeye dönüşmesi gibi, Apache SOAP projesinin temelini attı. IBM uygulamasının Apache SOAP ile birleştirilecek şekilde yeniden tasarlanması bekleniyor. Kabaca aynı şey IBM'in XML4J'inde de oldu: şimdi yalnızca Xerces'te paketleme sağlıyor. Bu yalnızca eğilimi vurguluyor - büyük üreticiler genellikle OpenSource projelerini destekliyor ve kullanıyor, bu durumda her iki proje (Apache ve IBM) aynı kod tabanını kullanıyor ...

Microsoft kenarda mı?

Tabii ki hayır. Microsoft ve SOAP uygulamasının yanı sıra tüm .NET alanı (kitabımda daha ayrıntılı olarak ele alınmıştır) önemlidir. Aslında, zamanımın çoğunu Microsoft'un SOAP uygulamasına ayrıntılı olarak bakmak istedim, ancak yalnızca onlar gibi COM nesnelerini destekliyor ve Java'yı desteklemiyor. Bu nedenlerden ötürü, Java ve XML ile ilgili bir makaleye böyle bir açıklama dahil edilemez. Bununla birlikte, Microsoft (geliştiriciler olarak bu şirkete karşı yaptığımız tüm iddialara rağmen) web hizmetleri alanında önemli işler yaptık ve tereddüt etmeden reddederseniz, yalnızca çıplak duygularla yönlendirilirseniz bir hata yaparsınız. COM veya Visual Basic bileşenleriyle çalışmanız gerekiyorsa, http://msdn.microsoft.com/library/default.asp?url\u003d/nhp/Default.asp adresinde bulunan Microsoft SOAP araç setini kullanmanızı şiddetle tavsiye ederim. ? contentid \u003d 28000523, diğer birçok SOAP kaynağı ile birlikte.

Axis nedir?

Apaçi'yi izleyenleriniz Apache Axis'i duymuş olmalı. Axis, Apache XML şemsiyesi altında da geliştirilen yeni nesil bir SOAP araç setidir. Son yıllarda hızlı ve radikal bir şekilde gelişen SOAP (spesifikasyon, spesifik bir uygulama değil) takibi çok zordur. Mevcut gelişen gereksinimlerle tamamen uyumlu bir SOAP sürümü oluşturmaya çalışmak da zordur. Sonuç olarak, Apache SOAP'ın şu anki sürümü, kısıtlı bir tasarım çözümü sunar. Apache geliştiricileri, mevcut aracı tamamen tersine çevirmeye çalışmamaya karar vererek, yeni koda dayalı bir proje oluşturmaya başladılar. Axis doğdu. SABUN adı da önce SOAP'tan XP'ye ve sonra XMLP'ye değişti. Daha sonra şartnamenin adı yeni SOAP adından çıkarıldı ve "Axis" adı doğdu. Ancak şimdi W3C, SOAP belirtiminin adını (sürüm 1.2 veya 2.0) yeniden ziyaret ediyor gibi görünüyor, bu nedenle işler hala değişebilir ve daha fazla kafa karışıklığı olacaktır!

IBM SOAP4J'i bir SABUN araç mimarisi olarak düşünün? Bir mimari olarak Apache SOAP'a (bu makalede ele alınan) ne dersiniz? Ve Axis, yeni nesil mimari olan # 3 mimarisidir. Bu proje SAX'i kullanırken Apache SOAP DOM tabanlıdır. Ek olarak Axis, Apache SOAP'tan daha dostça bir kullanıcı deneyimi sağlar. Bu değerleri sıraladıktan sonra, konu olarak Axis'i neden seçmediğimi merak edebilirsiniz. Sadece biraz erken olur. Şu anda sadece 0.51 Eksen sürümü yayınlanmak üzere hazırlanıyor. Henüz beta değil, bir alfa sürümü bile değil. Axis için yeni özelliklerin ana hatlarını çizmeyi çok isterim, ancak yönetiminizi kritik sistem ihtiyaçlarınız için alfa altındaki açık kaynaklı yazılımı kullanabileceğiniz konusunda ikna etme şansınız olmaz. Bu yüzden gerçek olduğun bir şeye odaklanmaya karar verdim kullanabilirsiniz zaten bugün - Apache SABUNU. Apache Axis'in son versiyonu çıktığında, kitabımın bir sonraki baskısında bu materyali güncelleyeceğimi düşünüyorum. O zamana kadar, zaten mevcut olan çözüme odaklanalım.

Kurulum

İki çeşit SOAP kurulumu vardır. Birincisi, SOAP mesajlarını kabul edebilen bir sunucuyla iletişim kurmak için SOAP API kullanarak bir SOAP istemcisi başlatmaktır. İkinci yol, SOAP istemcisinden mesajlar alabilen bir SOAP sunucusu başlatmaktır. Bu bölümde, her iki prosedürü de anlattım.

Müşteri

SOAP istemcisini kullanmak için, önce http://xml.apache.org/dist/soap adresinde bulunan Apache SOAP'u indirmeniz gerekir. 2.2 sürümünü ikili biçimde indirdim (alt dizinden versiyon-2.2). Ardından arşivin içeriğini bilgisayarınızdaki bir dizine açmanız gerekir. Benim durumumda, dizindi javaxml2 (c: \\ javaxml2 Windows bilgisayarımda, / javaxml2 Mac OS X bilgisayarımda). Sonuç olarak, dosyalar sıkıştırılmış / javaxml2 / soap-2_2... Ayrıca http://java.sun.com/products/javamail/ adresindeki Sun sunucusunda bulunan JavaMail paketini indirmeniz gerekecektir. Apache SOAP tarafından kullanılan SMTP taşıma protokolünü desteklemesi gerekecektir. Ardından, http://java.sun.com/products/beans/glasgow/jaf.html adresindeki Sun sunucusunda da bulunan Java Beans Activation Framework'ü (JAF) indirin. Halihazırda Xerces veya başka bir XML ayrıştırıcısının kurulu ve kullanıma hazır olduğu varsayımına göre.

Not: XML ayrıştırıcınızın JAXP uyumlu olduğundan ve doğru ad alanını kullandığından emin olun. Büyük olasılıkla ayrıştırıcınız bu gereksinimleri karşılıyor.Eğer sorun yaşıyorsanız en iyisi Xerces'i kullanmaya dönmektir.

Not: Xerces'in en son sürümlerini kullanın. 1.4 veya daha sonraki sürümler işe yarar. SOAP ve Xerces 1.3 (.1) ile ilgili bir dizi hata var, bu yüzden bu kombinasyonu kullanmamanızı tavsiye ederim.

JavaMail ve JAF paketlerini açın ve daha sonra jar dosyalarını sınıf yolunuzun yanı sıra kitaplığa ekleyin soap.jar... Bu jar dosyalarının her biri, ilgili programın kök dizininde veya bir alt dizinde yer almalıdır. / lib... Tamamlandığında, değişkeniniz sınıf yolu şöyle bir şeye benzemeli:

$ echo $ CLASSPATH /javaxml2/soap-2_2/lib/soap.jar:/javaxml2/lib/xerces.jar: /javaxml2/javamail-1.2/mail.jar:/javaxml2/jaf-1.0.1/activation.jar

Windows için şu şekilde görünecektir:

c: \\\u003e echo% CLASSPATH% c: \\ javaxml2 \\ soap-2_2 \\ lib \\ soap.jar; c: \\ javaxml2 \\ lib \\ xerces.jar; c: \\ javaxml2 \\ javamail-1.2 \\ mail.jar; c: \\ javaxml2 \\ jaf-1.0.1 \\ activation.jar

Son olarak dizini ekleyin javaxml2 / sabun-2_2 / senin içinde sınıf yolu SOAP örneklerini çalıştırmak için. Bu bölümde birkaç örnek için özelleştirmeyi anlattım.

Sunucu

SOAP uyumlu bir sunucu bileşenleri kümesi oluşturmak için önce bir sunucu uygulaması motoruna ihtiyacınız vardır. Önceki bölümlerde olduğu gibi, bu bölüm için örnek olarak Apache Tomcat'i (http://jakarta.apache.org/ adresinde mevcuttur) kullandım. Müşterinin ihtiyaç duyduğu her şeyi eklemeniz gerekecek sınıf yolu sunucu. Bunu yapmanın en kolay yolu sıfırlamaktır soap.jar, activation.jar ve mail.jarve ayrıştırıcınız, servlet motorunuzun kitaplık dizinine. Tomcat için bu, otomatik yükleme için kitaplıkları içeren / lib dizinidir. Komut dosyası desteği sağlamak istiyorsanız (bu bölümde tartışılmamış ancak Apache SOAP örneklerinde anlatılmıştır), bsf.jar (http://oss.software.ibm.com/developerworks/projects/bsf adresinde mevcuttur) ve js.jar (http://www.mozilla.org/rhino/ adresinde mevcuttur) aynı dizine.

Not: Tomcat ile Xerces kullanıyorsanız, Bölüm 10'da anlattığım numarayı tekrarlamanız gerekecektir. parser.jar içinde z_parser.jar, ve jaxp.jariçinde z_jaxp.jaremin olmak için xerces.jar ve dahil olan JAXP sürümü, herhangi bir başka ayrıştırıcı veya JAXP uygulamasından önce yüklenir.

Ardından, servlet motorunuzu yeniden yükleyin, bu noktada SOAP sunucu bileşenlerini yazmaya hazırsınız.

Yönlendirici Sunucusu ve Yönetici İstemcisi

Temel işlemlerin yanı sıra, Apache SOAP bir yönlendirici sunucu uygulamasının yanı sıra bir yönetici istemcisi içerir. Bunları kullanmayacak olsanız bile, SOAP'ın doğru kurulup kurulmadığını test etmek için kurmanızı tavsiye ederim. Bu işlem hangi sunucu motorunu kullandığınıza bağlıdır, bu nedenle kendimi Tomcat'in kurulum sürecini açıklamakla sınırlayacağım. Diğer servlet motorlarından bazıları için kurulum talimatları http://xml.apache.org/soap/docs/index.html adresinde bulunabilir.

Tomcat altına kurulum çok basit: sadece dosyayı alın soap.war dizinden soap-2_2 / webapps ve dizine bırakın $ TOMCAT_HOME / webapps - bu kadar! Kurulumu kontrol etmek için tarayıcıya adresi girin http: // localhost: 8080 / soap / servlet / rpcrouter... Şekil 12-2'ye benzer bir cevap almalısınız.

Şekil 12-2. RPC Yönlendirici Servlet

Mesaj bir hata mesajı gibi görünse de her şeyin doğru çalıştığını gösterir. Tarayıcınızda yönetici istemci adresini belirterek aynı yanıtı almalısınız: http: // localhost: 8080 / soap / servlet / messagerouter.

Sunucu ve istemci testinizi tamamlamak için tüm talimatları eksiksiz bir şekilde uyguladığınızdan emin olun. Ardından, RPC yönlendirici sunucu uygulaması için sunucu uygulaması URL'nizi desteklemek üzere aşağıda gösterildiği gibi aşağıdaki Java sınıfını çalıştırın:

C: \\\u003e java org.apache.soap.server.ServiceManagerClient http: // localhost: 8080 / soap / servlet / rpcrouter listesi Dağıtılmış Hizmetler:

Yukarıda gösterildiği gibi boş bir hizmet listesi almalısınız. Herhangi bir mesaj alırsanız, http://xml.apache.org/soap/docs/trouble/index.html adresinde bulunan olası hataların uzun listesine bakın. Bu, karşılaşmış olabileceğiniz sorunların en kapsamlı listesidir. Boş bir liste alırsanız, yapılandırma tamamlanmıştır ve bu bölümdeki örneklere bakmaya hazırsınız demektir.

Başlayalım

Herhangi bir SOAP tabanlı sistemi yazmanın üç ana adımı vardır. Listeledikten sonra, kısaca her birine odaklanacağım:

  • SOAP-RPC ve SOAP mesajları arasında seçim;
  • Bir SOAP hizmetine yazma veya erişme;
  • SOAP istemcisi yazma veya erişme.

İlk adım, SOAP'ı RPC aramaları (uzak yordamın sunucuda yürütüldüğü yer) veya mesajlar (istemcinin yalnızca bilgi parçalarını sunucuya gönderdiği) için kullanıp kullanmayacağınızı seçmektir. Bu süreçleri aşağıda detaylı olarak tartışıyorum. Bu kararı verdikten sonra, kendi hizmetinize erişmeniz veya oluşturmanız gerekir. Elbette, hepimiz Java uzmanı olduğumuz için, bu bölüm kendinizinkini nasıl oluşturacağınızı açıklıyor. Ve son olarak, bu hizmet için bir müşteri yazmanız gerekiyor, hepsi bu kadar!

RPC veya Mesajlaşma?

İlk göreviniz programlama ile ilgili değildir ve daha çok bir tasarım niteliğindedir. RPC hizmetini mi yoksa mesajları mı kullanacağınızı seçmeniz gerekir. RPC'ye aşina olduğunuzu varsayalım (örneğin, kitabımın bölümlerinden birini okuduktan sonra). İstemci, sunucuda uzak bir yordamı yürütür ve ardından bir yanıt alır. Bu senaryoda, SOAP, daha iyi hata işleme ve karmaşık veri türlerinin ağ üzerinden aktarılmasını sağlayan zengin bir XML-RPC sistemi olarak işlev görür. Bu konsepte zaten aşinasınız ve SOAP'ta RPC sistemleri yazmak daha kolay olduğu için onlarla başlayacağım. Bu makale bir RPC hizmetinin, bir RPC istemcisinin nasıl oluşturulacağını ve sistemin nasıl kurulup çalıştırılacağını açıklar.

Başka bir SOAP tarzı çalışma mesajlaşmadır. Uzaktan prosedürler yerine sadece bilgi alışverişi için kullanılır. Tahmin edebileceğiniz gibi, bu, istemcinin herhangi bir sunucunun bireysel yöntemlerini bilmesini gerektirmeyen güçlü bir araçtır. Ayrıca, veri paketlerinin (mecazi olarak, ağa bağlı değil) paketlerinin diğer sistemlere aktarım için kullanılmasına izin vererek uzak sistemlerin modellemesini daha izole hale getirir. Aynı zamanda diğer sistemlerin bu verilerle yapılan işlemleri bilmesine gerek yoktur. Bu stil, RPC programlamadan daha karmaşıktır, bu yüzden onu burada yeniden üretmeyeceğim. Bunu, işletmeler arası etkileşimlerin diğer ayrıntılarıyla birlikte kitabımda bulacaksınız. Öncelikle SOAP-RPC programlamasına bir göz atın.

Çoğu tasarım probleminde olduğu gibi, bu karar tamamen size bağlıdır. Uygulamanızı analiz edin ve SOAP'ı ne için kullanmanız gerektiğini belirlemeye çalışın. Bir sunucunuz ve talep üzerine belirli iş işlevlerini gerçekleştiren bir dizi istemciniz varsa, RPC sizin için daha uygundur. İletişimin sadece talep üzerine belirli iş işlevlerini yerine getirmekten daha fazlası olduğu karmaşık sistemlerde, SOAP mesajları çok tercih edilir.

RPC hizmeti

Artık formaliteler bittiğine göre harekete geçme zamanı. Bildiğiniz gibi, RPC'de yöntemleri uzaktan çalıştırılacak sınıflara ihtiyacınız var.

Kod parçacıkları

Sunucunun kod parçacıklarına bakarak başlayacağım. Bu parçacıklar, RPC istemcilerinde çalışan yöntemlere sahip sınıflardır. Kitabımdaki kodu örnek olarak kullandım. Basit sınıfları kullanmak yerine, SOAP'ın gücünü olabildiğince açık bir şekilde göstermek için daha karmaşık bir örnek seçtim. Bu yüzden örnek olarak CD sınıfını kullandım. İlk önce öğeyi tanımlıyoruz harita standart olmayan her parametre türü için. Öznitelik için encodingStyleen azından Apache SOAP 2.2'de. http://schemas.xmlsoap.org/soap/encoding/ değerini vermelisiniz. Şu anda desteklenen tek kodlama budur. Kullanıcı tanımlı tür için bir ad alanı ve ardından bu tür için bir ad alanı önekiyle birlikte sınıf adı sağlamanız gerekir. Bizim durumumuzda, bu amaçlar doğrultusunda, hayali bir ad alanı ve basit bir önek kullandım " x". Ardından özniteliği kullanarak javaType, Java sınıfının gerçek adını ayarlayın (bu durum için - javaxml2.CD). Ve son olarak, niteliklere sahip kuralesil java2XMLClassName ve xml2JavaClassName... Java'dan XML'e ve tersi yönde dönüşen bir sınıfı tanımlamak için kullanılırlar. Apache SOAP ile birlikte gelen çok kullanışlı BeanSerializer sınıfını kullandım. Özel parametreniz JavaBean formatındaysa, bu serileştirici ve seriyi kaldırma işlemi sizi kendi parametrenizi yazma zahmetinden kurtaracaktır. Varsayılan bir kurucuya sahip bir sınıfa ihtiyacınız var (hatırlayın, CD sınıfı için basit, parametresiz, yapıcı ayarlıyorum) ve bu sınıfın tüm verilerini yöntemleri kullanarak yayınlayın. setXXX ve getXXX... Sınıftan beri CD tüm bu gereksinimleri mükemmel şekilde karşılar, BeanSerializer mükemmel çalışıyor.

Not: Ne sınıf CD gereksinimleri karşılar BeanSerializer... gerçekten önemli değil. Sınıfların çoğu bu formata kolayca dönüştürülebilir. Bu nedenle, kendi serileştiricilerinizi ve seri kaldırıcılarınızı yazmaktan kaçınmanızı tavsiye ederim. Bu fazladan bir baş ağrısıdır (karmaşık bir şey değil, çok zahmetli) ve biraz enerji tasarrufu yapmanızı ve özel parametrelerinizde çöp kutusu dönüşümünü kullanmanızı tavsiye ederim. Pek çok durumda, fasulye dönüşümleri, sınıfınızda yalnızca varsayılan bir kurucu (parametre yok) gerektirir.

Şimdi yeniden yaratalım kavanoz hizmetimizi dosyalayın ve yeniden konumlandırın:

(gandalf) / javaxml2 / Ch12 $ java org.apache.soap.server.ServiceManagerClient http: // localhost: 8080 / soap / servlet / rpcrouter xml / CDCatalogDD.xml

Dikkat: Sunucu uygulaması motorunuzu çalışır durumda bırakırsanız ve aynı zamanda hizmeti yeniden konumlandırırsanız, SOAP hizmeti için yeni sınıfları etkinleştirmek ve hizmeti yeniden konumlandırmak için sunucu uygulaması motorunu yeniden başlatmanız gerekecektir.

Şimdi, yeni sınıfları ve yöntemleri kullanmak için istemciyi değiştirmek kalır. Örnek 12-10, istemci sınıfının değiştirilmiş bir sürümünü içerir CDAdder... Önceki versiyonda yapılan değişiklikler vurgulanmıştır.

Örnek 12-10: Güncellenmiş CDAdder sınıfı

paket javaxml2; java.net.URL dosyasını içe aktarın; import java.util.Vector; import org.apache.soap.Constants; org.apache.soap.Fault'u içe aktarın; import org.apache.soap.SOAPException; import org.apache.soap.encoding.SOAPMappingRegistry; import org.apache.soap.encoding.soapenc.BeanSerializer;import org.apache.soap.rpc.Call; import org.apache.soap.rpc.Parameter; import org.apache.soap.rpc.Response; import org.apache.soap.util.xml.QName; genel sınıf CDAdder ( public void add (URL url, Dize başlığı, Dize sanatçısı, Dize etiketi) SOAPException ( System.out.println ("" "+ başlık +" "sanatçı" "+ sanatçı +" "stüdyolar" + etiketli bir CD eklemek); CD cd \u003d yeni CD (başlık, sanatçı, etiket); // Bir çağrı nesnesi oluşturun Call Call call \u003d new Call (); call.setSOAPMappingRegistry (kayıt defteri); call.setTargetObjectURI ("urn: cd-katalog"); call.setMethodName ("addCD"); call.setEncodingStyleURI (Sabitler.NS_URI_SOAP_ENC); // Parametreleri ayarlama Vektör parametreleri \u003d new Vector (); params.addElement (yeni Parametre ("cd", CD.class, cd, null)); call.setParams (parametreler); // Invoke call Response yanıtını işleyin; yanıt \u003d call.invoke (url, ""); if (! response.generatedFault ()) (System.out.println ("CD ekleme başarıyla tamamlandı.");) else (Fault error \u003d response.getFault (); System.out.println (Hata: "+ error.getFaultString ());)) public static void main (String argümanları) (if (args.length! \u003d 4) (System.out.println ("Şablon: java javaxml2.CDAdder" + "\\" [CD Başlığı] \\ "\\" [Sanatçı adı] \\ "\\" [CD Stüdyosu] \\ ""); dönüş;) deneyin (// SOAP sunucusunun URL'si URL'ye bağlanmak için url \u003d yeni URL (değiştirgeler); // Yeni CD Dizesi için değerleri alın title \u003d args; String artist \u003d değiştirgeler; Dize etiketi \u003d değiştirgeler; // CDAdder adder'ı ekleyin \u003d new CDAdder (); adder.add (url, başlık, sanatçı, etiket); ) catch (Exception e) (e.printStackTrace ();)))

Gerçekten ilginç olan tek değişiklik, sınıfın gösterilmesiyle ilgilidir. CD:

// SOAP MappingRegistry kayıt defteri \u003d new SOAPMappingRegistry (); BeanSerializer serializer \u003d new BeanSerializer (); kayıt defteri.mapTypes (Sabitler.NS_URI_SOAP_ENC, yeni QName ("urn: cd-katalog-demo", "cd"), CD.class, serileştirici, serileştirici);

Bu, özel bir parametrenin ağ üzerinden nasıl kodlanıp iletilebileceğini gösterir. Sana sınıfın nasıl olduğunu zaten söyledim BeanSerializer sınıf gibi JavaBean formatındaki parametreleri işlemek için kullanılabilir CD... Onları sunucuya yönlendirmek için bir dağıtım tanımlayıcı kullandım, ancak şimdi istemciye bu serileştiriciyi ve seriyi kaldırıcıyı kullanmasını söylemem gerekiyor. Bu işlev sınıf tarafından gerçekleştirilir SABUN HARİTASI... Yöntem mapTypes () şifrelenmiş bir dizge alır (ve yine bunun için sabiti kullanmak daha iyidir NS_URI_SOAP_ENC) ve özel serileştirmenin kullanılması gereken parametrenin türü hakkında bilgi. Önce QName belirtilir. Dağıtım tanımlayıcısında garip bir ad alanının kullanılmasının nedeni budur. Burada aynı URN'yi ve yerel öğe adını (bu örnek için "CD"), ardından Java nesnesini belirtmeniz gerekir. Sınıf serileştirilecek sınıf ( CD.class) ve son olarak, serileştirme ve seriyi kaldırma için sınıfın bir örneği. Bu örnek için her iki durumda da bir örnek görünecektir BeanSerializer... Tüm bu ayarlar kayıt defterine girildikten sonra, bunu nesneye bildirin Telefon etmek yöntemi kullanarak setSOAPMapping-Registry ().

Bu sınıfı daha önce gösterildiği gibi bir CD ekleyerek çalıştırabilirsiniz ve her şey beklendiği gibi çalışmalıdır:

C: \\ javaxml2 \\ build\u003e java javaxml2.CDAdder http: // localhost: 8080 / soap / servlet / rpcrouter "Tony Rice" "Manzanita" "Sugar Hill"Sugar Hill Studio'dan "Manzanita" tarafından "Tony Rice" adlı CD'nin eklenmesi Başarılı CD eklenmesi.

Sınıf değişikliğinden ayrıldım CDLister Senin için. Her şey aynı düzeni takip ediyor. Kendinizi test etmek için, kitabımdaki bu güncellenmiş sınıfları zaten içeren örneklerle dosyalara başvurabilirsiniz.

Not: Buna dersten beri karar verebilirsiniz. CDLister doğrudan nesne ile etkileşime girmez CD (yöntemle döndürüldü liste () önemli olan tip Hashtable), herhangi bir değişiklik yapmanız gerekmez. Ancak, döndürülen sınıf Hashtable nesne örnekleri içerir CD... SOAP bunların serisini nasıl kaldıracağını bilmiyorsa, istemci bir hata mesajı atar. Bu durumda sorunu çözmek için nesnede belirtmelisiniz Telefon etmek kopya SABUN HARİTASI.

Etkili hata yönetimi

Artık özel nesnelere, RPC çağrılarına ve daha fazlasına aşina olduğunuza göre, daha az heyecan verici bir konu hakkında konuşmama izin verin: hata işleme. Herhangi bir ağ işleminde birçok arıza meydana gelebilir. Hizmet başlamıyor, sunucu işleminde bir hata, nesne bulunamıyor, sınıflar eksik ve diğer birçok sorun. Şimdiye kadar sadece yöntemi kullandım error.getString () hata mesajları oluşturmak için. Ancak bu yöntem her zaman yardımcı olmayabilir. Eylem halinde görmek için yapıcıdaki yorumu temizleyin CDCatalog:

genel CDCatalog () ( // katalog \u003d new Hashtable (); // Dizin oluştur addCD (yeni CD ("Nickel Creek", "Nickel Creek", "Sugar Hill")); addCD (yeni CD ("Let it Fall", "Sean Watkins", "Sugar Hill")); addCD (yeni CD ("Hava Sınırları", "Michael Hedges", "Windham Hill")); addCD (yeni CD ("Taproot", "Michael Hedges", "Windham Hill")); )

Yeniden derleyin, sunucu uygulaması motorunu yeniden başlatın ve yeniden bölümleyin. Bu bir istisna ile sonuçlanacaktır. NullPointerException Bir sınıf oluşturucu başlatılmamış olana CD eklemeye çalıştığında Hashtable... İstemciyi başlatırken bir hata mesajı görünecek, ancak çok bilgilendirici olmayacaktır:

(gandalf) / javaxml2 / build $ java javaxml2.CDLister http: // localhost: 8080 / soap / servlet / rpcrouter Geçerli CD dizinini görüntüleyin. Hata: Hedef nesne çözülemiyor: boş

Bu, hatayı saptamanıza ve düzeltmenize yardımcı olabilecek türden bilgiler değildir. Yine de çerçeve, hata işlemeyi düzgün bir şekilde ele alır. Hatırlarsın DOMFaultListenerelement değeri olarak ayarladığınız faultListener? Oyuna adım atma zamanı gelmişti. Hatayla döndürülen nesne Hata DOM (Belge Nesne Modeli) içerir org.w3c.dom.Element hata hakkında ayrıntılı bilgi ile. Önce içe aktarma ifadesini kaynak kodunuza ekleyin java.util.Iterator:

java.net.URL dosyasını içe aktarın; import java.util.Enumeration; java.util.Hashtable'ı içe aktarın; java.util.Iterator'ı içe aktarın;import java.util.Vector; import org.apache.soap.Constants; org.apache.soap.Fault'u içe aktarın; import org.apache.soap.SOAPException; import org.apache.soap.encoding.SOAPMappingRegistry; import org.apache.soap.encoding.soapenc.BeanSerializer; import org.apache.soap.rpc.Call; import org.apache.soap.rpc.Parameter; import org.apache.soap.rpc.Response; import org.apache.soap.util.xml.QName;

Şimdi list () yöntemindeki hataları işlemek için değişiklikler yapalım:

if (! response.generatedFault ()) (Parametre returnValue \u003d response.getReturnValue (); Hashtable kataloğu \u003d (Hashtable) returnValue.getValue (); Numaralandırma e \u003d katalog.keys (); while (e.hasMoreElements ()) (Dize title \u003d (Dize) e.nextElement (); CD cd \u003d (CD) catalog.get (title); System.out.println ("" "+ cd.getTitle () +" "sanatçı" + cd.getArtist () + "stüdyolar" + cd.getLabel ());)) else (Hata hatası \u003d response.getFault (); System.out.println ("Hata:" + error.getFaultString ()); Vektör girdileri \u003d error.getDetailEntries (); (Yineleyici i \u003d entryler.iterator (); i.hasNext ();) (org.w3c.dom.Element entry \u003d (org.w3c.dom.Element) i.next (); System.out.println (giriş .getFirstChild (). getNodeValue ());))

Yöntemi kullanarak getDetailEntries () sorunla ilgili bilgiler içeren desteklenen bir SOAP hizmetine ve ham veri sunucusuna erişirsiniz. Kod onları yeniden işler (genellikle tek bir öğe vardır, ancak çok dikkat gerektirir) ve DOM'u keser Elemanher girişte bulunur. Temel olarak, işte çalıştığınız XML:

SOAP-ENV: Server.BadTargetObjectURI Hedef çözülemiyor: boş İşte istediğimiz bu!

Başka bir deyişle, Fault nesnesi, SOAP zarfının hataları içeren kısmına erişmenizi sağlar. Apache SOAP ayrıca hata olması durumunda bir Java yığın izlemesi sağlar ve bunları düzeltmek için gereken ayrıntılı bilgileri sağlar. Elemanı yakalayarak yığın izleme ve düğüm değerini yazdırmak Metin bu öğeden istemciniz sunucu yığın izlemesini yazdırabilir. Bu değişiklikleri derlemek ve istemciyi yeniden başlatmak size aşağıdaki çıktıyı verecektir:

C: \\ javaxml2 \\ build\u003e java javaxml2.CDLister http: // localhost: 8080 / soap / servlet / rpcr dış Geçerli CD dizinini görüntüleyin. Hata: Hedef çözümlenemiyor: javaxml2.CDCatalog'da javaxml2.CDCatalog.addCD'de (CDCatalog.java:24) null java.lang.NullPointerException. (CDCatalog.java:14) java.lang.Class.newInstance0 at (Native Method) java.lang.Class.newInstance (Class.java:237)

Bu çok daha iyi değil, ancak en azından bir istisna atıldığına dair bazı güzel bilgiler görebilirsiniz. NullPointerException ve hatta bu sorunun oluştuğu sunucu sınıflarındaki satır numaralarını öğrenin. Bu son değişikliklerin sonucu, size hata işleme sorunu hakkında görsel bir anlayış sağladı. Şimdi sunucu sınıflarınızı hatalar için kontrol etmelisiniz. Evet, neredeyse unutuyordum, ondan önce sınıfınızı geri değiştirmeyi unutmayın CDCatalogaçıklık için kasıtlı olarak yaptığımız hatalardan kurtulmak için!

  1. SOAP'ı SMTP (hatta Jabber) gibi diğer protokoller üzerinden çalıştırmak hakkında çok fazla konuşma var. SOAP standardı henüz bunu sağlamamaktadır, ancak gelecekte benzer yetenekler eklenebilir. Bu nedenle, bu konuda aktif tartışmalarla karşılaşırsanız şaşırmayın.