A szappan könnyű

előző ◈ a következő

Furcsa módon, de a SOAP (S végrehaj O bject A ccess P kiegészítő jegyzőkönyvét cross-platform, cross-language technológia indítási objektumok ..) - ez nagyon könnyű, de amikor elkezdtem dolgozni vele Delphi. nem tudta kideríteni, hogy melyik oldalon kell megközelítenie. Valójában a SOAP alkalmazások tervezésénél nagyon kevés feltételnek kell teljesülnie, amelyek után minden rendben lesz, és itt megpróbálom megfontolni ezeket az egyszerű feltételeket.

Először is, miért szükséges ez a SOAP? Két fő előnye van: a SOAP az interprogram kommunikáció általános színvonala, és a kliensnek nem kell tudnia semmit a szerverről - sem a nyelvéről, sem a platformról; A SOAP interfészek önmaguk dokumentáló jellegűek. a kiszolgálónak részletes információt kell adnia az ügyfélnek az interfészről, annak funkcióiról, bemeneti és kimeneti paramétereiről.

A SOAP programozásának fő feltétele: a szervernek hontalannak kell lennie. azaz a lekérdezés eredménye nem függhet a szerver által kapott korábbi parancsoktól. Ez azt jelenti, hogy az összes munkamenet paramétert az ügyfélen kell tárolni, és a kérelem részeként továbbítani kell a kiszolgálónak (ha szükséges). Ez biztosítja a rendszer stabilitását és skálázhatóságát (az ügyfelet egy másik kiszolgálóra át lehet váltani anélkül, hogy észrevehetné azt), bár a szokásos kétlinkű rendszer számos finomsága nem lesz elérhető:

  • Ön nem kezelheti kifejezetten tranzakciókat az ügyfélről (ez a kiszolgáló),
  • ezért nem lehet lezárni a rekordot a szerkesztési időhöz (kivéve, ha speciális mezőt jelző zászlókat hoz létre az adatbázisban)
  • Lehetetlen lehet paramétereket egy parancs segítségével átvinni, és egy másik pedig megvizsgálni az eredményt - mindennek ugyanabban a parancsban kell történnie
  • A mesterrész klasszikus csomópontjával nem tud dolgozni (azonban a TClientDataset kiváló eszköz erre: beágyazott adatkészletek - beágyazott táblák),
  • Nem használható a ClientDataSet.PacketRecords> 0 tulajdonság. a kiszolgáló "nem emlékszik" arra, amit már elküldött az ügyfélnek, és mi nem - az ilyen funkciókat további lekérdezési paraméterekkel kell végrehajtani,
  • . ha elfelejtettem valamit, később befejezem.

Egyszerű SOAP alkalmazás

Hasonló példákat tekintünk minden olyan szakirodalomra, amely a Delphi SOAP kifejlesztésére vonatkozik.
Futtassa a Delphi-t, és válassza a File | Új | Egyéb. . menjen a WebServices lapra, és válassza a SoapServer Application lehetőséget.

5 lehetőség közül választhat:

  • Az ISAPI / NSAPI Dinamic Link Libarry egy plug-in könyvtár az IIS / Netscape szerverekhez. minden kérelmet struktúrként továbbítanak és külön szálon dolgoznak fel.
  • A CGI Standalone Executable - konzolalkalmazás, egy szabványos bemenetre vonatkozó kérelmet kap, visszaküldi a szabvány kimenetre adott válaszokat, minden kérelmet külön alkalmazáspéldány feldolgoz,
  • A Win-CGI önálló végrehajtható Windows alkalmazás. az adatcsere az INI-fájlon keresztül történik (nem ajánlott, mivel elavult),
  • Apache Shared Module (DLL) - egy plug-in könyvtár az Apache szerver számára. minden kérelmet struktúrként továbbítanak, és külön szálon dolgoznak fel,
  • WebAppDebugger Executable - a Delphi szolgáltatással ellátott hibakereső kiszolgálóhoz tartozó plug-in könyvtár. mivel a WebAppDebugger is COM szerver, meg kell adnia (önkényesen) a CoClass Name-ot a COM-objektumhoz, amelyet a webmodul hívásához használ.

Válassza a CGI önálló végrehajtható lehetőséget. mint a legegyszerűbb hibakeresési formátum, akkor az alkalmazás könnyen átalakítható bármely más. A trükk az, hogy ha az alkalmazás minden logikája koncentrálódik az általad írt modulokra, akkor egyszerűen hozzon létre egy új alkalmazást a kívánt típustól, csatlakoztassa a modulokat hozzá, és működik!

Az OK gombra kattintás után egy új alkalmazás fog megjelenni, amely három összetevővel rendelkező WebModule-ot tartalmaz:

  • THTTPSoapDispatcher - fogadja a bejövő SOAP csomagokat, és átadja azokat a Diszpécser tulajdonsága (általában THTTPSoapPascalInvoker) által definiált összetevőnek,
  • THTTPSoapPascalInvoker - fogadja a bejövő SOAP kérés találja Fohász Registry nevű módszerrel végrehajt (behívja) generál egy választ, és elküldi azt obrabno THTTPSoapDispatcher.
  • TWSDLHTMLPublish - generálja a WSDL-t (W eb S ervices D escription L anguage), a modul által támogatott adatok és interfészek leírását.

Mentse a létrehozott alkalmazást, ez lesz a szerverünk vázlata.

Strangeness: később észrevettem, hogy WebModule. létrehozva a WebAppDebugger számára. némileg eltér a többi alkalmazási lehetőségtől

Amit ebben az üzletben nem értettem, de nélkülem a WebAppDebugger alatt végzett alkalmazás nem működik.

Logikailag kitöltjük. Mivel mind a kiszolgálónak, mind az ügyfélnek meg kell adnia a továbbított adatok és interfészek struktúráját, jobb, ha külön modulba teszik őket, és a teljes kiszolgáló megvalósítását egy másikban. Ehhez hozzon létre két modult (File | New | Unit), és mentse az egyiket CentimeterInchIntf.pas néven. és egy másik - CentimeterInchImpl.pas. Inside CentimeterInchIntf.pas írja be a következőt:

Tehát meghatároztuk az ICmInch interfészt. Két funkcióval rendelkezik: a centimétereket hüvelykre és hüvelykre konvertálja centiméterre, és regisztrálja az InvokeRegistry-ben.

Kezeljük a végrehajtást. A CentimeterInchImpl.pas-ban megadjuk a TInvokableClass leszármazottját. amely megvalósítja az ICmInch interfészt.

Amint látja, a TCmInch-ben az ICmInch interfész mindkét funkcióját implementáltuk. és az InvokeRegistry-ben is regisztráltuk az új invokálható osztályunkat (általában minden olyan hálózaton keresztül továbbítani kell, ami a skalár típusok kivételével) regisztrálva van.

Hozzon létre egy új alkalmazást (a szokásos típustól függően), adja meg felhasználási területünkben a CentimeterInchIntf interfészmodulunkat. Helyezze el a két gombot, két beviteli mezőt és a THTTPRIO összetevőt a WebServices palettán a fő formában.

Az alkalmazás összeállítása és futtatása után a centimétereket hüvelykre és fordítva alakíthatja át.

Kérdés: És mi van akkor, ha a SOAP kiszolgálót valaki más írja és nincs interfész-modulunk?
V: Akkor használja a webszolgáltató importőrét. amely a Fájlban található Új | Egyéb. . a WebServices lapon. Ez a varázsló létrehoz egy interfészmodult a WSDL szolgáltatáshoz.

Komplex típusok továbbítása

A komponens THTTPSOAPPascalInvoker már tudja, hogyan kell továbbítani skalár típusok és a dinamikus tömböket (az utóbbit kell előzetesen regisztrált InvokeRegistry. Cm. Alább), de a szállítást a komplex típusú, mint a statikus tömbben. felület. rekordot. set vagy osztály. először le kell írni őket a TRemotable osztály leszármazottaiként. amely rendelkezik RunTime Típusinformációkkal (RTTI). Például ha egy olyan osztályt szeretnénk deklarálni, amely visszaküldi az árfolyamot és a nevét, az interfészmodulunk így fog kinézni:

Itt adtuk meg a TCurrencyArray dinamikus tömböt. abban az esetben, ha át szeretné adni (jegyezze meg az osztály és a tömb regisztrációs parancsának különbségét).
Valójában az osztály regisztrációs parancs teljes szintaxisa némileg szélesebb, azok, akik szeretnének olvasni róla a Delphi dokumentációjában.

Megjegyzés: ha létezik olyan típus, amely skaláris a WSDL dokumentumban, de nincs közvetlen egyezés a Pascal objektumban (például DateTime), akkor TRemotableXS-t kell használni alaposztályként. amely két módszert deklarál XSToNative és NativeToXS-ként, hogy egy string-reprezentációt átalakítson az Object Pascal-nak és vissza (ezeket a módszereket természetesen végre kell hajtani).
A Delphi tartalmazza az XSBuiltIns modult. ahol számos hasznos funkciót már végrehajtottak (azonban a 6.0-s verzióban hibák voltak a dátum feldolgozása során, ha a rendszer nemzeti beállításai nem angolul voltak).

Van érdekes kérdés a paraméterekként továbbított objektumok létrehozásával és megsemmisítésével kapcsolatban. Íme, amit a TRemotable dokumentáció mond róla:
"A kiszolgáló oldalon a TRemotable leszármazottak, amelyek bemeneti paraméterek, automatikusan létrehozásra kerülnek a metódushívás megszüntetésénél, és automatikusan megsemmisülnek a kimeneti paraméterek márkakészlete után az ügyfél felé történő továbbításhoz.
A TRemotable leszármazottai. Létrehozva egy hívható felületen keresztül hívott módszert. automatikusan törlődik, miután az értéküket csomagolták (marsall) az ügyfél felé történő továbbításhoz.
Meghívható felületet hívó ügyfél. felelős a bemeneti paraméterekként használt objektumok létrehozásáért és az összes TRemotable leszármazott elpusztításáért. amelyet létrehozott, valamint az így kapott módszert. "

Adatkészlet átvitel

Itt minden nagyon egyszerű. A Soap Server Application projektben való részvétel. válassza a Fájl menüpontot Új | Egyéb. . menjen a WebServices lapra, és válassza ki a SoapServer Data Module-t. További fejlesztés nem különbözik a hagyományos MIDAS alkalmazás, két jellemzői: a szerver kell hontalan - érkezett kérelem, azt mondta elfelejtett (például CGI modul szó minden hívás után kerül véglegesítésre), és hogy nincs több, mint egy SoapDataModule.
Helyezze az adat-hozzáférési összetevőket a kapott modulra (például TClientDataset), állítsa be a feladathoz szükséges összes tulajdonságot. Helyezze a TDataSetProvider-t. csatlakoztassa az adatbeviteli összetevőhöz.

Skompilliruyte alkalmazására és olyan helyen, ahol lehet futtatni a Web-szerver (valamiért nem tudtam futni alatt WebAppDebugger. Valószínűleg használt téves WebModule. Cm. Megjegyzés fent).

Az ügyfélalkalmazásban helyezze a TSoapConnection és a TClientDataset az űrlapot. a SoapConnection.URL mezőben határozza meg a kiszolgáló felületének elérési útját:

használhat egy adott SoapDataModule interfészt. és lehetséges és általánosabb - IAppServer. A TClientDataset.RemoteServerben mutasson a TSoapConnection pontra. Most, a TClientDataset.Active:=true beállításával. adatokat fogunk kapni az ügyféltől.

Amikor ásni adatbázisba a szerver szükséges bizonyos paraméterek, ez lesz kényelmes helyett Előtelepítő: = true használatra DataRequest kérelmet (ne feledjük, hogy a SOAP alkalmazások minden paramétert belül kell átadni egy lekérdezés, hogy nem lehet az eredetileg beállított paraméterek és kérjen adatokat, mivel nagy valószínűséggel a második kérés egy másik kiszolgálói példányra megy át). Úgy néz ki, mint ez.
Az ügyfélen.

azaz a kiszolgáló bármilyen adatot átvihet (az átvitt típus az OleVariant), és mindenféle típusú adatokat, például adatcsomagot visszaszerezhet. mint a fenti esetben.

Ha megváltoztatta az adatokat az ügyfélen, és menteni kívánja a kiszolgálóra, többféle módon is megteheti. A legegyszerűbb mód a TDataSetProvider.ResolveToDataSet: = false beállítása és az ApplyUpdates módszer felhívása a TClientDataseton. A kérések frissítése a TDataSetProvider által létrehozható. és ellenõrzés (meglehetõsen gyenge) a lekérdezések kialakításához a TField.ProviderFlags tulajdonságok segítségével végezhetõ el.

Egy másik módszer: telepítse a TDataSetProvider.ResolveToDataSet: = true parancsot. Ebben az esetben azonban a TDataSetProvider.OnBeforeApplyUpdates eseménynek meg kell nyitnia a hozzá tartozó adatkészletet. úgy, hogy betöltődjön a rekordra, amelyet meg fog változtatni. De most már használhatja a BeforeInsert-BeforePost adatkészletének módszereit.

És az utolsó lehetőség: az interfészhez hozzáadott saját módszert használni, ahogy azt korábban a Cm2Inch segítségével végezték, és átadni a ClientDataset.Delta fájlnak. vagy frissítési utasításokat vagy a fejlesztő képzelőerejét. Például.

Ebben a példában a SaveChanges módszer Delta adatcsomagot vesz fel, és visszaad egy hibaütemezést a frissítés során.

Érdekes: a továbbított adatcsomag formátuma a community.borland.com oldalon található meg. de a valóságban egy bináris (base64Binary) csomag formájában kerül átadásra, ugyanabban a formátumban, mint a fájl (* .db), nem tudtam megtalálni ennek a formátumnak a leírását.
A tcpTrace program használatával megtekintheti, hogy a hálózaton keresztül továbbított csomagok valóban hogyan néznek ki. vagy a WebAppDebugger naplót.

A mesterrész munkája

Itt is minden egyszerű, de kissé szokatlan, mivel a részt át kell adni, mivel a mester adatkészletbe van beágyazva. mivel a TClientDataSet kötésének szokásos mesterrésze nem lehetséges. Ez így történik.

A Soap Server Data Module tartalmazza a master táblázat és a részletek adatait, és a szokásos módon a TDataSource segítségével kapcsolódik. Van egy TDatasetProvider is. amely a master táblához kapcsolódik. A kiszolgáló össze van állítva és elhelyezve, ahol a webszerver elindíthatja.

A második TClientDataSet (ez lesz a mi részünk) az egyetlen tulajdonságot állítja be: DataSetField (válassza ki az első adatlistából a TDataSetField nevét a listából). Most, ha a TClientDataSet-et a rácsokhoz csatlakoztatja. látni fogjuk adatainkat - külön a master táblát és az elemet.

Van egy alternatív lehetőség: a mester és a rész külön adatkészletekkel kerül elküldésre. míg a rész teljesen betöltve van. és kiválaszthatja a varázsló egy adott vonalához tartozó részrekordok készletét, akkor a kliensen végzett szűrést használják, de a varázsló és a részletek szinkron frissítése esetén problémák merülnek fel.

Menj egy másik alkalmazáshoz

Ha már játszott elég WebAppDebugger-edik és CGI, akkor törölje az „úgymond, Shakespeare” modul ISAPI- / NSAPI.

Általánosságban elmondható, hogy egyik alkalmazásról a másikra (például a WebAppDebuggerről a CGI-re) való áttérés rendkívül egyszerű. Hozzon létre egy új alkalmazást a szükséges típussal, add hozzá minden modulunkat, és az új alkalmazás működik! Ha biztosan nem adott meg kódot az automatikusan generált modulokhoz, amit személy szerint nem javasolok.

Mégis meg kell emlékezni a korábban említett különbségek WebModule a WebAppDebugger és CGI, valamint a különbséget a CGI és ISAPI alkalmazások: az első esetben, egy példányát a kérelmet a kapcsolatot (azaz minden alkalmazásnak van egy felhasználó), a második - kérelem egy, hanem minden kapcsolatot az alkalmazás létrehoz egy külön téma, hogy óvatosan kell kezelni a megosztott adatok, és a többi - nem probléma.

Megjegyzés: SOAP szerver összeállított Delphi 7 (és valószínűleg nagyobb) Nyelv chuvsvitelny hogy a szerver, amelyen dolgoznak - alapul, ők átalakítani orosz karaktereket Win1251 az UTF8. Ie nemzeti szükségét, hogy az ország „Oroszország” beállítások Server operációs rendszer helyett, vagy orosz karakterek kap kryakozyubry.
vagy bármelyik vonalat hozzáadni bármelyik modul inicializálási kódjához

ami miatt a modul az orosz alapértelmezett kódolást használja.

További irodalomként azt javasolom, hogy nézzen ki:

  1. A Kylix Fejlesztői Útmutató BizSnap fejezete (különösen a 4-6. Rész)
  2. InterBase egy többszintű világban
  3. ISAPI alkalmazások tervezése az adatbázisok kezeléséhez
  4. . és természetesen - RTFM. az igazság a keresési ezen szakaszok valamilyen oknál fogva nagy probléma, de a információ a segítség is elég részletes,
  5. valamint a demo alkalmazások. amelyek Delphivel érkeznek

Üdvözlendő a cikk fejlesztésében. [email protected]

Kapcsolódó cikkek

előző ◈ a következő