სისტემა და განახლება 

ვებ სერვისები wsdl. ვებ სერვისების აღწერა WSDL ენაზე. შექმენით ინტერფეისი და სერვისის კლასი

Წინასიტყვაობა

მომხმარებელთა მომხმარებლებმა კლიენტებს სთხოვეს xsd ფაილები განხორციელებული ვებ სერვისებით გადაცემული სტრუქტურებისთვის. მომხმარებლებმა უპასუხეს და მოიწვიეს კლიენტები WSDL-ების შესაქმნელად. რომ. უეცრად, „ბუნებრივიდან“, გაჩნდა საჭიროება მონაცემთა დამოწმებისთვის არა მხოლოდ xsd სქემების, არამედ „მთელი WSDL-ების“ შექმნა. როგორც წესი, WSDL გამოიყენება SOAP-ისთვის, მაგრამ ჩვენ ვიყენებთ REST...

ადრე დავწერე ამის შესახებ

შესავალი

ტერმინი ვებ სერვისები ჩვეულებრივ ასოცირდება ოპერაციებზე ან მოქმედებაზე დაფუძნებულ სერვისებთან, რომლებიც დაფუძნებულია SOAP ან WS* სტანდარტებზე, როგორიცაა WS-Addressing ან WS-Security. ტერმინი REST ვებ სერვისები ჩვეულებრივ ეხება ვებ სერვისების რესურსზე დაფუძნებულ არქიტექტურას, რომელიც აკავშირებს XML-ს HTTP-ზე. თითოეულ ამ არქიტექტურულ სტილს თავისი ადგილი აქვს, მაგრამ ბოლო დრომდე WSDL სტანდარტი ორივე ამ სტილს არ უჭერდა მხარს. WSDL 1.1 HTTP დაკავშირება არაადეკვატური იყო XML-ის გამოყენებით ურთიერთქმედების აღსაწერად HTTP-ზე, ე.ი. არ არსებობდა ფორმალური გზა WSDL-ის გამოყენებით REST ვებ სერვისების აღწერისთვის. WSDL 2.0 სტანდარტის გამოქვეყნებამ (რომელიც შემუშავდა REST ვებ სერვისების აღწერის აუცილებლობის გათვალისწინებით) მსოფლიო ქსელის კონსორციუმის (W3C) რეკომენდაციის სახით, უზრუნველყო REST ვებ სერვისების აღწერის ენა.

REST არის არქიტექტურული სტილი, რომელიც განიხილავს ვებს, როგორც რესურსზე ორიენტირებულ აპლიკაციას. პრაქტიკულად, ეს ნიშნავს, რომ RESTful აპლიკაციაში ყველა URL წარმოადგენს რესურსს. URL-ები ადვილად გასაგები და დასამახსოვრებელია. მაგალითად, წიგნის მაღაზიამ შეიძლება განსაზღვროს URL http://www.bookstore.com/books/ იმ წიგნების სიისთვის, რომლებსაც ისინი ყიდიან და http://www.bookstore.com/books/0321396855/ კონკრეტული წიგნის შესახებ დეტალებისთვის. ISBN 0321396855. ეს ეწინააღმდეგება მოქმედებაზე ორიენტირებულ აპლიკაციებს, რომლებსაც ჩვეულებრივ აქვთ გრძელი, რთული URL-ები, რომლებიც აღწერს შესასრულებელ მოქმედებებს, მაგალითად http://www.bookstore.com/action/query?t=b&id=11117645532&qp=0321396855. შეკითხვის პარამეტრები გამოიყენება საჭირო მონაცემების შესარჩევად. წიგნის მაღაზიის მაგალითის გამოყენებით, საგნის პარამეტრის მითითება ზღუდავს წიგნის თემას. მაგალითად, ფიზიკა ან დეტექტიური ისტორიები, ან მაგალითად, URL http://www.bookstore.com/books/?subject=computers/eclipse - მოთხოვნა, რომელიც აბრუნებს წიგნების სიას Eclipse პლატფორმის შესახებ.

ტერმინი REST გამოიგონა როი ფილდინგმა თავის სადოქტორო დისერტაციაში. იგი განიხილავდა ჰიპერბმულებს, როგორც აპლიკაციის მდგომარეობის შეცვლის (შენახვის) საშუალებას. ჰიპერბმულები ინახება აპლიკაციის რესურსებში და არის აპლიკაციის მდგომარეობის შეცვლის მეთოდი, გადამისამართება ერთი მდგომარეობიდან მეორეში. როგორც წესი, ჰიპერბმულები (X)HTML განკუთვნილია ადამიანების გამოსაყენებლად, ისინი არ გამოიყენებოდა XML-ში, რომელიც განკუთვნილი იყო მანქანური დამუშავებისთვის. ისევე, როგორც (X)HTML, REST ვებ სერვისები იყენებენ ჰიპერბმულებს XML-ში.

ტრადიციული ვებ აპლიკაციები წვდებიან რესურსებს HTTP GET ან POST ოპერაციების მეშვეობით. RESTfull აპლიკაციები რესურსებთან მუშაობს „შექმნა, წაკითხვა, განახლება და წაშლა (CRUD)“ სტილში HTTP პროტოკოლის სრული შესაძლებლობების გამოყენებით (POST, GET, PUT და DELETE).

კიდევ ერთი მნიშვნელოვანი შენიშვნა RESTful აპლიკაციების შესახებ: RESTful აპლიკაციები უნდა იყოს მოქალაქეობის არმქონე. ეს ნიშნავს, რომ REST აპლიკაცია არ ინარჩუნებს სესიის მდგომარეობას სერვერის მხარეს. მოთხოვნის დასასრულებლად საჭირო ყველა ინფორმაცია გადაიცემა თავად მოთხოვნაში. (აქედან გამომდინარე, სერვერმა უნდა უპასუხოს განმეორებით მოთხოვნებს იმავე გზით. მთარგმნელის შენიშვნა). შესაბამისად, კლიენტს შეუძლია მიღებული რესურსების ქეშირება, რამაც შეიძლება მნიშვნელოვნად დააჩქაროს აპლიკაციის სიჩქარე, სადაც სერვისი ცალსახად იძლევა ამის საშუალებას. REST-ის შესახებ მეტი ინფორმაციისთვის იხილეთ სტატიის ბმულები.

WSDL და REST

WSDL შეიცავს ყველა დეტალს ვებ სერვისის შესახებ, მათ შორის:

    ვებ სერვისის URL
    კომუნიკაციის მექანიზმები, რომლებსაც ვებ სერვისი ესმის
    ოპერაციები, რომელთა შესრულებაც ვებ სერვისს შეუძლია
    ვებ სერვისის შეტყობინებების სტრუქტურა

კლიენტებს შეუძლიათ გამოიყენონ ჩამოთვლილი დეტალები სერვისთან ურთიერთობისთვის.

WSDL 2.0 გამოცხადდა W3C რეკომენდაციად 2007 წლის ივნისში. WSDL სტანდარტის ეს ვერსია გამოვიდა WSDL 1.1 სტანდარტის პრობლემების გადასაჭრელად, რომელთაგან ბევრი აღმოაჩინა ვებ სერვისების ურთიერთთანამშრომლობის (WS-I) ორგანიზაციამ. გარდა ამისა, WSDL 2.0-ს აქვს გაუმჯობესებული მხარდაჭერა HTTP კავშირებისთვის.

WSDL თავისთავად არის XML, ქვეჯგუფი, რომელიც ოფიციალურად აღწერს ვებ სერვისს. იფიქრეთ ვებ სერვისის WSDL აღწერაზე, როგორც მის API კონტრაქტზე კლიენტთან. WSDL განსაზღვრავს მისამართს, ინფორმაციის გადაცემის მისაღებ მეთოდებს, ინტერფეისებს და ვებ სერვისის შეტყობინებების ტიპებს. მოკლედ, WSDL აღწერა შეიცავს ყველა ინფორმაციას, რომელიც კლიენტს სჭირდება ვებ სერვისის გამოსაყენებლად.

WSDL-ის გამოყენებადობა სცილდება მის, როგორც API კონტრაქტის გამოყენებას. როგორც ფორმალური განმარტება, WSDL შეიძლება გამოყენებულ იქნას პროგრამული უზრუნველყოფის მიერ ვებ სერვისების განხორციელების გასამარტივებლად ისეთი ოპერაციებისთვის, როგორიცაა:

  • კლიენტის აპლიკაციისა და სერვერის წყაროს კოდის გენერირება ვებ სერვისისთვის სხვადასხვა პროგრამირების ენაზე
  • ვებ სერვისის გამოქვეყნება
  • დინამიური ვებ სერვისის ტესტირება

ვებ სერვისების პროგრამული უზრუნველყოფის უმეტესობა მოიცავს WSDL 1.1-ის მხარდაჭერას. ბოლო დროს, იზრდება ვებ სერვისების განვითარების ინსტრუმენტების რაოდენობა, რომლებიც მხარს უჭერენ WSDL 2.0-ს. Apache Web Services პროექტი შედგება ორი ქვეპროექტისგან, რომლებიც ამჟამად მხარს უჭერენ WSDL 2.0. Woden არის Java-ზე დაფუძნებული WSDL 2.0 პარსერ-ვალიდიატორი. Apache Web Services პროექტი ასევე უზრუნველყოფს XSL (XSLT) WSDL 2.0 ტრანსფორმაციას ე.წ WSDL 2.0 ლამაზი პრინტერი, რომელიც უზრუნველყოფს WSDL დოკუმენტის უკეთ წაკითხვას ადამიანისათვის. Axis2 არის პოპულარული ვებ სერვისების ძრავა (ასევე Apache-სგან), რომელიც ქმნის კლიენტისა და სერვერის Java კოდს WSDL 2.0 დოკუმენტიდან.

REST ვებ სერვისის აღწერა WSDL 2.0-ის გამოყენებით

თქვენ ქმნით წიგნის მაღაზიას, რომელსაც აქვს გაფართოებული URL: http://www.bookstore.com. თქვენ უკვე შექმენით ორი REST ვებ სერვისი:

  • წიგნის სია - სერვისი იღებს თქვენს მიერ გაყიდული წიგნების სიას.
  • წიგნის დეტალები - სერვისი იღებს ინფორმაციას კონკრეტული წიგნის შესახებ.

პასუხი ბრუნდება XML დოკუმენტებში.

ელემენტი ინტერფეისიგანსაზღვრავს ვებ სერვისის ოპერაციების ჩამონათვალს, მათ შორის შეყვანის, გამომავალი და შეცდომის შესახებ შეტყობინებების აღწერას ოპერაციებისთვის, ასევე გადაცემის თანმიმდევრობას.

ელემენტი სავალდებულოგანსაზღვრავს კლიენტსა და ვებ სერვისს შორის კომუნიკაციის საშუალებებს. REST ვებ სერვისების შემთხვევაში კომუნიკაციის საშუალებად მითითებულია HTTP.

სერვისის ელემენტი აკავშირებს ვებ სერვისის მისამართებს კონკრეტულ ინტერფეისებთან და კავშირებთან. (ანუ ის ადგენს კორესპონდენციას ვებ სერვისის ოპერაციის URL-სა და ელემენტს შორის სავალდებულო).

დააკავშირეთ წიგნების სია HTTP-ზე

ელემენტი სავალდებულოგანსაზღვრავს ვებ სერვისის დაკავშირებას მონაცემთა გადაცემის კონკრეტულ პროტოკოლთან. წიგნების სიის სერვისის HTTP-თან დასაკავშირებლად, თქვენ უნდა მიუთითოთ მნიშვნელობა http://www.w3.org/ns/wsdl/http ატრიბუტისთვის. ტიპიელემენტი სავალდებულო.

ელემენტი სავალდებულოსურვილისამებრ შეიძლება ეხებოდეს ინტერფეისი. დატოვეთ ატრიბუტი ინტერფეისიცარიელი. თქვენ შექმნით მას შემდეგ განყოფილებაში. თუ ინტერფეისიდაკავშირებული სავალდებულო, მაშინ სავალდებულოელემენტს შეუძლია სურვილისამებრ განსაზღვროს ბავშვის ელემენტი ოპერაცია, რომელიც სარკეა ინტერფეისის ოპერაციაელემენტი. თქვენ უნდა შექმნათ ელემენტის ჩანაწერი ოპერაციადა შეავსეთ ბმული ოპერაციამოგვიანებით შექმნის შემდეგ ინტერფეისი.

არსებობს 4 HTTP კომუნიკაციის მეთოდი

  • წაშლა

წიგნების სიის სერვისი კითხულობს მოთხოვნას და შესაბამისად მუშაობს HTTP GET-ის გამოყენებით. დააყენეთ GET მეთოდი ოპერაციული ელემენტისთვის WSDL 2.0 HTTP სახელთა სივრცის მეთოდის ატრიბუტის გამოყენებით. ამ ატრიბუტის გამოსაყენებლად, ჯერ უნდა განისაზღვროს სახელთა სივრცე http://www.w3.org/ns/wsdl/http ელემენტზე. აღწერა.

წიგნების სიის სავალდებულო სერვისი განსაზღვრულია შემდეგ ჩამონათვალში. დააკონკრეტე ახლა სავალდებულოელემენტში საბოლოო წერტილი: tns:BookListHTTPBinding.

წიგნის მაღაზიის წიგნების ჩამონათვალის სერვისი.

წიგნების სიის სერვისის ოპერაციის განმარტება

აქამდე თქვენ ისწავლეთ როგორ მიმართოთ და დაუკავშირდეთ წიგნების სიის ვებ სერვისს. შემდეგ თქვენ მიუთითებთ წიგნების სიის სერვისის ოპერაციას, რომელიც აღწერს რას აკეთებს წიგნების სიის სერვისი.

ასე რომ, თქვენ ისწავლეთ როგორ დააყენოთ მისამართი და დააყენოთ სავალდებულო (კომუნიკაციის მეთოდი) ვებ სერვისისთვის. შემდეგი, თქვენ უნდა დააყენოთ სერვისის ოპერაცია, რომელიც განსაზღვრავს რას აკეთებს წიგნების სიის ვებ სერვისი.

ინტერფეისის ელემენტი და მისი შვილობილი ოპერაციის ელემენტი გამოიყენება სერვისის ოპერაციების განსაზღვრისათვის. წიგნების სიის შემთხვევაში, თქვენ განსაზღვრავთ ერთ ოპერაციას, getBookList, რომელიც აბრუნებს წიგნების სიას.

შემდეგი, განსაზღვრეთ სამი ატრიბუტი ოპერაციის ელემენტისთვის:

ნიმუში

გამოიყენება შეტყობინებების ნიმუშის დასადგენად შეტყობინებების გაცვლის ნიმუში(დეპუტატი) ოპერაციისთვის. MEP განსაზღვრავს შეტყობინებების თანმიმდევრობას ოპერაციისთვის და მათ მიმართულებას. ამ შემთხვევაში, თქვენ უნდა მიუთითოთ მნიშვნელობა http://www.w3.org/ns/wsdl/in-out, რათა მიუთითოთ, რომ ვებ სერვისი იღებს ერთ შემავალ შეტყობინებას, რომელიც ითხოვს წიგნების სიას და აგზავნის ერთ გამომავალ შეტყობინებას. წიგნების სია. ამ ევროპარლამენტის მხარდასაჭერად, მიუთითეთ ბავშვები შეყვანადა გამომავალიელემენტისთვის ოპერაცია. ეს ელემენტები იყენებენ XML სქემაში აღწერილ ელემენტებს შეტყობინების სტრუქტურების დასადგენად. დეტალები შემდეგ განყოფილებაში.

სტილი

გამოიყენება სამუშაოს შესახებ დამატებითი ინფორმაციის მითითებისთვის. მიუთითეთ მნიშვნელობა http://www.w3.org/ns/wsdl/style/iri, რომელიც აწესებს შეზღუდვებს შეყვანის ელემენტების შიგთავსზე, როგორიცაა მხოლოდ XML სქემის ელემენტების გამოყენების მოთხოვნა.

wsdlx: უსაფრთხო

wsdlx:safe: WSDL გაფართოებების სახელთა სივრციდან, ეს ატრიბუტი აცხადებს, რომ ეს ოპერაცია იდემპოტენტურია. ამ ტიპის ოპერაცია არ ცვლის რესურსს და, შესაბამისად, შეიძლება მრავალჯერ გამოიძახოს იგივე შედეგებით. ამ ელემენტის გამოსაყენებლად, აღწერის ელემენტზე გამოაცხადეთ WSDL გაფართოებების სახელების სივრცე http://www.w3.org/ns/wsdl-extensions.

ეს ატრიბუტი არის WSDL გაფართოებების სახელთა სივრციდან. ის განსაზღვრავს, რომ ოპერაცია არის უძლური. ეს ოპერაცია არ ცვლის რესურსს, ამიტომ შეიძლება რამდენჯერმე გამოიძახოს იგივე შედეგებით. ამ ელემენტის გამოსაყენებლად, თქვენ უნდა გამოაცხადოთ სახელთა სივრცის WSDL გაფართოებები http://www.w3.org/ns/wsdl-extensions ძირეულ ელემენტში (აღწერის ელემენტი).

თქვენ შეგიძლიათ იპოვოთ წინასწარ განსაზღვრული შეტყობინებების გაცვლის ნიმუშები, სტილები და wsdlx:safe განმარტებები WSDL 2.0 ნაწილი 2: დანამატები

ქვემოთ მოცემულია წიგნების სიის სერვისის განმარტება დამატებული აღწერილობით ინტერფეისი. ინტერფეისის დამატების შემდეგ, ახლა შეგიძლიათ შეცვალოთ სავალდებულო ოპერაციის ელემენტი, რათა მიუთითოთ აღწერილის ბმულები ინტერფეისიდა ოპერაცია.

RESTful HTTP სავალდებულო წიგნების სიის სერვისისთვის. წიგნის მაღაზიის წიგნების ჩამონათვალის სერვისი.

წიგნების სიის ოპერაციის სერვისის შეტყობინებების განსაზღვრა

წიგნების სიის ვებ სერვისი იყენებს ორ შეტყობინებას: შეყვანა და გამომავალი. თქვენ უნდა აღწეროთ ამ შეტყობინებების სტრუქტურები, რათა კლიენტის პროგრამებმა იცოდნენ, რა უნდა გაუგზავნონ სერვისს და რა უნდა ელოდონ უკან.

WSDL 2.0 მხარს უჭერს რამდენიმე ტიპის სისტემას შეტყობინების შინაარსის აღწერისთვის, მაგრამ XML სქემა ერთადერთია, რომელიც გამოიყენება. ეს განყოფილება არ მოიცავს XML სქემის დეტალებს. XML სქემა გამოიყენება ბევრ სხვა აპლიკაციაში, როგორიცაა WSDL 1.1 და ბევრი კარგი სტატიაა ამის შესახებ. ეს განყოფილება ხაზს უსვამს, თუ როგორ გამოვიყენოთ XML სქემა წიგნების სიის REST ვებ სერვისისთვის და როგორ გამოვიყენოთ WSDL 2.0-ით განსაზღვრული დამატებითი ატრიბუტები სქემის ატრიბუტის ანოტაციისთვის.

WSDL 2.0 მხარს უჭერს მრავალი ტიპის განსაზღვრის სისტემას, მაგრამ პრაქტიკაში გამოიყენება მხოლოდ XML სქემა. ეს სტატია არ განიხილავს დეტალებს XML სქემის შესახებ. XML სქემა გამოიყენება ბევრ სხვა აპლიკაციაში, როგორიცაა WSDL 1.1 და ამის შესახებ ბევრი კარგი სტატიაა. (). ეს განყოფილება აჩვენებს XML სქემის გამოყენებას წიგნების სიის REST სერვისის კონკრეტულ მაგალითთან მიმართებაში, ასევე WSDL 2.0-ში განსაზღვრული დამატებითი ატრიბუტების გამოყენებას სქემის ატრიბუტის ანოტაციისთვის.

წიგნების სიისთვის 2 შეტყობინების აღსაწერად, თქვენ უნდა აღწეროთ 2 გლობალური ელემენტი.

  • getBookListწარმოადგენს შეყვანის შეტყობინებას. იგი შეიცავს ელემენტების თანმიმდევრობას, მათ შორის თითოეული მოთხოვნის პარამეტრს, რომელიც დაშვებულია სერვისისთვის: ავტორიტეტი, სათაური, გამომცემელი, საგანიდა ენა. მხოლოდ ელემენტების გამოყენება შესაძლებელია getBookList შეტყობინების შიგნით, რადგან ინტერფეისის მუშაობისთვის არჩეულია IRI სტილი.
  • წიგნის სიაწარმოადგენს გამომავალ შეტყობინებას. იგი შეიცავს წიგნის ელემენტების თანმიმდევრობას. წიგნის თითოეული ელემენტი თავის მხრივ შეიცავს სათაურსა და url ატრიბუტებს. სათაურის ატრიბუტი თავისთავად გასაგებია. url ატრიბუტი არის ბმული წიგნის დეტალების სერვისზე, რომელიც აბრუნებს დეტალურ ინფორმაციას კონკრეტული წიგნის შესახებ.

თქვენი url ატრიბუტის განმარტება თავის მხრივ იყენებს 2 ატრიბუტს WSDL გაფართოებების სახელთა სივრციდან. wsdlx:interface და wsdlx:binding ატრიბუტები განსაზღვრავს სერვისის ინტერფეისს და სავალდებულოს. პროგრამულ უზრუნველყოფას შეუძლია გამოიყენოს ეს ინფორმაცია სერვისის ავტომატურად განთავსებისთვის. ამ ატრიბუტების გამოსაყენებლად, მიუთითეთ ელემენტის WSDL გაფართოებების სახელების სივრცე სქემა. ასევე ჩართეთ წიგნის დეტალების სახელთა სივრცე მისი WSDL 2.0 აღწერილობიდან.

წიგნების სიის სერვისის XML სქემა მოცემულია ქვემოთ.

მოთხოვნის ელემენტი წიგნების სიის სერვისისთვის. პასუხის ელემენტი წიგნების სიის სერვისისთვის.

შეყვანისა და გამომავალი ელემენტების მითითებისთვის, თქვენ უნდა შემოიტანოთ სქემა თქვენს WSDL დოკუმენტში. სქემის იმპორტისთვის გამოიყენეთ სქემის იმპორტის ელემენტი ტიპების განყოფილებაში, როგორც ეს ნაჩვენებია ქვემოთ მოცემულ ჩამონათვალში. გარდა ამისა, თქვენ უნდა დაამატოთ ცნობები getBookList და Booklist ელემენტებზე ინტერფეისის ოპერაციების შეყვანისა და გამომავალი ელემენტებში და დაამატოთ წიგნების სიის XML სქემის სახელთა სივრცეები WSDL root ელემენტს.

მზა WSDL წიგნების სიის ვებ სერვისისთვის.

ეს არის WSDL 2.0 აღწერილობა წიგნების მაღაზიის სერვისების ჩამონათვალის წიგნების ინფორმაციის მისაღებად. ეს ოპერაცია აბრუნებს წიგნების სიას. RESTful HTTP სავალდებულო წიგნების სიის სერვისისთვის. წიგნის მაღაზიის წიგნების ჩამონათვალის სერვისი.

მთარგმნელის შენიშვნა

მე ავიღე თავისუფლება არ გადამეთარგმნა რეზიუმე და ბმულები. იხილეთ ავტორი ორივესთვის. თავდაპირველ სტატიაში. უნდა ითქვას, რომ ორიგინალური ენა ძალიან რთულია. თუმცა, იმედი მაქვს, რომ სტატია სასარგებლო იქნება.

XSD: XML სქემის განმარტება.

XML: გაფართოებადი მარკირების ენა.

WSDL: ვებ სერვისების განმარტების ენა.

ტექნიკურად პასუხს არ ვაპირებ. მე ამ ახსნას მივმართავ ახალბედებს.

არ არის ადვილი კომუნიკაცია ორ განსხვავებულ აპლიკაციას შორის, რომლებიც შემუშავებულია ორი განსხვავებული ტექნოლოგიის გამოყენებით. მაგალითად, ჩიკაგოში მყოფმა კომპანიამ შეიძლება განავითაროს ვებ აპლიკაცია Java-ს გამოყენებით, ხოლო სხვა კომპანიამ ნიუ-იორკში შეიძლება განავითაროს აპლიკაცია C#-ში, და როდესაც ორი კომპანია გადაწყვეტს ინფორმაციის გაზიარებას, მაშინ XML ჩნდება სურათზე. ის ეხმარება მონაცემთა შენახვას და ტრანსპორტირებას ორ განსხვავებულ აპლიკაციას შორის, რომლებიც შემუშავებულია სხვადასხვა ტექნოლოგიების გამოყენებით. Შენიშვნა. ეს არ შემოიფარგლება პროგრამირების ენით, გთხოვთ შეისწავლოთ ინფორმაციის ტრანსპორტირება ორ განსხვავებულ აპლიკაციას შორის.

XSD არის სქემის განმარტება. ამით მე ვგულისხმობ იმას, რომ ის მომხმარებლებს ეუბნება შექმნან თავიანთი XML ასეთ სქემაში. გთხოვთ, იხილოთ ქვემოთ მოცემული სურათები და ყურადღება მიაქციოთ "ჩატვირთვისას" ელემენტს და მის ტიპს, რომელიც არის მთელი რიცხვი. XSD სურათზე ხედავთ, რომ ეს არის მთელი რიცხვი "ჩატვირთვისას" და, შესაბამისად, როდესაც მომხმარებელმა შექმნა თავისი XML, მან გადასცა int მნიშვნელობა ამ კონკრეტულ ელემენტს. შეგახსენებთ, რომ XSD არის სქემა და სტილი, ხოლო XML არის ფორმა სხვა აპლიკაციასთან ან სისტემასთან კომუნიკაციისთვის. თქვენ უნდა ნახოთ XSD და შექმნათ XML ამ გზით, წინააღმდეგ შემთხვევაში ის არ დაუკავშირდება სხვა აპლიკაციას ან სისტემას, რომელიც შეიქმნა სხვა ტექნოლოგიის გამოყენებით. ჩიკაგოს კომპანია უზრუნველყოფს XSD შაბლონს ტეხასის კომპანიისთვის, რომ დაწეროს ან შექმნას თავისი XML ამ XSD ფორმატში. თუ ტეხასის კომპანიამ ვერ შეასრულა XSD-ში აღნიშნული წესები ან სქემები, მაშინ შეუძლებელია ჩიკაგოში მყოფი კომპანიისგან სწორი ინფორმაციის მოლოდინი. ზემოთ მოყვანილი ისტორიის შემდეგ, იმდენი რამ არის, რაც მოყვარულმა ან დამწყებმა უნდა იცოდეს ზოგიერთი რამის კოდირებისას, როგორც ზემოთ ვთქვი. თუ ნამდვილად გსურთ იცოდეთ რა იქნება შემდეგი, მაშინ უმჯობესია დაჯდეთ უფროს პროგრამულ ინჟინრებთან, რომლებმაც რეალურად განავითარეს ვებ სერვისები. შემდეგი არის WSDL, გთხოვთ, მიჰყევით სურათებს და შეეცადეთ გაარკვიოთ სად მოერგება WSDL.

*************** ======== ქვემოთ მოცემულია ნაწილობრივი XML სურათი ========== ********* ** *****

*************** ======== ქვემოთ მოცემულია ნაწილობრივი XSD სურათი ========== ********* ** *****

*************** ======== ქვემოთ არის ნაწილობრივი WSDL სურათი ======= *********** **

მე უნდა შემექმნა WSDL ნიმუში ვებ სერვისისთვის სახელწოდებით "წიგნი". გაითვალისწინეთ, რომ ეს არის XSD, მაგრამ თქვენ უნდა უწოდოთ მას WSDL (ვებ სერვისების განმარტების ენა), რადგან ის ძალიან სპეციფიკურია ვებ სერვისებისთვის. ქვემოთ WSDL (ან სხვა სიტყვებით რომ ვთქვათ XSD) შექმნილია Book.java კლასისთვის და მან შექმნა SOAP სერვისი. როგორ შეიქმნა SOAP ვებ სერვისი, ეს სხვა თემაა. Java-ის კლასი უნდა დაიწეროს და სანამ მის ვებ სერვისად შექმნას განაგრძობს, მომხმარებელმა უნდა დარწმუნდეს, რომ Axis2 API დაინსტალირებულია და Tomcat ვებ სერვისის მასპინძლობისთვის არის ადგილზე.

როგორც სერვისის პროვაიდერი (ის, ვინც საშუალებას აძლევს სხვებს (კლიენტებს) მიიღონ ინფორმაცია ან მონაცემები მათი სისტემებიდან) ეფექტურად აძლევს კლიენტს (მათ, ვინც უნდა გამოიყენოს სერვისის პროვაიდერის ინფორმაცია ან მონაცემები) სრულ წვდომას მონაცემებზე ვებ სერვისის საშუალებით, და არც ერთ კომპანიას. on earth არ არის მზად თავისი მონაცემთა ბაზა ხელმისაწვდომი გახადოს აუტსაიდერებისთვის. ჩემი კომპანიის მსგავსად, მე გადავწყვიტე პროდუქტის შესახებ გარკვეული ინფორმაციის მიწოდება ვებ სერვისების საშუალებით, ამიტომ მოგვიწია შეგვექმნა XSD შაბლონი და გადაგვეტანა ის ჩვენს ზოგიერთ კლიენტზე, ვისაც სურს ჩვენთან მუშაობა. მათ უნდა დაწერონ კოდი, რათა სრულად გამოიყენონ მოცემული XSD და განახორციელონ ვებ სერვისის ზარები სერვისისგან მონაცემების მოსაპოვებლად და დაბრუნებული მონაცემების შესაბამის მოთხოვნად გარდაქმნაზე და შემდეგ აჩვენონ ან გამოაქვეყნონ მონაცემები ან პროდუქტის ინფორმაცია თავიანთ ვებსაიტზე. მარტივი მაგალითი იქნება FLIGHT ფრენების დაჯავშნა. ავიაკომპანია მესამე პირებს საშუალებას მისცემს გამოიყენონ ფრენის მონაცემები მის ვებგვერდზე ბილეთების გასაყიდად. მაგრამ კიდევ ბევრი რამ არის მასში, უბრალოდ, თუ მესამე მხარის ავიაბილეთების სააგენტოს ბილეთების გაყიდვის უფლება არ მისცემთ, იქნება სინქრონიზაცია და უსაფრთხოება. თუ არ არის სინქრონიზაცია, მაშინ არის 100% შანსი, რომ ერთზე მეტ კლიენტს შეუძლია იყიდოს ერთი და იგივე ბილეთი სხვადასხვა წყაროდან.

იმედი მაქვს, რომ ექსპერტები ხელს შეუწყობენ ჩემს პასუხს. დამწყებთათვის ან დამწყებთათვის ძალიან რთულია XML, XSD-ის გაგება და შემდეგ ვებ სერვისებთან მუშაობა.

მე-2 თავში განვიხილეთ, რომ სერვერზე ვებ სერვისის შექმნის შემდეგ, როგორც servlet, JSP გვერდი, JWS ფაილი, EJB ან სხვა ობიექტი, თქვენ უნდა აღწეროთ ვებ სერვისის შემადგენლობა და შესაძლებლობები პლატფორმისგან დამოუკიდებელ ენაზე, რომელიც მუშაობს. სისტემის სისტემა, პროგრამირების სისტემა, რომელიც გამოიყენება ვებ სერვისის შესაქმნელად. ეს აღწერა რეგისტრირებულია ინტერნეტის საჯაროდ ხელმისაწვდომ ადგილას, როგორიცაა UDDI ან ebXML რეესტრი, ან ინახება ვებ სერვისის სერვერზე. აღწერა უნდა შეიცავდეს სრულ და ზუსტ ინფორმაციას ვებ სერვისის მიერ მოწოდებული ყველა სერვისის შესახებ, სერვისების მიღების მეთოდებს, სერვისზე მოთხოვნის შინაარსს და მოწოდებული ინფორმაციის ფორმატს.

ვებ სერვისების ზუსტი და ერთგვაროვანი აღწერის ერთ-ერთი საშუალებაა WSDL ენა, შექმნილი W3C კონსორციუმის მიერ. ეს ენა XML-ის კიდევ ერთი განხორციელებაა. მისი უახლესი რეკომენდებული სპეციფიკაცია ყოველთვის ქვეყნდება გვერდზე http://www.w3.org/TR/wsdI. წიგნის დაწერის დროს WSDL ვერსია იყო 1.2, რომელსაც ამ თავში აღვწერთ.

WSDL დოკუმენტის შემადგენლობა

XML დოკუმენტის ძირეული ელემენტი - WSDL აღწერა - არის ელემენტი . ამ ელემენტში შეგიძლიათ გამოიყენოთ არასავალდებულო სახელი ატრიბუტი აღწერილობის სახელის მისაცემად. ასევე მოსახერხებელი ადგილია აღწერილობაში გამოყენებული სახელთა სივრცის გასაცნობად.

WSDL განმარტებები ფართოდ იყენებს სხვადასხვა სახელების სივრცეს. შესაბამისი სახელების გარდა, WSDL ხშირად იყენებს XSD სქემის განსაზღვრის ენის ტიპებისა და ელემენტების სახელებს (იხ. თავი 1) და SOAP პროტოკოლის ენის სახელებს. WSDL სახელთა სივრცე ხშირად აღწერილია, როგორც ნაგულისხმევი სახელთა სივრცე. WSDL 1.2-ის უახლესი ვერსიის სახელთა სივრცის იდენტიფიკატორი წერის დროს ტოლი იყო http://www.w3.org/2002/07/wsdl. სამიზნე სახელთა სივრცე, რომლის იდენტიფიკატორი მითითებულია ატრიბუტით, ჩვეულებრივ, პრეფიქსით არის tns (სამიზნე სახელთა სივრცე).

ფესვის ელემენტამდე ჩართულია ექვსი ძირითადი და ორი დამატებითი ტიპის ელემენტები. ყველა ელემენტი არჩევითია, მათი რაოდენობა შეიძლება იყოს ნებისმიერი, გარდა ელემენტისა , რომელიც შეიძლება მხოლოდ ერთხელ გამოჩნდეს დოკუმენტში. თითოეულ ელემენტს აქვს სახელი, რომელიც განისაზღვრება საჭირო სახელის ატრიბუტით. ელემენტები ეხება ერთმანეთს ამ სახელების გამოყენებით. აქ არის ელემენტები, რომლებიც ჩადებულია ძირეულ ელემენტში

? განსაზღვრავს ვებ სერვისის მიერ გამოყენებულ კომპლექსურ ტიპებს XSD ან სხვა ტიპის განსაზღვრების ენის გამოყენებით. ეს ელემენტი არ არის საჭირო, თუ ვებ სერვისი იყენებს მხოლოდ XSD ენაზე აღწერილ მარტივ ტიპებს.

? - აღწერს თითოეულ SOAP შეტყობინებას: მოთხოვნა, პასუხი, დოკუმენტის გადაცემა. ეს ელემენტი შეიცავს ელემენტებს გზავნილის ნაწილების აღწერა, რომლებიც განუყოფელია WSDL-ის თვალსაზრისით. პროცედურული ტიპის შეტყობინებებისთვის, თითოეული ელემენტი შეუძლია აღწეროს ერთი მოთხოვნის არგუმენტის სახელი და ტიპი ან დაბრუნებული მნიშვნელობის ტიპი. დოკუმენტის ტიპის შეტყობინებებისთვის, ელემენტები შეუძლია შეტყობინების თითოეული ნაწილის აღწერა „მრავალნაწილიანი/დაკავშირებული“. ეს აბსტრაქტული აღწერა შემდეგ ხდება ელემენტებით .

? აღწერს ვებ სერვისის ინტერფეისს, რომელსაც უწოდებენ WSDL-ში შეტყობინების საბოლოო წერტილს ან მისვლის პორტს. იგი აღწერილია, როგორც ვებ სერვისების ერთობლიობა, რომელსაც ეწოდება ოპერაციები WSDL-ში. ამ აღწერილობის პროგრამირების ენაზე თარგმნისას, თქვენ ხედავთ, რომ პორტი კარგად არის დაკავშირებული Java ინტერფეისთან და თითოეული ოპერაცია კარგად არის დაკავშირებული ამ ინტერფეისის მეთოდთან. ოპერაციები აღწერილია წყობილი ელემენტებით , აღწერს თითოეულ ინდივიდუალურ მომსახურებას. სერვისი აღწერილია მოქმედებებით, რომლებიც იყოფა ოთხ ტიპად. ეს არის ორი მარტივი ქმედება: „შეტყობინების მიღება“, „პასუხის გაგზავნა“ და ორი კომბინირებული მოქმედება: „შეტყობინებების გაგზავნა - პასუხის მიღება“ ან, პირიქით, „შეტყობინების მიღება - პასუხის გაგზავნა“. მიღება და გაგზავნა, თავის მხრივ, აღწერილია წყობილი ელემენტებით და და შეცდომის შეტყობინება არის ელემენტი . მიღებული და გაგზავნილი შეტყობინებები უკვე უნდა იყოს აღწერილი ელემენტებით , ელემენტები , და მიმართეთ მათ შეტყობინების ატრიბუტით.

? - ჩამოთვლის ჩადგმულ ელემენტებს პორტების ნაკრები, რომელიც დაკავშირებულია ერთ ვებ სერვისთან. ერთი და იგივე პორტი შეიძლება დაკავშირებული იყოს მრავალ სერვისთან.

? - აღწერს შეტყობინების გაგზავნის სპეციფიკურ ფორმატს: პროტოკოლებს, როგორიცაა SOAP ან HTTP, შეტყობინების შეფუთვის მეთოდები, მისი შინაარსის ტიპი: HTML, XML ან სხვა MIME შეტყობინების ტიპი. თითოეული ელემენტი შეიძლება ასოცირებული იყოს რამდენიმე ასეთ ელემენტთან, ერთი გადაგზავნის თითოეული მეთოდისთვის. ეს ელემენტი შეიცავს ელემენტებს, რომლებიც განსაზღვრულია არჩეული პროტოკოლის სქემაში.

? < service >- განსაზღვრავს ვებ სერვისის მდებარეობას, როგორც ერთი ან მეტი პორტი. თითოეული პორტი აღწერილია ჩადგმული ელემენტით შეიცავს ელემენტში არჩეული წესების მიხედვით მითითებულ ვებ სერვისის ინტერფეისის მისამართს ტრანსპორტირების მეთოდი.

ამ ექვსი ძირითადი ელემენტის გარდა, არის კიდევ ორი ​​დამხმარე ელემენტი.

? - მოიცავს WSDL XSD სქემის ფაილს ან სხვა WSDL ფაილს.

კომენტარი. ის შეიძლება შევიდეს ნებისმიერ ელემენტში

WSDL აღწერილობები.

შეგვიძლია ვთქვათ, რომ ელემენტები , და ისინი აჩვენებენ, თუ რა აქვს აღწერილ ვებ სერვისს, რა სერვისებს აწვდის მას, როგორ არის ორგანიზებული სერვისები და რა ტიპის მონაცემები აქვს ამ სერვისებს.

ელემენტები განმარტეთ როგორ ხდება ვებ სერვისის დანერგვა, რა არის შეტყობინების გადაცემის პროტოკოლი: HTTP, SMTP თუ სხვა და ასევე აკონკრეტებს მონაცემთა გადაცემის ტექნიკურ მახასიათებლებს.

და ბოლოს, ელემენტები აჩვენე სად მდებარეობს ვებ სერვისი აღწერილობის ბმულით კონკრეტული ვებ სერვისის მისამართებით.

WSDL დოკუმენტის სტრუქტურა ნაჩვენებია სიაში 4.1. სიმბოლოები კვადრატულ ფრჩხილებში არ შეიცავს დოკუმენტს. ისინი აჩვენებენ ელემენტის ან ატრიბუტის განმეორებას ვებ სერვისის აღწერაში:

[?] სიმბოლო ნიშნავს, რომ ელემენტი ან ატრიბუტი შეიძლება იყოს ნულოვანი ან ერთხელ დოკუმენტში;

[*] სიმბოლო ნიშნავს, რომ ელემენტი შეიძლება გამოჩნდეს ნულამდე ან მეტჯერ;

[+] სიმბოლო ნიშნავს, რომ ელემენტი შეიძლება გამოჩნდეს ერთხელ ან მეტჯერ;

კვადრატულ ფრჩხილებში სიმბოლოს არარსებობა ნიშნავს, რომ ატრიბუტი ზუსტად ერთხელ უნდა გამოჩნდეს.

j ჩამონათვალი 4.1. WSDL დოკუმენტის სქემა

targetNamespace="nfleH l ra«iij

ადგილმდებარეობა = "URI-aflpec" /> [*]

უფასო კომენტარი

რთული და არასტანდარტული ტიპების აღწერილობები.

[*]

[*]

[? ]

SOAP შეტყობინების აბსტრაქტული აღწერა, როგორც მისი შემადგენელი ნაწილების ნაკრები.

[*]

ვებ სერვისის, როგორც ოპერაციების (სერვისების) ერთობლიობის აბსტრაქტული აღწერა.

[*]

სერვისის აღწერა, როგორც შეტყობინებების მიღება (შეყვანა) და გაგზავნა (გამომავალი, გაუმართაობა).

[?]

მიღებული შეტყობინება.

[?] [?]

Გაგზავნილი

message="nMH შესაბამისი ელემენტი "> [*] [?]

შეცდომის შეტყობინება უნდა გაიგზავნოს.

[*]

[+]

type="შესაბამისი ელემენტის MMH "> [*]

[?]

პროტოკოლის კონკრეტული დეტალები. ისინი განსაზღვრულია სქემაში

ამ პროტოკოლს. ->

[*]

[?]

დეტალების აღწერის ელემენტები აქ იწერება

კონკრეტული ოპერაცია. ->

[?]

ელემენტები, რომლებიც აღწერს

მიღებული კონკრეტული შეტყობინების დეტალები. ->

[?]

[?]

ელემენტები, რომლებიც აღწერს

გაგზავნილი კონკრეტული შეტყობინების დეტალები. ->

[*]

[?]

ელემენტები, რომლებიც აღწერს

კონკრეტული შეცდომის შეტყობინების დეტალები. ->

serviceType="შესაბამისი ელემენტის MMH "> [*]

ვებ სერვისის ინტერფეისის აღწერა, როგორც პორტების ნაკრები.

binding="nMH შესაბამისი ელემენტის "> [*]

[?]

აქ იწერება ვებ სერვისის ინტერფეისის სავალდებულო და ერთადერთი მისამართი, წესების მიხედვით

ელემენტში მითითებული პროტოკოლი . ->

ყოველი კონკრეტული შეტყობინების გადაცემის პროტოკოლი - SOAP, HTTP, FTP, SMTP - ამატებს თავის დამატებით ელემენტებს WSDL ენის ექვს ძირითად და ორ დამხმარე ელემენტს, აღწერს ამ პროტოკოლის მახასიათებლებს.

მოვიყვანოთ მარტივი მაგალითი. სიაში 3.14, ჩვენ დავწერეთ მარტივი ვებ სერვისი, როგორც Java კლასი, რომელიც აბრუნებს გაგზავნილ მოთხოვნას ყოველგვარი დამუშავების გარეშე:

საჯარო კლასის EchoService (

საჯარო სტრიქონი getEcho(სტრიქონი req) ( დაბრუნების მოთხოვნა;

ჩამონათვალი 4.2 აღწერს ამ ვებ სერვისს WSDL-ში SOAP პროტოკოლის გამოყენებით.

ჩამონათვალი 4.2. EchoService ვებ სერვისის აღწერა

ვერსია = "1.0" კოდირება = "UTF-8" ?>

targetNamespace="http://echoservice.com/echoservice.wsdl" xmlns="http://www.w3.org/2002/07/wsdl" xmlns:tns="http://echoservice.com/echoservice.wsdl " xmlns:soap="http://www.w3.org/2002/07/wsdl/soapl2" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

transport="http://schemas.xmlsoap.org/soap/http" />

"http://schemas.xmlsoap.org/soap/encoding/"

namespace= "http://echoservice.ccm/echcservice.wsdl" use="encoded" />

^oapKbocy enccdingStyle=

"http: //schemas .xmlsoap. org/soap/encoding/" namespace= "http: //echoservice. c^/ech^service .wsdl" use="encoded" />

name="EchoServService">

Binding="tns:EchoServiceSoapBinding" name="EchoService"> მდებარეობა =

"http://localhost:8080/axis/EchoService.jws" />

სიაში 4.2 ჩვენ ელემენტში ვართ ჩვენ განვსაზღვრეთ ჩვენთვის საჭირო ყველა სახელთა სივრცის პრეფიქსი. შემდეგი, ჩვენ აღვწერეთ მოთხოვნა და პასუხი ორ ელემენტად . ჩვენ მივეცით მათ სახელები "getEchoRequest" და "getEchoResponse". მოთხოვნა შეიცავს xsd ტიპის ერთ არგუმენტს: string. ეს ტიპი განსაზღვრულია XSD ენაზე. არგუმენტს მივეცით სახელი req, რომელიც იგივეა, რაც getEcho() მეთოდის არგუმენტის სახელი. მეთოდით დაბრუნებულ მნიშვნელობას დავარქვით return, მისი ტიპი ასევე არის xsd: string.

სახელები "getEchoRequest" და "getEchoResponse" გამოიყენება შემდეგ ელემენტში ვებ სერვისის შეყვანის და გამომავალი პარამეტრების დასაზუსტებლად. ის შეიცავს ერთ ელემენტს . ეს ნიშნავს, რომ ვებ სერვისი უზრუნველყოფს ერთ სერვისს, რომლის სახელი "getEcho" იგივეა, რაც იმ მეთოდის სახელს, რომელიც ახორციელებს ამ სერვისს. ელემენტი განსაზღვრავს შეყვანას და დასვენების დღე სერვისის პარამეტრები. შემდეგ ელემენტი ჩვენ დავაფიქსირეთ შეტყობინებების გაგზავნის ერთი გზა - პროცედურული სტილის SOAP შეტყობინებები, რომლებიც გაგზავნილია HTTP პროტოკოლით, როგორც ეს ელემენტით არის მითითებული.

txarspcrt^=^"ht:tp^://?chepas^.>plscap^.c^rc^/?cap^/ht:tp^" />

თუ SOAP დოკუმენტის სტილი გამოიყენება, სტილის ატრიბუტი დაყენებულია „დოკუმენტზე“.

ბოლოს ელემენტში ჩადგმული ელემენტი ელემენტის დაკავშირება ელემენტთან ერთად

, სადაც მითითებულია მისამართი, სადაც მდებარეობს ვებ სერვისი.

4.2 ჩამონათვალში საპნით დატანილი სახელები მიუთითებდნენ შეტყობინების აღწერას და როგორ გაიგზავნა. ვნახოთ, რა კონკრეტულ პროტოკოლებს გვთავაზობს WSDL 1.2 სპეციფიკაცია.

ლიტერატურა:

ხაბიბულინი I. შ. ვებ სერვისების განვითარება Java-ს გამოყენებით. - სანკტ-პეტერბურგი: BHV-Petersburg, 2003. - 400გვ.: ილ.

WSDL (ვებ სერვისების აღწერილობის ენა) ვერსია 1.1 გამოქვეყნდა 2001 წლის 15 მარტს. WSDLარის XML-ზე დაფუძნებული ფორმატი, რომელიც გამოიყენება ვებ სერვისების აღსაწერად შეტყობინებების გამოყენებით, რომლებიც შეიცავს ინფორმაციას კონკრეტულ ვებ სერვისზე წვდომის შესახებ. WSDLგაფართოებადი, რაც საშუალებას გაძლევთ აღწეროთ სერვისები და მათი შეტყობინებები, იმისდა მიუხედავად, თუ რა შეტყობინებების ფორმატები ან ქსელის პროტოკოლები გამოიყენება ტრანსპორტირებისთვის, თუმცა, WSDL 1.1 ყველაზე ხშირად გამოიყენება SOAP 1.1, HTTP GET/POST და MIME-თან ერთად. Იმიტომ რომ WSDLშეიქმნა SOAP-თან ერთად და მის განვითარებაში მონაწილეობა მიიღეს იგივე კომპანიებმა Microsoft-მა, Ariba-მ და IBM-მა. თუ გავითვალისწინებთ დოკუმენტს WSDLინტუიციურად, შეგვიძლია ვთქვათ, რომ ეს საშუალებას იძლევა უპასუხეთ 4 კითხვას:

1) რას აკეთებ? ამ კითხვაზე პასუხი მოცემულია როგორც ადამიანის აღქმისთვის, ასევე მანქანით აღქმადი ფორმისთვის. პასუხი ტეგში მოყვანილი პირისთვის:<სახელი/>, <დოკუმენტაცია/> მანქანისთვის -<შეტყობინება/>, <წერტილის ტიპი>

2) რა ენაზე საუბრობ? (რა ტიპებს იყენებთ?) უპასუხეთ ტეგში:<ტიპები/>

3) როგორ დაგიკავშირდები? (როგორ შეძლებს კლიენტი წვდომას ვებ სერვისზე?): HTTP ან SMTP. პასუხი იმაში მდგომარეობს<სავალდებულო/>

4) სად ვიპოვო? (სად ვიპოვო ეს ვებ სერვისი ან რა არის მისი URL?). Პასუხი არის:<სერვისი/>

სტრუქტურა:

თითოეული WSDL დოკუმენტი შეიძლება დაიყოს სამ ლოგიკურ ნაწილად:

1. მონაცემთა ტიპების განსაზღვრა - XML ​​სერვისის მიერ გაგზავნილი და მიღებული შეტყობინებების ტიპის განსაზღვრა

2. აბსტრაქტული ოპერაციები - ოპერაციების სია, რომელიც შეიძლება შესრულდეს შეტყობინებებით

3. სერვისის დაკავშირება - მეთოდი, რომლითაც გაგზავნილი იქნება შეტყობინება

დოკუმენტაცია WSDLშეიძლება შეიქმნას ხელით, მაგრამ ენა მკაცრად ფორმალიზებულია WSDLსაშუალებას გაძლევთ ავტომატიზირდეთ წერის პროცესი WSDL- დოკუმენტები. მრავალი ვებ სერვისის საავტორო ინსტრუმენტი შეიცავს კომუნალურ პროგრამებს, რომლებიც ავტომატურად ქმნიან WSDL-ფაილები, რომლებიც აღწერს მზა ვებ სერვისებს. მაგალითად, ვებ სერვისების საავტორო ინსტრუმენტი აპაჩის ღერძიშეიცავს კლასს Java2WSDL, შექმნა WSDL- Java კლასის ან ინტერფეისის ფაილი, რომელიც აღწერს ვებ სერვისს. IBM WSTK პაკეტი, რომელიც მოიცავს ღერძი, შეიცავს უტილიტას java2wsdl, რომელიც ქმნის და აწარმოებს ობიექტს ამ კლასიდან. ის მუშაობს ბრძანების ხაზიდან.

WSDL დოკუმენტის ელემენტები

მოდით აღვწეროთ ყველაზე ხშირად გამოყენებული WSDL ტეგები:

მონიშნეთ არის ყველა WSDL დოკუმენტის ძირითადი ტეგი. იგი განსაზღვრავს რამდენიმე სახელთა სივრცეს:

1) target Name space არის ჩვენი ვებ სერვისის სახელთა სივრცე

2) xmlns – სტანდარტული WSDL დოკუმენტის სახელთა სივრცე

3)xmlns: SOAP_ENC – სახელთა სივრცე, რომელიც გამოიყენება SOAP კოდირების აღსაწერად


4) xmlns: impl და intf – ჩვენი ვებ სერვისის განხორციელების და განსაზღვრის სახელთა სივრცე

· ვებ სერვისის განმარტების დოკუმენტი

· ვებ სერვისის განხორციელების დოკუმენტი

სიმარტივისთვის, როგორც წესი, იყენებენ 1 ფაილს, რომელიც შეიცავს ყველა ინფორმაციას

ელემენტი - გვაწვდის ინფორმაციას ერთი ბოლო წერტილიდან მეორეზე გადატანილი მონაცემების შესახებ.

RPC ზარის აღსაწერად, თქვენ უნდა შექმნათ შემავალი და გამომავალი შეტყობინება.

ამ ელემენტის ფარგლებში, თქვენ შეგიძლიათ მიუთითოთ მეთოდის პარამეტრები ელემენტის გამოყენებით

ელემენტი აღწერს და განსაზღვრავს ვებ სერვისის მიერ მხარდაჭერილ ოპერაციებს ან მეთოდებს

ოპერაციებს შეიძლება ჰქონდეს როგორც შემავალი შეტყობინებები, ასევე შეცდომის შეტყობინებები.

ელემენტი - აღწერს, თუ როგორ გადაიცემა პორტის ტიპში მითითებული ოპერაციები ქსელში. იმიტომ რომ ელემენტი იყენებს პორტის ტიპს, მან უნდა მიუთითოს დოკუმენტში სადღაც ადრე განსაზღვრული ტიპი.

ელემენტი - მიუთითებს სად ვიპოვოთ ვებ სერვისი

ელემენტი იმპორტი . ძალიან ხშირად სერვისის ელემენტი გამოყოფილია საკუთარ wsdl დოკუმენტზე პრაქტიკულობის გამო.

რამდენიმე wsdl დოკუმენტის ერთში გაერთიანების დასაშვებად, გამოიყენება იმპორტის ელემენტი. ის საშუალებას გაძლევთ ჩართოთ ერთი wsdl დოკუმენტი მეორეში.

ელემენტი ტიპები საშუალებას გაძლევთ მიუთითოთ გადაცემული მონაცემების ტიპები, თუ ისინი არ არის სტანდარტული.

WSDL მხარს უჭერს ოპერაციების 4 რეჟიმს:

· ცალმხრივი ან ცალმხრივი ოპერაციები. შეტყობინება იგზავნება სერვისის ბოლო წერტილში. ამ შემთხვევაში, ოპერაცია აღწერილია მხოლოდ ერთი შეყვანის შეტყობინებით.

· მოთხოვნა-პასუხი – მოთხოვნა-პასუხის რეჟიმი. მუშაობის ეს რეჟიმი ყველაზე გავრცელებულია. ამ რეჟიმში, ოპერაციის აღწერა შეიცავს შემავალ და გამომავალ შეტყობინებას და არჩევით შეცდომის შეტყობინებას.

· მოთხოვნა-პასუხის ტიპის ოპერაცია. ამ რეჟიმში, საბოლოო წერტილი არის სხვა საბოლოო წერტილის კლიენტი. ოპერაციის ფორმატი მსგავსია მოთხოვნა-პასუხის რეჟიმში, მაგრამ გამომავალი მონაცემები ჩამოთვლილია შეყვანის მონაცემამდე.

· ოპერაციის შეტყობინება. ეს რეჟიმი არის ცალმხრივი გადაცემის პრიმიტივის კიდევ ერთი ვერსია, რომელშიც ბოლო წერტილი აგზავნის შეტყობინებას და არა მის მიღებას. ოპერაცია შეიცავს მხოლოდ გამომავალ შეტყობინებას.

სტანდარტიზებული აღწერა აადვილებს მის გაგებას და გამოყენებას. ვთქვათ, რომ თქვენ იპოვეთ სერვისი, რომელიც აგვარებს თქვენთვის საჭირო პრობლემებს და გსურთ მისი გამოყენება თქვენს გადაწყვეტილებებში. სხვისი დიზაინისა და მისი შესაძლებლობების შესახებ ინფორმაციის მისაღებად ყველაზე მარტივი გზაა WSDL აღწერილობის ნახვა. WSDL დოკუმენტები შეიძლება შედგებოდეს მრავალი მოდულისაგან ან სხვა დოკუმენტების მითითებით ან XML სქემებისგან (XSD), რომლებიც აღწერს მონაცემთა ტიპებს, რომლებიც გამოიყენება ვებ სერვისში. თავდაპირველად, აღწერილობის შენარჩუნების რამდენიმე ვარიანტი იყო შემოთავაზებული და ორმა მთავარმა მოთამაშემ - Microsoft და IBM - წარმოადგინეს თავიანთი ხედვა ამ პრობლემის შესახებ. პირველმა შეიმუშავა და შესთავაზა SDL (სერვისის აღწერის ენა), რომელიც შედიოდა კომპანიის SOAP Toolkit-ის პირველ ვერსიაში. IBM-მა წარმოადგინა პრობლემის ხედვა Network NASSL-ში (Accessible Service Specification Language), რომელიც დანერგილი იყო SOAP4J-ში, როგორც NASSL Toolkit-ის ნაკრები. NASSL-ში შემოთავაზებულმა იდეებმა შთააგონა მაიკროსოფტი, გაეგრძელებინა აღწერილობის ენის შემუშავება, რის შედეგადაც შეიქმნა SOAP Contract Language (SCL). ეს გამოსავალი ძალიან ეფექტური აღმოჩნდა, ის დაიხვეწა მესამე მხარის მწარმოებლების სურვილების გათვალისწინებით და 2001 წლის 15 მარტს იდეები გახდა WSDL 1.1 სპეციფიკაცია. რა თქმა უნდა, კომპიუტერული სფერო ამდენი წელი ვერ იცოცხლებს ცვლილებების გარეშე, ამიტომ ვერსია 2.0 გამოჩნდა 2006 წლის 27 მარტს, ხოლო 2007 წლის 26 ივნისიდან მას საკონსულტაციო ხასიათი აქვს.

Unix/Linux ბრძანების მითითება

ამბავი

WSDL 1.0 (სექტემბერი 2000) შეიქმნა IBM-ის, Microsoft-ისა და Ariba-ს მიერ SOAP-ის ინსტრუმენტარიუმის ვებ სერვისების აღსაწერად.

WSDL 1.1, გამოშვებული 2001 წლის მარტში. სინამდვილეში, ეს არის ოფიციალური WSDL 1.0. ამ ვერსიებს შორის ფუნდამენტური განსხვავებები არ არსებობს.

WSDL 1.2 (2003 წლის ივნისი) ჯერ კიდევ მუშაობს W3C-ში. WSDL 1.2 არ არის მხარდაჭერილი SOAP მომწოდებლების უმეტესობის მიერ.

WSDL 2.0-მა მიიღო ოფიციალური მხარდაჭერა W3C-ისგან 2007 წლის ივნისში. WSDL 1.2 დაარქვეს WSDL 2.0, რადგან მას მნიშვნელოვანი განსხვავებები ჰქონდა წინა ვერსიისგან.

ვებ სერვისების დიზაინი

ავტორის მიერ ტერმინი ვებ სერვისების გამოყენება ეხება ექსკლუზიურად ტექნოლოგიის ტიპს, რომელიც ორიენტირებულია ურთიერთქმედებაზე. ეს ნიშნავს, რომ ეს ტექნოლოგია სტანდარტიზებულია: ჰეტეროგენული სისტემები მუშაობს მხოლოდ ღია სტანდარტების არსებობის შემთხვევაში. ამ შემთხვევაში, შესაბამისი კითხვაა: იქნება თუ არა ვებ სერვისები თქვენი პრობლემის გადაწყვეტა? დღეს სიტყვა „ვებ სერვისები“ აღარ არის საკმარისი იმისათვის, რომ ვისაუბროთ კომპანიის რეპუტაციაზე, რომელიც იყენებს მათ, ამიტომ უკეთესი იქნება მათი გამოყენების სხვა დამაჯერებელი მიზეზები. თუ თქვენ აკონტროლებთ არხის ორივე ბოლოს, შესაძლებელია უკეთესი ტექნოლოგიები არსებობდეს. ახლა მხოლოდ გარიჟრაჟია ღია სტანდარტების ეპოქის განაწილებული მონაცემთა დამუშავებისთვის. ამიტომ, ამ ჯერ კიდევ ჩამოუყალიბებელ ბაზარზე ვებ სერვისების მხარდაჭერის ღირებულება რჩება მაღალი - ეს ნიშნავს პროდუქტიულობის შემცირებას, განვითარების ხარჯების ზრდას და უსაფრთხოების გაუარესებას. იდეა, რომ ვებ სერვისები არის "firewall მეგობრული" არის შეცდომაში შემყვანი. მართლაც, ჩვეულებრივი firewalls იცავს კორპორატიულ აქტივებს თავდამსხმელებისგან, რომლებიც იყენებენ აპლიკაციის პროგრამულ სისუსტეებს, რომლებიც შექმნილია პორტების გახსნით, რომლებზეც დაცული სერვისები სრულდება. მეორეს მხრივ, ვებ სერვისები ამჟღავნებს აპლიკაციის პროგრამულ უზრუნველყოფას ამ პორტების მეშვეობით.

სხვა სიტყვებით რომ ვთქვათ, ისინი ასუსტებენ უსაფრთხოებას არასანქცირებული ადამიანების აპლიკაციებზე წვდომის მიცემით - ზუსტად ის, რის თავიდან ასაცილებლადაც იქნება შექმნილი ქსელის firewall. ამიტომ საჭიროა ახალი თაობის firewalls. ბაზარზე უკვე არის რამდენიმე ახალი მოთამაშე, რომლებიც ასეთ პროდუქტებს გვთავაზობენ. ჩვეულებრივი firewall-ის გამყიდველები ასევე იწყებენ ყურადღების მიქცევას ამ პრობლემაზე. მაგრამ ეს მხოლოდ დასაწყისია და ასეთმა ტექნოლოგიამ ჯერ კიდევ უნდა დაამტკიცოს თავისი თავი. მაშინაც კი, თუ თქვენ აპირებთ ვებ სერვისების გამოყენებას, უნდა გახსოვდეთ, რომ არ გჭირდებათ SOAP-ის გამოყენება. მაგალითად, ამ სტატიის ავტორს უნახავს ფორმები, რომლებიც გადაცემულია როგორც SOAP დისტანციური პროცედურის გამოძახების (SOAP-RPC) მოთხოვნის არგუმენტი. მან ასევე წააწყდა ფორმებს, რომლებიც დაბრუნდა SOAP დისტანციური პროცედურის ზარის საპასუხოდ. მან ვერასოდეს ვერ იპოვა რაიმე დამატებითი სარგებელი საპნის გამოყენებით. თუ განაწილებული კომპონენტები შეიძლება განვითარდეს სხვადასხვა პროგრამირების ენაზე, მაშინ საჭიროა პროგრამირების ენის ნეიტრალური ინტერფეისის განმარტების ენა (IDL), რათა დაზუსტდეს, თუ როგორ უნდა იქნას გამოყენებული სერვისები. ასეთი ენა აქვს CORBA-ს (Common Object Request Broker Architecture), ისევე როგორც DCOM-ს (Distributed Component Object Model). IDL არის კონტრაქტი სერვისის ინიციატორსა და პროვაიდერს შორის, მაგრამ ის მხოლოდ სინტაქსს აგროვებს. სემანტიკა გაურკვეველი რჩება: IDL ღიად ტოვებს კითხვას, რას აკეთებს სერვისი. WSDL არის ვებ სერვისების IDL. იგი აღწერს, თუ როგორ უნდა დარეკოთ ვებ სერვისები. ის ასევე განსაზღვრავს პასუხებს, რომლებიც შეიძლება მიღებულ იქნას ან არ მიიღოთ, როდესაც ზარი წარმატებულია.

WSDL სპეციფიკაცია მკაცრად არეგულირებს შეტყობინებების ფორმატს, გამოყენებულ პროტოკოლებს და მისამართს, სადაც მდებარეობს სერვისები. სამწუხაროდ, WSDL-ში მკაფიო და მკაცრი აღწერაც კი არ იძლევა მაღალი ხარისხის დიზაინის გარანტიას. ყველა IDL ენის მსგავსად, WSDL ძლიერია სინტაქსით და სუსტია სემანტიკაში. თუმცა, ისინი არ უნდა იყოს უგულებელყოფილი - საბოლოო ჯამში, ეს არის სემანტიკა, რომელიც მნიშვნელოვანია, ხოლო სინტაქსი გამოიყენება უბრალოდ მის გამოსავლენად.

ინტერფეისის დიზაინი

სანამ დაიწყებთ WSDL-ის წერას, თქვენ უნდა შეთანხმდეთ თქვენს კლიენტებთან, რა უნდა გააკეთოს ვებ სერვისმა. გამოყენების შემთხვევები უნდა ჩაიწეროს, ნათლად განისაზღვროს, თუ როგორ ურთიერთქმედებს სერვისი მის გარემოსთან. დავუშვათ, რომ აგენტის პროგრამა (მსახიობი) იძახებს ვებ სერვისს გარკვეული მიზნით. ამ შემთხვევაში, თქვენ უნდა შექმნათ არა მხოლოდ "მზიანი დღის" სცენარი, რომელიც ასრულებს დავალებას, არამედ "წვიმიანი დღის" სცენარი, როდესაც შედეგი უარყოფითია. რა გარანტიების შეთავაზება შეუძლია სისტემას, რომ მიზანი წარმატებით იქნა მიღწეული? და როდის არა? სად არის პასუხისმგებლობის ხაზი კლიენტსა და სერვერს შორის? მოთხოვნების მკაფიოდ განსაზღვრის მნიშვნელობა არ შეიძლება გადაჭარბებული იყოს. ამ ეტაპზე ღირს პროექტის მიზანზე ფიქრი. კონკრეტულად რა არის? რა მონაცემები უნდა მიიღოს კლიენტისგან და რა უნდა მიაწოდოს სერვერს? ამ ეტაპზე შეცდომის დაშვებამ შეიძლება გამოიწვიოს მნიშვნელოვანი ხარჯები. მაგალითად, განიხილეთ ვებ სერვისი, რომელიც პარამეტრებად იღებს დაინსტალირებული პროგრამების სიას და დისკზე თავისუფალი სივრცის რაოდენობას. შემდეგ ამ სერვისმა უნდა დააბრუნოს განახლებული აპლიკაციების სია.

თუ საკმარისი სივრცეა, პრობლემები არ არის. თუმცა, რა მოხდება, თუ ეს არ არის საკმარისი? როგორ ავირჩიო პროდუქტები, რომლებისთვისაც ახალი ვერსიების დაყენება მჭირდება? მოსალოდნელია თუ არა, რომ კლიენტი წაშლის პროგრამების ძველ ვერსიებს, რათა ადგილი ჰქონდეს ახალს? ეს არ არის იოლი კითხვები, რომელთა გადაწყვეტა მოითხოვს რთული ალგორითმების შემუშავებას, რომელთა განხორციელება შეიძლება შეცდომებს მოჰყვეს. რა თქმა უნდა, არც ერთი სისტემა არ უნდა იყოს განსაზღვრული ამ გზით. სერვერმა უნდა მიაწოდოს აპლიკაციების სია, მათ შორის დამოკიდებულებები და რესურსების მოთხოვნები. კლიენტის პასუხისმგებლობაა გადაწყვიტოს რომელი პაკეტი დააინსტალიროს. ამიტომ ამ დავალების სერვერზე მინდობით კლიენტი ვერაფერს მოიგებს, ეს მხოლოდ გაზრდის სერვერის ნაწილის შემუშავების ხარჯებს. ამრიგად, საწყის ეტაპზე აუცილებელია ხარჯების ანალიზის ჩატარება. ამ შემთხვევაში, თქვენ შეგიძლიათ უგულებელყოთ ტექნიკური დეტალები - სერვისი შეიძლება განიხილებოდეს როგორც შავი ყუთი. მაგრამ ჩვენ არ შეგვიძლია უგულებელვყოთ დეტალები ამ სერვისსა და მის გარემოს შორის ურთიერთქმედების შესახებ. შემდეგი ნაბიჯი არის იმის ანალიზი, თუ როგორ შეიძლება განხორციელდეს გამოყენების შემთხვევები.

იქნება თუ არა ერთი ინტერფეისი (portType WSDL ვერსიაში 1.1), რომელიც უზრუნველყოფს ყველა ფუნქციონირებას? ან მრავალი ინტერფეისი? თითოეული ინტერფეისი შეიძლება იყოს შემოთავაზებული რამდენიმე ბოლო წერტილზე, მაგრამ ზოგადად უნდა იყოს განუყოფელი. ანუ, საბოლოო წერტილი უნდა უზრუნველყოს ან მთელი ფუნქციონირება ან არაფერი. ანალოგიურად, ინტერფეისი უნდა იყოს სემანტიკურად თანმიმდევრული. ზემოთ მოყვანილი მიზანია იყოს სახელმძღვანელო და საღი აზრი, თუმცა WSDL სპეციფიკაციაში არაფერი უშლის ხელს განსხვავებულ ინტერპრეტაციას. საჭიროა რაიმე დამხმარე ინტერფეისი? როგორ და როდის უნდა გამოიძახონ? რა არის ამ დამოკიდებულების ბუნება? ჯერ არ არსებობს სტანდარტები, მხოლოდ რეკომენდაციები, თუ როგორ უნდა მოგვარდეს „მომსახურების ქორეოგრაფიები“, როგორ მივცეთ სერვისებს სხვა სერვისებთან ჰიპერბმულის მიცემა. სხვა სიტყვებით რომ ვთქვათ, ეს არის შეუსწავლელი პრობლემური სფერო.



გაქვთ შეკითხვები?

შეატყობინეთ შეცდომას

ტექსტი, რომელიც გაეგზავნება ჩვენს რედაქტორებს:

გაგზავნა