Cesnavarra 2008-boletín 11

Título Programar un Webpart de Excel Web Access

Texto En este articulo crearemos un procedimiento para agregar
un Webpart de Excel Web Access para poderlo utilizar en
SharePoint. Por otro lado veremos cómo mostrar un libro Excel
mediante la programación en un Webpart de Excel Web Access.

Lo primero deberemos crear una biblioteca de documentos de
SharePoint y convertirla en una ubicación de confianza mediante el
siguiente procedimiento:

1. En el menú Inicio, haga clic en Todos los
programas.
2. Elija Microsoft Office Server y haga clic
en Administración central de SharePoint
3.0.
3. En Inicio rápido, haga clic en el vínculo del
Proveedor de servicios compartidos (SSP), por
ejemplo, "ServiciosCompartidos1", para ver la
página inicial Servicios compartidos de ese SSP
en particular.
4. En la página de inicio Servicios compartidos,
dentro de la sección Configuración de Excel
Services, haga clic en Ubicaciones de
archivos de confianza.
5. En la página Ubicación de archivos de confianza
de Excel Services, haga clic en Agregar
ubicación de archivo de confianza.
6. En la página Agregar ubicación de archivo de
confianza de Excel Services, en el
cuadro Dirección, escriba la ubicación donde
guardará el libro, por
ejemplo, http://MyServer002/Shared%20Docum
ents.
7. En Tipo de ubicación, haga clic en el tipo de
ubicación correspondiente. Por ejemplo,
seleccione Windows SharePoint Services.
8. En Confiar en nodos secundarios,
seleccione Nodos secundarios de confianza si
desea confiar en bibliotecas o directorios de
elementos secundarios.
9. Haga clic en Aceptar.

Seguidamente crearemos un nuevo proyecto en C#,
previamente deberemos descargar herramientas de
Windows SharePoint Services 3.0: extensiones de Visual
Studio 2008, versión 1.2 en el siguiente

enlace: http://www.microsoft.com/downloads/details.aspx
?displaylang=es&FamilyID=7bf65b28-06e2-4e87-9bad-
086e32185e68.
Una vez instaladas estas herramientas elegiremos dentro de la
ubicación SharePoint un Webpart como se muestra en la siguiente
imagen:

using System;
using System.Collections.Generic;
using System.Windows.Forms;
namespace AddEWATool
{
internal static class Program
{
//Principal punto de entrada de la aplicación.
[STAThread]
public static int Main(string[] args)
{

if (args.Length == 0)
{
Application.Run(new Form1());
return 1;
}
else
{
Commandline comm = new Commandline();
int worked = comm.CommandLineAddWebPart(args);
return worked;
}
}
}
}

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;
using Microsoft.Office.Excel.WebUI;
namespace AddEWATool
{
//Form1 deriva de la clase System.Windows.Form
//iniciación de variables
public partial class Form1 : Form
{
private string siteurl;
private string bookuri;
private bool succeeded;

private string appname = "AddEWATool";
private string specifyinput = "Por favor añada la URL de un sitio,
por ejemplo, http://myserver/site/";
private string siteproblem = "Se ha producido un problema con

el nombre del sitio. Por favor, compruebe que el sitio existe.";
private string addproblem = " Se ha producido un problema al añadir

el Web Part.";
private string success = "Web Part ha sido añadido
satisfactoriamente.";
private SPSite site;
private SPWeb TargetWeb;
private SPWebPartCollection sharedWebParts;
//Clase constructor
public Form1()
{
InitializeComponent();
}

//Método que Añade Webpart
public bool AddWebPart(string sitename, string book)
{
bool b = false;
progressBar1.Visible = true;
progressBar1.Minimum = 1;
progressBar1.Maximum = 4;
progressBar1.Value = 1;
progressBar1.Step = 1;

if (String.IsNullOrEmpty(sitename))
{
MessageBox.Show(
specifyinput,
appname,
MessageBoxButtons.OK,
MessageBoxIcon.Asterisk);
return b;
}
try
{
site = new SPSite(sitename);
TargetWeb = site.OpenWeb();
}
catch (Exception exc)
{
MessageBox.Show(
siteproblem + "n" + exc.Message,
appname,
return b;
}
progressBar1.PerformStep();

//Accede a la colección shared Web Parts en la pagina de
inicio.
//Accede a los Webpats personales a través del default.aspx

try
{
sharedWebParts =
TargetWeb.GetWebPartCollection("Default.aspx",
Microsoft.SharePoint.WebPartPages.Storage.Shared);
}
{
MessageBox.Show(
siteproblem + "n" + exc.Message,
appname,
return b;
}
//Instancia de Excel Access WebPart
//Añade un Excel Access WebPart
ExcelWebRenderer ewaWebPart = new ExcelWebRenderer();
ewaWebPart.ZoneID = "Left";
ewaWebPart.WorkbookUri = book;
try
{
sharedWebParts.Add(ewaWebPart);
}
{
MessageBox.Show(
addproblem + "n" + exc.Message,
appname,
return b;
}
b = true;
return b;
}
//Evento Click que llama al metodo para añadir el Webpart
//pasándole la dirección del sitio y el libro.
private void AddEWAButton_Click(object sender,
EventArgs e)
{
siteurl = textBox1.Text;
bookuri = textBox2.Text;
succeeded = AddWebPart(siteurl, bookuri);
if (succeeded)
{
MessageBox.Show(
success,
appname,
MessageBoxIcon.Information);
}
}

Y el resultado en pantalla de nuestro ejemplo podría ser el
siguiente:

Como se ve, un sencillo desarrollo permite ampliar las capacidades
de nuestra plataforma SharePoint ampliando con ello sus usos.

Categ CES Microsoft
orías
Tema Desarrollo

Autor Raul Mayo González

Mes Noviembre

Año 2008

Boletí 11
n

Título Integración de jQuery con SharePoint(I)

Texto Buscando novedades interesantes presentadas durante el
Microsoft Professional Developers Conference (PDC) de este año,
encontré un artículo que habla sobre la integración de jQuery con
SharePoint. Dado que me parece un tema bastante interesante

para tratar y que puede aportar nuevas funcionalidades a los
sitios SharePoint, vamos a descubrir de qué se trata.

jQuery es una biblioteca de JavaScript que simplifica, entre otras
cosas, el manejo de eventos, las animaciones y las interacciones
con Ajax dentro del desarrollo web. Además aporta gran
interoperabilidad, ya que se puede integrar fácilmente con
cualquier tipo de páginas web (html, aspx…).

Lo primero que hay que tener en cuenta para usar dicha
biblioteca, es que debe estar disponible para cualquier página de
nuestro sitio. Por lo tanto debemos tener en cuenta 2 cosas:

 Desplegar la biblioteca en una localización accesible
para nuestro sitio SharePoint. El directorio
recomendado es el siguiente:
C:Program FilesCommon FilesMicrosoft Sharedweb server
extensions12TEMPLATELAYOUTS

 Cargar la biblioteca en todas las páginas .aspx de
nuestro sitio.
Para ello, una vez que descargamos el archivo JS de la página
oficial, lo guardamos en el directorio indicado anteriormente, al
que se accederá cuando llamemos a la
url http://[sitioweb]/default.aspx/_layouts/jquery-
1.2.6.min.js. Y añadimos, por ejemplo con la ayuda de
SharePoint Designer, el siguiente código en la cabecera de la
página maestra (master page) de nuestro sitio.

<script type="text/javascript" src="http://[sitioweb]/default.aspx/_layouts/jquery-
1.2.6.min.js"></script>

Donde pone [sitio web], cada uno deberá escribir la url de su
sitio.

El paso anterior, a pesar de ser muy sencillo, no siempre es el
más adecuado para asegurarnos de que todas las páginas de
nuestro sitio cargan la biblioteca. Ya que para que la carga se
realice correctamente se debe realizar desde el directorio de
archivos del sitio: C:Program FilesCommon FilesMicrosoft Sharedweb server
extensions12.

Por ello, la mejor manera de hacerlo es crear un control (web user
control) llamado jQueryControl.ascx que realice la carga de
jQuery. Este control estará desplegado con el resto de controles
en

extensions12TEMPLATECONTROLTEMPLATES

y el código que lo define es el mismo que utilizamos en nuestra
master page.

Nos interesa que este control se encuentre en la sección
“AdditionalPageHead Delegate Control”, de esta manera se
añadirá automáticamente a cada página de nuestro sitio.

Para añadirlo a “AdditionalPageHead Delegate Control”
necesitamos crear un feature de Sharepoint. Este feature que
llamamos jQuery y que guardamos en

extensions12TEMPLATEFEATURES

consta de dos archivos .xml:

 Feature.xml, que define nuestra característica
 Elements.xml, que define los elementos de nuestra
característica.
El archivo feature.xml quedaría de la siguiente manera:

Los principales parámetros que definen un feature son los
siguientes:

1. Id, es el identificador de nuestro feature. Este valor
único lo creamos con Visual Studio mediante la
herramienta para creación de GUID.
Tools > Create GUID

2. Title, es el nombre que le damos a nuestro feature.
3. Description, es la descripción que hacemos de
nuestro feature.
4. Scope, es el nivel de sitio al que queremos que actúe.
Aquí debemos tener en cuenta que Web se refiere a

un sitio y Site a una colección de sitios.
5. Lista de “ElementManifests”, donde definimos el que
nosotros vamos a usar que es elements.xml, e
indicamos su localización.
El archivo elements.xml, que indica que web control vamos a
añadir y donde, queda de la siguiente manera:

Finalmente lo que hacemos es instalar nuestro feature a través
del comando stsadm –o installfeature.

Aunque la consola nos muestra que la operación se ha realizado
con éxito lo mejor es comprobarlo en nuestro propio sitio. Para
ello, dentro de nuestro sitio SharePoint, vamos a Site Actions
>Site Settings >Site Administration > Site Features

Vemos que aparece nuestro feature, así que lo activamos y ya
podemos usarlo. La activación también se podría realizar
mediante el comando stsadm –o activefeature.

Para aquellos que lo prefieran, en vez de realizar estos pasos
manualmente, existe una solución de SharePoint (.wsp) que
contiene todos los elementos necesarios para su
implementación. Esta solución está disponible en Codeplex y
forma parte del proyecto Smart Tools. En artículos posteriores
veremos cómo se pueden realizar soluciones SharePoint de
manera sencilla con la ayuda de Visual Studio.

Como resumen decir, que en el artículo de hoy hemos visto las
pautas necesarias que hay que seguir para implementar jQuery,
además de algunas necesarias para crear e instalar un feature en
SharePoint. El paso siguiente será usarlo dentro de nuestro sitio,
que es donde realmente podemos ver las posibilidades que nos
ofrece. Esto es lo que veremos en el próximo artículo.

Catego CES Microsoft
rías
Tema Desarrollo

Autor Goretti Ortigosa Rada

Mes Noviembre

Año 2008

Boletín 11

Título ¿Qué es Azure?

Texto La verdad es que este mes no tenía pensado escribir sobre este tema sino

continuar investigando en la oportunidad que presentan los servicios Web
de los diversos servidores de Microsoft, pero la actualidad manda y
Microsoft impone que veamos la realidad de un nuevo color, Azure.

Y en realidad ¿qué es Azure? La definición oficial que encontramos en la
página de Microsoft http://www.microsoft.com/azure/default.mspx nos
dice que Azure es una plataforma de servicios de amplia gama de Internet
que pueden ser empleados tanto desde entornos locales como desde la
propia web. Y si buscamos más dice que la Plataforma de Servicios Azure™
proporciona un abanico de funcionalidades para crear, migrar y extender
aplicaciones que cubren desde las aplicaciones orientadas a consumo hasta
los escenarios empresariales. Dichos servicios se pueden usar de manera
individual o conjunta, con aplicaciones existentes o de nueva creación.

¿Más claro? Lo dudo. Intentemos bajar esta nube a tierra…

Azure Services Training Kit

Microsoft tiene disponible para su descarga desde la página
Web http://www.microsoft.com/azure el “Azure Services Training Kit”, que
consta de una serie de laboratorios, demos, presentaciones y ejemploe uqe
nos ayudan a entender qué es la Plataforma de Servicios Azure. De hecho
este kit nos da una definición más profunda y clara de qué es esta
plataforma:

La plataforma de servicios Azure es una ”nube” de servicios informáticos

de Internet y su plataforma de desarrollo asociada, alojada en centros de
datos de Microsoft que proporciona un sistema operativo y un conjunto de
servicios para el desarrollador que se pueden utilizar individualmente o
juntos. Da a los desarrolladores la opción para crear aplicaciones web;
aplicaciones que se ejecutan en dispositivos conectados, en PC o en
servidores; o en soluciones de tipo híbrido que ofrecen lo mejor de ambos
mundos. Aplicaciones de nueva creación o mejoradas pueden construirse
con los conocimientos existentes el entorno de desarrollo Visual Studio y
.NET Framework. Con su enfoque basado en estándares e interoperable la
plataforma de servicios admite varios protocolos de Internet, incluidos
HTTP, REST, SOAP y XML sin formato.

¿Qué es esto? Bueno, representa la introducción de Microsoft en el mundo
de las aplicaciones “in the cloud”, o aplicaciones que bien ellas mismas
completamente o bien parte de ellas (como determinados procesos, o los
datos en todo o en parte) residen en una plataforma formada por
servidores accesibles a través de Internet.

Este es un concepto que ya se conocía, pero al que Microsoft dota de una
parte esencial: la plataforma. Está claro que una necesidad tanto si una
aplicación se ejecuta en Internet (lo denominaré como “la nube” de ahora
en adelante), usa servicios de la nube, almacena todo o parte de su
información en la nube, o cualquier combinación de lo anterior, necesita
algún tipo de plataforma de aplicación. Será esta plataforma la que los
desarrolladores han de emplear para crear estas aplicaciones.

Microsoft por tanto define la plataforma Azure en tres conjuntos de
servicios, cada uno adecuado a una de estas necesidades descritas
anteriormente, y un sistema Windows para ejecutar las aplicaciones de la
nube:

- .Net Services: ofrece una infraestructura para servicios distribuidos
a aplicaciones de la nube y las basadas en escritorio.

- SQLServer Services: proporciona servicios de datos en la nube
basados en SQLServer.

- Live Services: proporcionan acceso mediante el Live Framework a
datos de las aplicaciones de Microsoft Live (Spaces, Hotmail,
Messenger…). El Live Framework también posibilita la sincronización
de estos datos entre dispositivos y desktops, búsqueda y descarga
de aplicaciones y más.

- Windows Azure: un entorno basado en Windows para ejecutar
aplicaciones y manejar datos en los servidores de los Microsoft data
centers.

Ilustración 1: La Plataforma de Servicios Azure soporta aplicaciones ejecutándose en la
nube y en sistemas locales.

.Net Services
Básicamente se trata de los servicios que se denominaban BizTalk Services,
y se tratan de una serie de servicios que permiten solucionar los problemas
de infraestructura de las aplicaciones distribuidas mediante el uso de buses
de comunicación, control de acceso y workflows.

Ilustración 2: Estructura de Azure .NET Services

Los componentes de estos .NET Services son:

- Access Control: servicio que posibilita la gestión de acceso a
recursos basada en tokens asociados a unos claims, así como el uso
de plataformas de Federación de Identidades entre empresas.
- Service Bus: permite exponer los servicios de una aplicación a
través de su URI (Universal Resource Identifier) para ser accesibles
tanto desde aplicaciones web como de aplicaciones dedicadas.
También facilita otros problemas de la red: NAT (Network Address
Translation), firewalls,…
- Workflow: es un motor basado en Windows Workflow Foundation
que ejecuta la lógica que permite el correcto funcionamiento de las
aplicaciones distribuidas, incluyendo aquellas con procesos
especialmente largos.

Por ejemplo, comentemos los siguientes usos de .NET Services:

- Imaginemos un ISV que desarrolla una aplicación usada por
diversos clientes, y que podría hacer uso de la parte de Access
Control para simplificar la gestión y acceso de sus diversos clientes
a la misma. El servicio de Access Control podría “traducir” los
diversos “claims” de los diversos usuarios (los cuales a su vez
pueden utilizar cada uno un sistema diferente de autenticación en
sus empresas) a un conjunto único de permisos consistente para el
ISV.
- O una empresa que desea poner disposición de sus filiales una
aplicación. Podría exponer esta a través de servicios web SOAP o
RESTful y registrar los servicios que ofrece la aplicación con el
Service Bus. Entonces sus filiales podrían acceder a los URIs que
este proporciona para acceder a la aplicación (adicionalmente se
podría usar Access Control para la gestión de accesos). De este
modo se evita abrir puertos en el firewall, limitando la exposición a
ataques.
- Esa misma aplicación también podría basar su funcionamiento en
un Workflow de manera que su ejecución fuese consistente entre
todas las filiales de la empresa, esperase cambios en la ejecución,
ejecutara ramas en paralelo, etc.

SQL Services
El objetivo de los SQLServices es proporcionar unos servicios basados en la
nube para almacenar y trabajar con muchos tipos de datos, desde
desestructurados a relacionales. Por el momento sólo se dispone de SQL
Data Services, pero Microsoft pondrá en el futuro más servicios bajo este
“paraguas”: reporting, analytics…

Ilustración 3: Estructura de Azure SQL Services

SQL Data Services es una “base de datos en la nube”, que permite a las
aplicaciones de escritorio y a las de “la nube” almacenar y acceder a datos
en los servidores de los Microsoft Data Centers. La ventaja es que, como
con cualquier otro servicio “nube”, una organización paga sólo por lo que
usa, aumentando o disminuyendo el uso (y el coste) según varíen las
necesidades de la organización.

Para permitir la accesiblidad plena a los datos, SQL Data Services ofrece
interfaces SOAP y RESTful que emplean protocolos estándar, por lo que su
uso no se limita a aplicaciones Windows. SQL Data Services sí está
construido sobre Microsoft SQL Server aunque para ofrecer mayor
flexibilidad emplea un modelo de datos jerárquico que no obliga a emplear
un esquema predefinido, de modo que para acceder a estos datos
emplearemos accesos RESTful o un lenguaje basando en LINQ. De este
modo SQL Data Services consigue:

- Ser más escalable, disponible (mediante replciación) y estable
(mediante balanceo de carga) que la simple ejecución de
“SQLServer en la nube”.
- Y abstraer al cliente de la gestión y diseño de su BBDD,
permitiéndole concentrarse en lo que importa: los datos.

Casos de uso podrían ser:

- Almacenamiento en SQL Data Services de información “histórica”

de datos con mucha frecuencia de cambio, como fuentes RSS.
- Una empresa que desea proporcionar una información de
producto de manera inmediata a sus clientes y distribuidores podría
emplear SQL Data Services para almacenarla y ofrecer acceso a
estos últimos mediante interfaces RESTful o SOAP.

Live Services
El uso de aplicaciones en Internet no es nuevo, Windows Live por ejemplo
dispone de una serie de aplicaciones cuyos datos e información son de
valor para sus usuarios: contactos o mensajes de Live Messenger,
direcciones y mapas de Live Maps, correo de Live Hotmail… Para permitir
que otras aplicaciones puedan acceder a esta información Microsoft ha
creado el Live Framework y dotado a Azure de Live Services.

Ilustración 4: El Live Framework permite a las aplicaciones el acceso a Live Services, con
o sin sincronización.

El componente fundamental de Live Framework es el Live Operating
Environment, que se ejecuta tanto en la nube como en desktops o
dispositivos. El acceso desde este a los datos se realiza mediante HTTP por
lo que cualquier aplicación escrita en .NET, JavaScript, Java o cualquier otro
lenguaje puede acceder a los datos de Live Services. Esta información
también puede emplear Atom o RSS para notificar cambios a las
aplicaciones. Para la gestión de Live Services, el desarrollador hará uso del

Live Services Developer Portal.

Otro de los aspectos destacables de Live Services es que los sistemas
diversos que usemos podrán agruparse en una “mesh”: desktops con
Windows Vista/XP p Macintosh OS X y Windows Mobile 6. Mediante el
Live Operating Environment los datos que indiquemos serán sincronizados
entre todos los elementos de esta “mesh”, que podrán ser aplicados según
las necesidades de los usuarios y sus aplicaciones. Por ejemplo, los
contactos de nuestro Live Messenger podrán ser sincronizados de manera
transparente con nuestro Live Hotmail (que podemos acceder desde
cualquier dispositivo con acceso a Internet) y la agenda de contactos de
nuestro dispositivo Windows Mobile 6. Además, si lo queremos el Live
Operating Environment nos permitirá exponer esta información a otros
usuarios.

Asimismo, los desarrolladores podrán crear aplicaciones Web denominadas
“mesh-enabled” que emplean tecnologías multi-plataforma, como
Microsoft SilverLight. Estas aplicaciones acceden a los datos mediante el
Live Operating Environment, de manera que se pueden ejecutar en
cualquier dispositivo de esta “mesh” y acceden siempre a los mismos datos
(sincronizados). Estas aplicaciones se ponen a disposición de los usuarios
en un catálogo de aplicaciones “mesh-enabled” y Microsoft proporcionará
a los desarrolladores tecnologías para el uso de publicidad en las mismas,
de manera que obtengan beneficios por su trabajo (este modelo de
financiación a través de la publicidad en software se va a convertir en algo
común en breve).

Como ejemplos de uso del Live Framework/Services tenemos:

- Una aplicación Java ejecutándose en Linux que accede a los datos
de contactos de Live Services, mediante HTTP.
- Una aplicación .NET que puede requerir el uso de un mesh, y que
emplea el Live Framework como un servicio de caché y
sincronización de datos, mantenidos en la nube. Cuando la
aplicación está desconectada emplea una copia local de los datos.
- El desarrollo de las denominadas “aplicaciones sociales” se ve muy
facilitado si consideramos las bondades de los Live Services y su
capacidad multiplataforma.

Windows Azure

Por último tenemos Windows Azure, que es una plataforma para ejectuar
aplicaciones Windows en la nube, incluidos sus datos.

Ilustración 5: Windows Azure proporciona servicios para almacenamiento y ejecución
de programas Windows en la nube.

Windows Azure se puede ejecutar en un número indeterminado de
máquinas, todas residentes en Microsoft Data Centers y accesibles a través
de la Web. Las aplicaciones se ejecutan en un entorno basado en Windows
e inicialmente sólo se soportan aquellas desarrolladas con el .NET
Framework. Microsoft planea soportar otras aplicaciones en
Windows Azure durante 2009.

Los desarrolladores pueden crear aplicaciones basadas en .NET como por
ejemplo aplicaciones ASP.NET y servicios Windows Communication
Foundation, mediante lenguajes como C# (u otros .NET) y herramientas
como Visual Studio 2008. Y también se pueden desarrollar procesos de
segundo plano independientes, no estamos hablando sólo de una
plataforma Web.

Tanto las aplicaciones Windows Azure como las de desktop pueden
acceder a los datos del servicio Windows Azure Storage mediante un
protocolo RESTful. Estos datos no se almacenan en SQL Server sino en una
plataforma más flexible que permite almacenar blobs (binary large objetcs)
y proporcionan colas para la gestión de información entre componentes de
Windows Azure así como también soportan tablas tradicionales.

Lógicamente los beneficios de ejecutar una aplicación en la nube y
almacenar en ella sus datos son considerables: en vez de comprar, instalar
y gestionar Sistemas Operativos, una organización puede descargar todo
este trabajo en un tercero que le proporcione ese acceso a la nube.
Además, el pago se reduce a sólo aquello que se necesita con las ventajas
que esto aporta para la gestión de picos de trabajo. Y si estas aplicaciones
se escriben correctamente, su escalado es sencillo de manera que se puede
atender a las necesidades de un negocio en crecimiento.

La gestión de estas aplicaciones se realiza mediante un fichero de
configuración, mostrado en la Ilustración anterior. Para manejar este
fichero, Windows Azure proporciona un portal web al que accederemos
con una Windows Live ID. Una vez que hemos accedido habremos de
decidir si crearemos una cuenta “hosting” para la ejecución de aplicaciones,
una cuenta “storage” para almacenar información, o una cuenta
combinada. En nuestras manos queda luego la opción de si cobraremos o
no a los usuarios de esta aplicación y de qué manera: suscripción, por uso,
etc.

Como ejemplos podemos mencionar:

- Una start-up que crea una aplicación nueva que hace uso de un
frontal Web y de una serie de servicios de segundo plano
(background), para lo que no le hará falta desarrollar la
infraestructura (por ejemplo, una aplicación tipo Facebook será
sencilla de desarrollar). Además, la flexibilidad para crecer de la
plataforma permitiría a esta start-up crecer según sus necesidades
sin un coste excesivo.
- Un ISV puede crear una versión de software como servicio (SaaS)
de una aplicación .NET que tenga desarrollada y mantenga en sus
locales, y generarla para Windows Azure. Dado que
Windows Azure proporciona en su mayoría un entorno .NET
estándar, mover la lógica empresarial de la aplicación .NET a esta
plataforma en la nube normalmente no plantea muchos problemas.
Y una vez más, crear en una plataforma existente (no tener que
desarrollar esta plataforma de soporte para la ejecución en la nube)
permite el enfoque del ISV en la lógica empresarial — lo que le
proporciona el dinero — en lugar de perder tiempo con la
infraestructura.

Windows Azure en la práctica

Veamos a continuación un ejemplo muy básico de cómo podemos
desarrollar con Windows Azure y hacer logging de nuestras aplicaciones,
para lo que nos basaremos en el primer ejercicio de los publicados por

Microsoft en la página web de Windows Azure en el denominado
“Azure Services Kit”.

Como entorno de trabajo necesitaremos lo siguiente:

- Windows Vista o Server 2008 con Internet Information Services 7.0
con soporte ASP.Net (como esto no lo activa por defecto,
recomiendo consultar la Web “Not Rocket Science” donde
tratan en este artículo de cómo se activa ASP.Net en IIS 7.0 para
poder ejecutar Azure)
- Windows® Azure™ Software Development Kit (October 2008 CTP)
- Windows Azure Tools for Microsoft Visual Studio October 2008
CTP

Efectuaremos la instalación de los Code Snippets del Azure Services Kit
para que nos sea más sencillo editar el código usado. Por ejemplo:

C:AzureServicesKitLabsBuildingWindowsAzureServicesSetupSetupEx
.cmd

(Nota: si tenemos VS2005 y VS2008 instalados, habremos de lanzar el
comando anterior como una “Herramienta Externa”, porque si no el
instalador se obstina en instalarlo sobre VS2005, lo que no nos sirve. En mi
caso, he preferido instalarlos en los “Other” Code Snippets)

Este comando lanza el instalador “Install Visual Studio 2008 Code Snippets
for the lab”. Seleccionaremos “Siguiente”, “Sí” (no están firmados
digitalmente esto ejemplos, pero sabemos que son buenos ¿no?),
“Siguiente”, “Finalizar” y una vez completado “Cerrar”.

Una vez preparados con todos los elementos instalados, ejecutaremos
Microsoft Visual Studio 2008 pero COMO ADMINISTRADOR. Desde aquí
creamos un nuevo proyecto de tipo “Cloud Service”, de nombre
“RDCompute” y nombre de la solución “Begin”

La plantilla de Windows Azure nos creará muchos elementos por defecto
en nuestra solución, que podemos ver en el Explorador de Soluciones.

El proyecto RDCompute_WebRole es una plantilla de proyecto de

aplicación Web ASP.NET estándar que ha sido modificada para trabajar con
Windows Azure. Éste contiene la mayor parte del proyecto.

El proyecto RDCompute contiene una referencia al proyecto ASP.NET, junto
con archivos ServiceDefinition.csdef y ServiceConfiguration.cscfg. El archivo
ServiceDefinition.csdef contiene los metadatos necesarios por la
infraestructura de Windows Azure para entender los requisitos de la
aplicación, como si se utilizan funciones o no. También contendrá la
configuración común que se aplica a todas las instancias. Estos valores de
configuración se pueden leer usando la API de Windows Azure. El archivo
ServiceConfiguration.cscfg le permite establecer los valores de
configuración concretos y el número de instancias que se ejecuta para cada
función.

El nodo de Roles en un proyecto de Cloud Services le permite configurar
qué funciones de los servicios se incluyen (Web, trabajador o ambas) así
como que proyectos se utilizan para estas funciones. Al agregar Roles de
configuración mediante el nodo de Roles, se actualizarán automáticamente
los archivos ServiceDefinition.csdef y ServiceConfiguration.cscfg.

Una vez creado nuestro proyecto base, modificaremos el título y el mensaje
por defecto en “default.aspx” y ejecutamos F5 para comprobar que todo
funciona
correctamente.

Podremos consultar nuestra “Development Fabric” mediante el botón

derecho del ratón sobre el icono que se nos muestra en la barra de tareas.
Si abrimos su UI podemos consultar el estado de nuestra “fábrica” (que
soporta los servicios que creemos), su registro, etc.

Como se muestra, en este caso nuestro Contrato se ha establecido en el
puerto 81 (Windows Azure se encarga de buscar uno libre a partir del
puerto 80), pero el comportamiento sería similar en caso de establecer
nuestro servicio RDCompute en cualquier otra máquina de la nube.
Lógicamente nuestra “aplicación” ASPX en este estado no es de gran
utilidad, pero hemos visto que la infraestructura de creación de servicios
para Windows Azure funciona.

Vayamos un poco más allá, y añadamos Logging a nuestra aplicación. La
gestión y configuración del logging es muy importante en Windows Azure,
ya que no tenemos la posibilidad de obtenerlo de la manera “tradicional”
de los servidores de “la nube” y es la propia plataforma la que nos va a
permitir ser capaces de registrar la actividad de estas aplicaciones así como
consultar ese registro.

Como en los ejemplos de Microsoft, añadimos un text box y un par de
botones ASP en default.aspx. No van a hacer gran cosa: el primer botón
añadirá al registro el texto que hayamos introducido en el text box, y el
segundo lanzará una excepción no gestionada que volcará por tanto su
mensaje al registro. Nuestra pantalla queda ahora así:

El código de nuestros botones ASP.Net, que podemos insertar fácilmente
haciendo uso de los Code Snippets que hemos instalado con
el Azure Services Kit, quedará como sigue:

using System;

using System.Collections;

using System.Configuration;

using System.Data;

using System.Linq;

using System.Web;

using System.Web.Security;

using System.Web.UI;

using System.Web.UI.HtmlControls;

using System.Web.UI.WebControls;

using System.Web.UI.WebControls.WebParts;

using System.Xml.Linq;

using Microsoft.ServiceHosting.ServiceRuntime;

namespace RDCompute_WebRole

{

public partial class _Default : System.Web.UI.Page

{

protected void Page_Load(object sender, EventArgs e)

{

}

protected void btnLog_Click(object sender, EventArgs e)

{

RoleManager.WriteToLog("Information", txtMessage.Text);

}

protected void btnThrowException_Click(object sender, Event
Args e)

{

try

{

object o = null;

o.ToString();

}

catch (Exception ex)

{

RoleManager.WriteToLog("Error", ex.ToString());

}

}

}

}

Ejecutando nuestra aplicación, vamos a consultar cómo quedaría el registro
de la misma tras introducir uno o dos textos y lanzar una excepción:

Como vemos, nuestro servicio es capaz de mantener una estructura de
registro tradicional para nuestra aplicación Windows Azure. Este registro lo
podremos consultar bien desde los interfaces web de Windows Azure o
bien consultándolo desde nuestra propia aplicación, de modo que
podremos actuar en consecuencia.

En definitiva Windows Azure se trata de una plataforma muy completa, y a
la vez compleja, pero que si conseguimos conocer debidamente aporta una
serie de ventajas que hacen que el futuro de nuestros desarrollos sea
radicalmente diferente, así como los beneficios que podemos obtener de
ella. La potencia de poder desarrollar aplicaciones/servicios para la Web
que se ejecuten con independencia de la estructura que los soporte libera
de inicio a las empresas desarrolladoras de software de la necesidad de
mantener ese coste, además de ofrecer un nuevo horizonte para el
desarrollo de aplicaciones, como la posibilidad para los desarrolladores de
cooperar con otros equipos de desarrollo mediante el “intercambio de
servicios”.

¡Así que ya es hora de que volemos entre la nube!

Catego CES Microsoft
rías

Tema Arquitectura

Autor Rafael Flores

Mes Noviembre

Año 2008

Boletín 11

Título Sincronización de aplicaciones MHP (Parte 2)

Texto Uso de los Stream Events en aplicaciones

Para una aplicación MHP, los objetos DSM-CC Stream Events están representados por
la clase org.dvb.dsmcc.DSMCCStreamEvent (para representar objetos Stream Event),
que es una subclase de org.dvb.dsmcc.StreamEvent (para representar Stream Event
concretos, es decir los descriptores que debe escuchar el listener).

A través del DSMCCStreamEvent nos subscribimos a determinados tipos de eventos y
definimos un listener para recibirlos. A partir de ese momento el middleware nos
notificará a través del listener los eventos concretos en el instante adecuado
mediante objetos StreamEvent

La clase DSMCCStreamEvent:

public class DSMCCStreamEvent extends DSMCCStream
{
public DSMCCStreamEvent(DSMCCObjectaDSMCCObjec
t);
public DSMCCStreamEvent(java.lang.String
path);
public DSMCCStreamEvent(java.lang.String
path, java.lan
g.Stringname);

String[] getEventList();

int subscribe(java.lang.StringeventName,
StreamEventListener l);
void unsubscribe(inteventId,
void unsubscribe(java.lang.String eventName,
}

El método getEventList() permite a la aplicación obtener una lista de los nombres de
los eventos que son válidos en ese momento.

Una vez conocida la lista de eventos, se puede elegir el evento al que te quieres
suscribir, para ello se usa el método subscribe(). Para ello, la solicitud deberá
especificar el nombre del evento al que deseas suscribirte, y el listener que será
notificado cuando se reciban los eventos. El oyente debe aplicar la
interfaz org.dvb.dsmcc.StreamEventListener.

Una aplicación puede darse de baja usando el método unsubscribe() , se usará un
constructor u otro dependiendo de si el parámetro de entrada es el nombre o el
identificador del evento.

La clase StreamEvent:

public class StreamEvent extends
java.util.EventObject
{

public StreamEvent(DSMCCStreamEvent source, long
npt, String name, int
eventId,
byte[] eventData);

int getEventId();
String getEventName();
byte[] getEventData();

long getEventNPT();
Object getSource();
}

El método getEventData() devuelve los datos específicos que se incluyeron en el
descriptor. Por otro lado, el método getSource() devuelve el objeto
org.dvb.dsmcc.DSMCCStreamEvent al que está asociado. Esto da facilidades a la hora
de anular una suscripción a un evento o suscribirse a otros eventos que puedan estar
relacionados.

Ejemplo práctico: AppSincronizada.

En este ejemplo, vamos a ver como hacer una sencilla aplicación sincronizada. Esta
aplicación, recibe Stream Events y saca por pantalla un mensaje informativo diciendo
que se ha recibido correctamente el Stream Event o los datos que lleve este, en caso
de que los lleve.

Pasamos a ver el código:

Las aplicaciones interactivas reciben el nombre de Xlets y se transmiten de forma
cíclica.

La interfaz Xlet define 4 métodos abstractos pero no los implementa (initXlet(),
startXlet(), pauseXlet() y destroyXlet()), será la aplicación la que sobrescriba estos
métodos para implementar la interfaz Xlet. Estos métodos son los encargados de
ordenar las transiciones entre estados. A continuación vemos como se han
implementado estos métodos en la aplicación:

public void destroyXlet(boolean boDestroy) throws
XletStateChangeException {
if (boDestroy){
System.out.println("destroyXlet() called");
hsScene.setVisible(false);
thStartThread = null;
prEventProp = null;
xcContext.notifyDestroyed();
} else {
System.out.println("destroyXlet() called,
but I
don't want to die, I'm waiting for
streamevents.");
}
}
La aplicación puede ser terminada en cualquier momento evocando a este método.
En nuestro caso, el método es llamado por la aplicación pero también podría llamarlo
el Application Manager (este se encarga de manejar los estados de cada aplicación y
hacer de puente a los recursos del Set-Top Box).

public void initXlet(XletContext xcContext) throws
XletStateChangeException
{
this.xcContext = xcContext;
boFirstStart = true;
System.out.println("The initXlet() method
has
been called. Our Xlet context is " +
xcContext +
" Date " + (new Date()).getTime());
}
En este método se inicializa el XletContext, este hace de puente entre el Xlet y el
Application Manager. Permite que el Application Manager sea correctamente
notificado de cualquier cambio en los estados de las Xlets.

public void pauseXlet()
{
hsScene.setVisible(false);

}
Cuando se llama a este método, se libera la pantalla haciendo invisible la escena de la
aplicación.

public void startXlet() throws
XletStateChangeException
{
if (boFirstStart)
{
System.out.println("The startXlet()
method
has been called to start the Xlet
for
the first time.Hello, world!" + "
Date "
+ (new Date()).getTime());
thStartThread = new Thread(this);
thStartThread.start();
}
}
En este caso, se crea el hilo de la aplicación y se lanza. Para que esto sólo se haga una
vez nos aseguramos con la variable boFirstStart. La aplicación solo se lanza una vez,
después estará corriendo hasta que queramos terminar con la aplicación, ya que para
que pueda recibir los Stream Events debe estar corriendo.

Después tenemos el método run() en el que se describe lo que va a hacer la
aplicación una vez que se haya iniciado.

public void run()
{
if (boFirstStart)
{
prEventProp =
PropertyCharger("data/event.properties"
);
uerRepos = new UserEventRepository("Repos");
uerRepos.addAllColourKeys();
uerRepos.addAllArrowKeys();
getResources();
boFirstStart = false;
if (prEventProp != null)
{
dsoObject = new DSMCCObject
(prEventProp.getProperty("EventPath")
);
try {
dsoObject.synchronousLoad();
}
catch (InvalidFormatException ife) {

ife.printStackTrace();
}
catch (MPEGDeliveryException mpegde) {
mpegde.printStackTrace();
}
catch (ServerDeliveryException sde) {
sde.printStackTrace();
}
catch (InvalidPathNameException ipne) {
ipne.printStackTrace();
}
catch (NotEntitledException nee) {
nee.printStackTrace();
}
catch (ServiceXFRException sxe) {
sxe.printStackTrace();
}
catch (InterruptedIOException iioe) {
iioe.printStackTrace();
}
System.out.println("Path al dsoObject:
"+dsoObject.getAbsolutePath());
try {
dseEvent = new
DSMCCStreamEvent(dsoObject);
}
catch (NotLoadedException nle)
{
nle.printStackTrace();
try
{
destroyXlet(true);
}
catch (XletStateChangeException
xsce)
{
xsce.printStackTrace();
}
return;
}
catch (IllegalObjectTypeException iote)
{
iote.printStackTrace();
try
{
destroyXlet(true);
}
xsce)
{

}
return;
}
catch (Exception e){
try
{
destroyXlet(true);
}
xsce)
{
}
return;
}
try
{
iSubscribedEventID=dseEvent.subscr
ibe
(prEventProp.getProperty("EventN
ame"),
this);
}
catch (UnknownEventException uee)
{
uee.printStackTrace();
try
{
destroyXlet(true);
}
xsce)
{
}
return;
}
catch (InsufficientResourcesException
ire)
{
ire.printStackTrace();
try
{
destroyXlet(true);
}
xsce)
{
}
return;

}
catch (Exception e)
{
try
{
destroyXlet(true);
}
xsce)
{
}
return;
}
}
else
{
try
{
destroyXlet(true);
}
catch (XletStateChangeException xsce)
{
}
return;
}
Date dtNow = new Date();
System.out.println("Starting countdown of 10
seconds"+
(new Date()).getTime());
while (new Date().before(new
Date(dtNow.getTime()+10000))){
}
pauseXlet();
}
else
{
return;
}
}
Se cargan las propiedades del Stream Event (en este caso lo llamamos “evento”) en el
fichero de propiedades.

Con la función “dsoObject.synchronousLoad()” se hace la carga del objeto DSM-CC
que previamente hemos guardado en la variable dsoObject (dsoObject = new
DSMCCObject(prEventProp.getProperty("EventPath"))) . Una vez hecho esto ya
podemos guardar el objeto en la variable dseEvent como un objeto DSM-CC Stream
Event (dseEvent = new DSMCCStreamEvent(dsoObject)).

Por último, nos suscribimos al Stream Event con la función “suscribe” que ya
comentamos al inicio de este artículo
(iSubscribedEventID=dseEvent.subscribe(prEventProp.getProperty("EventName"),
this)) , es aquí donde hacemos uso de la variable.

Como podemos ver, en esta aplicación se hace uso de un fichero de propiedades,
pero este se podría eliminar y definir las propiedades directamente como constantes.
Las dos soluciones son igualmente válidas y se deja su elección a las preferencias del
programador.

En el método getResources() lo que hacemos es crear la escena donde se represente
el interfaz gráfico de la aplicación.

public void getResources()
{
HSceneFactory hsfFactory =
HSceneFactory.getInstance();
HSceneTemplate hstTemplate = new
HSceneTemplate();
hstTemplate.setPreference(
HSceneTemplate.SCENE_SCREEN_DIMENSION,n
ew
org.havi.ui.HScreenDimension(1,1),
HSceneTemplate.REQUIRED);
hstTemplate.setPreference(
HSceneTemplate.SCENE_SCREEN_LOCATION,
new org.havi.ui.HScreenPoint(0,0),
HSceneTemplate.REQUIRED);
hsScene =
hsfFactory.getBestScene(hstTemplate);
rRect = hsScene.getBounds();
System.out.println("The startXlet() method
has
gotten the bounds of the hsScene " +
(new
Date()).getTime());
setBounds(rRect);
setVisible(true);
hsScene.add(this);
hstText = new
HStaticText(prEventProp.getProperty
("InitialText"), 100,350,520,150, new
Font("Tiresias",Font.PLAIN,26),Color.bl
ack,
new DVBColor(255,172,255,128),new
HDefaultTextLayoutManager());
hstText.setVisible(true);
hsScene.add(hstText);

hstText.setBackgroundMode
(HStaticText.BACKGROUND_FILL);
hsScene.setVisible(true);
emManage.addUserEventListener(this,
uerRepos);
System.out.println("The startXlet() method
has
added the scene and set it visible " +
(new
Date()).getTime());
this.requestFocus();
Para crear la escena se usa la clase HSceneFactory (HSceneFactory hsfFactory =
HSceneFactory.getInstance()). Cuando ya tenemos creada una escena vacía le
indicamos nuestras preferencias utilizando las plantillas HSceneTemplate.

En el método descrito a continuación se crea el fichero de propiedades donde
guardaremos información relativa al Stream Event, como puede ser el path, el
nombre, … De esta forma cada vez que necesitemos alguna de estas propiedades la
tomaremos directamente de aquí.

public static Properties PropertyCharger(String
txProperties)
{
Properties prProperties = new Properties();
InputStream isGeneral = null;
try
{
isGeneral = new FileInputStream((new
File(new
File(txProperties).getCanonicalPath()))
);
prProperties.load(isGeneral);
}
catch (IOException e)
{
System.out.println("Input/Output error while
charging properties: " + e.toString() +
(new
Date()).getTime());
}
finally
{
try
{
if(isGeneral!= null)
{
isGeneral.close();
}

}
catch(IOException e)
{
System.out.println("Input/Output error
in
finally when we wanted to close
the
InputStream: " + e.toString() +
(new
Date()).getTime());
}
}
return prProperties;

Este último método implementa la interfaz del Stream Event Listener. Es decir,
gestiona la recepción de los descriptores de Stream Events.

public void receiveStreamEvent(StreamEvent seEvent)
{
int iEventID = seEvent.getEventId();
System.out.println("Event recieved. ID = " +
iEventID);
if (iEventID == iSubscribedEventID)
{
byte[] arrbyDatos = seEvent.getEventData();
if (arrbyDatos != null){
for (int i = 0; i <
arrbyDatos.length; i++)
{
System.out.println(arrbyDatos[i]);
}
if (arrbyDatos.length > 0)
{
hstText.setTextContent(new
String(arrbyDatos),
HStaticText.NORMAL_STATE);
} else {
hstText.setTextContent(new
String("He
recibido un Stream Event pero
no
datos"),
}
} else {
hstText.setTextContent(new String("He
recibido un Stream Event pero no
datos"),

}
hstText.repaint();
hsScene.setVisible(true);
Date dtNow = new Date();
System.out.println("Starting countdown of
10
seconds "+ (new Date()).getTime());
while (new Date().before(new
Date(dtNow.getTime()+10000))){
}
pauseXlet();
}
}

En este método se gestiona la recepción de los descriptores de Stream Events. En
primer lugar, se comprueba si la aplicación esta suscrita a ese Stream Event, si no es
así se ignora el descriptor y la aplicación no hace nada. Si por el contrario, la
aplicación si que está suscrita, se reacciona a la llegada del descriptor.

Primero se comprueba si contiene datos, y si es así se guardan en la variable
arrbyDatos. A partir de aquí se pueden dar dos casos:

 El descriptor contiene datos: se muestran los datos por
pantalla.

 El descriptor no contiene datos: se saca por pantalla el
siguiente texto: "He recibido un Stream Event pero no datos".

Después de esto se llama al método pauseXlet()que pasa el Xlet al estado de pausa.

ENLACES DE INTERES:

 http://www.mhproject.org/index.php/mhproject.php/2006/11
/10/ique_es_una_xlet_ipara_que_sirven

 http://en.wikipedia.org/wiki/Xlet

 http://www.xlet.net/article/21/xlet-tutorial-for-beginners

 http://www.interactivetvweb.org/tutorials/mhp/xlet_introducti
on

Categ CES OpenSouce/Java
orías
Tema Desarrollo

Autor Elena Gadea

Mes Noviembre

Año 2008

Boletí 11
n

Título 2001 + 7.
Texto „Cualquier tecnología lo suficientemente avanzada es
indistinguible de la magia.‟ (Tercera Ley de Clarke.)
„Esto es magia.‟ (José Bono, presidente del Congreso de los
Diputados al recibir los Presupuestos Generales del Estado en
una memoria USB.)

Arthur C. Clarke falleció el pasado 19 de marzo. Está
considerado como uno de los popes de la ciencia ficción. Este
año se cumple el 40º de la proyección de la película2001: una
odisea del espacio, basada en un relato suyo, „El centinela„.
Pronto se convirtió en un filme de culto entre el público, en
sus dos vertientes: por un lado convertirse en un referente y,
por otro, ser ininteligible y no atreverse a confesarlo.

Uno de los personajes de dicha película es HAL 9000: HAL es
el acrónimo de Heuristically programmed ALgorithmic
computer (computador algorítmico heurísticamente
programado), aunque muchos detectaron que H-A-L son las
letras inmediatemente anteriores a I-B-M. HAL es capaz de
jugar (y ganar) al ajedrez a los miembros de la nave
Discovery, amén de controlar la misma y de conversar con los
astronautas.

Hoy, en el año 2001 + 7, lo primero ya está conseguido y es
un hecho que muchos ordenadores controlan el
comportamiento de ciertos dispositivos. La cuestión de que
una máquina converse con las personas es todavía un reto.

Es en estos retos cuando la Ley de Clarke citada arriba
empieza a tomar sentido: a todo aquello que no entendemos
le intentamos de dar una explicación y si no es así empieza a
tomar el carácter de „mágico‟. Ahora bien: ¿hay alguna
tecnología actualmente que la podamos calificar así? La
respuesta es que no he sabido dar con ninguna.

En éstas estaba cuando leyendo en diagonal un mailing que
recibo con referencias bibliográficas, de ésas que nunca

tendré tiempo de leer, un título me ha golpeado en la retina:
„Hypercomputation: computing beyond the church-turing
barrier„
¿Hipercomputación? Uhu... ¿Computando más allá del límite
de Church-Turing? Doble uhu... Esto tiene la mitad de los
ingredientes para convertirse en un libro de culto: no
entiendo nada.

He recurrido entonces a la Wiki para intentar desbrozar este
bosque: „Un hipercomputador computa funciones que son
incomputables por una máquina de Turing. Esta computa
funciones o números, resuelve problemas o realiza tareas que
no pueden ser computados o resueltas por una máquina de
Turing (MT).‟

De acuerdo: lo que haría un hipercomputador es
ejecutar/resolver funciones que no podría hacer una máquina
de Turing. Pero yo creo recordar que precisamente una
máquina de Turing es un modelo matemático que computa
todo tipo de problemas y que los que no computa, es por eso
precisamente: porque no son computables.
Esto es lo que viene a decir la Tesis de Church-Turing,
referenciada en el título del libro: „Todo lo que es computable
es Turing-computable.‟

Pero aquí aparece algo, el hipercomputador, que va a
calcular, resolver, computar, lo que la máquina de Turing no
puede hacer... A mí me suena a magia.
Pero esta respuesta a lo que realmente suena es a „No te has
enterado de nada‟, así que habrá que indagar algo más.
Parece ser que en 2001 (no podía ser en otro año) alguien
llamado Tien Kieu logró definir un algoritmo que podría
ejecutarse en un hipotético hipercomputador pero no en uno
al uso como el que estoy utilizando ahora para escribir esto o
tú para leerlo, que siguen el modelo de una máquina de
Turing.

Dicho algoritmo resolvería el Décimo problema de Hilbert, que
dice ni más ni menos: „Dada una ecuación diofántica con
cualquier número de incógnitas y con coeficientes numéricos
racionales enteros: idear un proceso de acuerdo con el cual
pueda determinarse, en un número finito de operaciones, si la
ecuación es resoluble en números racionales enteros‟. Aún así
parece ser que hay respuestas que lo refutan.

El caso es que si a alguien le hubieran dicho en 1968 que
podría comprar las entradas de cine para ver la última
película de Kubrick desde un teléfono portable, sin cable, que
cabe en la palma de una mano, habría dicho: „Imposible: eso
es magia.‟

¿Qué pensará Clarke de todo esto, donde quiera que ahora
esté?

Si quieres enviar algún comentario o sugerir temas a tratar en otros artículos, escribe a:
curtasun[simboloArroba]cein.es

Categorías General
Tema Varios
Autor Carlos Urtasun
Mes Noviembre
Año 2008
Boletín 11

Título Proyecto piloto TDT: parte 3: fase 1
Texto Continuamos con el artículo anterior en el que se completará
el periplo por la fase 1 describiendo lo que fueron los
procesos de desarrollo de los siguientes módulos:
 Lanzadera
 Servicios de Hacienda.
Descripción proceso Lanzadera:

Este proceso aparentemente sencillo en primera instancia
también tuvo sus dificultades. La lanzadera es una aplicación
que permite el acceso a un número determinado de
servicios. La primera decisión a tomar fue el tipo de
lanzadera a desarrollar:

Opción 1:

Lanzadera que presenta la lista de servicios disponibles
superpuesta a la emisión de televisión y que ocupa un
espacio mínimo. Es decir, se da prioridad a la emisión de
televisión frente a la aplicación de la lanzadera. Es una
opción menos intrusiva.

Opción 2:

Lanzadera que ocupa el tamaño completo de la pantalla de
televisión, a modo de portal, relegando a un segundo plano
la emisión de ese momento. Se trata de una opción más
intrusiva puesto que se puede perder la emisión actual. Esto
no se recomienda, por lo que se evita superponiendo dicha
emisión en un pequeño cuadro ubicado en algún punto de la
pantalla. Esta segunda opción permite un aprovechamiento
mayor del espacio, que ya de por si es limitado.

Finalmente, se decidió realizar la segunda opción por ese
mejor aprovechamiento del espacio.

Así pues, se empezó a trabajar en una propuesta más
concreta de lanzadera. No obstante, el anuncio de la gala del
3 de abril, nos hizo ser conscientes de una cuestión muy
importante que habíamos pasado por alto hasta el momento,
el resto de entidades propietarias del canal de datos de la
TDT: Canal 4 y Canal 6. Se trata de un canal de datos
compartido entre estas dos entidades y el Gobierno de

Navarra, con lo que esa aplicación de Lanzadera debería
representar a las 3 entidades y dar acceso a todos los
posibles servicios.

La solución consistió finalmente en diseñar una lanzadera,
del tipo 2, en la que estuvieran representadas estas 3
entidades y que diese acceso, para el caso de Gobierno de
Navarra, a otra lanzadera, también del tipo 2, que serviría
de portal, es decir, la lanzadera planteada en primera
instancia. Las siguientes imá genes quizás esclarezcan más
la solución elegida:

Lanzadera común

Portal Gobierno de Navarra: el cuadrado rectangular marca
el área de visionado, fuera de este margen y dependiendo de
modelos, no se asegura que se visualice la información.

Cómo se puede apreciar, a esta altura se establecieron
algunos elementos que el resto de aplicaciones irían
heredando:

 Cabecera con el logotipo del Gobierno de Navarra
 Menú superior: en este caso usado para el acceso a
todos los servicios.
 Posición y tamaño de la emisión de televisión: zona
inferior izquierda.
 Funciones asociadas a los cuatro botones de colores
que suele tener los mandos a distancia:

Por coherencia, esta asociación de botón y funcionalidad se
arrastraría en todas las aplicaciones siguientes. Con la
salvedad de que en la Lanzadera común, no se cuenta con
todas las posibilidades, dado que algunas no tenían sentido.
Esta asociación de botón y funcionalidad fue la siguiente:

 Botón rojo: salir de la aplicación y volver a la emisión
de TV.
 Botón verde: cambio de idioma.
 Botón amarillo: acceso a una página de ayuda.
 Botón azul: acceso al menú superior de la aplicación.

El contenido informativo incluido en la lanzadera y
denominado “Así es navarra”, consistió en información
general acerca de la comunidad navarra y sus instituciones.
El aspecto fue este:

Aquí, vuelven a darse otras características de diseño que
marcarían las aplicaciones siguientes por desarrollar:

 Un área superior para la cabecera y el menú que, a
diferencia del portal del Gobierno de Navarra, tan solo
permitía reiniciar el servicio actual o bien volver al
portal para acceder a otros servicios. Es decir, no se
mostraba la lista completa de servicios, esto hubiese
supuesto modificar el menú de todas las aplicaciones
en emisión cada vez que se introdujese un nuevo
servicio.
 Un área donde se despliegan las secciones cada
servicio en particular.
 Otra área donde se visualizan los datos.

Esta será, en mayor o menor medida, la disposición de la
información del resto de aplicaciones MHP.

Por simplicidad y dado que tampoco iban a sufrir constantes
cambios, todos los contenidos de texto eran estáticos. No en
un sentido estricto de la palabra, si no en el sentido de que
debían ser modificados a mano en caso de necesitarse. La
inclusión de un gestor de contenidos para TDT quedaba fuera
del alcance de este proyecto ya que suponía prácticamente
el esfuerzo y dedicación de un proyecto completamente
nuevo. Como se irá viendo, cada servicio marcaba las
necesidades de información, su inserción y mantenimiento

de una manera u otra

A finales de febrero ya se contaba con un diseño de la
lanzadera para ser implementado y a finales de marzo el
desarrollo estaba completado, a tiempo para el 3 de abril.

La lanzadera su había configurado de modo que estuviese en
auto-start, esto es, que tras un cambio al canal de televisión
al que va asociado el canal de datos (en este caso, Canal 4 o
Canal 6) por parte del tele-espectador esta aplicación se
arrancase de forma automática. Dado que se trataba de una
lanzadera a pantalla completa, se trataba de una acción muy
intrusiva desde el punto de vista del usuario, pero no fue
hasta finales de marzo que se planteó realizar un cambio de
modo que el usuario tuviese la opción de entrar en la
Lanzadera o no. Cambio que no se produjo hasta después de
la gala por la falta de recursos y que se tradujo en lo
siguiente:

De este modo el usuario no perdía la emisión de televisión
de ese momento y tenía la opción si así lo deseaba de
acceder a la Lanzadera. En cualquier caso, este desarrollo se
realizó con posterioridad a la gala del 3 de abril.

Posteriormente, con más calma se hizo una propuesta de
diseño nueva para el portal del Gobierno de Navarra en TDT.
Este daba protagonismo a los servicios y el acceso a los
mismo, realizando un mejor aprovechamiento del espacio:

Descripción proceso Servicios Hacienda:

El desarrollo de los servicios de Hacienda para la campaña
de la Renta resultaron más complicados. Se trataban de
aplicaciones que hacían uso del canal de retorno para la
petición de datos personalizados para cada usuario mediante
una identificación.

No fue hasta enero del 2007 prácticamente, cuando se tomó
la determinación de realizar dos servicios de Hacienda
relacionados con la campaña de la Renta:

 Servicio “Cuando”: servicio por el cual se notificaba al
contribuyente cuando se produciría la devolución de
Hacienda, si ese era el caso, y de cuanto sería el
importe. Por descarte, este mismo servicio podía
indicar, en función del valor positivo o negativo del
importe, si no se producía ninguna devolución, es
decir, a pagar por el contribuyente a Hacienda.
 Servicio “Enviada”: este otro servicio indicaba si se
había enviado el borrador de la declaración por correo
postal al contribuyente, y si no se había realizado, las
causas.

La decisión por estos dos servicios se basó principalmente en
la simplicidad, en la sencillez del interfaz y en la existencia
de servicios web que abstrayeran la petición de la
implementación del sistema de back-office.

No obstante, no fue prácticamente hasta febrero que no se
pudo empezar con el análisis de dichos servicios dado que no

se contaba aún con la consultora experta en TDT. Fue, por
tanto, a lo largo de febrero cuando fuimos, a través de
reuniones con Hacienda y Azertia, adjudicataria de los
desarrollo de la campaña de la RENTA, realizando la captura
de requisitos y el análisis técnico de la solución.

Tras redactar el documento de requisitos, se identificó el
siguiente escenario (no detallaré los casos de uso porque
este artículo sería interminable):

Diagrama de casos de uso servicio “Cuando”

Diagrama de casos de uso servicio “Enviada”

A partir de este momento se debían identificar las
comunicaciones entre la aplicación MHP en TDT y los
servicios web en el back-office del Gobierno de Navarra. En
dicha comunicación debían establecerse protocolos (SOAP =

Simple Object Access Protocol, protocolo estándar que define
cómo dos objetos en diferentes procesos pueden
comunicarse por medio de intercambio de datos XML),
parámetros y formato de la información (DNI, fechas,
cadenas de texto, etc). Era obvio que muchos de estos
aspectos venían determinados por los propios servicios web
ya existentes. Para este análisis se contaba con las
especificaciones WSDL (Web Services Description Language,
un formato XML que se utiliza para describir servicios Web)
de dichos servicios web.

Cómo se puede observar en los diagramas, los procesos
determinaban varias peticiones por separado:
 Una primera identificación del usuario a través del DNI
y un número PIN que proporcionaba Hacienda a
través de correo postal.
 Una segunda petición para la obtención de la
información requerida.
 En algunos casos una tercera petición para
información adicional dependiente de la respuesta
anterior.

Esto en TDT, dado que el canal de retorno habitual de
comunicaciones es el módem ralentizaba mucho las
peticiones con lo que en siguientes conversaciones con
Azertia, se propuso la posibilidad de crear otros dos servicios
web específicos para TDT que actuasen a modo de fachada y
permitiesen agrupar en una sola petición la identificación de
usuario y la petición de información. Se trataba de un
desarrollo pequeño puesto que delegaban en la lógica de los
ya existentes, con lo que fue aceptado y el trabajó asumido
por Azertia.

En esta situación, por tanto, se tenía lo siguiente:
 Servicio “Cuando”: en la primera solicitud el
contribuyente (usuario) se identifica y realiza la
petición de datos al servicio web. La
respuesta consistía en un código y en la información
en caso de existir. Con el fin de evitar una segunda
solicitud que tradujese dicho código (en caso de no
existir información a mostrar), se insertó la
información de los códigos en la propia aplicación MHP
de modo que supiese identificar el código dado por el
servicio web.
 Servicio “Enviada”: en este caso la primera solicitud
también identificaba al contribuyente y realizaba la
petición de datos. De no obtenerse una respuesta

positiva, es decir, de no haberse enviado al hogar la
propuesta de la declaración por parte de Hacienda,
existe una segunda solicitud que pide los motivos de
ese “no” envío. De igual forma, para evitar esta
segunda solicitud, en la primera petición, se mandaban
los códigos de los motivos en caso de no haberse
enviado la declaración y se insertaban, de igual forma,
la información de los códigos en la aplicación MHP.

Tras los desarrollos faltaba una parte muy importante, las
pruebas. Aquí había que conjugar una serie de aspectos. Por
un lado, el proceso que marcaba Hacienda y el departamento
de sistemas en la puesta en producción de los desarrollos.
Por otro lado, la coordinación con Azertia dado que en
paralelo ellos debían realizar las adaptaciones de los
servicios web a probar y por último la existencia de datos
con los que realizar las pruebas.

El proceso marcado por el departamento de sistemas
establecía 3 niveles:

 Desarrollo
 Pre-producción
 Producción

La aplicación debía probarse en cada uno de estos niveles y
no pasaba al siguiente hasta que en el anterior las pruebas
no hubiesen sido satisfactorias. Cada nivel requerían de
condiciones de acceso diferentes. Para el caso de los dos
primeros se precisaba de canal directo, en este caso, desde
CEIN a la red corporativa del Gobierno de Navarra.
Casualmente CEIN ya contaba con un acceso a dichos
sistemas, tan solo hubo que configurar los permisos y el
encaminamiento, no sin alguna que otra dificultad. Para las
pruebas en producción, aparentemente, no había mayor
dificultad puesto que se podían realizar a través de Internet
por medio de la conexión módem del decodificador, no
obstante, había que contar con el hecho de que la
comunicación en este caso estaría cifrada por un certificado
de servidor, escenario que no se podría probar hasta llegar
al paso de producción.

Por otro lado, el desarrollo de la adaptación de los servicios
web se iba a realizar con posterioridad al resto de desarrollos
que la campaña de la Renta precisaba ese año, lo cual
prácticamente no dejaba margen para las pruebas. Por esa
razón, se empezó a trabajar contra los servicios web

existentes sabiendo que posteriormente habría que realizar
los cambios y adaptaciones necesarios para los nuevos
servicios web.

Por último, tampoco se contaba con un número suficiente de
datos de prueba que que abarcase todos los escenarios
posibles.

Todo esto se tradujo en un proceso de pruebas bastante
traumático.

A finales de abril los desarrollos estaban terminados, las
pruebas habían sido satisfactorias y se pudo iniciar la
comunicación con al radiodifusor Abertis para poner en
producción estos servicios dentro del plazo acordado, a
finales de abril.

A continuación se muestran algunas capturas de pantalla del
resultado:

Identificación

Servicio “Enviada”

Servicio “Enviada”

Servicio “Cuando”



Conclusiones:

En esta primera fase se juntaron el arranque y configuración
del proyecto con la ejecución y desarrollo del mismo. Por
otro lado, las circunstancias obligaron a empezar por los
servicios más complejos, los de Hacienda. Todas estas
circunstancias unidas a la fuerte presión en fechas, dieron
como resultado una fase bastante caótica. No obstante,
afortunadamente todo salió de forma satisfactoria.

La presión en fechas impidió que el equipo local pudiese
participar de forma activa en los primeros desarrollos, lo cual
hubiese sido muy beneficioso para ellos. En cualquier caso,
aún quedaba mucho camino por recorrer para el proyecto y
múltiples oportunidades para el equipo.

Esta fase en definitiva, se caracterizó por el amplio número
de decisiones que se tuvieron que tomar sobre la marcha
con muy poco margen de tiempo, decisiones que en muchos
casos marcarían el resto del proyecto.

El siguiente artículo comenzará con la segunda reunión de
comité donde se concluían los trabajos desarrollados en la
primera fase y se proponía el planteamiento de la siguiente.

Categorí CES OpenSouce/Java
as
Tema Varios
Autor Raúl Sanz de Acedo
Mes Noviembre
Año 2008
Boletín 11

Título Introducción a Adobe Flex (I).

Texto Una de las palabras más de moda en el desarrollo de aplicaciones para Internet
es RIA (Rich Internet Applications). Este tipo de aplicaciones intentan mejorar
uno de los aspectos a menudo descuidados en las aplicaciones web: la llamada
“experiencia de usuario”. Para ello se utilizan controles avanzados, se obtienen
del servidor únicamente los datos necesarios (evitando así recargas innecesarias
de las páginas), etc. En definitiva se mejora la usabilidad de las aplicaciones.

Veamos un ejemplo para aclarar estos términos. A continuación se incluyen dos
enlaces a sitios web donde podemos elegir una televisión LCD:

Vemos que en la web de LG el filtrado de los modelos es tradicional, recargando
la página para cada uno de los tamaños de televisión. En cambio, en la de Philips,
contamos con un filtro más sofisticado, y que recarga únicamente los resultados
en función de los cambios realizados. Permite, por ejemplo, filtrar los modelos
entre 26 y 37 pulgadas, o los valores que deseemos. Éste es un ejemplo sencillo,
pero en aplicaciones más complejas las diferencias en usabilidad y mejora de
experiencia de usuario se hacen más evidentes.

Un vistazo general a la plataforma Flex

Una de las tecnologías más importantes para el desarrollo de RIAs es Flex, de
Adobe. Su desarrollo, inicialmente por parte de Macromedia, cuenta con varios

años de antigüedad, y se apoya en el reproductor de Flash, ampliamente
extendido.

El siguiente esquema muestra, de forma simplificada, las piezas que componen
la plataforma Flex. Por un lado, las tecnologías que se utilizan en la parte de
servidor, por otra las del cliente, y finalmente los mecanismos de transferencia
de datos entre ellos. No pretende ser una descripción rigurosa de todos los
elementos, sino una breve introducción a Flex y a los elementos y tecnologías
más destacados.

Cliente

MXML/ActionScript 3.0
El desarrollo de clientes en Flex se basa en MXML y ActionScript 3.0. Realizando
una analogía con el desarrollo web tradicional, MXML haría las veces de HTML, y
ActionScript las de Javascript. MXML (Multimedia eXtensible Markup Language)
es un lenguaje basado en etiquetas que define los componentes que forman el
interfaz. Existen herramientas que generan este código de forma visual,
como Flex Builder.

El lenguaje de programación que apoya el desarrollo de los clientes Flex es
ActionScript. Su versión 3.0 supuso importantes mejoras respecto de las
anteriores versiones en cuanto a orientación a objetos, manejo de excepciones,
espacios de nombres, etc.

Cairngorm/PureMVC
Con Flex es posible realizar muchos tipos de aplicaciones, desde las más sencillas
hasta las más complejas. En este último caso, es imprescindible tener en cuenta
conceptos como la escalabilidad y el posible crecimiento de estas aplicaciones,
así como la optimización de los equipos de desarrollo, de forma que varios
programadores puedan trabajar paralelamente en el desarrollo. Para ello,
existen frameworks o arquitecturas sobre las que basar los desarrollos en Flex,
basados en patrones cuyo funcionamiento está probado. Entre ellos, los más
destacado son Cairngorm, un proyecto abierto de Adobe, yPureMVC, otro
proyecto opensource desarrollado para varios lenguajes de programación, entre
ellos ActionScript3.0.

Servidor

PHP,Java,…
Flex permite a los clientes acceder al servidor de varias formas, realizando
peticiones HTTP, consumiendo servicios web o accediendo a objetos de forma
remota. De esta forma, en el servidor podemos tener una aplicación realizada en
PHP, sobre J2EE o utilizando otras tecnologías, siempre que devuelva los datos
en un formato que el cliente Flex sea capaz de tratar.

BlazeDS, LiveCycle Data Services, AMFPHP
Una de las formas que tiene Flex de acceder a los datos del servidor es mediante
la utilización de objetos remotos. Esto permite acceder directamente a métodos
del servidor, desarrollados en Java o PHP por ejemplo. Las tecnologías más
destacadas que permiten esto son:

- BlazeDS: proyecto opensource de Adobe que permite la llamada a
objetos remotos y servicios de mensajería. Funciona sobre un servidor
Java EE.

- LiveCycle Data Services: similar al anterior, también de Adobe, pero
que cuenta con una versión comercial con mejoras para el manejo
avanzado de datos y rendimiento. También utiliza Java EE.

- AMFPHP: acceso remoto a aplicaciones realizadas en PHP.

Comunicación Cliente-Servidor

La transferencia de datos entre cliente y servidor se puede realizar de varias
formas, como veíamos anteriormente. El cliente Flex puede recibir los datos en
XML, o en JSON (JavaScript Object Notation), y puede acceder a servicios web.

Para optimizar el rendimiento en Flex, se puede utilizar AMF (Action Message
Format), un formato binario que optimiza las comunicaciones cliente-servidor
minimizando el volumen de datos transferido, y que se utiliza en las tecnologías
BlazeDS, LiveCycle Data Services y AMFPHP.

Otras opciones para el desarrollo de RIA

Flex no es la única opción para el desarrollo de RIAs. Podemos dividirlas en dos
grandes grupos, aquellas que requieren un reproductor en el cliente, y las que
no lo necesitan. En este último caso, se hace un uso intensivo de Javascript y
Ajax para obtener componentes complejos, optimización de acceso al servidor, e
incluso animaciones. Existen ventajas y desventajas para cada una de las
opciones: en el primer caso, obligamos al cliente a tener un reproductos para
hacer funcionar la aplicación, algo que no ocurre con la segunda opción, que, sin
embargo, se encuentra con el problema de la compatibilidad con distintos
navegadores.

Con reproductor en el cliente:

- Flex, de Adobe.

- JavaFX, de Sun Microsystems.

- Silverlight, de Microsoft.

- OpenLaszlo

Sin reproductor en el cliente:

- ZK

- GWT-ExtJS.

- Dojo

- Qooxdoo

- jQuery

- …

Flex en acción

Existen multitud de ejemplos de aplicaciones en Internet desarrolladas
utilizando Flex. Algunas de las más importantes, son la nueva versión
de Metalinkde Oracle o la web de Philips que veíamos en el primer ejemplo.

Recientemente se ha publicado una herramienta llamada Tour de Flex, se trata
de una aplicación que muestra las funcionalidades más importantes de la
plataforma, con ejemplos y código fuente. Para aquellos que deseen ver qué se
puede hacer con Flex y cómo hacerlo, es sin duda un buen punto de partida.

En la segunda parte de este artículo, publicaremos un tutorial paso a paso para
crear un proyecto Flex y probar su funcionamiento con una aplicación sencilla.

Referencias

- Adobe Flex

- Made In Flex

- Tour de Flex

- BlazeDS

- LiveCycle Data Services

- AMFPHP

- Flex Showcase

Categor General
ías
Tema Desarrollo

Autor Miguel Bacaicoa

Mes Noviembre

Año 2008

Boletín 11

Título XML, RDFS, Ontologías: Camino a la Web semántica
Texto Propongo considerar la pregunta: “¿Pueden pensar las máquinas?”. Ésta
debería empezar con las definiciones del significado de los términos
“maquina” y “pensar”.
Alan Turing, Computing Machinery and Intelligence (1950)
"La Web semántica es una extensión de la Web actual en la que la
información se da con un significado bien definido, que permitirá que los
humanos y los ordenadores trabajen mejor en cooperación”
The Semantic Web, Tim Berners-Lee, James Hendler y Ora Lassila,
Scientific American (Mayo 2001)

Actualmente, la Web actual se compone de una gran cantidad de páginas
estáticas y otras dinámicas. Toda la cantidad de información definida por
estas páginas, hacen que buscar conceptos dentro de ellas sea complicado,
lo que hace que la Web deba tender a ser “inteligente”, esto es, que existan
máquinas que “comprendan” la información que existe y extraigan la que
les parece relevante a los usuarios. Ahora mismo, con
los buscadores actuales, no se pueden hacer búsquedas “inteligentes”, es
decir, de acuerdo a las preferencias e intenciones de un usuario. Los
resultados que se muestran tienen carácter estadístico y dependen de los
creadores de las páginas (uso adecuado de etiquetas meta, enlaces,
etc.). Así, si se busca por ejemplo un número de teléfono para ver a quién
pertenece, no se obtienen datos o si se hacen preguntas complicadas los
datos mostrados no siempre tienen que ver con la respuesta.

Figura 1 Ejemplo de Web actual con recursos enlazados.

Esta serie de carencias pretende arreglarlas la Web Semántica o Web 3.0,
para ello se pueden emplear distintas tecnologías
como XML, RDFS uontologías. En ella, estos datos serían más fáciles de
encontrar, pues los conceptos están relacionados entre sí, no a través de
enlaces sino a través de relaciones lógicas.

Figura 2 Ejemplo de Web Semántica. La información está
conectada mediante relaciones lógicas

A continuación se hará una breve descripción de las tecnologías que pueden
llevar a hacer una Web semántica, explicando sus ventajas e inconvenientes
a la hora de implementar la misma.

XML-
XML (eXtensible Markup Language), es el lenguaje que actualmente se
utiliza para intercambiar datos en la red. Este lenguaje se basa en las
tecnologíasURI (Uniform Resources Identifiers) e IRI (Internationalized
Resources Identifiers) tal como se ve en la Figura 3. XML emplea esas
tecnologías para especificar de forma única los recursos de la Web
Semántica.

Figura 3 Esquema de tecnologías a emplear en la Web Semántica

Un documento XML consiste en una serie anidada de etiquetas abiertas (<)
y cerradas (>), donde cada etiqueta tiene ciertos valores. Es potestad del
programador definir los nombres de las etiquetas y sus combinaciones
permitidas. Para ello puede usar documentos DTD(Document Type
Definition, definición de tipos de documentos) o esquemas XML. Las DTD
y los esquemas XML son usados por los analizadores sintácticos (parsers)
para comprobar si un documento XML es válido; es decir, si cumple la
gramática.

Ventajas:

 Cualquier documento y cualquier tipo de dato puede
expresarse como un documento XML.

 XML es autodescriptivo. Un documento XML no sólo
almacena datos, sino también la estructura de los
mismos.

 Los documentos XML pueden desarrollarse tal y como
quiera una persona o una organización.

 La estructura de los documentos XML puede
comprobarse automáticamente, de manera que se
rechacen aquellos documentos que no están
construidos siguiendo los esquemas o DTDs elegidos.

 Como XML se basa en texto plano, los documentos
XML son idóneos para transportarlos a través de
Internet.

 Como Unicode es el juego de caracteres predefinido
para XML, se pueden crear documentos XML para casi
todos los lenguajes humanos.

Inconvenientes:
No proporciona interoperabilidad completa puesto que no incorpora ningún
mecanismo para garantizar interoperabilidad semántica. XML sirve para
especificar el formato y estructura de cualquier documento; pero no impone
ninguna interpretación común de los datos del documento. Desde el punto
de vista semántico, XML resulta casi inútil: dado un documento XML, no
se pueden reconocer en él los objetos y relaciones del dominio de
interés. Es decir, si se tiene una etiqueta <precio> en un XML y otra
etiqueta <precioUnidad> en otro, una máquina no podrá deducir que pueden
significar lo mismo.

RDFS-
RDF (Resource Description Framework) es un lenguaje que
describe metadatos y fuentes de información (documentos, imágenes, etc.)
en la Web. Según W3C, el objetivo de RDF radica en “especificar la
semántica para los datos basados en XML, de una manera interoperable y
estandarizada”. Debido a su carácter general, también puede representar
datos.
Si bien suele decirse que RDF es un lenguaje, lo cierto es que resulta más
exacto describirlo como un modelo de datos para las instancias de
metadatos o, por abreviar, como un modelo de metadatos. En RDF, la
construcción básica es la tripleta (sujeto, propiedad, objeto). Toda tripleta
RDF corresponde a una sentencia RDF: la parte que identifica a qué se
refiere la sentencia es el sujeto; la parte que identifica la característica del
sujeto a la que se refiere la sentencia es la propiedad o el predicado; la parte
que identifica el valor de la propiedad es el objeto.
Los sujetos, las propiedades y los objetos son recursos. En general, un
recurso RDF es cualquier cosa con identidad y para identificarlos se recurre
a los URI. Cualquier organización o persona puede crear URIs y usarlos
para trabajar con sus dominios de interés. Los URI no tienen significado
por sí mismos, son identificadores, y la persona o la organización que los

crea se responsabiliza de darles significado.
Aparte de en forma gráfica o en forma de tripletas (sujeto, propiedad,
objeto), las sentencias RDF pueden representarse en XML
(RDF/XML). Por ejemplo:

Figura 4 Ejemplo de RDF. Los cuadrados son los objetos, las
flechas las propiedades y los globos son los sujetos.

La Figura 4 muestra un ejemplo de lo que RDF puede describir, que en
términos de XML puede ser descrito como:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about=http://www.w3.org/TR/rdf-syntax-
grammar dc:title="RDF/XML Syntax Specification (Revised)">
<ex:editor>
<rdf:Description ex:fullName="Dave Beckett">
<ex:homePage
rdf:resource="http://purl.org/net/dajobe/" />
</rdf:Description>
</ex:editor>
</rdf:Description>
</rdf:RDF>

Es decir, esto correspondería a la descripción de que la
página http://purl.org/net/dajobe (sujeto), tiene como editor (propiedad) a
Dave Beckett (objeto). O en forma de tripleta: (http://purl.org/net/dajobe,
editor, Dave Beckett).
Con xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#, lo que se
está dando es la descripción del vocabulario de RDFS. Después se definen
las etiquetas dc y ex, asociándolas a una URI que les da sentido:
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:ex="http://example.org/stuff/1.0/"
La ventaja de usar RDF en forma de XML estriba en que se puede hacer uso
de los esquemas XML y de las DTD para comprobar su validez, de usar las
transformaciones XSLT, de poder tener representaciones en memoria de los

mismos mediante el uso de DOM o SAX, etc. Pero esto no implica que no
se puedan representar de otras maneras ni que esté ligado a esta
representación.
Al igual que en XML se tienen los esquemas XML para comprobar la
validez sintáctica de un XML, en RDF se tienen los esquemas RDF o
también conocidos por RDFS, que permiten conocer si un conjunto de
tripletas RDF tiene sentido o no para ese esquema. Es decir, especifican la
interpretación que hay que dar a un modelo de datos RDF, pero dejan libre
su representación sintáctica.
El vocabulario completo de RDFS se define
en: http://www.w3.org/1999/02/22-rdf-syntax-ns#, pero básicamente puede
decirse que proporciona:

 Clases

 Jerarquías de clases

 Propiedades

 Jerarquías de propiedades

 Restricciones sobre los dominios y los rangos.

Ventajas:

 Permite definir conceptos mediante el uso de tripletas.

 Permite establecer relaciones semánticas y lógicas
básicas entre conceptos.

 Permite establecer clases y jerarquías de las mismas
mediante rdfs:subClassOf
Inconvenientes:

 No se pueden declarar restricciones de rango
(rdfs:range) que sean válidas sólo para algunas
clases. rdfs:range define el rango de una propiedad
para todas las clases.

 No se pueden representar algunas características de
las propiedades. No puede declararse que una
propiedad es transitiva (como MenorQué), simétrica
(como AlLadoDe (Pepe está AlLadoDe Juan y Juan
está AlLadoDe Pepe)), inversa
(como RaizCuadradaDe) o única (como PadreDe).

 No se puede representar que determinadas clases son
disjuntas. Por ejemplo, las clases Hombre y Mujer
subclases de Persona deberían ser disjuntas, sin

embargo con RDFS no puede declararse esto.

 No permite expresar restricciones de cardinalidad. No
se restringe el número de valores que una clase
puede tomar.

Ontologías-
El término ontología en informática hace referencia a la formulación de un
exhaustivo y riguroso esquema conceptual dentro de un dominio dado, con
la finalidad de facilitar la comunicación y la compartición de la información
entre diferentes sistemas. Aunque toma su nombre por analogía, ésta es la
diferencia con el significado filosófico de la palabra ontología.
Un uso común tecnológico actual del concepto de ontología, en este sentido,
lo encontramos en la inteligencia artificial y la representación del
conocimiento. En algunas aplicaciones, se combinan varios esquemas en
una estructura completa de datos, que contiene todas las entidades
relevantes y sus relaciones dentro del dominio.
Hay varios tipos de ontologías en informática:

 Según el ámbito del conocimiento al que se apliquen:

o Ontologías generales: son las ontologías de
nivel más alto ya que describen conceptos
generales (espacio, tiempo, materia, objeto,
etc.)

o Ontologías de dominio: describen el
vocabulario de un dominio concreto del
conocimiento.

o Ontologías específicas: son ontologías
especializadas que describen los conceptos para
un campo limitado del conocimiento o una
aplicación concreta.

 Según el tipo de agente al que vayan destinadas:

o Ontologías lingüísticas: se vinculan a
aspectos lingüísticos, esto es, a aspectos
gramáticos, semánticos y sintácticos destinados
a su utilización por los seres humanos.

o Ontologías no lingüísticas: destinadas a ser
utilizadas por robots y agentes inteligentes.

o Ontologías mixtas: combinan las
características de las anteriores.

 Según el grado o nivel de abstracción y razonamiento
lógico que permitan:

o Ontologías descriptivas: incluyen
descripciones, taxonomías de conceptos,
relaciones entre los conceptos y propiedades,
pero no permiten inferencias lógicas.

o Ontologías lógicas: permiten inferencias
lógicas mediante la utilización de una serie de
componentes como la inclusión de axiomas, etc.
Además de estas clasificaciones, se puede definir un grado de formalidad a
las ontologías, dependiendo del tipo de semántica que usen. Así, las
ontologías formales, de las que tratará el artículo, serán aquellas que usen
semánticas formales (usan lógica de primer orden o algún subconjunto de
ella) y que permitirán implementar sistemas de inferencia o razonamiento
automático.
En el entorno de la Web actual, las ontologías se representan generalmente
en formato XML. Este hecho no debe vincularlas indisolublemente con
XML, pues una ontología representa conocimiento, no es un formato de
mensajes. Hay muchos lenguajes que se usan para representar las
ontologías, los más conocidos son RDFS, OWL y DAML+OIL. En el
apartado anterior ya se han explicado las limitaciones de RDFS, y
DAML+OIL ha sido superado por OWL, por lo tanto se hablará sólo de este
último.
OWL es una versión mejorada de RDFS que sigue empleando el modelo de
tripletas de RDF. Mantiene una buena relación entre eficacia
computacional y poder expresivo. Hay tres versiones de OWL:

 OWL Lite

 OWL DL

 OWL Full
OWL Lite es un subconjunto de OWL DL, y esta a su vez es un
subconjunto de OWL Full. Por lo tanto OWL Full contiene todas las
características del lenguaje.
Así un ejemplo de la sintaxis empleada por OWL para definir una clase
Estudiantes:
<?xml version="1.0"?>
<!DOCTYPE Ontology [<!ENTITY xsd
"http://www.w3.org/2001/XMLSchema#" >]>
<owlx:Class owlx:name="Student" owlx:complete="false">
<owlx:Class owlx:name="Person" />
<owlx:DataRestriction owlx:property="studentID">
<owlx:cardinality owlx:value="1" />
<owlx:allValuesFrom owlx:datatype="&xsd;integer" />
</owlx:DataRestriction>

Cesnavarra 2008-boletín 11

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Cesnavarra 2008-boletín 11

Similar a Cesnavarra 2008-boletín 11 (20)

Más de Cein

Más de Cein (20)

Cesnavarra 2008-boletín 11