Cargo är en wrapper för programatisk styrning av Servlet- och J2EE-containrar. T ex stöds Tomcat, Jetty, JBoss och Weblogic (och några till).

Grund-API:et är enkelt, t ex:

InstalledLocalContainer container = new Resin3xInstalledLocalContainer(configuration);
container.setHome("c:/apps/resin-3.0.18");

container.start();

Denna användning är inte särskilt praktisk eller användbar, varför man snabbt letar upp Ant tasks eller Maven-pluginen. Varje container har en egen plugin, som kan vara olika mogen.

Cargos hemsida innehåller några exempel på konfiguration, och här har jag knyckt ett:

<container>
 <containerId>orion2x</containerId>
 <home>c:/apps/orion-2.0.5</home> or
 <zipUrlInstaller>
  <url>http://www.orionserver.com/distributions/orion2.0.5.zip</url>
  <installDir>${java.io.tmpdir}/cargoinstalls</installDir>
 </zipUrlInstaller>
</container>

<configuration>
 <type>standalone</type>
 <home>${project.build.directory}/orion2x</home>
 <properties>
  <cargo.servlet.port>8080</cargo.servlet.port>
  <cargo.logging>high</cargo.logging>
 </properties>
<configuration>

Med Tomcat var det inga problem alls. Det finns många och bra exempel och det är enkelt att få det mesta att fungera. T ex är det ganska häftigt att man har möljligheten att ange en url som containern hämtas från om den inte finns intallerad (gäller inte bara Tomcat; se zipUrlInstaller i exemplet ovan).

Med OC4J var det värre. Dels är det explicit att allt stöd inte finns implementerat, dels fick jag inte ens igång det, eftersom ett antal properties saknades. I konfigurationsexemplet ovan ser vi t ex cargo.servlet.port och cargo.logging. Utöver sådana, finns ett antal properties som är specifika per container. OC4J behövde ett antal sådana och det felmeddelande Maven gav var allt annat än snällt. I detta läge var det bara att ladda ner koden till Cargo, utan pluginen, och debugga sig fram till vad som saknades. Älska open source.

För att göra en lång historia kort, kan jag beräata att det går att få upp en haltande OC4J med Cargo/Maven. Dock är det smidigare att faktiskt använda Mavens exec-pluginoch köra containern manuellt.

Slutbetyget för Cargo är nja. Idén är super och stödet för vanliga containrar bra, men blandar man in Maven-pluginen sänks betyget. När man kör mvn cargo:start går Maven in i något slags loop, som inte avbryts fastän man kör mvn cargo:stop. Detta är mer opraktiskt och irriterande än det låter och försvårar automatiserad testning. Eftersom det säkert är en konfigurationsfråga får någon som vet hur man stänger av det gärna maila mig och berätta.

Det här inlägget hade varit så aktuellt för några månader sen. Precis när Google släppte sin App Engine för Java. För dem som inte vet, så är Google App Engine Googles tolkning av molnprogramvara.

Jag har för några veckor testat att skriva en riktig applikation för att se hur hela processen ser ut. Här följer några reflektioner.

Konto

Jag registrerade mig som något slags testanvändare och fick vänta några dagar på ett konto. För att aktivera det fick man uppge sitt mobilnummer, vilket alltid är läbbigt, speciellt när det gäller Google. Å andra sidan äger de mitt liv i alla fall. Kontot hittas på https://appengine.google.com/, som innehåller ett enkelt interface där ens molnapplikationer finns listade med sina versionsnummer och där man kan skapa nya. Totalt 10 stycken får man ha. Klickar man sedan på en applikation får man upp adminkonsolen som visar en massa detaljer om applikationen och tillhandhåller lite adminfunktionalitet.

De viktigaste är “Admin logs” och “Data Viewer”. Loggar som loggar, medan data viewern utgör interfacet mot databasen (CRUD). Den är otroligt enkel, men duger. Tänk PHP Mysql, fast simplare.

Tjänster

En “molnapplikation” hos Google är tänkt att sättas samman av några API:er och tjänster:

Persistens: JPA eller JDO
Inloggning: Google Accounts
Mail: JavaMail
Cachning: Memcache(JCache)
Interaktion med andra siter: URL Fetch 
Bildhantering: Images

De flesta sakerna i listan ovan borde vara bekanta. Värd att nämna är bildhanteringen. Det API som tillhandahålls möjliggör enkla manipulationer av bilder; rotation, skalning m m.

Utveckling

Tanken är att man ska använda Googles App Engine SDK, som ska simulera applikationens beteende i molnet. Självklart fungerade inte detta på min Vista 64, men på en XP gick det. I SDK:n ingår alltså en server som fejkar allt, t o m persistens-API:t.

Det normala är att man laddar ner en Eclipse-plugin, som lägger till lite nya knappar, främst för att deploya remote till molnet. Pluginen fungerar bra, men om man deployar många gånger kan det kärva ihop sig.

Programeringsmodellen är Servlet/EJB. Alltså inga filer, inga trådar o s v. Kodar man J2EE till vardags är det inget konstigt. En grundstruktur för en molnapplikation skapas av pluginen, och är ren webbapplikation så när som på någon extra XML-descriptor.

Det finns inga direkta restriktioner på vilka tredjeparts-jarar man får använda, bara de inte bryter mot grundläggande EJB-regler. Litor med testade bibliotek och whitelists för enskilda klasser finns.

Hur bra är det då?

Min applkation var enkel och använde sig bara av JPA och Google Accounts, och bägge fungerade bra. Pluginen i Eclipse fungerade också bra, men en deployment tar lite tid, och kan köra ihop sig. SDK:ns server fungerade inte .

I stort fungerar allt, men det blir ju en annan utvecklingscykel. En del saker känns lite ovant, som att inte ha en SQL-konsol mot databasen. Det som tog tid när jag testade var vanlig pill med JSP, EL och web.xml, alltså ingenting med själv molnmotorn.

Google har tagit en egen väg genom att lägga abstraktionsnivån så högt. Som utvecklare har man tjänsterna och API:erna och inget mer. Noll kontroll.

Detta gör att man kanske inte ska migrera sitt tunga affärssystem till Google App Engine, men å andra sidan finns det få plattformar som kan tävla i RAD och time to market för enklare webbapplikationer.