Kontekstinhallinnan määrittely versio 2 luonnos

Kontekstinhallinnan määrittely

versio 2 luonnos

Mika [email protected]

Sisältö

Korjatut virheet Tarkennukset Lisäykset / lisäysehdotukset Jatkokehitys

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

Korjatut virheet

VIRHE:

participantCoupon puuttuu GetItemValues-metodin input-parametreista http-viesteissä

KORJAUS: Lisätty

Tarkennukset

Kuvaus v1:

Aakkoskoosta 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

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.

Tarkennukset

Kuvaus v1:

Ehdotus v2:

Tarkennettu eri ratkaisuehdotuksia käyttäjäkontekstin turvallisuuteen.

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?

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?

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.

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.

Tarkennukset

Kuvaus v1:

TransactionInProgress-poikkeus

Kontekstinhallinta-palvelussa on parhaillaan kesken kontekstin tietosisällön muuttaminen jonkun muun sovelluksen toimesta

Ehdotus v2:

Poistetaan, ei tarvita.

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.

Tarkennukset

Kuvaus v1:

SetItemValues-metodi

Ehdotus v2:

Sallitaanko tyhjien arvojen asettaminen Vai onko se toteutuskohtaista? Missä tarvitaan?

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?

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?

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

Tarkennukset

Kuvaus v1:

7.5 Http-viestin muodostaminen

Ehdotus v2:

muotoon:

7.5 Http-kutsun muodostaminen.

Paluuarvoille oma kappale. kts jatkokehitys kohta 2

Lisäykset / lisäysehdotukset

Lisäys:

pidempi johdanto kappaleeksi 1

kpl 4.1 Kontekstinhallintaan liittyminen

kpl 4.4 Kontekstinhallinasta eroaminen


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?


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?


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?


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

Jatkokehitys

”Pollaus”

Turvallisuus

Työaseman identifiointi IP:n avulla ongelmana, jos työasemat ovat esim. NAT-osoitteiden takana

http-viestien tarkennus

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?

”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?

”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.


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?


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?

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

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?


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.


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

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


Omat kappaleet seuraaville kohdille:

HTTP-merkkien koodaus

output-parametrit

poikkeukset

merkistö

MUITA TARKENNETTAVIA KOHTIA?


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.


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.


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


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


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.


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).


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).


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).



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



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^^^^



Empty Array

A method input parameter whose value is an array with no elements shall not have any value encoded. For example:

&itemNames=


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.


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.


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

LIITE 2 JATKUU

exception=BadItemValue&itemName=Patient.Co.Sex&itemValue=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.


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.

Documents

Kontekstinhallinnan määrittely versio 2 luonnos