KYYHKY-PROJEKTI

Timo Aarniovuori
Teija Alasalmi
Jaakko Hyvärinen
Maunu Tuomainen

Vaatimusmäärittely
31.3.2004, versio 1.0

Jyväskylän Yliopisto
Tietotekniikan Laitos

Kyyhky-projektin tietoja
Tekijät
Timo Aarniovuori (taarnio@cc.jyu.fi)
Teija Alasalmi (teikku@cc.jyu.fi)
Jaakko Hyvärinen (japahyva@cc.jyu.fi)
Maunu Tuomainen (mttuomai@cc.jyu.fi)

Yhteystiedot
Agora, huone C222.2, puhelinnumero 014-2604963. Projektiorganisaation sähköpostilista on kyyhky@korppi.jyu.fi. Sen keskustelua voi seurata osoitteessa https://korppi.it.jyu.fi/list-archive/kyyhky/. Projektin kotisivu löytyy osoitteesta http://kotka.it.jyu.fi/kyyhky/.

Työn nimi Kyyhky-projekti, vaatimusmäärittely.

Työ Vaatimusmäärittely tietotekniikan Sovellusprojektiin.

Tiivistelmä
Kyyhky-projekti toteuttaa päivyrirajapinnan Jyväskylän yliopiston tietotekniikan laitoksella toteutettuun Korppi-nimiseen opintotietojärjestelmään. Rajapinnan avulla pystytään synkronoimaan tapahtumia Korppi-järjestelmän kalenteriosion ja erilaisten mikrojen, matkapuhelimien ja muiden kämmenlaitteiden kalenterien kesken. Vaatimusmäärittely kuvaa järjestelmälle asetetut vaatimukset.

Avainsanat synkronointi, kalenteri, SyncML, Korppi-järjestelmä.

VERSIOHISTORIA
Versio	Päiväys	Tehnyt	Muutokset	
0.1	25.2.2004	Jaakko Hyvärinen
Maunu Tuomainen	Ensimmäinen versio.	
0.2	2.3.2004	Jaakko Hyvärinen	Lukemattomia pieniä ja suuria Jukka-Pekka Santasen havaitsemia virheitä korjattu.
Ulkoasun muuttaminen ”työpaperista” sovellusprojekteilta vaadittavan tyylin mukaiseksi.
Termistön lisääminen.	
0.3	3.3.2004	Jaakko Hyvärinen	Pieniä muutoksia mm. vaatimuksiin ja rajoitteisiin.	
0.4	8.3.2004	Maunu Tuomainen
Jaakko Hyvärinen	Santasen osoittamien virheiden korjauksia.	
0.5	15.3.2004	Jaakko Hyvärinen
Maunu Tuomainen	Synkronointitaulukon laajennus.	
0.6	19.3.2004	Maunu Tuomainen
	Pieniä korjauksia mm. lähdeluetteloon ja –viittauksiin. 	
0.7	20.3.2004	Jaakko Hyvärinen	Taulukoiden asemointi.	
0.8	25.3.2004	Jaakko Hyvärinen
Maunu Tuomainen	Viimeistely	
1.0	31.3.2004	Jaakko Hyvärinen
Maunu Tuomainen	Lisää viimeistelyä	
1.1	23.3.2004	Jaakko Hyvärinen	Konfliktitaulukon  muuttaminen vastaamaan SyncStrategian implementaatiota	

 SISÄLLYSLUETTELO
1	JohDanto
2	Termistöä
3	Vaatimusmäärittely
3.1	Merkintöjä
3.2	Toiminnalliset vaatimukset
3.2.1	Synkronointivaatimukset
3.2.2	Korppi-järjestelmään toiminnallisuuteen suunnatut vaatimukset
3.3	Ei-toiminnalliset vaatimukset
3.4	Rajoitteet
4	Yleiset Syncml-vaatimukset
4.1	Muutosloki
4.2	Synkronointiankkurien käyttö
4.3	Tietoalkioiden avainten vastaavuuskartoitus
4.4	Konfliktien hallinta
4.5	Tietoturva
4.6	Osoitteistus
4.7	Laitetietojen vaihtaminen
4.8	Viestipakettien pilkkominen ja yhdistely
4.9	Suurten tietueiden käsittely
4.10	Synkronointi ilman erillistä alustusta
4.11	Busy-viesti
5	Konfliktit
6	erilaiset synkronointimuodot
lähteet

1	JohDanto
Kyyhky-projekti toteuttaa päivyrirajapinnan Jyväskylän yliopiston tietotekniikan laitoksella toteutettuun Korppi-nimiseen opintotietojärjestelmään. Rajapinnan avulla pystytään synkronoimaan tapahtumia Korppi-järjestelmän kalenteriosion sekä erilaisten mikrojen, matkapuhelimien ja muiden kämmenlaitteiden kalenterien kesken. 

Dokumentissa kuvataan rajapinnan toteuttamisen kannalta olennaisia vaatimuksia. Vaatimusmäärittelyssä vaatimukset voidaan luokitella kolmeen ryhmään: toiminnalliset ja ei-toiminnalliset vaatimukset sekä rajoitteet [Koikkalainen]. 

Luvussa 2 esitetään dokumentin kannalta keskeiset termit. Luvussa 3.1 käsiteltävät toiminnalliset vaatimukset määräävät tietyn toiminnan, kuten ohjelman suorittaman laskutoimituksen, käyttöliittymän toiminnan, ohjelman käyttämät tiedot ja I/O-rajapinnat. Luvussa 3.2  käsiteltävät ei-toiminnalliset vaatimukset liittyvät ohjelman käytettävyyteen. Niitä ovat mm. ohjelman suorituskyky, luotettavuus, turvallisuus ja siirrettävyys. Luvussa 3.3 käsiteltäviä rajoitteita ovat reaalimaailman asettamat ehdot ohjelmalle. Rajoitteiksi saattavat muodostua esimerkiksi tuotteen hinta, lainsäädäntö, standardit, aikataulu ja työkalut.

Luvussa 4  käsitellään SyncML-protokollan asettamia vaatimuksia. Luvussa 5 käsitellään SyncML-protokollan mukaisia konfliktitilanteita. Lisäksi käsitellään tilannetta, jossa ryhmäkohtaisiin tapahtumiin tehdään muutoksia henkilökohtaisessa kalenterissa. Luku 6  selvittää erilaisia synkronointitapoja ja niiden eroja.
2	
Termistöä
Tässä luvussa kuvataan tämän dokumentin kannalta olennaiset termit.

Avainkartoitus 	(engl. ID mapping) on SyncML-palvelimella oleva tietokantarakenne kertoen, mitkä asiakas-LUID:it ja palvelin-GUID:it vastaavat toisiaan. 

GUID 	(Global Unique Identifier) on tietueen yksilöivä numero SyncML-palvelimella. 

HTTP 	(HyperText Transfer Protocol) on WWW-tekniikassa käytettävä tiedonsiirtoprotokolla, jolla selain pyytää haluttuja sivuja WWW-palvelimelta. 

IMEI 	(International Mobile Equipment Identifier) on mobiililaitteen yksilöivä 15-osainen numero. 

J2EE 	(Java 2 Enterprise Edition) on standardi, joka mahdollistaa palvelinsovellusten tuottamisen niin, että sovelluksia voi ajaa millä tahansa J2EE-palvelimella. 
 
JSP	(Java Server Pages) on skriptaustyylinen ohjelmointikieli, jossa HTML-koodin sekaan on mahdollista lisätä Java-kielellä kirjoitettua koodia.

LUID 	(Locally Unique Identifier) on numero, joka yksilöi tietueet asiakaslaitteessa.

MD5	(Message digest 5) on trapdoor-funktio (alkuperäisen syötteen palauttaminen vasteesta on mahdotonta), jota käytettäessä salasanaa ei tarvitse tallentaa selkokielisenä.

Synkronointi 	tarkoittaa saman tiedon pitämistä ajantasaisena kahden tai useamman tietokannan välillä.

Sync-analyysi	on synkronointipalvelimen synkronoitaville tietueille suorittama analyysi, jossa päätetään tiedonsiirron tarpeesta.

SyncML 	(Synchronization Markup Language) on synkronointiprotokolla tiedon synkronointiin. 

Synkronointiankkuri 	on aikaleima tai merkkijono, joka kuvaa synkronointitapahtumaa. Synkronointiosapuolet tallentavat toistensa synkronointiankkurit. Näin ne voivat todeta toisissaan mahdollisesti tapahtuneet häiriötilat. SyncML määrittelee kaksi synkronointiankkuria: Next ja Last. (Katso luku 4.2)

SSL 	(Secure Sockets Layer) on protokolla, jonka yli voidaan muodostaa salattuja yhteyksiä muilla protokollilla, kuten esimerkiksi HTTP:llä.
 
URI 	(Uniform Resource Identifier) on universaali tapa yksilöidä resursseja.

vCalendar 	on formaatti kalenteritiedon tallentamiseen ja välittämiseen. 

3	
Vaatimusmäärittely
Luvussa kuvataan Korppi-järjestelmän kalenteriin toteutettavan synkronointirajapinnan vaatimukset ja rajoitteet. Kun seuraavassa käytetään termiä henkilökohtainen kalenteri, tarkoitetaan sillä käyttäjien omia Korpista erillisiä kalentereita.
3.1	Merkintöjä
Vaatimukset priorisoidaan seuraavasti [Haikala ym.]:
1.	välttämätön,
2.	toivottu (tärkeä, mutta ilmankin tullaan toimeen) ja
3.	valinnainen (voidaan jättää johonkin myöhempään versioon).

Taulukoiden 1-4 sarakeotsikoissa N kuvaa vaatimuksen järjestysnumeroa ja P vaatimuksen prioriteettia. Ryhmää koskevaksi tapahtumaksi ymmärretään taulukossa 1 kaikki Korpin opetustapahtumat sekä tapahtumat, joihin liittyy useampi kuin yksi henkilö.
3.2	Toiminnalliset vaatimukset
Toiminnalliset vaatimukset jaetaan selvyyden vuoksi sekä itse synkronointia koskeviksi (katso taulukko 1), että välittömästi Korppi-järjestelmän toiminallisuutta koskeviksi (katso taulukko 2). 
3.2.1	Synkronointivaatimukset 
Taulukossa 1 esitellään vaatimukset synkronoinnille. 

N	P	Vaatimus	
1	1	Käyttäjä pystyy synkronoimaan henkilökohtaiset kalenterinsa (yhden tai useamman) Korpin kalenteriin.	
2	1	Sovellus käyttää suoraan Kotka-tietokantaa.	
3	1	Synkronoinnin tulee toimia siten, että salivaraukset tehdään ainoastaan Korpista.	
4	1	Korpista ei voi poistaa tai muokata synkronoinnin seurauksena sellaisia tapahtumia, joihin käyttäjällä ei ole poisto- tai muutosoikeutta. (Piilottaminen on mahdollista, katso vaatimus 5.)	
5	1	Käyttäjän täytyy pystyä poistamaan ryhmää koskeva tapahtuma omalta osaltaan (piilottaa) kalenteristaan. Synkronoitaessa tapahtuman piilottaminen Korpissa samaistetaan poistoon henkilökohtaisessa kalenterissa.	
6	1	Korpin ryhmien tapahtumat synkronoidaan käyttäjien henkilökohtaisiin kalentereihin yksityisiksi tapahtumiksi.	
7	1	Synkronoinnin on kuitenkin pystyttävä selkeästi erottamaan ryhmiä koskevat tapahtumat yksityisistä tapahtumista.	
8	2	Ryhmän tapahtumat erotetaan yksityisten henkilöiden tapahtumista jollain sopivalla koodilla, kuten R.	
9	1	Synkronoinnin on selvittävä erilaisista konfliktitilanteista (esitelty luvussa 5).	
10	2	Synkronoinnin on toimittava, vaikka käyttäjän synkronoitavia tietoja muutetaan Kotka-tietokannassa synkronoinnin aikana (esim. poistetaan kurssi).	
11	1	Sovelluksen tulee tukea useanlaisia synkronointeja (esitelty luvussa 6).	
12	2	Asiakkaan virkistyssynkronisointia ei tueta.	
13	1	Henkilökohtaiseen kalenteriin merkityt toistuvat tapahtumat analysoidaan Sync4j-palvelimella ja muutetaan siellä Korpin ymmärtämään muotoon.	
Taulukko 1. Synkronointia koskevia toiminnallisia vaatimuksia.
3.2.2	
Korppi-järjestelmään toiminnallisuuteen suunnatut vaatimukset 
Taulukossa 2 esitetään Korppi-järjestelmää koskevia vaatimuksia.

N	P	Vaatimus	
14	1	Korppi-järjestelmään on toteutettava konfliktien hallintaosio. Sen avulla käyttäjä voi vahvistaa, miten hän haluaa toimia, kun synkronoinnin yhteydessä syntyy konflikti.	
15	1	Korppi-järjestelmässä tulee olla ominaisuus, jolla voidaan hallita käyttäjän henkilökohtaisessa kalenterissa muuttamia ryhmätapahtumia.	
16	3	Korppi-järjestelmään on toteutettava toiminto, jolla voidaan tehdä ryhmätapahtumista yksityisiä tapahtumia tai päinvastoin.	
17	1	Synkronoitaessa toistuvien tapahtumien tulee säilyä synkronoinnin kannalta ehjinä. Toisin sanoen siirrettäessä toistuva tapahtuma takaisin henkilökohtaiseen kalenteriin, ei se saa hajota yksittäisiksi tapahtumiksi.	
18	1	Henkilökohtaisesta kalenterista synkronoidut henkilökohtaiset tapahtumat merkitään oletusarvoisesti yksityisiksi Korpin kalenterissa.	
Taulukko 2. Korppi-järjestelmää koskevat vaatimukset.
3.3	
Ei-toiminnalliset vaatimukset
Taulukossa 3 esitetään järjestelmää koskevat ei-toiminnalliset vaatimukset.

N	P	Vaatimus	
19	1	Sovelluksen tulee olla toteutettu Javalla, joten järjestelmä teoriassa toimii kaikilla alustoilla, johon löytyy toteutus jostain J2EE-tekniikkaa tukevasta sovelluspalvelimesta.	
20	2	Sovelluksen tulee olla skaalautuva (tulevaisuudessa järjestelmän tulee pystyä palvelemaan mahdollisesti tuhansia käyttäjiä).	
21	1	Sovelluksen tulee noudattaa laitoksen yleistä tietoturvapolitiikkaa teknisten ratkaisujen osalta.	
22	2	Sovelluksen tulee tarjota vähintään HTTP-protokollaa tukeva liittymä.	
23	2	Sovelluksen avulla synkronoitava tieto tulee synkronoida luottamuksellisesti (SSL-salaus).	
24	1	Sovellusta tulee olla helppo käyttää.	
Taulukko 3. Ei-toiminnalliset vaatimukset.
3.4	Rajoitteet
Taulukossa 4 esitetään järjestelmää rajoittavat tekijät.

N	Rajoite	
25	Sovellus toteutetaan vapain tekniikoin.	
26	Sovellus toteutetaan kevään 2004 aikana.	
27	Sovellus toteutetaan yliopiston tarjoamilla ohjelmistokehitystyökaluilla.	
28	Korppiin toteutettavat käyttöliittymälaajennukset toteutetaan JSP:llä.	
29	Sovelluksen tulee toimia SyncML-määritysten mukaisesti.	
30	Sovelluksen tulee tukea SyncML-protokollan versioita 1.0 ja 1.1. 	
31	Sovellus tulee toteuttaa GPL-ehtojen mukaisesti.	
32	Sovellukseen tarvittava ulkopuolinen ohjelmakoodi tulee olla vapaasti käytettävissä.	
33	Synkronoitavan tapahtuman tulee olla muutettavissa vCalendar-muotoon. Tämä sanelee tapahtumalle tietyt rajoitukset [Internet Mail Consortium].  	
34	Järjestelmään voi liittyä ainoastaan SyncML-yhteensopivalla asiakasohjelmistolla.	
35	Henkilökohtaisessa kalenterissa ei voi luoda ryhmä- eikä opetustapahtumia.	
Taulukko 4. Rajoitteet.

4	
Yleiset Syncml-vaatimukset
Luvussa 3 esitettyjen vaatimusten lisäksi järjestelmän tulee toteuttaa yleiset SyncML-palvelimille asetetut vaatimukset, joita on kuvattu mm. SyncML-protokollan spesifikaatiossa [Open Mobile Alliance]. Yleisiä vaatimuksia on käsitelty pro gradu -tutkielmassa [Paadar]. 
4.1	Muutosloki
Protokolla vaatii sekä asiakkaan että palvelimen pitävän kirjaa tapahtuneista muutoksista synkronointien välillä. Protokolla ei määritä, missä muodossa muutoslokia (engl. Change Log Information) pidetään, mutta synkronoinnin alkaessa laitteen tulee pystyä kertomaan, mitkä tietueet ovat muuttuneet suhteessa jokaiseen aiempaan synkronointikumppaniin.
4.2	Synkronointiankkurien käyttö
Protokolla käyttää synkronointiajankohtia ilmaisevia synkronointiankkureita (engl. Sync Anchors). Ankkurit Last ja Next lähetetään aina synkronoinnin aluksi. Last edustaa viimeisintä synkronointitapahtumaa tietokannan ja lähettävän laitteen välillä. Next kuvaa sen hetkistä synkronointitapahtumaa.

Molemmat osapuolet lähettävät ankkurit toisilleen ja ainakin palvelimen tulee tallentaa   asiakkaan Next-ankkuri. Protokolla ei määritä ankkurien käyttöä. Mikäli laite tallentaa Next-ankkurin, se pystyy seuraavan kerran synkronoidessaan vertaamaan, onko se sama kuin vastapuolen lähettämä Last-ankkuri. Kyseisellä vertailulla pystytään päättelemään, onko synkronoinnin tila eheä, vai vaaditaanko suoritettavaksi erikoistoimenpiteitä, kuten hidas synkronointi.
4.3	Tietoalkioiden avainten vastaavuuskartoitus
Asiakkaan ja palvelimen (Korppi) käyttämien tietueiden tunnisteiden ei tarvitse olla samoja, joten palvelimen täytyy pitää kirjaa tunnisteiden vastaavuuksista (engl. ID Mapping of Data Items). Palvelimella tulee olla taulu, joka kertoo, mikä asiakkaan avain (LUID) vastaa mitäkin palvelimen avainta (GUID).
4.4	Konfliktien hallinta
Kun samaa tietuetta on muutettu sekä asiakkaan että palvelimen tietokannassa, syntyy synkronoitaessa konflikti. Konfliktit voidaan ratkaista joko palvelimen tai asiakkaan toimesta. Protokolla ei ota kantaa siihen, kuinka konflikti ratkaistaan.
4.5	Tietoturva
Protokolla vaatii tuen todennukselle (engl. authentication). Sekä asiakas että palvelin voivat vaatia todennusta eli tehdä haasteen, jolloin vastapuolen on pystyttävä vastaamaan. Todennus voidaan tehdä tavallisena tai MD5-algoritmiin perustuvana.
4.6	Osoitteistus
Laitteet, tietokannat (henkilökohtaisen kalenterin ja Korpin) ja tietueet osoitteistetaan (engl. Addressing) käyttäen SyncML-esitystapaprotokollan URI-skeemaa. Osoitteistamiseen liittyy lähdeosoite (Source) ja kohdeosoite (Target), joiden merkitys riippuu asiayhteydestä. Osoite voidaan ilmaista suhteellisessa tai absoluuttisessa muodossa.
4.7	Laitetietojen vaihtaminen
Protokolla tarjoaa tavan vaihtaa laitetietoja (kuten muistin määrä ja avainavaruuden koko) asiakkaan ja palvelimen välillä. Kun asiakas synkronoidaan ensimmäisen kerran palvelimen kanssa, on sen kerrottava laitetietonsa. Lisäksi kumpi tahansa voi pyytää laitetiedostojen vaihtoa, jolloin vastapuolen tulee pystyä lähettämään tietonsa. Palvelimen tulee pystyä myös käsittelemään asiakkaan lähettämät tiedot.
4.8	Viestipakettien pilkkominen ja yhdistely
Normaalisti paketti lähetetään yhden viestin sisällä, mutta mikäli jostain syystä näin ei tehdä, lähetetään paketti useammassa viestissä. Jos paketti lähetetään useammalla viestillä, täytyy viimeisen viestin sisältää Final-elementti. Aina viestin käsiteltyään täytyy vastaanottajan pyytää lisää viestejä Alert-komennolla.
4.9	Suurten tietueiden käsittely
Mikäli synkronoitavan tietueen koko ylittää yksittäisen SycnML-viestin maksimikoon, tarjoaa protokolla mahdollisuuden jakaa tietue osiin. Viesti päätetään MoreData-elementtiin, jolloin vastaanottaja odottaa saavansa seuraavassa viestissä loput tietueesta.
4.10	Synkronointi ilman erillistä alustusta
Synkronointia edeltää aina alustus. Alustus voidaan kuitenkin tehdä samanaikaisesti synkronoinnin kanssa, ilman erillisiä alustusviestejä, jolloin viestien lähetysmäärä pienenee. Palvelimen tulee pystyä käsittelemään molemmat tapaukset eli sekä erillisen alustuksen, että synkronoinnin ilman erillistä alustusta.
4.11	Busy-viesti
Mikäli palvelin ei kykene käsittelemään asiakkaan lähettämää dataa riittävän nopeasti, tulisi palvelimen pystyä lähettämään tästä tieto asiakkaalle (Busy-viesti). Asiakas voi sitten sopivaksi katsomansa ajan päästä pyytää synkronoinnin tuloksia tai aloittaa synkronoinnin alusta.
5	
Konfliktit
Konflikti on tapahtuma, jossa samaa tapahtumaa on muokattu kahdessa paikassa. Synkronoinnissa tulee helposti vastaan konfliktitilanteita.

Konflikteja on yleensä kahta eri tyyppiä: muutos-muutos ja poisto-muutos. Muutos-muutos tarkoittaa sitä, että samaa tietuetta on muutettu kummassakin synkronointiosapuolessa. Poisto-muutos tarkoittaa sitä, että tieto on poistettu toisessa synkronointiosapuolessa, kun taas toisessa sitä on muutettu. Käytännössä esimerkiksi henkilö A saattaa aikaistaa jotain kalenteritapahtumaa mobiililaitteellaan, kun samaan aikaan toisaalla hänen sihteerinsä siirtää tapahtumaa myöhemmäksi [Paadar].

Taulukossa 5 esitellään synkronoinnissa esiintyvät erilaiset tilanteet ja niiden ratkaisumenetelmät. Kalenteriryhmä- ja opetusryhmätapahtumat käyttäytyvät synkronoinnin suhteen yhtenevästi, joten ne ovat samaistettu taulukkoon otsikolla ”ryhmä”.

Korppi (Tietokanta B)	Henkilökohtainen kalenteri (Tietokanta A)	
	Uusi	Poistettu	Muokattu	Synkronoitu/
muuttumaton	Ei olemassa	
Henkilökohtainen	Uusi	C	C	C	C	B	
	Poistettu	C	X	C	P: D
K: X
S: D	X	
	Muokattu	C	C	C	B	B	
	Synkronoitu/
muuttumaton	C	P: X
K: D
S: D	A	X	B	
	Ei olemassa	A	X	A	A	X	
	Piilotettu	C	X	C	P: D
K: X
S: D	X	
	Ratkaisematon konflikti	C	C+	C+	X	X	
Ryhmä
(Muokkausoikeus)	Uusi	-	-	-	-	B	
	Poistettu	-	X	C & Q	P: D
K: X
S: D	X	
	Muokattu	-	C & Q	C & Q	B	B	
	Synkronoitu/
muuttumaton	-	Q	Q	X	B	
	Ei olemassa	-	-	-	-	X	
	Piilotettu	-	Q	C & Q	P: D
K: X
S: D	X	
	Ratkaisematon konflikti	-	C+ & Q	C+ & Q	X	 X	
Ryhmä
(Osallistumisoikeus)	Uusi	-	-	-	-	B	
	Poistettu	-	X	P: D
K: X
S: D	P: D
K: X
S: D	X	
	Muokattu	-	C	C & N	B	B	
	Synkronoitu/
muuttumaton	-	P: D
K: H
S: D	N
	X	B	
	Ei olemassa	-	-	-	-	X	
	Piilotettu
	-	X	C & N	P: D
K: X
S: D	X	
	Ratkaisematon konflikti	-	C+	C+ & N	X	X	
Taulukko 5. Toiminta synkronoitaessa.

Taulukossa 5 on käytetty seuraavia lyhenteitä:

C	on normaali protokollan mukainen konfliktitilanne, joka ratkaistaan Korpissa.

C+	on normaali konflikti siten, että lisätään uusi vaihtoehto konfliktin ratkaisemiseksi.

Q	tarkoittaa, että kysytään Korpissa, haluaako käyttäjä välittää henkilökohtaisen kalenterin tapahtuman muutokset koko ryhmälle.

N	tarkoittaa, että luodaan uusi henkilökohtainen ilmentymä ryhmätapahtumasta ja tehdään muutokset sille. Piilotetaan ryhmätapahtuma.

C & Q	tarkoittaa, että protokollan mukainen konflikti ratkaistaan Korpissa. Mikäli valitaan henkilökohtaisen kalenterin tapahtuma, kysytään, välitetäänkö muutokset koko ryhmälle.

D	tarkoittaa, että poistetaan tietue.

H	tarkoittaa, että piilotetaan tietue (vain Korpissa).

X	tarkoittaa, että ei tehdä mitään.

A	tarkoittaa, että asetetaan henkilökohtaisen kalenterin tila vallitsevaksi, ts. kopioidaan ko. tietue henkilökohtaisesta kalenterista Kotka-tietokantaan.

B	tarkoittaa, että asetetaan Kotka-tietokannan tila vallitsevaksi, ts. kopioidaan ko. tietue Kotka-tietokannasta henkilökohtaiseen kalenteriin.

P:	tarkoittaa, että muutokset kohdistuvat henkilökohtaisen kalenterin tietokantaan.

K:	tarkoittaa, että muutokset kohdistuvat Korpin tietokantaan.

S:	tarkoittaa, että muutokset kohdistuvat Korpin tietokannan synkronointitauluun.
6	
erilaiset synkronointimuodot
Valittu synkronointitapa kerrotaan toiselle osapuolelle ensimmäisen paketin mukana. Tiedon saatuaan toinen osapuoli pystyy suorittamaan oikeanlaisen synkronoinnin ja välittämään oikean määrän oikeata tietoa.

Normaali SyncML-protokollan mukainen synkronointi seuraisi seuraavaa käytäntöä: ensimmäisellä kerralla suoritetaan hidas tai asiakkaan virkistyssynkronointi (kaikki tiedot asiakkaalta siirretään palvelimelle) ja tämän jälkeen käytetään kaksisuuntaista synkronointia (vain muuttuneet tiedot siirretään laitteesta toiseen). Ongelmatapauksissa voidaan suorittaa uudestaan hidas synkronointi tai virkistyssynkronointi. Tarkempi synkronointitapojen kuvaus on esitetty taulukossa 6.

Synkronointitapa	Määritelmä	
Kaksisuuntainen synkronointi (engl. two-way sync)	Yleisin synkronointimenetelmä, jossa asiakas ja palvelin lähettävät toisilleen muuttuneet tietoalkionsa. Asiakas lähettää muutoksensa ensin. 	
Hidas synkronointi (engl. slow sync)	Kaksisuuntaisen synkronoinnin erityismuoto, jossa asiakkaan kaikki tietoalkiot lähetetään palvelimelle. Palvelin vertaa jokaista tietoalkioita omiinsa ja suorittaa näille Sync-analyysin.	
Asiakkaan yksisuuntainen synkronointi (engl. one-way sync from client only)	Asiakas lähettää muuttuneen tietoalkionsa palvelimelle. Palvelin ei lähetä omia muutoksiaan.	
Asiakkaan virkistyssynkronointi (engl. refresh sync from client only)	Asiakas lähettää kaikki tietoalkionsa palvelimelle. Palvelin korvaa omat tietonsa asiakkaan tiedoilla (Sync-analyysiä ei suoriteta).	
Palvelimen yksisuuntainen synkronointi (engl. one way sync from server only)	Palvelin lähettää muuttuneet tietoalkionsa asiakkaalle. Asiakas ei lähetä omia muutoksiaan	
Palvelimen virkistyssynkronointi (engl. refresh sync from server only)	Palvelin lähettää kaikki tietoalkionsa asiakkaalle. Asiakas korvaa omat tietonsa palvelimen tiedoilla.	
Taulukko 6. Erilaiset synkronointitavat.

lähteet
Haikala Ilkka ja Märijärvi Jukka, ”Ohjelmistotuotanto”, Satku, 2000.

Koikkalainen Pasi, ”Ohjelmistotuotanto 2000 -kurssimateriaali”, saatavilla WWW-muodossa <URL: http://erin.it.jyu.fi/pako/kurssit/ot2000/  >, viitattu 19.3.2004.

Vahvanen Arto, ”Henkilökohtainen mobiilikalenteri”, pro gradu -tutkielma, Tampereen yliopisto, tietojenkäsittelytieteiden laitos, 2002.

Paadar Pekka, ”SyncML:n käyttö henkilökohtaisen tiedon synkronointiin”, pro gradu -tutkielma, Jyväskylän yliopisto, tietotekniikan laitos, 2003.

Open Mobile Alliance, “SyncML Sync Protocol Specification, version 1.1”, saatavilla PDF-muodossa <URL: http://www.openmobilealliance.org/syncml/docs/syncml_sync_protocol_v11_20020215.pdf >, viitattu 19.3.2004.

Internet Mail Consortium, ”vCalendar V1.0 Specification”, saatavilla PS-muodossa <URL: http://www.imc.org/pdi/vcal-10.ps >, viitattu 26.3.2004.