Innledende Analyse (Under utvikling)

Transkript

1 Innledende Analyse (Under utvikling) Arianna Kyriacou 1. juni 2004 Innhold 1 Inspirasjon 3 2 Generell Prosjektbeskrivelse (Av Iskra Fadzan og Arianna Kyriacou) Hovedmål Mål (mer konkret) Krav Bakgrunn Spesifikk beskrivelse Hovedmål Mål (mer konkret) Krav Markedsfaktorer Konkurrenter Teknologier J2EE J2ME Database, lagringsteknologi og strukturering av data Protokoller Markedstrender Forventet antall brukere Fremtidige trender Standard Systemer Risikofaktorer Kort liste Antagelser Antagelser om Verktøy Andre antagelser

2 7 Verktøy Hovedverktøy Eventuelle hjelpeverktøy

3 1 Inspirasjon Ideen til denne oppgaven kom delvis fra samarbeidet mellom Khaled Mughal og Kjell J. Hole da de holdt seminaret Java Network Programming høsten 2003, og delvis fra at Mughal ble inspirert av keynote speaker Tim O Reilly på konferansen i Objekt-Orientert Programmering, OOPSLA 2003: OOPSLA 2003 Conference on Object-Oriented Programming, Systems, Languages, and Applications October, Anaheim, California. Keynote Speaker OOPSLA 2003: The Internet Paradigm Shift: Sitat: The computer industry has gone through a sea change in the past few years. The killer applications of the web era turned out not to be PC-based software packages like the web browser, but web hosted applications like google, mapquest and amazon.com. These applications are built on top of Linux and Apache, yet they are themselves fiercely proprietary. But what would most developers do with their source code? These massive systems are valuable for their data as much as for their programs. And by opening up XML web services APIs to that data, the most innovative of these sites are creating new opportunities for hackers to re-use that data and scratch their own itch. What s more, as constantly updated services, these applications operate on very different timelines and processes than conventional software development. One of the greatest challenges for developers in the next few years is to understand and adapt to the paradigm shift implicit in network computing, and to shed the legacy thinking of the desktop era. Sitat slutt. O Reilly-linker: Nedlastbare presentasjonsfiler: Keynotes: Speakers: 3

4 2 Generell Prosjektbeskrivelse (Av Iskra Fadzan og Arianna Kyriacou) 2.1 Hovedmål I dette prosjektet skal vi se nærmere på brukerdrevet ressursdeling over nettverk, og utvikle/designe et distribuert system; et java-basert klient-server-program som tilbyr og utfører disse tjenester for bruker. En server tilbyr en rekke tjenester, en klient spør serveren om å få utført disse. 2.2 Mål (mer konkret) Vi skal se på to typer klienter, en som kjører på en mobiltelefon eller en PDA (Personal Digital Assistant), og en som kjører på en PC. Serveren skal kjøre på en stasjonær PC. Den skal kunne håndtere forespørsler fra begge typer klienter, men må differensiere mellom de ettersom mobil/pda-klienten ikke kan håndtere like mye data som PC-klienten, siden den har mindre CPU og minnekapasitet tilgjengelig. Figur 1: Nettverksmodell Klienter: To versjoner: ˆ En for mobiltelefoner/pda er (trådløst nett), ˆ og en for PC er. Server: Er felles for begge klient-versjonene. ˆ Kjører på stasjonær PC. Må muligens ha forskjellig grensesnitt mot de to klient-versjonene. Transport: Vi velger å bruke HTTP-protokoll. 4

5 ˆ Fra Klient til Server: HTTP-request. ˆ Fra Server til Klient: HTTP-respons. Enda mer konkret: ˆ Ressurser som kan deles kan være for eksempel -adresser, bilder, musikk, filmer, tekstfiler eller internettadresser (URL er). URL står for Universal Resource Locator og er en unik adresse for en ressurs på nettet. ˆ Brukere skal ha tilgang til sine egne ressurser uavhengig av hvilken enhet (smart-telefon, PDA eller PC) de bruker. ˆ Ressursene skal kunne sorteres for å gjøre søkingen lettere for bruker. ˆ Det skal være mulig å hente ressurser fra andre brukere. ˆ Systemet skal kunne overvåke en nettsesjon og ta vare på alle hyperlinker det klikkes på ˆ Det skal være mulig å opprette en lukket gruppe av brukere som kan dele ressurser mellom seg. ˆ Bruker skal ha mulighet til å lagre/hente frem ressursene sine lokalt. 2.3 Krav Situasjons-scenarier: 1. En gruppe mennesker jobber for på et prosjekt der det er nødvendig å hente informasjon fra internett. Prosjektdeltakerne bruker søkemotorer for å finne frem til ønskelig informasjon, og søker på forskjellige typer nøkkelord. For hvert søk som gjøres inneholder resultatet en begrenset mengde URL er/linker som er interessante, men deltakeren som gjør søket må som oftest gå inn på selve internettsiden linken viser til for å finne ut om informasjonen er interessant eller ikke. Siden et slikt søk kan gi en stor mengde treff kan arbeidet med å plukke ut relevante linker ta lang tid. Det er da ønskelig at prosjektdeltakerne kan få fordel av hverandres arbeid, slik at alle ikke må gjøre samme type søk. Deltakerne ønsker å dele disse ressursene med hverandre. 2. En annen situasjon kan være en enkeltperson som ønsker å få tilgang til utplukkede linker fra slike søkeresultater som andre (ukjente) har gjort tidligere. Denne personen kan også ha en fin samling linker han ønsker å dele med andre, og som han selv ønsker tilgang til uansett hvilken maskin han sitter på og hvilken nettleser den har tilgjengelig. Avgrensning: ˆ Vi konsentrerer oss om deling av internettadresser, dvs.url er som ressurs. ˆ Vi ser bort fra lukkede grupper Vårt system skal tilby følgende funksjonalitet: Gitt en sti til en katalog på den lokale disken. I denne katalogen skal både den lokale klienten (applikasjonen) og http-klienten (nettleseren) lagre en fil som inneholder adresseboken til bruker. 5

6 Figur 2: Oversikt over Klient-enheten (Grønn del). Den har en http-klient-del (via nettleser) og en lokal-klient-del (applikasjon som er installert på enheten). Klient-enheten kan være en PC, en PDA eller en mobiltelefon. HTTP-KLIENTEN (Via nettleser): (To versjoner: En for mobiltelefoner/pda er og en for PC er) Krever ingen installering, kun nettforbindelse. Bruker skal kunne: ˆ Logge seg på med brukernavn og passord ˆ Lagre/slette internettadresser i databasen ˆ Lagre internettadresser lokalt ˆ Søke blant sine internettadresser ˆ Hente internettadresser en annen bruker har lagret ˆ Kjøre sesjonsovervåker DEN LOKALE KLIENTEN (Applikasjonen): (To versjoner: En for mobiltelefoner/pda er og en for PC er) Krever installering. Bruker skal kunne: ˆ Hente adressebok lagret lokalt av systemet ˆ Lagre/slette internettadresser lokalt ˆ Søke blant sine internettadresser ˆ Opprette forbindelse til server ˆ Synkronisere adresseboken mot databasen ˆ Kjøre sesjonsovervåker? ˆ Hente internettadresser en annen bruker har lagret 6

7 SERVEREN: ˆ Må kunne lagre ressursene i en eller annen form for database (SQL/XML) der den lett kan hente ut informasjon brukeren spør etter via klienten. ˆ Hvis flere brukere lagrer samme ressurs, lagres den bare en gang i databasen. ˆ Den må kunne utføre alle tjenester klienten har tilgjengelig for bruker. NETTVERKET: ˆ Serveren må kunne kommunisere med klienten via et nettverk. Vi vil sannsynligvis velge HTTP som nettverks-transport mellom klient og server. HTTP er en request/response protokoll: klienten sender en HTTP-request til serveren, og denne svarer med å sende tilbake en HTTP-response til klienten. HTTP-protokollen har bl.a. som fordel at den passerer gjennom brannmurer. 2.4 Bakgrunn Den største bruken av Internett er basert på framhenting av informasjon om et ønsket tema lagret på en ukjent maskin i nettverket. Flere eksisterende søkesystemer gjør slik bruk enkel. Først taster vi inn et nøkkelord som beskriver hvilket tema vi er interessert i å finne informasjon om. Systemet svarer f. eks. med en liste på 250 nettsteder med informasjon og spesifiserer kanskje de 50 mest aktuelle stedene (etter systemets mening). Etterpå må vi åpne hver av disse sidene og se på innholdet for å avgjøre om informasjonen er interessant. Denne prosessen er veldig tidkrevende og vi vil derfor ta vare på de sidene vi synes er mest relevante slik at vi slipper å åpne alle sidene igjen neste gang vi søker etter informasjon med samme nøkkelordet. I de fleste nettlesere (som for eksempel Internet Explorer, Mozilla, Opera og Netscape) er det muligheter for å lagre adressene (URL er). De legges i en adressebok hvor adressene er organisert i en mappestruktur. Men disse adressebøkene henger sammen med nettleseren, noe som gjør det vanskelig for brukeren å beholde den samme adresseboken når han går fra maskin til maskin. I enkelte nettlesere kan adressebøkene eksporteres, men formatene de eksporteres til er lukkede binære formater eller ustrukturerte, flate filer som legger begrensninger på nivået av nøsting en kan anvende. Det er ønskelig å kunne hente adressebøker til andre med samme interesser som oss. Disse adressebøkene kan ligge i en database slik at hver enkel bruker kan oppdatere sin adressebok og synkronisere den med andre adressebøker av interesse. I stedenfor å surfe på nettet og lete selv kan vi hente adressebøker til andre brukere som allerede har funnet sider med informasjon om det vi trenger. På denne måten sparer vi tid når vi trenger informasjon på nettet. Et annet verktøy til hjelp med informasjonsframhentingen er et verktøy som automatiserer nettsesjoner ved for eks. å overvåke en nettsesjon og ta vare på alle hyperlinker det klikkes på. Det finnes mange måter å forbedre adressebøkene i dagens aktuelle nettlesere og det er det vi vil prøve å oppnå med denne oppgaven. 7

8 3 Spesifikk beskrivelse Min del av oppgaven: 3.1 Hovedmål Jeg skal utvikle/designe et distribuert system der transport av data/ressurser går over et trådløst nettverk; et java-basert klient-server-program orientert mot mobiltelefoner/pda som klienter, der systemet/serveren tilbyr og utfører tjenester som handler om ressursdeling. I tillegg har klienten også en applikasjonsdel (en MIDlet i dette tilfellet) som kan installeres på enheten for å ta seg av funksjonalitet som bl.a. har med lokal lagring av ressurser å gjøre. Det siste nye innen teknologi skal brukes under utviklingen. Figur 3: Nettverksmodell: mobiltelefon/pda-klienter, nettverk og server med database. Klienter: Mobiltelefoner/PDA er (trådløst nett) Transport: HTTP-protokoll. Server: Kjører på stasjonær PC. 3.2 Mål (mer konkret) Jeg skal se på mobiltelefon/pda-klienten. Den har to deler: en http-klient som kommuniserer via nettleser, og en lokal-klient (applikasjonsdel). Serveren kjører på stasjonær PC. Den må kunne håndtere forespørsler fra klienter med begrenset båndbredde, minnekapasitet og prosessorkraft, typisk batteridrevne enheter (devices). Applikasjonsdelen til klienten, MIDlet en, som skal kjøre på en slik enhet, må også ta hensyn til de samme begrensningene. MIDlet en implementeres vha MIDP (Mobile Information Device Profile), som er en del av J2ME (en 8

9 java-platform i micro-utgave). MIDP har tilgjengelig en samling API er (pakker) beregnet på nettopp utvikling av applikasjoner som skal kjøre på små enheter. Jeg må sette meg grundig inn i J2ME-teknologi, spesielt i de delene jeg regner med å bruke, som MIDP og RMS, samt verktøy jeg skal bruke som har disse teknologiene tilgjengelig, som J2ME Wireless Toolkit. Jeg skal bruke de aller siste utgavene av interessant teknologi. Når det gjelder MIDP blir det MIDP versjonen. For serveren skal siste versjon av Tomcat brukes; Tomcat Den er en servlet/jsp-kontainer, og implementerer Servlet 2.4 og JSP 2.0 (JavaServer Pages 2.0) - spesifikasjonene. En stor del av oppgaven vil gå ut på å sette meg inn i ny teknologi, samt verktøy som implementerer denne teknologien. Som nettleser vil jeg bruke Opera som standard, hvorfor blir omtalt senere i dokumentet. Ellers blir de mer konkrete målene for selve systemet omtrent de samme som i den generelle beskrivelsen: Mer konkrete mål: ˆ Ressurser som kan deles kan være for eksempel -adresser, bilder, musikk, filmer, tekstfiler eller internettadresser (URL er). ˆ Brukere skal ha tilgang til sine egne ressurser uavhengig av hvilken konkret enhet (smart-telefon/pda) de bruker. ˆ Ressursene skal kunne sorteres for å gjøre søkingen lettere for bruker. ˆ Det skal være mulig å hente ressurser fra andre brukere. ˆ Systemet skal kunne overvåke en nettsesjon og ta vare på alle hyperlinker det klikkes på ˆ Det skal være mulig å opprette en lukket gruppe av brukere som kan dele ressurser mellom seg. ˆ Bruker skal ha mulighet til å lagre/hente frem ressursene sine lokalt på enheten. 9

10 3.3 Krav Figur 4: Klientmodell: Mobiltelefon/PDA-klient (grønn del) og server med database. Klient: Mobiltelefon eller PDA Transport: HTTP-protokoll. Server: Kjører på stasjonær PC. Funksjonaliteten er stort sett den samme som omtalt i den generelle beskrivelsen: HTTP-KLIENTEN (Via nettleser): Krever ingen installering, kun nettforbindelse. Bruker skal kunne: ˆ Logge seg på med brukernavn og passord ˆ Lagre/slette internettadresser i databasen ˆ Lagre internettadresser lokalt ˆ Søke blant sine egne internettadresser ˆ Hente internettadresser en annen bruker har lagret ˆ Kjøre sesjonsovervåker DEN LOKALE KLIENTEN (MIDLet en): Krever installering. Bruker skal kunne: ˆ Hente adressebok lagret lokalt av systemet ˆ Lagre/slette internettadresser lokalt (vha RMS-teknologi) 10

11 ˆ Søke blant sine internettadresser ˆ Opprette forbindelse til server (via http-klienten/nettleser?) ˆ Synkronisere adresseboken mot databasen ˆ Kjøre sesjonsovervåker? ˆ Hente internettadresser en annen bruker har lagret i serverens database SERVEREN: ˆ Må kunne lagre ressursene i en eller annen form for database (SQL/XML) der den lett kan hente ut informasjon brukeren spør etter via klienten. ˆ Hvis flere brukere lagrer samme ressurs, lagres den bare en gang i databasen. ˆ Den må kunne utføre alle tjenester klienten har tilgjengelig for bruker. NETTVERKET: ˆ Serveren må kunne kommunisere med klienten via et nettverk. Jeg vil bruke HTTP som nettverks-transport mellom klient og server. HTTP er en request/response protokoll der klienten sender en HTTP-request til serveren, og denne svarer med å sende tilbake en HTTP-response til klienten. HTTP-protokollen har bl.a. som fordel at den passerer gjennom brannmurer. AVGRENSNING: ˆ Ressurser som skal deles er kun URL er (internettadresser). ˆ Jeg ser bort fra funksjonalitet som har med lukkede grupper å gjøre. ˆ Jeg ser foreløpig også bort fra funksjonalitet som har med nettsesjonen å gjøre. ˆ Jeg antar foreløpig at jeg har en server som er i stand til å utføre de tjenester klienten ellers ber den om. ˆ Når det gjelder klienten konsentrerer jeg meg først om applikasjonen/midlet en (den lokale-klienten-delen). 11

12 4 Markedsfaktorer 4.1 Konkurrenter Når systemet jeg skal designe kun skal konsentrere seg om URL er som ressurs, blir det en slags Bookmark Manager. Det finnes allerede en del slike systemer fra før, og selv om de ikke har nøyaktig samme funksjonalitet som det vi har tenkt å ha med, blir de likevel konkurrenter. En av våre tilsynelatende største konkurrenter er Powermarks. URL: De har med det meste av interessant funksjonalitet, som muligheter for å eksportere adresselister til databasen, synkronisere dem mot databasen, publisere dem (blir en slags dele funksjon), lokal lagring og mulighet for å eksportere adresselisten til diverse andre format. Systemet er også nettleser-uavhengig og har en rask søkemotor for adressesamlingen. Det er likevel en del funksjonalitet de ikke har, enda!, som mulighet for å opprette lukkede grupper, søke i andres samlinger og sist men ikke minst; tilgang fra mobiltelefon/pda og applikasjon som kan innstalleres på disse. En annen konkurrent er, OnlineFavourites. URL: Her kan adresselisten nåes fra mobiltelefon, via wap. Adresselisten kan lastes opp fra en PC s nettleser og ned til PC for lagring lokalt. Den kan også lagre -adresser og har dessuten en personlig notisblokk. Jeg kan ikke se at den har applikasjoner som kan innstalleres lokalt, hverken på PC eller mobiltelefon/pda, heller ikke muligheter for å dele ressurser med andre. En tredje konkurrent er ol bookmarks. URL: Den har en hel rekke interessant funksjonalitet, som støtte for flere språk, multibel bruker støtte (jeg vet ikke om denne funksjonaliteten har med deling av ressurser å gjøre eller ikke), etc. Adresselisten er ordnet i mappestruktur, men man kan søke med deler av url en i tillegg til nøkkelord. Den har ikke funksjonalitet som tilgang fra mobiltelefon/pda. En fjerde er Link2Mark. URL: Denne er web-basert og har ikke applikasjoner som kan innstalleres lokalt. Her har en tilgang til adresselisten også via wap, og en har mulighet for å dele linkene med andre brukere eller gå til en side der man deler linker. Søker man på URL-Harvester får man sånn bortimot 162 treff! Enda flere hvis man ikke bruker bindestrek mellom ordene. De treffene som virker interessante her, omtaler stort sett funksjonalitet som ligner på vår sesjonsovervåker som er omtalt i beskrivelsen. Men i stedet for å ta vare på de hyperlinker som blir klikket på, trekker de ut alle hyperlinker fra en side. Et eksempel er Web Data Ekstractor. URL: 12

13 Konklusjon: Selv om det finnes mange konkurrenter på markedet, kan jeg ikke se at noen av dem jeg har gått nærmere inn på har samme totale funksjonalitet som vårt planlagte system, eller som min del av oppgaven. 4.2 Teknologier For ytterligere informasjon om teknologi enn det som er omtalt her, finner du en god samling linker på denne siden under linken teknologi : URL: arianna/prosjekt/ J2EE JSP 2.0 (JavaServer Pages) Servlet J2ME J2ME er en java-platform i micro utgave som brukes til utvikling av applikasjoner ment å kjøre på små innretninger/enheter (devices). Eksempel på enheter er mobiltelefoner, PDA er og lignende. Dvs. små håndholdte duppeditter. Felles for enhetene er at de har lite minnekapasitet og prosessorkraft tilgjengelig spesielt sett i forhold til stasjonære og bærbare PC er. De har også tilsvarende små skjermer. Det sier seg selv at applikasjonene som skal kjøre på disse enhetene må kreve minimalt med minne og prosessorkraft. J2ME er delt inn i: ˆ konfigurasjoner ˆ profiler ˆ valgfrie API er (pakker) Figur 5: J2ME Universet 13

14 En konfigurasjon er en samling pakker designet for en spesiell type enhet, og er basert på minnekapasitet og prosessorkraft denne har tilgjengelig. Den spesifiserer en Java Virtuell Machine (JVM) som enkelt kan overføres til en enhet som støtter konfigurasjonen. JVM er en programvare. Den spesifiserer også en undermengde av J2SE (Standard java-platform) sine API er i tillegg til nødvendige tilleggs-api er platformen trenger. Profiler er mer spesifikke. En profil er basert på en konfigurasjon, og legger til API er for brukergrensesnitt, utholdende (persistent) lagring og andre pakker som er nødvendige for å kunne kjøre en applikasjon på enheten. Valgfrie API er definerer spesifikk tilleggsfunksjonalitet som kan inkluderes i en konfigurasjon. Et eksempel er API er for Bluetooth-kommunikasjon. Når en konfigurasjon, profil og valgfrie API er er implementert på en innretning, blir de tilsammen kalt for en stack. CLDC 1.1 (J2ME Connected Limited Device Configuration, siste versjon) CLDC er et spesifikasjonsdokument. CLDC-konfigurasjonen er myntet på mindre enheter enn CDC-konfigurasjonen, og er konfigurasjonen som vil bli brukt i dette prosjektet. Figur 6: API er tilgjengelig fra CLDC 1.1 CLDC er beregnet på små enheter med begrenset nettverks-forbindelse, der enhetene har fra 160KB til 512KB minne tilgjengelig for java-platformen. CLDC er basert rundt KVM (Kilo Virtuell Machine ), en mikroutgave av JVM ( Java Virtuell Machine ). KVM er så liten at den blir målt i KB istedetfor MB (som JVM), derfor navnet. CLDC definerer en kjerne av API er, de fleste fra J2SE. Den siste versjonen: CLDC 1.1 er enda ikke i bruk på de trådløse enhetene, så det kan virke som om CLDC 1.0 er konfigurasjonen som må brukes i prosjektet. CLDS 1.0 har ikke pakken java.lang.ref og har noe mindre funksjonalitet tilgjengelig i de andre pakkene. Stort sett mister en kun flyt-tall. MIDP 2.0 (J2ME Mobile Information Device Profile, siste versjon) Profilen MID(P) er basert på/bygger på CLDC-konfigurasjonen, og legger til API er for grensesnitt, spill, media, midlets, lagring etc. i tillegg 14

15 Figur 7: API er tilgjengelig fra MIDP 2.0 til kjerne-funksjonaliteten som allerede er tilgjengelig fra CLDC. MID(P) profilen gjør tilgjengelig en standard platform for små, ressurs-begrensede, mobil-enheter med trådløs forbindelse, karakterisert som følger: ˆ 512K totalt minne (ROM + RAM) tilgjengelig for Java runtime og biblioteker. ˆ Begrenset prosessorkraft/ytelse, og typisk batteri-drevet. ˆ Nettverksforbindelse til trådløse nettverk med begrenset båndbredde. ˆ Brukergrensesnitt med varierende grad av sofistikasjon. MIDlets (MIDP - applikasjoner) En MIDlet er en MIDP-applikasjon, implementert på en platform som støtter MIDP, som J2ME-platformen. Eksempel på en server som svarer en MIDP-klient, SampleServer.java: ======================================== package j2me.techtips; import java.io.*; import java.util.*; import javax.servlet.*; import javax.servlet.http.*; /** * A simple example of a servlet that responds to an * input stream sent to it by a MIDP client. */ public class SampleServer extends HttpServlet { public void dopost( HttpServletRequest request, 15

16 HttpServletResponse response ) throws IOException, ServletException { // Get the input stream and read the data... ServletInputStream in = request.getinputstream(); DataInputStream din = new DataInputStream( in ); String text = din.readutf(); din.close(); // Do something with the data. In this case // make the string upper case and split it // into tokens. text = text.touppercase(); StringTokenizer tok = new StringTokenizer( text ); Vector v = new Vector(); while( tok.hasmoretokens() ) { v.addelement( tok.nexttoken() ); // Form a response: send back the # of strings // followed by each string in turn. ByteArrayOutputStream bout = new ByteArrayOutputStream(); DataOutputStream dout = new DataOutputStream( bout ); int size = v.size(); dout.writeint( size ); for( int i = 0; i size; ++i ){ dout.writeutf( (String) v.elementat( i ) ); byte[] data = bout.tobytearray(); // Set the response headers and data... 16

17 response.setcontenttype( "application/octet-stream " ); response.setcontentlength( data.length ); response.setstatus( response.sc _OK ); OutputStream out = response.getoutputstream(); out.write( data ); out.close(); ======================================== Eksempel på en MIDlet som bruker httpforbindelse(httpconnection), SecondExample.java: ======================================== import java.io.*; import javax.microedition.midlet.*; import javax.microedition.io.*; import javax.microedition.lcdui.*; /** * An example MIDlet to fetch a page using an HttpConnection. */ public class SecondExample extends MIDlet { private Display display; private String url = ; public SecondExample() { display = Display.getDisplay(this); /** * This will be invoked when we activate the MIDlet. */ public void startapp() { // Use the specified URL is overriden in the descriptor try { downloadpage(url); catch(ioexception e) { // handle the exception private void downloadpage(string url) throws IOException 17

18 private Display display; private String url = ; public SecondExample() { display = Display.getDisplay(this); /** * This will be invoked when we activate the MIDlet. */ public void startapp() { // Use the specified URL is overriden in the descriptor try { downloadpage(url); catch(ioexception e) { // handle the exception private void downloadpage(string url) throws IOException { StringBuffer b = new StringBuffer(); InputStream is = null; HttpConnection c = null; TextBox t = null; try { long len = 0 ; int ch = 0; c = (HttpConnection)Connector.open(url); is = c.openinputstream(); len =c.getlength() ; if ( len!= -1) { // Read exactly Content-Length bytes for (int i =0 ; i len ; i++ ) if ((ch = is.read())!= -1) b.append((char) ch); else { // Read till the connection is closed. while ((ch = is.read())!= -1) { len = is.available() ; b.append((char)ch); t = new TextBox( hello again..., b.tostring(), 1024, 0); finally { is.close(); c.close(); 18

19 display.setcurrent(t); /** * Pause, discontinue... */ public void pauseapp() { /** * Destroy must cleanup everything. */ public void destroyapp(boolean unconditional) { ======================================== Eksemplene er hentet fra: Kort om PDAP (J2ME Personal Digital Assistant Profile) Profilen PDA(P) er basert på/bygger på CLDC-konfigurasjonen. PDAprofilen tilbyr brukergrensesnitt og data-lagrings API er for små, ressursbegrensede hånd-holdte enheter som PDA er (personal digital assistants) og Palm Pilots med følgende ressursbegrensninger: ˆ Mellom 512K og 16 MB totalt minne (ROM + RAM) tilgjengelig for Java runtime og biblioteker. ˆ Begrenset prosessorkraft/ytelse, og typisk batteri-drevet. ˆ Brukergrensesnitt med varierende grad av sofistikasjon, men med skjermer som har en total oppløsning på minimum 20,000 pixler, en pointing device, og character input Database, lagringsteknologi og strukturering av data RMS (MIDP Record Management System, J2ME-teknologi) RMS er en API eller pakke som igjen er et subsystem av MIDP, og gjør det mulig for MIDP-applikasjoner (MIDlet er) å kunne lagre date lokalt på selve enheten den kjører på, ( f.eks.på en mobiltelefon) på en persitent måte. Dvs. at lagret data ikke går tapt når applikasjonen slutter å kjøre. Når applikasjonen blir kjørt på enheten igjen kan den hente tilbake de data som ble lagret dermed RMS. På de fleste enheter en kan kjøre MIDP-applikasjoner på, er RMS den eneste muligheten en har for å lagre data lokalt. Dette pga. at et vanlig filsystem ikke er tilgjengelig på enhetene, eller ikke kan nåes via java. 19

20 Figur 8: Innhold i RMS-pakken Sitat fra Record Management System Basics: ( ) The persistent storage facilities provided in the Java 2 Standard Edition (J2SE) platform, such as the JDBC and Object Serialization APIs, are not suitable for handheld devices with a small memory footprint. This is because the storage requirements vary significantly from one resourceconstrained device to another. For example, a MIDlet that lets you buy (add to your portfolio) and sell (delete from your portfolio) stocks through your cell phoneneeds a place to store the stock database. Introducing the RMS: The MIDP provides a mechanism for MIDlets to persistently store data and retrieve it later. This mechanism is a simple record-oriented database called the Record Management System (RMS). A MIDP database (or a record store) consists of a collection of records that remain persistent after the MIDlet exits. When you invoke the MIDlet again, it can retrieve data from the persistent record store. To use the RMS, import the javax.microedition.rms package. Her finnes et eksempel på en Midlet som bruker RMS: XBEL (XML Bookmarks Exchange Language) XBEL er et utvekslingsformat for internett bokmerker/internett adresser. Dokumentasjon finnes her: og den formelle dokument type definisjonen her: 20

21 Et eksempel på et XBEL dokument: Her et lett forkortet utdrag fra example-xbel.xml: <xbel version="1.0"> <title>some of David s Bookmarks</title> <folder> <title>http Clients</title> <bookmark href=" <title>netscape</title> <desc> Netscape 6.2 is the latest update to the Internet browsing, and instant messagin software suite from Netscape. </desc> </bookmark> <bookmark href=" <title>opera</title> <desc>opera -- Simply the Best Internet Experience</desc> </bookmark> <bookmark href=" <title>microsoft Internet Explorer</title> <desc> Internet Explorer 6 sets a new standard in privacy, reliability, and flexibility. Come see how Internet Explorer is leading the way on the Web. </desc> <bookmark href=" <title>amaya</title> <desc> Amaya is a browser/authoring tool that allows you to publish documents on the Web.It is used to demonstrate and test many of the new developments in Web protocols and data formats. Given the very fast moving nature of Web technology, Amaya has a central role to play. It is versatile and extensible and is available on both Unix and Windows 95/NT platforms. </desc> </bookmark> </folder> <folder> <title>extensible Markup Language (XML)</title> <bookmark href=" <title> Scientific American: Feature Article: XML and the Second Generation Web: May 1999 </title> 21

22 <desc> The combination of hypertext and a global Internet started a revolution. A new ingredient, XML, is poised to finish the job. by Jon Bosak and Tim Bray </desc> </bookmark> <bookmark href=" <title>xml in 10 Points</title> </bookmark> <folder> <title>building XML Documents</title> <bookmark href=" <title>well-formed XML Documents (webreview.com)</title> <desc> Still trying to tame the XML beast? Begin with this tutorial that will show you in clear terms how to build a simple XML document that is well-formed and valid. </desc> </bookmark> </folder> <folder> <title>extensible Stylesheet Language (XSL)</title> <bookmark href=" <title> WebReview.com: August 3, 2001: Introduction to XSLT </title> <desc>an introduction to XSLT</desc> </bookmark> </folder> </folder> </xbel> Protokoller WAP ( Wireless Application Protocol ) Wap er en applikasjon kommunikasjon protokoll for håndholdte enheter. Den er designet for svært små nettlesere (mikro-browsere) og blir brukt for å få tilgang til informasjon og tjenester. Wap bruker WML, wireless markup language, som er arvet fra html, men basert på xml. WML blir brukt for å lage sider ( decks ) som kan vises i en wap-nettleser. (Som html blir brukt for å lage sider som vises i større nettlesere). Decks er konstruert av et sett med cards -elementer, som igjen består av tekst, bilder, linker, felter, oppgaver eller annet. Cards kan være linket til hverandre, men kun ett card (kort) kan vises på skjermen om gangen. Når WML-siden blir aksessert fra en mobiltelefon, blir alle kortene til siden lastet ned fra wap-serveren. Eksempel på et wml-dokument; hello.wml : <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" " 22

23 Card 1 Hello World! next Tabell 1: Hva som vises på mobiltelefonen. <wml> <card id="no1" title="card 1"> <p>hello World!</p> </card> <card id="no2" title="card 2"> <p>hello Universe!</p> </card> </wml> De fleste nyere trådløse enheter kommer med nettleser. Noen av disse bruker wap som oppkoblingspunkt (wap-konto), men kan likevel lese vanlige internettsider. Opera bruker internett-konto, ikke wap, og vil ikke virke med en oppkobling som har wap som oppkoblingspunkt. Wap begynner å bli gammel teknologi, og er dermed ikke interessant i denne sammenheng. HTTP (Hypertext Transfer Protocol) Http er en protokoll på applikasjonsnivå for distribuerte, hypermedia informasjons systemer. Protokollen er tilstandsløs og generisk. Basis-enheten for http-kommunikasjon er en http-message (http-beskjed), som igjen består av en http-request eller en http-response. En klient sender en http-request (forespørsel) til server, som svarer med å sende en http-response (svar) tilbake til klienten. Innholdet i http-beskjeden trenger ikke å være hypertext. Ved å utvide request-metoden, feil-koder og headere (hoder), kan en også bruke http-message til bl.a. å sende objekter (distribuerte objekter). Her finnes mer informasjon HTTP/1.1-spesifikasjon: Markedstrender ˆ Mobiltelefoner er blitt allemannseie, og smarttelefoner på full fart inn. 23

24 ˆ Flere og flere føler seg trygge på å bruke internett, både til handel, kommunikasjon og til surfing generelt. 4.4 Forventet antall brukere?? 4.5 Fremtidige trender ˆ Rivende utvikling innen Smart-telefoner og PDA er. Sannsynligvis vil de være allemannseie om få år. ˆ Tegn på at databasene til web-baserte programmer i større grad vil bli generert av brukerne. Enten via cookies eller ved at brukerne legger inn data direkte. (Paradigme-skifte.) 4.6 Standard Systemer Opera: Opera s nye versjon 7 for smart-telefon og PDA: bringer DOM (W3C s Document Object Model) og Dynamisk Innhold til mobiler: Sitat fra Artikkel 9. Mars 2004: Opera 7... Having DOM support in a mobile browser secures that these devices can now display the same dynamic Webpages that have been available on desktop PCs. With Opera s superior standards support there is no need to separate into a mobile and desktop Web, the one available Web with its abundance of content looks great on any kind of device using Opera 7. Opera : Har Liten-Skjerm Rendering. Sitat fra: w3-sidene : Web Standard Compliant When you make your Web site work in Opera, you can be certain that it is open and accessible. Simply write your pages in standardscompliant code, and your site will work in all major browsers and for all major platforms and operating systems. Opera supports open international Web standards, such as HTML, XML, XHTML, WML, CSS, and DOM, and is a member of the World Wide Web Consortium (W3C). 24

25 5 Risikofaktorer 5.1 Kort liste -som må sees nærmere på senere! ˆ Hvordan unngå å miste informasjon ved systemfeil? ˆ Hvordan unngå å miste informasjon ved virusangrep? ˆ Hvordan håndtere muligheten for database-krasj? ˆ Hvordan vil systemet takle veldig mange brukere samtidig? ˆ Useriøse brukere: Hvordan beskytte systemet mot dette? ˆ Avhengig av ny teknologi. ˆ Oppdateres verktøy hurtig nok i forhold til ny teknologi? ˆ Manglende, eller delvis manglende, kompabilitet mellom verktøy vi tenker å bruke. ˆ Kompetanse på deler av teknologi og vertøy må tilegnes underveis. ˆ Tids-aspekt: målet er å bli ferdig før julen

26 6 Antagelser 6.1 Antagelser om Verktøy ˆ Det er meningen å bruke Eclipse som utviklingsmiljø, denne platformen har eksisterende plug-in s for Tomcat, Ant, JUnit og SQL, pluss mange flere! Hvis Eclipse ikke er kompatibel med Wireless Toolkit, blir vi enten nødt til å bruke Netbeans som utviklingsmiljø eller lage en Wireless- Toolkit-plugin for Eclipse først. Ny info: Det er kommet en plugin for J2ME. Vi får se hvor god den er! Da vil vi sannsynligvis bruke Eclipse. ˆ Skal ellers bruke JUnit, Ant, Tomcat og J2ME Wireless Toolkit 2.1. ˆ Vi har tenkt å basere oss på nettleseren Opera for kompabilitet mellom PC er, mobiltelefoner og PDA er. Opera er åpen-kildekode programvare. 6.2 Andre antagelser ˆ Antar at Http-protokoll brukes som nettverkstransport. ˆ Antar at Klientdelen til systemet er delt i to: En Http-klient og en MIDPapplikasjon (MIDlet) for innstallering på mobiltelefon/pda. 26

27 7 Verktøy 7.1 Hovedverktøy ˆ Eclipse (utviklingsmiljø) For nedlasting og informasjon: ˆ Netbeans (utviklingsmiljø) For nedlasting og informasjon: ˆ J2ME Wireless Toolkit 2.1 (Java 2 platform, Micro Edition Wireless Toolkit) Gir programvareetterligning av CLDC/MIDP-innretninger/enheter, og kan dermed simulere at MIDP-applikasjonen (MIDlet en) kjører på en mobiltelefon eller en PDA. For nedlasting og informasjon: Eclipse-J2ME-plugins: ˆ Tomcat (Servlet Kontainer, implementerer Servlet 2.4 og JSP 2.0 spesifikasjoner) For nedlasting og informasjon: doc/index.html ˆ Ant (vertøy for automatisering) For nedlasting og informasjon: ˆ JUnit (vertøy for å skrive og utføre automatisk testing) For nedlasting og informasjon: Notater om JUnit av Khalid Azim Mughal: Eventuelle hjelpeverktøy ˆ Opera for smart-telefoner og PDA er: The Norwegian Opera : ˆ Poseidon (UML-vertøy): ˆ Visual Paradigm (UML-vertøy): 27