Pokročilé programování v PHP5

CYAN

MAGENTA

YELOW

CYAN

BLACK

MAGENTA

E N C Y K L O P E D I E

PHP 5 PHP je velmi oblíbený a rozšířený programovací jazyk, speciálně vyvinutý pro vytváření funkčně bohatých webových stránek, které jsou rychlé a spolehlivé. Časem však PHP přerostl své původní určení a nyní se používá v různých prostředích pro nejrůznější účely.

Programátoři PHP začali využívat tento jazyk úplně všude – počínaje internetem a konče příkazovou řádkou, a to takovými způsoby, jaké by si ještě před nedávnem málokdo dokázal představit.

ZONER software, s.r.o. významný producent software v oblasti digitální fotografie, počítačové grafiky a multimédií, poskytovatel internetových služeb, souvisejících s prezentací na internetu a e-komercí, a nakladatelství odborné literatury.

PHP

Georgie Schlossnagle je přispěvovatel projektu PHP a autor modulu Apache. Má dlouholeté praktické zkušenosti s vytvářením velkých PHP webů a aplikací. Dva roky pracoval jako senior architekt v CommunityConnect, Inc., kde pomáhal při řešení systému se zátěží až 130 miliónů dynamických PHP požadavků denně. Je rovněž autorem dvou rozšíření Zend Engine pro PHP – obě byla vyvinuta v rámci zvýšení výkonu na transakčních webových systémech.

Přednáší na konferencích a je ředitelem OmniTI Consulting, kde buduje vysoce výkonná webová a emailová řešení.

© Foto: Jiří Heller, www.heller.cz

Pod tímto logem vycházejí publikace určené pro každého, kdo se zajímá o tvorbu webových stránek. Od ryze praktických příruček a průvodců až po komplexní publikace o všem, co potřebuje webdesignér při každodenní práci. Na slevy, které můžete získat, a vydavatelský plán, v němž vedle knih domácích odborníků najdete celou řadu titulů světově uznávaných autorů, se informujte na adrese vydavatelství.

Věrným čtenářům je určen výhodný PRÉMIOVÝ PLUS PROGRAM.

www.zoner.cz Fotografie z nabídky fotobanky HELLER.CZ

E N C Y K LO P E D I E W E B D E S I G N E R A

Pokročilé programování v

Kniha Pokročilé programování v PHP 5 poskytuje zkušeným vývojářům techniky pro používání PHP ve velkém měřítku v podnikovém prostředí. Kniha se zaměřuje na PHP 5 a detailně se věnuje technikám objektově orientovaného programování, testování, bezpečnosti, technikám a technologiím cachování, vyvíjení škálovatelných distribuovaných aplikací a ladění výkonu. Rovněž obsahuje komplexní pojednání o různých rozšířeních PHP. Kniha prakticky a jasně vysvětluje i nejsložitější koncepty, a pro ilustraci poskytuje vždy úplné a reálné příklady.

•

Techniky objektově orientovaného programování, používání vzorů a šablon.

• Tvorba aplikačního

programového rozhraní.

a interakce s databázemi.

• Správa relací (session), KATALOGOVÉ ČÍSLO: ZR412

ISBN 80-86815-14-5

autentizace a bezpečnost.

George Schlossnagle

• PHP a Zend Engine.

DEVELOPER’S LIBRARY

George Schlossnagle

www.zonerpress.cz

ZONER software, s.r.o., Koželužská 7, 602 00 Brno

obal_PHP_opraveny.indd 1

• Obsluha chyb a výjimek.

• Ladění výkonu a testování.

• Distribuované aplikace

© Foto: Jiří Heller

Zoner Press tel.: 532 190 883 fax: 543 257 245 e-mail: knihy@zoner.cz http://www.zonerpress.cz

YELOW



W E B D E S I G N E R A

pokročilé programování v

Pokročilé programování v

MAGENTA

BLACK

ENCYKLOPEDIE WEBDESIGNERA

George Schlossnagle

CYAN

YELOW

9 7 8 8 0 8 6

BLACK

8 1 5 1 4 5

CYAN

MAGENTA

YELOW

BLACK 17.12.2004 17:28:03

Pokročilé programování v

PHP George Schlossnagle

DEVELOPER’S LIBRARY

5

Authorized translation from the English language edition, entitled ADVANCED PHP PROGRAMMING, 1st Edition, 0672325616 by SCHLOSSNAGLE, GEORGE, published by Pearson Education, Inc, publishing as Que/Sams, Copyright © 2004 by Sams Publishing.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. CZECH language edition published by ZONER software s.r.o., Copyright © 2004 Autorizovaný překlad anglického vydání nazvaného ADVANCED PHP PROGRAMMING, první vydání, 0672325616 autor SCHLOSSNAGLE, GEORGE, vydal Pearson Education, Inc, ve vydavatelství Que/Sams; Copyright © 2003 Sams Publishing.

Všechna práva vyhrazena. Žádná část této publikace nesmí být reprodukována nebo rozšiřována žádnou formou nebo způsobem, elektronicky ani mechanicky, včetně fotokopií a natáčení, ani žádnými jinými systémy pro ukládání dat bez výslovného svolení Pearson Education, Inc. České vydání vydal ZONER software s.r.o., Copyright © 2004.

Pokročilé programování v PHP 5 Autor: George Schlossnagle Copyright © ZONER software s.r.o. Vydání první v září 2004. Všechna práva vyhrazena.

KATALOGOVÉ ČÍSLO: ZR412 Zoner Press ZONER software s.r.o.

Koželužská 7, 602 00 Brno Překlad: Jan Gregor, Jan Kuklínek, Václav Šimek, Martin Wokoun Odpovědný redaktor: Miroslav Kučera DTP: Miroslav Kučera © Cover foto: Jiří Heller, HELER.CZ s.r.o., www.heller.cz © Cover: Ing. Pavel Kristián Informace, které jsou v této knize zveřejněny, mohou byt chráněny jako patent. Jména produktů byla uvedena bez záruky jejich volného použití. Při tvorbě textů a vyobrazení bylo sice postupováno s maximální péčí, ale přesto nelze zcela vyloučit možnost výskytu chyb.

Vydavatelé a autoři nepřebírají právní odpovědnost ani žádnou jinou záruku za použití chybných údajů a z toho vyplývajících důsledků.

Všechna práva vyhrazena. Žádná část této publikace nesmí být reprodukována ani distribuována žádným způsobem ani prostředkem, ani reprodukována v databázi či na jiném záznamovém prostředku či v jiném systému bez výslovného svolení vydavatele s výjimkou zveřejnění krátkých částí textu pro potřeby recenzí.

Veškeré dotazy týkající se distribuce směřujte na: Zoner Press ZONER software s.r.o.

Koželužská 7, 602 00 Brno tel.: 532 190 883, fax: 543 257 245 e-mail: knihy@zoner.cz http://www.zonerpress.cz

ISBN 80-86815-14-5

Stručný obsah

Část IV: Výkon

Část I: Implementační a vývojářská metodika

Kapitola 17 – Srovnávací testy: testování celé aplikace

Kapitola 1 – Styl zápisu kódu Kapitola 2 – OOP prostřednictvím návrhových vzorů Kapitola 3 – Zpracování chyb Kapitola 4 – Implementujeme s PHP: Šablony a web Kapitola 5 – Implementujeme s PHP: Samostatné skripty

Kapitola 18 – Profilování Kapitola 19 – Syntetické benchmarky: zaostřeno na bloky kódu a funkce

Část V: Rozšiřitelnost Kapitola 20 – Pohled do útrob PHP a Zend Enginu Kapitola 21 – Rozšiřujeme PHP: část I

Kapitola 6 – Testování jednotek

Kapitola 22 – Rozšiřujeme PHP: část II

Kapitola 7 – Správa vývojového prostředí

Kapitola 23 – Vytváříme rozhraní SAPI a rozšiřujeme Zend Engine

Kapitola 8 – Návrh dobrého API

Část II: Cachování Kapitola 9 – Vnější ladění výkonu Kapitola 10 – Cachování dat Kapitola 11 – Znovupoužití výpočtů

Část III: Distribuované aplikace Kapitola 12 – Interakce s databázemi Kapitola 13 – Autentizace uživatele a bezpečnost relace Kapitola 14 – Zpracování relace Kapitola 15 – Tvorba distribuovaného prostředí Kapitola 16 – RPC: Interakce se vzdálenými službami

Podrobný obsah Stručný obsah – 3 O autorovi – 10 Poděkování – 10

Vyhněte se používání příkazu echo pro vytváření HTML – 40 Závorky používejte rozumně – 41

Dokumentace – 42

Sdělte nám svůj názor – 11

Vnořené komentáře – 42

Služby čtenářům – 11

Dokumentace API – 43

Předmluva – 12

Další informace – 48

Úvodní povídání – 13

2. OOP prostřednictvím návrhových vzorů – 49

PHP v komerční sféře – 13 Struktura a uspořádání knihy – 15 Část I – Implementační a vývojářská metodika – 15 Část II – Cachování – 16 Část III – Distribuované aplikace – 16 Část IV – Výkon – 17 Část V – Rozšiřitelnost – 18

Platformy a verze – 18

I – Implementační a vývojářská metodika – 19

1. Styl zápisu kódu – 21 Volba správného stylu – 22 Formátování a úprava kódu – 22 Odsazení – 22

Objektově orientované programování – 50 Dědičnost – 52 Zapouzdření – 53 Statické (třídní) atributy a metody – 53 Speciální metody – 54

Stručný úvod do návrhových vzorů – 56 Adaptér vzoru – 56 Šablona vzoru – 61 Polymorfismus – 62 Rozhraní a kontrola typu – 64 Vzor Factory – 67 Vzor Singleton – 68

Přetěžování – 70 SPL a iterátory – 76 _ _call() – 81

Další informace – 85

Délka řádku – 25

3. Zpracování chyb – 87

Formátovací znaky a mezery – 26

Zpracování chyb – 90

Direktiva SQL – 26

Zobrazování chyb – 90

Řízení toku programu – 27

Logování chyb – 91

Názvosloví – 32 Konstanty a globální proměnné – 33 Dlouhodobé proměnné – 35 Dočasné proměnné – 35 Víceslovné názvy – 36 Názvy funkcí – 37 Názvy tříd – 37 Názvy metod – 37 Názvy proměnných přizpůsobte názvům schémat – 38

Vyhněte se matoucímu kódu – 39 Vyhněte se používání zkrácených značek – 39

Ignorování chyb – 92 Reagování na chyby – 92

Zpracování vnějších chyb – 94 Výjimky – 97 Používání hierarchií výjimek – 100 Příklad s typovými výjimkami – 102 Řazení výjimek do kaskády – 108 Zpracování chyby konstruktoru – 112 Instalování funkce pro zpracovánívýjimek nejvyšší úrovně – 113 Validace údajů – 115

Kdy používat výjimek – 119

Přibalení mezi řádky – 172

Další informace – 120

Zabalení samostatných testů – 174

4. Implementujeme s PHP: Šablony a web – 121 Smarty – 122

Současné spouštění hromadných testů – 175

Další vlastnosti PHPUnit – 176 Tvorba chybových zpráv s vyšší informační hodnotou – 177

Instalace systému Smarty – 122

Přidání více testových podmínek – 178

Vaše první Smarty šablona: Ahoj světe! – 124

Použití metod setUp() a tearDown() – 179

Zkompilované šablony pod pokličkou – 125

Přidání naslouchačů – 180

Řídící struktury systému Smarty – 125

Používání grafického rozhraní – 182

Funkce systému Smarty a více – 128

Testy řízený návrh – 182

Cachování se systémem Smarty – 131

Fleschův výpočet hodnocení – 183

Pokročilé vlastnosti Smarty – 132

Testování třídy Word – 183

Vytvoření vlastního řešení pomocí šablon – 134

Chybová zpráva 1 – 192

Další informace – 136

Testování jednotek ve webovém prostředí – 194

5. Implementujeme s PHP: Samostatné skripty – 137

Další informace – 196

Úvod do rozhraní příkazové řádky PHP (CLI – Command-Line Interface) – 139

Kontrola změn – 198

Zpracování vstupu/výstupu (I/O) – 139

Úpravy souborů – 202

Analýza argumentů příkazové řádky – 142

Sledování rozdílů mezi soubory – 203

Vytváření a správa procesů potomků – 144

7. Správa vývojového prostředí – 197 Základy CVS – 199

Snazší spolupráce více vývojářů na jednom projektu – 206

Zavírání sdílených zdrojů – 145

Symbolické značky – 207

Sdílení proměnných – 146

Větve – 208

Úklid procesu potomka – 146

Údržba vývojových a provozních prostředí – 209

Signály – 148

Vytváření démonů – 152

Správa balíčkování – 214 Balíčkování a přesun kódu – 215

Nastavení pracovního adresáře – 153

Balíčkování binárek – 217

Zrušení oprávnění – 154

Balíčkování Apache – 218

Zaručení exkluzivity – 155

Balíčkování PHP – 219

Kombinace toho, co jste se naučili: monitorování servisů – 155 Další informace – 164

6. Testování jednotek – 167 Úvod k testování jednotek – 168

Další informace – 220

8. Návrh dobrého API – 221 Návrh dovolující přepracování a rozšiřování – 222 Doplnění funkcí významem – 223

Tvorba testů pro automatizované testování jednotek – 169

Udržování jednoduchých tříd a funkcí – 224

Tvorba vašeho prvního testu jednotky – 169

Redukce vazeb – 226

Přidávání hromadných testů – 170

Tvorba vložených a externích testů jednotek – 171

Jmenné prostory – 224

Opatrné programování – 227 Zavádění standardních zásad – 228 Používání sterilizačních technik – 228

Další informace – 230

Další informace – 293

II – Cachování – 231

11. Znovupoužití výpočtů – 295

9. Vnější ladění výkonu – 233 Ladění jazyka – 233 Cache kompilátoru – 233 Optimalizátory – 236 HTTP akcelerátory – 237 Reverzní proxy – 238 Vylaďování operačního systému na vysoký výkon – 242 Proxy cache – 243

PHP aplikace vhodné pro cachování – 244 Komprese obsahu – 248 Další informace – 249 Dokumenty RFC – 249 Cache kompilátoru – 249 Proxy cache – 249 Komprese obsahu – 250

10. Cachování dat – 251 Problematika cachování – 251 Rozpoznání cachovatelných dat – 253 Volba vhodné strategie: vlastní nebo hotové třídy – 253 Výstupní mezipamět – 254 Cachování v paměti – 256

Ilustrační příklad: Fibonacciho posloupnost – 295 Cachování znovupoužitých dat uvnitř požadavku – 302 Cachování znovu používaných dat mezi požadavky – 304 Znovupoužití výpočtů uvnitř PHP – 308 PCRE – 308 Délka polí – 308

Další informace – 309

III – Distribuované aplikace – 311

12. Interakce s databázemi – 313 Jak fungují databáze a dotazy – 314 Zkoumání dotazu pomocí EXPLAIN – 317 Hledání dotazů k profilování – 319

Vzory pro přístup do databáze – 321 Dotazy Ad Hoc – 321 Vzor Active Record – 322 Vzor Mapper – 324 Vzor Integrated Mapper – 330

Ladění přístupu k databázi – 332

Cache v obyčejných souborech – 256

Omezení množiny výsledků – 332

Udržování velikosti cache – 256

Líná inicializace – 334

Souběžnost a souvislost cache – 257

Cachování založené na DBM – 263 Souběžnost a souvislost cache – 264 Zneplatnění cache a její správa – 264

Cachování ve sdílené paměti – 268 Cachování pomocí cookies – 269 Správa velikosti cache – 274 Souběžnost a souvislost cache – 275

Integrace cachování do kódu aplikace – 275 Cachování domovských stránek – 278 Chytřejší cachování s mod_rewrite pro Apache – 285 Cachování části stránky – 288 Implementace cache dotazů – 291

Další informace – 336

13. Autentizace uživatele a bezpečnost relace – 339 Jednoduché autentizační schéma – 340 Základní autentizace HTTP – 341 Mungování řetězce dotazu – 341 Cookie – 342

Registrace uživatelů – 343 Ochrana hesel – 343 Ochrana hesel proti sociálnímu inženýrství – 346

Udržování autentizace: zajišťování, že stále komunikujete se stejnou osobou – 347

Kontrola neměněného stavu proměnné $_SERVER['REMOTE_IP'] – 347 Kontrola neměněného stavu proměnné $_SERVER['USER_AGENT'] – 348 Použití nezašifrovaných cookie – 348 Co byste měli udělat – 348 Příklad implementace autentizace – 350

Jednorázové přihlášení – 355 Implementace jednorázového přihlášení – 358

Další informace – 363

XML-RPC – 408 Tvorba serveru: implementace MetaWeblog API – 410 Informativní služby XML-RPC – 414

SOAP – 417 WSDL – 419 Přepis system.load na službu SOAP – 422 Webové služby Amazonu a komplexní typy – 424 Generování kódu proxy – 426

Srovnání SOAP s XML-RPC – 427 Další informace – 428

14. Zpracování relace – 365

SOAP – 428

Klientské relace – 366

XML-RPC – 428

Implementace relací přes cookie – 367 Menší vylepšení aplikace – 369

Serverové relace – 370 Sledování identifikátoru relace – 371 Stručný úvod do relací PHP – 373 Metody uživatelského ovladače relace – 375

Veřejně dostupné webové služby – 429

IV – Výkon – 431 17. Srovnávací testy : testování celé aplikace – 433

Garbage Collection aneb "sběr odpadu" – 380

Pasivní identifikace slabých míst – 434

Rozhodování mezi klientskými a serverovými relacemi – 382

Generátory zátěže – 436

15. Tvorba distribuovaného prostředí – 383 Co je to cluster? – 383 Základy tvorby clusterů – 386

Ab – 436 httperf – 438 Daiquiri – 440

Další informace – 441

18. Profilování – 443

Plánování chyb – 386

Požadavky na PHP profiler – 444

Dobrá spolupráce s ostatními – 387

Nabídka profilovacích programů – 444

Distribuce dat do clusterů – 389 Horizontální škálování – 389

Instalace a použití APD – 445

Specializované clustery – 390

Příklad trasování – 447

Cachování v distribuovaném prostředí – 391 Centralizované cachování – 393 Plně decentralizovaná cache pomocí nástroje Spread – 395

Škálování databází – 398 Tvorba aplikací pro architekturu master/slave – 402 Alternativy k replikaci – 404 Alternativy k systémům RDBMS – 405

Další informace – 406

16. RPC: Interakce se vzdálenými službami – 407

Profilování větší aplikace – 448 Zjišťování obecných nedostatků – 454 Odstranění zbytečných funkcionalit – 456 Další informace – 460

19. Syntetické benchmarky: zaostřeno na bloky kódu a funkce – 463 Základy benchmarků – 464 Vytváříme sadu benchmarků – 465 Benchmarky a kolekce PEAR – 465 Praktická stránka tvorby vlastních testů – 468

Pokaždé náhodná data – 469

MINIT – 551

Odstraňujeme režii benchmarků – 471

MSHUTDOWN – 552

Přidáváme doplňující časové údaje – 472

Funkce modulu – 552

Píšeme inline benchmarky – 476

Používáme modul Spread – 560

Benchmarky v příkladech – 477

Další informace – 561

Porovnání znaků na začátku řetězce – 477 Rozvoje makra – 478

22. Rozšiřujeme PHP: část II – 563

Interpolace versus konkatenace – 485

Implementujeme třídy – 563

V – Rozšiřitelnost – 487 20. Pohled do útrob PHP a Zend Enginu – 489 Jak pracuje Zend Engine: operační kód a operační pole – 490 Proměnné – 496 Funkce – 499 Třídy – 501

Vytváříme novou třídu – 564 Rozšíření vlastností třídy – 565 Třída a dědičnost – 568 Rozšíření třídy o metody – 568 Rozšíření třídy o konstruktor – 571 Generování výjimek – 572 Použití vlastních objektů a soukromých proměnných – 573 Používáme metody šablon – 576 Vytváříme a implementujeme rozhraní – 577

Manipulátory objektů – 503

Vytváříme vlastní manipulátory spojení – 578

Vytvoření objektu – 503

API pro práci s proudy – 583

Další významné struktury – 504

Životní cyklus požadavku v prostředí PHP – 506

Další informace – 594

Vrstva SAPI – 507

23. Vytváříme rozhraní SAPI a rozšiřujeme Zend Engine – 595

Jádro PHP – 510

Rozhraní SAPI – 595

API pro rozšíření PHP – 510 API pro rozšíření Zend Enginu – 511 Jak jednotlivé části zapadají dohromady – 513

Další informace – 514

21. Rozšiřujeme PHP: část I – 515 Základy rozšiřování – 516

CGI SAPI – 596 Vestavěné SAPI – 606 SAPI a vstupní filtry – 607 input_filter – 608

Pohled do útrob Zend Enginua jeho modifikace – 613

Vytváříme základ rozšíření – 516

Varovná hlášení a výjimky – 613

Sestavujeme a používáme rozšíření – 519

Jak na výpis opkódů – 616

Používáme funkce – 520

APD – 619

Typy a správa paměti – 523

APC – 621

Parsování řetězců – 526

Rozšíření Zend a zpětná volání – 621

Manipulace s typy – 527 Typové konverze s testováním a řízení přístupu – 532 Používáme zdroje – 536 Generování chybových hlášení – 541 Používáme zpětná volání u modulů – 541

Příklad: klient Spread a jeho obálka – 549

Za domácí úkol – 624

Rejstřík – 625

O autorovi George Schlossnagle je ředitelem průmyslové společnosti OmniTI Computer Consulting, která sídlí v Marylandu a zaměřuje se na vysokokapacitní webové a emailové systémy. Předtím vedl technické operace na několika silně navštěvovaných komunitních webech, přičemž se zdokonalil ve správě PHP ve velmi velkých podnikových prostředí. Patří mezi časté přispěvovatele komunity PHP a jeho práci lze najít v PHP rozšířeních PEAR a PECL. Před vstupem na pole informačních technologií studoval George matematiku a dva roky působil jako učitel v Peace Corps (tedy v mírových sborech). Jeho zkušenosti jej naučily si vážit disciplinovaného řešení problému, které analyzuje jeho pravou příčinu před prostým adresováním symptomů.

Poděkování Psaní této knihy bylo pro mne neocenitelnou zkušeností a rád bych poděkoval všem lidem, kteří mi to umožnili. Děkuji všem vývojářům PHP za náročnou práci při vytváření tak skvělého produktu. Bez jejich ustavičného úsilí by tato kniha neměla žádný námět.

Děkuji Shelley Johnston, Damon Jordan, Sheila Schroeder, Kitty Jarrett a ostatním zaměstnancům vydavatelství Sams za to, že věřili nejenom mě, ale i této knize. Bez nich by všechno bylo pouze nezrealizovaným cílem, který se mi honí v hlavě.

Děkuji technických editorům Briane France, Zak Greant a Sterling Hughes za čas a úsilí, které věnovali čtení a komentování jednotlivých kapitol. Bez jejich snažení bych si nemohl být jist, že tato kniha je kompletní a neobsahuje hromadu chyb.

Děkuji svému bratru Theovi za jeho technické konzultace a že mi byl zdrojem inspirace. V neposlední řadě také za to, že mi poskytl v práci časovou volnost, když jsem pracoval na dokončení této knihy.

Děkují rodičům, že ze mě vychovali takového člověka jakým jsem dnes a především mé matce Sherry za to, že se vlídně dívala na každou kapitolu této knihy. Doufám, že jste oba na mě pyšní.

A největší dík patří mé ženě, Pei, za neoblomnou podporu a za nesobecké obětování mnoha nocí a víkendů tomuto projektu. Za její lásku, trpělivost a podporu má mou nehynoucí vděčnost.

Sdělte nám svůj názor Jako čtenáři této knihy se stáváte těmi nejdůležitějšími kritiky a komentátory. Vážíme si vašeho názoru a chtěli bychom vědět, co děláme správně, co bychom mohli dělat lépe, ve kterých oblastech bychom měli publikovat a také vaše další podnětné myšlenky, o které jste ochotni se s námi podělit.

Jako odborný redaktor Zoner Press vítám vaše názory. Můžete mi psát – poslat e-mail nebo dopis – a sdělit mi, co se vám v této knize líbilo nebo nelíbilo, stejně tak, co bychom měli udělat, aby naše další knihy byly lepší. Pokud mi napíšete, nezapomeňte prosím připojit název knihy, ISBN, jméno autora, vaše jméno, telefon, fax nebo e-mail. Pozorně zhodnotím vaše názory a poskytnu je autorovi a redaktorům, kteří pracovali na této knize.

Prosím, vězte, že nemohu pomoci s technickými problémy, které se týkají obsahu knihy, a že díky velkému množství e-mailů, které dostávám, nemohu zaručit odpověď na každou zprávu.

E-mail: miroslav.kucera@zoner.com Adresa: Zoner Press ZONER software, s.r.o Miroslav Kučera Koželužská 7 602 00 Brno

Služby čtenářům Další informace o této a dalších knihách vydaných v Sams Publishing najdete na adrese www.samspublishing.com. Do vyhledávacího pole zadejte kód ISBN (bez pomlček) nebo titul knihy pro nalezení požadované knihy.

Zdrojové soubory k této knize je možné stáhnout z adresy http://www.zonerpress.cz.

Předmluva V poslední době jsem určitým způsobem pracoval na různých knihách Williama Gibsona a v knize All Tomorrow’s Parties jsem narazil na tohle: To, co je pře-designované, příliš hodně specifické, předvídá výsledek; předvídání výsledku zaručuje, pokud ovšem neselže, nedostatek půvabu.

Gibson tak elegantně shrnul nedostatky spousty projektů všech velikostí. Když něco vytváříte, řešte problém, který máte nyní. U velmi složité architektury se nesnažte předvídat, jak by mohl problém vypadat za rok a pokud vytváříte univerzální nástroj, nechtějte, aby byli lidé nucení používat váš nástroj pouze jedním způsobem.

Samotné PHP je na hraně mezi specifickým řešením problému webu a vyhýbání se snažení vnucovat lidem specifickou formu řešení problému. Někdo by označil PHP za elegantní. Jako skriptovací jazyk utržil za několik let služby v první linii webu spoustu šrámů po bitvách. Elegantní však je jednoduchost přístupu PHP. Každý vývojář prochází různými fázemi, jak přistupuje k řešení problémů. Zpočátku převažují jednoduchá řešení, protože není dostatečně pokročilý na to, aby pochopil složitější principy, které jsou potřeba pro všechno ostatní. Čím více se toho dozvíte, tím komplexnější řešení budete navrhovat a bude se zvětšovat okruh problémů, které můžete řešit. V tomto bodě je snadné upadnou do rutiny komplexnosti.

Je-li dostatek času a prostředků, lze každý problém vyřešit téměř s jakýmkoliv nástrojem. Úkolem nástroje je, aby vám nenutilo žádný konkrétní způsob řešení a o to se snaží i PHP. Nezavádí žádný konkrétní programovací vzor, ponechává na vás, abyste se sami rozhodli a tvrdě se snaží minimalizovat počet vrstev mezi vámi a řešeným problémem. To znamená, že všechno je připraveno tak, abyste s pomocí PHP našli jednoduché a elegantní řešení problému.

Ovšem to, že máte k dispozici připraveny všechny nástroje, které nevytváří zrůdnosti, nezaručí, že se tak nestane. A právě zde se dostává ke slovu George a tato jeho kniha. George vás provede nejenom po cestě za poznáním PHP, která se velmi podobá jeho vlastní cestě s PHP, ale provede vás také s vývojem a řešením problémů obecně. Po pár dnech čtení se naučíte to, co se on sám učil po mnoho let za svého působení v této branži. A proto nejlépe hned přestaňte číst tuhle neužitečnou předmluvu a nalistujete si kapitolu 1 a vykročte na svou vlastní cestu.

Rasmus Lerdorf

Úvodní povídání

Cílem této knihy je udělat z vás odborníky na programování v PHP. Být odborníkem na programování neznamená mít úplnou znalost syntaxe a vlastností jazyka (i když to určitě pomůže), ale znamená to, že můžete jazyk efektivně používat k řešení problémů. Po přečtení této knihy byste měli dobře znát silné a slabé stránky jazyka PHP a také byste měli vědět, jak jej nejlépe používat k odstranění problémů jak uvnitř, tak i mimo webovou doménu.

Tato kniha usiluje o to, aby byla soustředěnou myšlenkou popisující obecné problémy a používající konkrétní příklady pro ilustraci – jako protiklad ke kuchařce, kde jsou jak problémy, tak i řešení obvykle velmi specifické. Jak říká jedno stařé přísloví: „Dejte člověku rybu a on ji za den sní. Naučte ho, jak ji chytnout a bude ji jíst po celý život“. Cílem je poskytnout vám nástroje pro řešení jakéhokoliv problému a naučit vás rozpoznat správný nástroj pro daný úkol.

Podle mého názoru se nejlépe učí na příkladech a tato kniha je plná praktických příkladů, které implementují všechny myšlenky, o nichž se hovoří. Příklady nejsou bez kontextu příliš užitečné, proto veškerý kód v této knize je skutečný kód, které provádí skutečné úlohy. V této knize nenajdete příklady s názvy tříd jako např. Foo a Bar; kde to bylo možné, použili jsme příklady z aktuálních open-source projektů, abyste mohli vidět probírané nápady ve skutečných implementací.

PHP v komerční sféře Když jsem v roce 1999 začal profesionálně programovat v PHP, tento skriptovací jazyk právě přestávat být pouze jazykem pro nadšence. Byl to čas PHP 4 a první Zend Engine měla zrychlit a zlepšit stabilitu PHP. Exponenciálně rovněž rostl počet implementací PHP, nicméně, stále bylo obtížné prosadit PHP pro použití na velkých komerčních webových stránkách.

14

Pokročilé programování v PHP 5

Tato obtížnost pramenila hlavně ze dvou zdrojů:

• Vývojáři Perl/ColdFusion a dalších skriptovacích jazyků, kteří odmítali aktualizovat své porozumění schopnostem PHP od doby, kdy to byl ještě vznikající jazyk.

• Javoví vývojáři, kteří chtěli mít velký a kompletní systém, robustní objektově orientovanou podporu, statický zápis a další “podnikové“ vlastnosti. Žádný z těchto argumentů však dlouho neobstál a PHP tak již není jazykem používaným bezvýznamnými nadšenci – stal se výkonným skriptovacím jazykem, jehož design z něj dělá ideální volbu pro řešení problémů na webové doméně.

Aby byl programovací jazyk použitelný v aplikacích, musí splňovat těchto šest zásadních kritérií:

• • • • • •

Rychlé prototypování a implementace.

Podpora moderních programovacích forem. Škálovatelnost.

Výkon.

Interoperabilita.

Rozšiřitelnost.

První kritérium – rychlé prototypování – bylo od počátku silnou stránkou PHP. Zásadní rozdíl mezi vývojem webu a vývojem krabicového softwaru spočívá v tom, že na webu nejsou téměř žádné náklady na dodávání produktu. V krabicovém software však i miniaturní chyba znamená, že jste vypálili tisíce CD s chybným kódem. Oprava chyb zahrnuje komunikaci se všemi uživateli, kteří mají software s chybou a následném vyžádání, aby si stáhli a aplikovali opravu. Když opravíte chybu na webu, uživatel získá korektní verzi ihned, jakmile znovu načte stránku. Díky tomu mohou být webové aplikace vyvíjeny s pomocí velmi agilní metodologie s vysokou frekvencí vydávání nových verzí.

Skriptovací jazyky jsou obecně lepší pro agilní produkty, protože vám umožní rychle vyvinout a otestovat nové nápady bez toho, aniž byste museli procházet celý kompilační, testovací a ladící cyklus. PHP je k tomu dobré zejména proto, že má tak malou křivku osvojování znalostí, díky čemuž s ním mohou začít pracovat noví vývojáři s minimálními předchozími zkušenostmi.

PHP rovněž plně splňuje všechny ostatní kritéria. Jak uvidíte v této knize, nový objektový model PHP poskytuje stabilní a standardní objektově orientovanou podporu. PHP je rychlé a škálovatelné, například, různé programovací strategie, které můžete v PHP použít, vám umožní snadnou opětovnou implementaci zásadní části obchodní logiky v nízko úrovňových jazycích. PHP poskytuje obrovské množství rozšíření pro spolupráci s dalšími službami – od databázových serverů po SOAP. Nakonec má PHP nejzásadnější charakteristickou vlastnost jazyka: je snadno rozšiřitelný. Pokud jazyk neposkytuje vlastnost nebo dovednost jakou právě potřebujete, můžete přidat její podporu.

Úvodní povídání

15

Struktura a uspořádání knihy Kniha je rozdělena na pět částí, které jsou víceméně na sobě nezávislé. Přestože je kniha vytvořena tak, aby zainteresovaný čtenář mohl jednoduše přeskočit vpřed na konkrétní kapitolu, doporučujeme číst knihu od začátku do konce, protože celá řada příkladů je postupně vytvářena v průběhu celé knihy.

Uspořádání této knihy vychází z přirozeného vývoje – nejprve budeme hovořit o tom, jak napsat dobrý kód PHP, poté se zaměříme na specifické techniky a ladění výkonu a nakonec na rozšíření jazyka. Tento formát je založen na mém přesvědčení, že největší zodpovědností profesionálního programátora je psát spravovatelný kód a že je snazší zrychlit provádění dobře napsaného kódu, než zlepšovat mizerně napsaný kód, který již běží rychle.

Část I – Implementační a vývojářská metodika Kapitola 1 – Styl zápisu kódu V této kapitole vás uvedeme do konvencí používaných v této knize vyvíjením stylu programování. Budeme hovořit o důležitosti vytváření konzistentního, dobře zdokumentovaného programového kódu.

Kapitola 2 – OOP prostřednictvím návrhových vzorů Kapitola 2 podrobně pojednává o objektově orientovaném programování (OOP) v PHP. Schopnosti jsou předvedeny v kontextu prozkoumávání celé řady běžných designérských vzorů. Díky kompletnímu přehledu jak nových vlastností OOP v PHP5, tak i nápadů se vzorem OOP, je tato kapitola určena nejen pro nováčky v oblasti objektového programování, ale i pro zkušené programátory.

Kapitola 3 – Zpracování chyb Chyby jsou nedílnou součástí života, proto s nimi musíme počítat. V kapitole 3 se budeme zabývat jak procedurálními, tak i OOP metodami pro ošetření chyb. Zejména se zaměříme na nové schopnosti PHP 5 pro ošetření chyb na základě výjimek.

Kapitola 4 – Implementujeme s PHP: Šablony a web V kapitole 4 se podívám na šablonové systémy – sady nástrojů, které zjednodušují rozdvojení zobrazení a aplikace. Srovnáme si výhody a nevýhody hotových šablonových systémů (jako příklad je použit systém Smarty) a ad hoc šablonových systémů.

Kapitola 5 – Implementujeme s PHP: Samostatné skripty Velmi málo dnešních webových aplikací nemá žádnou back-endovou komponentu. Schopnost znovu použít stávající kód PHP pro psaní dávkových úloh, shell skriptů a rutin pro jiné než webové zpracování je zásadní pro užitečnost jazyka v podnikovém prostředí. V kapitole 6 si probereme základy psaní samostatných skriptů a démonů v PHP.

16

Pokročilé programování v PHP 5

Kapitola 6 – Testování jednotek Testování jednotek je způsob validace, že váš kód dělá přesně to, co má. V kapitole 6 se podíváme na strategie jednotkového testování a předvedeme si, jak implementovat flexibilní sady jednotkového testování s PHPUnit.

Kapitola 7 – Správa vývojového prostředí Pro většinu vývojářů nepředstavuje řídící kód příliš vzrušující úkol, přesto je zásadní. V kapitole 7 se podíváme na řídící kód ve velkých projektech a podrobně vás uvedeme do používání CVS (Concurrent Versioning System) pro správu PHP projektů.

Kapitola 8 – Návrh dobrého API V kapitole 8 najdete návody na vytváření kódové základny, která je spravovatelná, flexibilní a jednoduše slučitelná s dalšími projekty.

Část II – Cachování Kapitola 9 – Vnější ladění výkonu Použití cachovacích strategií je jednoduše nejefektivnější způsob, jak zvýšit výkon a škálovatelnost aplikací. V kapitole 9 se blíže podíváme na externí cachovací strategie PHP a budeme se zabývat kompilátory a proxy cache.

Kapitola 10 – Cachování dat V kapitole 10 budeme o hovořit o tom, jak lze začlenit cachovací strategie do samotného kódu PHP. Řekneme si, jak a kdy integrovat cachování do aplikace a vyvineme plně funkční cachovací systém s několika back-endy pro ukládání.

Kapitola 11 – Znovupoužití výpočtů V kapitole 11 se budeme zabývat vytvářením jednotlivých algoritmů a efektivnějším zpracováním pomocí ukládání intermediálních dat, tzn. dat, která nejsou konečným výsledkem funkce. V této kapitole vyvineme obecnou teorii za využíváním výsledků výpočtů (computation reuse) a aplikujeme ji na praktické příklady.

Část III – Distribuované aplikace Kapitola 12 – Interakce s databázemi Databáze jsou hlavní komponentou téměř všech dynamických webových stránek. V kapitole 12 se zaměříme na efektivní strategie pro přemostění PHP a databázových systémů.

Úvodní povídání

17

Kapitola 13 – Autentizace uživatele a bezpečnost relace V kapitole 13 prozkoumáme metody pro řízení autentizace uživatele a zabezpečování komunikace klient-server. Tato kapitola se rovněž zaměřuje na ukládání zašifrovaných informací o relaci v cookie a plnou implementaci systému jednorázového přihlášení.

Kapitola 14 – Zpracování relace V kapitole 14 budeme pokračovat v problematice uživatelských relací a probereme si rozšíření relace PHP a vytváření uživatelských ovladačů relace.

Kapitola 15 – Tvorba distribuovaného prostředí V kapitole 15 budeme hovořit o tom, jak vytvářet škálovatelné aplikace. Dále si detailně prozkoumáme vytváření a řízení počítačových clusterů pro efektivní řízení cachování a databázových systémů.

Kapitola 16 – RPC: Interakce se vzdálenými službami Webové služby představují termín pro služby, které poskytují jednoduchou komunikaci mezi počítači přes web. V této kapitole se podíváme na dva nejběžnější protokoly: XML-RPC a SOAP.

Část IV – Výkon Kapitola 17 – Srovnávací testy: testování celé aplikace Srovnávací testy aplikace jsou nepostradatelné pro zjištění, zdali je aplikace schopna zvládnout provoz, k jehož zpracování byla vytvořena a pro identifikaci komponent, které představují potencionální slabé místa systému. V kapitole 17 se podíváme na různé sady srovnávacích testů aplikací, které vám umožní měřit výkon a stabilitu aplikace.

Kapitola 18 – Profilování Po použití technik srovnávacích testů pro identifikaci rozsáhlých potenciálních slabin aplikace, můžete aplikovat nástroje profilování k izolaci specifických problémových oblastí v kódu. V kapitole 18 budeme hovořit o profilování a poskytneme vám podrobný návod na použití profileru APD (Advanced PHP Debugger) k prozkoumání kódu.

Kapitola19 – Syntetické benchmarky: zaostřeno na bloky kódu a funkce Není možné porovnat dvě části kódu, pokud nemůžete kvantitativně změřit jejich rozdíly. V kapitole 19 se podíváme na metodologie srovnávacích testů a projdeme si implementaci a hodnocení sad uživatelských srovnávacích testů.

18

Pokročilé programování v PHP 5

Část V – Rozšiřitelnost Kapitola 20 – Pohled do útrob PHP a Zend Enginu Informace o tom, jak PHP funguje „zevnitř“ vám pomohou provádět racionální rozhodnutí, které využívají silné stránky PHP a vyhýbají se slabinám. V kapitole 20 se podíváme z technického hlediska na nejenom na vnitřní funkci PHP, ale také na to, jak aplikace jako např. webové servery komunikují s PHP, jak se skripty syntakticky analyzují do intermediálního kódu a jak probíhá provádění skriptu v Zend Engine.

Kapitola 21 – Rozšiřujeme PHP: část I V kapitola 21 vás důkladně uvedeme do problematiky tvorby rozšíření PHP v jazyce C. Budeme se zabývat přenášením stávajícího kódu PHP do C a vytvářením rozšíření, které poskytují PHP přístup ke knihovnám třetích stran v jazyce C.

Kapitola 22 – Rozšiřujeme PHP: část II V kapitole 22 navážeme na téma z kapitoly 21 a podíváme se na pokročilé náměty jako např. vytváření tříd v kódu rozšíření a používání proudů a zařízení relací.

Kapitola 23 – Vytváříme rozhraní SAPI a rozšiřujeme Zend Engine V kapitole 23 se podíváme na to, jak se vnořuje kód PHP do aplikací a na rozšíření Zend Engine pro modifikaci základního chování jazyka.

Platformy a verze Tato kniha se zaměřuje na PHP 5, ale s výjimkou zhruba 10% materiálu (nové objektově orientované vlastnosti popisované v kapitole 2 a 22 a pojednání o protokolu SOAP v kapitole 16) není v této knize nic, co by bylo specifické výhradně pro PHP 5. Tato kniha je o nápadech a strategiích, s jejichž pomocí bude váš kód rychlejší, chytřejší a lépe navržený. Doufáme, že přinejmenším polovinu informací obsažených v této knize budete moci použít pro zlepšení kódu napsaného v libovolném jazyce.

Všechno v této knize bylo napsáno a otestováno na Linuxu a mělo by bez jakýchkoliv modifikací fungovat na systémech Solaris, OS X, FreeBSD nebo jakémkoliv jiném unixovém klonu. Většina skriptů by měla fungovat s minimálními modifikacemi ve Windows, ačkoli některé používané utility (zejména utilita pcnt1 v kapitole 5) nemusí být zcela přenositelné.

2

OOP prostřednictvím návrhových vzorů

Jasně největší a neproklamovanější změnou v PHP5 je kompletní přepracování objektového modelu a značně vylepšená podpora standardních objektově orientovaných (OO) metodologií a technik. Tato kniha není zaměřena na techniku objektově orientovaného programování (OOP) a ani není o návrhových vzorech. Těmto tématům se věnuje mnoho jiných knih (některé jsou uvedeny na konci této kapitoly). Místo toho se v této kapitole budeme věnovat přehledu rysů OOP v PHP5 a některým obecným návrhovým vzorům.

Já mám spíše agnostický pohled na využití OOP v PHP. Pro mnohé problémy je použití metod OOP jako použití kladiva k zabití mouchy. Úroveň abstrakce, která je zde použita, se mi jeví zbytečná pro zvládnutí jednoduchých úkolů. Metody OOP jsou vhodné pro řešení komplexnějších systémů. Již jsem pracoval na několika rozsáhlých projektech, které opravdu těžily z toho, že byly navrženy modulárně s využitím technik OOP. V této kapitole je popsán přehled pokročilých rysů OOP, které jsou nyní podporovány v PHP. Některé zde uvedené příklady budou použity i v dalších částech knihy a budou – doufejme – sloužit jako ukázky toho, jak lze prostřednictvím OOP úspěšně řešit určité problémy.

Objektově orientované programování znamená zásadní změnu od procedurálního programování, které je tradiční technikou programátorů PHP. U procedurálního programování máte data (uložená v proměnných), která předáváte funkcím a ty pak provádí s těmito daty různé operace, mohou je modifikovat, či vytvářet z nich data nová. Procedurální programování je tradičně seznam instrukcí, které se vykonávají v daném pořadí pomocí výrazů řízení toku, funkcí apod. Zde následuje příklad takovéhoto procedurálního kódu: <?php function hello($name)

50

Pokročilé programování v PHP 5

{ return "Hello $name!\n"; } function goodbye($name) { return "Goodbye $name!\n"; } function age($birthday) { $ts = strtotime($birthday); if($ts === -1) { return "Unknown"; } else { $diff = time() – $ts; return floor($diff/(24*60*60*365)); } } $name = "george"; $bday = "10 Oct 1973"; print hello($name); print "You are ".age($bday)." years old.\n"; print goodbye($name); ? >

Objektově orientované programování Úvodem je důležité poznamenat, že v procedurálním programování jsou funkce a data od sebe navzájem odděleny. V OOP jsou data a funkce, které s těmito daty operují, navzájem svázány do objektů.

Objekty obsahují jak data (nazývané attributy nebo vlastnosti), tak i funkce, které těmito daty operují (nazývané metody).

Objekt je definován třídou, jejíž je instancí. Třída definuje atributy, které objekt obsahuje a metody, které může použít. Objekt vytvoříte vytvořením instance třídy. Vytvořením instance se vytvoří nový objekt, incializují se všechny jeho atributy a je volán jeho konstruktor, což je funkce, která provádí všechny operace prvotního nastavení. Konstruktor třídy bývá v PHP 5 nazýván _ _construct(), což umožňuje jeho jednoduchou identifikaci. Následující příklad definuje jednoduchou třídu User, vytváří její instanci a volá její dvě metody: <?php class User { public $name; public $birthday; public function _ _construct($name, $birthday)

Kapitola 2 – OOP prostřednictvím návrhových vzorů

51

{ $this->name = $name; $this->birthday = $birthday; } public function hello() { return "Hello $this->name!\n"; } public function goodbye() { return "Goodbye $this->name!\n"; } public function age() { $ts = strtotime($this->birthday); if($ts === -1) { return "Unknown"; } else { $diff = time() – $ts; return floor($diff/(24*60*60*365)) ; } } } $user = new User('george', '10 Oct 1973'); print $user->hello(); print "You are ".$user->age()." years old.\n"; print $user->goodbye(); ?>

Spuštění tohoto kódu vyvolá následující: Hello george!

You are 29 years old.

Goodbye george!

Konstruktor je v tomto příkladu velmi jednoduchý – pouze inicializuje dva atributy, jméno (name) a datum narození (birthday). Metody jsou rovněž triviální. Poznamenejme, že parametr $this je automaticky vytvořen uvnitř metod třídy a reprezentuje samotný objekt User. Pro přístup k vlastnostem nebo metodám objektu použijte notaci ->.

Na první pohled zde není vidět mnoho rozdílů mezi asociačním polem a kolekcí funkcí, které ji reprezentují. Nicméně, existují některé další důležité vlastnosti, které si popíšeme v následujících částech:

• Dědičnost – Dědičnost je schopnost odvozovat novou třídu ze stávající a zdědit nebo přepsat její atributy a metody.

52

Pokročilé programování v PHP 5

• Zapouzdření – Zapouzdření je schopnost skrýt data před uživatelem třídy.

• Speciální metody – Jak uvidíte dále, třídy umožňují, v okamžiku, kdy je nový objekt vytvářen, pomocí konstruktoru vykonat prvotní inicializaci (např. nastavení atributů). Dále jsou rovněž generovány další události, které nastávají při určitých příležitostech, jakými jsou např. kopírování, rušení objektu apod.

• Polymorfismus – Když dvě třídy implementují stejné externí metody, je možné ve funkcích použít zaměnitelnost. Protože k úplnému pochopení polymorfismu je třeba větší znalostní báze než v této chvíli máme, popíšeme si ho později v této kapitole v části věnované polymorfismu.

Dědičnost Dědičnost můžete využít, pokud chcete vytvořit novou třídu, která má mít podobné vlastnosti nebo chování jako již existující třída. K zajištění dědičnosti podporuje PHP schopnost třídy rozšířit se o již existující třídu. Když třídu rozšíříte, nová třída zdědí všechny vlastnosti a metody svého rodiče (se dvěma výjimkami, které si popíšeme později v této kapitole). Dále pak můžeme buď přidat nové vlastnosti a metody nebo přepsat již existující. Dědičný vztah je definován klíčovým slovem extends. Nyní si rozšíříme třídu User, nová třída bude reprezentovat uživatele s právy administrátora. Třídu rozšíříme o vybrání uživatelského hesla ze souboru NDBM a přidáme funkci umožňující porovnání tohoto hesla se zadaným heslem: class AdminUser extends User{ public $password; public function _ _construct($name, $birthday) { parent::_ _construct($name, $birthday); $db = dba_popen("/data/etc/auth.pw", "r", "ndbm"); $this->password = dba_fetch($db, $name); dba_close($db); } public function authenticate($suppliedPassword) { if($this->password === $suppliedPassword) { return true; } else { return false; } } }

Třebaže je to úplně krátké, třída AdminUser automaticky zdědí všechny metody třídy User, takže můžete volat metody hello(), goodbye() a age(). Poznamenejme, že musíte ručně volat konstruktor

Kapitola 2 – OOP prostřednictvím návrhových vzorů

53

rodičovské třídy: parent::_ _constructor(); PHP5 automaticky nevolá konstruktor rodiče. Parent je klíčové slovo, které vyjadřuje, že se jedná o třídu rodiče.

Zapouzdření Uživatelé přecházející z procedurálního jazyka nebo PHP 4 si mohou myslet, že všechno kolem je veřejné. PHP verze 5 umožňuje rozdělit viditelnost dat atributů a metody na veřejnou, chráněnou a privátní. Tyto typy jsou normálně označovány zkratkou PPP (public, protected, private) a mají standardní sémantiku:

• Public – Veřejná proměnná nebo metoda, která může být přímo přístupná jakémukoli uživateli třídy.

• Protected – Chráněná proměnná nebo metoda, která nemůže být přístupná uživatelům třídy, ale může být přístupná uvnitř podtřídy, která tuto třídu dědí.

• Private – Privátní proměnná nebo metoda, která může být přístupná pouze uvnitř třídy, ve které je definována. To znamená, že privátní proměnná nebo metoda nemůže být volána z potomka dané třídy.

Zapouzdření umožňuje definovat veřejné rozhraní, které určuje způsob, jakým může uživatel s třídou komunikovat. Metody, které nejsou veřejné můžete předělat nebo změnit bez toho, abyste se znepokojovali tím, že poškodíte kód, který jste zdědili z nějaké třídy. Beztrestně rovněž můžete přepsat privátní metody. Přepsání chráněných metod vyžaduje více péče, abyste se vyvarovali přerušení vazby podtříd.

Zapouzdření není v PHP nezbytné (pokud není použito, metody a proměnné jsou považovány za veřejné), ale pokud je to jenom trochu možné, je dobré zapouzdření využít. V jednoprogramátorském prostředí a zvláště pak při týmové práci je velkou chybou vyhýbat se veřejným rozhraním objektu a provádět přímý přístup k proměnným a k metodám. Takové přístupy rychle vedou k neudržitelnosti kódu, protože místo jednoduchého veřejného rozhraní se dostanete do stavu, kdy jsou všechny metody třídy neschopné přepracování bez toho, aniž byste nezpůsobili chyby v třídě, která tyto metody používá. Použití PPP vás zavazuje používat tuto dohodu a zajišťuje, že v externím kódu jsou použity pouze veřejné metody bez ohledu na lákadlo přímého přístupu.

Statické (třídní) atributy a metody V PHP mohou být navíc metody a vlastnosti deklarovány jako statické. Statická metoda je vázána přímo na třídu, ne k instanci této třídy (objektu). Statické metody jsou volány pomocí syntaxe ClassName:: method(). Použití proměnné $this uvnitř statické metody není možné.

Statická vlastnost je proměnná třídy, která je spojena se třídou, ne s instancí třídy. Tzn., že když je vlastnost změněna, projeví se tato změna ve všech instancích dané třídy. Statické proměnné jsou deklarovány klíčovým slovem static a jsou přístupné prostřednictvím syntaxe ClassName::$property. Následující příklad ukazuje, jak taková statická proměnná funguje: class TestClass { public static $counter;

54

Pokročilé programování v PHP 5

} $counter = TestClass::$counter;

Pokud chcete ke statické proměnné přistupovat uvnitř třídy, můžete rovněž použít kouzelná klíčová slova self a parent, která rozlišují, zdali se jedná o danou třídu nebo jejího rodiče. Použití klíčových slov self a parent umožňuje vyhnout se explicitní referenci na název třídy. Zde je jednoduchý příklad, který využívá statickou vlastnosti k přiřazení unikátního celočíselného ID pro každou instanci třídy: class TestClass { public static $counter = 0; public $id; public function _ _construct() { $this->id = self::$counter++; } }

Speciální metody Třídy v PHP mají vyhrazeny určité názvy metod jako speciální volání pro zpracování určitých událostí.

Už jste se setkali s metodou _ _construct(), která je automaticky volána, když je vytvářena instance objektu. Třídy využívají dalších pět speciálních metod: _ _get(), _ _set() a _ _call() ovlivňující způsob, jakým jsou vlastnosti a metody objektu volány a jsou popsány později v této kapitole. Zbylé dvě metody jsou _ _destruct() a _ _clone(). _ _destruct() je metoda volaná při rušení objektu. Destruktory jsou vhodné pro uvolnění zdrojů

(např. napojení na soubor nebo databázi), které třída vytvořila. V PHP jsou proměnné referenčně počítány. Když je počítadlo referencí proměnné sníženo na nulu, je proměnná automaticky odstraněna ze systému. Pokud je proměnnou objekt, je volána jeho metoda _ _destruct().

Následující jednoduché zabalení funkcí pracujících v PHP se souborem ukazuje využití destruktoru: class IO { public $fh = false; public function _ _construct($filename, $flags) { $this->fh = fopen($filename, $flags); } public function _ _destruct() { if($this->fh) { fclose($this->fh); } } public function read($length)

Kapitola 2 – OOP prostřednictvím návrhových vzorů

55

{ if($this->fh) { return fread($this->fh, $length); } } /* ... */ }

V mnoha případech je vytváření destruktoru zbytečné, protože PHP na konci požadavku uvolňuje všechny použité zdroje. Pro dlouhotrvající skripty nebo skripty, které otevírají velký počet souborů, je však uvolňování zdrojů důležité.

V PHP 4 jsou objekty předávány svou hodnotou. Tzn. pokud v PHP 4 napíšete: $obj = new TestClass; $copy = $obj;

vytvoříte aktuálně tři kopie dané třídy: Jedna instance objektu je vytvořena při deklaraci, druhá během přiřazení návratové hodnoty z konstruktoru do $obj a třetí, když přiřadíte $copy proměnné $obj. Tato sémantika je úplně odlišná od sémantiky ve všech ostatních objektově orientovaných jazycích a v PHP 5 je již od ní upuštěno.

Když v PHP 5 vytváříte objekt, vracíte handle na tento objekt, který je obdobný v pojetí s referencí s C++. Když spustíte předchozí kód v PHP 5, vytvoříte pouze jednu instanci daného objektu; nevytvoříte žádnou jeho další kopii.

Pro vytvoření aktuální kopie objektu musíte v PHP 5 použít metodu _ _clone(). Takže předcházející příklad, ve kterém vytváříme v $copy aktuální kopii objektu $obj (a nikoliv jenom další referenci na stejný objekt), bude vypadat následovně: $obj = new TestClass; $copy = $obj->_ _clone();

Pro některé třídy není možné použít předpřipravenou metodu _ _clone(), ale PHP dovoluje její přepsání. Uvnitř metody _ _clone() máte proměnnou $this, která je novým objektem se všemi původními vlastnostmi objektu, které byly zkopírovány. Např. ve třídě TestClass, definované již dříve v této kapitole, byste použitím defaultní metody _ _clone(), zkopírovali i její vlastní proměnnou id. Proto musíte upravit tuto třídu následovně: class TestClass { public static $counter = 0; public $id; public $other; public function _ _construct() { $this->id = self::$counter++; }

56

Pokročilé programování v PHP 5

public function _ _clone() { $this->id = self::$counter++; } }

Stručný úvod do návrhových vzorů Určitě jste již o návrhových vzorech někdy slyšeli, ale nevěděli jste co tento pojem vlastně znamená. Návrhové vzory jsou zevšeobecněná řešení tříd problémů, se kterými se programátoři setkávají nejčastěji.

Když se programování věnujete už nějaký delší dobu, určitě máte potřebu přizpůsobit si danou knihovnu tak, aby byla přístupná prostřednictvím různých API. Nejste sami. Toto je obecný problém. Je sice pravda, že neexistuje nějaké obecné řešení, které řeší všechny problémy – nicméně, lidé tento typ problému znají a řeší jej stále znovu a znovu. Základní myšlenkou návrhových vzorů je, že problémy a jejich odpovídající řešení mají sklon k následování pomocí opakujících se šablon.

Návrhové vzory však bývají někdy nedoceňovány. Před lety jsem odmítl využít návrhové vzory bez toho, aniž bych o nich reálně uvažoval. Moje problémy byly natolik specifické a složité, že jsem si myslel, že se na ně nehodí žádná šablona. To bylo ode mně opravdu krátkozraké.

Návrhové vzory poskytují slovník pro identifikaci a klasifikaci problémů. V Egyptské mytologii měly božstva a další entity tajná jména a až když jste tato jména objevili, mohli jste ovládat jejich "božskou sílu". Problémy návrhu jsou v přírodě velmi podobné. Když můžete rozeznat správné řešení problému v přírodě a ztotožnit ho se známou množinu obdobných (řešených) problémů, dostanete se na správnou cestu k jejich řešení.

Tvrdit, že jedna kapitola o návrhových vzorech vám bude stačit, je směšná. V následujících částech si popíšeme několik vzorů, hlavně jako prostředek pro popsání některých pokročilých objektově orientovaných technik, které jsou v PHP k dispozici.

Adaptér vzoru Adaptér vzoru poskytuje přístup k objektu prostřednictvím specifického rozhraní. V čistě objektově orientovaném jazyku umožňuje adaptér vzoru provázání alternativního API s objektem; ale v PHP se často spíše setkáme s tím, jak takový adaptér vzoru poskytuje alternativní rozhraní k sadě procedur.

Poskytnutí rozhraní s objektem prostřednictvím specifického API může být užitečné z těchto dvou hlavních důvodů:

• Když různé třídy poskytují podobné služby a implementují stejné API, můžete se mezi nimi v průběhu programu přepínat. Toto je známo jako polymorfismus. Toto slovo pochází z latiny: Poly znamená "mnoho" a morph znamená "tvar" čili "mnohotvárnost".

Kapitola 2 – OOP prostřednictvím návrhových vzorů

57

• Může být obtížné změnit předdefinovaný systém pro využívání sady objektů. Když do projektu začleňujete třídu třetí strany, která není kompatibilní s použitým API systému, je často nejjednodušším řešením použít adaptér poskytující přístupu k danému API. Nejběžnější způsob použití adaptérů v PHP není při vytváření alternativního rozhraní pro spojení jedné třídy s druhou (protože to je v komerčním kódu PHP limitováno placenou částkou a v otevřeném kódu můžete takovéto rozhraní změnit přímo). PHP má svůj původ v procedurálním jazyku, a proto jsou mnohé předpřipravené funkce PHP jsou ze své podstaty procedurální. Když je potřeba, aby byly funkce spouštěny postupně, v daném pořadí (např. když pracujete s databází, musíte použít postupně funkce mysql_pconnect(), mysql_select_db(), mysql_query() a mysql_fetch()), jsou pro uchování dat pro napojení na databázi použity určité zdroje a vy je musíte předávat do všech těchto funkcí.

Zabalením celého takového procesu do třídy se můžete zbavit stále se opakující činnosti a vyhnete se generování následných chyb. Řekněme, že bychom chtěli vytvořit objektové rozhraní pro dvě základní zdrojové funkce MySQL: pro napojení se na databázi a pro získání výsledných dat. Naším cílem není napsat úplnou abstrakci, ale jednoduše vytvořit dostatečně zabalený kód, který bude zpřístupňovat všechny rozšiřující funkce MySQL objektově orientovaným způsobem a přidá navíc několik dalších praktických věcí.

Zde je první pokus, jak zabalit třídu: class DB_Mysql { protected $user; protected $pass; protected $dbhost; protected $dbname; protected $dbh; // Database connection handle public function _ _construct($user, $pass, $dbhost, $dbname) { $this->user = $user; $this->pass = $pass; $this->dbhost = $dbhost; $this->dbname = $dbname; } protected function connect() { $this->dbh = mysql_pconnect($this->dbhost, $this->user, $this->pass); if(!is_resource($this->dbh)) { throw new Exception; } if(!mysql_select_db($this->dbname, $this->dbh)) { throw new Exception; } } public function execute($query) { if(!$this->dbh) {

58

Pokročilé programování v PHP 5 $this->connect();

} $ret = mysql_query($query, $this->dbh); if(!$ret) { throw new Exception; } else if(!is_resource($ret)) { return TRUE; } else { $stmt = new DB_MysqlStatement($this->dbh, $query); $stmt->result = $ret; return $stmt; } } }

Pomocí tohoto rozhraní můžete vytvořit nový objekt DB_Mysql, při inicializaci mu předat přístupové údaje k databázi MySQL a tím se na ní napojit (uživatelské jméno, heslo, stanice a název databáze): $dbh = new DB_Mysql("testuser", "testpass", "localhost", "testdb"); $query = "SELECT * FROM users WHERE name = '".mysql_escape_string($name)."'"; $stmt = $dbh->execute($query); Tento kód vrací objekt DB_MysqlStatement, což je objekt, který zabaluje výstup z MySQL databáze: class DB_MysqlStatement { protected $result; public $query; protected $dbh; public function _ _construct($dbh, $query) { $this->query = $query; $this->dbh = $dbh; if(!is_resource($dbh)) { throw new Exception("Not a valid database connection"); } } public function fetch_row() { if(!$this->result) { throw new Exception("Query not executed"); } return mysql_fetch_row($this->result); } public function fetch_assoc() { return mysql_fetch_assoc($this->result);

Kapitola 2 – OOP prostřednictvím návrhových vzorů

59

} public function fetchall_assoc() { $retval = array(); while($row = $this->fetch_assoc()) { $retval[] = $row; } return $retval; } }

K vypsání jednotlivých řádků výsledku dotazu musíte místo použití funkce mysql_fetch_assoc(), použít následující konstrukci: while($row = $stmt->fetch_assoc()) { // process row }

Následuje několik poznámek k uvedené implementaci:

• Vyhýbá se manuálnímu volání funkcí connect() a mysql_select_db().

• Při chybě vyvolá výjimku. Výjimky jsou v PHP 5 novým rysem. Zde o nich ještě nebudeme mluvit, ale podrobně si je popíšeme v druhé polovině kapitoly 3 popisující zpracování chyb.

• Tento kód není moc praktický. Neexistuje způsob, jak jednoduše znovu použít nebo upravit dotaz – pro jiný dotaz musíte znovu všechna data kódu přepsat.

Na základě těchto tří problémů můžete toto rozhraní rozšířit tak, aby umožňovalo automaticky zabalit všechna data, která mu pošlete. Nejjednodušší cestou, jak to udělat, je provést emulaci všech připravených dotazů. Když spouštíte znovu dotaz na databázi, hrubé SQL, které zde vytváříte, musí být nejprve přeloženo do formátu, kterému databáze vnitřně rozumí. Tento krok vyžaduje zvýšené nároky na výkon a mnohé databázové systémy tento problém řeší cachováním. Uživatel si může dotaz předpřipravit, což způsobí, že databáze si provede rozbor tohoto dotazu a vrací jakýsi předkompilovaný zdroj, který je pak použit k vlastní reprezentaci dotazu. Takováto vlastnost je často spojována s pojmem vázání SQL. Vázání SQL umožňuje provést rozbor dotazu v souladu s umístěním dat, se kterými budou vaše proměnné následně svázány. Následně pak můžete svázat parametry s předkompilovanou verzí dotazu ještě před jeho spuštěním. V mnoha databázových systémech (zejména v Oracle) je použití vázání dat SQL významnou výkonnostní výhodou.

Verze MySQL před verzí 4.1 neposkytuje samostatné uživatelské rozhraní k přípravě dotazů před jejich spuštěním, ani neumožňuje vázání SQL. To pro nás znamená posílat všechna měnící se data ke zpracování samostatně, zajistit vhodné místo k uložení proměnných a uchovávat je až do doby, než budou vloženy do dotazu. Rozhraní nové verze MySQL 4.1 je vybudováno na základě rozšíření mysqli od Georga Richtera a poskytuje nové funkčnosti.

Abychom těchto nových vlastností mohli využít, musíme rozšířit třídu DB_Mysql o metody prepare a do třídy DB_MysqlStatement vložit metody bind a execute:

60

Pokročilé programování v PHP 5

class DB_Mysql { /* ... */ public function prepare($query) { if(!$this->dbh) { $this->connect(); } return new DB_MysqlStatement($this->dbh, $query); } } class DB_MysqlStatement { public $result; public $binds; public $query; public $dbh; /* ... */ public function execute() { $binds = func_get_args(); foreach($binds as $index => $name) { $this->binds[$index + 1] = $name; } $cnt = count($binds); $query = $this->query; foreach ($this->binds as $ph => $pv) { $query = str_replace(":$ph", "'".mysql_escape_string($pv)."'", $query); } $this->result = mysql_query($query, $this->dbh); if(!$this->result) { throw new MysqlException; } return $this; } /* ... */ }

Metoda prepare() v tomto příkladu neprovádí nic, jen jednoduše vytváří nový objekt DB_MysqlStatement, který specifikuje dotaz. Skutečná práce je prováděná třídou DB_MysqlStatement. Pokud nemáme vázané parametry, můžete tyto objekty volat takto: $dbh = new DB_Mysql("testuser", "testpass", "localhost", "testdb"); $stmt = $dbh->prepare("SELECT * FROM users WHERE name = '".mysql_escape_string($name)."'"); $stmt->execute();

Kapitola 2 – OOP prostřednictvím návrhových vzorů

61

Skutečnou výhodou použití zabaleného objektu oproti použití normálního procedurálního volání je, že k dotazu můžete navázat parametry. To provedete tak, že do textu dotazu vložíte výraz začínající dvojtečkou (:), který naváže daná data dotazu až v době provádění kódu: $dbh = new DB_Mysql("testuser", "testpass", "localhost", "testdb"); $stmt = $dbh->prepare("SELECT * FROM users WHERE name = :1"); $stmt->execute($name);

Výraz :1 v dotazu označuje, že se jedná o umístění první svázané proměnné. Když zavoláte metodu execute() objektu $stmt, tato metoda tento výraz rozpozná a přiřadí mu hodnotu prvního předaného argumentu ($name) a doplní hodnotu této proměnné za výraz :1 v dotazu.

Dokonce, i když toto navázané rozhraní nemá normální výkonnostní výhodu vázaného rozhraní, poskytuje vhodný způsob, jak se jednoduše vyhnout přepisování všech vstupů v dotazu.

Šablona vzoru Šablona vzoru popisuje třídu, jež modifikuje logiku podtřídy, čímž ji rozšiřuje. Šablonu vzoru můžete např. využít ke skrytí všech parametrů specifikujících napojení na databázi, které jsme používali v předchozích třídách. Při použití tříd z předchozích částí musíte specifikovat konstanty parametrů pro připojení: <?php require_once 'DB.inc'; define('DB_MYSQL_PROD_USER', 'test'); define('DB_MYSQL_PROD_PASS', 'test'); define('DB_MYSQL_PROD_DBHOST', 'localhost'); define('DB_MYSQL_PROD_DBNAME', 'test'); $dbh = new DB::Mysql(DB_MYSQL_PROD_USER, DB_MYSQL_PROD_PASS, DB_MYSQL_PROD_DBHOST, DB_MYSQL_PROD_DBNAME); $stmt = $dbh->execute("SELECT now()"); print_r($stmt->fetch_row()); ?>

Abychom se vyhnuli specifikaci konstant parametrů připojení, můžeme definovat podtřídu DB_Mysql a v ní natvrdo zadat parametry pro připojení k databázi test: class DB_Mysql_Test extends DB_Mysql { protected $user = "testuser"; protected $pass = "testpass"; protected $dbhost = "localhost"; protected $dbname = "test"; public function _ _construct() { } }

62

Pokročilé programování v PHP 5

Obdobně můžeme to samé udělat pro ostrou databázi: class DB_Mysql_Prod extends DB_Mysql { protected $user = "produser"; protected $pass = "prodpass"; protected $dbhost = "prod.db.example.com"; protected $dbname = "prod"; public function _ _construct() { } }

Polymorfismus Objekty určené pro práci s databází, popsané v této kapitole, jsou dobře obecně použitelné. Ale ve skutečnosti, když se podíváte na jiné databázové rozšíření vytvořené v PHP, najdete v nich vždy znovu a znovu stejnou základní funkčnost – napojení se na databázi, příprava dotazů, spuštění dotazů a zpracování výsledků. Když budete chtít, můžete napsat obdobné třídy DB_Pgsql nebo DB_Oracle, které zabalí knihovny pro PostgreSQL, respektive Oracle a v nich můžete použít úplně stejné základní metody.

Je ale vždy důležité použít pro metody, které provádějí stejný druh operace vždy totožné názvy metod, a to i v případě, že tyto metody jsou vnitřně nekompatibilní. To následně umožňuje polymorfismus, což je schopnost transparentně zaměnit jeden objekt za jiný, jejichž přístupové API jsou shodné.

Prakticky: polymorfismus znamená, že můžete například napsat funkci: function show_entry($entry_id, $dbh) { $query = "SELECT * FROM Entries WHERE entry_id = :1"; $stmt = $dbh->prepare($query)->execute($entry_id); $entry = $stmt->fetch_row(); // display entry }

Tato funkce nepracuje pouze, když je proměnná $dbh objekt typu DB_Mysql, ale bude pracovat správně s jakýmkoli typem objektu $dbh, který má implementovanou metodu prepare() a tato metoda vrací objekt, který má implementovány metody execute() a fetch_assoc().

Abychom daný databázový objekt předali do všech volaných funkcí, můžeme využít princip delegace. Delegace je objektově orientovaný model, kdy objekt má jako atribut jiný objekt, který používá k provádění daných úloh.

Knihovny zapouzdřující databázi jsou ideálním příkladem objektu, který využívá právě delegace. V normálních aplikacích mnohé třídy potřebují provádět databázové operace. Při tvorbě takovýchto tříd máte dvě možnosti:

• Všechna databázová volání můžete implementovat nativně. To je směšné. Toto řešení je jen pro nouzovou práci, kterou pak musíte dělat stále znovu a znovu a takovéto zabalení databáze je vlastně zbytečné.

Kapitola 2 – OOP prostřednictvím návrhových vzorů

63

• Můžete použít zabalené API databáze, ale vlastní objekty inicializovat mimo. Zde je příklad, který takovouto možnost využívá: class Weblog { public function show_entry($entry_id) { $query = "SELECT * FROM Entries WHERE entry_id = :1"; $dbh = new Mysql_Weblog(); $stmt = $dbh->prepare($query)->execute($entry_id); $entry = $stmt->fetch_row(); // display entry } }

Jak můžete vidět, inicializace objektu napojení na databázi mimo, se jeví jako dobrý nápad.

Můžete zde použít zabalenou knihovnu, což je dobré. Problém ale nastane, když chcete změnit databázi, která tuto třídu používá, to pak musíte vytvořit a změnit všechny funkce, které provádějí operace s databází.

• Použijete delegaci, a to tím, že třída Weblog obsahuje atribut, kterým je objekt zabalující databázi. Když je tato třída vytvářena, je vytvořen objekt zabalující databázi, který pak můžete použít pro všechny vstupně/výstupní operace. Zde je přepsána původní třída Weblog, která používá tuto techniku: class Weblog { protected $dbh; public function setDB($dbh) { $this->dbh = $dbh; } public function show_entry($entry_id) { $query = "SELECT * FROM Entries WHERE entry_id = :1"; $stmt = $this->dbh->prepare($query)->execute($entry_id); $entry = $stmt->fetch_row(); // display entry } }

Nyní můžete nastavit databázi do objektu následovně: $blog = new Weblog; $dbh = new Mysql_Weblog; $blog->setDB($dbh);

Samozřejmě můžete místo nastavení delegace databáze použít šablonu vzoru:

64

Pokročilé programování v PHP 5

class Weblog_Std extends Weblog { protected $dbh; public function _ _construct() { $this->dbh = new Mysql_Weblog; } } $blog = new Weblog_Std;

Delegace je výhodná vždy, když potřebujete provádět komplexní službu nebo službu, kterou je vhodné provádět uvnitř třídy. Dalším místem, kde se delegace běžně využívá, jsou třídy, které potřebují generovat výstup. Když je potřebné provádět výstup různými způsoby (např. v HTML, RSS [Rich Site Summary nebo také Really Simple Syndication] nebo prostém textu), vyplatí se vytvořit registr delegací umožňující generovat výstup, který chcete.

Rozhraní a kontrola typu Klíčem k úspěšné delegaci objektů je zaručení toho, že všechny třídy, které mají být použity jsou polymorfické. Když v objektu Weblog nastavíte jako parametr $dbh třídu, která nemá implementovánu metodu fetch_row(), vyvoláte při běhu programu fatální chybu. Takováto chyba při běhu programu se detekuje velice těžce a proto bychom měli již dopředu zajistit, že všechny objekty mají implementovány všechny požadované funkce.

K předcházení takovýchto chyb zavádí PHP 5 koncept rozhraní. Rozhraní (interface) je vlastně kostra třídy. Definuje všechny metody třídy, ale neobsahuje žádný jejich kód – pouze vzor toho, jaké má daná metoda argumenty.

Zde je základní rozhraní s názvem interface, které specifikuje metody potřebné pro napojení na databázi: interface DB_Connection { public function execute($query); public function prepare($query); }

Vždy, když pak budete chtít děděním rozšířit danou třídu, použijete toto rozhraní a protože neobsahuje kód, jednoduše rozpoznáte všechny funkce, které jsou v něm definovány a které budete muset implementovat.

Např. pokud má třída DB_Mysql implementovat všechny funkce specifikované v rozhraní DB_Connection, musíte ji deklarovat následovně: class DB_Mysql implements DB_Connection { /* definice třídy */ }

16

RPC: Interakce se vzdálenými službami

Jednoduše řečeno, služby vzdáleného volání procedur (RPC) poskytují standardizované rozhraní pro tvorbu volání funkcí nebo metod přes síť.

Prakticky každý aspekt webového programování obsahuje služby RPC. Na bázi RPC jsou požadavky HTTP provedené webovými prohlížeči na webové servery i dotazy zaslané databázovému serveru klienty databáze. I když oba tyto příklady jsou vzdálenými voláními, ve skutečnosti se nejedná o protokoly RPC. Postrádají generalizaci a standardizaci volání RPC; protokoly používané webovým serverem a databázovým serverem nelze například sdílet, přestože jsou vytvořeny na stejném síťovém protokolu.

Aby byl protokol RPC užitečný, měl by vykazovat následující vlastnosti:

• Generalizace – mělo by být snadné vkládat nové volatelné metody.

• Standardizace – jestliže znáte název a seznam parametrů metody, měli byste být schopni pro ni jednoduše sestavit požadavek.

• Jednoduše konvertovatelný – vrácená hodnota RPC by měla jít jednoduše zkonvertovat na příslušný nativní typ dat.

Samotný protokol HTTP nesplňuje žádné z těchto kritérií, ale poskytuje extrémně vhodnou transportní vrstvu pro zasílání požadavků RPC. V této kapitole se zaměříme na dva nejoblíbenější protokoly RPC a to XML-RPC a SOAP, které se tradičně implementují přes web.

408

Pokročilé programování v PHP 5

Použití protokolů RPC v aplikacích s velkým provozem I když jsou RPC extrémně flexibilními nástroji, vnitřně jsou pomalé. Jakýkoli proces, který využívá RPC se ihned prováže s výkonem a dostupností vzdálené služby. Dokonce i v nejlepším případě zaznamenáte zdvojnásobení času služby na každé obsluhované stránce. Jsou-li na vzdáleném koncovém bodu nějaké poruchy, celý web se může viset na dotazech RPC. U administrativních nebo málo využívaných služeb to nepředstavuje velký problém, avšak u produkčních nebo velmi navštěvovaných stránek to většinou není přijatelné.

Kouzelné řešení minimalizace dopadu na produkční služby a redukce problémů latence a dostupnosti webových služeb spočívá v implementaci cachovací strategie, díky níž se zbavíme přímé závislosti na vzdálené službě. O cachovacích strategií, které lze jednoduše adaptovat pro zpracování volání RPC, jsme hovořili v kapitole 10 a 11.

XML-RPC XML-RPC je předchůdcem protokolů RPC založených na XML. XML-RPC je nejčastěji zapouzdřen v požadavku a odezvě POST protokolu HTTP, ačkoli, jak si v krátkosti řekneme v kapitole 15, není to nezbytně nutné. Jednoduchý požadavek XML-RPC představuje dokument XML, který vypadá asi takto: <?xml version="1.0" encoding="UTF-8"?> <methodCall> <methodName>system.load</methodName> <params> </params> </methodCall>

Tento požadavek se odešle metodou POST na server XML-RPC. Server následně vyhledá a provede specifikovanou metodu (v tomto případě system.load) a předá specifikované parametry (v tomto případě se nepředají žádné parametry). Výsledek se poté předá zpět volajícímu. Vrácená hodnota tohoto požadavku představuje řetězec, který obsahuje aktuální zatížení počítače, získané z výsledku unixového příkazu uptime. Podívejte se na příklad výstupu: <?xml version="1.0" encoding="UTF-8"?> <methodResponse> <params> <param> <value> <string>0.34</string> </value> </param> </params> </methodResponse>

Kapitola 16 – RPC: Interakce se vzdálenými službami

409

Tyto dokumenty samozřejmě nemusíte sami vytvářet a interpretovat. Pro PHP existuje celá řada různých implementací XML-RPC. Obecně preferuji použití tříd PEAR XML-RPC, protože jsou distribuovány se samotným PHP. (Používá je instalátor PEAR.) Tudíž mají téměř 100% implementaci. Díky tomu existují pouze pramalé důvody poohlížet se po něčem jiném. Dialog XML-RPC se skládá ze dvou částí: požadavek klienta a odezva serveru.

Nejprve si něco řekneme o kódu klienta. Klient vytvoří dokument request, zašle jej na server a analyzuje (parse) odezvu. Následující kód generuje dokument požadavku znázorněný dříve v této sekci a analyzuje výslednou odezvu: require_once 'XML/RPC.php'; $client = new XML_RPC_Client('/xmlrpc.php', 'www.example.com'); $msg = new XML_RPC_Message('system.load'); $result = $client->send($msg); if ($result->faultCode()) { print "Error\n"; } print XML_RPC_decode($result->value());

Vytvořte nový objekt XML_RPC_Client, který předává vzdálené službě URI a adresu.

Poté se vytvoří XML_RPC_Message obsahující název metody, která se má vyvolat (v tomto případě system.load). Protože této metodě nejsou předány žádné parametry, není potřeba do zprávy vkládat další data.

Dále se přes metodu send() odešle zpráva na server. Výsledek se zkontroluje, zdali neobsahuje chybu.

Není-li výsledkem chyba, hodnota výsledku se dekóduje z formátu XML do nativního typu PHP a vytiskne se pomocí XML_RPC_decode().

Pro příjem požadavku, nalezení a provedení příslušného zpětného volání a vrácení odezvy musíte podporovat funkcionalitu na straně serveru. Podívejte se na příklad implementace, která zpracuje metodu system.load, kterou jste požadovali v kódu klienta: require_once 'XML/RPC/Server.php'; function system_load() { $uptime = `uptime`; if(preg_match("/load average: ([\d.]+)/", $uptime, $matches)) { return new XML_RPC_Response( new XML_RPC_Value($matches[1], 'string')); } } $dispatches = array('system.load' => array('function' => 'system_uptime')); new XML_RPC_Server($dispatches, 1);

Jelikož funkce PHP potřebné pro podporu příchozích požadavků jsou definovány, stačí pouze zpracovat system.load request, který se implementuje přes funkci system_load(). Tato funkce spustí

410

Pokročilé programování v PHP 5

příkaz uptime a extrahuje z počítače jednominutovou průměrnou zátěž. Dále serializuje extrahovanou zátěž do XML_RPC_Value a zabalí ji do XML_RPC_Response pro vrácení uživateli.

Dále se registruje funkce zpětného volání v odesílací mapě, která informuje server o tom, jak odeslat příchozí požadavky do specifických funkcí. Vytvoříte pole funkcí $dispatches, které se vyvolá. Tohle je pole, které mapuje názvy metod XML-RPC na názvy funkcí PHP. Nakonec se vytvoří objekt XML_ RPC_Server a předá se mu odesílací pole $dispatches. Druhý parametr 1 signalizuje, že by se měl požadavek obsloužit okamžitě s pomocí metody service() (která se volá interně).

Metoda service() hledá nezpracovaná data POST HTTP, analyzuje je pro požadavek XML-RPC a poté provede odeslání. Protože se spoléhá na autoglobální proměnnou PHP $HTTP_RAW_POST_DATA, musíte se ujistit, že máte v souboru php.ini zapnuto always_populate_raw_post_data.

Nyní byste měli obdržet následující, pokud umístíte kód serveru na www.example.com/xmlrpc.php a z libovolného počítače provedete kód klienta: > php system_load.php 0.34

případně jinou hodnotu udávající vaše průměrné jednominutové zatížení.

Tvorba serveru: implementace MetaWeblog API Síla XML-RPC spočívá v tom, že poskytuje standardizovanou metodu pro komunikaci mezi službami.

To je užitečné zejména, když neovládáte oba konce požadavku služby. XML-RPC vám umožní jednoduše vytvořit dobře definované rozhraní na poskytovanou službu. Příkladem toho je odesílací API web ogu.

K dispozici je celá řada systémů pro blogování na webu a existuje spousta nástrojů, které pomáhají lidem uspořádat a zaslat záznamy těmto systémům. Pokud by neexistovaly standardizované procedury, každý nástroj by musel podporovat každý weblog, aby byl obecně použitelný nebo každý weblog by musel podporovat všechny nástroje. Tento druh spleti relací by nebylo možné škálovat.

I když se množina funkcí a implementace weblogových systémů značně liší, je možné definovat množinu standardních operací, které je potřeba provést k odeslání záznamů systémům pro blogování na webu.

A následně, weblogy a nástroje musí implementovat pouze toto rozhraní, aby byly nástroje kompatibilní se všemi systémy pro blogování na webu.

Na rozdíl od velkého počtu systémů pro blogování, které jsou k dispozici, se obecně se používají pouze tři odesílací API weblogů: Blogger API, MetaWeblog API a MovableType API (což ve skutečnosti je pouze rozšíření MetaWeblog API). Všechny dostupné nástroje pro vytváření weblogů používají jeden z těchto tří protokolů, a proto, pokud implementujete tyto API, váš weblog bude schopen komunikovat s jakýmkoliv nástrojem. Tohle je obrovská výhoda pro vytváření nových snadno adaptovatelných blogovacích systémů.

Samozřejmě nejprve musíte mít webový blogovací systém, který lze zacílit jedním z API. Vytváření celého systému přesahuje rámec této kapitoly, a proto, místo jeho vytváření od úplného začátku, můžeme

Kapitola 16 – RPC: Interakce se vzdálenými službami

411

vložit vrstvu XML-RPC do blogovacího systému Serendipity. Zmíněné API zpracuje odeslání, a proto bude možné sestavit rozhraní s následujícími rutinami z Serendipity: function serendipity_updertEntry($entry) {} function serendipity_fetchEntry($key, $match) {}

serendipity_updertEntry() je funkce, která buď aktualizuje stávající záznam nebo vloží nový záznam v závislosti na tom, zda je předáno id. Její parametr $entry je pole, které přestavuje řádkovou bránu (row gateway) (elementy pole jsou se sloupci tabulky v poměru jeden-k-jednomu) pro následující tabulku databáze: CREATE TABLE serendipity_entries ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(200) DEFAULT NULL, timestamp INT(10) DEFAULT NULL, body TEXT, author VARCHAR(20) DEFAULT NULL, isdraft INT );

serendipity_fetchEntry() načte záznam z tabulky porovnáním specifikované dvojice klíč/hodno-

ta.

Cílem naší implementace je MetaWeblog API, protože poskytuje větší hloubku funkcionalit než Blogger API. MetaWeblog API implementuje tři hlavní metody: metaWeblog.newPost(blogid,username,password,item_struct,publish) returns string metaWeblog.editPost(postid,username,password,item_struct,publish) returns true metaWeblog.getPost(postid,username,password) returns item_struct

blogid je identifikátor weblogu, na který se zaměřujete (což je užitečné, pokud systém podporuje více samostatných weblogů). username a password jsou autentizační kritéria, které identifikují odesílatele. publish je příznak, zdali záznam je koncept nebo by se měl publikovat živě. item_struct je pole dat k odeslání.

Místo implementace nového formátu dat pro záznamy se autor specifikace MetaWeblogu – Dave Winer – rozhodl použít definici položky item ze specifikace RSS (Really Simple Syndication) 2.0, k dispozici na adrese http://blogs.law.harvard.edu/tech/rss. RSS je standardizovaný formát XML vytvořený pro prezentování článků a záznamů v novinách. Jeho uzel item obsahuje následující elementy:

412

Pokročilé programování v PHP 5

Element

Popis

title

Titulek item.

link

URL, které odkazuje na naformátovaný tvar položky.

description

Shrnutí položky.

author

Název autora položky. Podle specifikace RSS by to měla být emailová adresa, ačkoli mnohem častěji se používá přezdívka.

pubDate

Datum publikace záznamu.

Specifikace rovněž volitelně poskytuje pole pro odkazy na vlákna komentáře, jedinečné identifikátory a kategorie. Navíc spousta weblogů rozšiřuje RSS definici item pro zahrnutí elementu content:encoded obsahující úplnou poštu, nejenom tedy shrnutí pošty, které se tradičně nachází v RSS elementu description.

Chcete-li zavést MetaWeblog API, musíte definovat funkce pro implementace tří zmíněných metod.

Nejprve se podívejme na funkci pro zpracování zasílání nových záznamů: function metaWeblog_newPost($message) { $username = $message->params[1]->getval(); $password = $message->params[2]->getval(); if(!serendipity_authenticate_author($username, $password)) { return new XML_RPC_Response('', 4, 'Authentication Failed'); } $item_struct = $message->params[3]->getval(); $publish = $message->params[4]->getval(); $entry['title'] = $item_struct['title']; $entry['body'] = $item_struct['description']; $entry['author'] = $username; $entry['isdraft'] = ($publish == 0)?'true':'false'; $id = serendipity_updertEntry($entry); return new XML_RPC_Response( new XML_RPC_Value($id, 'string')); }

metaWeblog_newPost() extrahuje z požadavku parametry username a password a s pomocí metody getval() deserializuje jejich XML reprezentace do typů PHP. Poté metaWeblog_newPost() autentizuje specifikovaného uživatele. Pokud uživatel neprokáže svou identitu, metaWeblog_newPost() vrací prázdný objekt XML_RPC_Response s chybovou zprávou "Authentication Failed".

Proběhne-li autentizace úspěšně, metaWeblog_newPost() načte parametr item_struct a s pomocí metody getval() jej deserializuje na PHP pole $item_struct. Pole $entry definující reprezentaci interního záznamu Serendipity se sestaví z $item_struct a předá se serendipity_updertEntry().

XML_RPC_Response, kterou tvoří identifikátor nového záznamu, se vrátí volajícímu.

Back-end pro MetaWeblog.editPost se velmi podobá MetaWeblog.newPost. Podívejte se na kód:

Kapitola 16 – RPC: Interakce se vzdálenými službami

413

function metaWeblog_editPost($message) { $postid = $message->params[0]->getval(); $username = $message->params[1]->getval(); $password = $message->params[2]->getval(); if(!serendipity_authenticate_author($username, $password)) { return new XML_RPC_Response('', 4, 'Authentication Failed'); } $item_struct = $message->params[3]->getval(); $publish = $message->params[4]->getval(); $entry['title'] = $item_struct['title']; $entry['body'] = $item_struct['description']; $entry['author'] = $username; $entry['id'] = $postid; $entry['isdraft'] = ($publish == 0)?'true':'false'; $id = serendipity_updertEntry($entry); return new XML_RPC_Response( new XML_RPC_Value($id?true:false, 'boolean')); }

Provede se stejná autentizace a provede se sestavení a aktualizace pole $entry. Pokud serendipity_updertEntry vrací $id, znamená to, že byla úspěšná a odezva se nastaví na hodnotu true, jinak se odezva nastaví na hodnotu false.

Poslední funkcí, kterou máme ještě implementovat, je zpětné volání MetaWeblog.getPost. Tato funkce používá serendipity_fetchEntry() k získání podrobných informací o poště a poté naformátuje odezvu XML obsahující item_struct. Podívejte se na implementaci: function metaWeblog_getPost($message) { $postid = $message->params[0]->getval(); $username = $message->params[1]->getval(); $password = $message->params[2]->getval(); if(!serendipity_authenticate_author($username, $password)) { return new XML_RPC_Response('', 4, 'Authentication Failed'); } $entry = serendipity_fetchEntry('id', $postid); $tmp = array( 'pubDate' => new XML_RPC_Value( XML_RPC_iso8601_encode($entry['timestamp']), 'dateTime.iso8601'), 'postid' => new XML_RPC_Value($postid, 'string'), 'author' => new XML_RPC_Value($entry['author'], 'string'), 'description' => new XML_RPC_Value($entry['body'], 'string'), 'title' => new XML_RPC_Value($entry['title'],'string'), 'link' => new XML_RPC_Value(serendipity_url($postid), 'string') ); $entry = new XML_RPC_Value($tmp, 'struct');

414

Pokročilé programování v PHP 5

return new XML_RPC_Response($entry); }

Všimněte si, že po načtení záznamu se v item připraví pole všech dat. XML_RPC_iso8601() se postará o formátování časové známky Unixu, kterou používá Serendipity, na formát odpovídající ISO 8601, jenž vyžaduje RSS item. Výsledné pole se poté serializuje jako struct XML_RPC_Value. Tohle představuje standardní způsob sestavování XML-RPC typu struct ze základních typů PHP. Doposud jste viděli, že XML_RPC_Value lze předat identifikátory string, boolean, dateTime.iso8601 a struct. Podívejte se na úplný seznam všech možností: Typ

Popis

i4/int

32bitové celé číslo

boolean

logický typ

double

číslo s plovoucí desetinou čárkou

string

řetězec

dateTime.iso8601 časová známka ve formátu ISO 8601 base64

základní 64kódovaný řetězec

struct

implementace asociativního pole

array

neasociativní (indexované) pole

Typy struct a array mohou obsahovat jakýkoli datový typ (včetně dalších elementů struct a array). Není-li specifikován žádný typ, použije se string. I když všechna PHP data lze reprezentovat buď jako string, struct nebo array, jsou podporovány i ostatní typy, protože vzdálené aplikace napsané v jiných jazycích mohou vyžadovat specifičtější typ dat.

Chcete-li registrovat tyto funkce, vytvořte odeslání následovně: $dispatches = array( metaWeblog.newPost' => array('function' => 'metaWeblog_newPost'), 'metaWeblog.editPost' => array('function' => 'metaWeblog_editPost'), 'metaWeblog.getPost' => array('function' => 'metaWeblog_getPost')); $server = new XML_RPC_Server($dispatches,1);

Gratulujeme! Váš software je nyní kompatibilní s MetaWeblog API!

Informativní služby XML-RPC Uživatelé služeb XML-RPC jistě ocení možnost požádat server o podrobné informace o všech poskytovaných službách. XML-RPC definují tři standardní, vestavěné metody pro takovéto sebepozorování:

Kapitola 16 – RPC: Interakce se vzdálenými službami

415

• system.listMethods – vrací pole všech metod implementovaných serverem (všechny zpětné volání registrované v odesílací mapě).

• system.methodSignature – přijímá jeden parametr (název metody) a vrací pole možných signatur (prototypů) metody.

• system.methodHelp – přijímá název metody a vrací dokumentační řetězec pro metodu.

Protože PHP je dynamický jazyk a nedbá na dodržování počtu nebo typu argumentů předávaných funkci, data, která se mají vrátit pomocí system.methodSignature, musí být specifikovány uživatelem. Metody v XML-RPC mohou mít různé parametry, proto vrácená množina je pole všech možných signatur. Každá signatura je sama o sobě polem; první element pole je návratový typ metody a zbývající elementy představují parametry metody.

Pro poskytování těchto dalších informací musí server zvětšit svou odesílací mapu, aby zahrnul další informace, jak můžete vidět níže u metody metaWeblog.newPost: $dispatches = array( 'metaWeblog.newPost' => array('function' => 'metaWeblog_newPost', 'signature' => array( array($GLOBALS['XML_RPC_String'], $GLOBALS['XML_RPC_String'], $GLOBALS['XML_RPC_String'], $GLOBALS['XML_RPC_String'], $GLOBALS['XML_RPC_Struct'], $GLOBALS['XML_RPC_String'] ) ), 'docstring' => 'Takes blogid, username, password, item_struct '. 'publish_flag and returns the postid of the new entry'), /* ... */ );

Tyto tři metody můžete spolu kombinovat pro získání uceleného obrázku o tom, co implementuje server XML-RPC. Podívejte se na skript, který vypíše dokumentaci a signatury pro každou metodu na daném serveru XML-RPC: <?php require_once 'XML/RPC.php'; if($argc != 2) { print "Must specify a url.\n"; exit; } $url = parse_url($argv[1]); $client = new XML_RPC_Client($url['path'], $url['host']);

416

Pokročilé programování v PHP 5

$msg = new XML_RPC_Message('system.listMethods'); $result = $client->send($msg); if ($result->faultCode()) { echo "Error\n"; } $methods = XML_RPC_decode($result->value()); foreach($methods as $method) { $message = new XML_RPC_Message('system.methodSignature', array(new XML_RPC_Value($method))); $response = $client->send($message)->value(); print "Method $method:\n"; $docstring = XML_RPC_decode( $client->send( new XML_RPC_Message('system.methodHelp', array(new XML_RPC_Value($method)) ) )->value() ); if($docstring) { print "$docstring\n"; } else { print "NO DOCSTRING\n"; } $response = $client->send($message)->value(); if($response->kindOf() == 'array') { $signatures = XML_RPC_decode($response); for($i = 0; $i < count($signatures); $i++) { $return = array_shift($signatures[$i]); $params = implode(", ", $signatures[$i]); print "Signature #$i: $return $method($params)\n"; } } else { print "NO SIGNATURE\n"; } print "\n"; } ?>

Spustíte-li skript na instalaci Serendipity, vygeneruje se následující výstup: > xmlrpc-listmethods.php http://www.example.org/serendipity_xmlrpc.php /* ... */

Kapitola 16 – RPC: Interakce se vzdálenými službami

417

Method metaWeblog.newPost: Takes blogid, username, password, item_struct, publish_flag and returns the postid of the new entry Signature #0: string metaWeblog.newPost(string, string, string, struct, string) /* ... */ Method system.listMethods: This method lists all the methods that the XML-RPC server knows how to dispatch Signature #0: array system.listMethods(string) Signature #1: array system.listMethods() Method system.methodHelp: Returns help text if defined for the method passed, otherwise returns an empty string Signature #0: string system.methodHelp(string) Method system.methodSignature: Returns an array of known signatures (an array of arrays) for the method name passed. If no signatures are known, returns a none-array (test for type != array to detect missing signature) Signature #0: array system.methodSignature(string)

SOAP SOAP byla původně zkratka Simple Object Access Protocol, ale od verze 1.1 se jedná už pouze o označení, a nikoliv o zkratku. SOAP je protokol pro výměnu dat v heterogenním prostředí. Na rozdíl od XML-RPC, který je určen především pro zpracování RPC, je SOAP vytvořen pro generické zasílání zpráv a RPC je pouze jednou z aplikací SOAP. Je však potřeba říct, že tato kapitola pojednává o RPC, přičemž se soustředíme pouze na podmnožinu SOAP 1.1 používanou k implementaci RPC. Jak tedy SOAP vypadá? Podívejte se na vzorek obalu SOAP, který používá xmeth-ods.net – vzorovou službu SOAP pro implementaci kanonického příkladu SOAP RPC pro získávání skladových cen IBM (kanonický příklad proto, že jde o příklad z návrhového dokumentu SOAP): <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <soap:Body> <getQuote xmlns="http://www.themindelectric.com/wsdl/net.xmethods.services. stockquote.StockQuote/"> <symbol xsi:type="xsd:string">ibm</symbol>

418

Pokročilé programování v PHP 5

</getQuote> </soap:Body> </soap:Envelope> Tohle je odezva: <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <soap:Body> <n:getQuoteResponse xmlns:n="urn:xmethods-delayed-quotes"> <Result xsi:type="xsd:float">90.25</Result> </n:getQuoteResponse> </soap:Body> </soap:Envelope>

SOAP je vynikající příklad skutečnosti, že jednoduchý koncept nemusí vždy přinášet jednoduchou implementaci. Zprávu SOAP tvoří obal, který obsahuje hlavičku a tělo. V SOAP má všechno jmenný prostor, což je teoreticky dobrá věc, i když čtení XML je poté obtížnější.

Nejvyšší uzel je Envelope, což je kontejner zprávy SOAP. Tohle je element ve jmenném prostoru xmlsoap, jak udává jeho plně kvalifikovaný název elementu <soap:Envelope> a deklarace jmenného prostoru: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

která tvoří asociaci mezi soap a jmenným prostorem URI http://schemas.xmlsoap.org/soap/ envelope/.

SOAP a Schema SOAP znesnadňuje použití Schema, což je jazyk založený na XML pro definici a validaci datových struktur. Úplný jmenný prostor elementu je obvykle (například http://schemas.xmlsoap.org/ soap/envelope/) dokument Schema, který popisuje jmenný prostor. Není to však podmínkou – jmenný prostor dokonce nemusí být URL.

Jmenné prostory plní stejný účel v XML jako v jakémkoli programovacím jazyku: zabraňují možným kolizím dvou názvů. Popřemýšlejte o nejvyšším uzlu <soap-env:Envelope>. Název atributu Envelope je ve jmenném prostoru soap-env. Takže, pokud by z nějakého důvodu chtěl FedEX definovat formát XML, který používá Envelope jako atribut, mohlo by to být <FedEX:Envelope> a všichni by byli spokojeni.

Zde jsou čtyři jmenné prostory deklarované v SOAP Envelope:

Kapitola 16 – RPC: Interakce se vzdálenými službami

419

• xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" – obal SOAP definice Schema popisuje základní objekty SOAP a je standardním jmenným prostorem obsaženým v každém požadavku SOAP.

• xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" – atribut elementu xsi:type se převážně používá pro specifikaci typů elementů.

• xmlns:xsd="http://www.w3.org/2001/XMLSchema" – Schema deklaruje počet základních datových typů, které lze použít pro specifikaci a validaci.

• xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" – specifikace typu kódování použitého ve standardních požadavcích SOAP. Element <GetQuote> má rovněž jmenný prostor – v tomto případě s následujícím extrémně dlouhým názvem: http://www.themindelectric.com/wsdl/net.xmethods.services.stockquote.StockQuote

Všimněte si, jak je použito Schema pro specifikaci typu a uspořádání skladového symbolu, který se předává: <symbol xsi:type="xsd:string">ibm</symbol>

A podobně – v odezvě uvidíte specifický zápis skladové ceny: <Result xsi:type="xsd:float">90.25</Result>

Výše uvedené specifikuje, že výsledek musí být číslo s plovoucí desetinou tečkou. To je užitečné, protože jsou zde sady nástrojů pro validaci Schema, která vám umožní ověřit váš dokument. Mohly by vám sdělit, že odezva v tomto formuláři není platná, protože foo není platnou reprezentací čísla s plovoucí desetinou tečkou: <Result xsi:type="xsd:float">foo</Result>

WSDL SOAP je doplněno jazykem WSDL (Web Services Description Language). WSDL je jazyk založený na XML popisující schopností a metody interakce s webovými službami (častěji než SOAP). Zde je soubor WSDL, který popisuje službu, na kterou jsou v předchozí sekci sestaveny požadavky: <?xml version="1.0" encoding="UTF-8" ?> <definitions name="net.xmethods.services.stockquote.StockQuote" targetNamespace="http://www.themindelectric.com/wsdl/net.xmethods.services. stockquote.StockQuote/"xmlns:tns="http://www.themindelectric.com/wsdl/net. xmethods.services.stockquote.StockQuote/" xmlns:electric="http://www.themindelectric.com/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

420

Pokročilé programování v PHP 5

xmlns="http://schemas.xmlsoap.org/wsdl/"> <message name="getQuoteResponse1"> <part name="Result" type="xsd:float" /> </message> <message name="getQuoteRequest1"> <part name="symbol" type="xsd:string" /> </message> <portType name="net.xmethods.services.stockquote.StockQuotePortType"> <operation name="getQuote" parameterOrder="symbol"> <input message="tns:getQuoteRequest1" /> <output message="tns:getQuoteResponse1" /> </operation> </portType> <binding name="net.xmethods.services.stockquote.StockQuoteBinding" type="tns:net.xmethods.services.stockquote.StockQuotePortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> <operation name="getQuote"> <soap:operation soapAction="urn:xmethods-delayed-quotes#getQuote" /> <input> <soap:body use="encoded" namespace="urn:xmethods-delayed-quotes" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> </input> <output> <soap:body use="encoded" namespace="urn:xmethods-delayed-quotes" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> </output> </operation> </binding> <service name="net.xmethods.services.stockquote.StockQuoteService"> <documentation> net.xmethods.services.stockquote.StockQuote web service </documentation> <port name="net.xmethods.services.stockquote.StockQuotePort" binding="tns:net.xmethods.services.stockquote.StockQuoteBinding"> <soap:address location="http://66.28.98.121:9090/soap" /> </port> </service> </definitions>

WDSL se zřetelně zapojuje do obtížného použití jmenných prostorů, přičemž uspořádání má poněkud zmatenou logiku.

Kapitola 16 – RPC: Interakce se vzdálenými službami

421

První částí tohoto kódu, která stojí za povšimnutí, je uzel <portType>. Tento uzel specifikuje činnosti, které lze provést, a vstupní a výstupní zprávy. Definuje to getQuote, která přijímá getQuoteRequest1 a odpovídá pomocí getQuteResponse1.

Uzly <message> pro getQuoteResponse1 specifikují, že obsahuje jediný element Result typu float.

A podobně, getQuoteRequest1 musí obsahovat jediný element symbol typu string.

Dále je tu uzel <binding>. Vazba se asociuje k <portType> přes atribut type, který odpovídá názvu <portType>. Vazby specifikuje protokol a podrobné informace o přenosu (například specifikace kódování pro data obsažená v těle SOAP), nicméně, ne skutečné adresy. Vazba se asociuje k jedinému protokolu, v tomto případě HTTP, viz následující: <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" />

Nakonec uzel <service> seskupí skupinu portů a specifikuje pro ně adresy. Protože v tomto příkladě je použit jediný port, odkazuje se a je provázán s http://66.28.98.121:9090/soap pomocí následujícího: <port name="net.xmethods.services.stockquote.StockQuotePort" binding="tns:net.xmethods.services.stockquote.StockQuoteBinding"> <soap:address location="http://66.28.98.121:9090/soap" /> </port>

Za povšimnutí stojí skutečnost, že nic nepropojí SOAP, aby fungoval pouze s HTTP, ani nezapříčiňuje, že se musí vrátit odezvy. SOAP je vytvořen tak, aby byl flexibilním univerzálním protokolem pro zasílání zpráv, přičemž RPC přes HTTP je pouze jednou implementací. Soubor WSDL vám sdělí, jaké služby jsou k dispozici, jak a kde je zpřístupnit. SOAP poté implementuje samotný požadavek a odezvu.

Naštěstí třídy PEAR SOAP zpracují téměř všechno za vás. Chcete-li spustit požadavek SOAP, vytvořte nejprve nový objekt SOAP_Client a předejte soubor WSDL službám, které chcete zpřístupnit. Objekt SOAP_Client poté vygeneruje veškerý potřebný kód proxy pro požadavky, které se mají provést přímo, alespoň v případě, kde jsou všechny vstupu jednoduché typy Schema. Následující kód představuje kompletní požadavek klienta na demo službu xmethods.net: require_once "SOAP/Client.php"; $url = "http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl"; $soapclient = new SOAP_Client($url, true); $price = $soapclient->getQuote("ibm")->deserializeBody(); print "Current price of IBM is $price\n";

SOAP_Client provede všechny tajemné věci stojící za tvorbou objektu proxy, který poskytuje přímé vykonání metod specifikovaných v WSDL. Poté, co se provede volání getQuote(), výsledek se deserializuje do nativních typů PHP s pomocí deserializeBody() a získáte následující: > php delayed-stockquote.php Current price of IBM is 90.25

422

Pokročilé programování v PHP 5

Přepis system.load na službu SOAP Rychlý test vašich nových znalostí SOAP spočívá v reimplementaci XML-RPC služby system.load na službu SOAP. Pro začátek definujte službu SOAP jako specializaci SOAP_Service. Je třeba implementovat minimálně čtyři funkce:

• public static function getSOAPServiceNamespace(){} – musí vracet definovaný jmenný prostor.

• public static function getSOAPServiceName() {} – musí vracet název definované služby.

• public static function getSOAPServiceDescription() – musí vracet popis řetězce služby, kterou definujete.

• public static function getWSDLURI() {} – musí vracet URL, které směřuje na soubor WSDL, kde je popsána služba.

Navíc byste měli definovat všechny metody, které budete volat.

Podívejte se na definici třídy pro novou SOAP implementaci SystemLoad: require_once 'SOAP/Server.php'; class ServerHandler_SystemLoad implements SOAP_Service { public static function getSOAPServiceNamespace() { return 'http://example.org/SystemLoad/'; } public static function getSOAPServiceName() { return 'SystemLoadService'; } public static function getSOAPServiceDescription() { return 'Return the one-minute load avergae.'; } public static function getWSDLURI() { return 'http://localhost/soap/tests/SystemLoad.wsdl'; } public function SystemLoad() { $uptime = `uptime`; if(preg_match("/load averages?: ([\d.]+)/", $uptime, $matches)) { return array( 'Load' => $matches[1]); } } }

Na rozdíl od XML-RPC vaše metody SOAP_Service obdrží své argumenty jako normální proměnné PHP. Metoda musí vrátit pouze pole parametrů zprávy odezvy. Jmenné prostory, které si vybíráte, nejsou povinné, ale jsou ověřovány proti specifikovanému souboru WSDL, a proto musí být interně shodné.

Jakmile definujete službu, musíte ji registrovat jako u XML-RPC. V následujícím příkladě vytvoříte nový SOAP_Server, vložíte novou službu a nařídíte instanci serveru, aby zpracoval příchozí požadavky: