Veb-xizmat nima - bu WSDL bilan tavsiflangan. SOAP veb-xizmati Spring-WS bilan

Kompyuter xavfsizligi

WSDL 1.1 veb-xizmatlarini qanday belgilaydi va WSDL hujjatlarini tekshirish va o'zgartirish uchun Java modellarini qanday yaratish kerak

Tarkib seriyasi:

Ushbu maqolalar seriyasi haqida

Veb-xizmatlar korporativ hisoblashda Java ™ texnologiyasining muhim xususiyati hisoblanadi. Ushbu maqolalar seriyasida XML va veb-xizmatlar bo'yicha maslahatchisi Denis Sosnovskiy veb-xizmatlaridan foydalanadigan Java ishlab chiquvchilari uchun muhim bo'lgan asosiy ramkalar va texnologiyalarni muhokama qiladi. Ushbu sohadagi so'nggi yangiliklardan xabardor bo'lish va ularni o'z loyihalaringizda qanday qo'llashni bilish uchun ketma-ket maqolalarni kuzatib boring.

Korporativ dasturlar uchun veb-xizmatlar asosan xizmat ta'riflaridan foydalanishga tayanadi. Xizmat ta'riflari xizmat ko'rsatuvchi provayder bilan har qanday potentsial mijoz o'rtasidagi asosiy kelishuvni tavsiflaydi, unda xizmat tomonidan taqdim etiladigan funktsiyalar turlari va har bir funktsiya ichidagi xabarlar batafsil bayon etilgan. Provayderlar va iste'molchilar o'zlarining almashinadigan ob'ektlarini qanday amalga oshirishni tanlashlari mumkin, chunki ular yuborgan haqiqiy xabarlar xizmat ta'rifiga mos keladi. XML-xabarlarning qanday almashinishini tavsiflash uchun xizmat ta'rifidan foydalanish - bu veb-xizmatlarni ilgari tarqatilgan dasturlash texnologiyalaridan farq qiladi.

Veb-xizmatlarni aniqlash uchun turli usullar taklif qilingan, ammo WSDL 1.1 eng keng qo'llaniladigan usul bo'lib qolmoqda. WSDL 1.1 bir nechta kamchiliklarga ega, shu jumladan o'ta murakkab tuzilma, bu esa o'qimaganlar uchun o'qishni qiyinlashtiradi. Shuningdek, u vakolatli rasmiy ta'rifning etishmasligidan aziyat chekmoqda, bu esa asl spetsifikatsiya hujjatidagi ba'zi bo'shliqlarni to'ldiradigan izchil "aniqliklarni" keltirib chiqardi. Natijada, veb-xizmatlar to'plamlari WSDL 1.1 hujjatlarini iloji boricha moslashuvchan ishlashga harakat qilishadi. Ushbu moslashuvchanlik WSDL 1.1 ni tushunishda chalkashliklarni kuchaytirishi mumkin, chunki ishlab chiquvchilar har qanday yondashuv afzalroq bo'lishini ko'rsatmasdan WSDL tuzilmalarining xilma-xilligini ko'rishadi.

Ushbu maqolada biz sizga WSDL 1.1 hujjatlarini qanday tahlil qilishni va WSDL hujjatlarini tasdiqlash va ularni standart shaklga o'tkazish uchun Java modelining birinchi qismlari bilan tanishishingizni ko'rsatamiz.

WSDL 1.1-ni tahlil qilish

Ism maydonlari ishlatilgan

Ushbu maqola quyidagilardan foydalanadi:

  • wSDL 1.1 nom maydonini ifodalovchi wsdl prefiksi http://schemas.xmlsoap.org/wsdl/;
  • wSDL 1.1 SOAP 1.1 kengaytmasi tomonidan ishlatiladigan http://schemas.xmlsoap.org/wsdl/soap/ nom maydoni uchun sovun prefiksi
  • xML sxemalarini aniqlash uchun ishlatiladigan http://www.w3.org/2001/XMLSchema nom maydoni uchun xs prefiksi.

2001 yil boshida nashr etilgan WSDL 1.1-versiyasi 2007 yilda nashr etilgan W3C WSDL 2.0 yo'riqnomalari bilan texnik jihatdan almashtirilgan. WSDL 2.0 ko'proq moslashuvchanlik bilan birga WSDL 1.1 ga qaraganda aniqroq tuzilmani taqdim etadi. Ammo WSDL 2.0 tovuq va tuxum muammosidan aziyat chekmoqda: WSDL 2.0 keng qo'llanilmaydi, chunki u keng qo'llab-quvvatlanmaydi va u keng qo'llanilmagani uchun veb-xizmatlar to'plamini ishlab chiquvchilar tomonidan uni qo'llab-quvvatlashga undaydigan narsa kam. Barcha kamchiliklariga qaramay, WSDL 1.1 ko'p maqsadlar uchun etarlicha yaxshi.

Dastlabki WSDL 1.1 spetsifikatsiyasi ishlatilgan funktsiyalar soni bo'yicha noto'g'ri edi. WSDL-ning asosiy yo'nalishi SOAP xizmatining ta'riflariga qaratilganligi sababli, u keyinchalik eskirgan SOAP funktsiyalarini (masalan, rpc kodlash) qo'llab-quvvatlashni o'z ichiga olgan. Web Services Interoperability Organization (WS-I) ushbu muammolarni SOAP va WSDL-dan foydalangan holda veb-xizmatlar uchun eng yaxshi amaliyotlarni taqdim etadigan asosiy profil (BP) da ko'rib chiqdi. BP 1.0 2004 yilda va BP 1.1 2006 yilda chiqarilgan. Ushbu maqola WSDL 1.1-ga WS-I BP ko'rsatmalariga asoslangan va SOAP uchun rpc kodlash kabi amaldagi xususiyatlarga tegmagan.

XML hujjatlarining tuzilishi XML sxemalari ta'riflari bilan belgilanadi. Dastlabki WSDL 1.1 spetsifikatsiyasi sxemaning tavsifini o'z ichiga olgan, ammo sxema bir necha jihatdan matn tavsiflariga mos kelmaydi. Keyinchalik bu sxemaning o'zgartirilgan versiyasida o'rnatildi, ammo WSDL 1.1 hujjati ushbu o'zgarishni aks ettirish uchun tahrir qilinmadi. Keyin BP WS-I jamoasi WSDL sxemasiga yanada ko'proq o'zgartirishlar kiritishga qaror qildi va ushbu siljish sxemasi uchun eng yaxshi amaliyot sifatida baholanayotgan narsani yaratdi. Sxemaning bitta versiyasi uchun yozilgan hujjatlar, odatda, boshqa versiyalarga mos kelmaydi (bir xil nomlar maydonidan foydalanilganiga qaramay), ammo baxtiga ko'ra, veb-xizmatlarning aksariyat vositalari asosan sxemani e'tiborsiz qoldiradilar va shunga o'xshash narsalarni qabul qiladilar. oqilona. (Bo'limda ko'plab WSDL sxemalariga havolalarni ko'ring).

WSDL 1.1 sxemasining WS-I BP versiyasi ham WSDL 1.1 hujjat spetsifikatsiyasiga muvofiqligini ta'minlashda juda foydali emas. Diagramma BP WS-I ning barcha cheklovlarini aks ettirmaydi, ayniqsa komponentlarning tartibiga nisbatan. Bundan tashqari, XML sxemasi hujjatlarda osonlikcha o'rnatilgan cheklovlarning ko'p turlarini (masalan, muqobil atributlar yoki alohida sxemadan qo'shimcha elementlar kabi) boshqarolmaydi. Shunday qilib, WSDL 1.1 hujjatini WSDL 1.1 spetsifikatsiyasiga (BP WS-I tomonidan o'zgartirilgan) qarshi tekshirish shunchaki XML sxemalarini tekshirishni amalga oshirishni o'z ichiga oladi. Ushbu maqolada ushbu mavzuga qaytamiz. Avvalo, WSDL 1.1 xizmat tavsiflari tuzilishini ko'rib chiqamiz.

Ta'rif komponentlari

WSDL 1.1 hujjatlari qulay nomga ega sobit ildiz elementidan foydalanadi ... WSDL 1.1 nom maydonidagi ushbu ildiz elementi ichida bitta "passiv" bolalar elementi (faqat shaxsiy WSDL 1.1 hujjatlari bilan bog'lanish) va beshta "faol" bolalar elementlari (ular aslida xizmat tavsifini tashkil etadi) aniqlanadi:

  • ushbu hujjatga kiritilishi kerak bo'lgan tavsiflari bo'lgan alohida WSDL 1.1 hujjatiga ishora qiladi;
  • xabar almashish uchun ishlatiladigan XML turlarini yoki elementlarini belgilaydi;
  • haqiqiy xabarni turlari yoki XML elementlari bo'yicha belgilaydi;
  • xizmat tomonidan amalga oshiriladigan operatsiyalarning mavhum to'plamini belgilaydi;
  • haqiqiy bajarilishini belgilaydi maxsus protokol va formatlardan foydalangan holda;
  • odatda bir yoki bir nechta elementlarni o'z ichiga olgan xizmatni umuman belgilaydi elementlar uchun kirish ma'lumotlari bilan .

Shuningdek, element ham mavjud bu birinchi bola sifatida hujjatlar uchun ishlatilishi mumkin shuningdek, yuqoridagi har qanday narsaning birinchi farzandi.

Xizmatning to'liq tavsifi, odatda, ushbu turlarning har birining kamida bitta elementini talab qiladi, bundan tashqari , lekin ularning barchasi bitta hujjatda bo'lishi shart emas. Bir nechta hujjatdan to'liq WSDL tavsifini yaratish uchun foydalanishingiz mumkin , bu sizga tashkilotning ehtiyojlari uchun tavsiflarni ajratishga imkon beradi. Masalan, birinchi uchta tavsif elementlari ( , va ) birgalikda xizmat interfeysining to'liq tavsifini tashkil etadi (ehtimol arxitektura guruhi tomonidan belgilanadi), shuning uchun ularni amalga oshirishga yo'naltirilgan elementlardan ajratish mantiqan va ... Barcha asosiy veb-xizmatlar to'plamlari tavsiflarni bir nechta WSDL hujjatlariga bo'lishni qo'llab-quvvatlaydi.

1-ro'yxatda interfeys tavsifining tarkibiy qismlari BookServerInterface.wsdl faylida va dastur komponentlari BookServerImpl.wsdl faylida bo'lishi uchun WSDL xizmatining tavsifining ikkita WSDL hujjatiga bo'linishiga misol keltirilgan. Listing 1-da BookServerInterface.wsdl ko'rsatilgan.

Listing 1. BookServerInterface.wsdl
Kitob xizmati interfeysi ta'rifi. ... ... Kitob xizmatini amalga oshirish. Bu sinf yuklanganda kitoblarning boshlang'ich kutubxonasini yaratadi, so'ngra kutubxona ma'lumotlariga kirish uchun usul qo'ng'iroqlarini qo'llab-quvvatlaydi (shu jumladan yangi kitoblarni qo'shish). Kitobni ma'lum bir ISBN bilan oling. ... Yangi kitob qo'shing.

Listing 2-da BookServerImpl.wsdl ko'rsatiladi. Element birinchi navbatda BookServerInterface.wsdl interfeysining tavsifini import qiladi.

Listing 2. BookServerImpl.wsdl
Haqiqiy kitob xizmatini amalga oshirish ta'rifi. ...

WSDL 1.1 nom maydonidagi elementlarning (va atributlarning) ta'riflaridan tashqari, WSDL 1.1 qo'shimcha elementlarni ham belgilaydi. Ular ma'lum bir xizmat turi uchun zarur bo'lgan qo'shimcha ma'lumotlarni etkazish uchun WSDL 1.1 xizmat tavsifidagi ma'lum katakchalarni to'ldirishga mo'ljallangan. Hali ham keng qo'llaniladigan yagona qo'shimcha WSDL 1.1 elementlari SOAP 1.1 uchun biriktiruvchi elementlardir (ular elementlarda ko'rsatilgan va ), ular asl WSDL 1.1 spetsifikatsiyasida va 2006 yilda alohida spetsifikatsiyada belgilangan SOAP 1.2 uchun.

Komponent tafsilotlari

Element bir yoki bir nechta element sifatida xabarlar uchun ishlatiladigan barcha XML ta'riflarini o'z ichiga oladi ... (WSDL ushbu ta'riflar uchun XML sxemasiga alternativalarga ruxsat beradi, lekin ko'pgina to'plamlar faqat XML sxemalarini qo'llab-quvvatlaydi.) Agar kerak bo'lsa, elementlar foydalanishingiz mumkin yoki WSDL-ga tashqi boshqa sxemalarni kiritish (shuningdek, bir xil WSDL ichidagi alohida sxemalarga murojaat qilish).

Bitta element bo'lgani uchun har qanday miqdordagi sxema ta'riflarini o'z ichiga olishi mumkin, WSDL hujjatida bir nechta elementlardan foydalanish uchun sabab yo'q ... Element ichiga BookServerInterface.wsdl-ning yuqori qismida joylashgan.

Bundan tashqari va , WSDL hujjatining barcha yuqori darajadagi tarkibiy qismlariga kerakli ism atributidan foydalangan holda alohida nomlar berilgan. Root elementida targetNamespace atributidan foydalanilganda hujjat (odatda eng yaxshisi), ushbu komponentlarning nomlari ushbu maqsad nomlari maydonida aniqlanadi. Bu shuni anglatadiki, ismni belgilashda ismning oddiy yoki "mahalliy" qismini belgilash kifoya qiladi, ammo ushbu komponentga havolalar nomni prefiks yoki standart maydon bilan nomga moslashtirishi kerak. 1-rasmda WSDL komponentlari orasidagi eng muhim aloqalar ko'rsatilgan bo'lib, ular to'liq satrlar bilan ishoratlarni aks ettiruvchi va chiziqlar nomlar oralig'iga mos kelmasdan aniqlash uchun foydalanilgan.

Shakl 1. WSDL komponentlari o'rtasidagi munosabatlar

Elementlar bilan ifodalangan xabarlar WSDL xizmatining tavsiflari markazida joylashgan. Elementlar mijoz va xizmat ko'rsatuvchi provayder o'rtasida almashinadigan XML ma'lumotlarining tavsifidir. Har bir element nol yoki undan ortiq (odatda bitta) bolani o'z ichiga oladi ... Har bir qism elementi o'ziga xos atributini talab qiladi (ichida noyob) ) va XML ma'lumotlar sxemasi ta'rifiga murojaat qiladigan element yoki turdagi atributlardan biri. Bir nechta element elementdan keyin ko'rsatilgan BookServerInterface.wsdl-da.

Elementlar xizmatning abstrakt interfeysini xizmatga yuborilgan va undan olingan xabarlar nuqtai nazaridan aniqlang. Elementlar har qanday sonli bolani o'z ichiga oladi ... Har bir bola o'z nomi atributini talab qiladi (BP WS-I uning ichida noyob bo'lishini talab qiladi ) va u operatsiya tomonidan ishlatiladigan xabarlarni tavsiflovchi bir yoki bir nechta asosiy elementlarni o'z ichiga oladi. Bolalar elementlari har xil maqsadlarga mos keladigan uch xil:

  • : mijoz tomonidan xizmat ko'rsatuvchi provayderga operatsiya uchun kirish sifatida yuborilgan ma'lumotlar;
  • : operatsiya natijasida xizmat ko'rsatuvchi provayder tomonidan mijozga qaytarilgan ma'lumotlar;
  • : Qayta ishlash paytida xatolik yuz berganda, xizmat ko'rsatuvchi provayder tomonidan mijozga qaytarilgan ma'lumotlar.

WSDL 1.1 mijozlar va xizmat ko'rsatuvchi provayderlar o'rtasidagi o'zaro munosabatlarning bir nechta shakllarini belgilaydi, bu bolalarning turli xil ketma-ketliklari bilan ifodalanadi va ammo barcha modellar amalga oshirilish uchun etarli darajada aniqlangan emas. BP WS-I faqat ikkita modelga ruxsat beradi: so'rovga javob operatsiyalari, qaerda kerak va faqat o'z ichiga olgan bir tomonlama operatsiyalar ... Elementlarning orqasida so'rov-javob turidagi (hozirgacha eng keng tarqalgan turi) operatsiyalar bo'lsa va har qanday sonli elementlar amal qilishi mumkin .

Har bir element , yoki kerakli xabar atributi orqali xabarning tavsifiga ishora qiladi. Bu nom maydoni uchun mos ma'lumot, shuning uchun odatda prefiks qo'shishni talab qiladi. Bunga misollarni ko'rish mumkin: masalan, element qachon getBook operatsiyasining tavsifida ishlatiladi. (Tns prefiksi ildiz elementining ta'rifi bo'lib xizmat qiladi targetNamespace atributi bilan bir xil URI nom maydoni bilan.)

Ko'p jihatdan elementlarini Java interfeysining mantiqiy ekvivalenti deb hisoblash mumkin usullari, elementlariga tengdir - usul parametrlari, elementlari - usullarning natijalari va elementlari - tekshirilgan istisnolar. Ushbu xaritalashlar WSDL-dan Java kodini ishlab chiqarishda, xuddi mavjud Java kodlaridan WSDL yaratadigan ko'pgina vositalarda bo'lgani kabi ishlatiladi.

SOAP 1.1 va 1.2 ni taqqoslash

SOAP 1.1 spetsifikatsiyasi 2000 yilda nashr etilganidan beri veb-xizmatlar uchun keng qo'llanilgan. SOAP 1.2 W3C orqali keng sanoat ko'magi bilan ishlab chiqilgan va 2007 yilda rasmiy W3C standarti sifatida nashr etilgan. SOAP 1.2 SOAP 1.1 ga qaraganda yaxshiroq hujjatlashtirilgan va toza, bunda 1.1 ning ba'zi xunuk tomonlari jarrohlik yo'li bilan olib tashlanadi. Ushbu takomillashtirilgan tuzilishga qaramay, ko'pchilik veb-xizmatlar uchun ikkalasi o'rtasida amaliy farq juda kam. Ehtimol, SOAP 1.2-ning eng muhim xususiyati shundaki, bu XML ikkilangan optimallashtirilgan qadoqlash (XOP) va SOAP xabarlarini uzatishni optimallashtirish mexanizmi (MTOM) uchun kengaytirilgan SOAP qo'shimchasini qo'llab-quvvatlashdan foydalanishning yagona rasmiy usuli hisoblanadi. Loopda Java veb-xizmatlari Men hozirgacha SOAP 1.1 dan foydalanganman, chunki ba'zi eski stacklar SOAP 1.2 ni qo'llab-quvvatlamaydi, ammo yangi veb-xizmatlarni ishlab chiqish uchun 1.2 bu eng yaxshi tanlov bo'lishi mumkin.

Elementlar aniqlangan mavhum interfeysning nusxasini ifodalaydi bu BookServerImpl.wsdl boshida ko'rinadi. Type atributi majburiy ravishda bajarilgan port turining to'liq nomini o'z ichiga oladi.

Bolalar elementlari port turini qanday amalga oshirish haqida tafsilotlarni o'z ichiga oladi. WSDL nom maydonidagi asosiy elementlar elementlarga mos keladi va bir xil nom qiymatidan foydalanishi kerak - lekin emas holatdagi kabi aniqlangan ma'lumotnomalar ... bu munosabatlar darajadagi chiziqli chiziqlar bilan ko'rsatilgan ... Ism bilan bir xil munosabatlar bolalarga ham tegishli / / elementlar ... Xuddi shu element nomlarining qayta ishlatilishiga qaramay, ushbu elementlarning tarkibi, ular asosiy elementlar bo'lganda sezilarli darajada farq qiladi. , element emas .

WSDL tomonidan belgilangan kengaytmalar ishga tushadi ... Bola elementi SOAP xizmatining ta'rifida ishlatiladi (WSDL 1.1 ham HTTP birikmalariga ruxsat bergan bo'lsa-da, WS-I BP tomonidan ruxsat berilgan yagona xizmat turi). Ushbu element majburiy foydalaniladigan transport rejimini aniqlash uchun kerakli transport atributidan foydalanadi. (HTTP, http://schemas.xmlsoap.org/soap/http in qiymatida ko'rinib turganidek, WS-I VR tomonidan ruxsat berilgan yagona tanlovdir.) Ixtiyoriy uslub atributi XML ma'lumotlarini ko'rsatish uchun rpc va hujjat uslublari o'rtasida tanlov qilishga imkon beradi ( hujjatning eng keng tarqalgan qiymati turga emas, balki sxemani aniqlash elementlaridan foydalangan holda xabarlarga mos keladi).

Har bir bola elementi ichida element element ushbu operatsiyani bajarish uchun so'rovlarni aniqlash uchun SOAPAction qiymatini belgilash uchun ishlatilishi mumkin (va shuningdek, hujjat yoki rpc uslubi tanlovini bekor qilish uchun , garchi BP WS-I bunday foydalanishni taqiqlaydi). Har bir bola / / har doim element bo'lgan boshqa ixtiyoriy elementni o'z ichiga oladi (xabar ma'lumotlari SOAP xabarlari tanasida uzatilishini bildiradi - ma'lumotlar va hatto xatolar SOAP sarlavhalarida ham yuborilishi mumkin, garchi men buni tavsiya qilmasam ham) yoki yoki uning ekvivalenti bilan ishlatilgan .

WSDL xizmati tavsifining yakuniy komponenti bu element elementlar guruhidan iborat ... Har bir element kirish manzilini bilan bog'laydi ... Kirish manzili ichki o'rnatilgan ixtiyoriy elementda joylashgan .

WSDL bilan ishlash

Ajablanarli joyi yo'q, WSDL 1.1 hujjatlari uchun barcha sxemalar va qoidalar o'zgarishi bilan, ko'plab hujjatlar BP WS-I eng yaxshi amaliyotlariga amal qilmaydi. Barcha veb-xizmatlar to'plamlarining ko'plab eng yaxshi og'ishlarni qo'llab-quvvatlashi eskirgan yoki noto'g'ri tuzilgan konstruktsiyalardan foydalanishni davom ettirishga yordam berdi va bu yomon amaliyotning butun sanoat bo'ylab tarqalishiga olib keldi. Va men, albatta, ushbu infektsiyadan xoli emasman - ushbu qator uchun kod misollari sifatida taqdim etgan WSDL hujjatlariga qarab, ularning hech biri to'liq to'g'ri emasligini ko'rib hayron qoldim.

Shunday qilib, ushbu maqolani yozishga qaror qilganimda, WSDL hujjatlarini eng yaxshi amaliyot uchun tasdiqlashingiz mumkin bo'lgan vositani qo'shganim yaxshi deb o'yladim. Bu asl WSDL xatolardan xoli bo'lishi sharti bilan WSDL hujjatlarini to'g'ri shaklga o'tkazishga bir qadam qolgan ko'rinadi. Ammo bu ish men rejalashtirganimdan ancha ko'p bo'lib chiqdi va men ushbu model haqida to'liq ma'lumotlarni ushbu ketma-ketlikning keyingi ikkita maqolasiga kiritaman.

Java-da WSDL hujjatlari bilan ishlash uchun juda ko'p turli xil modellar yaratilgan, shu jumladan Java Toolkit (WSDL4J) uchun keng qo'llaniladigan veb-xizmatlarning tavsiflash tili, bu JSR 110 mos yozuvlar dasturidir (bo'limga qarang). Muammoning ikki tomonlama bayoni tufayli ushbu modellarning hech biri men qilmoqchi bo'lganimga to'g'ri kelmaydi: birinchidan, WSDL hujjatlarini har qanday yarim oqilona shaklda o'qish va xatolar va eng yaxshi amaliyotlardan chetga chiqish haqida xabar berish, ikkinchidan, xatosiz WSDLlarni yozish. amaliy ko'rsatmalarga javob beradigan shaklda qayta formatlangan hujjatlar. Masalan, WSDL4J kirish elementlari tartibini saqlamaydi, shunda buyurtma berish muammolari haqida xabar berish mumkin va sxema ta'riflarini qayta ishlamaydi, shuning uchun uni to'g'ridan-to'g'ri elementlardan havolalarni tekshirish uchun ishlatib bo'lmaydi. ... Shuning uchun muammoni yanada aniqroq belgilash va o'z modelimni yozish o'rtasida tanlov qilishim kerak edi. Tabiiyki, men o'zimning modelimni yozishga qaror qildim.

WSDL modeli

Tasdiqlash va tekshirish

Ushbu maqolada men ushbu atamani ishlataman tekshirish WSDL hujjatining tasdiqlanishini ko'rsatish uchun, chunki muqobil atama tasdiqlash, odatda XML hujjatlari uchun ishlatiladigan, hujjatlarni sxema ta'rifi bilan tasdiqlashni anglatadi.

Men ilgari JiBX / WS loyihasining bir qismi sifatida JiBX ma'lumotlarini bog'lashda foydalanish uchun WSDL modelini qisman amalga oshirdim. Ushbu model faqat namoyish etish uchun mo'ljallangan va ba'zi hollarda ichki joylashtirilgan WSDL XML tuzilmasi elementlaridan ma'lumotlarni birlashtiradigan nisbatan kam sonli sinflarni o'z ichiga oladi ( bitta bola bilan birlashtirilgan , , va ichida element bilan birlashtirilgan yoki va hokazo.). Ushbu ixcham sinf tuzilishi ramka tomonidan qo'llab-quvvatlanadigan WSDL hujjatlarining pastki qismini yaratishni osonlashtirdi, ammo men ushbu model asosida tekshirish va restrukturizatsiya vositasini yaratishni o'ylay boshlaganimda, ehtimol yomon tuzilgan WSDL-ning kiritilishini qo'llab-quvvatlaydigan model XML-ga yaqin bo'lishi kerakligini angladim. vakillik.

Boshqa variant - WSDL 1.1 uchun WS-I BP sxemasidan kod yaratish. Buni ko'rib, men yaratilgan sinflardan foydalanish to'g'ridan-to'g'ri chalkashliklarga olib kelishini tushunib etdim, chunki sxema ortiqcha turlarni va turli xil xabar almashish modellarini namoyish qilish uchun ishlatiladigan ba'zi noqulay tuzilmalarni o'z ichiga oladi (ba'zilari WS-I BP matni tomonidan rad etilgan) ...

Shunday qilib, men darslarni qo'l bilan yozishni tugatdim, garchi natija men sxemadan hosil bo'lgan koddan boshlaganim bilan keraksiz takrorlanish va murakkablikni qisqartirganim bilan deyarli bir xil edi. JiBX ma'lumotlarini bog'lash bir xil sinflarga bir nechta ulanishlarni saqlaydi, shuning uchun men WSDL 1.1 ning har qanday versiyasi tomonidan ruxsat berilgan barcha variantlarni boshqarish uchun kirish majburiyligini yaratishga muvaffaq bo'ldim, garchi WSDL chiqishi uchun chiqishni bog'lashni sozlash faqat eng yaxshi amaliyot shaklida edi.

Listing 3 da Definitions sinfining ildiz elementiga mos keladigan qismi ko'rsatilgan. .

Listing 3. Ta'riflar sinfi (qisman)
umumiy sinf ta'riflari ElementBase-ni kengaytiradi (/ ** bolalar elementlarini kutilgan tartibda ro'yxatlaydi. * / statik enum AddState (yaroqsiz, import, turlar, xabar, portType, majburiy, xizmat); / ** ruxsat berilgan atribut nomlari ro'yxati. * / public static final StringArray s_allowedAttributes \u003d yangi StringArray (yangi String ("name", "targetNamespace")); / ** Amaldagi kontekstni tasdiqlang. * / Private ValidationContext m_validationContext; / ** joriy holat (* / / ** bolalar qo'shilishi tartibini tekshirish uchun ishlatiladi). * / xususiy AddState m_state; / ** Ushbu ta'rifning nomi. * / xususiy String m_name; / ** WSDL maqsad maydonlari. * / private String m_targetNamespace; / ** Barcha import qilingan bolalar ro'yxati. * / shaxsiy ro'yxat m_imports \u003d yangi ArrayList (); / ** Barcha turdagi bolalar ro'yxati. * / shaxsiy ro'yxat m_types \u003d yangi ArrayList (); / ** Bolalar elementlarining barcha xabarlari ro'yxati. * / shaxsiy ro'yxat m_messages \u003d yangi ArrayList (); / ** Barcha portType elementlari ro'yxati. * / shaxsiy ro'yxat M_portTypes \u003d yangi ArrayList (); / ** Barcha bolalar bog'lanishlari ro'yxati. * / shaxsiy ro'yxat m_bindings \u003d yangi ArrayList (); / ** Barcha bolalar xizmatlari ro'yxati. * / shaxsiy ro'yxat m_services \u003d yangi ArrayList m_nameMessageMap \u003d yangi HashMap (); / ** Ushbu ta'rifda malakali nomni port turiga solishtirish. * / xususiy xarita m_namePortTypeMap \u003d yangi HashMap (); / ** Ushbu ta'rifdagi xabarga malakali ismni xaritalash. * / xususiy xarita m_nameBindingMap \u003d yangi HashMap (); / ** Ushbu ta'rifda xizmatga malakali ismni xaritalash. * / xususiy xarita m_nameServiceMap \u003d yangi HashMap (); ... / ** * Turli xil bolalar o'rtasidagi o'tish holatlarini tekshirish. * Agar buyumlar kutilgan tartibda bo'lmasa, * kutilayotgan tartibdan birinchi narsa hisobot uchun belgilanadi. * @param holati yangi qo'shilish holati * @param komp elementi komponentasi * / private void checkAdd (AddState state, ElementBase comp) (if (m_state! \u003d state) (if (m_state \u003d\u003d null || (m_state! \u003d AddState.invalid &&) state.ordinal ()\u003e m_state.ordinal ())) (// boshqa turdagi bolalar elementlariga o'tish m_state \u003d state;) else if (state.ordinal ()< m_state.ordinal()) { // отчет о дочерних элементах вне ожидаемого порядка m_validationContext.addWarning ("Child element of wsdl:definitions out of order", comp); m_state = AddState.invalid; } } } ... /** * Добавление немаршаллизированного дочернего элемента wsdl:message. * Здесь же сообщение индексируется по имени для доступа с целью валидации. * * @param child */ public void addMessage(Message child) { checkAdd(AddState.message, child); m_messages.add(child); addName(child.getName(), child, m_nameMessageMap); } ...

Bolalar ma'lumotlarini tashkil qilish, model qanday qilib umumiy kirish va chiqishni eng yaxshi amaliyot sifatida qo'llab-quvvatlashini ko'rsatadi. Barcha turdagi bolalarning bitta ro'yxati o'rniga har bir tur uchun alohida ro'yxatlar qo'llaniladi. JiBX kirish majburiyligi bolalarni tartibsiz to'plam sifatida ko'rib chiqadi, agar bola o'z joyida bo'lmaganida, har bir narsaga mos keladigan moslamani chaqiradi. Oldingi qadriyatlarning birortasini almashtirish o'rniga, setter, qo'shilgan elementlar uchun ishlatiladigan addMessage () setteridan ko'rinib turganidek, nusxani yozilgan ro'yxatga qo'shadi. ... Shuningdek, har bir sozlovchi buyurtmaga yaroqsiz narsalarni ushlab qolish uchun davlat tekshiruvini o'tkazadi.

Har qanday WSDL elementida qo'shimcha atributlar va elementlarga ruxsat beriladi (odatda, barcha atributlar yoki WSDL 1.1 nom maydonidan foydalanmaydigan elementlar). Bunday qo'shimcha elementlarga misol sifatida ushbu ketma-ket oldingi maqolalardan olingan WSDL hujjatlariga kiritilgan WS-Policy konfiguratsiyalari va haqiqiy qoidalarga havolalar kiradi. Ushbu qo'shimcha elementlarning WSDL 1.1 nom maydonidagi har qanday asosiy elementlardan oldinroq bo'lishi eng yaxshisidir va ular natijalarni bog'lashda shunday ishlaydi. Kiritish majburiyligi qo'shimcha elementlar va atributlarni boshqaradi, bu erda ko'rsatilmagan WSDL elementlari sinflaridan asosiy sinf kodi va elementlarning istalgan tartibda bajarilishiga imkon beradi (agar ular WSDL 1.1 nomlar maydonidagi elementga ergashsa ogohlantirish hosil qiladi).

Model ma'lum elementlarni har bir qo'shimcha nom maydoni uchun alohida birikmalar yordamida ishlaydi, ularning har biri o'ziga xos sinflar to'plamiga ega. Ushbu qo'shimcha elementlarning ishlashini keyingi nashrda batafsilroq aytib o'taman. Java veb-xizmatlari, bu erda manba kodi batafsilroq taqdim etiladi.

Modelni tekshirish

WSDL ma'lumotlarini ba'zi bir asosiy tekshiruvlari, oxiriga addMessage () kodida ko'rsatilgandek, elementlarga mos keladigan marshallashmaydigan ob'ektlar WSDL hujjatining daraxt tuzilishiga qo'shilishi bilan amalga oshiriladi. Ushbu kod bolalar tartibini tekshirish uchun checkAdd () usulidan va haqiqiy ism berilganligini tekshirish uchun addName () usulidan foydalanadi (matn NCName sxemasi turiga mos keladi va qiymat element turi ichida noyob) va nomni ob'ektga moslashtiradi. Ammo bu faqat alohida element uchun eng asosiy ma'lumotlarni tekshirish; har bir elementning boshqa xususiyatlarini va buyumlar o'rtasidagi munosabatlarni tekshirish uchun qo'shimcha tasdiqlash kodi talab qilinadi.

JiBX sizga marshalling va unmarshalling jarayonining bir qismi sifatida maxsus kengaytma ishlovchilarini chaqirishga imkon beradi. WSDL modeli tekshirish mantig'ini bajarish uchun ushbu qo'shimcha ishlov beruvchilardan birini, post-set usulidan foydalanadi. Post-set usuli bog'langan ob'ektni saralash tugagandan so'ng chaqiriladi, shuning uchun bu ko'pincha ob'ektlarda tip tekshiruvlarini amalga oshirishning yaxshi usuli hisoblanadi. WSDL-ni tasdiqlashda, eng sodda yondashuv - barcha element tekshiruvlarini root elementi uchun post-set usulidan bajarish. ... Ushbu yondashuv, komponentlar kutilgan tartibda bo'lmaganida, WSDL hujjatining tarkibiy qismlariga to'g'ridan-to'g'ri murojaat qilish muammosidan qochadi.

Boshqa qo'shimchalar

Ushbu maqolada WSDL tuzilishi va ishlatilish asoslari va WSDL hujjatlarini tekshirishni qo'llab-quvvatlash va ularni eng yaxshi amaliyot shakliga o'tkazish uchun WSDL uchun Java Data Model-ga kirish bayon qilingan.

Keyingi maqola ushbu mavzuni WS-Policy va WS-SecurityPolicy tasdiqlarini yozishda uchraydigan muammolarni ko'rib chiqish bilan davom ettiradi. Shuningdek, WSDL modeli va tekshirish jarayoni, shu jumladan WSDL-ga o'rnatilgan WS-Policy / WS-SecurityPolicy tasdiqlarini o'z ichiga olgan modelni kengaytirish haqida batafsilroq ma'lumot beriladi.

Bir marta ular menga veb-xizmatlarni rivojlantirishni boshlash vazifasini topshirdilar va hech qanday tushuntirishsiz eng sodda loyihaning namunasini berishdi. Loyiha, albatta, boshlanmadi. Bahor nima va u qanday ishlaydi, menda bu haqda umuman tasavvur ham bo'lmagan. Shuningdek, rus tilida yoki ingliz tilida "Spring" dan foydalangan holda veb-xizmatlarni rivojlantirish bo'yicha etarli maqolalarni topa olmadim. Men buni o'zim anglashim kerak edi, unchalik qo'rqinchli emas edi.
Va yaqinda men o'sha paytdan beri bahorga qanday yangi xususiyatlar qo'shilganligini ko'rishga qaror qildim va eski xizmatlarni yangiladim, natijada meni ushbu maqolani yozishga undadi.

Ushbu maqola Spring-WS-dan foydalangan holda SOAP-ga asoslangan asosiy veb-xizmatni ishlab chiqish uchun qo'llanma.

Shunday qilib, biz foydalanuvchi nomini qabul qiladigan va serverda salomlashish va joriy vaqtni yuboradigan oddiy xizmatni yozamiz.

Bizga nima kerak?
  • IDE. Men Eclipse dan foydalanmoqdaman.
Ishga tayyorgarlik
Yangi veb-dastur loyihasini yarating. Eclipse-da bu quyidagicha: "File \u003d\u003e New \u003d\u003e Dynamic Web Project".
Men loyihani shunday nomladim: HelloService.
Keyin, kutubxonalarni Spring, XMLBean, wsdl4j, commons-logging-dan WEB-INF / lib loyiha katalogiga nusxalash.
Agar xohlasangiz, ularni har qanday dastur bilan sudrab ketmaslik uchun ularni server kutubxonalariga qo'shishingiz mumkin.
WSDL sxemasini yaratish
Aslida WSDL sxemasi xizmatni tavsiflash uchun mo'ljallangan.
Albatta, biz uni qo'lda yaratmaymiz. Sxema avtomatik ravishda Spring vositalari tomonidan yaratiladi, ammo keyinroq bu haqda ko'proq ma'lumot.
Kirish va chiqish ma'lumotlarini aniqlash
Kirish ma'lumotlari:
  • String nomi.
Chiqish:
  • Ip bilan tabriklash;
  • Vaqt bu hozirgi vaqt.
Kirish va chiqish ma'lumotlarining tavsifini yarating
WEB-INF katalogida HelloService.xsd faylini yarating. Ushbu fayl WSDL sxemasini yaratish va tegishli Java sinflarini yaratish uchun kerak bo'ladi.
Fayl matni:

Xususiyat targetNamespace - ishlatilgan ism maydoni. O'sha. yaratilgan barcha ob'ektlar org.example.helloService paketida joylashgan bo'ladi.
Elementlar ServiceRequest va ServiceResponse mos ravishda kirish va chiqish ma'lumotlarini tavsiflash (so'rov / javob).
Xususiyatlar min sodir bo'ladi va maxOccurs bitta element ichida berilgan komponentani takrorlanish sonini aniqlang. Agar ushbu parametrlar ko'rsatilmagan bo'lsa, unda sukut bo'yicha ular 1 ga teng hisoblanadi. Ixtiyoriy komponent uchun minOccurs \u003d 0 ni ko'rsatishingiz kerak. Cheklanmagan miqdordagi komponentlar bilan: maxOccurs \u003d cheksiz.
Siz XML sxemalari haqida ko'proq o'qishingiz mumkin.
JavaBeans yarating
Yaratilgan sxema asosida biz Java sinflarini yaratamiz. Buning uchun build.xml faylini yarating:

Parametr WS_HOME XMLBeans joylashgan katalogga ishora qilishi kerak.
HelloService.xsd - yaratilgan sxemaga yo'l.
lib \\ helloservice.jar - yaratilayotgan java kutubxonasi.

Keyin Ant-build-ni ishga tushiring (umid qilamanki, siz allaqachon o'rnatgansiz).
Eclipse-da siz uni quyidagicha ishlatishingiz mumkin: RMB build.xml faylida \u003d\u003e Run As \u003d\u003e Ant Build.
Agar buyruq satri orqali:
ant -buildfile build.xml
Xo'sh, biz qurilish tugashini kutmoqdamiz. Shundan so'ng biz WEB-INF \\ lib loyiha katalogini tegishli kutubxonaning mavjudligini tekshirib ko'rishimiz mumkin (helloservice.jar).

Xizmatni amalga oshirish
Interfeys va xizmat ko'rsatish sinfini yarating
Xizmat interfeysi: HelloService.java:
paketi org.example; import java.util.Calendar; umumiy interfeys HelloService (public String getHello (String nomi) istisnolarni tashlaydi; public Calendar getCurrentTime ();)
Xizmatni amalga oshirish: HelloServiceImpl.java:
paketi org.example; import java.util.Calendar; import org.springframework.stereotype.Service; @Service jamoat klassi HelloServiceImpl HelloService dasturini amalga oshiradi (public String getHello (String nomi) istisno holatini tashlaydi ("Salom", "+ name +" qaytadi! ";) Public Calendar getCurrentTime () (return Calendar.getInstance ();))
Ushbu kod, menimcha, hech qanday izohga muhtoj emas. Ilgari bahorni uchratmagan odamlar savol tug'dirishi mumkin bo'lgan yagona narsa @ Service annotatsiyasi, ammo men bu haqda birozdan keyin gaplashaman.
Oxirgi nuqta
Endpoint - bu kiruvchi so'rovlarni qayta ishlashga mas'ul bo'lgan sinf (kirish nuqtasining bir turi).

HelloServiceEndpoint.java faylini yarating:
paketi org.example; import org.springframework. loans.factory.annotation.Atowired; import org.springframework.ws.server.endpoint.annotation.Endpoint; import org.springframework.ws.server.endpoint.annotation.PayloadRoot; import org.example.helloService.ServiceRequestDocument; import org.example.helloService.ServiceRequestDocument.ServiceRequest; import org.example.helloService.ServiceResponseDocument; import org.example.helloService.ServiceResponseDocument.ServiceResponse; @Endpoint umumiy klassi HelloServiceEndpoint (xususiy statik yakuniy String namespaceUri \u003d "http://www.example.org/HelloService"; xususiy HelloService helloService; @Autowired public void HelloService (HelloService helloService) (this.helloService \u003d helloService;) localPart \u003d "ServiceRequest", namespace \u003d namespaceUri) public ServiceResponseDocument getService (ServiceRequestDocument so'rovi) Exception (ServiceRequestDocument reqDoc \u003d request; ServiceRequest req \u003d reqDoc.getServiceRequest (); ServiceResponseDocument \u003d respaDocument \u003d addNewServiceResponse (); String userName \u003d req.getName (); String helloMessage \u003d testNewService.getHello (userName); Calendar currentTime \u003d testNewService.getCurrentTime (); resp.setHello (helloMessage); resp.setCurrentT); )
Bu erda nima qilingan?
izoh @Endpoint faqat ushbu sinf kiruvchi so'rovlarni ko'rib chiqishini aniqlaydi.
nomlar maydoniUri - xml sxemasini yaratishda ko'rsatilgan bir xil nom maydoni.

Endi biroz orqaga qaytsak va izohni eslaymiz @ Xizmati... Agar siz o'quvchiga keraksiz ma'lumotni haddan tashqari ko'tarmaslik uchun tafsilotlarga kirmasangiz, unda ushbu izoh bahorda "tegishli ob'ektni yaratishi kerakligini aytadi. Va izoh @Avtomobil mos keladigan ob'ektni in'ektsiya qilish (avtomatik almashtirish) uchun xizmat qiladi. Albatta, oddiy dasturlarni yaratishda ushbu izohlardan foydalanishda hech qanday ma'no yo'q, ammo men ushbu misolda hammasini chiqarib tashlamaslikka qaror qildim.

Aks holda, yana hamma narsa aniq bo'lishi kerak. ServiceRequest, ServiceResponse va hk. - bu bizning xml-sxema asosida yaratilgan aynan shu sinflar.

Bahor xizmati konfiguratsiyasi
Shunday qilib, oxiri allaqachon yaqinlashmoqda.
Service-ws-servlet.xml faylini yarating.

sws: izohlarga asoslangan - ushbu loyihada izohlardan foydalanilganligini aniq aytadi.
A kontekst: komponentlarni skanerlash pastki paketlarda ham izlash paytida izohlarni qidirish kerak bo'lgan to'plamni ko'rsatadi.

Keyingi ikkita quti har doim o'zgarmaydi. Ularning mohiyati Xml-dan so'rovni qabul qilish va Java ob'ektiga aylantirish va keyin transformatsiyani teskari yo'naltirishdir.

sws: dinamik-wsdl yaratilgan Xml sxemasi asosida WSDL hujjatini avtomatik yaratish uchun javobgardir.
manzil sxemaga yo'lni ko'rsatadi.
joyUri - WSDL sxemasi mavjud bo'ladigan manzil (konteynerga nisbatan).
Mening holimda WSDL quyidagi manzilda mavjud:
localhost / HelloService / HelloService.wsdl

Joylashtirish tavsifi
Va nihoyat, oxirgi narsa.
WEB-INF katalogida web.xml faylini o'zgartiring yoki yarating.
Salom xizmat Salom xizmat xizmat-ws org.springframework.ws.transport.http.MessageDispatcherServlet transformWsdlLocations to'g'ri xizmat-ws /*
Men endi ushbu faylni ta'riflamayman, ko'pchilik allaqachon bilishi kerak. Murakkab bo'lmagan loyihalar uchun bu aslida o'zgarmasligi kerak. Shuni ta'kidlash kerakki, servlet nomi (servlet-nomi) xizmatning Spring konfiguratsiya fayli nomiga mos kelishi kerak. xizmat-ws-servlet.xml.
Funktsional tekshirish
To'g'ri ishlashning birinchi belgisi - yaratilgan WSDL sxemasi.
Tekshirish uchun ushbu sxemaning manziliga o'ting (http: //localhost/HelloService/HelloService.wsdl) va ko'ring: xml fayli o'sha erda ko'rsatilishi kerak. Agar hech narsa ko'rsatilmagan bo'lsa yoki qanday xato paydo bo'lgan bo'lsa, biz maqolani to'liq o'qib chiqamiz va xatolarimizni qidiramiz.

Keyinchalik tekshirish uchun bizga soapUI kerak (menda 3.0.1 versiyasi bor).
O'rnating va ishga tushiring.
Yangi loyiha yarating: File \u003d\u003e New soapUI Project. Dastlabki WSDL / WADL maydoniga WSDL sxemasiga havola qo'shing (http: //localhost/HelloService/HelloService.wsdl).
Yaratilgan loyihada kerakli so'rovni oching.

Ism maydonida nom bilan haydang va "So'rov yuborish" tugmasini bosing


Natijada, biz serverdan salomlashish va joriy vaqt bilan javob olamiz.


Agar biror narsa noto'g'ri bo'lib ketgan bo'lsa, unda biz ushbu maqolani qayta o'qib chiqdik.

Keyin nima?
Xo'sh, keyingi qadam ushbu veb-xizmat uchun mijoz yozishdir. Ammo bu boshqa maqola uchun materialdir, ehtimol keyinchalik yoziladi, agar bu material kimnidir qiziqtirsa.

Mavzuning sarlavhasi haqiqatan ham savol, chunki Men nima ekanligini bilmayman va birinchi marta ushbu maqola doirasida u bilan ishlashga harakat qilaman. Quyidagi kodning ishlashiga kafolat berishim mumkin bo'lgan yagona narsa, ammo mening iboralarim bularning barchasini o'zim qanday tushunganim haqidagi taxminlar va taxminlar bo'ladi. Xo'sh, boraylik ...

Kirish

Veb-xizmatlar kontseptsiyasi nima uchun yaratilganidan boshlashimiz kerak. Ushbu kontseptsiya paydo bo'lgan vaqtga qadar dunyoda dasturlar masofadan turib o'zaro aloqada bo'lishga imkon beradigan texnologiyalar mavjud edi, bu erda bitta dastur boshqa dasturda qandaydir usulni chaqirishi mumkin edi, uni boshqa shaharda yoki hatto mamlakatda joylashgan kompyuterda ishlatish mumkin edi. Bularning barchasi qisqartirilgan RPC (Masofaviy protsedura chaqiruvi). Masalan, CORBA texnologiyalari va Java uchun RMI (Remote Method Invoking) kiradi. Va ularda hamma narsa yaxshi ko'rinadi, ayniqsa CORBA, tk. u bilan har qanday dasturlash tilida ishlashingiz mumkin, ammo hali ham bir narsa etishmayotgan edi. Menimcha, CORBA-ning kamchiligi shundaki, u har qanday xavfsizlik devori orqali o'tib ketadigan oddiy HTTP o'rniga ba'zi bir tarmoq protokollari orqali ishlaydi. Veb-xizmatning g'oyasi HTTP paketlariga yopishib oladigan RPC yaratish edi. Standartni ishlab chiqish shu tarzda boshlandi. Ushbu standartning asosiy tushunchalari qanday:
  1. SABUN... Masofaviy protsedurani chaqirishdan oldin, ushbu qo'ng'iroqni SOAP XML faylida tasvirlab berishingiz kerak. SOAP shunchaki veb-xizmatlarida ishlatiladigan ko'plab XML formatlashlaridan biridir. Biz biron bir joyga HTTP orqali jo'natmoqchi bo'lgan hamma narsa avval XML SOAP tavsifiga aylantiriladi, keyin u HTTP paketiga joylashtiriladi va tarmoqdagi boshqa kompyuterga TCP / IP orqali yuboriladi.
  2. WSDL... Veb-xizmat mavjud, ya'ni. masofadan turib chaqirilishi mumkin bo'lgan dastur. Ammo standart ushbu dasturga tavsifni ilova qilishni talab qiladi, unda "ha, siz adashmaysiz - bu haqiqatan ham veb-xizmat va undan falon usulni chaqirishingiz mumkin" deb yozilgan. Ushbu tavsif boshqa formatga ega bo'lgan boshqa XML fayli bilan, ya'ni WSDL bilan ifodalanadi. O'sha. WSDL bu shunchaki veb-xizmatni tavsiflovchi XML fayli va boshqa hech narsa emas.
Nima uchun bu qadar qisqacha so'raysiz? Batafsil ma'lumot ololmaysizmi? Ehtimol siz qila olasiz, ammo buning uchun siz Mashnin T. "Java Web Services" kabi kitoblarga murojaat qilishingiz kerak. U erda dastlabki 200 sahifada SOAP va WSDL standartlarining har bir tegining batafsil tavsifi mavjud. Men buni qilishim kerakmi? Menimcha, yo'q, chunki Java-da bularning barchasi avtomatik ravishda yaratiladi va siz faqat masofadan chaqirilishi kerak bo'lgan usullarning tarkibini yozishingiz kerak. Shunday qilib, Java-da JAX-RPC kabi API paydo bo'ldi. Agar kimdir bilmasa, Java-da bunday va bunday API mavjudligini aytganda, demak, ushbu texnologiyani o'z ichiga olgan sinflar to'plamiga ega paket mavjud. JAX-RPC uzoq vaqt davomida versiyadan versiyaga rivojlanib, oxir-oqibat JAX-WS ga aylandi. WS, shubhasiz, WebService degan ma'noni anglatadi va bu hozirgi kunda RPC nomini mashhur so'zga aylantirishning oddiy usuli deb o'ylashingiz mumkin. Bu shunday emas, chunki Endi veb-xizmatlar asl g'oyadan uzoqlashdi va nafaqat masofaviy usullarga qo'ng'iroq qilish, balki oddiygina SOAP formatida hujjat xabarlarini yuborish imkoniyatini yaratdi. Bu nima uchun kerak, men hali bilmayman, javob "ehtimol, kutilmaganda kerak bo'ladi" bo'lishi mumkin emas. Men o'zim tajribali o'rtoqlardan o'rganishni istardim. Va oxirgi narsa, keyin RESTful veb-xizmatlari uchun JAX-RS ham bor edi, ammo bu alohida maqola uchun mavzu. Bu erda kirish tugashi mumkin, chunki keyin biz JAX-WS bilan ishlashni o'rganamiz.

Umumiy yondashuv

Veb-xizmatlar doimo mijoz va serverga ega. Server bizning veb-xizmatimiz va ba'zan uni so'nggi nuqta deb atashadi (masalan, mijozning SOAP xabarlari ketadigan so'nggi nuqta). Biz quyidagilarni bajarishimiz kerak:
  1. Veb-xizmatimiz interfeysini tavsiflab bering
  2. Ushbu interfeysni amalga oshiring
  3. Veb-xizmatimizni boshlang
  4. Mijozni yozing va kerakli veb-xizmat usulini masofadan chaqiring
Siz veb-xizmatni har xil usulda boshlashingiz mumkin: yoki siz sinfni asosiy usul bilan tavsiflaysiz va to'g'ridan-to'g'ri server sifatida veb-xizmatni ishga tushirasiz yoki uni Tomcat yoki boshqa serverga joylashtirasiz. Ikkinchi holda, biz o'zimiz yangi serverni ishga tushirmayapmiz va kompyuterda boshqa portni ochmaymiz, faqat Tomcat servlet konteyneriga "biz bu erda veb-xizmat darslarini yozganmiz, ularni nashr eting, iltimos, siz bilan bog'lanadigan har bir kishi bizning veb-xizmatidan foydalaning ". Veb-xizmatni ishga tushirish usulidan qat'i nazar, biz bir xil mijozga ega bo'lamiz.

Server

IDEA-ni boshlaymiz va yangi loyiha yaratamiz Yangi loyiha yarating... Ism kiritamiz SalomWebService tugmachasini bosing Keyingi, keyin tugma Tugatish... Jildda src paket yaratish ru.javarush.ws... Ushbu paketda biz HelloWebService interfeysini yaratamiz: ru ru. javarush. ws; // bu izohlar, ya'ni. darslarimizni va usullarimizni belgilash usuli, // veb-xizmat ko'rsatish texnologiyasiga tegishli import javax. jws. WebMethod; import javax. jws. WebService; import javax. jws. sovun. SOAPBinding; // bizning interfeysimiz veb-xizmat sifatida ishlashini ayting @WebService // veb-xizmat qo'ng'iroq qilish usullari uchun ishlatilishini ayting @SOAPBinding (style \u003d SOAPBinding. Style. RPC) umumiy interfeysi HelloWebService ( // bu usulni masofadan chaqirish mumkin deymiz @WebMethod public String getHelloString (String nomi); ) Ushbu kodda WebService va WebMethod sinflari izohlar deb ataladi va bizning interfeysimiz va uning usulini veb-xizmat sifatida belgilashdan boshqa hech narsa qilmaydi. Xuddi shu narsa SOAPBinding sinfi uchun ham amal qiladi. Faqatgina farq shundaki, SOAPBinding parametr izohidir. Bunday holda, uslub parametri veb-xizmat hujjat xabarlari orqali emas, balki klassik RPC sifatida ishlashini aytadigan qiymat bilan ishlatiladi, ya'ni. usulni chaqirish. Keling, interfeysimiz mantig'ini amalga oshiramiz va paketimizda HelloWebServiceImpl sinfini yaratamiz. Aytgancha, men Impl-dagi sinfning oxiri Java-da konventsiya ekanligini ta'kidlayman, unga ko'ra interfeyslarni amalga oshirish shu tarzda belgilanadi (Impl - amalga oshirish so'zidan, ya'ni amalga oshirish). Bu shart emas va siz sinfga xohlagancha nom berishingiz mumkin, ammo yaxshi shakl qoidalari shuni talab qiladi: pack ru. javarush. ws; // interfeysni tavsiflash bilan bir xil izoh, import javax. jws. WebService; // lekin bu erda endpointInterface parametri bilan ishlatiladi, // veb-xizmatimiz interfeysining to'liq malakali sinf nomini ko'rsatish @WebService (endpointInterface \u003d "ru.javarush.ws.HelloWebService") HelloWebServiceImpl jamoat klassi HelloWebService dasturini (@Override public String getHelloString (String name)) amalga oshiradi. // faqat salomlashing qaytish "Salom", + ism + "!" ; )) Keling, veb-xizmatimizni mustaqil server sifatida boshlaymiz, ya'ni. hech qanday Tomcat va dastur serverlarini jalb qilmasdan (bu alohida muhokama uchun mavzu). Buning uchun papkada loyiha tarkibida src ru.javarush.endpoint to'plamini yarating va unda HelloWebServicePublisher sinfini asosiy usuli bilan yarating: ru ru. javarush. so'nggi nuqta; // veb-xizmatlar bilan veb-serverni ishga tushirish uchun sinf import javax. xml. ws. So'nggi nuqta; // veb-xizmatimizning klassi import ru. javarush. ws. HelloWebServiceImpl; umumiy sinf HelloWebServicePublisher (public static void main (String ... args)) // veb-serverni 1986 yil portida ishga tushiring // va birinchi argumentda ko'rsatilgan manzilda, // ikkinchi argumentda berilgan veb-xizmatni ishga tushiring Oxirgi nuqta. nashr etish ( "http: // localhost: 1986 / wss / salom", yangi HelloWebServiceImpl ()); )) Endi ushbu sinfni bosish orqali ishga tushiramiz Shift + F10... Konsolda hech narsa ko'rinmaydi, lekin server ishlaydi. Buni brauzerda http: // localhost: 1986 / wss / hello? Wsdl qatorini yozib tasdiqlashingiz mumkin. Ochilgan sahifa, bir tomondan, veb-server (http: //) bizning kompyuterimizda (localhost) 1986 yil portida boshlanganligini tasdiqlaydi va boshqa tomondan, bizning veb-xizmatimizning WSDL tavsifini ko'rsatadi. Agar dasturni to'xtatib qo'ysangiz, tavsif veb-xizmatning o'zi kabi mavjud bo'lmaydi, shuning uchun biz buni qilmaymiz, balki mijozni yozishni boshlaymiz.

Mijoz

Loyiha papkasida src ru.javarush.client to'plamini yarating va unda HelloWebServiceClient sinfini asosiy usuli bilan: ru ru. javarush. mijoz; // wsdl tavsifini olish uchun kerak va u orqali // veb-xizmatning o'ziga murojaat qiling import java. to'r. URL; // URL ob'ekti bilan ishlashda bunday harakat sodir bo'ladi import java. to'r. Noto'g'ri shakllanganURLExavfsizlik; // xmlni wsdl tavsifi bilan tahlil qilish uchun sinflar // va undagi xizmat yorlig'iga etib boring import javax. xml. ism maydoni. QName; import javax. xml. ws. Xizmat; // veb-xizmatimiz interfeysi (bizga ko'proq kerak) import ru. javarush. ws. HelloWebService; umumiy sinf HelloWebServiceClient (public static void main (String args) MalformedURLException ( // wsdl tavsifiga havola yarating Url url \u003d yangi url ( "http: // localhost: 1986 / wss / salom? wsdl") ; // Biz keyingi konstruktorning parametrlarini WSDL tavsifining birinchi yorlig'ida ko'rib chiqamiz - ta'riflar // targetNamespace atributidagi 1-argumentga qarang // name atributidagi 2-argumentga qarang QName qname \u003d yangi QName ("http://ws.javarush.ru/", "HelloWebServiceImplService"); // Endi biz xizmat yorlig'iga wsdl tavsifida erishishimiz mumkin, Xizmat xizmati \u003d Xizmat. yaratish (url, qname); // va keyin ichki o'rnatilgan yorliq yorlig'iga qadar, shunday qilib // bizdan uzoqdagi veb-xizmat ob'ektiga havolani oling HelloWebService salom \u003d xizmat. getPort (HelloWebService. sinf); // Ura! Endi siz masofadan turib qo'ng'iroq qilishingiz mumkin Tizim. chiqib. println (salom. getHelloString ("CodeGym")); )) Men ro'yxatdagi kod bo'yicha maksimal sharhlar berdim. Menda qo'shadigan narsa yo'q, shuning uchun biz (Shift + F10) ishlaymiz. Biz konsolda matnni ko'rishimiz kerak: Salom, CodeGym! Agar ko'rmagan bo'lsangiz, ehtimol veb-xizmatni boshlashni unutgansiz.

Xulosa

Ushbu mavzuda veb-xizmatlarga qisqacha ekskursiya namoyish etildi. Shunga qaramay, men yozgan narsalarning ko'pi bu qanday ishlashiga oid taxminim, shuning uchun juda ko'p ishonmaslik kerak. Agar bilimdon odamlar meni to'g'rilasa, men minnatdor bo'lar edim, chunki o'shanda men bir narsani o'rganaman. UPD.

Sahifa 2 ning 3

WSDL bilan tasvirlash

Agar veb-xizmat haqida hamma narsani bilsangiz, SOAP juda yaxshi ishlaydi. Biroq, bu har doim ham shunday emas. Veb-xizmatlarni ta'riflash tili (WSDL) veb-xizmatga kirish interfeysini tavsiflash uchun ishlatiladi. Ushbu standart IBM, Microsoft va webMethods tomonidan birgalikda ishlab chiqilgan. Uch kompaniyaning har biri veb-xizmatlarni tavsiflash standartini ishlab chiqishda o'zlarining yondashuvlariga ega edilar: IBM NASSL-ni yaratdi, Microsoft SCL-ni ishlab chiqdi va webMethods WIDL-ni ishlab chiqdi.

Ularning hamkorlik natijalari WSDL tilining 1.1-versiyasi edi.W3C haqida ham shuni ta'kidlash kerakki, SOAP-da bo'lgani kabi, W3C-ning 1.1-versiyasi asosida WSDL 1.2 versiyasi ishlab chiqilgan bo'lib, u hozirda W3C-ning tavsiyasi. Veb-xizmat uchun WSDL xizmatdan foydalanish uchun zarur bo'lgan barcha ma'lumotlarni, shu jumladan mavjud usullar va ularning parametrlarini o'z ichiga oladi. Ushbu ma'lumotlar quyidagi beshta elementda joylashgan:

  • - Qo'llab-quvvatlanadigan protokollar.
  • - veb-xizmat xabarlari (so'rov, javob).
  • Barcha mavjud usullar.
  • - URI xizmati.
  • - ishlatilgan ma'lumotlar turlari.

Ushbu ma'lumotlarning barchasi WSDL tavsifining ildiz elementida saqlanadi. Quyidagi ro'yxatda veb-xizmat uchun WSDL tavsifining namunasi ko'rsatilgan.

WSDL veb-xizmatining tavsifi

Ha ... buni stakansiz aniqlay olmaysiz, ammo bu eng oddiy (!) WSDL fayllaridan biridir. Afsuski, PHP 5 uchun SOAP kengaytmasining kamchiliklaridan biri shundaki, boshqa SOAP dasturlaridan farqli o'laroq, u avtomatik ravishda WSDL tavsiflarini yaratmaydi (hech bo'lmaganda hali). Albatta, bu kamchilik PHP-ning kelgusi versiyalarida tuzatiladi.

Aytmoqchi!

Avtomatik ravishda WSDL tavsifini yaratish uchun PHP-da muqobil SOAP dasturlaridan foydalanishingiz mumkin:

UDDI bilan katalogni qidirish

Endi veb-xizmat haqida qanday ma'lumot olish va undan qanday qilib so'rov olish kerakligini bilganimiz uchun, bunday xizmatni qanday topishni o'rganishimiz kerak. Shu maqsadda, Yellow Pages-ga o'xshash narsa bor, ya'ni Universal Business Registrlar (UBR) - veb-xizmatlar kataloglari.

Bunday registrlar bir nechta, shu jumladan IBM, Microsoft, NTT-Com va SAP. Ushbu registrlar o'zlarining ma'lumotlarini sinxronizatsiya qiladi, shuning uchun ulardan har qandayidan foydalanishingiz mumkin. UDDI standartining amaldagi versiyasi UDDI 3.0 hisoblanadi, lekin aksariyat dasturlarda 2-versiyadan foydalaniladi. Ushbu standartni ishlab chiquvchilar orasida HP, Intel, Microsoft va Sun kabi gigantlar mavjud.

UBR bilan o'zaro aloqada bo'lish uchun mavjud ikki turdagi API: So'rov API va Publish API... Interfeys So'rov uchun API so'rov uchun mo'ljallangan UBR registrlaridagi xizmatlar va interfeys Publish API ishlab chiquvchilarga o'z xizmatlarini ro'yxatdan o'tkazishga imkon beradi... Ro'yxatdan o'tishlar tarkibini spam bilan to'ldirish faqat vaqt masalasidir :)

Aytmoqchi!

Xizmatni ro'yxatdan o'tkazishni "haqiqiy" ro'yxatga olishdan oldin sinovdan o'tkazish uchun test registrlari mavjud.

Veb-xizmat so'rovi quyidagicha ko'rinadi:

sortByNameAsc sortByDateDesc % qo'llanma%

Yuqoridagi misolda siz UDDI so'rovining SOAP xabarida joylashganligini ko'rishingiz mumkin, shuning uchun u juda tanish ko'rinadi. So'rovga javob, shuningdek quyida ko'rsatilgan SOAP hujjati:

Veb-xizmatlar bo'yicha ekskursiya Guided Tourbook uchun namunali veb-xizmatlar Ekskursiyalar bo'yicha qo'llanma

O'rnatish

PHP5 uchun SOAP kengaytmasini o'rnatish juda oson. Windows-da ushbu modul PHP-ni o'rnatish katalogining pastki katalogida joylashgan. Uni ishlatish uchun php.ini fayliga quyidagi qatorni qo'shing: kengaytma \u003d php_soap.dll Ushbu modulning ishlashi uchun sukut bo'yicha PHP 5-ga, hech bo'lmaganda Windows-ning versiyasiga kiritilgan talab qilinadi.

XSD: XML sxemasining ta'rifi.

XML: kengaytiriladigan belgilash tili.

WSDL: Veb-xizmatlarning ta'rifi tili.

Men texnik javob bermayman. Men ushbu tushuntirishni yangi boshlanuvchilarga yo'naltiraman.

Ikki xil texnologiyalar yordamida ishlab chiqilayotgan ikki xil dastur o'rtasida aloqa o'rnatish oson emas. Masalan, Chikagodagi kompaniya Java-dan foydalangan holda veb-dastur ishlab chiqishi mumkin, va Nyu-Yorkdagi boshqa kompaniya C # dasturini ishlab chiqishi mumkin va agar ikkala kompaniya ma'lumot almashishga qaror qilsalar, rasmda XML paydo bo'ladi. Bu turli xil texnologiyalar yordamida ishlab chiqilgan ikki xil dasturlar o'rtasida ma'lumotlarni saqlash va tashishda yordam beradi. Eslatma. Bu faqat dasturlash tili bilan cheklanib qolmaydi, iltimos, ma'lumotni ikki xil dastur o'rtasida tashilishini tekshiring.

XSD - bu sxema ta'rifi. Demak, demak, bu foydalanuvchilarga o'zlarining xmllarini shunday sxemada ishlab chiqishni buyuradi. Iltimos, quyidagi rasmga qarang va "ishga tushirish paytida yuklash" elementi va uning turi, ya'ni butun son bilan diqqat bilan kuzatib boring. XSD-rasmda uning "ishga tushirish paytida yuklash" uchun butun son uchun ekanligini ko'rishingiz mumkin va shuning uchun foydalanuvchi o'z XML-ni yaratganda, u int qiymatini ushbu elementga o'tkazgan. Eslatib o'tamiz, XSD - bu sxema va uslub, XML esa boshqa dastur yoki tizim bilan aloqa qilish uchun shakl. Siz XSD-ni ko'rishingiz va shu tarzda XML yaratishingiz kerak, aks holda u boshqa texnologiya yordamida ishlab chiqilgan boshqa dastur yoki tizim bilan aloqa o'rnatmaydi. Chikago kompaniyasi Texas kompaniyasiga ushbu XSD formatida o'z xmllarini yozishi yoki yaratishi uchun XSD shablonini taqdim etadi. Agar Texas kompaniyasi XSD-da ko'rsatilgan qoidalar yoki sxemalarga rioya qilmasa, Chikago kompaniyasidan to'g'ri ma'lumotni kutish mumkin emas. Yuqoridagi voqeadan so'ng, havaskor yoki yangi boshlovchi yuqorida aytib o'tganimdek ba'zi narsalarni kodlash paytida bilishi kerak bo'lgan juda ko'p narsalar mavjud. Agar siz haqiqatan ham nima bo'lishini bilmoqchi bo'lsangiz, u holda veb-xizmatlarni ishlab chiqqan dasturiy ta'minot bo'yicha katta muhandislar bilan o'tirish yaxshidir. Keyin WSDL keladi, iltimos, rasmlarni kuzatib boring va WSDL mos keladigan joyni aniqlang.

*************** \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d Quyida qisman XML tasvir mavjud \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d ********* *** ***

*************** \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d Quyida qisman XSD tasvir mavjud \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d ********* *** ***

*************** \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d Quyida WSDL-ning qisman tasviri \u003d\u003d\u003d\u003d\u003d\u003d\u003d *********** **

Kitob deb nomlangan veb-xizmat uchun WSDL namunasini yaratishim kerak edi. Shuni esda tutingki, bu XSD, lekin uni WSDL (veb-xizmatlarning ta'rifi tili) deb nomlashingiz kerak, chunki u veb-xizmatlarga juda xosdir. WSDL ostida (yoki boshqacha qilib aytganda XSD) Book.java klassi uchun yaratilgan va u SOAP xizmatini yaratgan. SOAP veb-xizmati qanday yaratilganligi boshqa mavzu. Java sinfini yozish kerak va uni veb-xizmat sifatida yaratishga kirishishdan oldin foydalanuvchi Axis2 API o'rnatilganligiga va veb-xizmatni joylashtirishi uchun Tomcat-ga ishonch hosil qilishi kerak.

Xizmat ko'rsatuvchi provayder sifatida (boshqalarga (mijozlarga) o'z tizimidagi ma'lumotlarga yoki ma'lumotlarga kirishga ruxsat beruvchi) mijozga (xizmat ko'rsatuvchi provayder ma'lumotlari yoki ma'lumotlaridan foydalanishi kerak bo'lganlar) veb-xizmat orqali ma'lumotlarga to'liq kirish huquqini beradi. er yuzidagi bitta kompaniya o'z ma'lumotlar bazasini begonalar bilan baham ko'rishga tayyor emas. Mening kompaniyam singari, men ham veb-xizmatlar orqali mahsulot haqida ba'zi ma'lumotlarni taqdim etishga qaror qildim, shuning uchun biz XSD shablonini yaratib, biz bilan ishlashni istagan ba'zi mijozlarimizni topshirishimiz kerak edi. Ular berilgan XSD-dan to'liq foydalanish uchun kod yozishlari va xizmat ko'rsatuvchidan ma'lumotlarni olish uchun veb-xizmatiga qo'ng'iroqlarni amalga oshirishi va kerakli so'rovga qaytarilgan ma'lumotlarni o'zgartirishi kerak, so'ngra ma'lumotlarni yoki mahsulot haqidagi ma'lumotlarni veb-saytida namoyish qilishi yoki nashr etishi kerak. Oddiy misol - parvozlarni bron qilish - Flylight. Aviakompaniya chiptalarni sotish uchun uchinchi tomonga o'z veb-saytidagi parvoz ma'lumotlaridan foydalanishga ruxsat beradi. Ammo keyin yana bir narsa bor, shunchaki uchinchi tomon aviakompaniyasiga chiptalarni sotishiga yo'l qo'ymaslik bilan hamohanglik va xavfsizlik o'rnatiladi. Agar sinxronizatsiya bo'lmasa, ehtimol bitta mijoz turli xil manbalardan bir xil aviachipta sotib olish imkoniyatidan 100% ko'proqdir.

Mutaxassislar mening javobimga o'z hissalarini qo'shadilar deb umid qilaman. Yangi boshlagan yoki yangi boshlagan kishi uchun XML, XSD-ni tushunish, so'ngra veb-xizmatlar bilan ishlash juda qiyin.

Maqola sizga yoqdimi? Do'stlar bilan bo'lishish uchun:
Siz ham qiziqishingiz mumkin