Open Building Information Exchange (oBIX) - Revision history

Laurent.Lemke at 16:39, 16 February 2014

2014-02-16T16:39:39Z

← Older revision		Revision as of 16:39, 16 February 2014
Line 130:		Line 130:
	Un exemple d'architecture repris d'un article (http://www.automatedbuildings.com/news/jun08/articles/considine/080539121012obix.htm) qui se veut être purement illustrative:		Un exemple d'architecture repris d'un article (http://www.automatedbuildings.com/news/jun08/articles/considine/080539121012obix.htm) qui se veut être purement illustrative:

	[[~~Fichier~~:Archi_servOBIX.png\|~~vignette~~\|~~alt=~~Exemple d'architecture d'un serveur oBIX\|Exemple d'architecture d'un serveur oBIX]]		[[Image:Archi_servOBIX.png\|200px\|thumb\|right\|Exemple d'architecture d'un serveur oBIX\|Exemple d'architecture d'un serveur oBIX]]

	Ici, il s'agit d'une gateway qui fait office de serveur oBIX. Les clients étant extérieur (browser/appli/sources de données) et interrogeant la passerelle.		Ici, il s'agit d'une gateway qui fait office de serveur oBIX. Les clients étant extérieur (browser/appli/sources de données) et interrogeant la passerelle.

Laurent.Lemke at 16:37, 16 February 2014

2014-02-16T16:37:48Z

← Older revision		Revision as of 16:37, 16 February 2014
Line 130:		Line 130:
	Un exemple d'architecture repris d'un article (http://www.automatedbuildings.com/news/jun08/articles/considine/080539121012obix.htm) qui se veut être purement illustrative:		Un exemple d'architecture repris d'un article (http://www.automatedbuildings.com/news/jun08/articles/considine/080539121012obix.htm) qui se veut être purement illustrative:

			[[Fichier:Archi_servOBIX.png\|vignette\|alt=Exemple d'architecture d'un serveur oBIX\|Exemple d'architecture d'un serveur oBIX]]
	INSERT IMAGE

	Ici, il s'agit d'une gateway qui fait office de serveur oBIX. Les clients étant extérieur (browser/appli/sources de données) et interrogeant la passerelle.		Ici, il s'agit d'une gateway qui fait office de serveur oBIX. Les clients étant extérieur (browser/appli/sources de données) et interrogeant la passerelle.
Line 136:		Line 136:

	Le support de persistance est utilisé notamment par les objets History, ce support peut être une base de données par exemple.		Le support de persistance est utilisé notamment par les objets History, ce support peut être une base de données par exemple.

Laurent.Lemke at 16:34, 16 February 2014

2014-02-16T16:34:05Z

@@ Line 68: / Line 68: @@
 Il est alors possible de redéfinir les attributs, ces derniers doivent être redéfini de manière cohérente.
-De même l'héritage multiple doit être cohérent (pas d'attribut contradictoire dans 2 classes différentes dont on hérite par ex.). On parle alors de Contract Compatibility (section 7.7)
+De même l'héritage multiple doit être cohérent (pas d'attribut contradictoire dans 2 classes différentes dont on hérite par ex.). On parle alors de Contract Compatibility (section 7.7).
 ==Opérations==
@@ Line 87: / Line 88: @@
 TODO => watch/alarm/history, modèle client/serveur...
 ==Implémentations==

Laurent.Lemke at 16:23, 14 February 2014

2014-02-14T16:23:59Z

← Older revision		Revision as of 16:23, 14 February 2014
Line 2:		Line 2:
	Open Building Information Exchange (oBIX) est un standard OASIS mené par divers industriels dans le domaine du batiment intelligent.		Open Building Information Exchange (oBIX) est un standard OASIS mené par divers industriels dans le domaine du batiment intelligent.

	oBIX vise a s'affranchir des protocoles des devices (sensors/actuators/web-services exterieurs/...) en les décrivant en tant qu'objet suivant un [[#Modèle Objet\|Modèle Objet]]. Ces objet sont décris ~~via~~ un [[#Encodage\|Encodage]] ~~via~~ ~~les avec~~ ~~les~~ ~~diverses~~ ~~possibilités~~ ~~qu'offre~~ ~~oBIX~~.		oBIX vise a s'affranchir des protocoles des devices (sensors/actuators/web-services exterieurs/...) en les décrivant en tant qu'objet suivant un [[#Modèle Objet\|Modèle Objet]]. Ces objet sont décris avec un [[#Encodage\|Encodage]] et manipulable en tant que web service.

	Ce standard se base sur une architecture RESTful qui est indépendante des protocoles pouvant être ~~utilisé~~ de manière sous-jacente (HTTP, SOAP, COAP, ...).		Ce standard se base sur une architecture RESTful qui est indépendante des protocoles pouvant être implémenté de manière sous-jacente (HTTP, SOAP, COAP, ...).

	Actuellement la specification en est a la version 1.1, dispo ici: http://docs.oasis-open.org/obix/obix/v1.1/csprd02/obix-v1.1-csprd02.pdf		Actuellement la specification en est a la version 1.1, dispo ici: http://docs.oasis-open.org/obix/obix/v1.1/csprd02/obix-v1.1-csprd02.pdf
Line 13:		Line 13:
	Exemple: Un objet "Int" possède 4 attributs: max, min, unit (= l'unité de la valeur °C, cm, min..), val (= valeur). Et hérite d'un objet de type primitif '''Obj''' lui même ayant des attributs, l'un des plus important attribut étant '''href''' représentant une URI qui va permettre d'atteindre l'objet.		Exemple: Un objet "Int" possède 4 attributs: max, min, unit (= l'unité de la valeur °C, cm, min..), val (= valeur). Et hérite d'un objet de type primitif '''Obj''' lui même ayant des attributs, l'un des plus important attribut étant '''href''' représentant une URI qui va permettre d'atteindre l'objet.

	Par ailleurs, des annotations peuvent être utilisés en plus des attributs pour apporter des informations complémentaires l'objet (ex: avec l'encodage XML, il s'agira ~~des~~ Facets		Par ailleurs, des annotations peuvent être utilisés en plus des attributs pour apporter des informations complémentaires l'objet (ex: avec l'encodage XML, il s'agira de Facets XSD)

	Une notion essentielle dans le standard oBIX est le typage de chaque objet décrit dans l'une des section suivantes.		Une notion essentielle dans le standard oBIX est le typage de chaque objet décrit dans l'une des section suivantes.
Line 69:		Line 69:

	De même l'héritage multiple doit être cohérent (pas d'attribut contradictoire dans 2 classes différentes dont on hérite par ex.). On parle alors de Contract Compatibility (section 7.7)		De même l'héritage multiple doit être cohérent (pas d'attribut contradictoire dans 2 classes différentes dont on hérite par ex.). On parle alors de Contract Compatibility (section 7.7)



	==Opérations==		==Opérations==
			Les objets oBIX possèdant une URI peuvent répondre à diverses opérations suivant leur nature, on en distingue 4 différentes:
⚫	TODO => ~~Archi RESTful,~~ watch/alarm/history, modèle client/serveur...
			* READ: Pour lire un objet
			* WRITE: Pour changer l'état (= la valeur) d'un objet
			* INVOKE: Pour appeler une fonction ayant possiblement des paramètres d'entrée/sortie.
			* DELETE: Supprimer un objet

			Exemple:

			Dans le cadre d'un serveur oBIX implémentant des webservices permettant l'accès aux objets via le protocole HTTP, des opérations HTTP typiques seraient:
			* HTTP GET: pour la lecture d'un objet
			* HTTP PUT: pour changement d'état d'un objet
			* HTTP POST: pour appeler une fonction avec comme paramètre le corps de message de la requete POST.
			* HTTP DELETE: pour supprimer un objet.

		⚫	TODO => watch/alarm/history, modèle client/serveur...

	==Implémentations==		==Implémentations==

Laurent.Lemke at 12:29, 14 February 2014

2014-02-14T12:29:30Z

← Older revision		Revision as of 12:29, 14 February 2014
Line 2:		Line 2:
	Open Building Information Exchange (oBIX) est un standard OASIS mené par divers industriels dans le domaine du batiment intelligent.		Open Building Information Exchange (oBIX) est un standard OASIS mené par divers industriels dans le domaine du batiment intelligent.

	oBIX vise a s'affranchir des protocoles des devices (sensors/actuators/web-services exterieurs/...) en les décrivant en tant qu'objet suivant un [[#Modèle Objet\|Modèle Objet]]. Ces objet sont décris via un [[#Encodage\|Encodage] via les avec les diverses possibilités qu'offre oBIX.		oBIX vise a s'affranchir des protocoles des devices (sensors/actuators/web-services exterieurs/...) en les décrivant en tant qu'objet suivant un [[#Modèle Objet\|Modèle Objet]]. Ces objet sont décris via un [[#Encodage\|Encodage]] via les avec les diverses possibilités qu'offre oBIX.

	Ce standard se base sur une architecture RESTful qui est indépendante des protocoles pouvant être utilisé de manière sous-jacente (HTTP, SOAP, COAP, ...).		Ce standard se base sur une architecture RESTful qui est indépendante des protocoles pouvant être utilisé de manière sous-jacente (HTTP, SOAP, COAP, ...).

Laurent.Lemke at 12:29, 14 February 2014

2014-02-14T12:29:16Z

← Older revision		Revision as of 12:29, 14 February 2014
Line 2:		Line 2:
	Open Building Information Exchange (oBIX) est un standard OASIS mené par divers industriels dans le domaine du batiment intelligent.		Open Building Information Exchange (oBIX) est un standard OASIS mené par divers industriels dans le domaine du batiment intelligent.

	oBIX vise a s'affranchir des protocoles des devices (sensors/actuators/web-services exterieurs/...) en les décrivant en tant qu'objet ~~XML~~ suivant un [[#~~modèle~~ ~~objet~~\|Modèle Objet]]. Ces objet sont via les avec les diverses possibilités qu'offre oBIX.		oBIX vise a s'affranchir des protocoles des devices (sensors/actuators/web-services exterieurs/...) en les décrivant en tant qu'objet suivant un [[#Modèle Objet\|Modèle Objet]]. Ces objet sont décris via un [[#Encodage\|Encodage] via les avec les diverses possibilités qu'offre oBIX.

	Ce standard se base sur une architecture RESTful qui est indépendante des protocoles pouvant être utilisé de manière sous-jacente (HTTP, SOAP, COAP, ...).		Ce standard se base sur une architecture RESTful qui est indépendante des protocoles pouvant être utilisé de manière sous-jacente (HTTP, SOAP, COAP, ...).
Line 9:		Line 9:

	==Modèle Objet==		==Modèle Objet==
	Tel que détaillé en Section 4 de la spécificiation, les objets oBIX respectent un modèle correspondant au type primitif d'objet		Tel que détaillé en Section 4 de la spécificiation, les objets oBIX respectent un modèle correspondant au type primitif d'objet.

	Exemple: Un objet "Int" possède 4 attributs: max, min, unit (= l'unité de la valeur °C, cm, min..), val (= valeur). Et hérite d'un objet de type primitif '''Obj''' lui même ayant des attributs, l'un des plus important attribut étant '''href''' représentant une URI qui va permettre d'atteindre l'objet.		Exemple: Un objet "Int" possède 4 attributs: max, min, unit (= l'unité de la valeur °C, cm, min..), val (= valeur). Et hérite d'un objet de type primitif '''Obj''' lui même ayant des attributs, l'un des plus important attribut étant '''href''' représentant une URI qui va permettre d'atteindre l'objet.

	Par ailleurs, ~~les Facets~~ ~~du langage XSD (Xml Schema Definition)~~ peuvent être utilisés en plus des attributs pour ~~annoter~~ l'objet.		Par ailleurs, des annotations peuvent être utilisés en plus des attributs pour apporter des informations complémentaires l'objet (ex: avec l'encodage XML, il s'agira des Facets

	Une notion essentielle dans le standard oBIX est le typage de chaque objet décrit dans la section ~~suivante~~.		Une notion essentielle dans le standard oBIX est le typage de chaque objet décrit dans l'une des section suivantes.

	==Objet==		==Objet==
	Les objets oBIX suivent tous le modèle d'objet ~~comme~~ évoqué en section précédente.		Les objets oBIX suivent tous le modèle d'objet évoqué en section précédente.
	Ces derniers peuvent servir à décrire l'état d'une lampe. ~~Typiquement,~~ ~~l'objet~~ ~~"Bool"~~ de ~~type~~ ~~primitif~~ ~~sera~~ ~~utilisé~~ ~~ici:~~		Ces derniers peuvent servir à décrire l'état d'une lampe et sont encodés dans une syntaxe particulière décrit ci-après.

			===Encodage===
			Le standard oBIX définit plusieurs encodage pour les objets:
			* XML, qui est recommandé par la spécification.
			* JSON
			* EXI (Efficient XML Interchange)

			Une description de ces derniers est disponible ici: http://docs.oasis-open.org/obix/obix-encodings/v1.0/csprd02/obix-encodings-v1.0-csprd02.pdf

			Dans la suite de cette page wiki, les exemples seront donnés uniquement dans l'encodage XML.

			Un exemple d'un objet oBIX encodé en XML pour représenter l'actionneur d'une lampe pourrait être:

	<pre>		<pre>
	<obj href="/uri/to/access/~~Lamp~~">		<obj href="/uri/to/access/LampActuator">
	<bool name="state" val="off"/>		<bool name="state" val="off"/>
	</obj>		</obj>
	</pre>		</pre>
			Ici, l'objet "Bool" de type primitif est utilisé pour montrer que l'actionneur de la lampe n'a pas été déclenché; La lampe est donc éteinte.

⚫	Afin de pouvoir avoir des ~~modèles d'~~objets ~~plus~~ ~~poussés,~~ et ~~réutilisable/~~extensible, ~~oBIX~~ permet l'~~utilisation~~ de types.

	===Type d'objet===		===Type d'objet===
		⚫	Afin de pouvoir avoir des objets oBIX réutilisables et extensible, la norme permet l'usage de types.
	~~Les~~ objets de type primitif peuvent être typés dans oBIX par ce qui est nommé des "Contracts" (section 7 spécif.).		En effet, les objets de type primitif peuvent être typés dans oBIX par ce qui est nommé des "Contracts" (section 7 spécif.).

	Un contract représente le template(<=> squelette) d'un objet		Un contract représente le template(<=> squelette) d'un objet

Laurent.Lemke: /* Implémentations */

2014-02-14T00:19:47Z

Implémentations

← Older revision		Revision as of 00:19, 14 February 2014
Line 64:		Line 64:
	==Implémentations==		==Implémentations==
	Middleware JAVA/OSGi pouvant s’exécuter sur une gateway en tant que serveur oBIX: [[IoTSyS]]		Middleware JAVA/OSGi pouvant s’exécuter sur une gateway en tant que serveur oBIX: [[IoTSyS]]

	Une implem. en C mais qui est ancienne, non complète et non-tenu à jour: https://code.google.com/p/c-obix-tools/		Une implem. en C mais qui est ancienne, non complète et non-tenu à jour: https://code.google.com/p/c-obix-tools/

Laurent.Lemke at 00:19, 14 February 2014

2014-02-14T00:19:39Z

← Older revision		Revision as of 00:19, 14 February 2014
Line 61:		Line 61:
	==Opérations==		==Opérations==
	TODO => Archi RESTful, watch/alarm/history, modèle client/serveur...		TODO => Archi RESTful, watch/alarm/history, modèle client/serveur...

			==Implémentations==
			Middleware JAVA/OSGi pouvant s’exécuter sur une gateway en tant que serveur oBIX: [[IoTSyS]]
			Une implem. en C mais qui est ancienne, non complète et non-tenu à jour: https://code.google.com/p/c-obix-tools/

Laurent.Lemke at 00:14, 14 February 2014

2014-02-14T00:14:29Z

← Older revision		Revision as of 00:14, 14 February 2014
Line 60:		Line 60:

	==Opérations==		==Opérations==
			TODO => Archi RESTful, watch/alarm/history, modèle client/serveur...
	TODO

Laurent.Lemke at 00:13, 14 February 2014

2014-02-14T00:13:47Z

← Older revision		Revision as of 00:13, 14 February 2014
Line 1:		Line 1:
	Open Building Information Exchange (oBIX)

			Open Building Information Exchange (oBIX) est un standard OASIS mené par divers industriels dans le domaine du batiment intelligent.
	standard OASIS pour le building automation

			oBIX vise a s'affranchir des protocoles des devices (sensors/actuators/web-services exterieurs/...) en les décrivant en tant qu'objet XML suivant un [[#modèle objet\|Modèle Objet]]. Ces objet sont via les avec les diverses possibilités qu'offre oBIX.
⚫	http://docs.oasis-open.org/obix/obix/v1.1/csprd02/obix-v1.1-csprd02.pdf

			Ce standard se base sur une architecture RESTful qui est indépendante des protocoles pouvant être utilisé de manière sous-jacente (HTTP, SOAP, COAP, ...).

		⚫	Actuellement la specification en est a la version 1.1, dispo ici: http://docs.oasis-open.org/obix/obix/v1.1/csprd02/obix-v1.1-csprd02.pdf

			==Modèle Objet==
			Tel que détaillé en Section 4 de la spécificiation, les objets oBIX respectent un modèle correspondant au type primitif d'objet

			Exemple: Un objet "Int" possède 4 attributs: max, min, unit (= l'unité de la valeur °C, cm, min..), val (= valeur). Et hérite d'un objet de type primitif '''Obj''' lui même ayant des attributs, l'un des plus important attribut étant '''href''' représentant une URI qui va permettre d'atteindre l'objet.

			Par ailleurs, les Facets du langage XSD (Xml Schema Definition) peuvent être utilisés en plus des attributs pour annoter l'objet.

			Une notion essentielle dans le standard oBIX est le typage de chaque objet décrit dans la section suivante.

			==Objet==
			Les objets oBIX suivent tous le modèle d'objet comme évoqué en section précédente.
			Ces derniers peuvent servir à décrire l'état d'une lampe. Typiquement, l'objet "Bool" de type primitif sera utilisé ici:
			<pre>
			<obj href="/uri/to/access/Lamp">
			<bool name="state" val="off"/>
			</obj>
			</pre>

			Afin de pouvoir avoir des modèles d'objets plus poussés, et réutilisable/extensible, oBIX permet l'utilisation de types.

			===Type d'objet===
			Les objets de type primitif peuvent être typés dans oBIX par ce qui est nommé des "Contracts" (section 7 spécif.).

			Un contract représente le template(<=> squelette) d'un objet
			Exemple pour le contract obix:Weekday définissant les jours de la semaine:
			<pre>
			<enum href="obix:Weekday" range="#Range">
			<list href="#Range" is="obix:Range">
			<obj name="sunday" />
			<obj name="monday" />
			<obj name="tuesday" />
			<obj name="wednesday" />
			<obj name="thursday" />
			<obj name="friday" />
			<obj name="saturday" />
			</list>
			</enum>
			</pre>
			Ici le contract utilise un autre contract obix:Range. Ce dernier est défini comme suit:
			<pre>
			<list href="obix:Range" of="obix:obj"/>
			</pre>
			Il ne s'agit en fait que d'un contrat permettant de définir des listes d'objets. Dans le contexte du contract obix:Weekday, ces objets étant des jours de la semaine.

			La notion de type recouvre une notion importante dans oBIX qui est l''''héritage multiple''' (Section 7.4). Il est possible de spécifier une liste d'objet dont on hérite, via l'attribut <pre>is="parent1 parent2 etc.."</pre>
			Il est alors possible de redéfinir les attributs, ces derniers doivent être redéfini de manière cohérente.

			De même l'héritage multiple doit être cohérent (pas d'attribut contradictoire dans 2 classes différentes dont on hérite par ex.). On parle alors de Contract Compatibility (section 7.7)



			==Opérations==
			TODO