Oracle XE a openSuSE 11.0

Včera jsem dostal novou hračku - IBMku x3550 se dvěma QuadCore XEONy. Nainstaloval jsem tam 64bitové openSuSE 11.0 a pak jsem se vrhl do instalace Oracle. Momentláně vyvíjím na Oracle 10g Express Edition, takže šup na oracle.com, stáhnout RPMko s Oracle XE a šup tam s ním!

Ale ouha. Nebyla to žádná procházka růžovým sadem.

První zádrhel byl v tom, že Oracle nenabízí 64bitovou verzi. Nu což, řekl jsem si, 32bit by snad měl chodit. Prošla instalace i konfigurace pomocí /etc/init.d/oracle-xe configure (dal jsem jej na port 6060, na 8080 chci mít JBoss), databáze šla nahodit, ale na URL http://127.0.0.1:6060/apex jsem z linkse dostaval connection refused. Takže co s tím?

1) Firewall - rcSuseFirewall stop - nezabralo
2) IPadresa - links http://127.0.0.2:6060/apex ani links http://192.168.11.240:6060/apex
3) links - export DISPLAY=bilbo:0; firefox - nezabralo, firefox hazel totez

Takže přišel na řadu Google.
A)opensuse oracle express connection refused
4) našel jsem, že by to mělo být právě tím 32bitem na 64bitu. Tedy yast, Software-Software Manager, tam vybrat 32bitový pattern a Apply. Následně
/etc/init.d/oracle-xe restart; links http://127.0.0.1:6060/apex a opět totéž
5) Co kdyby to bylo portem? Všichni používají 8080... takže /etc/init.d/oracle-xe configure - smůla, already configured...
6) další link obsahoval, že sqplplus / as sysdba jim fungovalo. Testnu to a nemohl najít ORACLE_SID.
7) vzpomínám, jak se konfigurovalo prostředí - aha, oraenv - Error: dbhome cannot be find...
8) přenastavuju cestu, znova spouštím a nic, opět nenalezen. Dívám se, kde by mohl být a zjišťuju, že nikde :-(
9) po několika pokusech jsem přece našel, co jsem hledal: oracle_env.sh nemá žádný výstup, což mne zmátlo, ale less oracle_env.sh odhaluje pravou podstatu jeho fungování. Samozřejmě jsem v prvé chvíli zapomněl spustit to tečkově, takže export proměnných šel do háje, ale přece...
10)Opět sqplplus / as sysdba a tentokrát řve, že nemůže najít libaio.so.1
11)ldd sqplplus nehlásí nic chybějícího, takže to bude asi někde jinde. Zkouším se podívat do /lib a /usr/lib a ORACLE_HOME/lib a taky jsem ji nenašel.
12)rpmfind libaio našel jenom balíky pro Fedoru. Paráda.
B) opět Google: oracle libaio vrací hned na prvním místě oracle libaio. Jsou tam zdrojáky, takže je tahám.
C) během tahání zkouším oracle opensuse. Hned na prvním místě je Oracle on OpenSuse. Čtu to už potřetí, přestože tam o XE nikde ani zmínky, ale stálo to za to. Na konci, téměř neviditelně, je řádek:

Alternatively if you don't want problems in the installation of oracle 10g or 11g on openSUSE 11.0 (64bit) you can use this script doris1.1d.sh. This script will automate the setup by downloading from Yast dependencies, sorting out all the 32bit and 64bit libraries and linking where required. The purpose of this script is not to install Oracle but just to get the system ready for installation. Own risks policy applies. (root@localhost# sh doris1.1d.sh suse11 10g)

Myslel jsem, že mně vomejou.
13) Stáhnout skript a pak už jen:
root@localhost# sh doris1.1d.sh suse11 10g

rpm -e oracle-xe-univ; rpm -i oracle-xe-univ-10.2.0.1-1.0.i386.rpm

/etc/init.d/oracle-xe configure

links http://127.0.0.1:6060/apex a ejhle, už po mně chce heslo a lze se tma přihlásit!

Jaké z toho plyne poučení? Pochválen buď každý, kdo své znalosti promění do perfektně fungujícího skriptu...

TheServerSide podruhé a FrameWorkPrasárny

Přečtě te si toto: http://blog.krecan.net/2008/07/17/zavazna-bezpecnostni-chyba-ve-springu-odhalena/

To vážně nemá chybu.

oRESTované dotazy

Nedávno do emailové konference na java.cz přišel dotaz, jak co nejlépe do RESTu nacpat různé filtry.

Zdravim konfereneciu

Zacinam s REST a zakladne principy som snad pochopil (CRUD ->
POST,GET,PUT,DELETE). Ale neviem presne ako realizovat filtrovanie
zaznamov.

Napriklad:
mam zoznam uzivatelov ktory maju polozky: age, firstName, lastName,
atd. Ak chcem nacitat vsetky zaznamy tak dam GET request na adr.
'http://adresa.server/users' vrati mi zoznam vsetkych uzivatelov. Ale ak
by som chcel filtrovat zaznamy podla kriterii napr:
firstName='James' AND lastName!='Bond' OR age>40
Akym sposobom sa dotazovat k tymto zaznamom ? Napadaju ma nasedovne
sposoby:

1) cely dotaz dat do URL:

http://adresa/users/search/v1,s1,c1,o1: ... :vn,sn,cn,o1/orderby/xyz/...

n=1..m
vn - variable, napr: 'firstName'
sn - string, napr: 'James'
cn - condition, napr. 'eg' = equals, 'gt' = greater than, ...
on - operator, napr. 'a' = AND, 'o' = OR

V tomto pripade by sa cely dotaz zapisal do URL a po zavolani GET
request by sa vratil vyfiltrovany obsah. Tento sposob mi pripada asi
najviac RESTful, ale ta url by bola asi dost dlha v niektorych
pripadoch.

2) dotaz zakodovat do XML






V tomto pripade by sa muselo XML asi poslat cez request POST alebo PUT a
nasledne spracovat, ale metody POST, PUT sluzia na ine ucely a asi to
nie je 'validne' REST riesenie.

3) nejak inak :) rad sa necham poucit ...

RM

Jsem moc rád za tento dotaz - zdá se, že s RESTem konečně začíná koketovat
více a více lidí.

Jeho problém je hned v několika omylech, které pramení z chýru kolem RESTu:
a) REST != CRUD . REST je o definici malého množství operací nad všemi
zdroji daného systému. Jako příklad uvedu HTTP operace HEAD a OPTIONS.
b) REST != HTTP . HTTP je pouze jedním z RESTových protokolů, který se typicky
používá jako transportní protokol pro jiný RESTový protokol.
c) URI nereprezentuje přesnou datovou podobu zdroje pro READ operace.
URI reprezentuje zdroj jako takový, je to tedy jeho identifikace. Každá operace může být parametrizována. Podstatne je, aby opakované READ operace na stejný zdroj vracely btť různé, ale sémanticky shodné reprezentace zdroje. Jako příklad opět uvedu onu HTTP operaci HEAD, ktera vrací pouze "metadata" zdroje.

Co z toho plyne, tedy jaké řešení navrhnout?

Pro každý typ zdroje zavést jako zdroj kolekci vsech zdroju daneho typu, na teto kolekci zavést operaci QUERY či FILTER, která bude mít logicky dva parametry:
1) URL kolekce
2) vlastní query

Pak už záleží čistě na libovůli autorově, jaký transportní protokol použije (no dobře, bude to HTTP, že? :-D ) a jak se naimplementuje (tak jo, jak se na HTTP udělá binding onoho protokolu). Pro HTTP lze použít jak query string GETové operace (ta je mimochodem také dvouparametrová, URL a QUERY_STRING, přičemž druhý parametr je nepovinný) nebo POST a query posílat v datech.

Už mne ti Phisháci fakt iritují

Tak jsem si pravě objevil ve FireFoxu zafišované CSSko. Chvilku jsem Gůglil a našel jsem jasné vysvětlení - někdo se snaží pomocí Googlovských reklam nečistě vydělávat, když na háček nechytí vás, ale váš prohlížeč.

Doufám, že bude brzo čapnut. Víte, takový přístup k síti se mi z duše protiví.

Takže si projistotu dejte

grep -rl a0b4df006e02184c60dbf503e71c87ad /

(nebo obecněji hledat řetězec

expression(eval(unescape(

Tak možná zjistíte, že buď Vám v systému nechal tesař díru, nebo jste poskytli svůj browser jako nástroj k vylepšení něčí peněženky.

V druhém případě je dobré dát vědět adminovi serveru, odkud vám ten humus přišel.

Kouzelné slůvko

"Tati, potřeboval bych nový pevný disk do počítače. Koupíš mi ho?"
"A kouzelné slovíčko?"
"Sákryš, dneska už je všechny zaheslované..."

WebServisování, díl první - pojem WebServisa ( Web Service )

Dneska jsem Gůglil něco o JBossu a WebServisách a narazil jsem na terminologický problém - pod pojmem Raw Service si různí lidé představují různé věci. A protože jsem si sám nebyl jist, rozhodl jsem si všechno zase oživit, nastudovat a taky o tom něco napsat. Navíc vzhledem k několika diskusím, které jsem tu na téma WebServis rozvířil a v nichž se ukázalo vzájemné nepochopení základního pojmosloví, začnu s tím vším celým tak nějak z gruntu.

Úplně na začátku musím uvést, že ač jsem příznivcem překladů termínů do češtiny, tak anglický termín Web Service překladám jako (TWikiňácky) WebServisa. Vím, že mnozí češtinofilové preferují webová služba, ale mám k tomu překladu hned několik výhrad.

Ponejprv je třeba si říci, že ani samotné slovo Web se nepřekládá, pavučina se zkrátka neujala. Proto u tohoto termínu neexistuje precedent (který se mimochodem také nepřekládá :-) ). Dále pak nepřekládáme pojem Web Server.

Přestože by se dalo říci, že Webová Služba zní pěkně hezky česky a proč to nepoužít, mám jeden velký protipříklad. Mnoho lidí používá termín Webová Služba pro označení portálu nebo funkce portálu. Například https://kontrola.isvav.cvut.cz/ , http://www.zive.cz/default.aspx?server=1&article=141698, http://www.magic-shop.cz/webove-sluzby-atcomputers-s-v-zencart. Takže aby nedošlo ke zmatení nepřítele, budu i nadále používat terminus technicus WebServisa. Může se vám to nelíbit, můžete s tím nesouhlasit... ale to je tak asi všechno, co s tím můžete dělat.

A co to vlastně ta WebServisa je? Už toto je poměrně těžká otázka. Ještě před čtyřmi lety platilo, že v každé firmě, která se nějak podílela na onom WS-H (WebService Hype :-D ), měli svou vlastní definici. Přestože všichni tak nějak intuitivně chápali wocogo, každý si tento termín definoval tak, jak se mu hodilo, a tím se také vymezoval proti ostatním. "Ty že máš WebServisy? Ale kdeže! To MY máme WebServisy..." V roce 2003 (nejsem si rokem přesně jist) vyšel Sun s prohlášením, že ON dělá WebServisy už SEDM let! No nic. Uvedu pár příkladů definice:
* A service is an abstract resource that represents a capability of performing tasks that represents a coherent functionality from the point of view of provider entities and requester entities. To be used, a service must be realized by a concrete provider agent. (W3C ws-arch)
* A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. (Oasis standard SOA-RM)
* WebService - Loosely coupled software components delivered over Internet standard technologies. (Systinet Server for Java glossary)
* Webová služba je podle definice W3C řešení, jak spolu aplikace mohou komunikovat a vyměňovat si informace přes Internet. (tak hovoří česká Wikipedie)

Néjlepe celou rozepři vystihuje asi Google.

"Kupodivu" ony terminologické pře přestaly přesně v okamžiku, kdy se buzzword WebServisa stal "out" a "in" bylo mluvit jen a jen o SOA.

Já tedy zkusím tak nějak shrnout onu definici ne do věty, ale bodů:
1) WebServisa je kus kódu, který zprostředkovává nějakou funkcionalitu, z pohledu z horního patra sémantiky atomickou.
2) WebServisa má přijímat data v (jednoduše) strojově zpracovatelném stavu a ve stejně jednoduše strojově zpracovatelném stavu produkovat.
3) WebServisa je dostupná svému "zákazníkovi" obdobným způsobem jako webové stránky, může tedy běžet jak na stejném počítači, tak na druhém konci světa.
4) Každá WebServisa má nějaký její jednojednoznačný identifikátor (URI), který je možno použít k jejímu dosažení.
5) Komunikační protokol mezi klientem a WebServisou je otevřený, kýmkoli použitelný, nepodléhá patentům (no, tak tady sice můžeme narazit, ale podle vyjádření IBM a Microsoftu nebudou svá vlastnická práva na SOAP nikdy zpoplatňovat), není závislý na implementaci WebServisy či klienta (je tedy zaručeno, že lze implementovat na všech různých platformách libovolným jazykem). Je tedy možné jednu WebServisu bez obtíží nahradit jinou od jiného dodavatele.
6) Totéž platí pro transportní protokol.

A co se ještě přidává jako "ještě by mělo platit, abychom to jako WebServisu uznali všichni":
1) Data jsou strukturovaná a textová, ideálně XML. Veškerá binární data jsou zakódována do textové podoby (nejčastěji algoritmem Base64).
2) WebServisa má dobře zdokumentované rozhraní.
3) Jako URI se používá URL.

A co je de facto standardem:
1) Transportním protokolem je HTTP a používá se HTTP-SOAP binding, protože na jiný není standard. HTTP je sice aplikační protokol, ale pro potřeby WebServis byl ohnutý tak, aby sloužil jako transportní vrstva.
2) Data jsou zabalena v SOAPové obálce.
3) Klient a WebServisa si spolu povídají jazykem, kterému rozumí Microsoft DotNet framework. Když MS přejde na modré trpaslíky, mýdlo bude zahozeno. Tolik k nezávislosti na jedné firmě.
4) Na popis rozhraní se používá WSDL.
5) Každé volání je synchronní request-response. K WebServisám se tak převážně přistupuje jako ke vzdáleným objektům, tedy takové vylepšené XML-RPC.

Neříkám, že je to přesně ono, ale plus mínus ano.