Anvil, Java-pohjainen sovellusalusta
Jani Lehtimäki
kehitysympäristöä. Järjestelmä on syntynyt omien kokemustemme
ja tarpeittemme muokkaamina ja se lienee omimmillaan server-side
pohjaisten (laajojen) sovellusten alustana.
Anvilin piirteitä:
- modulaarinen, proseduraalinen ja olio-orientoitunut
ohjelmointikieli jossa myös funktionaalisia piirteitä
- osittainen käännösaikainen sidonta, ajonaikainen tyypitys
- saman kielen riisuttu malli tag-pohjaisena
- muokattava serveriympäristö http-kuuntelijalla
- peruskirjastot (io, net, sql, naming, etc.)
- anvildoc, dokumentaatio generaattori
- java-luokkia voidaan käyttää ja kutsua suoraan
- käännetty; tuottaa suoraan java-bytekoodia
- valmis applikaatio voidaan toimittaa yhtenä jar-tiedostona
Anvil ja dokumentaatio löytyvät osoitteesta http://njet.org/
Olemme kiinnostuneita kuulemaan mielipiteitä ja kokemuksia Anvilista
ja www-sovellusten teosta yleensä.
Terveisin,
Jani Lehtimäki, j...@njet.com
Heikki Luhtala, hei...@njet.com
Jari Mäkelä
> Olemme kehittäneet noin kaksi vuotta Java-pohjaista Anvil
> kehitysympäristöä. Järjestelmä on syntynyt omien kokemustemme ja
> tarpeittemme muokkaamina ja se lienee omimmillaan server-side
> pohjaisten (laajojen) sovellusten alustana.
Lyhyesti dokumentaatiota tutkimalla Anvilista on vaikea sanoa
mitään. Onko teillä joku lista olemassaolevien alustojen puutteista,
jotka ovat johtaneet Anvilin kehittämiseen ja mitkä ovat ne ratkaisut,
jotka korjaavat nämä puutteet? Eli minkä ongelman Anvil ratkaisee ja
miten? Miksi en käyttäisi vain Java-alustaa?
Lyhyesti saittia vilkaisemalla oli havaittavissa toteutuksessa tiettyä
pragmaattisuutta ja holistisuutta: kaikki dokumentaatio oli
autogeneroidun, yhtenäisen ja hyvin linkitetyn näköistä.
Jari
--
"Ihminen on muutakin kuin hiilidioksinen kokonaisuus."
-- Juhan af Grann, IL 27.4.2002
Jani Lehtimäki
> mitään. Onko teillä joku lista olemassaolevien alustojen puutteista,
> jotka ovat johtaneet Anvilin kehittämiseen ja mitkä ovat ne ratkaisut,
> jotka korjaavat nämä puutteet? Eli minkä ongelman Anvil ratkaisee ja
> miten? Miksi en käyttäisi vain Java-alustaa?
henkilökohtaisesti en jaksaisi käyttää esimerkiksi servlet/jsp/ejb
kokonaisuutta sovellusten tekemiseen, enimmäkseen siksi että olen
hätäinen ja laiska: jsp:ien käännösajat, ejb:ien deployaaminen ja
serverin uudelleenkäynnistely korventaa mieltä. toisaalta koodia
syntyy pitkälti, ja karu totuus on että se on yleensä enemmän tai
vähemmän epämiellyttävän näköistä vaikka miten yrittäisi, erityisesti
mitä tulee jsp:hin.
motivaatio kaikkeen (tai siis anviliin) lienee laiskuus: halu tehdä
enemmän; nopeammin, tehokkaammin ja helpommin. arvelen että monilla
ohjelmoijilla, itseni lisäksi, on tarve nähdä nopeasti tuloksia.
konreettiset tulokset on polttovoima seuraaville muutoksille.
tietysti voisi kysyä että miksi tehdä uusi kieli? miksi ei?
ohjelmoijista on aina ollut kiva keksiä "uusia" kieliä ongelmien
ratkaisuun.
anvil ei ole mitenkään erityisesti suunniteltu [hakasuluissa
motivaatio]:
- ensimmäisenä syntyi tulkattu templatekieli
[servlettipuuhastelua helpottamaan],
- myöhemmin generoitiin .java tiedostoja
[need for speed],
- eräänä päivänä huomasin että samoista koodeista saisi java-henkisen
skriptikielen
[javalla on työlästä koodata]
- joka myöhemmin sai olio-omaisuuksia
[monimutkaisempia sovelluksia]
- näiden ympärille rakentui serveriympäristö
[helpompi konffata]
- lopulta .java tiedostoista siirryttiin suoraan bytekoodin
generointiin [tehokkuus - ei enään tulkattua tilaa, riippumattomuus
muista työkaluista]
kielellisten ominaisuuksi suhteen anvilia voi verratta j(p)ythoniin.
(kaupallisempaa höpinää osoitteessa http://demodays.njet.com)
--jkl
Jaripekka Salminen
> Lyhyesti dokumentaatiota tutkimalla Anvilista on vaikea sanoa
> mitään. Onko teillä joku lista olemassaolevien alustojen puutteista,
> jotka ovat johtaneet Anvilin kehittämiseen ja mitkä ovat ne ratkaisut,
> jotka korjaavat nämä puutteet? Eli minkä ongelman Anvil ratkaisee ja
> miten? Miksi en käyttäisi vain Java-alustaa?
Olen ollut mukana Janin kanssa viemässä Anvil-alustaa
asiakkaiden Java-projekteihin.
Anvil oli jo olemassa, kun ryhdyimme analysoimaan, mitä
se oikeastaan ratkaisee. Kirjoitimme erään
teknologia white-paperin, jossa on mielestäni kirjattu
juuri vastaukset sinun kysymyksiisi.
Oleellisia havaintoja ovat seuraavat:
1) skriptikieliä on aina ollut olemassa ja
niitä tulee aina olemaan. Skriptikielten rooli
on aivan eri kuin systeemikielien. Skriptikielillä
tuotetaan sovelluksia ja asiakasratkaisuja,
systeemikielillä tuotetaan alustoja ja infrastruktuuria.
2) Java-alustalta puuttuu skriptikieli/liimakieli/
systeemi-integraatiokieli/sovelluskieli.
3) Web-orientoituneita käyttöliittymiä on vaikea
tehdä, ellei ole helposti erotettavissa
sovelluskoodi ja ulkoasukoodi toisistaan.
Tarvitaan yksinkertainen MVC-toteutus (Model-View-Control)
server-side Java-alustalle.
4) Skriptitoteutuksia (Anvil, TCL, jne) voi tyypillisesti tuottaa
1/3 ajassa verrattuna systeemikielisiin (Java/C jne) toteutuksiin
5) Ylläpidettävän koodin määrä on tyypillisesti 1/3.
6) Moderni skriptikieli skaalautuu tuotantoon yhtä
hyvin kuin systeemikielinen versio.
Koko mainitsemani white paper löytyy seuraavasta osoitteesta:
"Anvil: Higher-Level Development of Internet Services"
http://demodays.njet.com/docs/whitepapers/higher.html
JPS
Lauri Alanko
Jaripekka Salminen <j...@medios.fi> wrote:
>4) Skriptitoteutuksia (Anvil, TCL, jne) voi tyypillisesti tuottaa
>1/3 ajassa verrattuna systeemikielisiin (Java/C jne) toteutuksiin
>
>5) Ylläpidettävän koodin määrä on tyypillisesti 1/3.
>
>6) Moderni skriptikieli skaalautuu tuotantoon yhtä
>hyvin kuin systeemikielinen versio.
Mikähän mahtaa olla "skriptikielen" ja "systeemikielen" ero?
Lauri Alanko
l...@iki.fi
Jaripekka Salminen
Lainaan tässä vapaasti suomentaen suoraan skriptauksen
oppi-isää John Ousterhoutia:
"Ymmärtääksemme skriptikielen ja systeemikielen eroja,
on ymmärrettävä miten systeemikielet ovat kehittyneet.
Systeemikielet olivat alunperin vaihtoehtoja assembly-kielille.
Systeemikielillä tarkoitetaan nykyään sellaisia kuten
PL/1, Pascal, C, C++ ja Java. Systeemikielet eroavat
assembly-kielistä kahdella tavalla: ne ovat korkeamman tason
kieliä ja ne ovat vahvasti tyypitettyjä. Korkeammalla tasolla
tarkoitetaan sitä, että voidaan päästä samaan tulokseen
kirjoittamalla vähemmän koodia.
Skriptikielet, kuten Perl, Python, Rexx, Tcl, Visual Basic ja
Unix shell-skriptit edustavat aivan eri tyyppistä ohjelmointia
kuin systeemikielet. Skriptikielten käyttö edellyttää, että
on olemassa joukko hyödyllisiä komponentteja. Skriptikielillä
ei ole tarkoitus kirjoittaa sovelluksia "skrätsistä";
niillä pääasiassa integroidaan olemassa olevia toimintoja yhteen.
Siksi skriptikieliä kutsutaankin myös liimakieliksi
tai systeemi-integraatiokieliksi.
Jotta komponenttien liimaaminen olisi helppoa, skriptikielet
ovat tyypittömiä (tai dynaamisesti tyypitettyjä).
Myös koodia ja dataa voi sekoittaa siten, että ohjelma
voi generoi koodia ja sitten ajaa sitä lennossa.
Tyypittömän kielen etuja voi arvioida vaikkapa katsomalla
seuraavaa Tcl-komentoa, joka luo yhden käyttöliittymäkontrollin:
button .b -text Hello! -font {Times 16} -command {puts hello}
Java-versiossa tarvittaisiin 7 riviä koodia, ja C++/Microsoft
-versiossa tarvittaisiin 25 riviä koodia. Suurin osa
"ylimääräisestä koodista" aiheutuu vahvasta tyypityksestä.
Skriptikielet ovat korkeamman tason kieliä kuin systeemikielet
siinä mielessä, että kukin koodirivi tuottaa keskimäärin
enemmän toiminnallisuutta.
Yllä olevista seikoista johtuen skriptikielet mahdollistavat
hyvin nopean sovelluskehityksen, koska koodia tarvitsee
tuottaa vähemmän, ja käytännössä sovellusprojektien toteutusaika
on huomattavasti nopeampaa kuin systeemikielillä."
Toimin itse muutamassa pienessä itsenäisessä
Internet-ohjelmistoyrityksessä. Olemme viimeisten kolmen
vuoden aikana havainneet nuo seikat todeksi.
Aikaisemmin koodasimme C:llä ja Javalla
kaupallisia asiakassovellusprojekteja,
nyttemmin PHP:llä, Perlillä ja Anvililla.
Tulos näkyy loppujen lopuksi aika mukavasti yritystemme
liikevaihdossa ja kannattavuudessa.
Viite:
" Scripting: Higher Level Programming for the 21st Century"
http://home.pacbell.net/ouster/scripting.html
JPS
T Teemu E Kurppa
> Jotta komponenttien liimaaminen olisi helppoa, skriptikielet
> ovat tyypittömiä (tai dynaamisesti tyypitettyjä).
> Myös koodia ja dataa voi sekoittaa siten, että ohjelma
> voi generoi koodia ja sitten ajaa sitä lennossa.
>
> Tyypittömän kielen etuja voi arvioida vaikkapa katsomalla
> seuraavaa Tcl-komentoa, joka luo yhden käyttöliittymäkontrollin:
>
> button .b -text Hello! -font {Times 16} -command {puts hello}
OCamlissa (www.ocaml.org) sama sanottaisiin seuraavasti:
let b = Button.create ~text:"Hello!" ~font:"Times 16"
~command:(fun () -> print_string "Hello")
OCaml on vahvasti ja staattisesti tyypitetty kieli, jossa on tyypinpäättely.
_Kääntäjä_ huomaisi tyyppivirheen seuraavassa määrittelyssä:
let b = Button.create ~text:1000
> Java-versiossa tarvittaisiin 7 riviä koodia, ja C++/Microsoft
> -versiossa tarvittaisiin 25 riviä koodia. Suurin osa
> "ylimääräisestä koodista" aiheutuu vahvasta tyypityksestä.
Höpö höpö. Vahva staattinen tyypitys ja kompakti ilmaisu ovat mahdollisia
moderneissa ohjelmointikielissä kuten Ocaml ja Haskell. Käännösaikainen
tyypinpäättely on todella hieno kielen ominaisuus, joka ei valitettavasti
esiinny valtavirtakielissä. Se on ainakin minut saanut kyseenalaistamaan
perinteisten dynaamisesti tyypitettyjen skriptikielten tarpeellisuuden ja
skriptaan nykyään Ocamlilla.
Ja mitä skriptaukseen tulee, itse kutsun skriptauskieliä englannin
kielisellä termillä "domain-specific language". Tämä on mielestäni parempi
termi: jokin kieli soveltuu nopeaan ohjelmointiin tietyllä alueella, esim.
tiedostojen ja hakemistojen käsittelyyn, pelien tekoälyyn, web-palveluiden
tekoon... Itse en usko, että esim. dynaaminen tai heikko tyypitys olisi
tällaisiin kieliin staattista vahvaa tyypitystä parempi. Päinvastoin,
erityisesti tehtäessä skriptejä, joita ei ole aikaa paljon testata, on hyvä,
että kääntäjä löytää mahdollisimman monia virhetyyppejä.
--
Teemu Kurppa
Teemu....@Helsinki.fi
Lauri Alanko
> Lainaan tässä vapaasti suomentaen suoraan skriptauksen
> oppi-isää John Ousterhoutia:
Joka ei nauti kovin suurta arvostusta ainakaan minun silmissäni, mutta
eipä hätäillä...
> "Ymmärtääksemme skriptikielen ja systeemikielen eroja, on ymmärrettävä
> miten systeemikielet ovat kehittyneet. Systeemikielet olivat alunperin
> vaihtoehtoja assembly-kielille. Systeemikielillä tarkoitetaan nykyään
> sellaisia kuten PL/1, Pascal, C, C++ ja Java. Systeemikielet eroavat
> assembly-kielistä kahdella tavalla: ne ovat korkeamman tason kieliä ja
> ne ovat vahvasti tyypitettyjä.
Tämän määritelmän mukaan C ei olisi systeemikieli.
> Korkeammalla tasolla tarkoitetaan sitä, että voidaan päästä samaan
> tulokseen kirjoittamalla vähemmän koodia.
Tämä onkin eksoottinen määritelmä. Minusta "korkea taso" on aina
tarkoittanut, että kielessä voidaan suoraan ilmaista lähempänä
ohjelmoijan aivoituksia olevia käsitteitä. Siitä saattaa seurata
tarvittavan koodin lyheneminen, mutta se riippuu muistakin asioista,
kuten kielen syntaksista.
> Skriptikielet, kuten Perl, Python, Rexx, Tcl, Visual Basic ja Unix
> shell-skriptit edustavat aivan eri tyyppistä ohjelmointia kuin
> systeemikielet. Skriptikielten käyttö edellyttää, että on olemassa
> joukko hyödyllisiä komponentteja.
Tämän määritelmän mukaan perl ei ole skriptikieli. Sillä kun saa tehtyä
vaikka kuinka hyödyllisiä ohjelmia vain kielen primitiivioperaatioita
käyttäen. Pythonilla varmaan myös.
> Skriptikielillä ei ole tarkoitus kirjoittaa sovelluksia "skrätsistä";
> niillä pääasiassa integroidaan olemassa olevia toimintoja yhteen.
> Siksi skriptikieliä kutsutaankin myös liimakieliksi tai
> systeemi-integraatiokieliksi.
Toisin sanoen: "skriptikielellä" ei voi tehdä muuta kuin yhdistää
olemassaolevia komponentteja. Täten sitä ei muuhun käytetäkään. Tästä ei
seuraa, etteikö muunlaisella kielellä voisi ihan yhtä hyvin yhdistellä
komponentteja.
Ousterhout ja Stallman kävivät tästä aikoinaan ison tappelun nyysseissä.
Stallmanin teesi oli, että systeemi-integraatiokieleltäkin joku
kuitenkin jossakin vaiheessa tulee tarvitsemaan ihan kaikkia Oikean
Ohjelmointikielen ominaisuuksia, syystä tai toisesta. Joten yhtä hyvin
voi sitten käyttääkin oikeaa ohjelmointikieltä. Stallmanin valinta oli,
yllätys yllätys, Scheme.
> Jotta komponenttien liimaaminen olisi helppoa, skriptikielet
> ovat tyypittömiä (tai dynaamisesti tyypitettyjä).
> Myös koodia ja dataa voi sekoittaa siten, että ohjelma
> voi generoi koodia ja sitten ajaa sitä lennossa.
Tämä onkin ainoa sisällöllinen määritelmä skriptikielelle koko
tekstissä. Hassua kyllä assemblerkin sopii tähän kuvaukseen, kuten myös
Lisp, jolla on kuitenkin tehty käyttöjärjestelmiäkin.
> Tyypittömän kielen etuja voi arvioida vaikkapa katsomalla
> seuraavaa Tcl-komentoa, joka luo yhden käyttöliittymäkontrollin:
>
> button .b -text Hello! -font {Times 16} -command {puts hello}
>
> Java-versiossa tarvittaisiin 7 riviä koodia, ja C++/Microsoft
> -versiossa tarvittaisiin 25 riviä koodia. Suurin osa
> "ylimääräisestä koodista" aiheutuu vahvasta tyypityksestä.
Kummassakin suurin osa ylimääräisestä koodista aiheutuu
anonyymifunktioiden puutteesta sekä yleisestä syntaktisesta
pitkäsanaisuudesta, ei tyypityksestä. Vaan mistäköhän nuo luvut on
revitty? Vastaavalla rajapinnalla (modulo nimetyt argumentit) Javalla ja
C++:lla tuo menisi suunnilleen näin:
// Java
Button b = new Button("Hello!", "Times 16",
new Callback(){public void call() {
System.out.print("hello");
} });
// C++
class PrinterCallback : public Callback {
string msg;
public:
PrinterCallback(const string& m):msg(m){}
void call() { cout << msg; }
};
// unohdetaan muistinhallintakysymykset...
Button* b = new Button("Hello!", "Times 16", new PrinterCallback("hello"));
Tietenkään aivan tuollaista rajapintaa ei tietääkseni Swingissä tai
MFC:ssä ole, mutta tällöin kritiikki kohdistuukin _kirjastoihin_, ei
itse kieleen.
Ja kuten Teemu Kurppa jo osoittikin, staattinen tyypitys ei millään
tavoin suoraan implikoi koodin pituutta.
> Skriptikielet ovat korkeamman tason kieliä kuin systeemikielet
> siinä mielessä, että kukin koodirivi tuottaa keskimäärin
> enemmän toiminnallisuutta.
No tämä ei ole mikään ihme, jos määritelmän mukaan skriptikieltä
käytetään vain jo valmiiksi tehtyjen hyvin "toiminnallisten"
komponenttien käyttöön. Tuo ei ole itse kielen vaan käyttötavan
ominaisuus.
> Yllä olevista seikoista johtuen skriptikielet mahdollistavat
> hyvin nopean sovelluskehityksen, koska koodia tarvitsee
> tuottaa vähemmän, ja käytännössä sovellusprojektien toteutusaika
> on huomattavasti nopeampaa kuin systeemikielillä."
Ylläpidosta ei sitten sanotakaan mitään.
> Toimin itse muutamassa pienessä itsenäisessä
> Internet-ohjelmistoyrityksessä. Olemme viimeisten kolmen
> vuoden aikana havainneet nuo seikat todeksi.
> Aikaisemmin koodasimme C:llä ja Javalla
> kaupallisia asiakassovellusprojekteja,
> nyttemmin PHP:llä, Perlillä ja Anvililla.
Nuo voivat hyvinkin olla C:tä ja Javaa vähemmän työläitä kieliä teidän
tarkoituksiinne, mutta se ei todellakaan ole vielä paljon sanottu.
Eli en ole vielä yhtään vakuuttunut siitä, että mitään
systeemi/skriptikieli -eroa on mielekästä tehdä. Monet kielet soveltuvat
hyvin sekä matalan tason ohjelmointiin että valmiiden pakettien
ohjailuun, lispit ehkä etunenässä. Oletteko muuten vilkaisseet BRL:ää?
http://brl.sourceforge.net/
Lauri Alanko
l...@iki.fi
Jaripekka Salminen
olevan asiallisempia kuin lainaamani Ousterhoutin
teesit skriptikielien ja systeemikielien olemuksesta.
Täytyy kääntyä samoille kannoille kirjoittajien kanssa siitä,
että skripti/systeemi erottelu on turhaa.
Tästä lähtien emme kutsukaan Anvilia skriptikieleksi,
vaan vain yleiskäyttöiseksi ohjelmointikieleksi.
Siinä kun on kaikki "Oikean Ohjelmointikielen" ominaisuudet.
Sitä voidaan käyttää "domain-specific" -kielenä, joka soveltuu
erityisesti web-palveluiden tekoon, erityisesti
server-side Java-alustalle.
Komponenttejakin me koodaamme itse Anvililla, ja liimaaminen
tapahtuu visuaalisella työkalulla (joka on koodattu Anvililla,
joka tuottaa liimaksi lisää Anvilia...).
Arvostaisimme kovasti joitakin kommentteja tämän Jani Lehtimäen
kehittämän ohjelmointikielen olemuksesta. Aika hyvän yleiskäsityksen
voi saada katsomalla joitakin live Anvil-esimerkkien sourceja
osoitteessa http://njet.org/examples/
JPS