e.Toscana Compliance 
Request for Comments:  
Del: 10/10/2006 
Categoria: Applicativa
Destinatari: Regione Toscana, enti locali e regionali

Centro Servizi Regionale per il Digitale Terrestre
 
Indice
------
1. Contesto di riferimento ed obiettivi
2. Integrazione dei sistemi informativi	
3. Interazioni previste tra Enti Locali e Regione 
4. Descrizione del sistema
4.1. Pubblicazione/aggiornamento dei contenuti
4.2. Gestione canale di ritorno
5. Bibliografia

1. Contesto di riferimento ed obiettivi
---------------------------------------
Il contesto in cui si colloca il progetto "Centro Servizi Regionale per il Digitale Terrestre", 
di seguito CS-DTT-Toscana  la creazione di un sistema unificato di pubblicazione di 
applicazioni e contenuti in ambito DTT.
Obiettivo del progetto  sia creare un sistema che sia in grado di offrire una piattaforma 
regionale unica per la trasmissione su piattaforma DTT delle applicazioni MHP 
e dei contenuti che i soggetti facenti parte della RTRT sono interessati a diffondere sia 
creare un punto di incontro tra i soggetti RTRT ed i broadcaster per le trasmissioni su DTT.


2. Integrazione dei sistemi informativi
---------------------------------------
L'infrastruttura CART (Cooperazione Applicativa della Regione Toscana) abilita 
la cooperazione tra i SIL degli enti ed il Centro Servizi DTT attraverso la 
realizzazione di interfacce applicative (Proxy Applicativi). 
Ogni proxy applicativo presenta una doppia interfaccia: da un lato utilizza i 
servizi infrastrutturali del CART per inviare e ricevere informazione e 
per invocare servizi; dall'altro rende disponibili i servizi ai SIL 
attraverso una molteplicit di interfacce.

Al fine di supportare l'integrazione di sistemi SIL diversi, realizzati in tempi 
diversi e con tecnologie eterogenee, ogni proxy applicativo fornisce una 
descrizione standard di ogni interfaccia esposta ai SIL. Questo riguarda 
aspetti diversi:
- documentazione delle interfacce di servizio in modo standard (es. WSDL)
- rappresentazione dell'informazione scambiata in modo standard (XML come 
indicato nelle linee guida [AP1])
- documentazione del formato dell'informazione scambiata in modo standard 
(XMLSchema)

3. Interazioni previste tra Enti e Regione
---------------------------------------------
I sistemi coinvolti nel sistema appartengono a due tipologie: 
- SIL degli enti locali; 
- Centro Servizi DTT Regione Toscana. 

Questi partecipano alla cooperazione ricoprendo ruoli diversi:
- I SIL che partecipano al servizio CS-DTT assumono il ruolo di pubblicatori e inviano 
eventi XML (con formato dipendente dalla natura stessa dell'informazione) ed i contenuti
da pubblicare (codice binario della applicazione e/o contenuti informativi)
al proxy applicativo CS-DTT a cui afferiscono. 
- Gli eventi sono propagati nel CART e ricevuti dal centro servizi (attraverso un proxy 
applicativo centrale) che pertanto assume il ruolo di sottoscrittore.

Gli eventi inviati dai SIL al centro servizi sono di tipo diverso:

 - DTT-E1 EventoPubblicazioneApplicazione
 - DTT-E2 EventoPubblicazioneContenuti

Di seguito si riporta la definizione del formato di ogni evento attraverso 
XMLSchema


DTT-E1 EventoPubblicazione
============================
Questo evento  inviato per notificare al sottoscrittore informazione relativa 
ai seguenti eventi: 

Pubblicazione Applicazione
Aggiornamento Applicazione
Aggiornamento Contenuti

Il formato dell'evento  documentato dallo schema xml seguente:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<!--type attributo azione-->
  <xs:annotation>
    <xs:documentation>Tipo descrivente l'azione</xs:documentation>
    <xs:documentation>Deve essere presente esattamente UNA delle possibilit previste</xs:documentation>
    <xs:documentation>Ad ogni evento che viene pubblicato viene allegato un file in 
    formato archivio (zip o rar) che contiene tutti i file che devono essere trasferiti. 
    Nel caso di un evento di tipo "Aggiornamento Contenuti", per una stessa applicazione,
    la struttura dell'archivio sar sempre la stessa anche se non sono presenti tutti i 
    file della struttura originaria</xs:documentation>
  </xs:annotation>
  <xs:simpleType name="azione_type">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Pubblicazione Applicazione"/>
      <xs:enumeration value="Aggiornamento Applicazione"/>
      <xs:enumeration value="Aggiornamento Contenuti"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:element name="dtt_evento_pubblicazione">
    <xs:complexType>
        <xs:sequence>
          <xs:element name="nome" type="xs:string" maxOccurs="1" minOccurs="1">E' il nome dell'applicazione
		 cos come comunicato al centro servizi DTT di Regione Toscana</xs:element>
          <xs:element name="provider" type="xs:string" minOccurs="1" maxOccurs="1">E' il nome del providercos 
		 come comunicato al centro servizi DTT di Regione Toscana</xs:element>
          <xs:element name="data" type="xs:date" minOccurs="1" maxOccurs="1">E' la data della pubblicazione 
		 dell'evento </xs:element>
          <xs:element name="argomento" type="xs:string" minOccurs="1" maxOccurs="1">E' l'argomento della 
		pubblicazione </xs:element>
        </xs:sequence>
        <xs:attribute name="azione" type="azione_type" use="required"/>
    </xs:complexType>
  </xs:element>
</xs:schema> 

Un esempio di evento XML conforme allo schema  il seguente:

<?xml version="1.0" encoding="UTF-8"?>
<dtt_evento_pubblicazione azione="Aggiornamento Contenuti" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="dtt_pubblicazione.xsd">
  <nome>PortaleInformativo_RegioneToscana</nome>
  <provider>Regione Toscana</provider>
  <data>2006-10-10</data>
  <argomento>news</argomento>
</dtt_evento_pubblicazione>

4. Descrizione del sistema
--------------------------
La cooperazione applicativa tra SIL afferenti e CS-DTT-Toscana  resa possibile 
da una serie di servizi messi a disposizione dei SIL. Tali servizi si possono
riassumere in due tipologie:
- servizi per la pubblicazione/aggiornamento dei contenuti presso i broadcaster
- servizi di gestione del canale di ritorno per le applicazioni DTT interattive.

4.1. Pubblicazione/aggiornamento dei contenuti
----------------------------------------------
Per la pubblicazione delle applicazioni e per il periodico aggiornamento 
dei contenuti informativi sono fornite due interfacce:
- una interfaccia Web accessibile da browser
- una interfaccia SOAP realizzata con web service che permette l'invocazione dei servizi
  da parte di una applicazione che supporti il protocollo SOAP
  
Di seguito il WSDL dell'interfaccia SOAP:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://carttestnal.rete.toscana.it/DTTProxy/services/AxisProxyService" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://carttestnal.rete.toscana.it/DTTProxy/services/AxisProxyService" xmlns:intf="http://carttestnal.rete.toscana.it/DTTProxy/services/AxisProxyService" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><wsdl:types><schema targetNamespace="http://xml.apache.org/xml-soap" xmlns="http://www.w3.org/2001/XMLSchema"><import namespace="http://schemas.xmlsoap.org/soap/encoding/"/><complexType name="Vector"><sequence><element maxOccurs="unbounded" minOccurs="0" name="item" type="xsd:anyType"/></sequence></complexType></schema></wsdl:types>
  <wsdl:message name="deleteAllMessagesResponse">
    <wsdl:part name="deleteAllMessagesReturn" type="xsd:string"/>
  </wsdl:message>
  <wsdl:message name="receiveEventsRequest">
    <wsdl:part name="nomeEvento" type="xsd:string"/>
    <wsdl:part name="silId" type="xsd:string"/>
  </wsdl:message>
  <wsdl:message name="uploadEventRequest">
    <wsdl:part name="nomeEvento" type="xsd:string"/>
    <wsdl:part name="silId" type="xsd:string"/>
  </wsdl:message>
  <wsdl:message name="receiveEventsResponse">
    <wsdl:part name="receiveEventsReturn" type="apachesoap:Vector"/>
  </wsdl:message>
  <wsdl:message name="uploadEventResponse">
    <wsdl:part name="uploadEventReturn" type="xsd:string"/>
  </wsdl:message>
  <wsdl:message name="deleteAllMessagesRequest">
    <wsdl:part name="silId" type="xsd:string"/>
  </wsdl:message>
  <wsdl:portType name="AxisProxyService">
    <wsdl:operation name="receiveEvents" parameterOrder="nomeEvento silId">
      <wsdl:input message="impl:receiveEventsRequest" name="receiveEventsRequest"/>
      <wsdl:output message="impl:receiveEventsResponse" name="receiveEventsResponse"/>
    </wsdl:operation>
    <wsdl:operation name="uploadEvent" parameterOrder="nomeEvento silId">
      <wsdl:input message="impl:uploadEventRequest" name="uploadEventRequest"/>
      <wsdl:output message="impl:uploadEventResponse" name="uploadEventResponse"/>
    </wsdl:operation>
    <wsdl:operation name="deleteAllMessages" parameterOrder="silId">
      <wsdl:input message="impl:deleteAllMessagesRequest" name="deleteAllMessagesRequest"/>
      <wsdl:output message="impl:deleteAllMessagesResponse" name="deleteAllMessagesResponse"/>
    </wsdl:operation>
  </wsdl:portType>
  <wsdl:binding name="AxisProxyServiceSoapBinding" type="impl:AxisProxyService">
    <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="receiveEvents">
      <wsdlsoap:operation soapAction=""/>
      <wsdl:input name="receiveEventsRequest">
        <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost/DTTProxy/services/AxisProxyService" use="encoded"/>
      </wsdl:input>
      <wsdl:output name="receiveEventsResponse">
        <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://llocalhost/DTTProxy/services/AxisProxyService" use="encoded"/>
      </wsdl:output>
    </wsdl:operation>
    <wsdl:operation name="uploadEvent">
      <wsdlsoap:operation soapAction=""/>
      <wsdl:input name="uploadEventRequest">
        <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost/DTTProxy/services/AxisProxyService" use="encoded"/>
      </wsdl:input>
      <wsdl:output name="uploadEventResponse">
        <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost/DTTProxy/services/AxisProxyService" use="encoded"/>
      </wsdl:output>
    </wsdl:operation>
    <wsdl:operation name="deleteAllMessages">
      <wsdlsoap:operation soapAction=""/>
      <wsdl:input name="deleteAllMessagesRequest">
        <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost/DTTProxy/services/AxisProxyService" use="encoded"/>
      </wsdl:input>
      <wsdl:output name="deleteAllMessagesResponse">
        <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost/DTTProxy/services/AxisProxyService" use="encoded"/>
      </wsdl:output>
    </wsdl:operation>
  </wsdl:binding>
  <wsdl:service name="AxisProxyServiceService">
    <wsdl:port binding="impl:AxisProxyServiceSoapBinding" name="AxisProxyService">
      <wsdlsoap:address location="http://localhost/DTTProxy/services/AxisProxyService"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

Ogni evento di pubblicazione prevede due allegati:
- un file xml rappresentativo dell'evento
- un file di tipo archivio (zip o rar) contenente i file dell'applicazione e/o contenuti

Per una stessa applicazione, l'archivio dei file da trasmettere deve conservare la struttura 
di cartelle cos come richiesta dall'applicazione MHP che li utilizzer.

Esempio.
Supponiamo che la struttura di una applicazione sia la seguente:

basedir---
         |
         -->appCode---
	 |	     |
	 |	     --->codeDir1
	 |	     .
  	 |	     .
         |           --->codeDirn
         |
         -->content---
		     |
		     --->contDir1---
		     |		   |
		     |		   --->contFile1
		     |		   |
		     |		   --->contFile2
		     |		   .
		     |		   .
		     |		   .
		     | 		   --->contFilen
		     |
                     --->contDir2---
				   |
				   ........

Nel caso in cui sia necessario l'upload sulla piattaforma anche del solo file contFile2,
l'archivio non dovr contenere il solo file interessato, ma dovr conservare la struttura 
originale di cartelle a partire dalla basedir.



4.2. Gestione canale di ritorno
-------------------------------
Il CS-DTT della Regione Toscana offre anche il servizio di gestione del canale di ritorno 
per le applicazioni interattive. Anche in questo caso, scopo del servizio  quello di offrire 
un unico punto di accesso per tutte le applicazioni che necessitano dell'utilizzo del canale
di ritorno. Per l'erogazione del servizio, il CS mette a disposizione due server:
- un access server, il cui scopo  quello di ricevere le connessioni dai diversi Set Top Box,
- un proxy server, presso cui tutte le richieste di interrogazione dovranno essere dirette.

Per poter utilizzare la gestione del canale di ritorno offerto dal CS-DTT, i provider 
delle applicazioni dovranno impostare nelle proprie applicazioni, come parametri di 
configurazione, i seguenti valori:

per la connessione del Set Top Box all'access server del CS-DTT,
- numero di telefono=7011110155
- username=da richiedere a Regione Toscana
- password=da richiedere a Regione Toscana


Inoltre, i provider devono fornire al CS, la lista dei servizi remoti verso cui effettuare le
richieste. Il modulo di segnalazione dei servizi remoti  cos strutturato:

-----------------------------------------------------------------
|NOME SERVIZIO		|	URL RISORSA  			|
-----------------------------------------------------------------
|Ente1_servizio1	|http://ente1_server/risorsa1......	|
-----------------------------------------------------------------
| .......		| ........				|
-----------------------------------------------------------------

Solo successivamente alla conferma da parte di Regione Toscana, il provider potr effettivamente
utilizzare il servizio.

Dopo aver stabilito il canale dati con l'access server, le richieste dovranno essere rivolte
al proxy server, il quale si occuper di recuperare i dati presso le reali destinazioni e di 
rispedirle ai richiedenti.
Il proxy server esporr un servizio dal nome CSProxy, che accetta due parametri, "application" e "params".
Il parametro application dovr essere valorizzato con il nome del servizio cos come da 
tabella comunicata al CS.
Il parametro params dovr essere valorizzato con la stringa, URL encoded, di coppie parametro-valore
cos come richiesto dalla risorsa che si vuole utilizzare.

L'URL completo del proxy server :
http://159.213.225.62:8080/CSProxy/CSProxy

Esempio.
URL completo: http://ente1_server/risorsa1/risorsa1?param1=valore1&param2=valore2

URL da utilizzare: http://159.213.225.62:8080/CSProxy/CSProxy?application=Ente1_servizio1&params=param1%3Dvalore1%26param2%3Dvalore2 


5. Bibliografia
---------------
Documenti rilasciati dal Centro Nazionale per lInformatica nella Pubblica
Amministrazione (AIPA-CNIPA):
[AP1] AIPA, "Servizio di cooperazione applicativa basata su eventi", Quaderni 
AIPA Dicembre 1999 