რა არის საპონი? რაც შეეხება IBM SOAP4J-ს
აქსესუარები 

რა არის საპონი? რაც შეეხება IBM SOAP4J-ს

ბრეტ მაკლაფლინი თარგმანი ილია ჩეკმენევი

SOAP არის მარტივი ობიექტზე წვდომის პროტოკოლი. თუ აქამდე არასოდეს გსმენიათ ამის შესახებ, მაშინ უნდა იცხოვროთ შუაგულში, ცივილიზაციისგან შორს. ის გახდა უახლესი მოდა ვებ პროგრამირებაში და ვებ სერვისების განუყოფელი ნაწილი, რომელიც ასეთი ფანატიზმით გამოიყენება უახლესი თაობის ვებ-განვითარებებში. თუ გსმენიათ Microsoft-ის .NET-ის ან Peer-to-peer "რევოლუციის" შესახებ, მაშინ გსმენიათ ტექნოლოგიების შესახებ, რომლებიც ეყრდნობა SOAP-ს (თუნდაც არ იცით რა არის ეს). არ არის ერთი, მაგრამ ორი SOAP-ის დანერგვა Apache-სა და Microsoft-ისგან, რომლებსაც აქვთ ათასობით გვერდი მიძღვნილი მათ MSDN-ის მხარდაჭერის საიტზე (http://msdn.microsoft.com/).

ამ სტატიაში მე გეტყვით რა არის SOAP და რატომ არის ის ასეთი მნიშვნელოვანი ნაწილი ვებ პროგრამირების პარადიგმის შემუშავებაში. ეს დაგეხმარებათ გამოტოვოთ საფუძვლები და პირდაპირ დაიწყოთ მუშაობა SOAP ინსტრუმენტთა ნაკრებით. შემდეგ მე მივცემ სწრაფ მიმოხილვას არსებული SOAP პროექტების შესახებ და ჩავუღრმავდები Apache-ს განხორციელებას. ეს სტატია არ არის გამიზნული SOAP-ის სრული სურათის შესაქმნელად; ჩემი წიგნი, Java & XML, 2nd Edition, ავსებს ბევრ ხარვეზს. ამ სტატიის წაკითხვის შემდეგ ბევრ კითხვაზე პასუხს ნახავთ წიგნში.

შესავალი

ჯერ უნდა გესმოდეთ რა არის საპონი. თქვენ შეგიძლიათ წაიკითხოთ სრული (და საკმაოდ გრძელი) W3C მოსაზრება http://www.w3.org/TR/SOAP. შემდეგ, როცა გაარკვიეთ და გადააგდეთ მთელი ქერქი, მიხვდებით, რომ SOAP მხოლოდ პროტოკოლია. ეს არის მარტივი პროტოკოლი (არ არის საჭირო ახლის დაწერა მის გამოსაყენებლად) დაფუძნებული იმ აზრზე, რომ განაწილებული არქიტექტურის რაღაც მომენტში არის საჭირო ინფორმაციის გაცვლა. გარდა ამისა, სისტემებისთვის, რომლებშიც არსებობს გადატვირთვისა და დამუშავების პროცესებში სირთულეების შესაძლებლობა, ეს პროტოკოლი ძალიან მომგებიანია იმით, რომ ის მსუბუქია და საჭიროებს რესურსების მინიმალურ რაოდენობას. დაბოლოს, ის საშუალებას აძლევს ყველა ოპერაციას განხორციელდეს HTTP-ზე, რაც შესაძლებელს ხდის გვერდის ავლით ისეთი რთული საკითხების, როგორიცაა firewalls და დაიცვა თავი პორტების წარმოუდგენელი რაოდენობის სოკეტების გამოყენებით მოსმენისგან. მთავარია ამას ხვდები და დანარჩენი ყველაფერი დეტალებია.

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

სურათი 12-1. SOAP შეტყობინების პროცესი

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

კონვერტი

საპნის კონვერტი ჩვეულებრივი ასოების კონვერტის მსგავსია. ის შეიცავს ინფორმაციას შეტყობინების შესახებ, რომელიც დაშიფრული იქნება SOAP-ის მთავარ განყოფილებაში, მათ შორის ინფორმაციას მიმღების და გამგზავნის შესახებ, ასევე ინფორმაციას თავად შეტყობინების შესახებ. მაგალითად, SOAP კონვერტის სათაურმა შეიძლება მიუთითოს, თუ როგორ უნდა დამუშავდეს შეტყობინება. სანამ აპლიკაცია დაიწყებს შეტყობინების დამუშავებას, ის იკვლევს ინფორმაციას შეტყობინების შესახებ, მათ შორის, შეუძლია თუ არა მას შეტყობინების დამუშავება საერთოდ. სტანდარტული XML-RPC ზარებისგან განსხვავებით (გახსოვთ? XML-RPC შეტყობინებები, დაშიფვრა და ა.შ., ყველაფერი გაერთიანებულია ერთ XML ფრაგმენტში), SOAP-ით მიმდინარეობს მიმდინარე დამუშავება, რათა გაიგოთ რაიმე შეტყობინების შესახებ. ტიპიური SOAP შეტყობინება შეიძლება ასევე შეიცავდეს დაშიფვრის სტილს, რომელიც დაეხმარება მიმღებს შეტყობინების დამუშავებაში. მაგალითი 12-1 გვიჩვენებს SOAP-ის კონვერტს, რომელიც მთავრდება კოდირების სპეციფიკაციით.

მაგალითი 12-1: საპნის კონვერტი

საპნის ყუთი http://www-106.ibm.com/developerworks/library/x-soapbx1.html

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

დაშიფვრა

SOAP-ის მეორე მნიშვნელოვანი ელემენტია პერსონალური მონაცემთა ტიპების დაშიფვრის შესაძლებლობა. RPC-ით (და XML-RPC) დაშიფვრა შეიძლება განხორციელდეს მხოლოდ წინასწარ განსაზღვრულ მონაცემთა ტიპებზე, რომლებიც მხარდაჭერილია თქვენ მიერ გადმოწერილი XML-RPC ინსტრუმენტთა ნაკრებით. სხვა ტიპის მონაცემების დაშიფვრა მოითხოვს თქვენ თავად შეცვალოთ RPC სერვერი და კლიენტი. SOAP-ით, XML სქემა შეიძლება გამოყენებულ იქნას საკმაოდ მარტივად მონაცემთა ახალი ტიპების დასაზუსტებლად (სტრუქტურის გამოყენებით კომპლექსური ტიპი, განხილული ჩემი წიგნის მე-2 თავში), და ეს ახალი ტიპები შეიძლება წარმოდგენილი იყოს XML-ში, როგორც SOAP-ის ძირითადი განყოფილების ნაწილი. XML Schema ინტეგრაციის წყალობით, თქვენ შეგიძლიათ დაშიფროთ ნებისმიერი ტიპის მონაცემი SOAP შეტყობინებაში მისი ლოგიკურად აღწერით XML Schema-ში.

დარეკეთ

საუკეთესო გზა იმის გასაგებად, თუ როგორ მუშაობს SOAP ზარი არის მისი შედარება თქვენთვის ნაცნობთან, როგორიცაა XML-RPC. თუ გახსოვთ, XML-RPC ზარი ჰგავს კოდის ნაწყვეტს, რომელიც წარმოდგენილია მაგალითში 12-2.

მაგალითი 12-2. დარეკეთ XML-RPC-ზე

// XML პროცესორის (პარსერის) დაზუსტება XmlRpc.setDriver("org.apache.xerces.parsers.SAXParser") გამოსაყენებლად); // სერვერის მითითება, რომელთანაც ხდება კავშირი XmlRpcClient client = new XmlRpcClient("http://rpc.middleearth.com"); // პარამეტრების შექმნა Vector params = new Vector(); params.addElement(flightNumber); params.addElement(numSeats); params.addElement(creditCardType); params.addElement(creditCardNum); // მოითხოვეთ Boolean buyTickets = (Boolean)client.execute("ticketCounter.buyTickets", params); // პასუხის დამუშავება

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

მაგალითი 12-3. ზარი SOAP-ზე

// პარამეტრების შექმნა Vector params = new Vector(); params.addElement(new Parameter("flightNumber", Integer.class, flightNumber, null)); params.addElement(new Parameter("numSeats", Integer.class, numSeats, null)); params.addElement(new Parameter("creditCardType", String.class, creditCardType, null)); params.addElement(new Parameter("creditCardNumber", Long.class, creditCardNum, null)); // Call ობიექტის შექმნა Call call = new Call(); call.setTargetObjectURI("urn:xmltoday-airline-tickets"); call.setMethodName("buyTickets"); call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC); call.setParams(params); // Call Response res = call.invoke(new URL("http://rpc.middleearth.com"), ""); // პასუხის დამუშავება

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

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

პარამეტრები

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

ამრიგად, ჩვენ შეუფერხებლად მივუახლოვდით ღია კოდის პროექტებს. ამ სფეროდან შემიძლია დავასახელო მხოლოდ ერთი პროდუქტი: Apache SOAP. ის მდებარეობს http://xml.apache.org/soap-ზე და გთავაზობთ SOAP-ის ინსტრუმენტარიუმს Java-სთვის. წერის დროს გამოვიდა ვერსია 2.2, რომელიც შეგიძლიათ ჩამოტვირთოთ Apache ვებსაიტიდან. სწორედ ამ ვერსიას გამოვიყენებ ამ სტატიის მაგალითებში.

სხვა ალტერნატივები

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

რაც შეეხება IBM SOAP4J-ს?

ალტერნატივების სიაში პირველი არის IBM-ის იმპლემენტაცია: SOAP4J. IBM-ის მუშაობამ საფუძველი ჩაუყარა Apache SOAP-ის პროექტს, ისევე როგორც IBM-ის XML4J გადაიზარდა ისეთად, რასაც დღეს უწოდებენ Apache Xerces XML პარსერის პროექტს. ვარაუდობენ, რომ IBM-ის იმპლემენტაცია ხელახლა შეიმუშავებს, Apache SOAP-თან შერწყმა. დაახლოებით იგივე მოხდა IBM-ის XML4J-თან დაკავშირებით: ახლა ის მხოლოდ Xerces-ში უზრუნველყოფს შეფუთვას. ეს მხოლოდ ხაზს უსვამს ტენდენციებს - მსხვილი მწარმოებლები ხშირად მხარს უჭერენ და იყენებენ OpenSource პროექტებს, ამ შემთხვევაში ორივე პროექტი (Apache და IBM) იყენებს იგივე კოდის ბაზას.

მაიკროსოფტი გამოსულია თამაშში?

Რათქმაუნდა, არა. მაიკროსოფტი და მისი SOAP დანერგვა, ისევე როგორც მთელი .NET მოძრაობა (უფრო დეტალურად განხილული ჩემს წიგნში), საკმაოდ მნიშვნელოვანია. ძალიან მინდოდა ჩემი დროის უმეტესი ნაწილი დამეხარჯა Microsoft-ის SOAP-ის დანერგვის დეტალურად, მაგრამ ის მხარს უჭერს მხოლოდ COM ობიექტებს და არ უჭერს მხარს Java-ს. ამ მიზეზების გამო, ასეთი აღწერილობა ვერ შედიოდა Java-სა და XML-ის შესახებ სტატიაში. თუმცა, მაიკროსოფტმა (მიუხედავად იმისა, რომ ჩვენ, როგორც დეველოპერებს, გვაქვს ამ კომპანიის მიმართ ყველა პრეტენზია) მნიშვნელოვანი სამუშაო შეასრულა ვებ სერვისების სფეროში და თქვენ შეცდომას დაუშვებთ, თუ მას დაუფიქრებლად, მხოლოდ უხეში ემოციებით ხელმძღვანელობთ. თუ თქვენ გჭირდებათ COM ან Visual Basic კომპონენტებთან მუშაობა, გირჩევთ გამოიყენოთ Microsoft SOAP ხელსაწყოთა ნაკრები, რომელიც ხელმისაწვდომია http://msdn.microsoft.com/library/default.asp?url=/nhp/Default .asp ?contentid=28000523 ბევრ სხვა SOAP რესურსთან ერთად.

რა არის აქსისი?

მათ, ვინც მიჰყვება Apache საქმიანობას, უნდა გსმენიათ Apache Axis-ის შესახებ. Axis არის შემდეგი თაობის SOAP ინსტრუმენტარიუმი, რომელიც ასევე შემუშავებულია Apache XML ქოლგის ქვეშ. SOAP (სპეციფიკაცია და არა კონკრეტული იმპლემენტაცია), რომელიც ბოლო დროს სწრაფად და რადიკალურად ვითარდებოდა, ძალიან რთული შესასრულებელია. ასევე საკმაოდ რთულია SOAP-ის ვერსიის შექმნის მცდელობა, რომელიც სრულად აკმაყოფილებს მიმდინარე მოთხოვნებს მათი განვითარებასთან ერთად. შედეგად, Apache SOAP-ის ამჟამინდელი ვერსია გთავაზობთ გადაწყვეტას, რომელიც შეზღუდულია მისი დიზაინით. მას შემდეგ რაც გადაწყვიტეს, რომ არ ღირდა არსებული ხელსაწყოს სრულად გადამუშავების მცდელობა, Apache-ს დეველოპერებმა დაიწყეს ახალი კოდის საფუძველზე პროექტის შექმნა. ასე დაიბადა აქსისი. SOAP-ის სახელიც შეიცვალა, ჯერ SOAP-დან XP-ზე და შემდეგ XMLP-ზე. შემდეგ ახალი SOAP-ის სახელიდან ამოიღეს სპეციფიკაციის სახელწოდება და სახელწოდება „აქსისი“ დაიბადა. მაგრამ ახლა, როგორც ჩანს, W3C უბრუნდება SOAP-ის სპეციფიკაციის სახელს (ვერსია 1.2 ან 2.0), ასე რომ, შესაძლოა ყველაფერი მაინც შეიცვალოს და კიდევ უფრო მეტი დაბნეულობა იყოს!

წარმოიდგინეთ IBM SOAP4J, როგორც SOAP ინსტრუმენტარიუმის არქიტექტურა?1. რაც შეეხება Apache SOAP-ს (განხილულია ამ სტატიაში) როგორც არქიტექტურაზე?2. და Axis წარმოადგენს ?3 არქიტექტურას, ახალი თაობის არქიტექტურას. ეს პროექტი იყენებს SAX-ს, ხოლო Apache SOAP დაფუძნებულია DOM-ზე. გარდა ამისა, Axis, განსხვავებით Apache SOAP-ისგან, უზრუნველყოფს მომხმარებლის ურთიერთქმედების უფრო მოსახერხებელი მიდგომას. ამ უპირატესობების ჩამოთვლის შემდეგ, შეიძლება გაინტერესებთ, რატომ არ ავირჩიე აქსისი ჩემს სასწავლო საგანად. უბრალოდ ცოტა ნაადრევი იქნებოდა. ამჟამად აქსისის მხოლოდ 0.51 ვერსია მზადდება გამოსაშვებად. ეს ჯერ არ არის ბეტა, ან თუნდაც ალფა ვერსია. მე მინდა ვისაუბრო Axis-ის ახალ ფუნქციებზე, მაგრამ თქვენ არ გექნებათ შანსი დაარწმუნოთ თქვენი მენეჯმენტი, რომ შეგიძლიათ გამოიყენოთ სუბ-ალფა ღია კოდის პროგრამული უზრუნველყოფა თქვენი კრიტიკული სისტემის საჭიროებებისთვის. ამიტომ გადავწყვიტე ფოკუსირება იმაზე, რაც შენ ნამდვილი ხარ შეგიძლია გამოიყენოუკვე დღეს- აპაჩის საპონი. ვფიქრობ, სანამ Apache Axis-ის საბოლოო ვერსია გამოვა, ამ მასალას ჩემი წიგნის მომდევნო გამოცემაში განვაახლებ. მანამდე კი, მოდით ფოკუსირება მოვახდინოთ უკვე ხელმისაწვდომ გადაწყვეტაზე.

ინსტალაცია

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

კლიენტი

SOAP კლიენტის გამოსაყენებლად, ჯერ უნდა ჩამოტვირთოთ Apache SOAP, რომელიც ხელმისაწვდომია http://xml.apache.org/dist/soap. მე გადმოვწერე ვერსია 2.2 ბინარულ ფორმატში (ქვედირექტორიიდან ვერსია-2.2). შემდეგ თქვენ უნდა გახსენით არქივის შიგთავსი თქვენს კომპიუტერში არსებულ დირექტორიაში. ჩემს შემთხვევაში ეს იყო დირექტორია javaxml2 (c:\javaxml2ჩემს ვინდოუს კომპიუტერზე /javaxml2ჩემს Mac OS X კომპიუტერზე). შედეგად, ფაილები გაიხსნა /javaxml2/soap-2_2. თქვენ ასევე დაგჭირდებათ JavaMail პაკეტის ჩამოტვირთვა, რომელიც ხელმისაწვდომია Sun-დან http://java.sun.com/products/javamail/. საჭირო იქნება SMTP გადაცემის პროტოკოლის მხარდაჭერა, რომელსაც იყენებს Apache SOAP. შემდეგ ჩამოტვირთეთ Java Beans Activation Framework (JAF), რომელიც ასევე ხელმისაწვდომია Sun-დან http://java.sun.com/products/beans/glasgow/jaf.html. ეფუძნება ვარაუდს, რომ თქვენ უკვე გაქვთ Xerces ან სხვა XML პარსერი დაინსტალირებული და გამოსაყენებლად მზად.

Შენიშვნა:დარწმუნდით, რომ თქვენი XML პარსერი შეესაბამება JAXP-ს და სწორად იყენებს სახელთა სივრცეს. თქვენი პარსერი, სავარაუდოდ, აკმაყოფილებს ამ მოთხოვნებს. თუ პრობლემები გაქვთ, უმჯობესია დაუბრუნდეთ Xerces-ის გამოყენებას.

Შენიშვნა:გამოიყენეთ Xerces-ის უახლესი ვერსიები. 1.4 და უფრო მაღალი ვერსია გამოდგება. SOAP-თან და Xerces 1.3(.1)-თან არის მრავალი შეცდომა, ამიტომ გირჩევთ არ გამოიყენოთ ეს კომბინაცია.

გახსენით JavaMail და JAF პაკეტები და შემდეგ ჩართეთ მათი jar ფაილები თქვენს კლასში, ისევე როგორც ბიბლიოთეკაში საპონი.ქილა. თითოეული ეს jar ფაილი უნდა განთავსდეს ან შესაბამისი პროგრამის root დირექტორიაში, ან ქვედირექტორიაში /lib. როდესაც დასრულდება თქვენი ცვლადი კლასის გზადაახლოებით ასე უნდა გამოიყურებოდეს:

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

Windows-ისთვის ეს ასე გამოიყურება:

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

და ბოლოს დაამატეთ დირექტორია javaxml2/soap-2_2/შენში კლასის გზა SOAP-ის მაგალითების გასაშვებად. მე აღვწერე დაყენება რამდენიმე მაგალითისთვის ამ თავში.

სერვერი

სერვერის კომპონენტების SOAP-თან თავსებადი ნაკრების შესაქმნელად, პირველ რიგში გჭირდებათ servlet ძრავა. როგორც წინა თავებში, ამ თავის მაგალითად გამოვიყენე Apache Tomcat (ხელმისაწვდომია http://jakarta.apache.org/). თქვენ უნდა დაამატოთ ყველაფერი, რაც კლიენტს სჭირდება კლასის გზასერვერი. ამის გაკეთების ყველაზე მარტივი გზაა გადატვირთვა საპონი.ქილა, გააქტიურება.jarდა ფოსტა.jar, ისევე როგორც თქვენი პარსერი, თქვენს servlet ძრავის ბიბლიოთეკების დირექტორიაში. Tomcat-ისთვის ეს არის /lib დირექტორია, რომელიც შეიცავს ბიბლიოთეკებს ავტომატური ჩატვირთვისთვის. თუ გსურთ სკრიპტების მხარდაჭერა (რომლებიც არ არის განხილული ამ თავში, მაგრამ არის Apache SOAP-ის მაგალითებში), თქვენ უნდა დააყენოთ bsf.jar(ხელმისაწვდომია http://oss.software.ibm.com/developerworks/projects/bsf) და js.jar(ხელმისაწვდომია http://www.mozilla.org/rhino/) იმავე დირექტორიაში.

Შენიშვნა:თუ იყენებთ Xerces-ს Tomcat-თან ერთად, თქვენ უნდა გაიმეოროთ ხრიკი, რომელიც მე-10 თავში განვიხილეთ. სახელის შეცვლა პარსერი.jarვ z_parser.jar, ა jaxp.jarვ z_jaxp.jarრომ დავრწმუნდეთ xerces.jarდა JAXP-ის ჩართული ვერსია იტვირთება ნებისმიერი სხვა პარსერზე ან JAXP-ის განხორციელებამდე.

შემდეგ გადატვირთეთ თქვენი servlet ძრავა, რის შემდეგაც მზად ხართ დაწეროთ SOAP სერვერის კომპონენტები.

Router Servlet და Admin Client

ძირითადი ოპერაციების გარდა, Apache SOAP მოიცავს როუტერის სერვლეტს და ასევე ადმინისტრატორ კლიენტს. მაშინაც კი, თუ თქვენ არ აპირებთ მათ გამოყენებას, გირჩევთ დააინსტალიროთ ისინი, რათა შეამოწმოთ, რომ SOAP სწორად არის დაინსტალირებული. ეს პროცესი დამოკიდებულია იმაზე, თუ რომელ სერვლეტ ძრავას იყენებთ, ამიტომ მე შევზღუდავ ინსტალაციის პროცესს Tomcat-ით. ინსტალაციის ინსტრუქციები ზოგიერთი სხვა servlet ძრავებისთვის შეგიძლიათ იხილოთ http://xml.apache.org/soap/docs/index.html.

Tomcat-ის ქვეშ ინსტალაცია ძალიან მარტივია: უბრალოდ აიღეთ ფაილი საპონი.ომიდირექტორიადან საპონი-2_2/ვებ აპებიდა ჩააგდე დირექტორიაში $TOMCAT_HOME/ვებ აპები- და ეს არის! ინსტალაციის შესამოწმებლად, შეიყვანეთ მისამართი თქვენს ბრაუზერში http://localhost:8080/soap/servlet/rpcrouter. თქვენ უნდა მიიღოთ მსგავსი პასუხი, როგორც ნაჩვენებია სურათზე 12-2.

სურათი 12-2. როუტერი RPC Servlet

მიუხედავად იმისა, რომ შეტყობინება, როგორც ჩანს, შეცდომის შეტყობინებაა, ის მიუთითებს, რომ ყველაფერი სწორად მუშაობს. თქვენ უნდა მიიღოთ იგივე პასუხი, თუ თქვენს ბრაუზერს მიუთითებთ ადმინისტრატორის კლიენტის მისამართზე: http://localhost:8080/soap/servlet/messagerouter.

სერვერისა და კლიენტის ტესტირების დასასრულებლად, დარწმუნდით, რომ სრულად დაიცავით ყველა ინსტრუქცია. შემდეგ გაუშვით შემდეგი Java კლასი, როგორც ეს ნაჩვენებია ქვემოთ, რათა მხარი დაუჭიროთ თქვენი servlet URL RPC როუტერის servlet-ისთვის:

C:\>java org.apache.soap.server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter list განლაგებული სერვისები:

თქვენ უნდა მიიღოთ სერვისების ცარიელი სია, როგორც ეს ნაჩვენებია ზემოთ. თუ რაიმე შეტყობინებებს მიიღებთ, გთხოვთ, გადახედოთ შესაძლო შეცდომების გრძელ სიას, ხელმისაწვდომია http://xml.apache.org/soap/docs/trouble/index.html. ეს არის ყველაზე ამომწურავი სია იმ პრობლემებისა, რომლებიც შეიძლება შეგხვდეთ. თუ თქვენ მიიღებთ ცარიელ სიას, ეს ნიშნავს, რომ დაყენება დასრულებულია და თქვენ მზად ხართ დაიწყოთ ამ თავში მოცემული მაგალითების ყურება.

Დავიწყოთ

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

  • არჩევა SOAP-RPC და SOAP შეტყობინებებს შორის;
  • SOAP სერვისზე წერა ან წვდომა;
  • SOAP კლიენტზე წერა ან წვდომა.

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

RPC თუ შეტყობინებები?

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

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

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

RPC სერვისი

ახლა, როცა ფორმალობა დასრულდა, დროა ვიმოქმედოთ. მოგეხსენებათ, RPC-ში დაგჭირდებათ კლასები, რომელთა მეთოდები შესრულდება დისტანციურად.

კოდის ფრაგმენტები

დავიწყებ სერვერის ზოგიერთი კოდის ფრაგმენტების ყურებით. ეს ფრაგმენტები არის კლასები მეთოდებით, რომლებიც შესრულებულია RPC კლიენტებისთვის. მაგალითებად გამოვიყენე ჩემი წიგნის კოდი. იმის ნაცვლად, რომ გამოვიყენო მარტივი კლასები, მე ავირჩიე უფრო რთული მაგალითი SOAP-ის შესაძლებლობების რაც შეიძლება ნათლად დემონსტრირებისთვის. ასე რომ, მე გამოვიყენე CD კლასი, როგორც მაგალითი. ჯერ განვსაზღვრავთ ელემენტს რუკათითოეული არასტანდარტული პარამეტრის ტიპისთვის. ატრიბუტისთვის კოდირების სტილი, ყოველ შემთხვევაში Apache SOAP 2.2-ში. თქვენ უნდა მიუთითოთ მნიშვნელობა http://schemas.xmlsoap.org/soap/encoding/. ამჟამად ეს არის ერთადერთი მხარდაჭერილი კოდირება. თქვენ უნდა მიუთითოთ სახელთა სივრცე მომხმარებლის მიერ განსაზღვრული ტიპისთვის და შემდეგ კლასის სახელი ამ ტიპის სახელთა სივრცის პრეფიქსით. ჩვენს შემთხვევაში, ამ მიზნებისათვის გამოვიყენე ფიქტიური სახელების სივრცე და მარტივი პრეფიქსი " x". შემდეგ ატრიბუტის გამოყენებით javaTypeდააყენეთ Java კლასის ნამდვილი სახელი (ამ შემთხვევაში - javaxml2.CD). და ბოლოს, კურალესილი ატრიბუტებით java2XMLClassNameდა xml2JavaClassName. მათი დახმარებით მითითებულია კლასი, რომელიც გარდაიქმნება Java-დან XML-ში და პირიქით. მე გამოვიყენე საოცრად მოსახერხებელი BeanSerializer კლასი, რომელიც ასევე შედის Apache SOAP-ში. თუ თქვენი მორგებული პარამეტრი JavaBean ფორმატშია, ეს სერიალიზატორი და დესერიალიზატორი გიხსნით საკუთარის დაწერისგან. თქვენ გჭირდებათ კლასი ნაგულისხმევი კონსტრუქტორით (გახსოვდეთ, CD კლასისთვის მე განვსაზღვრე მარტივი, უპარამეტრული კონსტრუქტორი) და გამოაქვეყნეთ ამ კლასის ყველა მონაცემი მეთოდების გამოყენებით. ნაკრებიXXXდა მიიღეთXXX. რადგან კლასი CDსრულყოფილად აკმაყოფილებს ყველა ამ მოთხოვნას, BeanSerializerმუშაობს იდეალურად.

Შენიშვნა:Რომელი კლასი CDაკმაყოფილებს მოთხოვნებს BeanSerializer. დიდი მნიშვნელობა არ აქვს. კლასების უმეტესობა ადვილად გარდაიქმნება ამ ფორმატში. ამიტომ, მე გირჩევთ, თავი აარიდოთ საკუთარი სერიალიზატორებისა და დესერიალიზატორების დაწერას. ეს არის დამატებითი თავის ტკივილი (არაფერი რთული, მაგრამ ძალიან მტკივნეული) და გირჩევთ დაზოგოთ თქვენი ენერგია და გამოიყენოთ ლობიოს კონვერტაცია თქვენს მორგებულ პარამეტრებში. ხშირ შემთხვევაში, ლობიოს კონვერტაციისთვის საჭიროა მხოლოდ ნაგულისხმევი კონსტრუქტორი (პარამეტრების გარეშე) თქვენს კლასში.

ახლა მოდით ხელახლა შევქმნათ ქილაშეიყვანეთ და ხელახლა დააინსტალირეთ ჩვენი სერვისი:

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

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

ახლა რჩება მხოლოდ კლიენტის შეცვლა ახალი კლასებისა და მეთოდების გამოსაყენებლად. მაგალითი 12-10 შეიცავს კლიენტის კლასის შეცვლილ ვერსიას CDAdder. მონიშნულია წინა ვერსიაში განხორციელებული ცვლილებები.

მაგალითი 12-10: განახლებული CDAdder კლასი

პაკეტი javaxml2; იმპორტი java.net.URL; იმპორტი java.util.Vector; იმპორტი org.apache.soap.Constants; იმპორტი org.apache.soap.Fault; იმპორტი org.apache.soap.SOAPException; იმპორტი org.apache.soap.encoding.SOAPMappingRegistry; იმპორტი org.apache.soap.encoding.soapenc.BeanSerializer;იმპორტი org.apache.soap.rpc.Call; იმპორტი org.apache.soap.rpc.Parameter; იმპორტი org.apache.soap.rpc.Response; იმპორტი org.apache.soap.util.xml.QName; საჯარო კლასის CDAdder( საჯარო ბათილი დამატება (URL url, სტრიქონის სათაური, სიმებიანი მხატვარი, სტრიქონის ლეიბლი) აგდებს SOAPException ( System.out.println("CD-ის დამატება სათაურით "" + სათაური + "" შემსრულებელი "" + მხატვარი + "" სტუდია " + ლეიბლი); CD cd = ახალი CD (სათაური, შემსრულებელი, ლეიბლი); // ზარის ობიექტის შექმნა Call Call call = new Call(); call.setSOAPMappingRegistry(რეგისტრი); call.setTargetObjectURI("urn:cd-catalog"); call.setMethodName("addCD"); call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC); // პარამეტრების დაყენება Vector params = new Vector(); params.addElement(new Parameter("cd", CD.class, cd, null)); call.setParams(params); // Invoke call Response პასუხის დამუშავება; პასუხი = call.invoke(url, ""); if (!response.generatedFault()) ( System.out.println("CD-ის დამატება წარმატებით დასრულდა."); ) else (Fault fault = response.getFault(); System.out.println(შეცდომა: " + fault.getFaultString ());)) საჯარო სტატიკური void main(string args) ( if (args.length != 4) ( System.out.println("თარგი: java javaxml2.CDAdder " + "\"[CD სათაური]\" \"[მუსიკოსის სახელი]\ " \"[სტუდიის CD]\""); დაბრუნება;) try ( // SOAP სერვერის URL, რომელთანაც დაკავშირება ხდება URL url = new URL(args); // მიიღეთ მნიშვნელობები ახალი CD სტრიქონის სათაურისთვის = args; სიმებიანი მხატვარი = არგსი; სიმებიანი ლეიბლი = args; // CD-ის დამატება CDAdder adder = new CDAdder(); adder.add(url, title, artist, label); ) catch (გამონაკლისი e) ( e.printStackTrace(); ) ) )

ერთადერთი მართლაც საინტერესო ცვლილება არის კლასის რუკებში CD:

// შეადგინეთ ეს ტიპი ისე, რომ მისი გამოყენება შესაძლებელი იყოს SOAP SOAPMappingRegistry registry = new SOAPMappingRegistry(); BeanSerializer serializer = new BeanSerializer(); registry.mapTypes(Constants.NS_URI_SOAP_ENC, new QName("urn:cd-catalog-demo", "cd"), CD.class, serializer, serializer);

ასე შეიძლება იყოს მომხმარებლის პარამეტრის კოდირება და გადაცემა ქსელში. მე უკვე გითხარით, როგორ კლასში BeanSerializerშეიძლება გამოყენებულ იქნას JavaBean ფორმატში პარამეტრების დასამუშავებლად, როგორიცაა კლასი CD. მე გამოვიყენე განლაგების აღმწერი, რომ ეს სერვერზე მიეთითებინა, თუმცა ახლა კლიენტს უნდა ვუთხრა, გამოიყენოს ეს სერიალიზატორი და დესერიალიზატორი. ამ ფუნქციას ასრულებს კლასი SOAPMappingRegistry. მეთოდი mapTypes()იღებს დაშიფრულ სტრიქონს (კიდევ ერთხელ, უმჯობესია გამოიყენოთ მუდმივი ამისათვის NS_URI_SOAP_ENC), და ინფორმაცია პარამეტრის ტიპის შესახებ, რომლისთვისაც უნდა იქნას გამოყენებული სპეციალური სერიალიზაცია. ჯერ მითითებულია QName. სწორედ ამიტომ გამოიყენებოდა უცნაური სახელთა სივრცე ჰოსტინგის აღმწერში. თქვენ უნდა მიუთითოთ იგივე URN აქ, ისევე როგორც ელემენტის ადგილობრივი სახელი (ამ მაგალითისთვის "CD"), შემდეგ Java ობიექტი. Კლასიკლასი, რომელიც იქნება სერიული ( CD.კლასი) და ბოლოს კლასის მაგალითი სერიალიზაციისა და დესერიალიზაციისთვის. ამ მაგალითისთვის, ორივე შემთხვევა მოიცავს მაგალითს BeanSerializer. მას შემდეგ რაც ყველა ეს პარამეტრი შეიყვანება რეესტრში, აცნობეთ ობიექტს დარეკეთმეთოდის გამოყენებით setSOAPMapping-Registry().

თქვენ შეგიძლიათ გაუშვათ ეს კლასი, როგორც ეს ადრე იყო ნაჩვენები, დაამატეთ CD და ყველაფერი უნდა იმუშაოს ისე, როგორც მოსალოდნელია:

C:\javaxml2\build>java javaxml2.CDAdder http://localhost:8080/soap/servlet/rpcrouter "Tony Rice" "Manzanita" "Sugar Hill"დისკის დამატება სათაურით "ტონი რაისი" Sugar Hill-ის "Manzanita"-ის მიერ წარმატებით დავამატე CD.

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

შენიშვნა: თქვენ შეგიძლიათ გადაწყვიტოთ ეს იმის გამო, რომ კლასი CDListerუშუალოდ არ ურთიერთქმედებს ობიექტთან CD(დაბრუნდა მეთოდით სია ()ტიპს აქვს მნიშვნელობა ჰეშტაბი), მაშინ არ გჭირდებათ რაიმე ცვლილებების შეტანა. თუმცა, დაბრუნდა კლასი ჰეშტაბიშეიცავს ობიექტის მაგალითებს CD. თუ SOAP-მა არ იცის როგორ მოახდინოს მათი დესერიალიზაცია, კლიენტი გაუშვებს შეცდომას. ამ შემთხვევაში, პრობლემის გადასაჭრელად თქვენ უნდა მიუთითოთ ობიექტში დარეკეთკოპირება SOAPMappingRegistry.

შეცდომების ეფექტური დამუშავება

ახლა, როდესაც თქვენ ნახეთ მორგებული ობიექტები და გააკეთეთ RPC ზარები და სხვა, ნება მომეცით ვისაუბრო ნაკლებად საინტერესო თემაზე: შეცდომების დამუშავება. ნებისმიერი ქსელის ტრანზაქციის დროს შეიძლება მრავალი მარცხი მოხდეს. სერვისი არ იწყება, სერვერზე არის შეცდომა, ობიექტის პოვნა შეუძლებელია, კლასები აკლია და ბევრი სხვა პრობლემა. აქამდე მე უბრალოდ ვიყენებდი მეთოდს fault.getString()შეცდომის შეტყობინებების გენერირება. მაგრამ ეს მეთოდი შეიძლება ყოველთვის არ იყოს სასარგებლო. მოქმედებაში რომ ნახოთ, გააუქმეთ კონსტრუქტორი CDCatalog:

საჯარო CDCatalog() ( //კატალოგი = new Hashtable(); // დირექტორიის შექმნა addCD(new CD("Nickel Creek", "Nickel Creek", "Sugar Hill")); addCD(ახალი CD("Let it Fall", "Sean Watkins", "Sugar Hill")); addCD(new CD("Aerial Boundaries", "Michael Hedges", "Windham Hill")); addCD(ახალი CD("Taproot", "Michael Hedges", "Windham Hill")); )

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

(gandalf)/javaxml2/build$ java javaxml2.CDLister http://localhost:8080/soap/servlet/rpcrouter იხილეთ მიმდინარე CD დირექტორია. შეცდომა: სამიზნე ობიექტის ამოხსნა შეუძლებელია: null

ეს საერთოდ არ არის ის ინფორმაცია, რომელიც დაგეხმარებათ შეცდომის იდენტიფიცირებასა და გამოსწორებაში. მიუხედავად ამისა, ჩარჩო უმკლავდება შეცდომების სწორად დამუშავებას. Გახსოვს DOMFaultListener, რომელიც თქვენ მიუთითეთ ელემენტის მნიშვნელობად faultListener? დადგა დრო, რომ ის თამაშში შევიდეს. ობიექტი დაბრუნდა შეცდომის შემთხვევაში ბრალიაშეიცავს DOM-ს (დოკუმენტის ობიექტის მოდელი) org.w3c.dom.Elementშეცდომის შესახებ დეტალური ინფორმაციით. ჯერ დაამატეთ იმპორტის გამოხატულება თქვენს საწყის კოდს java.util.Iterator:

იმპორტი java.net.URL; იმპორტი java.util.Enumeration; იმპორტი java.util.Hashtable; იმპორტი java.util.Iterator;იმპორტი java.util.Vector; იმპორტი org.apache.soap.Constants; იმპორტი org.apache.soap.Fault; იმპორტი org.apache.soap.SOAPException; იმპორტი org.apache.soap.encoding.SOAPMappingRegistry; იმპორტი org.apache.soap.encoding.soapenc.BeanSerializer; იმპორტი org.apache.soap.rpc.Call; იმპორტი org.apache.soap.rpc.Parameter; იმპორტი org.apache.soap.rpc.Response; იმპორტი org.apache.soap.util.xml.QName;

ახლა მოდით შევიტანოთ ცვლილებები list() მეთოდში შეცდომებთან დაკავშირებით:

if (!response.generatedFault()) ( პარამეტრი returnValue = answer.getReturnValue(); Hashtable კატალოგი = (Hashtable)returnValue.getValue(); Numeration e = catalog.keys(); while (e.hasMoreElements()) (სტრიქონი title = (String)e.nextElement(); CD cd = (CD)catalog.get(title); System.out.println(" "" + cd.getTitle() + "" შემსრულებელი " + cd.getArtist() + " studios " + cd.getLabel()); ) ) else (Fault fault = answer.getFault(); System.out.println("შეცდომა: " + fault.getFaultString()); ვექტორული ჩანაწერები = fault.getDetailEntries(); for (Iterator i = entries.iterator(); i.hasNext();) ( org.w3c.dom.Element ჩანაწერი = (org.w3c.dom.Element)i.next(); System.out.println(entry .getFirstChild().getNodeValue()); ) )

მეთოდის გამოყენება getDetailEntries ()თქვენ მიიღებთ წვდომას SOAP სერვისზე და პრობლემის მხარდაჭერის ნედლეული მონაცემთა სერვერზე. კოდი ხელახლა ამუშავებს მათ (როგორც წესი, მხოლოდ ერთი ელემენტია, მაგრამ ის მოითხოვს დიდ ყურადღებას) და წყვეტს DOM-ს ელემენტი, შეიცავს თითოეულ ჩანაწერში. არსებითად, აქ არის XML, რომლითაც მუშაობთ:

SOAP-ENV:Server.BadTargetObjectURI სამიზნის გადაჭრა შეუძლებელია: null ეს არის ის, რაც ჩვენ გვინდა!

სხვა სიტყვებით რომ ვთქვათ, Fault ობიექტი გაძლევთ წვდომას SOAP კონვერტის იმ ნაწილზე, რომელიც შეიცავს შეცდომებს. გარდა ამისა, Apache SOAP უზრუნველყოფს ჯავის სტეკის კვალს, როდესაც ხდება შეცდომები, რაც უზრუნველყოფს მათ გამოსწორებისთვის საჭირო დეტალურ ინფორმაციას. ელემენტის ჩაჭრა stackTraceდა ამობეჭდოთ კვანძის მნიშვნელობა ტექსტიამ ელემენტიდან თქვენს კლიენტს შეუძლია დაბეჭდოს სერვერის სტეკის კვალი. ამ ცვლილებების შედგენით და კლიენტის გადატვირთვით მიიღებთ შემდეგ შედეგს:

C:\javaxml2\build>java javaxml2.CDLister http://localhost:8080/soap/servlet/rpcr outer იხილეთ მიმდინარე CD დირექტორია. შეცდომა: ვერ ამოიხსნება target: null java.lang.NullPointerException javaxml2.CDCatalog.addCD(CDCatalog.java:24) javaxml2.CDCatalog-ში. (CDCatalog.java:14) java.lang.Class.newInstance0 (მშობლიური მეთოდი) java.lang.Class.newInstance-ში (Class.java:237)

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

  1. ბევრი საუბარია SOAP-ის გაშვებაზე სხვა პროტოკოლებზე, როგორიცაა SMTP (ან თუნდაც Jabber). SOAP სტანდარტი ამჟამად არ ითვალისწინებს ამას, მაგრამ მსგავსი შესაძლებლობები შეიძლება დაემატოს მომავალში. ამიტომ, ნუ გაგიკვირდებათ, თუ ამ თემაზე აქტიურ დისკუსიებს წააწყდებით.
  • სახელმძღვანელო

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

ვიმედოვნებ, რომ თემის წაკითხვის შემდეგ თქვენ შეძლებთ:

  • დაწერეთ ვებ აპლიკაციის საკუთარი სერვერის განხორციელება;
  • დაწერეთ ვებ აპლიკაციის საკუთარი კლიენტის განხორციელება;
  • დაწერეთ თქვენი ვებ სერვისის აღწერა (WSDL);
  • სერვერზე გაგზავნეთ იმავე ტიპის მონაცემების კლიენტის მასივები.
როგორც თქვენ ალბათ მიხვდით, მთელი ჯადოქრობა შესრულდება PHP-ის და ჩაშენებული SoapClient და SoapServer კლასების გამოყენებით. ჩვენი კურდღელი იქნება SMS შეტყობინებების გაგზავნის სერვისი.

1 პრობლემის განცხადება

1.1 საზღვრები

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

1.2 რა მონაცემებს შევცვლით?

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

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

შედეგად, მივიღებთ, რომ SMS შეტყობინების გასაგზავნად გვჭირდება შემდეგი მონაცემები:

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

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

  • TRUE – პაკეტმა წარმატებით მიაღწია სერვერს, გაიარა ავტორიზაცია და SMS პროვაიდერთან გაგზავნის რიგში
  • FALSE - ყველა სხვა შემთხვევაში

ეს ამთავრებს პრობლემის განცხადების აღწერას! და ბოლოს, მოდით გადავიდეთ სახალისო ნაწილზე - მოდით გაერკვნენ, რა უცნაური მხეცი არის ეს საპონი!

2 რა არის საპონი?

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

და დავიწყებ ჩემს ისტორიას იმით, რომ მონაცემთა გაცვლის ეს პროტოკოლი ეკუთვნის ეგრეთ წოდებულ RPC (Remote Procedure Call) პარადიგმაზე დაფუძნებულ პროტოკოლების ქვეჯგუფს, რომლის ანტიპოდია REST (Representational State Transfer). ამის შესახებ მეტი შეგიძლიათ წაიკითხოთ ვიკიპედიაზე; სტატიების ბმულები არის თემის ბოლოს. ამ სტატიებიდან ჩვენ უნდა გავიგოთ შემდეგი: „RPC მიდგომა საშუალებას იძლევა გამოიყენოს მცირე რაოდენობის ქსელური რესურსები დიდი რაოდენობით მეთოდებით და რთული პროტოკოლით. REST მიდგომით, მეთოდების რაოდენობა და პროტოკოლის სირთულე მკაცრად შეზღუდულია, რაც ნიშნავს, რომ ინდივიდუალური რესურსების რაოდენობა შეიძლება იყოს დიდი.” ანუ ჩვენთან მიმართებაში ეს ნიშნავს, რომ საიტზე RPC მიდგომის შემთხვევაში ყოველთვის იქნება ერთი შეყვანა (ბმული) სერვისზე და რა პროცედურა უნდა გამოვიძახოთ შემომავალი მონაცემების დასამუშავებლად, რომელსაც ჩვენ მონაცემებთან ერთად გადავცემთ, ხოლო REST მიდგომით ჩვენს საიტს აქვს მრავალი შეყვანა (ბმული), რომელთაგან თითოეული იღებს და ამუშავებს მხოლოდ გარკვეულ მონაცემებს. თუ ვინმემ კითხულობს იცის როგორ ახსნას განსხვავება ამ მიდგომებში კიდევ უფრო მარტივად, აუცილებლად დაწერეთ კომენტარებში!

შემდეგი, რაც უნდა ვიცოდეთ SOAP-ის შესახებ არის ის, რომ ეს პროტოკოლი იყენებს იგივე XML-ს, როგორც ტრანსპორტს, რაც ერთის მხრივ ძალიან კარგია, რადგან ჩვენი არსენალი დაუყოვნებლივ მოიცავს ამ მარკირების ენაზე დაფუძნებული ტექნოლოგიების სრულ ძალას, კერძოდ, XML-Schema - ენა XML დოკუმენტის სტრუქტურის აღწერისთვის (მადლობა Wikipedia!), რომელიც იძლევა სერვერის მიერ მიღებული მონაცემების ავტომატური ვალიდაციის საშუალებას. კლიენტებისგან.

ასე რომ, ახლა ჩვენ ვიცით, რომ SOAP არის პროტოკოლი, რომელიც გამოიყენება დისტანციური პროცედურის ზარების განსახორციელებლად და ის იყენებს XML-ს, როგორც ტრანსპორტს! თუ წაიკითხავთ სტატიას ვიკიპედიაში, იქიდანაც შეგიძლიათ გაიგოთ, რომ მისი გამოყენება შესაძლებელია ნებისმიერი აპლიკაციის დონის პროტოკოლზე და არა მხოლოდ HTTP-თან ერთად (სამწუხაროდ, ამ თემაში განვიხილავთ მხოლოდ SOAP-ს HTTP-ზე). და იცით რა მომწონს ყველაზე მეტად ამ ყველაფერში? თუ ვარაუდები არ არის, მაშინ მინიშნებას მოგცემ - SOAP!... მაინც არ არის გამოცნობები?... დარწმუნებული ხარ, რომ წაიკითხე სტატია ვიკიპედიაზე?... ზოგადად, აღარ გატანჯავ. ამიტომ, მე პირდაპირ პასუხზე გადავალ: ”SOAP (ინგლისური მარტივი ობიექტების წვდომის პროტოკოლიდან - მარტივი ოქმიობიექტებზე წვდომა; სპეციფიკაციამდე 1.2)". ამ სტრიქონში ყველაზე მნიშვნელოვანი რამ არის დახრილი! არ ვიცი, რა დასკვნა გამოიტანე ამ ყველაფრისგან, მაგრამ მე ვხედავ შემდეგს - რადგან ამ პროტოკოლს არანაირად არ შეიძლება ეწოდოს "მარტივი" (და როგორც ჩანს, w3-იც კი ეთანხმება ამას), მაშინ 1.2 ვერსიიდან მან რატომღაც შეწყვიტა გაშიფვრა. ! და იგი ცნობილი გახდა, როგორც SOAP, უბრალოდ SOAP, წერტილი.

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

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

WSDL შექმნილია იმისთვის, რომ ჩვენს კლიენტებს სერვერთან ნორმალური კომუნიკაციის საშუალება მისცეს. ამისათვის ფაილი გაფართოებით "*.wsdl" აღწერს შემდეგ ინფორმაციას:

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

3 XML-სქემის შესავალი

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

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

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

მე გთავაზობთ შორს არ წახვიდეთ და დაწეროთ XML სქემა ჩვენი SMS შეტყობინებისთვის! ქვემოთ მოცემულია SMS შეტყობინების xml აღწერა:

71239876543 სატესტო შეტყობინება 2013-07-20T12:00:00 12
ჩვენი რთული ტიპის დიაგრამა ასე გამოიყურება:


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

მე ვფიქრობ, რომ ელემენტების მნიშვნელობა " ელემენტი"და" კომპლექსური ტიპი"ყველაფერი მეტ-ნაკლებად გასაგები გახდა თქვენთვის, ამიტომ მათზე ყურადღებას აღარ გავამახვილებთ და პირდაპირ კომპოზიტორის ელემენტზე გადავიდეთ" თანმიმდევრობა" როდესაც ვიყენებთ კომპოზიტორის ელემენტს " თანმიმდევრობა„გაცნობებთ, რომ მასში შემავალი ელემენტები ყოველთვის უნდა იყოს განთავსებული დიაგრამაში მითითებული თანმიმდევრობით და ყველა მათგანი სავალდებულოა. მაგრამ არ დაიდარდოთ! XML სქემებში კიდევ ორი ​​კომპოზიტორის ელემენტია: " არჩევანი"და" ყველა" კომპოზიტორი " არჩევანი"აცხადებს, რომ უნდა იყოს მასში ჩამოთვლილი ერთ-ერთი ელემენტი და კომპოზიტორი" ყველა» – ჩამოთვლილი ელემენტების ნებისმიერი კომბინაცია.

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

71239876543 სატესტო შეტყობინება 1 2013-07-20T12:00:00 12 71239876543 სატესტო შეტყობინება N 2013-07-20T12:00:00 12
ასეთი რთული ტიპის დიაგრამა ასე გამოიყურება:


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

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

4 დაწერეთ თქვენი WSDL

გახსოვთ, რომ WSDL არის ჩვენი ვებ სერვისი? იმედია გახსოვთ! როგორც ჩვენ ვწერთ, ჩვენი პატარა ვებ სერვისი იმუშავებს მასზე. ამიტომ, გირჩევთ, არ აურიოთ.

ზოგადად, იმისათვის, რომ ჩვენთან ყველაფერი სწორად იმუშაოს, უნდა გადავიტანოთ WSDL ფაილი სწორი MIME ტიპის კლიენტზე. ამისათვის თქვენ უნდა დააკონფიგურიროთ თქვენი ვებ სერვერი შესაბამისად, კერძოდ, დააყენოთ MIME ტიპი ფაილებისთვის „*.wsdl“ გაფართოებით შემდეგ ხაზზე:

აპლიკაცია/wsdl+xml
მაგრამ პრაქტიკაში, მე ჩვეულებრივ ვუგზავნიდი HTTP სათაურს PHP-ის საშუალებით. ტექსტი/xml»:

Header("შინაარსის ტიპი: text/xml; charset=utf-8");
და ყველაფერი მშვენივრად მუშაობდა!

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

ვინაიდან WSDL არის XML, თქვენ უნდა დაწეროთ ამის შესახებ პირდაპირ პირველივე სტრიქონში. ფაილის root ელემენტს ყოველთვის უნდა ეწოდოს " განმარტებები»:


როგორც წესი, WSDL შედგება 4-5 ძირითადი ბლოკისგან. პირველივე ბლოკი არის ვებ სერვისის განმარტება ან, სხვა სიტყვებით რომ ვთქვათ, შესვლის წერტილი.


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

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

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


ამისათვის ის ჩამოთვლის რომელ ოპერაციებს და რა ფორმით დაერქმევა. იმათ. პორტისთვის" SmsServicePort"სავალდებულო განსაზღვრულია სახელწოდებით" SmsServiceBinding", რომელსაც აქვს ზარის ტიპი" rpcდა HTTP გამოიყენება როგორც გადაცემის პროტოკოლი. ამრიგად, ჩვენ აქ აღვნიშნეთ, რომ განვახორციელებთ RPC ზარს HTTP-ზე. ამის შემდეგ ჩვენ აღვწერთ რომელი პროცედურები ( ოპერაცია) მხარდაჭერილია ვებ სერვისში. ჩვენ მხარს დავუჭერთ მხოლოდ ერთ პროცედურას - ” SMS გაგზავნა" ამ პროცედურის მეშვეობით ჩვენი მშვენიერი შეტყობინებები გადაეგზავნება სერვერს! პროცედურის გამოცხადების შემდეგ აუცილებელია მიუთითოთ რა ფორმით მოხდება მონაცემების გადაცემა. ამ შემთხვევაში მითითებულია, რომ გამოყენებული იქნება სტანდარტული საპნის კონვერტები.

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


ამისათვის ჩვენ ვაზუსტებთ, რომ ჩვენი სავალდებულოა ტიპის " SmsServicePortType"და ელემენტში" პორტის ტიპი„იგივე ტიპის სახელწოდებით ჩვენ მივუთითებთ პროცედურების დაკავშირებას შეტყობინებებთან. ასე რომ, შემომავალ შეტყობინებას (კლიენტიდან სერვერამდე) დაერქმევა ” გაგზავნეთSmsRequest"და გამავალი (სერვერიდან კლიენტამდე)" sendSmsResponse" WSDL-ის ყველა სახელის მსგავსად, შემომავალი და გამავალი შეტყობინებების სახელები თვითნებურია.

ახლა ჩვენ თვითონ უნდა აღვწეროთ მესიჯები, ე.ი. შემომავალი და გამავალი:


ამისათვის ჩვენ ვამატებთ ელემენტებს " შეტყობინება"სახელებით" გაგზავნეთSmsRequest"და" sendSmsResponse"შესაბამისად. მათში ჩვენ აღვნიშნავთ, რომ შეყვანა უნდა იყოს კონვერტი, რომლის სტრუქტურა შეესაბამება მონაცემთა ტიპს. მოთხოვნა" რის შემდეგაც სერვერიდან ბრუნდება კონვერტი, რომელიც შეიცავს მონაცემთა ტიპს - ” პასუხი».

ახლა ჩვენ ცოტა რამ უნდა გავაკეთოთ - დავამატოთ ამ ტიპის აღწერა ჩვენს WSDL ფაილში! და როგორ ფიქრობთ, როგორ აღწერს WSDL შემომავალ და გამავალ მონაცემებს? მე ვფიქრობ, რომ თქვენ უკვე გაიგეთ ყველაფერი დიდი ხნის წინ და უთხარით საკუთარ თავს XML სქემების გამოყენებით! და თქვენ აბსოლუტურად მართალი იქნებით!


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

5 ჩვენი პირველი SOAP სერვერი

ადრე დავწერე, რომ PHP-ში SOAP სერვერის შესაქმნელად გამოვიყენებთ ჩაშენებულ SoapServer კლასს. იმისათვის, რომ ყველა შემდგომი მოქმედება განხორციელდეს ისევე, როგორც მე, თქვენ უნდა შეცვალოთ თქვენი PHP ოდნავ. კიდევ უფრო ზუსტად რომ ვთქვათ, თქვენ უნდა დარწმუნდეთ, რომ დაინსტალირებული გაქვთ „php-soap“ გაფართოება. უმჯობესია წაიკითხოთ როგორ დააინსტალიროთ იგი თქვენს ვებ სერვერზე ოფიციალურ PHP ვებსაიტზე (იხილეთ მითითებების სია).

ყველაფრის დაინსტალირებისა და კონფიგურაციის შემდეგ, ჩვენ უნდა შევქმნათ ფაილი თქვენი ჰოსტინგის root საქაღალდეში. smsservice.php» შემდეგი შინაარსით:

setClass ("SoapSmsGateWay"); //სერვერის დაწყება $server->handle();
იმედი მაქვს, არ არის საჭირო იმის ახსნა, თუ რა არის ხაზის ზემოთ "ini_set" ფუნქციით. იმიტომ რომ იქ დგინდება რომელ HTTP სათაურებს გავუგზავნით სერვერიდან კლიენტს და ხდება გარემოს კონფიგურაცია. „ini_set“-ის სტრიქონში ჩვენ ვთიშავთ WSDL ფაილის ქეშირებას, რათა მასში ჩვენი ცვლილებები დაუყოვნებლივ ამოქმედდეს კლიენტზე.

ახლა მოვედით სერვერზე! როგორც ხედავთ, მთელი SOAP სერვერი იღებს მხოლოდ სამ ხაზს! პირველ რიგში, ჩვენ ვქმნით SoapServer ობიექტის ახალ ინსტანციას და ვებ სერვისის ჩვენი WSDL აღწერილობის მისამართს გადავცემთ მის კონსტრუქტორს. ახლა ჩვენ ვიცით, რომ ის განთავსდება ჰოსტინგის ძირში, ფაილში, რომელსაც აქვს თვითახსნადი სახელი " smsservice.wsdl.php" მეორე სტრიქონში, ჩვენ ვეუბნებით SOAP სერვერს, რომელი კლასის ამოღება სჭირდება კლიენტისგან მიღებული კონვერტის დასამუშავებლად და პასუხთან ერთად კონვერტის დასაბრუნებლად. როგორც თქვენ ალბათ მიხვდით, სწორედ ამ კლასში იქნება აღწერილი ჩვენი ერთადერთი მეთოდი SMS გაგზავნა. მესამე ხაზზე ჩვენ ვიწყებთ სერვერს! ესე იგი, ჩვენი სერვერი მზად არის! რითაც ყველას გილოცავთ!

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

"; ?> /" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:http="http:// schemas.xmlsoap.org/wsdl/http/" name="SmsWsdl" xmlns="http://schemas.xmlsoap.org/wsdl/"> /"> /smsservice.php" />
ამ ეტაპზე, ჩვენ სრულიად კმაყოფილი უნდა ვიყოთ მიღებული სერვერით, რადგან ჩვენ შეგვიძლია ჩავწეროთ მასზე მომავალი კონვერტები და შემდეგ მშვიდად გავაანალიზოთ შემომავალი მონაცემები. იმისათვის, რომ სერვერზე რაიმე მივიღოთ, გვჭირდება კლიენტი. ასე რომ, მოდი მივაღწიოთ მას!

6 SOAP კლიენტი გზაში

პირველ რიგში, ჩვენ უნდა შევქმნათ ფაილი, რომელშიც დავწერთ კლიენტს. ჩვეულებისამებრ, ჩვენ შევქმნით მას ჰოსტის ძირში და ვუწოდებთ მას " კლიენტი.php“ და შიგნით დავწერთ შემდეგს:

messageList = new MessageList(); $req->messageList->message = new Message(); $req->messageList->message->phone = "79871234567"; $req->messageList->message->text = "სატესტო შეტყობინება 1"; $req->messageList->message->date = "2013-07-21T15:00:00.26"; $req->messageList->message->type = 15; $client = new SoapClient("http://($_SERVER["HTTP_HOST"])/smsservice.wsdl.php", მასივი ("soap_version" => SOAP_1_2)); var_dump($client->sendSms($req));
მოდით აღვწეროთ ჩვენი ობიექტები. როდესაც ჩვენ ვწერდით WSDL, ის აღწერდა სერვერზე შემოსული კონვერტის სამ ერთეულს: მოთხოვნა, შეტყობინებების სიადა შეტყობინება. შესაბამისად კლასები მოთხოვნა, შეტყობინებების სიადა შეტყობინებაარის ამ ერთეულების ასახვა ჩვენს PHP სკრიპტში.

როდესაც ჩვენ განვსაზღვრავთ ობიექტებს, ჩვენ უნდა შევქმნათ ობიექტი ( $req), რომელსაც ჩვენ გამოგიგზავნით სერვერზე. ამის შემდეგ მოდის ჩვენთვის ორი ყველაზე საყვარელი ხაზი! ჩვენი SOAP კლიენტი! გინდ დაიჯერეთ თუ არა, ეს საკმარისია იმისთვის, რომ ჩვენმა სერვერმა კლიენტისგან შეტყობინებების მიღება დაიწყოს, ასევე ჩვენმა სერვერმა წარმატებით მიიღოს და დაამუშავოს ისინი! პირველ მათგანში ვქმნით SoapClient კლასის ინსტანციას და გადავცემთ WSDL ფაილის ადგილმდებარეობის მისამართს მის კონსტრუქტორს, ხოლო პარამეტრებში ცალსახად მივუთითებთ, რომ ვიმუშავებთ SOAP პროტოკოლის 1.2 ვერსიის გამოყენებით. შემდეგ ხაზზე ჩვენ ვუწოდებთ მეთოდს SMS გაგზავნაობიექტი $კლიენტიდა დაუყოვნებლივ აჩვენეთ შედეგი ბრაუზერში.
მოდით გავუშვათ და ვნახოთ რა მივიღეთ საბოლოოდ!

შემდეგი ობიექტი დამიბრუნდა სერვერიდან:

Object(stdClass) public "status" => ლოგიკური true
და ეს შესანიშნავია, რადგან ... ახლა ჩვენ ზუსტად ვიცით, რომ ჩვენი სერვერი მუშაობს და არა მხოლოდ მუშაობს, არამედ შეუძლია კლიენტს დაუბრუნოს გარკვეული მნიშვნელობები!

ახლა მოდით შევხედოთ ჟურნალს, რომელსაც ჩვენ გონივრულად ვინახავთ სერვერის მხარეს! მის პირველ ნაწილში ჩვენ ვხედავთ სერვერზე მოსულ ნედლეულ მონაცემებს:

79871234567 სატესტო შეტყობინება 1 2013-07-21T15:00:00.26 15
ეს არის კონვერტი. ახლა თქვენ იცით, როგორ გამოიყურება! მაგრამ ნაკლებად სავარაუდოა, რომ ჩვენ დაინტერესებული ვიქნებით მისი გამუდმებით ყურებით, ასე რომ, მოდით გავაანალიზოთ ობიექტი log ფაილიდან და ვნახოთ ყველაფერი კარგადაა:

Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "სატესტო შეტყობინება 1 " (სიგრძე=37) საჯარო "თარიღი" => სტრიქონი "2013-07-21T15:00:00.26" (სიგრძე=22) საჯარო "ტიპი" => სტრიქონი "15" (სიგრძე=2)
როგორც ხედავთ ობიექტის დესერიალიზაცია მოხდა სწორად, რისთვისაც მინდა ყველას მოგილოცოთ! რაღაც უფრო საინტერესო გველოდება შემდეგში! კერძოდ, კლიენტს სერვერზე გავუგზავნით არა მხოლოდ ერთ SMS შეტყობინებას, არამედ მთელ პაკეტს (უფრო სწორად, სამს)!

7 რთული ობიექტების გაგზავნა

მოდით ვიფიქროთ იმაზე, თუ როგორ შეგვიძლია გადავიტანოთ მესიჯების მთელი თაიგული სერვერზე ერთ პაკეტში? ალბათ ყველაზე მარტივი გზა იქნება მასივის ორგანიზება messageList ელემენტის შიგნით! Მოდი გავაკეთოთ ეს:

// შექმენით ობიექტი სერვერზე გასაგზავნად $req = new Request(); $req->messageList = new MessageList(); $msg1 = new Message(); $msg1->phone = "79871234567"; $msg1->text = "სატესტო შეტყობინება 1"; $msg1->date = "2013-07-21T15:00:00.26"; $msg1->ტიპი = 15; $msg2 = new Message(); $msg2->phone = "79871234567"; $msg2->text = "სატესტო შეტყობინება 2"; $msg2->date = "2014-08-22T16:01:10"; $msg2->type = 16; $msg3 = new Message(); $msg3->phone = "79871234567"; $msg3->text = "სატესტო შეტყობინება 3"; $msg3->date = "2014-08-22T16:01:10"; $msg3->type = 17; $req->messageList-> message = $msg1; $req->messageList-> message = $msg2; $req->messageList->message = $msg3;
ჩვენი ჟურნალი მიუთითებს, რომ შემდეგი პაკეტი იქნა მიღებული კლიენტისგან:

79871234567 სატესტო შეტყობინება 1 2013-07-21T15:00:00.26 15 79871234567 სატესტო შეტყობინება 2 2014-08-22T16:01:10 16 79871234567 სატესტო შეტყობინება 3 2014-08-22T16:01:10 17
რა სისულელეა, შენ ამბობ? და გარკვეული გაგებით მართალი იქნებით, რადგან... როგორც კი გავიგეთ, რომ ობიექტმა დატოვა კლიენტი, ის ჩვენს სერვერზე მოვიდა აბსოლუტურად იგივე ფორმით, კონვერტის სახით. მართალია, SMS შეტყობინებები არ იყო სერიული XML-ში ისე, როგორც ჩვენ გვჭირდებოდა - ისინი უნდა შეფუთულიყო ელემენტებში შეტყობინება, არა შიგნით სტრუქტურა. ახლა ვნახოთ, რა ფორმით მოდის ასეთი ობიექტი მეთოდზე SMS გაგზავნა:

ობიექტი(stdClass) საჯარო "messageList" => ობიექტი(stdClass) საჯარო "მესიჯი" => ობიექტი (stdClass) საჯარო "სტრუქტურა" => მასივი (ზომა=3) 0 => ობიექტი (stdClass) საჯარო "ტელეფონი" => სტრიქონი "79871234567" (სიგრძე=11) საჯარო "ტექსტი" => სტრიქონი "სატესტო შეტყობინება 1" (სიგრძე=37) საჯარო "თარიღი" => სტრიქონი "2013-07-21T15:00:00.26" (სიგრძე=22) საჯარო " ტიპი" => სტრიქონი "15" (სიგრძე=2) 1 => ობიექტი(stdClass) საჯარო "ტელეფონი" => სტრიქონი "79871234567" (სიგრძე=11) საჯარო "ტექსტი" => სტრიქონი "სატესტო შეტყობინება 2" (სიგრძე= 37) საჯარო "თარიღი" => სტრიქონი "2014-08-22T16:01:10" (სიგრძე=19) საჯარო "ტიპი" => სტრიქონი "16" (სიგრძე=2) 2 => ობიექტი(stdClass) საჯარო "ტელეფონი" " => სტრიქონი "79871234567" (სიგრძე=11) საჯარო "ტექსტი" => სტრიქონი "სატესტო შეტყობინება 3" (სიგრძე=37) საჯარო "თარიღი" => სტრიქონი "2014-08-22T16:01:10" (სიგრძე= 19) საჯარო "type" => სტრიქონი "17" (სიგრძე = 2)
რას გვაძლევს ეს ცოდნა? მხოლოდ ის, რომ ჩვენ მიერ არჩეული გზა არ არის სწორი და არ მიგვიღია პასუხი კითხვაზე - "როგორ მივიღოთ მონაცემთა სწორი სტრუქტურა სერვერზე?" მაგრამ მე გირჩევთ, არ დაიდარდოთ და სცადოთ ჩვენი მასივის ტიპად გადაქცევა საგანი:

$req->messageList->message = (ობიექტი)$req->messageList->message;
ამ შემთხვევაში, ჩვენ მივიღებთ სხვა კონვერტს:

79871234567 სატესტო შეტყობინება 1 2013-07-21T15:00:00.26 15 79871234567 სატესტო შეტყობინება 2 2014-08-22T16:01:10 16 79871234567 სატესტო შეტყობინება 3 2014-08-22T16:01:10 17
მოვიდა მეთოდში SMS გაგზავნაობიექტს აქვს შემდეგი სტრუქტურა:

ობიექტი(stdClass) საჯარო "messageList" => ობიექტი(stdClass) საჯარო "მესიჯი" => ობიექტი(stdClass) საჯარო "BOGUS" => მასივი (ზომა=3) 0 => ობიექტი (stdClass) საჯარო "ტელეფონი" => სტრიქონი "79871234567" (სიგრძე=11) საჯარო "ტექსტი" => სტრიქონი "სატესტო შეტყობინება 1" (სიგრძე=37) საჯარო "თარიღი" => სტრიქონი "2013-07-21T15:00:00.26" (სიგრძე=22) საჯარო " ტიპი" => სტრიქონი "15" (სიგრძე=2) 1 => ობიექტი(stdClass) საჯარო "ტელეფონი" => სტრიქონი "79871234567" (სიგრძე=11) საჯარო "ტექსტი" => სტრიქონი "სატესტო შეტყობინება 2" (სიგრძე= 37) საჯარო "თარიღი" => სტრიქონი "2014-08-22T16:01:10" (სიგრძე=19) საჯარო "ტიპი" => სტრიქონი "16" (სიგრძე=2) 2 => ობიექტი(stdClass) საჯარო "ტელეფონი" " => სტრიქონი "79871234567" (სიგრძე=11) საჯარო "ტექსტი" => სტრიქონი "სატესტო შეტყობინება 3" (სიგრძე=37) საჯარო "თარიღი" => სტრიქონი "2014-08-22T16:01:10" (სიგრძე= 19) საჯარო "type" => სტრიქონი "17" (სიგრძე = 2)
რაც შემეხება მე, ტერმინების ადგილების შეცვლით თანხა არ იცვლება“ (გ). Რა ყალბი, Რა სტრუქტურა- ჩვენ ჯერ ვერ მივაღწიეთ ჩვენს მიზანს! და მის მისაღწევად, ჩვენ უნდა დავრწმუნდეთ, რომ ამ გაუგებარი სახელების ნაცვლად გამოსახულია ჩვენი მშობლიური შეტყობინება. მაგრამ ავტორმა ჯერ არ იცის როგორ მიაღწიოს ამას. აქედან გამომდინარე, ერთადერთი, რისი გაკეთებაც შეგვიძლია, არის ზედმეტი კონტეინერის მოშორება. სხვა სიტყვებით რომ ვთქვათ, ჩვენ ახლა დავრწმუნდებით, რომ ამის ნაცვლად შეტყობინებაგახდა ყალბი! ამისათვის შეცვალეთ ობიექტი შემდეგნაირად:

// შექმენით ობიექტი სერვერზე გასაგზავნად $req = new Request(); $msg1 = new Message(); $msg1->phone = "79871234567"; $msg1->text = "სატესტო შეტყობინება 1"; $msg1->date = "2013-07-21T15:00:00.26"; $msg1->ტიპი = 15; $msg2 = new Message(); $msg2->phone = "79871234567"; $msg2->text = "სატესტო შეტყობინება 2"; $msg2->date = "2014-08-22T16:01:10"; $msg2->type = 16; $msg3 = new Message(); $msg3->phone = "79871234567"; $msg3->text = "სატესტო შეტყობინება 3"; $msg3->date = "2014-08-22T16:01:10"; $msg3->type = 17; $req->messageList = $msg1; $req->messageList = $msg2; $req->messageList = $msg3; $req->messageList = (ობიექტი)$req->messageList;
რა მოხდება, თუ გაგვიმართლა და სწორი სახელი გამოვა დიაგრამიდან? ამისათვის გადავხედოთ ჩამოსულ კონვერტს:

79871234567 სატესტო შეტყობინება 1 2013-07-21T15:00:00.26 15 79871234567 სატესტო შეტყობინება 2 2014-08-22T16:01:10 16 79871234567 სატესტო შეტყობინება 3 2014-08-22T16:01:10 17
დიახ, სასწაული არ მომხდარა! ყალბი- ჩვენ არ გავიმარჯვებთ! მივიდა SMS გაგზავნაობიექტი ამ შემთხვევაში ასე გამოიყურება:

ობიექტი(stdClass) საჯარო "messageList" => ობიექტი(stdClass) საჯარო "BOGUS" => მასივი (ზომა=3) 0 => ობიექტი(stdClass) საჯარო "ტელეფონი" => სტრიქონი "79871234567" (სიგრძე=11) საჯარო " text" => სტრიქონი "სატესტო შეტყობინება 1" (სიგრძე=37) საჯარო "თარიღი" => სტრიქონი "2013-07-21T15:00:00.26" (სიგრძე=22) საჯარო "ტიპი" => სტრიქონი "15" (სიგრძე =2) 1 => ობიექტი (stdClass) საჯარო "ტელეფონი" => სტრიქონი "79871234567" (სიგრძე=11) საჯარო "ტექსტი" => სტრიქონი "სატესტო შეტყობინება 2" (სიგრძე=37) საჯარო "თარიღი" => სტრიქონი " 2014-08-22T16:01:10" (სიგრძე=19) საჯარო "ტიპი" => სტრიქონი "16" (სიგრძე=2) 2 => ობიექტი(stdClass) საჯარო "ტელეფონი" => სტრიქონი "79871234567" (სიგრძე= 11) საჯარო "ტექსტი" => სტრიქონი "სატესტო შეტყობინება 3" (სიგრძე=37) საჯარო "თარიღი" => სტრიქონი "2014-08-22T16:01:10" (სიგრძე=19) საჯარო "ტიპი" => სტრიქონი " 17" (სიგრძე = 2)
როგორც ამბობენ - "თითქმის"! ამ (ოდნავ სამწუხარო) ნოტაზე, მე ვთავაზობ ნელ-ნელა დავასრულოთ ყველაფერი და გამოვიტანოთ გარკვეული დასკვნები საკუთარი თავისთვის.

8 დასკვნა

ბოლოს აქ მოვედით! მოდით გავარკვიოთ, რა შეგიძლიათ გააკეთოთ ახლა:
  • შეგიძლიათ დაწეროთ თქვენი ვებ სერვისისთვის საჭირო WSDL ფაილი;
  • თქვენ შეგიძლიათ მარტივად დაწეროთ თქვენი საკუთარი კლიენტი, რომელსაც შეუძლია სერვერთან კომუნიკაცია SOAP-ის საშუალებით;
  • შეგიძლიათ დაწეროთ თქვენი საკუთარი სერვერი, რომელიც ურთიერთობს გარე სამყაროსთან SOAP-ის საშუალებით;
  • თქვენ შეგიძლიათ გაგზავნოთ იმავე ტიპის ობიექტების მასივები სერვერზე თქვენი კლიენტისგან (გარკვეული შეზღუდვებით).
ჩვენ ასევე გავაკეთეთ რამდენიმე აღმოჩენა ჩვენი პატარა კვლევის დროს:
  • მშობლიური SoapClient კლასი არ ახდენს XML-ში იმავე ტიპის მონაცემთა სტრუქტურების სწორად სერიულიზაციას;
  • მასივის XML-ზე სერიულირებისას ის ქმნის დამატებით ელემენტს, რომელსაც ეწოდება სტრუქტურა;
  • ობიექტის XML-ზე სერიულირებისას ის ქმნის დამატებით ელემენტს, რომელსაც ე.წ ყალბი;
  • ყალბინაკლები ბოროტება ვიდრე სტრუქტურაიმის გამო, რომ კონვერტი უფრო კომპაქტურია (კონვერტის XML სათაურს დამატებითი სახელების სივრცე არ ემატება);
  • სამწუხაროდ, SoapServer კლასი ავტომატურად არ ამოწმებს კონვერტის მონაცემებს ჩვენი XML სქემით (შესაძლოა სხვა სერვერებიც არ აკეთებენ ამას).

მე არ შევჩერდები კითხვაზე, თუ რა არის ეს ვებ სერვისებიდა რატომ არის ისინი საჭირო. ამ თემაზე ინტერნეტში უამრავი სტატიაა. მე უბრალოდ შევეცდები მოკლედ ვაჩვენო, რამდენად მარტივია კლიენტის შექმნა ნებისმიერი ვებ სერვისისთვის PHP-ში.

პარამეტრები

Გამოყენებისთვის საპონი php-ში თქვენ უნდა დააკავშიროთ SOAP მოდული (შედის php5 დისტრიბუციაში). Windows-ის პირობებში, ეს კეთდება უბრალოდ - თქვენ უნდა დაამატოთ (კერძოდ დაამატოთ, რადგან ეს სტრიქონი უბრალოდ არ არის კომენტირებული, ის საერთოდ აკლია) php.ini:
extension=php_soap.dll

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


SOAP კლიენტის შექმნა WSDL დოკუმენტიდან

SOAP კლიენტის შექმნა ჩვეულებრივ ხდება WSDL დოკუმენტი, რომელიც არის XML დოკუმენტი კონკრეტულ ფორმატში, რომელიც სრულად აღწერს კონკრეტულ ვებ სერვისს. WSDL-ის შესახებ დეტალებისთვის მე მოგმართავთ W3C კონსორციუმის ვებსაიტზე - http://www.w3.org/TR/2005/WD-wsdl20-soap11-binding-20050510/.

მთავარი, რაც თქვენ უნდა იცოდეთ ვებ სერვისისთვის კლიენტის შესაქმნელად არის მისი WSDL დოკუმენტის URL-ის ცოდნა.
მაგალითად, ავიღოთ "ვალუტის გაცვლის კურსი" ვებ სერვისი xmethods.com-დან. ამ ვებ სერვისის მისამართი, რომელიც საშუალებას გაძლევთ მიიღოთ გაცვლითი კურსი ონლაინ რეჟიმში, არის http://www.xmethods.net/sd/2001/CurrencyExchangeService.wsdl.

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

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

// ვებ სერვისის გამოყენება
// "ვალუტის გაცვლის კურსი" xmethods.com-დან

// SOAP კლიენტის შექმნა WSDL დოკუმენტიდან
$client = new SoapClient ("http://www.xmethods.net/sd/2001/CurrencyExchangeService.wsdl");

// გაგზავნეთ SOAP მოთხოვნა და მიიღეთ შედეგი
$result = $client->getRate("us", "russia");

ექო 'დოლარის მიმდინარე კურსი: ', $ შედეგი, ' რუბლი';
?>

როგორც კოდიდან ხედავთ, თქვენ უნდა გადასცეთ WSDL დოკუმენტის URL SoapClient კლასის კონსტრუქტორს და მიიღოთ ობიექტი სასურველ ვებ სერვისთან მუშაობისთვის. შემდეგ იწოდება ამ ობიექტის მეთოდი, რომლის სახელი იგივეა, რაც თავად ვებ სერვისის მეთოდის სახელი. ეს მეთოდი აბრუნებს ჩვენ სასურველ შედეგს.

ასე რომ, ეს მარტივი მაგალითი ასახავს PHP-ში ვებ სერვისებისთვის SOAP კლიენტის აგების პრინციპს. თუმცა, რეალურ აპლიკაციაში ჯერ კიდევ ბევრია ზრუნვა, განსაკუთრებით ის ფაქტი, რომ ვებ სერვისის გამოძახებისას ის შეიძლება დროებით მიუწვდომელი იყოს ან დაბრუნდეს შეცდომა. აშკარად გვთავაზობს ბლოკის გამოყენებას ცდა/დაჭერა/გასროლა :)

აქ LeaseWeb-ში ჩვენ ბევრს ვმუშაობთ SOAP ვებ სერვისებთან ჩვენი შიდა აპლიკაციების ერთმანეთთან ინტეგრირებისთვის. განსაკუთრებით ჩვენი აპლიკაციების შემუშავებისა და ტესტირების დროს, რადგან გვჭირდება SOAP API-ების პრაქტიკის უნარი.

$ curl -sS http://leaseweb.github.io/php-soap-client/installer | php

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

$ ./soap_client

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

# დააინსტალირეთ php საპნის კლიენტი $ git clone https://github.com/LeaseWeb/php-soap-client.git $ cd php-soap-client $ composer.phar install $ make $ sudo make install

თუ თქვენ იღებთ Failed to compile phar გამონაკლისს გაშვებისას, თქვენ უნდა დააყენოთ phar.readonly = Off თქვენს php.ini-ში. დეველოპერულ მანქანაზე ამის გაკეთება კარგია, მაგრამ გთხოვთ გაითვალისწინოთ უსაფრთხოების რისკები phar.readonly-ზე გამორთვის დაყენებისას.

ზემოაღნიშნული make install ბრძანება დააინსტალირებს soap_client აპლიკაციას /usr/local/bin და გახდის მას შესრულებადი, ასე რომ თქვენ შეგიძლიათ მარტივად დარეკოთ ასე:

$ soap_client php-soap-client ვერსია 2.1.3 გამოყენება: ბრძანება პარამეტრები: ... ხელმისაწვდომი ბრძანებები: გამოძახება დარეკეთ დისტანციურ სერვისზე მითითებული `მეთოდით` და გამოიტანეთ პასუხი stdout-ზე. დახმარება ბრძანებების სიის დახმარების ჩვენება. ბრძანებების სია-მეთოდები მიიღეთ ხელმისაწვდომი მეთოდების სია დისტანციურზე გამოსაძახებლად. მოთხოვნა შექმენით xml ფორმატირებული SOAP მოთხოვნა მოცემული მეთოდისთვის და გამომავალი stdout-ში. wsdl მიიღეთ საპნის სერვისის WSDL.

ამ მომენტიდან ჩვენ ვვარაუდობთ, რომ თქვენ დააინსტალირეთ soap_client.phar თქვენს სისტემაზე /usr/local/bin/soap_client-ში და რომ დირექტორია /urs/local/bin არის თქვენს $PATH-ში.

ვთქვათ, გვინდა ვნახოთ, რა მეთოდებია ხელმისაწვდომი დისტანციურ სერვისზე http://www.webservicex.net/ConvertTemperature.asmx. ჩვენ შეგვიძლია გამოვცეთ შემდეგი ბრძანება:

$ soap_client --endpoint="http://www.webservicex.net/ConvertTemperature.asmx?WSDL" სიის მეთოდები

რომელიც გამოსცემს შემდეგს:

ConvertTemp

თუ ზემოხსენებულ ბრძანებას -vvv ოფციით გაუშვით, უფრო ვრცელ გამომავალს მიიღებთ.
ამ შემთხვევაში ერთადერთი ხელმისაწვდომი მეთოდია ConvertTemp. ვნახოთ, როგორ გამოიყურება SOAP XML მოთხოვნა ამ მეთოდისთვის:

$ soap_client --endpoint="http://www.webservicex.net/ConvertTemperature.asmx?WSDL" მოთხოვნა ConvertTemp 0

თუ გსურთ SOAP-ის მოთხოვნა დისტანციურ სერვისზე ConvertTemp მეთოდზე, გამოიყენეთ ზარის ქვე ბრძანება:

$ soap_client --endpoint="http://www.webservicex.net/ConvertTemperature.asmx?WSDL" ზარი --რედაქტორი ConvertTemp

დააკვირდით --editor ოფციას ზარის ქვე ბრძანების შემდეგ. თუ იყენებთ --editor დროშას soap_client გახსნის თქვენი გარემოს $EDITOR ცვლადში მითითებულ რედაქტორს, ასე რომ თქვენ შეძლებთ შეცვალოთ მოთხოვნა XML გაგზავნამდე.

თუ ერთსა და იმავე მოთხოვნას რამდენჯერმე გასცემთ, შეგიძლიათ შეინახოთ საპნის მოთხოვნა ადგილობრივ XML ფაილად და გადასცეთ იგი /dev/stdin soap_client გამოძახების ბრძანებაში:

# მიიღეთ მოთხოვნა xml და შეინახეთ იგი ადგილობრივად $ soap_client --endpoint="http://www.webservicex.net/ConvertTemperature.asmx?WSDL" მოთხოვნა ConvertTemp > my_sample_request.xml # ახლა შეცვალეთ my_sample_request.xml # ახლა შეგიძლიათ დარეკოთ ConvertTemp მეთოდი ამ წინასწარ მომზადებული მოთხოვნით $ soap_client --endpoint="http://www.webservicex.net/ConvertTemperature.asmx?WSDL" ზარი ConvertTemp< my_sample_request.xml

იმის გამო, რომ მოკლე დროში ხშირად იმეორებთ soap_client ბრძანებებს დისტანციური ვებ სერვისის შესწავლისას, შეგიძლიათ დაზოგოთ დრო SOAPCLIENT_ENDPOINT გარემოს ცვლადის დაყენებით, რომელიც შეიცავს WSDL-ის URL-ს. როდესაც ეს გარემო ცვლადი დაყენებულია, შეგიძლიათ გამოტოვოთ --endpoint ბრძანების ხაზის ვარიანტი. მოდით გავაკეთოთ ეს ახლა და მოვუწოდებთ ConvertTemp მეთოდს:

$ ექსპორტი SOAPCLIENT_ENDPOINT="http://www.webservicex.net/ConvertTemperature.asmx?WSDL" $ soap_client ზარი ConvertTemp< my_sample_request.xml

მინდოდა მცოდნოდა რამდენია 107,6 გრადუსი ფარენჰეიტი ცელსიუსში, ამიტომ ჩემი my_sample_request.xml შეიცავს:

$ cat my_sample_request.xml 107.6 ფარენჰეიტის ხარისხი გრადუსი ცელსიუსით

$ soap_client დარეკეთ ConvertTemp< my_sample_request.xml stdClass Object ( => 42)

პასუხი არის 42.

თუ თქვენ ხედავთ პასუხებს XML ფორმატში, შეგიძლიათ გამოიყენოთ --xml ბრძანების ხაზის ვარიანტი:

$ soap_client ზარი --xml ConvertTemp< my_sample_request.xml 42

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

ლირიკული ნაწილი.

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

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

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

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

პრაქტიკული ნაწილი.

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

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

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

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

რა უპირატესობა აქვს ყველა ამ ზარს და სასტვენს:

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

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

    NewUser:=TSoapUser.Create("Vasya","Pupkin","admin"); საპონი.AddUser(NewUser);

  • ავტომატური ვალიდაცია.

    • xml ვალიდაცია. xml კარგად უნდა იყოს ჩამოყალიბებული. არასწორი xml - დაუყონებლივ შეცდომა კლიენტს, ნება მიეცით დაალაგოს.
    • სქემა-ვალიდაცია. xml უნდა ჰქონდეს გარკვეული სტრუქტურა. xml არ ემთხვევა სქემას - დაუყოვნებლივ შეცდომა კლიენტს, მიეცით მას დალაგება.
    • მონაცემთა გადამოწმება ხორციელდება საპნის სერვერის მიერ, რათა მონაცემთა ტიპები და შეზღუდვები ემთხვეოდეს აღწერილობას.
  • ავტორიზაცია და ავთენტიფიკაცია შეიძლება განხორციელდეს ცალკე მეთოდის გამოყენებით. მშობლიურად. ან http ავტორიზაციის გამოყენებით.
  • ვებ სერვისებს შეუძლიათ იმუშაონ როგორც საპნის პროტოკოლით, ასევე http-ის საშუალებით, ანუ მისაღებად მოთხოვნების საშუალებით. ანუ, თუ პარამეტრები მარტივი მონაცემებია (სტრუქტურის გარეშე), მაშინ შეგიძლიათ უბრალოდ დარეკოთ ჩვეულებრივი მიიღეთ www.site.com/users.asmx/GetUser?Name=Vasia ან პოსტი. თუმცა, ეს არ არის ყველგან და არა ყოველთვის.
  • ... იხილეთ ვიკიპედიაში

ასევე ბევრი უარყოფითი მხარეა:

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

მაგალითად, არის ღია ვებ სერვისი:

  • http://86.57.245.235/TimeTable/Service.asmx - შესვლის წერტილი, ასევე არსებობს მეთოდების ტექსტური აღწერა მესამე მხარის დეველოპერებისთვის.
  • http://86.57.245.235/TimeTable/Service.asmx?WSDL - მიღებული და დაბრუნებული მონაცემების მეთოდებისა და ტიპების wsdl აღწერა.
  • http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - კონკრეტული მეთოდის აღწერა xml მოთხოვნის ტიპისა და xml პასუხის მაგალითით.

თქვენ შეგიძლიათ ხელით შექმნათ და გაგზავნოთ მოთხოვნა, როგორიცაა:

POST /TimeTable/Service.asmx HTTP/1.1 ჰოსტი: 86.57.245.235 კონტენტის ტიპი: text/xml; charset=utf-8 კონტენტი-სიგრძე: სიგრძე SOAPAction: "http://webservices.belavia.by/GetAirportsList" ru

პასუხი მოვა:

HTTP/1.1 200 OK თარიღი: ორშაბათი, 30 სექტემბერი 2013 00:06:44 GMT სერვერი: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-ვერსია: 4.0.30319 Cache-Control: კერძო, მაქს. -age=0 Content-Type: text/xml; charset=utf-8 კონტენტი-სიგრძე: 2940

PS ადრე აეროფლოტის ვებ სერვისი გაიხსნა, მაგრამ მას შემდეგ, რაც 1C-მა დაამატა საპნის მხარდაჭერა 8ku-ზე, 1C ბეტა ტესტერების ჯგუფმა წარმატებით დააინსტალირა იგი. ახლა იქ რაღაც შეიცვალა (მისამართი არ ვიცი, თუ დაგაინტერესებთ შეგიძლიათ მოძებნოთ).
ZZY პასუხისმგებლობის უარყოფა. ის საუბრობდა ყოველდღიურ დონეზე. შეგიძლია დაარტყა.

დათვალიერება


შეიძლება თქვენც მოგეწონოთ

მოკლე მანძილზე ნავიგაციის რადიო საინჟინრო სისტემები

მოკლე მანძილზე ნავიგაციის რადიო საინჟინრო სისტემები

0
ვერტმფრენი გრძელვადიანი სამშენებლო თაობიდან

ვერტმფრენი გრძელვადიანი სამშენებლო თაობიდან

0
Realtek HD Audio-ს უფასო ვერსიის მიმოხილვა

Realtek HD Audio-ს უფასო ვერსიის მიმოხილვა

0