Development

WebParts con ASP.NET 2.0

Antes de entrar de lleno en toda la parafernalia de los webparts, voy a hacer una breve definición de un webparts. Se podría decir que es un bloque de nuestra web, con un determinado contenido, que los usuarios pueden personalizar a su gusto y antojo (Moviéndolo, ocultándolo, cerrándolo, etc), y dichos cambios se guardarán para posteriores visitas a la pagina donde se encuentren dichos webparts.

Vale!!! Esto está muy bien, pero… ¿cómo se crean los webparts? … Tranqui!!! Decirte que es sencillismo. Basta con crear una página web, añadir un control "WebPartManager" (este control es el primero que se debe de introducir o agregar antes que cualquier otro control, si no, no funcionará ok?. bien, sigo!! aaa!! Una cosa… cuando agregeís el WebPartManager, no os extrañeís al ver un recuadro gris, los WebPartManager no tienen un diseño. Sigo!!! (que me estoy enrrollando ya) A continuación agregaremos uno y varios controles "WebPartZone" (Consejo: Yó, antes de agregar los webparzone, añado una tabla la cual me delimitará las zonas donde se verán mis webparts). Tras agregar los webpartzone, ya puedo arrastrar cualquier control de la caja de herramientas dentro de las zonas y ¡VOILA!, ya tenemos un webpart, parece facil no? jejejeje! ¿Como es esto posible? Pues gracias a la clase "GenericWebParts".

Cada vez que arrastremos un control (por ejemplo un "Label") a una zona, Visual Studio creará como un envoltorio (wrapper) alrededor de dicho control, conviertiendoló en un GenericWebPart. El tener un envoltorio, el control agregado pasa a tener una serie de propiedades que de otra forma no tendría. Estas propiedades son tales como: "Title", "Descripción", "TitleIconImageUrl", "TitleUrl" y CatalogIconImageUrl". Además, gracias a este envoltorio podemos establecer comunicaciones de datos entre diferentes WebParts.

En realidad no todos los controles son iguales de buenos para ser convertidos en WebParts. Tomemos por ejemplo los controles "Literal". Si añadimos un literal a una zona tendremos un webParts pero sin embargo no tendremos las nuevas propiedades comentadas anteriormente. Entonces ¿Donde está la diferencia entre un Label y un literal? Pues que el Label desciende de la clase "Control", mientras que el segundo lo hace de "webControl". La clase "WebControl" implementa una serie de interfaces que son los que posibilitan que el envoltorio añada nuevas propiedades a nuestros controles, con lo que hay unas ciertas limitaciones. Lo primero que para empezar con webparts genericos no podremos aprovechar todas las posibilidades de los webparts. No podríamos, por ejemplo, añadir nuevas acciones al menu contextual, ni podríamos definir nuestras propias propiedades personalizables, por el usuario final.

Informática e Internet

Apple TV

Tu ordenador es el centro de tu vida digital y tu televisor, tu centro de diversión. ¿Pero qué pasa si quieres ver las películas, tráilers de películas, podcats, fotos y vídeos de YouTube de tu ordenador en el televisor? Los modelos del Apple TV de 40 GB y los nuevos de 160 GB, a la venta a partir de 289 €, llevan iTunes y mucho más a la gran pantalla.

La revolución se verá por televisión.

En lugar de pegarte a la pantalla de tu ordenador para ver lo que hay en iTunes, conecta el Apple TV a tu televisor de pantalla panorámica y sincroniza tu biblioteca de iTunes sin cables. Después, coge una silla, estira las piernas y hazte con el mando Apple Remote incluido para reproducir iTunes en la tele. ¡Enhorabuena! Acabas de cambiar tu forma de ver contenidos digitales multimedia.

¿Qué echan en la tele? Lo que te apetezca.

El Apple TV pone tu biblioteca de iTunes —incluidas tus canciones, vídeos musicales y podcasts— en tu televisor. Además, tus fotos digitales se ven en alta definición para que hagas pases de diapositivas a toda pantalla. Con hasta 200 horas de vídeo, 36.0000 canciones o 25.000 fotos a tus órdenes, siempre dan algo bueno por televisión.

Directamente desde Internet

Con el Apple TV, puedes ver los tráilers cinematográficos de Apple.com en tu televisor; y ahora, también puedes navegar y disfrutar de los vídeos de YouTube en la gran pantalla: busca entre miles de vídeos gratuitos de YouTube y reprodúcelos directamente desde Internet. Ponte cómodo y disfruta.

De iTunes al Apple TV sin cables.

El Apple TV se conecta a tu televisor a través de un puerto HDMI o de entradas de audio y vídeo por componentes. Su velocísimo módulo inalámbrico Wi-Fi 802.11 integrado sincroniza tu biblioteca de iTunes con cualquier ordenador Mac o PC de la casa. Y lo mejor es que todo cuanto tengas en el Apple TV se mantiene sincronizado: en el momento en que cambies algo en tu librería de iTunes, también lo hará en el Apple TV, de forma inalámbrica y automática.

iTunes

Descarga iTunes 7.1 para escuchar podcasts gratuitos y comprar audiolibros, juegos para el iPod y, como siempre, canciones a 0,99 €.

 

Development

Secretos internos de ASP.NET – Parte II

Ciclo vital de las páginas

ASP.NET
2.0 presenta dos importantes cambios en el ciclo vital de una página
ASP.NET. En primer lugar, ASP.NET 2.0 expone nuevos eventos para
admitir nuevas características, entre las que se incluyen páginas
principales, personalización y la compatibilidad integrada con
dispositivos móviles. En segundo lugar, ASP.NET 2.0 introduce el envío
cruzado entre páginas para formularios Web.

Nuevos eventos

ASP.NET 2.0 proporciona una pila de métodos de ciclo vital de las páginas más granular en comparación con ASP.NET 1.x.
Los nuevos métodos proporcionan un mayor nivel de control al
desarrollador Web. Se puede obtener acceso a estos eventos a través del
objeto Page de cualquier página ASP.NET.

La tabla 1 muestra la lista completa de métodos. La columna Método muestra el nombre real del método de evento y la columna ActivoPostBack. Por ejemplo, se puede utilizar el nuevo método TestDeviceFilter
para determinar el filtro de dispositivo aplicado y utilizar esta
información para decidir cómo se mostrará la página. Por otra parte, el
nuevo método LoadControlState sólo se desencadena durante una devolución de datos. Este método se puede omitir (junto con SaveControlState)
para crear esquemas alternativos de serialización para guardar y
restaurar el estado de control durante una devolución de datos.
indica si el evento siempre está activo o sólo está activo durante las acciones

Si se consideran
los detalles de bajo nivel del ciclo vital de las páginas, podemos ver
que muchas de las características que están disponibles en ASP.NET 2.0,
como los temas y la personalización, estarían implementados de manera
natural. Por ejemplo, un tema se procesaría en el evento IntializeThemes, mientras que los datos de personalización se cargarían en LoadPersonalizationData y posteriormente se aplicarían con el método ApplyPersonalization.
Observe que el orden de los métodos es extremadamente importante para
conocer los elementos de la interfaz de usuario que determinarán el
aspecto y el funcionamiento final de las aplicaciones Web.

Envío cruzado entre páginas

El otro cambio importante en el ciclo vital de las páginas se refiere a la devolución de eventos y Web Forms. En ASP.NET 1.x,
Web Forms realiza la devolución de manera automática a su página host.
Es decir, cuando un usuario envía un formulario, los datos del
formulario siempre se devuelven a la página que contenía el formulario
original. Esta decisión de diseño permite un fácil almacenamiento del
estado de control, pero limita la capacidad del desarrollador de
realizar operaciones más complejas.

En ASP.NET
2.0, los controles de Web Forms tienen una nueva propiedad que permite
al desarrollador decidir adonde se deben enviar los datos del
formulario cuando se realiza una acción de envío. En la mayoría de los
casos, el mecanismo de devolución de datos será la opción deseada y,
por tanto, sigue siendo la opción predeterminada. Sin embargo, si el
desarrollador desea enviar los datos de una forma diferente, ahora es
posible.

Puede, por
ejemplo, crear un asistente de varias páginas compuesto por varios
formularios diferentes. Cada formulario remite a la siguiente página de
la secuencia, hasta que el usuario alcanza una página de resumen en la
que se puede realizar la validación final. Se puede obtener acceso a
los datos de la última página en el contexto actual mediante el objeto PreviousPage. El objeto PreviousPage

almacena los datos validados de la página anterior para utilizarlos en
la página actual. Gracias a este objeto, el envío cruzado entre páginas
no sacrifica la persistencia del control. Si el usuario necesita
realizar una copia de seguridad de un formulario de la secuencia, los
datos de la página estarán accesibles de manera inmediata y el usuario
no tendrá que volver a introducir todos los datos.

Extensibilidad

ASP.NET
se diseñó en un principio como un marco de trabajo abierto. Es decir,
muchos de los módulos y de los componentes que forman ASP.NET pueden
ampliarse, modificarse o reemplazarse para adaptarlos a sus necesidades
concretas. En ASP.NET 2.0, la naturaleza extensible del marco de
trabajo queda claramente ilustrada con los nuevos HTTPHandlers y HTTPModules que ahora son una parte estándar del marco de trabajo.

La canalización de solicitudes

En
ASP.NET, las solicitudes se pasan desde el servidor Web a través de un
filtro de interfaz de programación de aplicación de servidor de
Internet (ISAPI, Internet Server Application Programming Interface)
hacia el tiempo de ejecución real de ASP.NET.

Cuando IIS recibe
una solicitud, la extensión se asigna a un filtro ISAPI de acuerdo con
la configuración de IIS. Las extensiones .aspx, .asmx, .asd y otras se
asignan a aspnet_isapi.dll, que es sencillamente un filtro ISAPI que
inicia el tiempo de ejecución de ASP.NET. Una vez que una solicitud
llega al tiempo de ejecución de ASP.NET, se inicia en el objeto HTTPApplication, que actúa como host de la aplicación Web ASP.NET. El objeto HTTPApplication:

  1. Lee los archivos de configuración del equipo y de la aplicación.

  2. Pasa la solicitud a través de una o varias instancias HTTPModule. Cada HTTPModule
    proporciona un servicio como el mantenimiento de sesiones,
    autenticación o mantenimiento de perfiles. Estos módulos devuelven la
    solicitud a HTTPApplication.

  3. Pasa la solicitud a un HTTPHandler
    en función del verbo y de la ruta de acceso. El verbo hace referencia
    al verbo HTTP utilizado en la solicitud (GET, POST, FTP, etc.) y la
    ruta de acceso hace referencia a una dirección URL dentro de la
    aplicación. Dependiendo de cómo se hayan configurado los controladores,
    la solicitud se puede procesar como una página ASP.NET (System.Web.UI.Page es una implementación de IHTTPHandler)
    o la solicitud puede desencadenar otra acción como la compilación por
    lotes de todas las páginas Web (precomiplation.asd desencadena PrecompHandler).

En
ASP.NET 2.0, este modelo permanece intacto; no obstante, se han
agregado nuevos módulos y controladores para proporcionar servicios
adicionales. Al igual que ocurre con ASP.NET 1.x, puede
extender, reemplazar o reconfigurar cualquier clase de controlador o
módulo para proporcionar su propia funcionalidad personalizada.

Nuevos módulos

Por supuesto, se han agregado nuevos HTTPModules
para admitir los nuevos servicios que se ofrecen en ASP.NET 2.0.
Concretamente, una aplicación ASP.NET con la configuración de módulos
predeterminada incluirá nuevos módulos para:

  • Id. de sesión: el mecanismo de identificación de sesiones se ha escindido del módulo Session de ASP.NET 1.x
    para proporcionar un mayor control sobre las cookies, la reescritura de
    direcciones URL y otras formas de generación de identificadores de
    sesión.

  • Administración de funciones: se ha
    agregado un nuevo módulo que proporciona servicios basados en funciones
    para admitir los nuevos mecanismos de identificación de usuarios. Este
    módulo ayuda a vincular las aplicaciones ASP.NET con la seguridad
    basada en funciones incorporada en .NET Framework.

  • Identificación anónima: las nuevas
    características de personalización admiten usuarios anónimos. Este
    módulo realiza un seguimiento de las características a las que puede
    obtener acceso un usuario anónimo y cómo se mantienen dichas
    características entre solicitudes.

  • Perfil: el módulo de perfiles está
    vinculado con el nuevo servicio de perfiles y ayuda a proporcionar un
    almacenamiento persistente de datos específico del usuario.

  • Contadores de página: ASP.NET 2.0
    incorpora un nuevo módulo para vincular con contadores de página y
    mejorar el análisis estadístico del tráfico Web.

Además
de estos nuevos módulos, se ha cambiado el comportamiento de algunos de
los módulos más antiguos: por ejemplo, el módulo de almacenamiento en
caché de la salida ahora admite las nuevas técnicas de almacenamiento
en caché que se describen más adelante en este artículo.

Nuevos controladores

Además
de estos nuevos módulos, ASP.NET 2.0 presenta nuevos controladores para
admitir las herramientas de configuración de aplicaciones y otras
nuevas características como la solicitud de compilación por lotes. El
más importante de los nuevos controladores incluye la familia ".axd"
que procesa las solicitudes de administración de sitios Web. Estos
controladores inician las herramientas de administración interna que
permiten a los desarrolladores configurar los usuarios ASP.NET así como
otras opciones de configuración. Entre los controladores de
administración se incluyen:

  • Administración Web: WebAdminHandler
    es la página principal del sitio Web administrativo. Este controlador
    proporciona el punto de partida para administrar aplicaciones Web
    ASP.NET 2.0.

  • Seguimiento: se ha mejorado ASP.NET 1.x TraceHandler y es el único controlador "axd" que estaba disponible en ASP.NET 1.x.

  • Recursos
    Web: ahora es posible configurar los recursos Web tras la
    implementación gracias a la nueva herramienta administrativa y a WebResourcesHandler.

  • Imágenes en caché: CachedImageServiceHandler ofrece compatibilidad para almacenar en caché componentes gráficos.

  • Contadores: SiteCountersHandler funciona con el módulo de contadores de páginas para ofrecer estadísticas de acceso para una aplicación ASP.NET 2.0.

  • Precompilación: como ya se ha mencionado, PrecompHandler se puede utilizar para compilar por lotes todas las páginas ASPX de una aplicación ASP.NET.

  • Exportación de elementos Web: WebPartExportHandler
    proporciona compatibilidad para almacenar y transferir diseños de
    elementos Web. Los elementos Web son un nuevo mecanismo para
    personalizar el aspecto y el contenido de una aplicación Web de tipo
    portal.

Como siempre, HTTPForbiddenHandler
está vinculado con todos los tipos de archivos que no hay que devolver
nunca. En ASP.NET 2.0, la lista de tipos de archivos prohibidos se ha
ampliado para incluir páginas principales, archivos de máscara y otros
nuevos componentes para desarrolladores.

Técnicas avanzadas de almacenamiento en caché

Una
manera de mejorar el rendimiento de cualquier aplicación Web es
almacenar en memoria caché el contenido estático. El contenido en caché
siempre se devuelve más rápidamente que el contenido recientemente
procesado. Sin embargo, el posible inconveniente es que el contenido en
caché puede quedarse obsoleto. ASP.NET 1.x admite varios tipos de almacenamiento en caché, entre los que se incluyen:

  • Nivel
    de página: cada página se puede almacenar en caché como un elemento
    completo o en función de los parámetros utilizados para obtener acceso
    a la página. La página en caché caduca después de un tiempo fijo.

  • Fragmento de página: si la página se creó con
    los controles del usuario (archivos .ascx), los controles del usuario
    se pueden almacenar en caché independientemente del resto del contenido
    de la página.

  • Almacenamiento en caché mediante programación:
    el desarrollador también puede almacenar en caché objetos, gracias a la
    API de caché. La API de caché ofrece la ventaja concreta de
    proporcionar una manera de crear varios tipos de dependencias para
    cuando es necesario limpiar la caché.

En
ASP.NET 2.0, el mecanismo de almacenamiento en caché de nivel de página
se ha extendido para admitir las dependencias de base de datos. Con una
dependencia de caché de base de datos, una página almacenada en caché
se puede vincular a una determinada tabla de una base de datos de SQL
Server. Cuando la tabla cambia, la caché caducará automáticamente.
Además, un desarrollador puede utilizar la sustitución tras la caché
para reemplazar parte del contenido almacenado en caché por contenido
actualizado. La sustitución tras la caché permite que una aplicación
utilice el almacenamiento en caché de nivel de página incluso cuando es
preciso generar dinámicamente parte de la página.

Invalidación de la caché de la base de datos

Para
la mayoría de los sitios Web orientados a datos, el almacenamiento en
caché puede ser un tema espinoso, especialmente en aquellas situaciones
que exigen el almacenamiento en caché y es necesario disponer de datos
actualizados. En ASP.NET 1.x, las páginas se pueden almacenar en
caché durante un período de tiempo y organizarlas por los parámetros de
entrada (cadena de consulta o parámetros POST):

Listado 5. Directiva de caché de salida de ASP.NET 1.x

<%@ outputcache duration="3600" varybyparam="ProdID" %> 

Por ejemplo, el código del listado 5 almacena una página en memoria caché durante una hora en función de la variable ProdID.
El problema que surge en el ejemplo anterior es qué hacer si los datos
empresariales relevantes se actualizan en otro sitio. Por ejemplo,
imaginemos una página de catálogo de productos almacenada en caché por
identificador de producto. Si la información acerca de este producto
(cantidad disponible o precio, por ejemplo) se actualiza desde un sitio
administrativo, se almacenarán en caché y se mostrarán a los clientes
datos incorrectos. Con la versión anterior de ASP.NET, para solucionar
este problema habría que eliminar manualmente la página de la caché
mediante Response.RemoveOutputCacheItem o esperar hasta que finalice el período de tiempo duration y permitir al sistema actualizar la página automáticamente.

ASP.NET
2.0 resuelve este problema ofreciendo compatibilidad con dependencias
de caché de bases de datos. Hay disponibles notificaciones de nivel de
tabla al trabajar con SQL Server 7 y 2000, y Microsoft SQL Server 2005
ofrecerá notificaciones en un nivel todavía más granular. Por ejemplo,
el siguiente código almacena en caché una página de productos durante
un período de hasta 1 hora, pero agrega una segunda dependencia en una
tabla de base de datos.

Listado 6. Ejemplo de caché de base de datos de ASP.NET 2.0

<%@ outputcache duration="3600" 
varybyparam="ProdID"
sqldependency="MyDatabase:Products" %>

Utilizando el nuevo atributo sqldependency, la página almacenada en caché caducará si se realiza algún cambio a la tabla de productos. El atributo sqldependency debe hacer referencia a un datasource que se haya configurado en el archivo web.config. A su vez, datasource identifica la conexión de base de datos y los parámetros necesarios para lograr que funcione la notificación de dependencias.

Dependencias de caché personalizadas

ASP.NET 2.0 incluye una implementación de CacheDependency, la clase SQLCacheDependency,
que es compatible con Microsoft SQL Server. La implementación de una
nueva dependencia de caché puede ser un proceso complicado, pero es
posible debido a la naturaleza extensible de ASP.NET 2.0. Es decir,
puede crear su propia clase CacheDependency para proporcionar una funcionalidad similar para otros sistemas de bases de datos como Oracle o Sybase.

Sustitución tras la caché

Para
aquellos casos en los que unos pocos elementos de la página sean
dinámicos pero la mayoría de la página podría utilizar el
almacenamiento en caché, ASP.NET 2.0 proporciona una característica
denominada sustitución tras la caché. Esta característica se utiliza
para informar al tiempo de ejecución de ASP.NET de que un elemento
concreto, mientras se encuentra en una página almacenada en caché, debe
volver a evaluarse antes de presentar la página al usuario.

Hay dos maneras de utilizar esta característica:

  • Llamar al nuevo método Response.writeSubstitution, pasándole una referencia a la función de devolución de llamada de sustitución.

  • Agregar un control <asp:substitution> a la página Web y establecer el atributo methodname en el nombre de la función de devolución de llamada.

  • Para ambas opciones es necesario agregar a la página una directiva @OutputCache, que especifique la duración y la ubicación de la dependencia.

Implementación de la sustitución tras la caché

Es
posible crear controles que detecten la sustitución tras la caché para
aprovechar esta característica. Un ejemplo de esto es el control AdRotator. El listado 7 ilustra una página que:

  • Recupera datos de la tabla de autores de la base de datos Pubs.

  • Enlaza los datos con un control GridView.

  • Muestra anuncios desde AdRotator.

  • Muestra la hora en la que se creó la página en un control de etiqueta.

También se ha agregado al ejemplo un control <asp:substitution> (líneas en negrita del listado). Este control tiene su atributo methodname establecido en uncachedUpdate
(un método que devuelve como salida una cadena, en este caso, la hora
actual). El control de sustitución devolverá la hora correcta,
independientemente de lo que se haya almacenado en caché.

Listado 7. Código fuente de PostCache.ASPX

<%@ Page language="c#" Codebehind="PostCache.ASPX.cs" 
AutoEventWireup="true" Inherits="WebApplication1.PostCache" %>
<%@ outputcache duration="30" varybyparam="none" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
<HEAD>
<title>WebForm1</title>
</HEAD>
<body MS_POSITIONING="GridLayout">
<form id="Form1" method="post" runat="server">
<DIV style="DISPLAY: inline;
Z-INDEX: 101; LEFT: 32px; WIDTH: 160px;
POSITION: absolute; TOP: 24px; HEIGHT: 8px"
align="right" ms_positioning="FlowLayout">
this page was created at:
</DIV>
<asp:Label id="CreatedTime"
style="Z-INDEX: 102; LEFT: 200px; POSITION: absolute;
TOP: 24px" runat="server" Width="120px" Height="16px">
</asp:Label>
<asp:substitution id="UpdatedTime" methodname="uncachedUpdate"
style="Z-INDEX: 103; LEFT: 200px; POSITION: absolute;
TOP: 48px" runat="server" Width="112px" Height="11px">
</asp:substitution>
<DIV style="DISPLAY: inline; Z-INDEX: 104; LEFT: 32px;
WIDTH: 160px; POSITION: absolute; TOP: 48px;
HEIGHT: 16px" align="right" ms_positioning="FlowLayout">
and last updated at:
</DIV>
<asp:AdRotator id="Ads" style="Z-INDEX: 105; LEFT: 312px;
POSITION: absolute; TOP: 16px" runat="server"
Width="80px" Height="60px" AdvertisementFile="img/Ads.xml">
</asp:AdRotator>
</form>
</body>
</HTML>

El archivo de código subyacente de esta página
contiene el evento necesario para admitir la sustitución tras la caché
en el método uncachedUpdate. Observe que el método Page_Load
informa de la hora en la que se cargó la página, por lo que podemos
determinar cuándo se está produciendo un almacenamiento en caché.

Listado 8. PostCache.ASPX.cs

using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Web;
using System.Web.SessionState;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;

namespace WebApplication1 {
public class PostCache : System.Web.UI.Page {
protected System.Web.UI.WebControls.Label CreatedTime;
protected System.Web.UI.WebControls.Label UpdatedTime;
protected System.Web.UI.WebControls.AdRotator Ads;

private void InitializeComponent() {
this.Load += new System.EventHandler(this.Page_Load);
}

private void Page_Load(object sender, System.EventArgs e) {
CreatedTime.Text = DateTime.Now.ToShortTimeString();
}

protected String uncachedUpdate() {
return DateTime.Now.ToShortTimeString();
}
}

}

Sustitución tras la caché en acción

La primera vez que se ejecuta la aplicación, podemos ver que las horas
de "creación de la página" y "última actualización" son iguales.

En las posteriores
llamadas a la misma página podemos ver el efecto de la sustitución tras
la caché. Aunque la hora de creación de la página y la imagen siguen
siendo las mismas, la hora de última actualización cambia.

Tanto la hora de creación como la imagen de adRotator
permanecen constantes como consecuencia de la directiva de
almacenamiento en caché. La página se almacena en caché durante 30
segundos. Una vez que ya ha pasado este tiempo, tanto la hora de
creación como adRotator se actualizarán en la siguiente solicitud. Sin embargo, el control <asp:substitution>, que llama al método uncachedUpdate(), se actualizará cada vez que se solicite la página independientemente de su estado de almacenamiento en caché.

Con
una correcta manipulación de la sustitución tras la caché, los
desarrolladores pueden aumentar notablemente el rendimiento de sus
aplicaciones Web actualizando únicamente los puntos dinámicos de sus
páginas. Junto con la invalidación de la caché de base de datos y las
actualizaciones asíncronas de páginas, las aplicaciones Web
desarrolladas con ASP.NET 2.0 acabarán con la mayoría de las
limitaciones impuestas por la tradicional arquitectura Web de solicitud
y respuesta.

Rendimiento

Teniendo
en cuenta los cambios en la infraestructura y las características
adicionales de ASP.NET 2.0, la pregunta que cabe plantearse es, ¿qué
velocidad ofrece ASP.NET 2.0? Aunque todavía no hay indicadores de
rendimiento ya que ASP.NET 2.0 todavía está en proceso de desarrollo,
se ha realizado un importante esfuerzo para garantizar que el
rendimiento se mantiene o se mejora en todos los aspectos del marco de
trabajo ASP.NET 2.0.

Mejor canalización de solicitudes

Un
punto en el que todos los desarrolladores verán un mejor rendimiento es
en la canalización de solicitudes. A pesar de la incorporación de
muchos nuevos enlaces de eventos, la pila de solicitudes básica de
ASP.NET es hasta un 30% más rápida que la de ASP.NET 1.1. Puede evaluar
las mejoras en el rendimiento creando una página sencilla que muestre
"Hola mundo". Como la página no tiene ninguna funcionalidad avanzada,
puede probar directamente las canalizaciones HTTPHandler y HTTPModule,
así como el complemento ISAPI que conecta ASP.NET 2.0 con IIS.
Independientemente de la versión de IIS que esté utilizando, debe
apreciar una mejora del rendimiento ya que este código se ha optimizado
para conseguir un funcionamiento más rápido.

Mejor administración de la memoria con IIS 6.0

Algunas
de las mejoras de rendimiento de ASP.NET 2.0 sólo vienen junto con IIS
6.0. Por ejemplo, en IIS 6.0, la memoria de trabajo para el proceso de
trabajo se ha reducido en aproximadamente un 50% en las pruebas de
carga; para estas se han utilizado 100 usuarios simultáneos requiriendo
una página con varios controles. Esto significa que, para un
determinado servidor, el sistema operativo utiliza aproximadamente la
mitad de los recursos que antes eran necesarios.

En
una prueba diseñada para imitar una página ASP.NET moderadamente
compleja, la carga del sistema (memoria y uso de la CPU) descendió
drásticamente en comparación con la misma página ejecutándose en IIS
5.0. Esta mejora concreta del rendimiento se consiguió moviendo los
búferes de respuesta de la memoria administrada a la memoria nativa. Al
eliminar la necesidad de asignar memoria administrada a una determinada
respuesta, ASP.NET 2.0 elimina un cuello de botella de recursos y
genera respuestas más rápidas para cada solicitud.

Otras
mejoras de rendimiento aprovechan la estrecha integración de IIS 6.0
con el núcleo del sistema operativo Windows. IIS 6.0 realiza parte de
su almacenamiento en caché y en búfer a nivel de núcleo, lo que
proporciona un mayor rendimiento para todas las aplicaciones Web,
incluidas ASP.NET.

Otras mejoras

Como desarrollador, esperará que ASP.NET 2.0 funciona tanto o más rápido que ASP.NET 1.x.
Ahora que se ha creado la funcionalidad básica, son de esperar mejoras
adicionales de rendimiento en la versión final de ASP.NET 2.0.

Conclusión

ASP.NET
2.0 contiene muchas mejoras en la arquitectura diseñadas para mejorar
la productividad de los desarrolladores. No sólo se ha mejorado el
modelo de código para reducir los conflictos, sino que el proceso de
compilación se ha ampliado para proporcionar una mayor variedad de
opciones a la hora de compilar e implementar aplicaciones Web. La
extensibilidad del marco de trabajo ASP.NET se ha puesto de manifiesto
una vez más mediante los nuevos HTTPModules y HTTPHandlers,
que admiten muchas de las nuevas características que incluye ASP.NET,
incluidas la personalización, las páginas principales y el sitio
administrativo. El almacenamiento en caché se ha mejorado para permitir
las dependencias de base de datos y la sustitución tras la caché.
Internamente, ASP.NET 2.0 contiene notables mejoras respecto a su
predecesor; la nueva implementación incorpora un número de mejoras
solicitadas por los desarrolladores al mismo tiempo que respeta las
prácticas recomendadas del sector. ASP.NET 2.0 proporciona una
plataforma de desarrollo Web de primera clase diseñada para manejar la
complejidad del desarrollo de aplicaciones Web empresariales.

Development

Secretos internos de ASP.NET – Parte I

Modelo de código

Tal
vez el cambio más obvio del funcionamiento interno de ASP.NET 2.0 esté
relacionado con cómo se crea una página Web ASP.NET. En esta sección,
examinaremos los cambios realizados al modelo de código subyacente y
cómo afectan estos cambios al desarrollo de ASP.NET.

Modelos de codificación en ASP.NET 1.x

En ASP.NET 1.x,
los desarrolladores tenían básicamente dos opciones para desarrollar un
formulario Web. En primer lugar, el desarrollador podía seguir el
modelo de ASP tradicional y escribir el código directamente en la
página ASPX. Este proceso, conocido como código en línea,
funciona muy bien cuando se trata de comandos sencillos. Sin embargo,
si el código es más complejo, la escritura de código en línea genera
páginas Web difíciles de leer que mezclan la presentación (HTML) con la
funcionalidad (código). En ASP.NET, se cambió la práctica de
codificación predeterminada para ayudar a resolver este problema. La
lógica empresarial y el código de control de eventos se podían escribir
en un archivo independiente que sólo incluía el código, denominado
archivo de código subyacente. El modelo de código subyacente
vincula un archivo de sólo código con el archivo ASPX que contiene las
etiquetas de presentación. Al separar el código de la presentación, los
equipos de desarrollo podían trabajar más rápido permitiendo a los
diseñadores trabajar en el archivo de presentación mientras los
desarrolladores trabajaban en el archivo de código.

Las principales
dificultades del modelo de código subyacente estaban relacionadas con
la manera en que era necesario sincronizar el archivo de código
subyacente con la página ASPX. Aunque la página ASPX se heredaba del
archivo de código subyacente desde el punto de vista de la
programación, los dos archivos estaban en realidad acoplados por una
relación más compleja.

Para obtener información más detallada acerca del modelo de código subyacente de ASP.NET 1.x, consulte el artículo de MSDN Library, Modelo de códigos de formularios Web Forms.

Complejidad de la herencia

El
paradigma del diseño de ASP.NET era que los desarrolladores utilizarían
Microsoft Visual Studio .NET para arrastrar y colocar controles en la
página ASPX. A continuación, Visual Studio generaría automáticamente el
código necesario correspondiente en el archivo de código subyacente. Si
se agregaban los controles a la página ASPX, era necesario agregar
nuevo código al archivo de código subyacente. Es decir, a pesar de que
la relación de herencia apunte en dirección contraria, la página ASPX
en realidad dirigiría el diseño del archivo de código subyacente.

Complejidad de la compilación

El
segundo problema de sincronización residía en la manera de compilar los
archivos. Todos los archivos de código subyacente, junto con todas las
clases necesarias, se compilaban en un ensamblado y se almacenaban en
el directorio /bin de la aplicación Web. El paso de compilación
se llevaba a cabo antes de la implementación de la aplicación. Por otra
parte, la página ASPX se compilaba en tiempo de ejecución la primera
vez que se solicitaba la página. El tiempo de ejecución de ASP.NET en
realidad compilaba la página ASPX en su propio ensamblado temporal.

El
problema de este proceso es que era posible cambiar la página ASPX sin
actualizar el ensamblado de código subyacente. Es decir, un
desarrollador podía decidir modificar una propiedad o cambiar el tipo
de un control en una página ASPX después de la implementación y no se
actualizaría el archivo de código subyacente ni se volvería a compilar
el ensamblado de la aplicación. Cuando ocurría esto, la aplicación
presentaría errores inesperados debido a la falta de coincidencia entre
los archivos de código subyacente y sus páginas ASPX asociadas.

Modelos de codificación en ASP.NET 2.0

ASP.NET
2.0 continúa ofreciendo tanto los modelos de código en línea como de
código subyacente. En lo que se refiere al modelo de código en línea,
hay muy pocos cambios salvo en la manera en que Microsoft Visual Studio
2005 admite el desarrollo de un único archivo. Para obtener más
detalles acerca de los cambios realizados en Visual Studio 2005 y cómo
maneja el código en línea, consulte este artículo (en inglés).

ASP.NET
2.0 resuelve tanto los problemas de herencia como de compilación del
modelo de código subyacente al modificar la naturaleza del archivo de
código subyacente. En ASP.NET 2.0, el archivo de código subyacente ya
no es una implementación completa de la clase System.Web.UI.Page. En su lugar, el archivo de código subyacente es una nueva construcción denominada clase parcial.
La clase parcial contiene todo el código definido por el usuario, pero
omite todo el código de estructura y conectividad que generaba
automáticamente Visual Studio .NET en ASP.NET 1.x. Cuando se
solicita una página ASPX con un nuevo archivo de código subyacente,
será el momento en que el tiempo de ejecución de ASP.NET 2.0 combine en
realidad la página ASPX y la clase parcial en una única clase, en vez
de en dos clases diferentes.

La clase parcial utiliza una nueva palabra clave (Expands en Visual Basic o Partial
en C#) para indicar que el código de la clase se debe combinar con otra
clase en tiempo de ejecución. De manera similar, la página ASPX utiliza
una nueva directiva denominada compilewith para indicar su asociación con el archivo de código subyacente.

Comparación de los archivos de código subyacente

Si ya está familiarizado con los archivos tradicionales de código subyacente de ASP.NET 1.x,
sabrá que Visual Studio inserta el código de inicialización y las
declaraciones de control generadas automáticamente. Este código
generado automáticamente es resultado directo de la sincronización
bidireccional entre el archivo de código subyacente y el archivo ASPX.
Una página ASPX típica con una etiqueta tendría su correspondiente
archivo de código subyacente que estaría compuesto de muchas líneas de
texto generado automáticamente.

Listado 1. Archivo de código subyacente en ASP.NET 1.x

namespace WebApplication1
{
public class WebForm1 : System.Web.UI.Page
{
protected System.Web.UI.WebControls.Label Label1;
private void Page_Load(object sender,
System.EventArgs e) { }
#region Web Form Designer generated code
override protected void OnInit(EventArgs e)
{
InitializeComponent();
base.OnInit(e);
}
private void InitializeComponent()
{
this.Load += new System.EventHandler(this.Page_Load);
}
#endregion
}
}

El código generado automáticamente no sólo
define la etiqueta (línea en negrita), sino que también declara un
nuevo evento (la carga de la página) y conecta automáticamente el
evento con un contenedor de métodos generado automáticamente (Page_Load()).

En comparación, la misma página ASP.NET en ASP.NET 2.0 genera un archivo de código subyacente mucho más limpio.

Listado 2. Archivo de código subyacente en ASP.NET 2.0

namespace ASP {
public partial class Webform1_aspx
{
}
}

El desarrollador puede tener acceso a Label1 de manera automática y agregar todos los eventos necesarios. Por ejemplo, se puede agregar un evento Page_Load que inicialice la etiqueta.

Complejidad de la herencia

El
nuevo modelo de código subyacente reduce en gran medida la complejidad
de la herencia. Como la página ASPX no se hereda directamente del
archivo de código subyacente, ya no es necesario que este archivo
defina ni admita todos los controles definidos en la página ASPX. De
manera similar, el archivo de código subyacente puede obtener acceso
automáticamente a todos los controles de la página ASPX sin que sea
preciso el código de declaración, que era necesario en ASP.NET 1.x.
Todo esto es posible gracias a que el tiempo de ejecución de ASP.NET
inserta automáticamente la declaración necesaria y el código de
conexión de eventos en el archivo compilado final. Como el tiempo de
ejecución asume dicha responsabilidad, ni el desarrollador de código ni
el desarrollador Web deben preocuparse por ello.

Durante
el tiempo de diseño, esta vinculación la mantiene Visual Studio 2005.
El entorno de Visual Studio aprovecha el elemento de compilación del
tiempo de ejecución de ASP.NET para asegurarse de que el desarrollador
de código y el desarrollador Web puedan trabajar de forma sincronizada.

Complejidad de la compilación

Como
el nuevo archivo de código subyacente se une a la página ASPX y se
compila en una única clase completa en tiempo de ejecución, la
complejidad de la compilación desaparece. Es decir, el archivo de
código subyacente queda sincronizado automáticamente con la página
ASPX. Incluso con el nuevo modelo de compilación sigue siendo posible
tener código que no esté sincronizado, pero el problema puede
localizarse rápidamente ya que la excepción resultante es mucho más
explícita.

Aunque este
modelo tiene ventajas, también tiene dos inconvenientes básicos. En
primer lugar, las páginas ASPX deben implementarse en el sitio Web con
un formato humanamente legible. Si los desarrolladores utilizan el
modelo de código en línea, esto implica que toda la lógica
empresarial o parte de ella también se puede implementar en un servidor
de producción. Aunque IIS y ASP.NET están configurados para no exponer
las páginas ASPX sin procesar, un usuario malintencionado podría seguir
obteniendo acceso a los archivos mediante cualquier vulnerabilidad que
le permitiese tener acceso al servidor Web. En segundo lugar, la
primera vez que alguien solicite una página Web, la respuesta será más
lenta de lo normal, ya que el tiempo de ejecución de ASP.NET tendrá que
compilar la página ASPX.

El único control que tiene
un desarrollador sobre este proceso consiste en decidir si compila o no
por lotes las páginas ASPX. En ASP.NET 1.x, se puede configurar la compilación por lotes en el archivo web.config modificando la etiqueta <compilation>.

Listado 4. Configuración de la compilación por lotes

<compilation  
batch="true|false"
batchTimeout="number of seconds"
maxBatchSize="maximum number of pages per batched compilation"
maxBatchGeneratedFileSize="maximum combined size (in KB) of the
generated source file per batched compilation"
</compilation>

La compilación por lotes busca un equilibro,
respecto al tiempo de arranque para obtener un tiempo de carga
reducido, en la primera solicitud de una página Web. La otra ventaja de
la compilación por lotes es que todos los archivos ASPX se compilan en
un único ensamblado temporal en vez de compilar un ensamblado temporal
por página.

Compilación en ASP.NET 2.0

ASP.NET 2.0 ofrece cuatro modelos de compilación diferentes para una aplicación Web:

  • Normal (ASP.NET 1.x):
    en una aplicación Web ASP.NET normal, los archivos de código subyacente
    se compilaban en un ensamblado y se almacenaban en el directorio /bin.
    Las páginas Web (ASPX) se compilaban a medida que se solicitaban. Este
    modelo funcionaba correctamente para la mayoría de los sitios Web. Sin
    embargo, el proceso de compilación hacía que la primera solicitud de
    cualquier página ASP.NET fuera más lenta que las solicitudes
    posteriores. ASP.NET 2.0 continúa admitiendo este modelo de
    compilación.

  • Compilación por lotes: en ASP.NET 2.0, puede
    compilar por lotes cualquier aplicación con una única solicitud URL. Al
    igual que ocurría con ASP.NET 1.x, la compilación por lotes
    elimina la demora de la primera solicitud de página, pero crea un ciclo
    vital más largo durante el inicio. Además, la compilación por lotes
    sigue requiriendo que los archivos de código subyacente se compilen
    antes de la implementación.

  • Compilación antes de la implementación: una
    nueva característica de ASP.NET 2.0 que permite realizar la compilación
    completa del proyecto antes de la implementación. En la compilación
    completa, todos los archivos de código subyacente, las páginas ASPX,
    HTML, recursos gráficos y demás código de servidor se compilan en uno o
    más ensamblados ejecutables, dependiendo del tamaño de la aplicación y
    de la configuración de la compilación. Los ensamblados contienen todo
    el código compilado del sitio Web y los archivos de recursos y de
    configuración se copian sin modificación. Este método de compilación
    proporciona una seguridad y un rendimiento máximos, al precio de
    eliminar toda posibilidad de modificar el sitio Web tras su
    implementación. Si está trabajando con sitios Web muy seguros o muy
    visibles, esta opción es la mejor opción para la implementación final.
    Sin embargo, si está creando un pequeño sitio que se ejecuta en su
    intranet local y el sitio cambia con frecuencia, la precompilación
    completa puede ser una exageración.

  • Compilación completa en tiempo de ejecución:
    en el otro extremo de la compilación antes de la implementación,
    ASP.NET 2.0 proporciona un nuevo mecanismo para compilar toda la
    aplicación en tiempo de ejecución. Es decir, puede colocar los archivos
    de código subyacente sin compilar, así como todo el resto del código
    asociado, en el nuevo directorio de código y permitir que ASP.NET 2.0
    cree y mantenga las referencias al ensamblado que se generarán a partir
    de estos archivos en tiempo de ejecución. Esta opción ofrece la mayor
    flexibilidad en lo que se refiere a la modificación del contenido del
    sitio Web, pero al precio de almacenar el código sin compilar en el
    servidor.

Elegir la mejor opción de
compilación dependerá de sus circunstancias y necesidades concretas,
pero el modelo de compilación sigue siendo flexible. Incluso si decide
utilizar el directorio de código para almacenar los archivos de código
subyacente, podrá seguir implementando la aplicación mediante el método
de compilación completa.

Compilación por lotes

La
configuración de compilación por lotes de web.config sigue funcionando
en ASP.NET 2.0. Las ventajas de la compilación por lotes son que las
páginas están inmediatamente disponibles para el primer usuario y que
todos los errores de las páginas ASPX se detectarán durante la
compilación por lotes. Sin embargo, la compilación por lotes agrega un
retraso al inicio de la aplicación y se debe incluir en el archivo
web.config.

Compilación antes de la implementación

La
compilación antes de la implementación permite crear uno o varios
ensamblados que son una versión ejecutable del sitio Web. Los
ensamblados resultantes contienen el código compilado para el sitio
Web. Las páginas HTML, los recursos, los archivos de configuración y
las páginas ASPX se copian por separado.

La
compilación antes de la implementación requiere el uso de una utilidad
de línea de comandos denominada aspnet_compiler.exe. Esta utilidad crea
un directorio de implementación de destino que contiene un directorio /bin
con ensamblados y archivos auxiliares de las diferentes páginas ASPX.
También se puede utilizar esta utilidad para realizar una
precompilación en el lugar, lo que es similar a llamar a la "página
mágica". Los archivos auxiliares comparten los nombres de las páginas
ASPX, pero contienen código simple que llama al ensamblado compilado.
Es decir, las páginas ASPX son sencillamente armazones vacíos en vez de
páginas completamente funcionales.

Si se
precompila el sitio Web para su implementación, se consigue una mayor
seguridad ya que no es posible obtener acceso a parte alguna del código
sin descompilar el ensamblado. Para aumentar la protección, puede
proteger el ensamblado resultante y hacer que la aplicación Web sea
todavía más segura. Los principales inconvenientes de la compilación
antes de la implementación son que es necesario realizar estos pasos
antes de la implementación y que no se puede cambiar el sitio Web
después de que se haya implementado. Si quiere realizar cambios, deberá
compilar de nuevo el sitio Web y volver a implementarlo.

Para
la mayoría de las aplicaciones Web más importantes, la opción de
compilar antes de implementar será el mecanismo preferido para la
implementación, ya que reduce la cantidad de código sin procesar que se
implementa en el servidor Web y ofrece la mayor seguridad. El
incremento de proceso se puede incorporar al ciclo normal de
desarrollo/prueba/implementación sin ninguna perdida significativa de
productividad.

Compilación completa en tiempo de ejecución (el directorio de código)

En
los tres métodos de compilación descritos hasta ahora, era necesario
compilar todos los archivos de código (código subyacente y clases
necesarias) antes de la implementación. En ASP.NET 2.0 se dispone del
directorio de código.

El directorio de código es un
directorio especial que contiene las clases sin compilar. En tiempo de
ejecución, el tiempo de ejecución de ASP.NET compila el contenido de
este directorio en un ensamblado al que hacen referencia de manera
automática las páginas ASPX de la aplicación. Es decir, mediante el
directorio de código, puede evitar crear y hacer referencia a
ensamblados diferentes para el código necesario. La ventaja del
directorio de código es que puede realizar la implementación sin
compilar completamente el proyecto, lo que reduce por tanto los
posibles fallos de coincidencia. El inconveniente es que está
exponiendo potencialmente el código sin compilar en el servidor.

Esta
opción funciona mejor para las aplicaciones ASP.NET que no precisan una
gran cantidad de código necesario (ya sea en forma de archivos de
código subyacente o bien objetos externos). Para una aplicación
sencilla, la posibilidad de implementar y probar con rapidez el sistema
proporciona varias ventajas sobre otros métodos de compilación más
robustos.

Informática e Internet

Office PerformancePoint Server 2007 – Introducción

El 19 de septiembre Microsoft lanzó Office PerformancePoint Server 2007 y promete mejoras significativas al panorama del Business Intelligence (BI).

PerformancePoint Server 2007 ayuda a las organizaciones a alinear sus procesos optimizando en una sola aplicación las actividades de monitoreo, análisis y planificación necesarias para mejorar el desempeño empresarial.

Al implementar PerformancePoint Server 2007, las empresas pueden obtener mejores resultados permitiendo a los individuos de toda una organización que mejoren su desempeño.

Por su parte, SQL Server 2008 –que estará disponible a partir del segundo trimestre de 2008– ayudará a las empresas a brindar una plataforma de datos más segura y confiable para almacenar información crítica para el negocio y entregar la información correcta a todos los usuarios, al mismo tiempo que se reduce el tiempo y costo de la administración de datos.

PerformancePoint Server está fuertemente integrado con el sistema familiar y fácil de usar que brinda Microsoft Office, lo que permite a las organizaciones alinear de una mejor forma a los empleados de todas las divisiones y hacerlos responsables por sus acciones. Asimismo, aprovecha la confiabilidad de nivel empresarial, el alto desempeño, la tecnología segura y la escalabilidad de SQL Server 2005, permitiendo que más gente en todos los niveles de la organización transformen datos empresariales distintos en información compartida que puedan usar para tomar mejores decisiones y acciones que mejoren los resultados empresariales.

Como preparación para sus próximos lanzamientos, se liberó el programa Community Technology Preview (CTP) para Microsoft Office PerformancePoint Server 2007, así como la CTP de julio para SQL Server 2008.

La CTP para PerformancePoint Server 2007 está disponible en https://connect.microsoft.com/site/sitehome.aspx?SiteID=181&wa=wsignin1.0 La solución permite a los clientes y socios examinar y emitir su opinión sobre las versiones de prueba más recientes de ambos productos. Por su parte, la CTP de julio para SQL Server 2008 puede descargarse en http://connect.microsoft.com/sqlserver

Informática e Internet

Microsoft afianza su presencia en el mercado de Business Intelligence

El reporte “Worldwide Business Intelligence Tools 2006 Vendor Shares”, realizado por la consultora de mercado IDC, revela que el mercado de Business Intelligence (BI) creció más de 11 por ciento durante el año 2006.

Por su parte, Microsoft tuvo un índice de crecimiento del 28 por ciento, el más alto entre los diez principales proveedores de la industria e IDC lo reconoce como uno de los proveedores de más rápido crecimiento durante el año pasado.

El mercado de herramientas de BI continúa teniendo su impulso por la necesidad de una administración de desempeño mejorada.

“La administración de desempeño puede tomar la forma de varias funciones de decisión-soporte y reporte para mejorar los ingresos, las utilidades y la eficiencia operativa, disminuir los costos, generar nuevas oportunidades o mitigar riesgos”, afirma Dan Vesset, analista de IDC. “Microsoft tuvo otro buen año en este mercado” completa. Asimismo, Microsoft SQL Server 2005 fue reconocido por el reporte On-Line Analytical Processing (OLAP) como el servidor de procesamiento analítico en línea número uno en el mercado.

SQL Server se ha establecido como una plataforma de datos de clase empresarial. Un reciente estudio de BZ Research encontró que el 74,7 por ciento de las empresas usa SQL Server, en comparación con el 54,5 por ciento del competidor más cercano.

La continua inversión de Microsoft para entregar soluciones BI de alto desempeño y bajo costo a todos los usuarios empresariales a través de la experiencia Microsoft Office y SQL Server 2005 ha rendido frutos entre los clientes.

“Por lo general los clientes nos dicen que experimentan un constante flujo de cambios. Tener la capacidad de monitorear el negocio, analizar datos empresariales clave, actuar sobre los mismos y ver resultados en tiempo real da a las compañías la ventaja competitiva que necesitan los negocios para sobrevivir”, afirma Liliana González, gerente de Marketing para Servidores de Aplicaciones para Microsoft Latinoamérica.

“Microsoft brinda la capacidad y confianza para permitir a los empleados de todos los niveles tomar decisiones con más información. Estamos enfocados en ayudar a nuestros clientes a alcanzar niveles más altos de desempeño empresarial permitiéndoles aprovechar las capacidades de BI integrales que ofrece la inteligencia empresarial de Microsoft”, concluye González.

Informática e Internet

Expert Zone de Unified Communications

Con el evento Expert Zone de Unified Communications te invitamos a conocer la nueva propuesta de Microsoft para Comunicaciones Unificadas. Durante el mismo podrás disfrutar de una serie de tracks técnicos ofrecidos por expertos de Microsoft en la tecnología y un amplio número de socios especializados en la materia.

A partir del jueves 18 de octubre, y hasta el 26 del mismo mes, deberás volver a entrar a este sitio, donde ya podrás asistir a cualquiera de las conferencias en línea aquí mencionadas.

El objetivo a cubrir es mostrarte como hacer el despliegue y administración de estas nuevas tecnologías entre las que destacamos – Microsoft Office Communications Server 2007, Microsoft Office Communicator 2007 y Microsoft Office Live Meeting en combinación con Microsoft Exchange Server 2007 – que proporcionarán la base de software para ofrecer servicio de VoIP integrado con la infraestructura existente.

El evento estará orientado a los siguientes productos:

· Microsoft Office Communications Server 2007 (OCS 2007)
· Microsoft Office Communicator 2007 (OC 2007)
· Microsoft Exchange Server 2007 SP1
· Microsoft Office Live Meeting 2007 (OLM 2007)
· Microsoft Exchange Hosted Services (EHS)
· Microsoft Round Table
· UC Devices: IP Phones
· UC 5 Start program announcement
· IP Phone Devices – Partner driven
· Mobility and Anywhere Access
· The UC Administration Experience
· End-User VOIP Experience · VOIP Architecture
· VOIP Topologies and Interoperability
· OCS 2007 Deployment
· Exchange
Server 2007 SP1 Overview