Filip Vařecha 17. února 2010

Transkript

1 Carsharing: závěrečná zpráva Filip Vařecha 17. února 2010 Abstrakt Tento článek slouží jako závěrečná zpráva shrnující dění a pokrok v projektu Carsharing za zimní semestr školního roku 2009/2010. Jeho další využití je jako reference pro všechny co se chystají tímto projektem dále zabývat. 1

2 1 Historie projektu Projekt Carsharing má za sebou již poměrně dlouhou historii, během které prošel poměrně velkými změnami v celé jeho architektuře. Původní projekt, který byl obsahem několika bakalářských prací, fungoval pod názvem Metrocar. Architektura sestávala ze dvou samostatných částí: 1. Palubní jednotky: jednalo se jak o hardwarovou část jako takovou (speciálně pro tento projekt sestavené zařízení), jako i softwarovou část napsanou v Javě, která tento hardware obsluhovala. Palubní jednotky slouží pro komunikaci automobilů se serverem. 2. Serverová aplikace: má na starosti obsluhu palubních jednotek, business logiku celého projektu, rozhraní pro zákazníky (tvorba rezervací,... ) a pro administrátory. Architekturou byla zvolena webová aplikace. Platformou bylo PHP + MySQL + Apache PHP a Drupal Pro programovou vrstvu bylo zvoleno PHP (viz. výše). Aby se ušetřila nějaká dávka programování, bylo rozhodnuto, že se použije CMS 1 Drupal ve verzi 6. Jedná se o open-source systém pro správu obsahu webových stránek založený na PHP. Jeho hlavní devizou je poměrně vysoká penetrace na trhu, díky čemuž se jedná o robustní systém s velkým počtem dodatečných modulů a obecně spolehlivým jádrem. Bohužel se však nejedná o objektově orientovaný software, nebot jeho vývoj začal ještě předtím, než do PHP byly objektové prvky řádně zapracovány. Přesto se dá mluvit o jisté objektovosti - alespoň co se dědičnosti a polymorfismu týče - která je docílena pomocí systému hooků, které jednotlivé moduly mohou implementovat. Původní projekt běží na webové adrese Uživatelské jméno je admin a heslo je metro1car. 2 Transformace do Pythonu V podobě popsané v předchozím odstavci tento projekt ustál několik bakalářských prací. Jeho vývoj však neskončil, bylo rozhodnuto pokračovat dál, ale stáli jsme tentkrát před otázkou, zda současná forma implementace je opravdu ta nejlepší. 2.1 Důvody transformace Hlavním problematickým článkem byl totiž Drupal samotný. Je vhodný na prezentace obsahových webů. Není však již tolik vhodný na programování složité business logiky, kterou carsharingový systém vyžaduje. Proto bylo rozhodnuto, že se provede transformace a především oddělení frontendu, tedy čistě prezentační části aplikace, a backendu coby výkonné části, kde je uložena hlavní business logika. Dále bylo ustanoveno, že backendová část by měla mít vystavěno API, které bude dostupné zvenčí, tedy se stane webovou službou. Toto API by pak bylo 1 Content Management System 2

3 možné využívat nejen pro čistě browserové internetové aplikace, ale třeba i z desktopových aplikací napsaných v Javě. 2.2 Volba platformy Jako platofma byl nově zvolen Python. Databázový stroj a webový server byly ponechány. Pro usnadnění vývoje bylo rozhodnuto, že se použije webový framework Django, který je v poslední době poměrně populární a snad díky němu se Python dostává do povědomí i webových vývojářů. 3 Implementační detaily Jak bylo řečeno v předchozí části, základem implementace jsou následující celky: Python - s využitím frameworku Django[2] MySQL Apache2 3.1 Původní idea funkce Původně bylo zamýšleno, že celý frontend aplikace bude pouze jedna z možných aplikací, která bude využívat API poskytované backendem. Jednalo by se tedy v podstatě o velmi hloupou aplikaci, která by pouze prezentovala na venek služby poskytované jádrem aplikace. Vzhledem k takto těsné vazbě byl jako standard pro webovou službu použito XML-RPC 2, tedy vzdálené volání procedur pomocí XML. Tento standard je založen na jednoduše zakódovaném volání procedur, kdy v každém requestu je přenášeno v podstatě pouze jméno metody a její parametry, případně chybový string[4]. Tím je docíleno poměrně úsporného formátu na úkor robustnosti. To nám ale příliš nevadilo, vzhledem k tomu, že se nepředpokládalo, že by tato webová služba byla volně dostupná pro veřejnost. 3.2 Další využívané knihovny Naše aplikace pro svůj běh potřebuje ještě sadu dalších knihoven, které nám usnadnily její tvorbu. Jedná se především o: django xmlrpc - knihovna založená na Djangu, která umožňuje jednoduchou tvorbu XML-RPC metod[1]. GeoDjango - rozsáhlá knihovna pro geografické výpočty a zobrazování geografických dat[3]. Nebudu se zde zmiňovat o dalších Python knihovnách, které jsou potřebné například pro napojení na MySQL apod. 2 XML Remote Procedure Call 3

4 3.3 Rozhraní pro komunikaci s palubními jednotkami Pro komunikaci s palubními jednotkami jsme si vytvořili vlastní formát založený na XML, který klade hlavní důraz na úspornost kódu. Jeho reference je uvedena v příloze. Toto rozhraní běží na adrese /comm/ a příjmá POST requesty. V aplikaci ho obsluhuje handler car unit management/handler.py. 3.4 Rozhraní pro XML-RPC Jako rozhraní pro XML-RPC každý modul může definovat soubor xmlrpc.py (pouze konvence pro přehlednost, obecně může být pojmenován jakkoliv), jehož funkce používají dekorátor xmlrpc func. Nakonec je v konfiguračním modulu aplikace (který začíná v settings.py) uveden soubor exportovaných metod, které lze využívat. Pro autentizaci slouží dekorátor secure func. 3.5 Stav implementace Bohužel, původní vizi nové implementace se zatím nepodařilo dokončit vinou nedostatečné týmové spolupráce. Většina modulů tak je nehotová a čeká na rozvinutí. Nejkompletnější je modul user management. Dále se dá říci, že je vcelku kompletní i databázové schéma aplikace, které bylo do velké míry přejato z původní koncepce, pouze vylepšeno v místech, kde nebylo zcela dotaženo. V modulech se to projevuje definicí používaných modelů, ze kterých je toto databázové schéma pomocí Djanga vygenerováno. Vývojová verze projektu běží na webové adrese fragaria.cz/admin. Uživatelské jméno je admin a heslo je yepr6s6r. Pro projekt není zaveden DNS záznam a proto je potřeba přidat následující řádek do /etc/hosts (nebo C: Windows System32 drivers etc hosts): metrocar.proj.fragaria.cz 3.6 Subversion repozitář Projekt je k dispozici v SVN repozitáři. SVNka obsahuje jak původní, tak i novou implementaci projektu, všechnu dostupnou dokumentaci a vůbec veškeré vědomosti a informace, které byly během vývoje nashromážděny. Adresa SVN je: Pro použití je zřejmě nutné mít uživatelský účet na Assemble. To by měl dodat garant projektu, kterým je Ing. Martin Komárek ( komarem@fel.cvut.cz). 4 To Do V této sekci nastíním co vše je potřeba dále udělat. Bude to v podstatě strohý výčet okruhů: Dodělání backend modulů - především programování logiky aplikace 4

5 Částečně cars (billing) a usermanagement (sladění s frontendem) Z větší části reservations (vytvořeno zatím pouze vkládání rezervací) invoices (kompletně naprogramovat), tariffs (kompletní logika tarifikace, asi převést z původního projektu) Dořešení frontendu - bud přepsat, nebo kompletně dotáhnout 5 Závěr V tomto dokuementu jsme se zabývali projektem Carsharing. Uvedli jsme jeho stručnou historii a dále jsme se zabývali jeho postupným vývojem. Nakonec jsme uvedli jeho současnou podobu a lehce nastínili jeho implementaci. 5.1 Kontakt V případě jakýchkoliv dotazů mě můžete kontaktovat na u: varecfil@ fel.cvut.cz. Reference [1] G. Bins. django xmlrpc, [2] Django. Django, [3] GeoDjango. Geodjango, [4] Wikipedia. Xml-rpc wikipedia, the free encyclopedia, wikipedia.org/wiki/xmlrpc. 5

6 A Komunikační protokol pro palubní jednotky Jako referenci zde vkládám obsah DTD 3 souborů, které popisují jednotlivé formáty XML požadavků. Pomocí těchto souborů není problém okamžitě ověřit, zda je request validní (alespoň co se struktury XML elementů týče). Formát requestu?xml version= 1.0 encoding= UTF-8?!ELEMENT r (a, v?, z?)!element a (#PCDATA)!--autorizacni klic--!element v (i, s?, p, q*, l, t?)!--usage--!element i (#PCDATA)!--user id int--!element s (#PCDATA)!--since same like till (t tag)--!element p (b, c)!--base position--!element b (#PCDATA)!--base latitude double--!element c (#PCDATA)!--base longitude double--!element q (d,e)!--incremental position=what to add to base to get real possition--!element d (#PCDATA)!--incremental latitude int--!element e (#PCDATA)!--incremental longitude int--!element l (#PCDATA)!--length in metres int--!element t (#PCDATA)!--till string formated YY-MM-DD HH:MM --!ELEMENT z (x+)!--what i need--!element x (#PCDATA)!--requested info, one of RESERVATIONS, SETTINGS-- Formát response?xml version= 1.0 encoding= windows-1252?!element r (u?, g?)!--response--!element u (v?)!--reservations--!element v (i, (p q)+, b+)!--user--!element i (#PCDATA)!--user id int--!element p (#PCDATA)!--user phone number string !ELEMENT q (#PCDATA)!--user RFID card code string--!element b (s, t)!--reservation times--!element s (#PCDATA)!--since--!ELEMENT t (#PCDATA)!--till--!ELEMENT g (j+)!--settings--!element j (k, h)!--setting--!element k (#PCDATA)!--key--!ELEMENT h (#PCDATA)!--value-- 3 Document Type Definiton 6

7 Příklady requestů r a 123 /a v i 2 /i s :00 /s p b /b c /c /p q d 0.1 /d e 1.2 /e /q l 4000 /l t :30 /t /v z x RESERVATIONS /x x SETTINGS /x /z /r r a 123 /a v i 2 /i s :50 /s p b /b c /c /p q d 0.1 /d e 1.2 /e /q q d 0.6 /d e 2.1 /e /q l 1500 /l t :20 /t /v z x SETTINGS /x /z /r 7