cesnavarra 2008-boletín 11
DESCRIPTION
respuesta digitalTRANSCRIPT
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, MessageBoxButtons.OK, MessageBoxIcon.Asterisk); progressBar1.Value = 1; 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); } catch (Exception exc) { MessageBox.Show( siteproblem + "\n" + exc.Message, appname, MessageBoxButtons.OK, MessageBoxIcon.Asterisk); progressBar1.Value = 1; return b; } //Instancia de Excel Access WebPart //Añade un Excel Access WebPart progressBar1.PerformStep(); ExcelWebRenderer ewaWebPart = new ExcelWebRenderer(); progressBar1.PerformStep(); ewaWebPart.ZoneID = "Left"; ewaWebPart.WorkbookUri = book; try { sharedWebParts.Add(ewaWebPart); } catch (Exception exc) { MessageBox.Show( addproblem + "\n" + exc.Message, appname, MessageBoxButtons.OK, MessageBoxIcon.Asterisk); progressBar1.Value = 1; return b; } progressBar1.PerformStep(); 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, MessageBoxButtons.OK, MessageBoxIcon.Information); progressBar1.Value = 1; } }
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
orías
CES Microsoft
Tema Desarrollo
Autor Raul Mayo González
Mes Noviembre
Año 2008
Boletí
n
11
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 Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS
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 Files\Common Files\Microsoft Shared\web server
extensions\12.
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
C:\Program Files\Common Files\Microsoft Shared\web server
extensions\12\TEMPLATE\CONTROLTEMPLATES
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
C:\Program Files\Common Files\Microsoft Shared\web server
extensions\12\TEMPLATE\FEATURES
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.
Categorías
CES Microsoft
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:\AzureServicesKit\Labs\BuildingWindowsAzureServices\Setup\SetupEx.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, EventArgs 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!
Categorías
CES Microsoft
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,
StreamEventListener l); void unsubscribe(java.lang.String eventName,
StreamEventListener l); }
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);
}
catch (XletStateChangeException
xsce)
{
xsce.printStackTrace();
}
return;
}
catch (Exception e){
try
{
destroyXlet(true);
}
catch (XletStateChangeException
xsce)
{
xsce.printStackTrace();
}
return;
}
try
{
iSubscribedEventID=dseEvent.subscr
ibe
(prEventProp.getProperty("EventN
ame"),
this);
}
catch (UnknownEventException uee)
{
uee.printStackTrace();
try
{
destroyXlet(true);
}
catch (XletStateChangeException
xsce)
{
xsce.printStackTrace();
}
return;
}
catch (InsufficientResourcesException
ire)
{
ire.printStackTrace();
try
{
destroyXlet(true);
}
catch (XletStateChangeException
xsce)
{
xsce.printStackTrace();
}
return;
}
catch (Exception e)
{
try
{
destroyXlet(true);
}
catch (XletStateChangeException
xsce)
{
xsce.printStackTrace();
}
return;
}
}
else
{
try
{
destroyXlet(true);
}
catch (XletStateChangeException xsce)
{
xsce.printStackTrace();
}
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"),
HStaticText.NORMAL_STATE);
}
} else {
hstText.setTextContent(new String("He
recibido un Stream Event pero no
datos"),
HStaticText.NORMAL_STATE);
}
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_introduction
Categ
orías
CES OpenSouce/Java
Tema Desarrollo
Autor Elena Gadea
Mes Noviembre
Año 2008
Boletí
n
11
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”
Servicio “Cuando”
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í
as CES OpenSouce/Java
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
ías
General
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>
<owlx:DataRestriction owlx:property="grade">
<owlx:cardinality owlx:value="1" />
<owlx:allValuesFrom>
<owlx:OneOf>
<owlx:DataValue
owlx:datatype="&xsd;integer">1</owlx:DataValue>
<owlx:DataValue
owlx:datatype="&xsd;integer">2</owlx:DataValue>
<owlx:DataValue
owlx:datatype="&xsd;integer">3</owlx:DataValue>
<owlx:DataValue
owlx:datatype="&xsd;integer">4</owlx:DataValue>
</owlx:OneOf>
</owlx:allValuesFrom>
</owlx:DataRestriction>
<owlx:ObjectRestriction owlx:property="schoolYear">
<owlx:cardinality owlx:value="1" />
<owlx:allValuesFrom>
<owlx:OneOf>
<owlx:Individual owlx:name="Freshman" />
<owlx:Individual owlx:name="Sophomore" />
<owlx:Individual owlx:name="Junior" />
<owlx:Individual owlx:name="Senior" />
</owlx:OneOf>
</owlx:allValuesFrom>
</owlx:ObjectRestriction>
<owlx:ObjectRestriction owlx:property="advisor">
<owlx:minCardinality owlx:value="1" />
<owlx:allValuesFrom owlx:class="Person" />
<owlx:someValuesFrom>
<owlx:Class owlx:name="Professor" />
<owlx:Class owlx:name="AssociateProfessor" />
</owlx:someValuesFrom>
</owlx:ObjectRestriction>
</owlx:Class>
En ella se definen conceptos como Identificador de estudiante, las notas, el
año en el que estudia o su asesor. Se ven conceptos interesantes que en
RDFS no se encontraban como las restricciones a la hora de asignar valores
a las propiedades y a los objetos definidas con owlx:minCardinality o a la
hora de asignar valores owlx:someValuesFrom. También se puede elegir
una única característica para una propiedad con owlx:OneOf, cosa que con
RDFS no se podía.
Ventajas:
Pueden usarse para mejorar la búsqueda de
información en la Web y navegar por ella.
Favorecen la interoperabilidad.
Pueden usarse para comprobar la validez de los datos.
Pueden servir para organizar las colecciones de
recursos multimedia.
Se usarán para programar agentes inteligentes, que
entenderán e integrarán las informaciones
procedentes de distintas fuentes.
Facilitarán el comercio electrónico.
Inconvenientes:
No están estandarizadas, entonces puede haber varias ontologías describiendo lo mismo, pero que no tienen
nada que ver unas con otras.
CONCLUSIONES-
La Web Semántica proporcionará un salto cualitativo sobre el potencial de
la Web. Las principales ventajas de esta nueva revolución en Internet serán
el desarrollo de aplicaciones con esquemas de datos comunes, fomento de
las transacciones entre empresas por comercio electrónico y búsqueda de
información con inferencias.
Para poder lograr estos objetivos se necesita unificar los contenidos
semánticos por medio de ontologías que formalicen este conocimiento de
forma consensuada y reutilizable.
Se necesita un lenguaje común basado en Web, con suficiente capacidad
expresiva y de razonamiento para representar la semántica de las
ontologías; este hecho parece que lo veremos en muy poco tiempo. Los
futuros sistemas se diseñarán para explotar el conocimiento de la Web.
ENLACES DE INTERÉS:
http://www.javahispano.org/tutorials.item.action?id=
55
XML
http://en.wikipedia.org/wiki/XML
http://es.wikipedia.org/wiki/XML
RDFS
http://www.w3.org/2008/Talks/1026-ISCW-RDFa/RDFa-ISWC08.html
http://es.wikipedia.org/wiki/RDF_Schema
http://www.w3.org/TR/rdf-syntax-grammar/
ONTOLOGÍAS
http://www.ksl.stanford.edu/people/dlm/papers/ontol
ogy101/ontology101-noy-mcguinness.html
http://es.wikipedia.org/wiki/Ontolog%C3%ADa_(Infor
m%C3%A1tica)
http://www.wshoy.sidar.org/index.php?2005/12/09/30-ontologias-que-son-y-para-que-sirven
http://www.hipertexto.info/documentos/ontologias.ht
m
http://elies.rediris.es/elies18/index.html
WEB SEMÁNTICA
http://es.wikipedia.org/wiki/Web_sem%C3%A1ntica
http://www.w3c.es/Divulgacion/Guiasbreves/WebSem
antica
http://www.hipertexto.info/documentos/web_semantica.htm
http://www.informandote.com/jornadasIngWEB/articu
los/jiw02.pdf
http://www.w3.org/2001/sw/
http://www.w3.org/2008/Talks/1009-bratt-W3C-SemTech/Overview.html
Catego
rías
CES OpenSouce/Java
Tema Varios
Autor Blanca Cubas Cruz
Mes Noviembre
Año 2008
Boletín 11