Lataa esitys
Esittely latautuu. Ole hyvä ja odota
JulkaistuHannu-Pekka Leppänen Muutettu yli 10 vuotta sitten
1
Kontekstinhallinnan määrittely versio 2 luonnos Mika Tuomainen mika.tuomainen@savonia-amk.fi
2
Sisältö Korjatut virheet Tarkennukset Lisäykset / lisäysehdotukset Jatkokehitys
3
Korjatut virheet VIRHE: GetItemValues-metodin poikkeuksista puuttuu UnknownParticipant Tätä ei mukana versiossa 1, eikä myöskään CCOW:ssa tässä metodissa, koska CCOW olettaa ettei ei-turvallisissa yhteyksissä tarvita tunnistusta. Jos halutaan tunnistus, CCOW:ssa käytetään secure-rajapintoja. TARVITAAN MINIMITASON MÄÄRITYKSESSÄ, JOTTA VOIDAAN TUNNISTAA KONTEKSTITIETOA HAKEVA SOVELLUS, VARSINKIN KÄYTTÄJÄTUNNUSTA HAETTAESSA. KORJAUS: Lisätty
4
Korjatut virheet VIRHE: participantCoupon puuttuu GetItemValues-metodin input-parametreista http-viesteissä KORJAUS: Lisätty
5
Tarkennukset Kuvaus v1: A akkoskoosta riippuvuus: Subjektin tietojen nimet ja arvot on käsiteltävä aakkoskoosta riippumattomina, ellei toisin ole erikseen mainittu. Ehdotus v2: huomioidaan vain subjektien nimet, ei arvoja
6
Tarkennukset Kuvaus v1: Käyttäjäsubjektia ei turvallisuussyistä saa asettaa minimitoteutuksen SetItemValues-metodilla. Ehdotus v2: Käyttäjäsubjektia ei turvallisuussyistä saa asettaa minimitoteutuksen SetItemValues-metodilla, ellei turvallisuutta ole jollain toteutuskohtaisella tekniikalla varmistettu.
7
Tarkennukset Kuvaus v1: Ehdotus v2: Tarkennettu eri ratkaisuehdotuksia käyttäjäkontekstin turvallisuuteen.
8
Tarkennukset Kuvaus v1: applicationName: sovelluksen nimi. Liittyessään kontekstinhallintaan sovellus tunnistautuu context manager-komponentille nimensä avulla. Sovelluksen nimellä voidaan myös kertoa etukäteen context managerille, mitkä sovellukset voivat osallistua yhteiseen kontekstiin. Ehdotus v2: ONKO SOVELLUKSIEN NIMEÄMINEN CONTEXT MANAGERILLE VAPAAEHTOISTA VAI PAKOLLISTA? MÄÄRITELLÄÄNKÖ TÄSSÄ VAI TOTEUTUSKOHTAISESTI?
9
Tarkennukset Kuvaus v1: JoinCommonContext-metodin allreadyJoined-poikkeus: Samalla nimellä (applicationName) varustettu sovellus on jo mukana kontekstinhallinta-palvelussa. Ehdotus v2: CM voisi sallia myös ”täsmälleen saman nimisten” sovellusten liittymisen, mikä helpottaisi sovellusten kannalta toteutusta (sovelluksen ei tarvitse tietää montako instanssia sovelluksesta jo on käynnissä). JÄTETÄÄNKÖ NÄIN VAI MUUTETAANKO,SITEN ETTÄ MYÖS SAMANNIMISET SALLITAAN?
10
Tarkennukset Kuvaus v1: participantCoupon-selitys TÄMÄ POIS: Helposti toteutettavissa esim. laskurilla, jota kasvatetaan aina kun uusi sovellus liittyy kontekstinhallintaan. Ehdotus v2: TARKEMMIN NÄIN: participantCoupon-tunniste on muodoltaan 32-bittinen kokonaisluku, joka on tietotyypiltään long. Tunnisteen pitää olla sovellusta kontekstisessiossa yksilöivä. Nolla (0) ei saa olla arvona.
11
Tarkennukset Kuvaus v1: TooManyParticipants: Kontekstinhallinta-palvelu ei voi ottaa lisää sovelluksia palveluun Ehdotus v2: TARKEMMIN NÄIN TooManyParticipants: Jos kontekstinhallinta-palveluun on määritelty maksimi määrä osallistuvien sovelluksien määrälle ja tämä määrä ylittyy.
12
Tarkennukset Kuvaus v1: TransactionInProgress-poikkeus Kontekstinhallinta-palvelussa on parhaillaan kesken kontekstin tietosisällön muuttaminen jonkun muun sovelluksen toimesta Ehdotus v2: Poistetaan, ei tarvita.
13
Tarkennukset Kuvaus v1: ContextNotActive-poikkeus Kontekstinhallintapalvelu ei ylläpidä aktiivista kontekstia. This should be transparent to applications that have a means for handling unexpected exceptions, if in fact this exception is ever encountered. Ehdotus v2: Poistetaan, ei tarvita.
14
Tarkennukset Kuvaus v1: SetItemValues-metodi Ehdotus v2: Sallitaanko tyhjien arvojen asettaminen Vai onko se toteutuskohtaista? Missä tarvitaan?
15
Tarkennukset Kuvaus v1: SetItemValues-metodin BadItemNameFormat-poikkeus Ehdotus v2: sovellus yrittää päivittää tietoa, jota kontekstinhallinta ei tue Edellytyksenä, että kontekstinhallintaan konfiguroitu sallitut itemNamet (= tukee vain määriteltyjä itemnameja) TARKENNETAANKO MÄÄRITYKSIIN PITÄÄKÖ SALLITUT ITEMIT OLLA MÄÄRITELTY ETUKÄTEEN VAI EI ? JÄTEÄÄNKÖ TOTEUTUSKOHTAISEKSI?
16
Tarkennukset Kuvaus v1: GetItemValues-metodin itemValues-parametri Ehdotus v2: Pitäisikö tarkentaa GetItemValuesia myös siten, että jos haetaan item, jota ei ole asetettu, siinä palautuu tyhjä (ei esim. virhettä)? Onko määrityksissä tarpeellista määrittää, että parametrien pitää tulla tietyssä järjestyksessä? Pitäisikö kirjoittaa, että kontekstipalvelutoteutus ei saa olettaa tiettyä järjestystä? Vai, että palautuu siinä järjestyksessä kuin on pyydetty?
17
Tarkennukset Kuvaus v1: GetItemValues-metodin UnknownItemName-poikkeus Ehdotus v2: sovellus yrittää hakea kontekstinhallinnasta tietoa, jota ei ole kontekstissa TÄMÄ PITÄISI TARKENTAA NÄIN: sovellus yrittää hakea kontekstinhallinnasta tietoa, jota ei ole asetettu kontekstiin
18
Tarkennukset Kuvaus v1: 7.5 Http-viestin muodostaminen Ehdotus v2: muotoon: 7.5 Http-kutsun muodostaminen. Paluuarvoille oma kappale. kts jatkokehitys kohta 2
19
Lisäykset / lisäysehdotukset Lisäys: pidempi johdanto kappaleeksi 1 kpl 4.1 Kontekstinhallintaan liittyminen kpl 4.4 Kontekstinhallinasta eroaminen
20
Lisäykset / lisäysehdotukset Lisäys: Kpl 6.1 Rajapintojen, metodien, parametrien ja subjektien nimeäminen poikkeukset (UnknownApplication) Selitys: Versiossa 1 Rajapintojen, metodien ja parametrien nimeäminen epätarkasti + poikkeukset ONKO KPL 6.1 OK?
21
Lisäykset / lisäysehdotukset Lisäys: JoinCommonContext-metodin UnknowApplication-poikkeus Selitys: Kontekstinhallintapalvelu ei tunnista sovellusta. Tilanteessa, jossa kontekstinhallintapalveluun on konfiguroitu sallitut sovellukset etukäteen. LISÄTÄÄNKÖ? VAI PALAUTETAANKO TURVALLISUUSSYISTÄ VAIN GENERALFAILURE?
22
Lisäykset / lisäysehdotukset Lisäys: SetItemValues-metodin ChangesNotAllowed-poikkeus Selitys: Sovellus ei saa asettaa tiettyä subjektia, esim. käyttäjä-subjektia minimimäärityksen mukaan. LISÄTÄÄNKÖ MÄÄRITYKSEEN TÄLLÄ NIMELLÄ VAI MÄÄRITELLÄÄNKÖ JOKU MUU?
23
Lisäykset / lisäysehdotukset Lisäys: kpl 6.4 Rajapintojen käyttöesimerkki kappaleisiin 7.6 ContextManager-rajapinta ja 7.7 ContextData-rajapinta esimerkit http-viesteistä ja paluuarvoista Liite 1. Turvallisuus Liite 2. Jatkokehitys Liite 3. Minimitoteutuksen edut ja erot CCOW-standardiin
24
Jatkokehitys ”Pollaus” Turvallisuus Työaseman identifiointi IP:n avulla ongelmana, jos työasemat ovat esim. NAT-osoitteiden takana http-viestien tarkennus
25
Jatkokehitys – ”pollaus” ”Pollaus” Mikäli kontekstinhallinta-palvelu ”kaatuu”, on sovelluksen osattava toimia ilman kontekstinhallintaa. Miten sovellus voi tarkistaa kontekstinhallinta-palvelun toiminnan, muuten kuin saamalla virheilmoituksen palvelimelta kutsuessaan kontekstinhallinta-palvelun metodeja? Mikäli kontekstinhallintaan liittynyt sovellus ”kaatuu”, muodostuu ongelmaksi kontekstinhallinta-palveluun roikkumaan jäävät turhat sovellukset. Kontekstinhallinta-palvelu mahdollisesti olettaa, että kontekstia pitää vielä pitää yllä, koska kaikki sovellukset eivät ole eronneet kontekstinhallinnasta. Miten kontekstinhallinta-palvelu voi tarkistaa sovellusten olemassa olon?
26
”Pollaus” – uusi metodi Miten sovellus voi tarkistaa kontekstinhallinta- palvelun toiminnan? Yksi ratkaisu esitettyyn ongelmaan olisi määritellä uusi metodi, jolla sovellus voisi varmistaa kontekstinhallinta-palvelun toiminnan. Kontekstinhallinta-palvelu vastaisi metodiin esimerkiksi true/false- mekanismilla. Tällä metodilla olisi mahdollista selvittää myös istunnon voimassaolo. Sovellus antaisi input-parametrina participantCoupon tunnisteensa, jonka avulla voitaisiin selvittää, onko participantCoupon-tunnistetta vastaava istunto vielä voimassa. Muita vaihtoehtoja?
27
”Pollaus” – aikakatkaisu Miten kontekstinhallinta-palvelu voi tarkistaa sovellusten olemassa olon? Minimitason kontekstinhallinnan tavoitteena on pitää liikenne yksisuuntaisena eli ainoastaan sovellus kutsuu kontekstinhallintapalvelun metodeja - kontekstinhallinta ei kutsu sovelluksia. Yksi vaihtoehto on määrittää kontekstinhallintaan aikaleima, johon määritellään kontekstin voimassaolo.
28
”Pollaus” – aikakatkaisu Vaihtoehtoja toteutukselle: Vakio Sovelluskohtainen Kontekstikohtainen Tietokohtainen Kysymyksiä: Aikaleiman asettamiseen oma mekanismi? Aikaleiman asettaminen uudella subjektilla? Asettaako asiakassovellus aikaleiman? Tapahtuuko context managerissa sisäisesti (konfiguroimalla)? Onko asiakassovellukselle vapaaehtoinen?
29
”Pollaus” – aikakatkaisu Aikaleima ei kuitenkaan ratkaise sitä ongelmaa, että sovellus kaatumisen jälkeen käynnistetään uudelleen ja se liittyy uudelleen kontekstiin. Tällöinhän kontekstinhallinnan pitäisi ilmoittaa, että kyseinen sovellus on jo kontekstissa. Muita vaihtoehtoja? Muita näkökulmia kaksisuuntaisuus?
30
Jatkokehitys - turvallisuus Tulevaisuudessa määrittelyn seuraaviin versioihin on mietittävä löytyykö yhtä yhteistä standardi-ratkaisua turvallisuuden huomioimiseen nyt luotettu sovellus SSL? CCOW-tapa? vai jääkö sen toteuttaminen toteutuskohtaiseksi
31
Jatkokehitys – työaseman tunnistaminen Työaseman identifiointi IP:n avulla ongelmana, jos työasemat ovat esim. NAT-osoitteiden takana Ratkaisuvaihtoehtoja JoinCommonContextWithIp-metodi Context Management Registry Muita vaihtoehtoja?
32
Jatkokehitys – työaseman tunnistaminen JoinCommonContextWithIp-metodi Työaseman identifioinnissa ovat ongelmana esimerkiksi NAT- osoitteet, jolloin eri työasemat saattavat näin näkyä kontekstinhallinnalle samana IP-osoitteena. Yksi ratkaisu käyttää JoinCommonContextWithIp-metodia. Kontekstinhallinta saisi metodin parametrina työaseman todellisen IP-osoitteen, jolla voisi yksilöidä työaseman. Kontekstinhallinta-palvelu saisi käyttää työaseman todellista IP- osoitetta vain työaseman yksilöintiin.
33
Jatkokehitys – työaseman tunnistaminen Context Management Registry (CMR) CCOW-standardin web/http-määritys määrittelee CMR-rajapinnan CMR toteuttaa vain yhden locate-metodin, joka palauttaa työaseman käyttämän CM komponentin URL-osoitteen sekä oman tunnisteensa (ip/id) työasemalla sijaitsevasta rekisteristä voidaan toteuttaa esim. applettina onko kuitenkin liian monimutkainen minimitoteutukseen? oma rajapinta rekisteri työasemalle
34
Jatkokehitys – http-viestien tarkennus Omat kappaleet seuraaville kohdille: Yleinen skeema http GET / POST viittaus komponenttiin MIME-header nimetyt argumentit rajapinnan nimi metodin nimi input-parametrit
35
Jatkokehitys – http-viestien tarkennus Omat kappaleet seuraaville kohdille: HTTP-merkkien koodaus output-parametrit poikkeukset merkistö MUITA TARKENNETTAVIA KOHTIA?
36
Jatkokehitys – http-viestien tarkennus Yleinen skeema The general schema for representing CMA methods as HTTP messages is to URL-encode the method name and associated parameters as a non-cached HTTP message. The authoritative source for URL-encoding is IETF RFC 1738, which can be found at http://www.ietf.org/rfc/rfc1738.txt.
37
Jatkokehitys – http-viestien tarkennus http GET / POST All CMA web-based components (e.g., context manager, context agent, etc.) shall be capable of receiving CMA methods encoded as HTTP POST or GET messages. The context manager, which is the only component that communicates directly with an application, shall only send HTTP GET messages to applications. CMA-compliant web applications shall only need to receive CMA methods encoded as HTTP GET messages, but may send HTTP POST or GET messages to CMA components.
38
Jatkokehitys – http-viestien tarkennus viittaus komponenttiin A component reference is represented as a URL. The path for a component (e.g., Context Manager) shall be encoded in the file name portion of the URL, for example: www.mcis.duke.edu/CCOW/ContextManager
39
Jatkokehitys – http-viestien tarkennus MIME-header The HTTP MIME header for both request and reply messages shall define the value for the standard Content-Type header using the standard name: Content-Type: application/x-www-form-urlencoded The header shall also indicate that the message should not be cached. In HTTP 1.0, the Expires header should be set to a time that is earlier than when the request was issued (an arbitrarily early time may be used): Expires: Mon, 01 Jan 1990 00:00:00 GMT In HTTP 1.1, the Cache-Control header shall be set to indicate that the maximum time that the message should be considered as fresh is zero seconds, and that this information must be respected (the net effect is that messages will not be cached): Cache-Control: max-age=0, must-revalidate
40
Jatkokehitys – http-viestien tarkennus nimetyt argumentit Named arguments shall be encoded as an argument name followed by the equal sign character (=) followed by a character-encoded representation of the argument’s value. If the argumement is not the first in the list, then it shall be preceded by the ampersand character (&), for example: &name=value The order in which named arguments are encoded shall not matter. Applications and components shall ignore any named argument whose name is not recognized. Argument names are not case sensitive. The case sensitivity of argument values is specified in the CMA.
41
Jatkokehitys – http-viestien tarkennus nimetyt argumentit - rajapinnan nimi The interface name shall be encoded as the first named argument, for example: ?interface=ContextData If the requested interface is not implemented by the component, then it shall return an HTTP reply header with the standard HTTP response code 404 (Not Found).
42
Jatkokehitys – http-viestien tarkennus nimetyt argumentit - metodin nimi The method name shall be encoded as the second named argument, for example: &method=SetItemValues If the requested interface is not implemented by the component, then it shall return an HTTP reply header with the standard HTTP response code 404 (Not Found).
43
Jatkokehitys – http-viestien tarkennus nimetyt argumentit - input-parametrit The method input parameters as defined in the CMA specification shall be encoded as the remaining arguments using the same names that appear in the CMA. If a parameter is not recognized by the component, then the component shall ignore the parameter. If a necessary parameter is missing, then the component shall return an HTTP reply header with the standard HTTP response code 404 (Not Found).
44
Jatkokehitys – http-viestien tarkennus nimetyt argumentit - input-parametrit Data Value Representation All data values shall be converted to string representations per the following CMA Specification Document Sections: 17.2.7, Character Encoded Binary Data; 17.2.8, Representing Message Authentication Codes, Signatures and Public Keys; Section 17.2.9, Representing Basic Data Types as Strings. Arrays Arrays are encoded as a vertical bar (|)-separated list of elements. For example: &itemNames=Patient.Id.MRN.medical_center|Patient.Co.Name &itemValues=123-81283-JMDH-79|Marchant^Kyle^^^^ &contextCoupon=27 &appSignature=0BC12D890913E9C98182808CD00BB983288A81238
45
Jatkokehitys – http-viestien tarkennus nimetyt argumentit - input-parametrit Null Value A method input parameter whose value is null shall not have any value encoded. For example: &contextParticipant= Empty String A method input parameter whose value is an empty string shall not have any value encoded. For example, a parameter whose value is an empty string and a parameter whose value is an array with two elements, the first of which is an empty string, is shown below: &appSignature= &itemValues=|Marchant^Kyle^^^^
46
Jatkokehitys – http-viestien tarkennus nimetyt argumentit - input-parametrit Empty Array A method input parameter whose value is an array with no elements shall not have any value encoded. For example: &itemNames=
47
Jatkokehitys – http-viestien tarkennus HTTP-merkkien koodaus All characters used in representing an argument value (i.e., to the right of the equal sign (=)) shall be encoded per HTTP conventions, defined in IETF RFC 2396, Section 2.4, which can be found at http://www.ietf.org/rfc/rfc2396.txt. A conservative summary of these conventions is as follows: The ASCII characters ‘a’ through ‘z’, ‘A’ through ‘Z’, and ‘0’ through ‘9’ remain the same. The space character ‘ ’ is converted into a plus sign ‘+’. All other characters are converted into the 3-character string “%xy”, where xy is the two-digit hexadecimal representation of the lower 8-bits of the character.
48
Jatkokehitys – http-viestien tarkennus output-parametrit Method output parameters are encoded in the body of an HTTP reply message. These parameters are encoded using the same scheme as for encoding input parameters. The HTTP reply header shall include the standard HTTP response code 200 (OK) unless otherwise noted in the interface definitions.
49
Jatkokehitys – http-viestien tarkennus poikkeukset CMA-specified exceptions are encoded in the same manner as outputs. However, in lieu of outputs, the exception shall be encoded in the body of the reply message as a pseudo output parameter whose name is exception and whose value is the name of the exception, as follows: exception=ExceptionName If the exception includes data members, then these members shall be encoded in the body of the reply message following the exception name. These members shall be encoded using a same scheme as for encoding input parameters. If members are encoded, then the first member shall be preceded by an ampersand (&), and subsequent members shall be delimited by an ampersand (&), for example: LIITE 2 JATKUU exception=BadItemValue&itemName=Patient.Co.Sex&itemVal ue=G&reason=Must be F, M, O or U The optional pseudo output parameter whose name is exceptionMessage and whose value is an explanation of the exception may also be encoded in the body of the response message: exceptionMessage=explanation This parameter is intended for diagnostic purposes. The content of the explanation is not specified and is implementation-dependent.
50
Jatkokehitys – http-viestien tarkennus merkistö CMA methods are mapped to HTTP messages, and may be partially or entirely encoded as part of a URL. URLs are currently required to be in US-ASCII, the character set referred to as ISO-8859-1, according to RFC2396. Therefore, only the ASCII character set shall be used to represent any data that is transmitted as part of a CMA- defined method. However, it may be necessary to represent the data values for certain CMA method parameters using a local character set (i.e., not US- ASCII). When this is the case, the parameter value may be represented using Unicode (see http://www.unicode.org). In doing so, each Unicode codepoint within the Unicode string shall be encoded as a two-character US-ASCII string representing the hex value of the Unicode codepoint. Each such two-character string shall be preceded by the percent (%) character to signal the message recipient that the following two characters are to be interpreted as hex value for a Unicode codepoint. The high byte of the Unicode codepoint shall be encoded lexically before the low byte.
Samankaltaiset esitykset
© 2024 SlidePlayer.fi Inc.
All rights reserved.