PON: P2P Over .NET PON: P2P Over .NET

Transcripción

nº13 marzo 2005 • 6,00 € (España)
Visual Basic.NET • C# • Delphi • ASP.NET • ADO.NET • .NET Framework • Windows Server System
dotNetManía
www.dotnetmania.com
Dedicada a los profesionales de la plataforma .NET
PON: P2P Over .NET
Una plataforma para redes punto a punto basada en .NET
Entrevista a Prashant Sridharan
Lead Program Manager del equipo de desarrollo de Visual Studio 2005
Construcción de clientes FTP utilizando .NET Framework •
Creación y uso de servicios Web desde entornos tradicionales •
Sistemas distribuidos en .NET con Remoting (II) •
Interoperabilidad no administrada y migración (II) •
SQL Server Analysis Services.
¡Hola cubo! (y IV)
MVP Online
Creación de bordes redondeados
en WebForms: RoundedCorners
TodotNet Q&A
Diálogo concerniente a los
principales sistemas mundiales
y sus diseños arquitectónicos
Laboratorio
Web.Config Editor 2.0
legal
Uso no autorizado de redes WIFI: Consecuencias en el ámbito penal
dnm.editorial
dotNetManía
Rumores 2005... beta 2
Vol. II •Número 13 • Marzo 2005
Precio: 6€ (España)
Editor
Paco Marín
([email protected])
Administración
Pilar Pérez
([email protected])
Asesor Técnico/Coordinación
Marino Posadas
([email protected])
Redactores
Antonio Quirós, Dino Esposito, Guillermo
'guille' Som, Jorge Serrano, José Manuel
Alarcón, Luis Miguel Blanco, Manuel Imaz y
Pedro Pozo.
Colaboradores habituales
Ángel Esteban, Braulio Díez, Eladio Rincón,
Erich Bühler, Fernando Nogueras, Jorge
Crespo Cano, José Miguel Torres, Miguel
Egea, Miguel Katrib Mora (Grupo Weboo),
Octavio Hernández, Pablo Abbate, Pepe
Hevia, Rodrigo Corral y Salvador Ramos.
Además colabora en este número
José Antonio Suárez de la Dehesa
Edición y Suscripciones
.netalia
c/ Robledal, 135
28529 Rivas-Vaciamadrid (Madrid)
Tf. (34) 91 666 74 77
Fax (34) 91 499 13 64
Publicidad
Mediadev
Sophie Mancini ([email protected])
Tf. 93 426 22 57 - 670 99 74 64
Fax. 93 423 11 40
Imprime
Gráficas Vallehermoso
www.graficasvallehermoso.com
ISSN
1698-5451
Depósito Legal
M-3.075-2004
<<
Este año va a ser divertido en cuanto a
rumores y declaraciones de intenciones sobre
lanzamientos de versiones betas, CTPs, candidate releases y de versiones finales. Y para
muestra lo que sigue:
El rumor más espectacular y que más ha
corrido es el del supuesto nombre final de
Longhorn: Windows e-XPedition. Parte de
Wil Harris de The Inquirer (http://www.theinquirer.net/?article=21365). Cita fuentes de
Microsoft sin decir cuáles, o sea, “rumor” en
versión alfa. Y yo que no me lo creo... (queda
impreso y podrás reirte de mí cuando veas
en la caja en letras grandes: Windows
e-XPedition). “Se dice” que se lanzará una
versión de Longhorn para desarrolladores a
finales de abril 2005, en el WinHEC, así como
que posiblemente en el verano tengamos una
versión beta 1.
Y para rumores, los relativos a la beta 3 de
SQL Server 2005. Éstos apuntaban a que la
beta 3 podría estar el 31 de marzo, pero a nadie
le sorprendería que los primeros en verla sean
los asistentes a los Tech-Eds a finales de junio
de este año.
Después del VSLive! de San Francisco,
tenemos también una pequeña tanda de fechas
de publicación de versiones más. En marzo
tendremos una versión CTP de WinFX, que
incluirá una actualización de la CTP de Avalon
de noviembre, una nueva versión CTP de
Indigo y una build de Visual Studio 2005 (que
no sabemos aún si será la beta 2, que Bill
Gates, entre otros, dice que está prevista para
el 31 de marzo), según Soma Somasegar, vicepresidente de Microsoft Corp. de Developer Division
y Eric Rudder, vicepresidente senior de la divi-
sión de Servidores y Herramientas, quien bromeó diciendo que estarán en marzo... aunque
sea el 38 de marzo (¿noticia o declaración de
intenciones, entonces?). Algo se comenta en
el desván de este mes, pero si tienes más interés en la actual versión de “rumores”, puedes
leerte la entrevista a Soma Somasegar que se
publica en eWeek, en: http://www.eweek.com/
article2/0,1759,1757521,00.asp o visitar el sitio
de VSLive! en: http://www.ftponline.com/reports/
vslivesf/2005.
El mes pasado publicábamos, citando
fuentes oficiales, que en febrero estarían disponibles las versiones CTP de Indigo y Visual
Studio 2005. Pues no, como puede verse no
ha sido así. Y es que hemos de tomarnos éstos
como lo que son: simples rumores, algo así
como la versión beta de la noticia... y, por tanto, falibles. Ya falta poco, debemos estar ya en
la beta 2 de los rumores de 2005.
En este mes publicamos una entrevista a
Prashant Sridharan, Lead Program Manager
del equipo de desarrollo de Visual Studio 2005,
con el que tuvimos la ocasión de charlar sobre
la que fue la primera y, por muy poco tiempo,
última beta de Visual Studio 2005. Con ésta
cerramos un ciclo de entrevistas en las que
todavía hablamos de esta versión.
Además, en este número estrenamos una
sección que vamos a dedicar a los asuntos legales que a la mayoría de los profesionales de TI
pueden interesar y que hemos denominado,
en un alarde de originalidad: dnm.legal.
Contaremos con la colaboración del despacho
de abogados Suárez de la Dehesa Abogados,
especializado en propiedad intelectual e industrial y nuevas tecnologías.
<<dotNetManía
Dedicada a los profesionales de la plataforma .NET
3
13
dnm.sumario
10-11
En el pasado Tech-Ed tuvimos la ocasión de charlar largo y tendido con Prashant Sridaran,
Lead Program Manager del equipo de desarrollo de Visual Studio 2005. Pusimos especial
énfasis en lo nuevo que nos ofrecía la que por entonces sería la primera beta estable.
Construcción de clientes FTP utilizando .NET Framework
13-18
En este artículo se explican los conceptos básicos de las clases de la infraestructura
para gestión de red, así como también la forma de programar un cliente FTP utilizando
.NET framework versión 1.0 ó 1.1.
Creación y uso de servicios Web desde entornos tradicionales
19-23
Con tanto bullicio generado alrededor de los servicios Web parece que los programadores
de toda la vida (sí, los que usan COM y/o lenguajes de Script, por ejemplo) se han quedado
fuera de la nueva onda. Sin embargo .NET ofrece soluciones para todo el mundo, incluso
para aquellos que no saben nada de .NET. En este artículo veremos cómo dar el salto al
mundo de los servicios Web desde lenguajes tradicionales como Visual Basic 6.0, usando
de manera indirecta .NET pero sin tener que aprender nada nuevo.
PON : P2P Over .NET.
24-32
El artículo presenta a PON (Peer to peer Over .NET): una plataforma implementada
sobre la tecnología .NET, la cual permite el desarrollo de comunidades de nodos .NET.
Con esta plataforma se da la posibilidad de conectar aplicaciones diferentes formando
redes de intercambio aún más universales.
dnm.sumario
Sistemas distribuidos en .NET con Remoting (II)
33-36
Después de los conceptos sobre la arquitectura de .NET Remoting que vimos en la anterior
entrega, podemos zambullirnos por completo en la creación de objetos remotos. En este
capítulo veremos un tema vital, los diferentes comportamientos que pueden presentar los
objetos remotos en .NET Remoting. A menudo la primera decisión que tenemos que tomar
a la hora de diseñar un objeto remoto o una familia de objetos es elegir el modelo de
comportamiento de los mismos.
Interoperabilidad no administrada y migración (II)
37-39
La interoperabilidad de .NET desde COM es quizás mas inusual aunque sus ventajas
nos ofrecen una nueva técnica en un entorno de migración e interoperabilidad. En esta
entrega conoceremos cómo utilizar dicha técnica además de las consideraciones previas
para interoperar de una manera más eficiente.
SQL Server Analysis Services. ¡Hola Cubo! (y IV)
40-45
Llegó el momento de explotar los datos almacenados en nuestra base de datos
multidimensional, desde algunas de las herramientas cliente que Microsoft nos ofrece para
ello. Aquí mostraremos el Examinador de cubos del Analysis Manager, Microsoft Excel
utilizando el PivotTable Service, la aplicación de ejemplo que viene con Analsys Services
y Microsoft Data Analyzer.
Uso no autorizado de redes WIFI: Consecuencias en el ámbito penal
46-47
En los últimos apenas dos años hemos podido advertir la aparición, ya con verdaderamente
relevante, de sistemas de comunicaciones inalámbricas, que permiten el acceso a Internet
en entornos más o menos amplios, y que, en no pocas ocasiones, exceden el ámbito de
establecimiento del titular de la red.
dnm.mvp.online
48-51
Creación de bordes redondeados en WebForms: RoundedCorners
dnm.todotnet.qa
52-54
Diálogo concerniente a los principales sistemas mundiales y sus diseños arquitectónicos
dnm.laboratorio
55-56
dnm.biblioteca.net
57
Introducing Microsoft .NET (David Platt)
Inside Microsoft Visual Studio .NET (Brian Johnson, Craig Skibo, Marc Young)
dnm.desvan
58
dnm.noticias
6
noticias.noticias.noticias.noticias.noticias.noticias
<< dotNetManía
<< dnm.noticias
El ASP.NET 2.0 Tour llega a España
La gira europea ASP.NET 2.0 Tour llegó a Madrid para presentar la última
versión de la tecnología en desarrollo Web de Microsoft
Microsoft celebró el pasado 21 de febrero en
Madrid, un evento para mostrar a la comunidad de
desarrolladores española las últimas novedades en la
tecnología ASP.NET. Asistieron alrededor de 200 desarrolladores que pudieron ver la primera demostración
en directo en España de las novedades en herramientas de desarrollo Visual Studio 2005, ASP.NET 2.0
para desarrollo Web y Visual Studio 2005 Team System.
Los asistentes tuvieron la oportunidad de comprobar los cambios realizados en la estructura básica de
ASP.NET a través de las ponencias de Eric Rudder,
vicepresidente senior de
la división de Servidores
y Herramientas y Brian
Goldfarb, jefe de producto del equipo de
Herramientas y Plataforma de Microsoft.
Esta sesión del
ASP.NET 2.0 Tour forEric Rudder
ma parte de una gira
por 17 ciudades europeas en la que los mayores expertos
en ASP.NET de todo el mundo muestran en directo y
por primera vez la última versión de la tecnología
Microsoft en desarrollo Web.
Los desarrolladores tuvieron la oportunidad de
ver las presentaciones y demostraciones en las que
se mostraban las novedades de ASP.NET 2.0, entre
las que caben destacar: la mejora en el diseño de la
capa de presentación, las master pages y los temas,
las mejoras en el editor -especialmente en lo que
toca a HTML-, la gestión del caché, mejoras en la
seguridad, en las facilidades para la localización de
aplicaciones, etc.
Más información en: http://www.microsoft.com/
emea/msdn/aspontour
Bowne Global Solutions localizará Visual Studio
2005 en los principales idiomas
El proyecto de localización de Visual Studio 2005 a los idomas más
importantes se hará entre Madrid, Beijing y Taipei
La empresa Bowne Global
Solutions (BGS) será la encargada de la localización de Visual
Studio 2005 en ocho idiomas: japonés, chino simplificado, chino tradicional, coreano, francés, italiano,
alemán y español. Ésta es ya la tercera versión de Visual Studio, después de las anteriores 2002 y 2003,
que BGS localiza para Microsoft.
El proyecto contará con un
equipo de más de 400 personas
entre jefes de proyecto, localizadores especializados en software y
documentación de ayudas, traductores, revisores, expertos en
la materia, especialistas en maquetación, ingenieros y comprobadores (testers). El proyecto tiene un
ámbito global pero cuenta con traductores localizados en cada país
para conseguir la redacción más
acertada y respetuosa con cada cultura. La gestión global del proyecto se hará en Madrid y Taipei
(Taiwan), mientras que el testing y
la ingeniería se hará entre Madrid
y Beijing (China).
Según Jim Fagan, presidente
y CEO de BGS, “BGS es la única
compañía que puede aportar el
número de especialistas que se precisan a esta escala -dada la complejidad de la materia- a lo largo de ocho
idiomas, incluyendo localizadores que
están especializados en software.
Nosotros tenemos la experiencia, los
métodos y las personas que garantizarán el éxito del proyecto”.
dotNetManía, colaborará con
BGS en calidad de expertos en la
materia para la versión en castellano de Visual Studio 2005, apoyando a los traductores en la traducción de términos, así como en la
fase de testing.
<< dnm.noticias
Crystal Reports 11 incluye más de 50 nuevas funciones
y nuevas características que aumentan la flexibilidad y
disminuyen la carga de trabajo de los desarrolladores
Crystal Reports XI aporta las
siguientes características nuevas:
• Crystal Reports XI proporciona a
los desarrolladores drivers de datos
mejorados que hacen más fácil el
acceso a, virtualmente, todas las
fuentes de datos.
• En vez de construir cientos de informes individuales, los desarrolladores pueden ahora ditribuir plantillas
con menús desplegables que permiten a los usuarios finales, personalizar sus informes. Crystal Reports XI
también entrega los informes a los
usuarios finales en formato RTF de
forma que ellos puedan modificarlos fácilmente.
• Crystal Reports XI da a los desarrolladores herramientas con un
diseño intuitivo para la creación de
informes. Por ejemplo, ahora los
desarrolladores pueden previsualizar sus informes en HTML antes de
que sean publicados en la Web y dis-
tribuidos a través de la organización.
Además, la nueva versión evalua
automáticamente los datos del informe y da a los desarrolladores las
opciones de visualización de gráficos más apropiadas.
• La nueva versión de Crystal
Reports también da a los desarrolladores una zona de trabajo virtual
en al que puedan organizar informes, así como decidir cómo agendarlos, gestionarlos, distribuirlos y
asegurar su acceso.
Más información: http://www.businessobjects.com o en http://www.abox.com
Patterns & practices Enterprise Library
y Connected Systems Business Kit
Microsoft ha anunciado la disponibilidad de estos nuevos
recursos para desarrolladores empresariales que quieran
construir sistemas conectados
Enterprise Library es una
colección de 7 bloques de aplicación (applications blocks) con
código fuente que puede ser usado “tal cual”, ampliardo o modificado por los
desarrolladores para usarlo en sus proyectos
empresariales. Enterprise Library tiene versiones nuevas y actualizadas de los bloques de aplicación que actualmente se distribuían por separado. Todos los bloques de aplicación de
Enterprise Library han sido actualizados focalizando particularmente en la consistencia, extensibilidad, faciliad de uso e integración.
Los bloques de Enterprise Library te ayudarán en los siguientes escenarios: caching,
configuración, criptografía, acceso a datos,
manejo de excepciones, acceso de usuarios y
seguridad.
La siguiente versión de Enterprise Library
estará disponible próximamente, junto con el
lanzamiento del Framework .NET 2.0 y Visual
Studio 2005. Más información y descargas en:
http://www.microsoft.com/practices.
Connected Systems Business Kit es una colección de aplicaciones de ejemplo, presentaciones, white papers y vídeos que ilustran cómo
implementar sistemas conectados y arquitecturas orientadas a servicios usando las tecnologías actuales. Puede pedirse gratuitamente en:
http://www.microsoft.com/connectedsystems
dotNetSolidario inagura su Web
El 4 marzo dotNetSolidario inauguró su Web en www.dotnetsolidario.com, a
través de la cual se dará a conocer las
acciones solidarias relacionadas con las
tecnologías de la información. Este portal nace con la intención de darle un lado
más humano a la tecnología y, gracias a la
utilización de la misma, conseguir ayudar
a los más necesitados y promover acciones solidarias. Además, a través de este
portal se ofrecerán servicios gratuitos para
ONG's como hosting, desarrollos Web,
software y formación, entre otros.
Más información en: http://www.dotnetsolidario.com
Microsoft pone en marcha un
programa de becas para estudiantes de postgrado
Microsoft ha puesto en marcha el programa de becas de postgrado de Microsoft
Research, un proyecto que refuerza el
papel de la compañía en el ámbito académico, y que se centra en reconocer y apoyar a aquellos estudiantes de tercer ciclo
que destaquen en sus áreas de investigación, y que posean el potencial para convertirse en relevantes líderes científicos de
la Europa del futuro.
Este programa ofrece apoyo a estudiantes de informática, matemáticas,
ingeniería electrónica y física. Asimismo
y de manera especial, presta ayuda en su
investigación a los alumnos de las áreas
de biología, químicas, neurociencia,
inmunología, ciencias sociales, económicas y ecología, que sientan especial
interés por la ciencia.
Podrán optar a estas becas todos los
estudiantes europeos de tercer ciclo, o
aquellos que hayan solicitado su admisión en estudios de postgrado de alguna
universidad europea y que comiencen a
cursarlos a partir del mes de octubre de
2005. Los alumnos que formen parte del
programa de Microsoft Research recibirán, durante tres años, una beca de
90.000 euros.
En los próximos dos años el programa
de ayuda a alumnos de postgrado de
Microsoft apoyará a no menos de cien estudiantes, potenciando así el desarrollo intelectual de los investigadores europeos.
dnm.noticias
<< dotNetManía
Business Objects anuncia Crystal
Reports 11
7
dnm.directo.entrevistas
Marino Posadas
Lead Program Manager del equipo de desarrollo de Visual Studio 2005
En el pasado Tech-Ed tuvimos la ocasión de charlar largo y tendido con Prashant
Sridaran, Lead Program Manager del equipo de desarrollo de Visual Studio 2005,
quien fue, además, uno de los ponentes principales en la conferencia de bienvenida (Keynote). Pusimos especial énfasis en lo nuevo que nos ofrecía la que
por entonces sería la primera beta estable.
<< Habéis anunciado una nueva versión de Visual Studio para
Marino Posadas es
asesor técnico y
redactor de
dotNetManía, MVP de
C# y formador de
Alhambra-Eidos
el final de este Tech-Ed, incluyendo muchas características nuevas. ¿Podrías resumirnos las más importantes en comparación con previews anteriores?
Se trata de algo más que de una Community
Technology Preview. Es una beta estable, en la que se
ha invertido ya bastante tiempo en las pruebas, y como
elemento más importante, cabría destacar la presencia del llamado Visual Studio Team System, el módulo
diseñado para permitir el análisis y diseño de aplicaciones. Esperamos poder publicar una nueva beta para
el fin del verano (2004), y continuar la política de renovaciones hasta la salida final del producto.
¿Podríamos decir que la novedad más importante de esta versión es precisamente ese módulo (o
módulos) que configuran VSTS? ¿Incluso más que
las nuevas características de ASP.NET o los nuevos
conjuntos de controles para Web y Windows?
Una de las cosas en las que nos hemos fijado principalmente a la hora del diseño de esta nueva versión
ha sido en los perfiles de los usuarios potenciales de
Visual Studio. Quiénes lo están usando hoy, y quiénes pueden ser los futuros usuarios. Así que se encuentran temas específicos que interesan al desarrollador
puntual de Visual Basic, o de ASP.NET, y otros que
tienen que ver con agrupaciones o equipos más grandes de desarrollo, sin olvidarnos de estudiantes, aficionados, entusiastas, etc. De forma que hemos intentado un estructura fácil de entender pero al mismo
tiempo potente: que permita a los nuevos usuarios
acercarse al producto de forma fácil, pero que incluya las características que grandes equipos y corporaciones pueden necesitar en la construcción de soft-
ware, incluyendo responsables de operaciones, equipos de testeo, product managers, etc. Esperamos que
el resultado sea un incremento notable de la comunidad de usuarios de Visual Studio, ya que podrán encontrar prácticamente lo que quieran de forma intuitiva,
bien organizada y sin olvidar ninguno de los aspectos
del ciclo de producción de aplicaciones.
A propósito, ¿cuántas personas tienes a tu cargo
en el equipo de desarrollo de Visual Studio?
Bueno, en total vienen a ser unos 3000. Por una parte, están los encargados de los diferentes departamentos
de lenguajes, los encargados de los compiladores, de la
interfaz de usuario, de la integración de elementos, la
localización a diferentes culturas, los responsables del
CLR, las versiones express, y muchos otros. A todo esto
hay que añadir los “evangelistas” y divulgadores de tecnología, personal de marketing, etc.
La nueva versión que estamos comentando, ¿incluirá mejora en la instalación de las aplicaciones? Y en concreto en la distribución de las aplicaciones Web?
Sí. Se ha tenido en cuenta esta necesidad de forma
prioritaria. No sólo se han incluido nuevas características arquitectónicas de solución que pretenden facilitar la distribución de la aplicación, sino que sen han
añadido facilidades especiales, como la posibilidad
“empaquetar” sitios Web, la posibilidad de precompilar los ejecutables, al objeto de obtener los niveles de
rendimiento que se desean, y un conjunto de utilidades añadidas al propio Visual Studio para permitir el
ajuste fino de las aplicaciones.
Otra posibilidad planteada es la de la edición remota. ¿Va a ser eso posible aunque sólo sea para pequeños fragmentos?
<< dnm.directo.entrevistas
No es una pregunta fácil de responder. Creo que muchas compañías deberían plantearse esto, y considerar los problemas de la migración vs. la espera de la
nueva versión. La práctica de este modelo, desde luego, establece una ventaja
estratégica, pero hay que considerar los
conocimientos de los integrantes del equipo de desarrollo, etc. Pero creo que tomar
una decisión en base a Longhorn no es
una forma adecuada de proceder. Lo
mejor es siempre considerar lo que se
necesita en el momento actual y tomar la
decisión de acuerdo con eso.
...hemos intentado un estructura fácil de entender pero
al mismo tiempo potente: que permita a los nuevos
usuarios acercarse al producto de forma fácil, pero
que incluya las características que grandes equipos y
corporaciones pueden necesitar en la construcción
de software, incluyendo responsables de operaciones,
equipos de testeo, product managers, etc.
Eso significa que si la siguiente versión de Visual Studio (Orcas) tiene que
soportar la programación nativa de
Lognhorn, incluirá muchísimos cambios
conceptuales y estructurales, ¿no?
Bueno, indudablemente llevará
muchas cosas nuevas, y el soporte del
nuevo sistema deberá de ser exhaustivo,
pero es muy pronto para hablar de un
producto que está en sus primeras fases
cimiento del lenguaje, de la arquitectura, de los protocolos implicados en las
comunicaciones, y por supuesto de las
herramientas, como Visual Studio, que
sufrirán modificaciones, indudablemente, pero que seguirán mejorando
para presentar al usuario la mejor interfaz de desarrollo posible, y la que mejor
se adapte a las posibilidades y las necesidades de las nuevas plataformas.
<<dotNetManía
Se está pensando sobre esa posibilidad, pero no hemos determinado todavía su viabilidad total para esta versión
de Visual Studio. Pero estamos pensando en ello.
En nuestros días parece inevitable dedicar alguna cuestión a temas de seguridad.
¿Vamos a contar con algún modelo nuevo, o bien con el mismo pero mejorado?
Bueno, esa pregunta sería más bien
para Scott (Gutrie). Es decisión suya y de
su equipo lo que las nuevas características
de seguridad Web vayan a incluir.
¿Y qué hay de los temas de accesibilidad? ¿Habéis seguido los estándares
recomendados por la W3C al respecto?
Es otro de los temas importantes. No
en las versiones express de los productos,
pero en Visual Studio hemos vuelto a
remodelar las características de accesibilidad, y hemos seguido escrupulosamente las recomendaciones de la implementación que sugerían los estándares. Y esto
no es solamente para las aplicaciones Web,
sino que muchas de las características han
sido pensadas para cumplir simultáneamente las necesidades de las aplicaciones
Windows respecto a accesibilidad.
En la actualidad, ya se conocen
muchas características del nuevo sistema operativo, Longhorn, que plantea
un modelo de programación totalmente orientado a objetos, en el que existe
una separación total entre la interfaz de
usuario (escrita en XAML) y el código
funcional. ¿Consideras una buena práctica la migración de aplicaciones a
ASP.NET que ya soporta ese modelo
de programación, como forma de anticiparse estratégicamente a lo que nos
espera con el nuevo sistema?
de desarrollo en este momento. Preferiría
posponer estas cuestiones para más adelante, si no te importa…) No obstante,
sí que puedo decirte que hay algo que los
clientes deberían hacer de cara a que la
migración a Longhorn les resulte lo más
fácil posible. Me refiero la construcción
de sistemas basados en los servicios Web
y la arquitectura SOA.
Longhorn, sin ningún género de
dudas está basado en eso, y la propia
arquitectura permitirá que la integración de lo existente, si sigue estos patrones sea mucho más sencilla. Tanto las
aplicaciones ASP.NET como las basadas en Windows, van a funcionar en
Longhorn. Ahora, está claro que va a
ser un gran cambio. La gente tendría
que aprender las nuevas tecnologías asociadas a esa forma de construir y utilizar el software, que conllevará inmensas ventajas, pero también va a requerir
de un reciclaje formativo y operativo
importante, si se quieren aprovechar
todas las posibilidades.
Así que, mis consejos finales a este
respecto, no irían encaminados a características punteras de un producto concreto, sino a tecnologías más globales.
Siempre va a ser positivo un buen cono-
11
dnm.comunicaciones
Erich Bühler
Construcción de clientes FTP
utilizando .NET Framework
En este artículo se explican los conceptos básicos de las clases de la infraestructura para gestión de red, así como también la forma de programar un cliente FTP
utilizando .NET framework versión 1.0 ó 1.1.
<< Utilidad del protocolo FTP
Figura 1. Cliente desarrollado en .NET framework
configuración de seguridad existen varios puntos del
protocolo que pueden dejar puertas abiertas y de esta
forma hacerlo vulnerable.
Antes de dar un vistazo a las clases de .NET
Framework vamos a repasar el funcionamiento del
protocolo, lo que nos ayudará posteriormente a
comprender la utilidad y los ejemplos. De más está
decir que al final de este artículo habremos creado una aplicación administrada (.NET) que podrá
enviar a través de la red uno o más archivos a un
servidor remoto. Pero antes de nadar en las clases,
métodos y propiedades de la infraestructura, veamos el funcionamiento de FTP.
<<dotNetManía
Erich Bühler
colabora habitualmente con
dotNetManía. Es .NET
Framework MVP, MCSD, autor
de varios libros de programación
y webmaster de vblibros.com
File Transfer Protocol o FTP pertenece a la familia de los protocolos de Internet y desde el año 1971
es el favorito para la transferencia de archivos entre
ordenadores. A diferencia de otras tecnologías, ésta
no está diseñada para permitir el acceso a otra máquina con el fin de ejecutar programas. Si se desea este
fin, entonces se deberán utilizar los servicios de
Telnet, DCOM, o .NET Remoting.
Actualmente todos los servidores Web ofrecen
un servicio FTP que puede ser configurado fácilmente. Como contrapartida, Microsoft brinda las
extensiones de FrontPage, las que ofrecen características de funcionalidad similar. Sin embargo, y a mi
criterio, FTP tiene actualmente dos ventajas importantes para el desarrollador: la primera radica en que
se cuenta con una interfaz de línea de comandos para
interactuar con el protocolo, lo que ofrece un nivel
de detalle mayor; por su parte, la segunda es que configura un estándar abierto y bien documentado, por
lo que es relativamente sencillo construir o integrar
a las aplicaciones las características de FTP tanto para
enviar o recibir archivos.
Además de los beneficios propios de transmitir
archivos a través de una red, un cliente FTP constituye un excelente ejemplo para aprender más .NET
Framework, debido a que ayuda a conocer algunas
de las clases de la infraestructura para transmisión de
información a través de una red.
Debo sin embargo destacar que pese a ser un buen
candidato para utilizar en una red interna o Intranet,
no recomiendo que se emplee en un entorno abierto (Internet), ya que si no se cuenta con una buena
13
<< dnm.comunicaciones
¿Cómo funciona FTP?
Para establecer una sesión con un
servidor FTP es necesario disponer de
un programa cliente específico –en
Windows se incluye uno llamado
FTP.EXE– o bien utilizar el explorador.
Para el primer caso es necesario conocer una serie de comandos que permiten interactuar con el servidor FTP.
Sin embargo, si se utiliza un navegador, se llevan adelante todas las operaciones de forma automática y totalmente transparente, aunque sin demasiado control.
El nombre del servidor o dirección
IP, así como el usuario y contraseña,
serán nuestro punto de partida y puerta de entrada. Básicamente, establecer
una sesión implica abrir un puerto de
nuestro ordenador –normalmente
mayor al 1024– a través del cual se
enviarán los comandos al puerto 21
del servidor, así como también un
puerto adicional para la transmisión
de datos, el que se conectará al puerto 20 del servidor. La figura 2 muestra la interacción entre los diferentes
puertos.
ftp> open www.miservido.com
Connected to www.miservidor.com.
220 Microsoft FTP Service
User (127.0.0.1:(none)): Anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password: [email protected]
230 Anonymous user logged in.
ftp> cd ArchivosdeGuillermoPuertas
ftp>
Fuente 1
el administrador conozca algo de sobre
el usuario conectado. Una vez establecida la conexión es posible comenzar a
ftp> help
Commands may be abbreviated. Commands are:
!
?
append
ascii
bell
binary
bye
cd
close
ftp>
delete
debug
dir
disconnect
get
glob
hash
help
lcd
literal
ls
mdelete
mdir
mget
mkdir
mls
mput
open
<<dotNetManía
14
prompt
put
pwd
quit
quote
recv
remotehelp
rename
rmdir
send
status
trace
type
user
verbose
Fuente 2. Comandos del cliente FTP de Windows XP.
Figura 2. Funcionamiento de FTP.
El puerto 21 del servidor es el encargado de recepcionar los comandos y
enviar las respuestas de la ejecución al
cliente, mientras que a través del puerto 20 se envían o reciben datos. El fuente 1 nos muestra un ejemplo sencillo de
utilización de comandos mediante el
cliente FTP de Windows XP.
Si es que el servidor acepta conexiones anónimas es posible ingresar
como nombre de usuario la palabra
Anonymous. Normalmente como contraseña se escribe un mail, con el fin de que
éstos, el cliente FTP lo traduce a una
o más instrucciones “especiales” que
son entendidas por el servidor. Esto
utilizar los comandos, los que en parte
se parecen en mucho a los de MS-DOS
debido a que FTP comenzó como un
servicio de UNIX. Para conocer la lista de comandos soportados es necesario escribir la palabra Help o Help <nombre del comando> (ver fuente 2).
Los que aquí vemos son los llamados “comandos amigables” ya que pertenecen a la aplicación cliente de FTP
(en este caso de Windows XP) y no
son finalmente los que se envían al servidor. Cada vez que se ingresa uno de
se ha hecho así para evitar que el usuario lidie con comandos y sentencias
complejas. Para un listado de los
comandos de servidor basta con escribir en la consola la palabra RemoteHelp
(tabla 1).
El motivo real de conocer la lista de
comandos del servidor es que cuando nos
conectemos utilizando la aplicación construida en .NET Framework no dispondremos de la opción amigable o del cliente, y debido a ello tendremos que indicar
lo que deseamos hacer mediante comandos de servidor. No se asuste por lo mal
que se ven y lo poco comprensible que
parecen ya que afortunadamente sólo
haremos uso de unos pocos, aunque si la
curiosidad puede más, en la siguiente
dirección podrá encontrar el detalle de los
mismos: http://www.nsftools.com/tips/
MSFTP.htm
También podemos escribir instrucciones de servidor en la aplicación
cliente de FTP, lo que nos facilitará
saber cómo funcionan y se comportan.
Para dicho fin se debe agregar la pala-
ABOR
ACCT
ALLO
APPE
CDUP
CWD
DELE
HELP
LIST
MDTM
MKD
MODE
NLST
NOOP
PASS
PASV
PORT
PWD
QUIT
REIN
REST
RETR
RMD
RNFR
RNTO
SITE
SIZE
SMNT
STAT
STOR
STOU
STRU
SYST
TYPE
USER
XCUP
XCWD
XMKD
XPWD
XRMD
Tabla 1. Lista de comandos del servidor.
private Socket socketCliente = null;
this.socketCliente = new
Socket(AddressFamily.InterNetwork,
SocketType.Stream, ProtocolType.Tcp );
El primer parámetro corresponde
al tipo de protocolo a emplear. La
tabla 2 muestra alguno de los valores
posibles.
ftp> open www.miservidor.com
Connected to www.miservidor.com.
220 Microsoft FTP Service
Fuente 3
Abriendo una conexión de
TCP/IP desde .NET framework
Para poder transmitir datos a través
de una red necesitaremos primeramente crear una estructura de tipo Socket del
espacio de nombres System.Net.Sockets.
Ésta, básicamente proporciona un conjunto de métodos y propiedades para
comunicación y datos a través de una
red. Afortunadamente también soporta
comunicaciones asíncronas, cosa que
puede ser de particular interés para que
Nombre
Descripción
IP
Protocolo de IP versión 4.0
IP6v6
Protocolo de IP versión 6.0
ND
Protocolo de disco de red
Ipx
Protocolo IPX
TCP
Protocolo de control de
transmisión
Tabla 3. 'Algunos valores del
enumerado ProtocolType
ftp> literal USER Anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
ftp> literal pass [email protected]
230 Anonymous user logged in.
ftp> literal CWD /ArchivosdeGuillermoPuertas
250 CWD command successful.
ftp>
Desde .NET Framework omitiremos la palabra literal ya que no tendremos al cliente FTP de Windows XP
debido a que nos comunicaremos directamente abriendo canales de TCP/IP
mediante clases de la infraestructura.
El segundo parámetro indica la forma de apertura del canal, el valor Stream
establece la posibilidad de envío y/o
recepción de valores binarios o texto al
un servidor remoto. El resto de los valores de este enumerado no son importantes ya que rara vez se utilizan, por lo
que los omitiremos. Por su parte el último parámetro especifica el protocolo a
emplear (vea la tabla 3). Aquí tampoco
figura FTP por lo que la opción más
adecuada es TCP.
Nombre
Descripción
Appletalk
Protocolo Appletallk
Banyan
Protocolo Banyan
InterNetwork
Protocolo IP versión 4.0
InterNetwork6 Protocolo IP versión 6.0
Tabla 2.Algunos valores del
enumerado AddressFamily
Como podemos apreciar no existe una opción para FTP y eso se debe
particularmente a que .NET Framework no tiene implementado el protocolo de intercambio de archivos. Sin
embargo, FTP funciona sobre TCP
por lo que si deseamos trabajar con el
primero tendremos necesariamente
que hacer uso del protocolo de IP versión 4.0.
Hemos creados el objeto pero todavía no nos conectaremos ya que debemos llevar acabo algunos pasos más
antes de abrir el socket.
Resolviendo dinámicamente
un nombre de dominio
Un punto importante para encontrar
el servidor al cual deseamos conectarnos
es tener la dirección IP, como por ejemplo 169.200.1.1. Pero ¿qué pasaría si el
usuario que utiliza nuestro software de
FTP ingresa un nombre de dominio como
ser www.vblibros.com? Bien… tendríamos
que obtener la dirección IP correspondiente a este dominio. Para ello existe un
servicio de Internet llamado DNS que
contiene un listado de nombres de servidores y sus direcciones IP, de igual forma
que un listín telefónico. Hábilmente los
ingenieros que diseñaron .NET framework pensaron en esto ya que construyeron una clase estática llamada DNS que
lleva adelante el trabajo sin demasiadas
complicaciones. Veamos entonces cómo
obtener la dirección IP de un nombre:
IPAddress dirección = null;
dirección = Dns.Resolve(
"www.vblibros.com").AddressList[0];
<<dotNetManía
bra literal al comienzo de la línea
seguido del comando. Esto hará que la
aplicación cliente de FTP transmita
automáticamente el comando sin realizar interpretación alguna. El fuente
3 muestra cómo hacer lo mismo que en
el 1, pero ahora empleando los comandos de servidor.
la aplicación no
quede congelada a
la espera o envío
de información, y
así permitir al
usuario continuar
interactuando con
la interfaz gráfica
o, en su defecto,
realizando otras
tareas en segundo
plano.
15
El método Resolve de la clase DNS
se especializa en consultar al servicio
de DNS la dirección IP de un nombre de dominio, mientras que
AddressList retornará la primera
dirección del sitio en cuestión. Como
podemos apreciar se cuenta con una
estructura especial para almacenar
direcciones IP llamada IpAddress .
Podría haberse optado por una variable de texto para almacenar la dirección, pero como .NET Framework es
muy estricto y claro, se ha diseñado
un tipo específico para almacenar este
tipo de datos. Bien… tenemos ahora
la dirección IP, ¿qué más nos está faltando?. Afortunadamente ya estamos
casi listos para establecer la conexión.
El término “casi listos” no es demasiado feliz ya que implica que algunas
cosas permanecen pendientes y esto
es cierto. En el próximo resolveremos
lo que está pendiente mediante la gestión de puertos en .NET Framework.
llave de acceso o punto de entrada al
servidor remoto.
puntodeEntradaIP = new
IPEndPoint(dirección, 21);
La estructura IPEndPoint representa justamente un valor de entrada
claramente definido, esto es, la dirección IP y puerto final al que deseamos
conectarnos. Esta estructura es de
mucha importancia ya que una vez
suministrada esta información estaremos en condiciones de conectarnos al
servidor remoto.
<<dotNetManía
16
Para poder acceder a un servidor
se requiere un dato adicional que es el
puerto de acceso, esto es, el punto
mediante el cual el servidor ofrece el
servicio y, por supuesto, al cual conectarse. Por ejemplo, el servicio de
HTTP emplea el puerto 80 mientras
que FTP el 20 y 21. Para esta primera instancia haremos uso del puerto
21 que es a través de donde se envían
los comandos y se reciben las respuestas. Una vez reunida toda esta
información (IP y puerto) podemos
decir que hemos constituido nuestra
//Obtiene la cantidad de bytes
//de la respuesta.
this.bytes = socketCliente.Receive(
this.búfer, this.búfer.Length, 0 );
//Obtiene el mensaje.
this.mensaje += ASCII.GetString(
this.búfer, 0, this.bytes );
//Carga otros valores de la respuesta.
...
Fuente 4
this.socketCliente.Connect(puntodeEntradaIP);
Si todo sale bien habremos abierto una conexión –o socket– con el puerto FTP del servidor especificado, de
lo contrario obtendremos una excepción en tiempo de ejecución. Es ya el
momento de comenzar a utilizar
comandos y así interactuar con el ser-
Hasta ahora solamente era posible utilizar FTP en .NET
Framework haciendo uso de controles de terceros, pero
con un poco de audacia y algunos trucos se puede lograr lo
mismo empleando las clases nativas de la infraestructura
Gestión de puertos en .NET
Framework
ble búfer, así como en mensaje el texto completo. (fuente 4).
vidor FTP, pero antes demos un vistazo a las posibles respuestas del servidor (ver tabla 4).
Valores de respuesta del servidor FTP
Una vez abierta la conexión es
necesario verificar la respuesta del servidor para saber si todo ha funcionado correctamente. Para ello he construido un procedimiento llamado
leerRespuesta que interactúa con la
conexión (que es en realidad un socket
abierto hacia el puerto 20 del servidor), y luego obtener el texto de respuesta. El método Receive recibe la
cadena de bytes y la carga en la varia-
Socket también cuenta con un método Send, del que hablaremos en breve
cuando queramos enviar comandos al
servidor.
Toda respuesta contiene al comienzo un código numérico de 3 dígitos
que identifica el mensaje posteriormente y una descripción que puede
variar de acuerdo al idioma del servidor FTP. La invocación al método
Código
Valor
125
Conexión de datos abierta, comenzando la transferencia.
150
Conexión de datos abierta.
202
Comando no implementado en
este servidor.
200
El comando enviado es correcto.
220
El servicio de FTP está disponible
226
Cerrando la conexión de datos,
la acción ha sido correcta.
230
El usuario se ha conectado exitosamente.
250
La acción sobre el archivo solicitado finalizó correctamente.
331
Usuario correcto, necesita ingresar la contraseña.
350
La acción requiere más información.
425
No se puede abrir la conexión de
datos.
530
No se puede establecer una
sesión con el usuario/contraseña
especificada
Tabla 4. Nota de tabla: Resumen de
códigos de respuesta de FTP.
leerRespuesta carga el código retornado en una
variable global llamada códigoResultado que nos
será de mucha utilidad ya que nos permitirá consultar este valor para conocer el estado de la conexión o de cualquier otro comando enviado. Veamos
entonces un ejemplo de esto en el fuente 5.
this.leerRespuesta();
//Si el resultado es <> 220 entonces es un error!!!
if(this.códigoResultado != 220)
{
//¡Hubo un error! Hacer algo aquí...
}
Fuente 5
Invocaremos este método siempre que interactuemos con el servidor con el fin de conocer si el
código de respuesta ha sido el esperado. Como norma, los códigos dentre 100 y 399 son positivos mientras que el resto son negativos. La tabla 4 muestra
algunos de los valores que utilizaremos.
Envío de comandos al servidor FTP
Ahora nos centraremos en enviar comandos al
servidor, como pueden ser el usuario y la contraseña, para finalmente establecer una conexión de
confianza. Para ello es necesario emplear USER y
PASS seguido de los respectivos valores (veáse la
tabla 1).
El envío de un comando es muy sencillo ya que
se logra utilizando la conexión abierta, aunque en
vez de invocar el método Receive (recibir) de Socket
se hace a través de Send (enviar). El fuente 6 mues//Envía comando de usuario y el nombre de usuario.
this.enviarComando("USER " + usuario );
//¿Son los valores esperados?
if( !(this.códigoResultado == 331 || this.códigoResultado == 230) )
{
//No son los valores esperados, hacer algo.
}
tra cómo enviar los comandos y verificar que los
resultados sean los esperados. Para que el listado sea
más amigable he encapsulado el procedimiento de
envío de comandos dentro de una rutina llamada
enviarComando.
A este punto no es mala idea bajar el ejemplo del
sitio de dotNetManía y probarlo o para depurar paso
a paso lo que hemos visto hasta el momento y así quitarnos alguna duda que haya quedado con respecto
al funcionamiento.
Hemos logrado un objetivo interesante que radica en conectarnos a un servidor FTP e interactuar
con el mismo mediante comandos, así como también leer la respuesta de cada uno de ellos. Esto gracias a que conocemos ya la utilidad de una conexión
(socket) y los métodos que ofrece para el envío y
recepción.
Modo pasivo y activo
Sin duda, una de las facetas más importantes de
FTP es la posibilidad de enviar o recibir archivos.
Como el espacio es tirano, he pensado brindar en
este artículo solamente una de las dos opciones, aunque en dotNetManía encontrará el ejemplo completo con ambas implementaciones.
Si recuerda, al comienzo de este artículo hablamos del funcionamiento de FTP y que empleaba
dos conexiones a través de puertos diferentes, las
que cumplían distintos roles: una se encargaba del
envío de comandos y recepción de respuestas (puerto 21); y la otra del envío y acogida de datos (puerto 20). Esto es muy sencillo, pero sin embargo, existe una trampa en todo esto que se debe tener en
cuenta antes de realizar la implementación del método para enviar un archivo.
Cuando la aplicación .NET Framework avisa
mediante un comando al servidor FTP que se subirá/bajará un archivo, entonces este último se conectará al puerto que utilizó el cliente para enviar el comando más uno y comenzará a emplear este canal para recibir o enviar datos. Véase la figura 3.
//Si no es 230 continúa.
if( this.códigoResultado != 230 )
{
//Envía comando de contraseña y el valor de la misma.
this.enviarComando( "PASS " + contraseña );
Figura 3. Modo Activo de FTP
}
Fuente 6
Esta aproximación se denomina Modo Activo y
funciona correctamente dentro de una intranet,
<<dotNetManía
//Verifica nuevamente código de respuesta.
if( !(this.códigoResultado == 230 || this.códigoResultado == 202) )
{
//No son los valores esperados, hacer algo.
}
17
pero cuando esta tarea se está llevando acabo a través de Internet, puede
no tenerse un resultado exitoso. Esto
es debido a que la mayor parte de los
computadores cuentan con un cortafuegos que no permite que agentes
externos abran una conexión a nuestro computador. Para que esto no
suceda, se cuenta con otra alternativa
llamada Modo Pasivo que implica que
una vez que el cliente envía el comando indicando que se subirá/bajará un
archivo, el servidor responderá el
número de puerto al que la aplicación
cliente se tendrá que conectar y
comenzar a escuchar o a enviar datos.
Este puerto no será el 20 sino que se
elegirá uno al azar. La figura 4 muestra gráficamente el funcionamiento de
este modo.
encargaremos de abrir la nueva conexión que utilizaremos para datos, o
lo que es igual, para el envío del
archivo.
Subiendo un archivo al servidor FTP
Ya hemos visto la mayor parte de la
implementación de un cliente FTP, ahora nos queda tan sólo un punto más, el
que radica en enlazarse al puerto de
datos para así finalmente enviar desde
el cliente el archivo deseado. Esto afortunadamente se hace de igual forma que
la conexión que abrimos inicialmente,
salvo que utilizando otra información
de puerto. El fuente 7 muestra como
hacerlo.
//Comienza el envío del archivo.
this.enviarComando( "STOR " +
Path.GetFileName(nombredeArchivo) );
El próximo y último paso radica
en abrir un stream para la lectura del
archivo y al mismo tiempo enviar lo
leído mediante el método Send del socket. Esta tarea simple, pero efectiva,
hará una copia del archivo del cliente
en el servidor; el fuente 8 muestra la
implementación de la rutina que lleva adelante la tarea.
Conclusión
Hemos concluido la implementación del cliente FTP en .NET
Framework, espero que haya sido un
ejemplo claro de cómo utilizar las cla-
//Socket y punto de entrada de datos para el archivo.
socket = new Socket(AddressFamily.InterNetwork,SocketType.Stream,ProtocolType.Tcp);
puntodeEntradaIP = new IPEndPoint(Dns.Resolve(DirecciónIP).AddressList[0], puerto);
//Se conecta al nuevo punto de entrada indicado por el servidor.
socket.Connect(puntodeEntradaIP);
Fuente 7
Figura 4. Modo Pasivo de FTP.
De esta forma es siempre el cliente el que administra la apertura o cierre de puertos en sí mismo, y no un
agente externo como es el servidor.
He optado entonces por esta segunda
alternativa ya que creo será más sana
y funcionará en todos los contextos.
Por supuesto que si el servidor tiene
un cortafuegos se tendrá que dejar
siempre un rango de puertos que sean
factibles de conectar desde el mundo
exterior.
Para configurar el Modo Pasivo basta con enviar el comando PASV al servidor.
<<dotNetManía
//Configura el modo pasivo.
this.enviarComando("PASV");
18
Una vez enviado este comando, el
servidor enviará en el texto de respuesta la dirección IP y el puerto al
que nos tendremos que conectar. En
la próxima y última sección nos
// Abre un stream para leer le archivo.
FileStream input = new FileStream(nombredeArchivo,FileMode.Open);
//Se continúa leyendo el archivo hasta el final
while ((bytes = input.Read(búfer,0,búfer.Length)) > 0)
{
//Envía por el socket de datoslos bytes leídos.
cSocket.Send(búfer, bytes, 0);
}
//Cierra el socket de salida.
cSocket.Close();
Fuente 8
Ya estamos listos para enviar el
archivo al servidor ya que nos hemos
conectado en forma exitosa, ahora falta avisarle de lo que haremos con el
canal. Para ello debemos utilizar el
comando STOR –acrónimo de Store
(almacenar)– para especificar que se
comenzará el envío de un archivo a
través del canal abierto.
ses de la infraestructura para gestionar
conexiones de red, así como también
sea de utilidad para incluir en sus aplicaciones. Como siempre es un placer
recibir sus comentarios a través de mi
correo electrónico [email protected]. Me despido hasta el próximo
mes y no olvide bajar el ejemplo del
sitio de dotNetManía.
dnm.asp.net
José M.Alarcón
Creación y uso de servicios Web desde
entornos tradicionales
Con tanto bullicio generado alrededor de los servicios Web parece que los programadores de toda la vida (sí, los que usan COM y/o lenguajes de Script, por
ejemplo) se han quedado fuera de la nueva onda. Sin embargo .NET ofrece soluciones para todo el mundo, incluso para aquellos que no saben nada de .NET.
En este artículo veremos cómo dar el salto al mundo de los servicios Web desde lenguajes tradicionales como Visual Basic 6.0, usando de manera indirecta
.NET pero sin tener que aprender nada nuevo.
José Manuel Alarcón
es redactor de dotNetManía.
Es ingeniero industrial y
especialista en consultoría de
empresa. Ha escrito varios libros,
y ha publicado más de
doscientos artículos sobre
informática e ingeniería en
revistas especializadas.Visita su
blog en www.jasoft.org.
entonces en el sector era la expresión “servicio Web”.
Todo el mundo se apuntaba a este nuevo concepto
de moda y todos los lenguajes y plataformas incorporaban funcionalidades nativas para la creación y
el consumo de componentes a través del protocolo
SOAP. En ese contexto parecía que los programadores de entornos de Microsoft más tradicionales
(como Visual Basic 6.0 o ASP) se quedaban totalmente fuera de juego, condenados a la ignominia
debido a la obsolescencia de sus herramientas.
Bien es cierto que Microsoft puso a disposición
de estos programadores un kit de desarrollo SOAP
pensado para entornos COM tradicionales, el SOAP
Toolkit. Sin embargo se trataba de un producto externo al lenguaje, que requería una instalación propia,
que ofrecía severas incompatibilidades entre sus diferentes versiones y que además no era fácil de aprender. Está muy bien para diseñar servicios avanzados
desde cero, pero requiere un esfuerzo importante
dominarlo, y es muy poco operativo para usos sencillos. La última versión de éste, la 3.0, se puede descargar gratuitamente desde el centro de descargas
de Microsoft (www.microsoft.com/downloads).
Lo que a todos nos gustaría es una ruta de actualización directa y sencilla que nos permitiese crear
y consumir servicios Web sin tener que esforzarnos
demasiado ¿verdad?
La plataforma .NET de manera indirecta nos
ofrece esta opción como enseguida comprobaremos.
Más que crear nuevas aplicaciones basadas en servicios Web con Visual Basic 6.0 (en ese caso reco-
miendo pasarse a .NET cuanto antes), las técnicas que
veremos están orientadas a permitirnos reutilizar como
servicios Web ciertos componentes COM preexistentes, recuperando la inversión hecha en ellos y dándole una vida más allá de su uso tradicional.
Primer ejemplo: un servicio Web simple
con Visual Basic 6.0
Como ejemplo inicial vamos a crear un servicio
Web con Visual Basic 6.0 que nos permitirá servir
la hora a diversos clientes que se mantendrán sincronizados a través de él. Puede descargar este ejemplo y todos los demás mencionados en el artículo
desde la Web de dotNetManía.
Abra el entorno de Visual Basic 6.0 y cree un
nuevo proyecto de tipo DLL ActiveX. En las propiedades del proyecto otórguele el nombre
PruebaSOAP y marque las opciones “ejecución desatendida” y “conservado en memoria” (figura 1).
A la clase que se crea por defecto cámbiele el
nombre y llámele Hora . Añádale un método
HoraLocal, que será el que expondremos, usando el
siguiente código:
Public Function HoraLocal() As String
HoraLocal = Format(Time, "h:m:s")
End Function
Más sencillo imposible. Ahora sólo hay que compilar el proyecto y obtendremos una DLL COM
que expondrá la clase recién creada y la registrará
en el sistema.
<< dotNetManía
<< Cuando .NET apareció en escena lo que más se oía por aquel
19
<< dnm.asp.net
del nodo “Aplicaciones COM+” cree
una nueva aplicación y agréguele la
DLL que acaba de compilar. En las
propiedades de la nueva aplicación
COM+ vaya a la pestaña “Activación”
y marque la opción “Usa SOAP”. En
el campo de texto inferior escriba el
nombre que quiera otorgarle al directorio de IIS en el que se publicará su
servicio Web, por ejemplo, HoraWS ,
como en la figura 3.
¡Ya está! Aunque parezca increíble desde este momento disponemos de un nuevo servicio Web en el equipo que estará
Figura 1. Para el ejemplo compilaremos
una biblioteca COM escrita en VB6 que
servirá de servicio horario que se
consumirá a través de SOAP.
Hasta aquí todo normal. No hay
problema alguno para usar la clase
recién creada a través de COM o
DCOM desde otro proyecto de Visual
Basic, un script o una página ASP.
Para exponer el componente como
servicio Web no hace falta tampoco gran
cosa. Debemos tener, eso sí, instalado
Internet Information Server en el equipo con
Windows XP o Windows 2003 Server, ya
que SOAP es un protocolo basado en
HTTP. Asegúrese de que tiene IIS instalado y funcionando antes de continuar.
En las herramientas administrativas ejecute la consola de administración de servicios de componentes (o
sea, COM+, vea la figura 2). Dentro
Figura 3. En la pestaña Activación podemos decidir que los objetos COM que forman
parte de la aplicación COM+ se expongan como un servicio Web.
sirviendo los métodos del objeto COM
que creamos hace un momento.
Para comprobarlo abra su navegador favorito (incluso desde otro equipo,
por supuesto), y escriba:
<<dotNetManía
http://nombre_servidor/HoraWS/
20
Figura 2. Desde la consola de administración de COM+ podemos crear nuevas
aplicaciones. Podemos utilizarlas para exportar los objetos COM mediante SOAP.
Al hacerlo verá cómo aparece una
página Web que contiene un enlace al
archivo de descripción (WSDL) del
nuevo servicio Web. Este WSDL contiene una descripción estándar de las
capacidades del servicio Web de forma que cualquier cliente que necesite utilizarlo sepa cómo hacerlo.
Pulsando el enlace anterior puede ver
su contenido.
Puede probar a consumirlo desde
una aplicación .NET agregando de la
manera habitual una referencia Web y
verá cómo funciona perfectamente.
<< dnm.asp.net
¿Qué ha pasado aquí?
La verdad es que ha resultado muy
fácil. Pero, ¿cómo lo hemos conseguido?,
¿qué tiene que ver .NET con todo esto?
Lo que ha ocurrido entre bambalinas
es que de forma automática se ha creado
un ensamblado .NET que envuelve a
nuestro objeto COM y expone su funcionalidad usando .NET Remoting. Es
decir, se ha creado una aplicación .NET
pero sin que fuera necesario por nuestra
parte tener conocimiento alguno de esta
plataforma. El ensamblado está configurado para responder a las peticiones a través del puerto 80, usando HTTP y SOAP,
es decir, es un servicio Web con todas las
de la ley.
Puede encontrar el ensamblado en
cuestión dentro de la carpeta
C:\Windows\System32\Com\SOAPVRoots\Ho
raWS. Dentro de ésta encontrará una
Consumir servicios Web desde
lenguajes tradicionales.
Además de crear de manera sencilla
servicios Web también resulta fundamental poder consumirlos desde lenguajes tradicionales, sin complicarnos
la vida con técnicas complejas. Por fortuna los chicos de Microsoft están en
todo y lo han convertido en algo muy
Figura 4. La clase .NET Remoting generada es muy sencilla.Aunque no dispongamos del
código fuente es muy fácil obtenerlo usando un decompilador como .NET Reflector.
sencillo también, aunque con algunas
limitaciones.
Como ejemplo vamos a consumir
el servicio Web que acabamos de crear desde un pequeño script de WSH
escrito en VBScript. Sólo tiene que
guardar el código con extensión .VBS
(o incluso usarlo desde una página
HTML) y podrá ejecutarlo haciéndole doble clic encima.
La técnica de acceso al servicio
Web consiste en usar de una manera
un tanto especial la conocida función
GetObject. Ésta se encuentra disponible en cualquier lenguaje capaz de
automatizar objetos COM: Visual
Basic, lenguajes de Script, Office,
etc… por lo que su uso es casi universal.
Por ejemplo, el siguiente código utiliza nuestro servicio Web de información horaria para mostrar en un cuadro
de diálogo la hora del servidor:
Dim oHora
set oHora = GetObject("soap:wsdl=”&_
“http://localhost/horaws/” &_
“PruebaSOAP.Hora.soap?WSDL")
msgbox oHora.HoraLocal
Como podemos comprobar nada más
sencillo. Basta con colocar la URL del descriptor del servicio Web (el archivo WSDL
que mencioné antes) como parámetro de
GetObject, precediéndolo con la expresión
“soap:wsdl”. Se creará automáticamente
un objeto COM con los métodos expuestos por el servicio Web que podremos usar
como si fuera local, usando de manera
transparente el servicio Web.
Al igual que antes es .NET quien
está detrás de todo el proceso haciendo
el trabajo sucio por nosotros. Se genera de forma automática código .NET
Remoting que se compila en un ensamblado .NET que es el que hace se comunica con el servicio Web. Esta funcionalidad se expone a través de un envoltorio COM (un CCW o COM Callable
Wrapper) que puede ser utilizado desde
cualquier cliente tradicional.
La primera vez que se hace una llamada al servicio Web, ésta tarda un par
de segundos mientras se compila el
componente. Todas las sucesivas llamadas, al existir ya el Proxy, se realizan a
gran rapidez y sólo dependeremos de la
velocidad de nuestra conexión.
<<dotNetManía
página Web por defecto para el servicio, el archivo Web.Config que controla
su comportamiento y dentro de la subcarpeta bin una ensamblado .NET que
contiene el objeto expuesto como servicio Web. Podemos abrir este ensamblado con un decompilador de código
.NET y veremos que la implementación
es muy sencilla, limitándose a crear un
envoltorio .NET sobre el objeto COM
que le hemos asociado (figura 4).
Dado que se trata de un objeto
.NET Remoting, se puede modificar su
comportamiento jugando con los parámetros de Web.config, pero los valores
por defecto que trae serán los más apropiados en la mayoría de los casos.
Como vemos es muy fácil darle una
nueva vida a nuestro código heredado
convirtiéndolo en un servicio Web gracias a la magia de .NET. En cualquier
caso, y como veremos enseguida, todavía nos quedan algunas consideraciones
que hacer al respecto. Mientras tanto…
21
<< dnm.asp.net
Lo que a todos nos gustaría es una ruta de
actualización directa y sencilla que nos permitiese
crear y consumir servicios Web sin tener
que esforzarnos demasiado ¿verdad?
La DLL generada (y el archivo de
código fuente a partir del cual se generó)
la podemos encontrar en la carpeta
C:\WINDOWS\system32\Com\SOAPAssembly,
por lo que incluso la podremos utilizar tal
cual o recompilarla para usarla desde nuestros desarrollos .NET también.
Por supuesto esta técnica permite el
consumo de servicios Web creados en
otros lenguajes y tecnologías, no sólo los
creados con el método anterior. Así, si disponemos de un servicio Web creado con
.NET, Java, Gluecode o cualquier otro
sistema compatible con SOAP, podemos
consumirlo a través de GetObject. Esto es
así en la mayor parte de las ocasiones, ya
que existen ciertas limitaciones si el servicio expuesto es muy complejo, aparte de
que no funcionará si requiere el uso de las
extensiones para servicios Web (WSE,
Web Service Enhancements).
Por ejemplo, el siguiente código, análogo al anterior, permite hacer uso de un
servicio Web gratuito de XMethods, que
comprueba la disponibilidad de dominios
de Internet “.com”, “.net” y “.org”:
actuar de intermediarios entre el script
y el servicio Web.
Reutilización de objetos con
estado
Con las técnicas aprendidas hasta
ahora hemos creado y consumido objetos sin estado. Esto es, si disponemos de
una DLL escrita en VB que contiene
una clase que debe mantener información entre llamadas, no funcionará
correctamente. Ello se debe a que cada
llamada realizada a través de SOAP con
la técnica descrita es independiente de
las demás y se realiza sobre un objeto
diferente en el servidor.
Ello supone un grave problema en
muchos casos, porque si bien en la
actualidad se considera una buena
práctica de programación el uso de
objetos sin estado, en los tiempos de
COM esto era menos frecuente. De
hecho lo habitual era que los objetos
guardaran el estado entre llamadas,
por lo que, en la práctica, lo que
<<dotNetManía
Dim sDominio
sDominio = InputBox("Dominio a verificar (sin 'www')", "Verificador de dominios")
If sDominio <> "" Then
Dim oDC
set oDC = _
GetObject("soap:wsdl=http://services.xmethods.net/soap/urn:xmethods-DomainChecker.wsdl")
MsgBox oDC.checkDomain(sDominio)
End If
22
Este código le preguntará el nombre de un dominio (por ejemplo,
JASoft.org) y devuelve la cadena
“Available” o “Unavailable” en función
de su disponibilidad. Si acude a la carpeta mencionada antes podrá ver también el código y la DLL generados para
hemos visto para crear servicios Web
a partir de objetos COM nos servirá
en contadas ocasiones.
Vamos a crear un ejemplo que
reproduzca este comportamiento y así
veremos cuál es la mejor forma de solventar el problema planteado.
Consideremos la siguiente clase de
Visual Basic 6 llamada PruebaSOAP2.
Persona y que dispone de dos métodos:
uno para anotar el nombre de una persona y otro para saludarla:
Private mNombre As String
Public Sub AnotaNombre(sNombre As String)
mNombre = sNombre
End Sub
Public Function DimeNombre() As String
DimeNombre = mNombre
End Function
El método AnotaNombre almacena
la cadena que se le pase como parámetro en una variable privada de la
clase. El método DimeNombre , por el
contrario, la recupera. Es obvio que
para que esta clase funcione como es
debido se debe poder realizar llamadas sucesivas sobre una misma instancia de ésta o el estado interno de la
variable mNombre se perdería.
Compile este código y expóngalo
como un servicio Web usando el
método visto antes. Vamos a probar a
consumirla mediante SOAP directamente tal y como hemos analizado
hace un momento:
Dim o
Set o=GetObject("soap:wsdl=http://localhost
/personaws/PruebaSOAP2.Persona.soap?WSDL")
o.AnotaNombre "Jose"
MsgBox o.DimeNombre
En el mensaje final debería aparecer la palabra “ Jose ”. Sin embargo
vemos que en realidad se muestra en
blanco. Ello se debe a lo que comentábamos: cada llamada al servicio Web es
atendida por un objeto diferente y nuevo en el servidor. Está claro que esto
limita bastante la capacidad de reutilizar como servicios Web algunos componentes heredados con estado.
Por suerte, como casi todo, esto
también tiene solución. Y es casi igual
de fácil que todo lo visto hasta ahora.
Lo primero que debemos hacer es
exportar nuestra aplicación COM+ desde la consola de administración de servicios de componentes. Pulse con el
botón derecho sobre el nodo de la aplicación COM+ y escoja la opción
<< dnm.asp.net
donde hayamos instalado el proxy
podemos encontrar el archivo .CONFIG que controla su comportamiento. El contenido de este archivo será
similar al siguiente:
<configuration>
<system.runtime.remoting>
<application>
<client url=
"http://www.nuestroservidor.com/PersonaWS">
<activated type=
"PruebaSOAP2SoapLib.PersonaClass,
PruebaSOAP2SoapLib"/>
</client>
</application>
</system.runtime.remoting>
</configuration>
Figura 5.Al generar un Proxy para el servicio Web que se exporta en formato MSI
podemos instalarlo en cualquier equipo y acceder vía SOAP al
objeto original de manera sencilla y transparente.
Si sabemos un poquito de .NET
Remoting podemos modificarlo y añadirle nuevos nodos de configuración
para modificar el comportamiento del
proxy.
“Exportar”. En el diálogo que aparece
seleccione la opción “Proxy de aplicación” y escoja una ruta en la que crear
un paquete de instalación MSI, tal y
como ilustra la figura 5.
Al terminar dispondrá de un
paquete de instalación que podrá utilizar en cualquier equipo con
Windows XP o Windows 2003 Server
y que lo que hará es instalar un objeto que actúa de proxy con el servicio
Web que hemos exportado. Ejecútelo.
Tenga en cuenta que para poder probarlo deberá instalar el proxy en otro
equipo diferente al que contiene el
servicio Web o sobrescribirá el registro del objeto COM original inutilizándolo. El objeto Proxy creado
encapsula el acceso al servicio Web en
una CCW (COM Callable Wrapper) que
replica la funcionalidad del objeto
COM original.
Una vez instalado en otro equipo
podrá comenzar a utilizar el objeto con
el siguiente código:
Dim o
Set o = WScript.CreateObject(_
"PruebaSOAP2.Persona")
o.AnotaNombre "Jose"
MsgBox o.DimeNombre
El código funcionará ahora perfectamente, devolviendo en el cuadro de
diálogo el valor del nombre fijado en la
llamada anterior, es decir, manteniendo
el estado entre llamadas.
Pero… ¡Eh!, ¡un momento!, ¿qué es
esto?. ¡No estoy utilizando SOAP!
Tranquilo, todo tiene una explicación.
En realidad sí está utilizando SOAP y las
llamadas se están realizando a través de
HTTP al servidor en el que está instalando el componente original. La diferencia respecto a lo que hemos visto hasta ahora es que estamos utilizando un
Proxy .NET Remoting generado de forma automática por COM+ durante la
exportación, y expuesto como un objeto
COM regular durante la importación.
Es éste el que nos aisla de las complejidades de SOAP y nos permite utilizar el
servicio Web remoto como si fuese un
componente local. Para nuestro código
no habrá diferencia pero por detrás se
estará haciendo uso de SOAP para realizar las llamadas remotamente.
En la carpeta C:\WINDOWS\system32\Com\SOAPAssembly del sistema en
En este artículo hemos estudiado
las diversas formas en las que .NET
nos puede ayudar a entrar en el mundo de los servicios Web desde lenguajes tradicionales, y todo ello sin
necesidad de aprender a programar en
la plataforma o de disponer de una
licencia de Visual Studio.
Hemos aprendido a crear servicios
Web simples a partir de objetos COM
existentes y a consumir éstos y otros
servicios desde código de script o cualquier lenguaje de automatización con
el simple uso de una función. Al mismo tiempo hemos visto cómo funciona todo ello por debajo para comprenderlo mejor.
Por fin hemos presentado un problema común que tiene que ver con el
mantenimiento de los estados de objetos COM y hemos aprendido una técnica adicional que nos permite salvar la
situación con el mínimo esfuerzo.
Esperamos que todo ello haya sido
de utilidad a aquellos lectores que todavía no han podido meterse a fondo con
.NET o que, simplemente, disponen de
multitud de código heredado que desean aprovechar de manera sencilla en la
era de SOAP.
<<dotNetManía
En resumen
23
Leonardo Paneque
Miguel Katrib
PON : P2P Over .NET
Una plataforma para redes punto a punto basada en .NET
Las tecnologías actuales
<<
Millones de personas conectadas a la red de redes utilizan
programas para compartir información.Aplicaciones como
Kazaa, eMule y BearShare permiten a sus clientes formar
gigantescas comunidades virtuales. En este artículo se enumeran algunas debilidades de estas tecnologías de intercambio Punto a Punto (P2P), entre ellas la de no operar
entre sí.
El artículo presenta a PON (Peer to peer Over .NET): una plataforma implementada sobre la tecnología .NET, la cual permite el desarrollo de comunidades de nodos .NET. Con esta
plataforma se da la posibilidad de conectar aplicaciones diferentes formando redes de intercambio aún más universales.
Además de que, cómo en cualquier aplicación, PON aprovecha las bondades de .NET para acortar el proceso de desarrollo, PON se sustenta en el uso de importantes capacidades
existentes en .NET como su carácter multiplataforma, y sus
capacidades de Reflexión (facilita inspeccionar lo recibido),
Serialización (facilita convertir la información al enviarla y al recibirla) y Nombrado Fuerte (nos permite dar y tener seguridad
en lo que se envía y en lo que se recibe).
La plataforma no requiere de la existencia de servidores para
su funcionamiento ya que se apoya en la cooperación de nodos
que decidan colaborar en el intercambio.
1
El término P2P de sus siglas en
inglés Peer to Peer, se usa para denominar la comunicación entre dos puntos
terminales cuando la comunicación permanece abierta y están fluyendo datos
a través de ella.
Una conexión HTTP no es de tipo
P2P, pues se basa en pedidos y respuestas [1]. PON se basa en conexiones P2P. Cuando se accede a un servidor mediante conexión socks (TELNET,
SSH, etc.), el tipo de conexión que se
establece en dicho momento es P2P. Se
han programado decenas de aplicaciones para compartir e intercambiar información entre PCs utilizando este tipo
de conexiones. Por supuesto que no
siempre se puede acceder directamente a otros PCs utilizando este tipo de
conexiones. Si su PC está detrás de un
cortafuegos1 es posible que no pueda
abrir este tipo de conexiones.
Con independencia de las múltiples
críticas de seguridad hechas a este tipo
de conexiones, lo cierto es que el número de usuarios que gusta de utilizar software de intercambio P2P ha crecido
considerablemente. Esto se debe al gran
volumen de información disponible
cuando se tiene acceso a lo que tienen
cada uno de los que participan y a la
sencillez del intercambio.
Muchos usuarios prefieren usar
dichas aplicaciones para buscar la información que desean descargar en lugar
de navegar en la Web en busca de la
información y luego ver desde dónde
pueden descargarla.
Napster fue el precursor del uso de
esta tecnología, brindando una mane-
Cortafuegos: Del inglés Firewall. Mecanismo de seguridad para Intranets que entre otras actividades restringe las conexiones entrantes.
dnm.comunicaciones
2
3
4
5
ción. Pero esto ha devenido en redes
separadas que no tienen ninguna posibilidad de intercambiar información con
usuarios de otra diferente.
Figura 1. Redes disjuntas
Se entiende por red en este caso a
los nodos conectados usando una aplicación. Por ejemplo, los servidores de
Kazaa y sus clientes que estén on line
definen la red de nodos de Kazaa. Así
como los servidores de búsqueda de
eMule y sus clientes definen la red de
nodos de eMule. Dado que Kazaa y
eMule utilizan protocolos distintos, es
imposible que nodos de estas redes compartan la misma información (figura 1).
Para hacerlo tendríamos que tener
ambas aplicaciones ejecutándose en el
mismo ordenador. Algo parecido sucede a diario con los programas de chat;
quien está en MSN Messenger no se
entiende con quien esté en Yahoo
Messenger y viceversa debido a que los
servidores y aplicaciones de Yahoo y
MSN no se entienden porque usan protocolos diferentes.
Problemas de las redes P2P
actuales
No se entienden entre sí
Desde la aparición de Napster, han
surgido múltiples redes dirigidas al mismo objetivo de intercambiar informa-
Otro asunto es si el poseedor de la información tiene derecho legal para tenerla o compartirla; pero ese no es el tema del presente trabajo que
se dedica solo a los aspectos tecnológicos que hacen posible el intercambio.
Ver por ejemplo el sitio www.rentacoder.com
Disponible en http://www.microsoft.com/downloads/details.aspx?FamilyID=262d25e3-f589-4842-8157-034d1e7cf3a3&displaylang=en
Una DLL de no más de 35 KB
<<dotNetManía
ra sencilla para que usuarios de todo el
mundo compartieran música. Esto por
supuesto tuvo problemas legales con las
compañías discográficas, pero la idea
sirvió de transición a otras aplicaciones
como Gnutella, Kazaa [2-3], eMule [46] y muchísimas otras, que ya no sólo se
centran en el intercambio de música sino
de cualquier información que el cliente desee compartir con el mundo2.
LPhant es una aplicación desarrollada recientemente sobre .NET sobre
la que se publicó en un número anterior de dotNetManía [7]. Aunque el
artículo presenta a LPhant como el
primer P2P sobre .NET, lo cierto es
que parece ser un cliente más para la
red eDonkey/eMule. Existen decenas,
sino cientos, de versiones clientes de
eMule tanto para Java como para
.NET (y también versiones clientes
para Kazaa, bitTorrent y otros) que
programadores hacen a diario por
encargo a consumidores en todo
Internet3. De modo que tal vez no sea
exacto el autor cuando dice que
LPhant es el primer Peer to Peer sobre
.NET. LPhant está desarrollado en
.NET, pero se basa en consumir y
enviar paquetes (o sea usar el protocolo) de eMule. Digamos entonces que
es una suerte de envoltura de eMule
programado en .NET. Claro está,
como mismo indica el autor del artículo, que es una propuesta interesan-
te porque muestra las bondades de
.NET en comparación con tecnologías nativas sobre C++ o C y le
demuestra a los tradicionalistas del
C++ que no sólo es factible, sino mucho más
fácil, desarrollar este
tipo de aplicaciones
en C# y .NET.
Lo que ocurre
con PON es que es
una plataforma como tal
programada en .NET y destinada a
que sobre la misma se puedan montar
disímiles aplicaciones P2P, que puedan incluso interoperar entre sí. Si
usted quiere participar en la red y
hacer de su PC un nodo de esta comunidad, lo único que debe es tener instalado el .NET Framework4 y ejecutar la plataforma. Cada cliente debe
centrarse solamente en programar su
aplicación utilizando PON5, que brinda un conjunto de facilidades programáticas basadas en .NET para el trabajo con redes. Su aplicación estará
lista entonces para conectarse con
otras aplicaciones que estén desarrolladas también sobre PON y ayudarse en la comunicación de nodos que,
aunque no estén ejecutando ninguna
aplicación, hayan decidido colaborar
instalando y ejecutando PON.
Los mensajes que PON envía por la
red no son simples paquetes de bytes
como en otros productos sino que son
objetos (y como tales incluyen datos y
funcionalidad ejecutable).
25
Si todos estamos en la misma
Internet (vale decir tenemos la misma
atmósfera) porqué no intercambiar
información sobre una misma plataforma de intercambio P2P (figura 2).
Figura 2.Varias redes de aplicaciones
distintas conectadas entre sí
Con las tecnologías actuales esto no
es posible debido a que los protocolos
utilizados han sido creados pensando en
cada aplicación en específico y no en la
posibilidad de extender la variedad de
aplicaciones conectadas entre sí. Pero
esto puede mejorarse aprovechando el
carácter cada vez más multiplataforma
de .NET donde un nodo podrá ser, por
ejemplo, un PC Windows, un PC Linux
o un dispositivo móvil.
En PON para convertirse en un
nodo de la comunidad basta con crear
una instancia de la clase PONKernel.
Cada usuario que desee sumarse al
número de clientes de una determinada red debe tener acceso socks a Internet
desde su PC, lo cual también es un riesgo informático. Supongamos, por ejemplo, que en una universidad o biblioteca todas las máquinas tienen acceso ilimitado a Internet, donde el acceso ilimitado sería la posibilidad de abrir conexiones P2P a cualquier PC en Internet.
El flujo de datos podría ser entonces
incontrolable y el peligro de ataques
hacia la red crecería considerablemente. De modo que es necesario crear de
algún modo un mecanismo para que
usuarios de una intranet puedan utilizar servicios de intercambio sin que
afecten el funcionamiento de la red
completa. De este modo en un escena-
xas entre sí, lo cual disminuye el
tamaño de la red a la cual tiene acceso un usuario. Estas componentes
conexas producto de desconexiones
y otras anomalías son llamadas
Horizons.
•Protocolos muy específicos. La mayoría de las aplicaciones están preparadas sólo para comunicarse
entre clientes que ejecuten la misma aplicación.
•Poca o ninguna extensibilidad. Si a
la debilidad anterior se añade el
que muchas de estas aplicaciones
de intercambio han sido programadas en lenguajes nativos, se tienen como resultados herramientas muy difíciles de extender o
modificar.
PON se encarga de modo transparente de hacer la
comunicación, y esto se logra sin detrimento de
otras funcionalidades porque al ejecutar PON
su aplicación decide qué velocidad de transmisión
está dispuesta a ofrecer a sus vecinos
Conexiones forzadas
<<dotNetManía
En este tipo de conexión si se desea
descargar un archivo hay que conectarse directamente al PC en el que se
encuentra éste. Háyase hecho la búsqueda por mediación de un servidor de
búsqueda o no, la forma de descargar la
información deseada es forzando a los
participantes a conectarse entre sí. Un
gran inconveniente para esto es que
muchos clientes pueden estar detrás de
un cortafuegos. En tal caso, si la política de seguridad lo permite, los clientes
podrán abrir conexiones hacia fuera de
su red pero nadie podrá abrir una conexión hacia él.
26
Figura 3. Limitante del cortafuegos
rio como el de la biblioteca no será necesario darle permisos completos de salida directa hacia Internet a todas las
máquinas de una biblioteca, sólo los permisos necesarios para que se pueda
navegar (HTTP) desde estas máquinas.
Además de las dos limitaciones anteriores se pueden mencionar otras dificultades en las redes P2P actuales:
•Ausencia de reconexión automática. Por
lo general los programas clientes de
estas redes no son lo suficientemente tolerantes a fallos. Cuando se caen
conexiones en la red, simplemente
se deja de buscar o intercambiar
archivos con los puntos perdidos. En
el caso de los que usan servidores es
peor, pues la estabilidad y velocidad
de los servidores puede comprometer la estabilidad y velocidad del servicio en toda la red.
•División de la red. Al caerse algunos
puntos se forman subredes no cone-
Qué es PON
Una red PON es simplemente un
conjunto de nodos formando un grafo
que disponen del .NET Framework y
que han decidido ejecutar PON. Es
decir, PON es la plataforma soporte y
las aplicaciones que se desarrollen sobre
PON y que utilicen estos nodos son las
responsables de brindar distintas funcionalidades. PON es el sustrato de
desarrollo y funcionamiento que además les facilita interoperar entre sí.
PON se encarga de modo transparente de hacer la comunicación, y esto
se logra sin detrimento de otras funcionalidades porque al ejecutar PON su
aplicación decide qué velocidad de
transmisión está dispuesta a ofrecer a
sus vecinos.
Crear un nodo PON consiste en ejecutar una aplicación que cree una instancia de la clase PONKernel, del names-
PONKernel kernel = new
PONKernel(KernelConfig,"Juan");
Donde KernelConfig es una instancia de la clase PONKernelConfiguration,
la cual provee al núcleo de PON con
información necesaria para instanciarse y funcionar correctamente. El
segundo parámetro es un alias (nombre que usted le quiere asociar al nodo).
PON no utiliza los alias para diferenciar a los nodos en la red ya que los alias
no son únicos y están destinados sólo
a brindar información consumible por
un ser humano. En cambio utiliza
GUIDs6 para identificar a los nodos;
estos GUIDs son solamente de lectura para el usuario y son trabajados
internamente por PON.
La clase de configuración tiene la
interfaz del fuente 1.
[Serializable]
public class PONKernelConfiguration
{
public int ListenningPort{...}
public bool IsHost{...}
public int MaxIncomingConnections{...}
public ArrayList BannedIPList{...}
public ArrayList IPList{...}
}
Fuente 1
Una vez creada la instancia se debe
llamar al método PONKernel.Start()
para que el nodo esté listo.
Mensajes en PON
Un mensaje para PON no es más
que un objeto .NET serializado en binario. Con ello, gracias a la característica
multiplataforma de .NET (un emisor,
un trasmisor y un receptor pueden estar
en diferentes plataformas pero todas con
.NET), se evita el problema de los protocolos hard-coded que utilizan las tecnologías P2P actuales.
6
Con el objetivo de hacer posible la
interconexión entre diversas aplicaciones desarrolladas y ejecutando
sobre la red de nodos PON, se llevan
a cabo un conjunto de operaciones
sobre estos mensajes para garantizar
que lleguen al destino correcto. Por
correcto no sólo se entiende que llegue al destino deseado, sino además
que dicho destino sea capaz de “entender” el mensaje.
Los mensajes son divididos en dos
tipos. Los propios de PON, y los que
personalizadamente implemente cada
aplicación que utilice PON.
Los mensajes PON son instancias
de la clase PONMessage contenida en el
namespace CommonPONMessages y está
dada por la interfaz del fuente 2.
[Serializable]
public enum MsgTypes
{
BroadCastMessage,
Personal,
Lost,
NewAdjacent,
AdjacentDown
}
Fuente 3
Transmisión
Se entiende por transmitir un
mensaje a serializar un objeto que se
desea transmitir dentro de un mensaje de PON, y enviarlo. La estructura
de un mensaje de PON es la de la figura 4.
[Serializable]
public class PONMessage
{
public PONMessage(){...}
public PONUser Target{...}
public ArrayList Path{...}
public MsgTypes MsgKind{...}
public PONUser Sender{...}
public string UniqueID{...}
public string GUID{...}
public Stream Content{...}
public object GetContent(){...}
public void SetContent(object obj){...}
public int Cursor;
}
Fuente 2
Donde MsgTypes está definido por el
enumerativo del fuente 3.
En las secciones a continuación se
explican los principios que usa PON
para la transmisión, entrega y filtrado
de estos mensajes.
Figura 4. Mensaje PON. Estructura
El array contenido dentro del
mensaje PON es la información que
la aplicación cliente quiere transmitir.
La forma de poner el mensaje del
cliente dentro del mensaje PON es a
través del método SetContent(object)
de la clase PONMessage, el objeto pasado como parámetro debe ser serializable o lanzará una excepción de tipo
ArgumentException . Se entiende por
cliente de PON a una aplicación que
utiliza la plataforma como base para
sus conexiones.
De esta forma la aplicación cliente utiliza PON para enviar sus men-
Figura 5. Procesos para enviar un mensaje
GUID (Global Unique IDentifier) es un valor de identificación, que por su forma de generarse se garantiza que sea único.
<<dotNetManía
pace PONFramework. Mientras su aplicación esté activa, su nodo PON le estará brindando su cooperación a usted y
a sus vecinos.
27
sajes, los cuales consisten en objetos
serializados a otros clientes de PON
capaz de entender estos mensajes, lo
cual se realiza a través del filtrado de
éstos. Puesto que son objetos serializados, sólo quienes tengan los ensamblados donde están definidos los tipos
de los objetos que se envían podrán
entender los mensajes.
Filtrado
La entrega de un mensaje a un cliente de PON se realiza si se cumplen las
dos condiciones siguientes:
1. El mensaje va destinado a un cliente especifico (MsgTypes.Personal) o
bien está destinado a todos los clientes de la red (MsgTypes.BroadCast
Message).
2. El cliente especificó explícitamente
que es capaz de entender este tipo
de mensajes y que desea recibirlo
(filtrado).
Para que se cumpla la segunda
condición el cliente debe especificar
que quiere “consumir” los mensajes
de este tipo que cumplan con la primera condición. Para ello el cliente
debe de tener el ensamblado en el cual
están contenidos los tipos de los objetos que desea recibir. Esto se logra con
el método kernel.CManager.Add
MessageFilter(Type)
Ejemplo:
Supongamos que tenemos sobre
PON una aplicación para chat que
consta de tres tipos de mensajes:
UserSearchMsg, UserSearchResultMsg y
TextMessage.
Se le diría entonces a PON que se
quiere procesar estos tipos de la forma
que vemos en el fuente 4.
Donde kernel es una instancia de la
clase PONKernel, la cual define un nodo
PON en sí.
Figura 6. Procesamiento de un mensaje PON dentro de un Nodo PON
nodo puede deserializar los objetos contenidos en los mensajes. Para ello es
necesario que cada aplicación en el nodo
que quiera interceptar mensajes le especifique a PON qué tipos puede entender. Así cuando un mensaje llega a un
nodo PON, éste se lo pasa asincrónicamente a un manejador. Este manejador
verifica si su tipo es de alguno de los filtros (tipo .NET con nombrado fuerte)
indicados por la aplicación que está
usando a dicho nodo; en tal caso se lo
pasa a la aplicación, mientras el nodo
PON pasa a su vez el mensaje a otros
nodos y continua con la recepción y
envío de mensajes (figura 6).
En la información del mensaje se
envía el nombre del tipo del objeto
que viene serializado en el mensaje.
Por ello cuando se crea un mensaje
(PONMessage), PON antes de serializar
guarda el nombre completo del tipo y
luego serializa en binario el objeto
(usando el mecanismo de serialización
de .NET).
La utilización de .NET permite
valernos del recurso del nombrado fuerte (strong naming) para facilitar la dife-
kernel.CManager.AddMessageFilter(typeof(UserSearchMsg));
kernel.CManager.AddMessageFilter(typeof(UserSearchResultMsg));
kernel.CManager.AddMessageFilter(typeof(TextMessage));
<<dotNetManía
Fuente 4
28
PON en cada nodo verifica si el tipo
del objeto que pasa por él puede ser
entendido, lo que se traduce en que este
renciación de los tipos y garantizar la
seguridad si se desea, habiendo firmado digitalmente el ensamblado. En otras
tecnologías esta diferenciación de si el
tipo del objeto recibido es de los que
estoy dispuesto a recibir, tendría que
sustentarse en el uso de recursos como
interfaz que en definitiva no garantizan
la unicidad y obligaría a añadir por separado los mecanismos de seguridad para
los casos en que se quiera privacidad.
El nombrado fuerte de un tipo A, no
es sólo el nombre A como tal (incluyendo el camino de namespaces en el que se
encuentre), sino el nombre del ensamblado, la versión, y la firma digital que
puede haberse utilizado a la hora de generarlo (compilarlo). Un ejemplo sería:
CommonPONMessages.GBMessage,
Version=1.0.1615.26757,
Culture=neutral,
PublicKeyToken=null
Ningún cliente no autorizado podrá
firmar un ensamblado para intentar interceptar mensajes que no le competen. De
este modo se garantiza que sólo clientes
que posean los ensamblados (DLLs) tengan acceso a determinados mensajes. Esto
puede parecer innecesario para una simple red P2P orientada a un mismo propósito, pero sí es de utilidad para interconectar aplicaciones de intercambio de propósitos diferentes.
Según el ejemplo anterior sólo
serán atendidos por el nodo aquellos
mensajes que sean de los tipos
UserSearchMsg, UserSearchResultMsg y
TextMessage . Aun cuando debido al
tráfico de la red pasen por este nodo
otros mensajes de diferentes tipos,
sólo los que sean instancias de estos
tres tipos serán entregados a la aplicación cliente
de PON que está ejecutando en ese nodo.
Una vez puestos estos filtros, el código de la aplicación cliente será notificado de la llegada de información (mensajes) para él, mediante el evento:
Internet, una red formada por clientes de una videoconferencia, etc.
Supongamos la red que se muestra en la figura 7.
public event OnMessageReceived EventMessageReceived;
El cual se encuentra en la clase PONKernel. Un
ejemplo de manejador para este evento sería el del
fuente 5.
Figura 7. Ejemplo de red con nodo crítico
Fuente 5
Auto-reconexión en PON
Un inconveniente en algunas redes P2P es la
cantidad de subredes no conexas que se puedan formar fruto de la caída inesperada de una conexión.
Para obviar este inconveniente, PON incorpora un
mecanismo de reconexión que funciona sin necesidad de interacción con servidor alguno. Es decir,
cada cliente o nodo es capaz de reparar por sí solo
la parte de la subred formada por sus nodos adyacentes y el nodo mismo. Ayuda a esto el mecanismo de excepciones y la recolección automática de
memoria en .NET.
El termino “red” es usado aquí para referirnos
a una red formada por aplicaciones, por ejemplo,
una red formada por un grupo de jugadores en
Supongamos entonces la caída del nodo marcado
en la figura 8; esto podría transformar la red y dividirla en varias subredes no conexas.
Figura 8. Red dividida por la caída de un nodo crítico
Esto es lo que ocurre en la mayoría de las tecnologías existentes que dependen de servidores, y es muy
común en el caso particular de Gnutella. En el caso de
PON al “caerse” un nodo, sus adyacentes tienen noticias mediante el envío de un mensaje de tipo
AdjacentDown de que esto ha ocurrido e intentan establecer conexiones entre ellos de manera inmediata.
La figura 9 a continuación muestra una posible topología para la nueva red luego de restaurarse la conexión, lo cual corre a cargo de PON. Sólo garantiza
que la red quede conexa sin atarse a ningún modelo
en específico para esto.
Figura 9. Red PON reconstruida
Al detectarse la caída de un nodo por medio del
mecanismo de excepciones de .NET se invoca uno de
los eventos:
<<dotNetManía
public void OnMessage( PONChatClient client,
PONMessage msg)
{
try
{
object obj = msg.GetContentObject();
if (obj is UserSearchResultMsg)
{
WhenUserSearchResult((UserSearchResultMsg)obj,
msg);
}
else if (obj is UserSearchMsg)
{
WhenUserSearch((UserSearchMsg)obj, msg);
}
else if (obj is TextMessage)
{
WhenTextMessage((TextMessage)obj, msg);
}
}
catch(Exception e)
{
//handle the exception here}
}
}
29
public event OnConnection EventIncomingConnectionDown;
public event OnConnection EventOutgoingConnectionDown;
Y a continuación se invoca el método de la clase PONKernel:
protected virtual void RestoreNetConectivity(
PONChatClient client);
Este método recibe como información cuál fue el
cliente que se desconectó de entre los adyacentes y,
gracias a la información que almacena PON sobre los
nodos y caminos que conoce hacia ciertos nodos, se
procede al intento de reconexión.
Interconexión de aplicaciones diferentes
<<dotNetManía
PON fue diseñado originalmente para interconectar aplicaciones diferentes pero puede evolucionar hasta llegar a ser una plataforma para redes P2P
de uso general.
Una de las debilidades de otras tecnologías es que
las redes de intercambio basadas en softwares diferentes no podían conectarse entre sí. Pero si las redes
de intercambio se sustentan en PON lo que viajará
por la red serán objetos .NET (cuyos tipos no pueden ser corrompidos si tiene un nombrado fuerte).
De este modo una nueva aplicación que se quiere
incorporar, y aprovechar el contexto PON, le basta
con crear una instancia de PON y valerse de la red
existente para filtrar aquellos objetos que sean de su
interés.
Note que lo único que se exige es tener instalado el .NET Framework y desarrollar la aplicación utilizando PON (es decir agregando el ensamblado PONFramework.DLL al proyecto y programar).
No es necesario instalar ningún SDK ni ningún servicio en el sistema.
De modo que si tenemos desarrolladas sobre PON
las siguientes aplicaciones, podemos tener el escenario que sigue (figura 10):
30
Figura 10. Múltiplices aplicaciones sobre PON conectadas
Donde los nodos pueden tener aplicaciones diferentes (tabla 1).
Aplicación de mensajería instantánea (al
estilo de MSN Messenger).
Aplicación para compartir imágenes de
coleccionistas de sellos.
Aplicación para el intercambio de archivos (al estilo eMule).
Tabla 1
Note que el cliente de PON no tiene porqué conocer sobre la existencia de nodos de la red que usen su
misma aplicación. Basta con que se conecte a cualquier nodo que utilice PON.
La operación de conectar dos nodos PON se puede hacer de forma explícita y directa invocando una
de las sobrecargas siguientes:
public void StartClient(PONEndPoint endpoint);
public void StartClient(string address, int port);
Donde PONEndPoint es:
[Serializable]
public class PONEndPoint
{
public string Address {get}
public int Port {get }
public PONEndPoint(string hostname,int port);
}
Pero también se puede hacer de forma global,
actualizando el ArrayList IPList de la instancia de la
clase PONKernelConfiguration que se le da en el constructor a la instancia de PONKernel. Entonces al ejecutarse el método PONKernel.Start() se abrirán conexiones a todos los nodos en esta lista.
Puesto que cada aplicación programada sobre
PON tiene implementado su propio conjunto de mensajes y su forma de manejar estos mensajes una vez
que lo reciban, y dado que PON no permite que se
entreguen mensajes de forma incorrecta o por error,
entonces el escenario mostrado anteriormente funcionará de forma transparente al cliente.
Un escenario útil es poder crear aplicaciones híbridas. Una de las limitaciones de los sistemas de chat actuales como MSN, Yahoo, ICQ, e IRC es que no tienen
forma de comunicarse entre ellos aun cuando todos tratan sobre el mismo tema. Lo que más se ha logrado (por
algunos grupos independientes o lobos solitarios) es hacer
un ejecutable que los incorpore todos para mostrar una
ventana por cada uno de ellos. Si estas aplicaciones hubiesen estado desarrolladas sobre PON esto se podría hacer
con facilidad porque todas las aplicaciones se pueden
entender con el mismo sustrato.
El enrutamiento de los
mensajes
Broadcast
Los mensajes de este tipo son enviados a todos los nodos de la red. La aplicación en el nodo fuente lo envía a
PON, quien a su vez se lo da a todos sus
adyacentes y cada uno de ellos vuelve a
hacer lo mismo, es decir, enviarlo a
todos sus adyacentes. PON incorpora
un mecanismo de identificación de mensajes por GUID que evita el “eco” en la
red porque evita que un mismo mensaje sea procesado dos veces por un mismo nodo. El método para hacer broadcast de un objeto search es:
kernel.CManager.BroadCastMessage(search);
Este método envia un mensaje hacia
todos los nodos de la red PON, y por
supuesto que serán capaces de procesarlo aquellos que pasen los filtros (dispongan del tipo real del objeto) indicados por la aplicación cliente del nodo
PON.
Personal
Estos mensajes viajan siguiendo un
camino de costo mínimo (mayor velocidad de transmisión) entre la fuente y
el destino. Este camino se determina de
manera automática por PON, garantizando, para no provocar atoros, que
nodos PON con poco ancho de banda
no sean usados como intermediarios salvo en los casos imprescindibles porque
no hay otra forma de llegar (figura 11).
7
Figura 11. Nodos PON detrás de una intranet se conectan con nodos fuera
La forma de enviar un mensaje personal, es decir dirigido a un usuario
determinado, es mediante:
kernel.CManager.SendMessageTo(UserName,
textmsg);
Aquí UserName es un GUID que no
es lo mismo que el Screen Name. Screen
Name puede ser una cadena como por
ejemplo “Pepe” y no tiene porqué ser
única. La aplicación cliente de PON
debe ser muy cuidadosa con su implementación y ser consistente con esta
propuesta. Para identificar realmente
a los nodos de modo directo (personalizado) se deben utilizar los
Username (que son en realidad
GUID).
Sirva como ejemplo el siguiente
escenario:
Un usuario A tiene un PC en su
oficina en la que sólo dispone de
HTTP y no tiene acceso directo a
Internet. Este usuario está impedido
de utilizar una aplicación como eMule
o Kazaa. Sin embargo, si eMule hubiese estado desarrollada sobre PON, y
A conociera de la existencia en su red
de otro usuario B del mismo eMule,
pero que si tuviera acceso a Internet,
entonces A podría conectar su eMule
al eMule de B y de esta manera formar
parte de la misma red eMule de B. Pero
es más, no se exige que B tenga en ejecución su eMule sino bastaría con que
B estuviese ejecutando cualquier aplicación basada en PON.
PON nos ofrece la posibilidad de formar una nueva red .NET
a .NET,pero de aplicaciones heterogéneas,a la escala
que nuestras conexiones lo permitan,con una mayor
seguridad para todos los usuarios
La ventaja de este modo de tratar los
mensajes es que usuarios detrás de un
cortafuegos podrán utilizar, sin impedimentos, aplicaciones de intercambio
siempre que estén basadas en PON.
Lo anterior no viola los derechos de
B, porque si lo desea B puede evitar que
A lo utilice como mediador. PON pro-
vee de un sencillo mecanismo mediante
el cual cada aplicación puede especificar
Claro recuerde que las redes de intercambio se basan en el principio de que hay que dar para recibir. En el caso de eMule por ejemplo entre mas
se da, mas se puede recibir.
<<dotNetManía
Los mensajes que transitan a través
de una red PON, pueden ser principalmente de dos tipos: Broadcast y Personal.
El primero es enviado desde un nodo al
resto de la red, y el segundo va desde un
nodo a otro. Una modificación introducida por PON es que los mensajes
viajan siguiendo el camino más rápido
de un nodo a otro. PON se encarga de
este cálculo. Con esto se evita el problema antes mencionado de las conexiones forzadas.
31
qué IPs no permite que se conecten a ella. También se
puede limitar la cantidad de conexiones entrantes y
salientes. Esto se hace poniendo las IPs que se quieren
bloquear en la lista BannedIPs en la instancia de
PONKErnelConfiguration que se le pasa en el constructor al kernel de PON (PONKernel). Por ejemplo, asumiendo que KernelConfig es el objeto que está siendo
utilizado por el kernel de PON y que el número de IP
a bloquear es 192.168.121.3 habría que hacer:
KernelConfig.BannedIPs.Add("192.168.121.3");
De este modo se puede construir una nueva red
de usuarios de intranets distantes que compartan información sin tener que tener acceso directo a Internet
o sin tener que utilizar subterfugios como túneles
HTTP, bouncers, enmascaramientos y otros.
La figura 12 muestra un posible escenario basado en PON. En dicho escenario se tienen tres tipos
de aplicaciones diferentes y varios nodos de cada uno
de ellos intercambiando información entre ellos,
muchos de ellos detrás de cortafuegos en el interior
de intranets.
PON se basa en el consistente, flexible y dinámico
modelo de objetos de .NET (a nuestro juicio la plataforma que ofrece el mejor modelo de objetos hasta el
presente). Pero además la capacidad de nombrado fuerte de un ensamblado permite a PON garantizar, si la
aplicación cliente lo decide usar, claro, un trasegar de
objetos con robustez, seguridad y privacidad. La disponibilidad, en aumento, de NET para la mayoría de
las plataformas como Windows, Linux, Mac y móviles
nos da la posibilidad entonces de disponer de un universo P2P mejor conectado, más seguro y más fácil de
que se desarrollen aplicaciones sobre él.
PON proporciona la ventaja de que los clientes
pueden programar aplicaciones que permitan acceder a sus facilidades mediante una aplicación que ejecutan localmente (sin complicadas instalaciones) y sin
tener que acceder a sitios Web. PON está concebido
para facilitar el desarrollo de aplicaciones que ayuden
a formar redes descentralizadas sin exigencia de servidores, lo que no excluye la utilidad de PON en aplicaciones que necesiten de servidores.
Se han desarrollado ya algunas aplicaciones basadas en PON que podrán ser presentadas en un futuro artículo.
Referencias
[1]
E-Book Cracking the Code: P2P Application
Development
[2]
How P2P and Kazaa Works,
www.kazaa.com/us/help/guide_aboutp2p.htm
[3]
How Kazaa v2 Works, ndnn.org/blog/down
loads/summit/UENSummit_Peer_2_Peer.ppt
[4]
forum.emule-project.net/
lofiversion/index.php/t54911.html
[5]
forum.emule-project.net/index. php?
showtopic=46749&view=getlastpost
[6]
www.emule-help.com/summary.htm
[7]
Ariño, Juanjo, Lphant, primer peer to peer
bajo .NET, dotNetManía No 5, junio 2004
Figura 12. Ejemplo de un posible escenario con PON
<<dotNetManía
Conclusiones
32
PON nos ofrece la posibilidad de formar una nueva red .NET a .NET, pero de aplicaciones heterogéneas, a la escala que nuestras conexiones lo permitan,
con una mayor seguridad para todos los usuarios.
PON supera algunas de las limitantes de las tecnologías actuales. Corrige el uso de protocolos HardCoded así como garantiza la posibilidad de extender la
red a un uso mayor si es deseado, es decir, montar
nuevas aplicaciones aprovechando redes ya existentes
sobre PON. PON soluciona a su vez el problema de
las conexiones forzadas y el problema de las redes de
aplicaciones no conexas.
Miguel Katrib
Es Dr.y Catedrático del Departamento de
Computación de la Universidad de La Habana y
jefe del grupo WEBOO dedicado a la
Orientación a Objetos y a la Programación en la
WEB.Es un especialista en lenguajes de
programación y entusiasta de la tecnología .NET
y el lenguaje C#.Miguel y el grupo WEBOO son
colaboradores habituales de dotNetManía
Leonardo Paneque
Es estudiante del
Departamento de
Computación de la Universidad
de La Habana y programador y
administrador de la red del
grupo WEBOO. Paneque es un
entusiasta usuario y desarrollador de las redes peer to peer.
Ilustraciones: Yamil Hernández
dnm.plataforma.net
Rodrigo Corral
Sistemas distribuidos en .NET
con Remoting (II)
Después de los conceptos sobre la arquitectura de .NET Remoting que vimos en la
anterior entrega,podemos zambullirnos por completo en la creación de objetos remotos.En este capítulo veremos un tema vital,los diferentes comportamientos que pueden presentar los objetos remotos en .NET Remoting.A menudo la primera decisión
que tenemos que tomar a la hora de diseñar un objeto remoto o una familia de objetos es elegir el modelo de comportamiento de los mismos.
objetos remotos
Básicamente, existen dos grandes tipos de objetos remotos en .NET Remoting atendiendo a su comportamiento:
• Objetos por valor (ByValue): Son objetos serializables
que son pasados en forma de copia desde el servidor al cliente.
• Objetos por referencia (ByRef): Son objetos remotos en sentido estricto que se ejecutan en el servidor y permiten que el cliente realice llamadas
a sus métodos. Dentro de estos objetos encontramos dos grandes grupos en función de cómo
se activan:
o Objetos activados por el servidor: No se crean hasta que llamamos a sus métodos. Dentro de los
objetos activados por el servidor hay dos modos
de funcionamiento:
• Objetos SingleCall: El objeto atiende a la llamada y se destruye.
• Objetos Singleton: Un solo objeto atiende todas
las peticiones
Server Activated Object
(RegisterWellKnowObjectType)
Rodrigo Corral
dotNetManía. Es Microsoft MVP
y analista de Sisteplant, empresa
líder en el sector de las
aplicaciones de gestión industrial
MarshalByRefObject
Client Activated Object
(RegisterActivatedServiceType)
MarshalByValObject
o Objetos activados por el cliente: Se crean en el
momento que los instanciamos.
Objetos por valor (MBV)
El uso de objetos por valor supone serializar los
objetos, es decir, ponerles en algún formato persistente para luego deserializarlos en la parte cliente
para su uso.
Para que un objeto sea serializable en .NET es
suficiente que se le añada el atributo [Serializable]
o que el objeto implemente la interfaz ISerializable.
Los objetos por valor no son objetos remotos en
un sentido estricto. Todos los métodos del objeto son
ejecutados de manera local respecto al cliente. Dado
que la ejecución de los objetos es local esto implica
que, al contrario que con los objetos por referencia,
el código ejecutable del objeto debe estar disponible
en el lado cliente de la aplicación.
Es importante señalar también que cuando un
objeto por valor mantiene referencias a otros objetos, éstos deben ser objetos serializables o
MarshallByRefObjects.
SingleCall
(WellKnonwObjectMode.SingleCall)
Singleton
(WellKnonwObjectMode.Singleton)
<<dotNetManía
<< Diferentes comportamientos de los
33
<< dnm.plataforma.net
¿Cuándo usar objetos por valor?
•
•
•
•
Cuando el objeto es pequeño.
Cuando vamos a hacer un uso intensivo del objeto.
Cuando la seguridad no es un factor importante.
Cuando el objeto no depende de recursos remotos.
A no ser que se cumplan estas cuatro condiciones,
es más interesante usar objetos por referencia.
Ejemplo: MBVSample1
El uso de objetos por valor supone
serializar los objetos, es decir,
ponerles en algún formato
persistente para luego deserializarlos
en la parte cliente para su uso
Objetos por referencia (MBR)
Los objetos por referencia heredan de la clase
MarshalByRefObject.
Un objeto por referencia es un objeto totalmente
remoto, corre en el lado servidor y acepta llamadas a sus
métodos públicos por parte de los clientes. Sus datos se
almacenan en la memoria del servidor y sus métodos son
ejecutados en el dominio de aplicación del servidor.
Al contrario que los objetos por valor, el cliente
no obtiene una copia del objeto, sino que obtiene una
especie de puntero al objeto; esta especie de puntero
es lo que se denomina proxy.
Un proxy se diferencia de un puntero en que no contiene la dirección de memoria en la que el objeto está
ubicado, sino datos referentes al objeto (dirección IP del
servidor y un identificador único del objeto) que permiten identificar al objeto del manera única.
Como ya hemos comentado existen dos grandes
tipos de objetos por referencia:
• Objetos activados en/por el servidor.
• Objetos activados en/por el cliente.
<<dotNetManía
Objetos activados en servidor (SAO)
34
Son comparables, en cierto modo, a los servicios
WEB, puesto que no mantiene el estado entre llamadas.
Cuando un cliente pide una referencia a un objeto SAO, no se envía ningún mensaje al servidor. Sólo
cuando alguno de los métodos del objeto es llamado
el servidor recibe una notificación.
1
Según la configuración del objeto, el servidor puede crear una nueva instancia para atender la petición
y luego eliminar el objeto, lo que es conocido como
modo SingleCall o bien puede usar un único objeto
para atender todas la peticiones, lo que es conocido
como modo Singleton.
Los objetos activados por el servidor no mantienen estado, aunque se puede lograr para los Singleton;
esto hace que sean muy escalables.
Un problema relacionado con los objetos activados
por el servidor es que no se pueden construir más que a
partir de su constructor por defecto, debido a que el
cliente obtiene el proxy antes de que el objeto esté realmente creado. Dado que los constructores se utilizan
para establecer el estado del objeto, y que los objetos
SAO no mantiene estado, esto no es un gran problema.
Objetos SingleCall
Para los objetos SingleCall el servidor va a crear
un objeto, ejecutar la llamada, y destruir el objeto.
Los objetos SingleCall son extremadamente escalables, puesto que no se “desperdician” recursos del
servidor manteniendo el estado del objeto.
Otro motivo para usar este tipo de objetos es que son
muy adecuados para realizar balanceo de carga; esto es
complicado con objetos con estado.
Para configurar un objeto como SingleCall, el host
debe realizar la siguiente llamada:
RemotingConfiguration.RegisterWellKnownServiceType
(
Typeof(<Clase>), "<URI>",
WellKnownObjectMode.SingleCall);
Ejemplo: SAOSingleCallSample1
Objetos Singleton
Sólo una instancia de un objeto remoto de tipo
Singleton existirá en un momento dado.
Cuando un host que ha configurado un objeto
como Singleton recibe una petición, .NET Remoting
comprueba sus tablas internas de objetos registrados
para comprobar si un objeto de esa clase ya existe para
el dominio de aplicación del host. Si el objeto aún no
existe se creará, si el objeto ya existe se utilizara éste
para atender la petición.
El servidor garantiza que uno y sólo un objeto va
a ser accesible al mismo tiempo.
El motivo principal para usar objetos Singleton es
que los clientes puedan acceder a información compartida. Dado que todos los clientes usan el mismo
objeto, todos los clientes ven la misma información.
Si un cliente cambia el estado del objeto todos los
clientes verán ese cambio.
Los ejemplos pueden descargarse del material de apoyo de este artículo en http://www.dotnetmania.com/Articulos/013
RemotingConfiguration.RegisterWellKnownServiceType
(
Typeof(<Clase>), "<URI>",
WellKnownObjectMode.Singleton);
Ejemplo: SAOSingletonSample1
Un objeto por referencia es un
objeto totalmente remoto, corre
en el lado servidor y acepta llamadas
a sus métodos públicos por parte
de los clientes. Sus datos se almacenan en la memoria del servidor y sus
métodos son ejecutados en el
dominio de aplicación del servidor
Objetos activados en cliente (CAO)
Los objetos activados en el cliente se comportan
de manera similar a los objetos no remotos. Con la
salvedad de que se ejecutan en el dominio de aplicación del servidor.
Cuando el cliente solicita la creación de un objeto, éste se crea de manera inmediata. En el lado cliente se crea un proxy que mantiene un ObjRef al igual
que para los SAO.
Los objetos CAO permiten mantener el estado,
las variables miembro que establezcamos se comportarán de la manera habitual a la que estamos acostumbrados.
Los objetos CAO son creados explícitamente por
el cliente, por eso pueden crearse usando constructores diferentes del constructor por defecto.
Para configurar un objeto remoto como CAO, la
aplicación host debe configurar el objeto con las
siguientes llamadas:
RemotingConfiguration.ApplicationName =
"<ServerAppName>";
RemotingConfiguration.RegisterActivatedServiceTy
pe(typeof(MyRemoteObject));
La URL del objeto remoto tendra la forma:
<protocol>://<hostname>:<port>/AplicationName
Para poder usar el operador new para crear objetos es necesario extraer los metadatos del assembly que
contiene los objetos remotos usando SoapSuds.exe. La
línea de comandos a ejecutar será:
Soapsuds -ia:server -nowp
-oa:generated_metadata.dll
La DLL con los metadatos que se genera tiene que
añadirse a las referencias del cliente.
Para poder usar el operador new para crear objetos remotos, es necesario registrar antes el objeto en
el cliente como un objeto CAO. Para ello ejecutaremos el siguiente código:
RemotingConfiguration.RegisterActivatedClientType(
typeof(<Class>), "<ServerURI>");
Ejemplo: CAOSample1
Gestión del tiempo de vida de los objetos
Sin duda un punto un poco oscuro en .NET
Remoting es como se maneja el tiempo de vida de los
objetos. Los objetos “normales” de .NET son destruidos mediante un sistema de recolección de basura, que comprueba si el objeto está en uso.
Evidentemente este sistema es insuficiente cuando tratamos con objetos remotos; el motivo es que un servidor no sabe nada acerca de cuántos clientes tienen
una referencia al objeto que sirve.
En COM este problema se solucionaba mediante
una combinación de pings y contaje de referencias. Si
bien es una solución válida, también es cierto que presenta problemas:
a. El sistema de contaje de referencias tiende a ser
propenso a errores.
b. Los pings se pueden ver interferidos por la presencia de firewalls.
Estos problemas han llevado a una nueva arquitectura para gestión de la vida de los objetos en .NET
Remoting basada en concesiones (leases).
Cada dominio de aplicación contiene su propio administrador de concesiones que se responsabiliza de monitorizar todas las concesiones dentro del dominio de aplicación. El administrador de concesiones es el encargado de comprobar de manera periódica el momento en
el que caducan. Si una concesión ha caducado, se invocará a los beneficiarios registrados de la misma y se les
ofrece la oportunidad de renovarla. Si ninguno de los
beneficiarios decide hacerlo, el administrador de concesiones los libera y el objeto remoto podrá ser recolectado como basura a partir de ese momento. El administrador de concesiones mantiene una lista de las mismas,
ordenadas según la fecha de caducidad de manera que la
<<dotNetManía
Las peticiones de los diversos clientes se atienden
en hilos de ejecución paralelos por ese motivo; los
objetos Singleton deben ser thread safe.
Para configurar un objeto como Singleton el host
debe realizar la siguiente llamada:
35
concesión a la que le queda menos tiempo para que caduque se almacena en la parte superior de la lista.
La concesiones implementan la interfaz ILease y
almacenan un grupo de propiedades que determina las
políticas y métodos de renovación. Las renovaciones se
pueden producir simplemente con una invocación a alguno de los métodos del objeto remoto.
Cada vez que es llamado un método en el objeto
remoto, el tiempo de duración de la misma se establece
en el máximo del LeaseTime actual más el RenewOnCallTime.
Cuando caduca el LeaseTime, se pregunta al beneficiario
si desea renovar la concesión.
El administrador de concesiones también mantiene una lista de los beneficiarios (que implementan la
interfaz ISponsor) almacenados en orden decreciente en
función de la duración. Cuando es preciso renovar una
concesión, se solicita a uno o más beneficiarios, empezando por la parte superior de la lista, que lo hagan. El
primer puesto de la lista lo ocupa el beneficiario al que
primero se ha solicitado la mayor duración para la renovación de su concesión. Si un beneficiario no responde
en el tiempo que dura SponsorshipTimeOut, se eliminará de la lista.
La gran flexibilidad de esta técnica de gestión
de vida de los objetos es que ellos mismos pueden
proporcionar sus propias concesiones y, por tanto,
controlar su propia duración. Cuando un objeto
quiere controlar su tiempo de vida debe sobreescribir el método InitializeLifetimeService
en MarshalByRefObject de la siguiente
manera, especificando los TimeSpan adecuados para el caso.
public class Sample : MarshalByRefObject {
public override Object InitializeLifetimeService()
{
ILease lease = (ILease)base.InitializeLifetimeService();
if (lease.CurrentState == LeaseState.Initial) {
lease.SponsorshipTimeout = TimeSpan.FromMinutes(1);
lease.InitialLeaseTime = TimeSpan.FromMinutes(1);
lease.RenewOnCallTime
= TimeSpan.FromSeconds(1);
}
return lease;
}
}
<<dotNetManía
Fuente 1
36
Las propiedades de una concesión sólo se pueden
modificar cuando ésta se encuentra en su estado inactivo. La implementación de InitializeLifetimeService
normalmente llama al correspondiente método de la
clase base para recuperar la concesión existente para el
objeto remoto. Si la referencia para el objeto no se ha
calculado con anterioridad, la concesión devuelta estará en su estado inicial y se podrán establecer sus propiedades. Una vez se ha calculado la referencia para el
objeto, la concesión pasa del estado inicial a estado activo y se ignorará cualquier intento de inicializar las pro-
piedades de la instancia (una excepción). Se llama a
InitializeLifetimeService cuando se activa el objeto
remoto. Se puede proporcionar una lista de beneficiarios para la concesión con la llamada de activación, así
como agregar beneficiarios adicionales en cualquier
momento mientras la concesión se encuentre activa.
Los posibles eventos que pueden provocar la renovación de una concesión son:
• Que el cliente invoque al método Renew en la clase Lease.
• Que la concesión solicite un Renewal a un beneficiario.
Cuando un cliente invoca a un método en el objeto, la concesión se renueva automáticamente por
medio del valor RenewOnCallTime.
Cuando caduca una concesión, su estado interno
cambia de Active a Expired, no se pueden realizar llamadas adicionales a los beneficiarios y el objeto se recolecta como basura. Puesto que en ocasiones resulta complicado que los objetos remotos puedan realizar una devolución de llamada en el beneficiario si éste se distribuye
en el Web o tras un cortafuegos, no es condición necesaria que el beneficiario deba encontrarse en la misma
ubicación que el cliente. La única condición es que el
beneficiario se encuentre en cualquier parte de la red a
la que el objeto remoto pueda obtener acceso.
La utilización de las concesiones para administrar
la duración de los objetos remotos constituye un enfoque alternativo al recuento de referencias, que suele
resultar de mayor complejidad y menor precisión en
conexiones de red menos confiables. Aunque en principio pueda parecer que la duración del objeto remoto se amplía más de lo necesario, la reducción en el tráfico de la red que suponen el recuento de referencias y
la solicitud de eco de los clientes, hacen de las concesiones una solución muy efectiva.
En la próxima entrega veremos cómo utilizar archivos de configuración para configurar las características
de nuestros objetos, lo que nos va a permitir que el código sea mucho más legible evitando tener que crear los
canales y registrar los objetos desde el código. También
crearemos un servicio que nos servirá como host genérico para nuestros servidores de Remoting. Así mismo
veremos que podemos alojar nuestros objetos en un servidor Web utilizando Internet Information Server.
dnm.plataforma.net
José Miguel Torres
Interoperabilidad no administrada
y migración (II)
La interoperabilidad de .NET desde COM es quizás mas inusual aunque sus ventajas nos
ofrecen una nueva técnica en un entorno de migración e interoperabilidad.En esta entrega conoceremos cómo utilizar dicha técnica además de las consideraciones previas para
interoperar de una manera más eficiente.
José Miguel Torres
dotNetManía. Es técnico
superior en desarrollo de
aplicaciones informáticas y
trabaja como arquitecto de
software en el departamento de
tecnologías de la
información de MRW
En el número anterior hablamos de cómo utilizábamos un componente COM en un proyecto bajo CLR
y ahora planteamos todo lo contrario, cómo un componente .NET lo utilizamos desde un proyecto Visual Basic
6.0, por ejemplo. Lo más obvio es que sea el primer caso,
ya que en un proceso de migración se suele plantear la
codificación de nuevo código en .NET y aprovechar el
antiguo basado en COM bajo el paraguas de CLR. Pero
estoy seguro que en algunos casos será necesario crear
un componente en .NET y que éste funcione bajo una
aplicación en Visual Basic 6.0, sea por ejemplo, porque
la política de migración así lo requiera.
Antes de empezar a codificar nada daremos a
conocer una serie de requisitos que deberán tener las
clases .NET que pretendan ser utilizadas por componentes COM. Recordemos que COM callable wrapper (CCW) será el objeto que hará de puente y nos
facilitará el proceso y cuando hagamos la llamada al
componente NET desde COM, realmente estaremos llamando a un objeto CCW.
En primer lugar se debe implementar una interfaz en el código administrado a la clase pública. Por
ejemplo, creamos un nuevo proyecto de biblioteca
de clases en C# llamado NETaCOM. Seguidamente en
la clase ponemos el nombre clsPrueba y añadimos al
espacio de nombre predeterminado el fuente 1.
En segundo lugar, hay que procurar declarar explícitamente la accesibilidad tanto de la clase como de
los métodos o elementos que queremos que sean accesibles desde COM. Fíjese que hemos creado una
interfaz y que la clase clsPrueba implementa dicha
interfaz. Esto es imprescindible para tener accesibilidad desde componentes COM.
using System;
namespace NETaCOM
{
public interface IPrueba
{
// dos propiedades
string Version
{get;set;}
int Numero
{get;set;}
// utilizaremos dos métodos
void Generar(int newNumero);
string Resultado();
}
/// <summary>
/// Este será una clase administrada que
/// utilizaremos desde COM (Visual Basic 6.0).
/// </summary>
public class clsPrueba : IPrueba
{
//atributos
private string _version;
private int _numero;
public clsPrueba(){}
// dos propiedades
public string Version { get {return _version;}
set {_version = value;} }
public int Numero{ get{return _numero;}
set{_numero = value;} }
// utilizaremos dos métodos
public void Generar(int newNumero)
{
_version += "." + newNumero.ToString();
}
public string Resultado()
{
return _version.Substring(0,_numero).ToString();
}
}
}
Fuente 1. Ejemplo de clase .NET codificada para que
pueda ser llamada desde COM.
<<dotNetManía
<< Implementar .NET desde COM
37
Aunque no es estrictamente necesario, sí se recomienda firmar el ensamblado con un nombre seguro. El firmado mejorará la generación de los identificadores de clase (CLSID) para las clases administradas. Utilizando sn.exe creamos un archivo de firmado llamado NETaCOM.snk. Es importante asignar el
atributo AssemblyTitle del ensamblado ya que equivale al nombre del proyecto en Visual Basic 6.0.
Hasta este punto hemos desarrollado y firmado
un ensamblado, el componente .NET que utilizaremos desde COM. El siguiente paso consiste en la
implementación, es decir, tenemos que crear la biblioteca de tipos del ensamblado. La herramienta que
utilizaremos para tal fin es TlbExp.exe. Ésta se ejecuta desde la consola del intérprete de comandos de
Visual Studio .NET, igual que TlbImp.exe, y el proceso será muy similar.
Para terminar haremos una prueba desde Visual
Basic 6.0. Trataremos de referenciar en un nuevo proyecto el fichero TLB y crearemos unas instancias a
la clase. En un nuevo proyecto de Visual Basic 6.0 en
el menú referencias localizamos el archivo resultante como muestra la figura 2.
C:\TlbExp.exe NETaCOM.dll /out:NETaCOM.tlb
El archivo resultante es la biblioteca de tipos del
ensamblado con extensión .TLB. Seguidamente registraremos la biblioteca de tipos con regasm /tlb. De
esta forma expondremos el componente para que
esté disponible para los clientes COM a partir del
ensamblado indicado en el segundo parámetro. La
sintaxis es la siguiente:
C:\Regasm /tlb: NETaCOM.tlb NETaCOM.dll
Por último, se recomienda mediante gacutil.exe
instalar el ensamblado en la caché global (GAC) para
que se encuentre disponible (ensamblado compartido) para los posibles clientes COM, así que:
C:\gacutil.exe /i NETaCOM.dll
Figura 2. Localización y referencia de la biblioteca de tipos resultante de un
componente .NET desde Visual Basic 6.0.
Desde el fuente 2 creamos un objeto NETaCOM.IPrueba
e interactuamos:
Si no se realiza ésta última, y deseamos tener el
ensamblado en un contexto privado, deberemos
copiar el archivo NETaCOM.dll en el directorio de la
aplicación VB 6.0 (figura 1).
Private Sub Form_Load()
Dim objeto As NETaCOM.IPrueba
Set objeto = New clsPrueba
objeto.Numero = 2
objeto.Version = "1.1"
MsgBox objeto.Resultado
Set objeto = Nothing
End Sub
<<dotNetManía
Fuente 2
38
Figura 1. Estructura de directorios y entrada del Registro
para implementación privada.
Ahora que los estamos viendo
funcionar, fijémonos en que realmente hemos instanciado la interfaz IPrueba , aunque creemos un
objeto de tipo clsPrueba. Cuando
intentamos instancias con set, por
ejemplo, el método QueryInterface
de la interfaz de COM IUnknown,
comprueba si admite clsPrueba. A
Consideraciones previas para
interoperar
Si en un futuro pretendemos seguir desarrollando componentes basados en COM quizás nos interese saber algunas consideraciones para que éste pueda
ser utilizado desde .NET.
Hasta ahora hemos visto todas las diferencias y nos
podríamos hacer una idea aproximada, pero en resumidas cuentas, ¿qué debemos tener en cuenta?
Pues bien, en primer lugar crear biblioteca de tipo.
Como hemos visto, por defecto Visual Basic 6.0 creaba dichas bibliotecas dentro del archivo .DLL o .EXE
ActiveX de manera implícita, incluso podíamos separar la biblioteca de tipos en un archivo .TLB. Quizás
otros lenguajes no tengan dicha funcionalidad y en ese
caso sería conveniente asegurarnos de crear la biblioteca de tipos. Igual de importante es “crear” que registrar dichas bibliotecas de tipos e incorporar la información regional y de versión.
Utilizar matrices de longitud fija ya que son autodescriptivas. Así el contador de referencia podrá calcular el tamaño, el rango y el límite en tiempo de ejecución. Utilizar tipos de datos que se puedan representar en bits o bytes para facilitar el trabajo en el cálculo de referencias. Asimismo evitar las llamadas intermodulares ya que implica un mayor costo del cálculo de referencias y limitar al máximo el retorno de
valores HRESULT si trabajamos con C++. Liberar recursos explícitamente. El ejemplo más claro sería el
Set obj=Nothing utilizado en Visual Basic 6.0.
Por otra parte, si lo que desea es generar un componente .NET cuyo cliente esté basado en COM, evite los
constructores con parámetros y los miembros estáticos.
Utilice HRESULT para las excepciones definidas por el usuario, así como defina interfaces públicas que implementen la clase administrada y para facilitar el trabajo, asigne identificadores únicos GUID.
Migración e interoperabilidad
El principal objetivo de la interoperabilidad es la
integración de varias tecnologías. Éste es el pilar fundamental para la migración escalonada. Cuando una
empresa posee una arquitectura o aplicación distribuida totalmente funcional y se plantea la evolución
de la misma, la migración total es una opción muy costosa en cuanto a desarrollo y a curva de aprendizaje
del personal, y delicada, ya que se van a poner en marcha nuevos modelos de programación.
La remodificación de nuevos componentes .NET
que interoperen con los COM existentes ofrece, dentro
de las estrategias de migración, por ejemplo, una opción
muy válida, ya que desde un principio se desarrollan com-
ponentes, sea cual sea la capa funcional (datos, negocio...),
en una nueva tecnología. Sin embargo, la etapa de captación de nuevas necesidades y de análisis inicial sigue
siendo imprescindible, puesto que el alcance de la aplicación no es la misma con la llegada de .NET, Longhorn
o Yukon (éstos próximamente), entre muchos otros.
La remodificación de nuevos componentes
.NET que interoperen con los COM existentes
ofrece,dentro de las estrategias de migración,
una opción muy válida,ya que desde un
principio se desarrollan componentes,sea
cual sea la capa funcional (datos,negocio...),
en una nueva tecnología
Como en casi todo, no existe una fórmula o plantilla estándar milagrosa, pero sí existen herramientas y
metodologías experimentadas por otros, como el ejemplo de la migración horizontal, en la que se plantea la
migración de arquitecturas DNA 2000 a .NET por capas,
o la migración vertical en la que se plantea la migración
por procesos de negocio, desde la capa de usuario a la
capa de datos. Todo esto no son más que posibilidades
que cada empresa deberá estudiar, decidir e implementar y en las que los servicios, como los que ofrece el CLR
para facilitar la interoperabilidad, son un apoyo más a la
evolución permanente de las aplicaciones adecuándose
o no, allá cada uno, a las últimas tendencias tecnológicas que aparecen tras la mercadotecnia.
Lo que es bastante evidente es que tras el ciclo del
que habla Microsoft de 7 a 10 años, COM será una
pequeña parte del volumen de código que se manejará, mientras ambos contextos, administrado o no, convivirán entre ellos.
Conclusión
En esta entrega hemos visto la interoperabilidad entre
COM y .NET y viceversa. Asimismo, hemos descrito
unos consejos para mejorar la interoperabilidad y además hemos conocido todas las técnicas para dicho fin;
bien, todas menos una. Me explico. En la primera parte
hablamos de una clase, TypeLibConverter, que permite
la exportación e importación de biblioteca de tipos a
ensamblados y que aún no hemos visto. La utilización
de esta clase y la interoperabilidad con funciones de DLLs
externas, será la siguiente parte sobre la interoperabilidad no administrada.
<<dotNetManía
partir de aquí de rienda suelta a su imaginación y disfrute de la interoperabilidad .NET a COM.
39
dnm.servidores.sql
Salvador Ramos
SQL Server Analysis Services
¡Hola Cubo! (y IV)
Llegó el momento de explotar los datos almacenados en nuestra base de datos
multidimensional, desde algunas de las herramientas cliente que Microsoft nos
ofrece para ello.Aquí mostraremos el Examinador de cubos del Analysis Manager,
Microsoft Excel utilizando el PivotTable Service, la aplicación de ejemplo que viene con Analsys Services y Microsoft Data Analyzer.
<< En primer lugar, como supongo que estaréis ansiosos de
empezar a ver la información y a “jugar” con ella, vamos
a utilizar el Examinador de Cubos, para ello pulsaremos el
botón secundario del ratón sobre nuestro cubo y elegiremos la opción “Examinar datos”.
se muestran las medidas en función de las dimensiones colocadas en las áreas de filas y columnas y de los
filtros establecidos. En nuestro caso hemos colocado
las medidas Artículo y Tiempo en el área de filas, y
estamos mostrando todas las medidas en el área de
datos, ya que esta herramienta sólo tiene la opción de
mostrar todas las medidas del cubo.
Figura 2.Vista del examinador de cubos mostrando
una consulta del cubo Ventas.
Figura 1.Acceso al examinador de cubos
desde el Analysis Manager.
Salvador Ramos
dotNetManía. Es Microsoft SQL
Server MVP y responsable del
sitio HelpDNA.net.Trabaja como
director de informática de la red
de estaciones de
servicio Andamur
Con esta herramienta podréis ir realizando multitud de consultas simplemente arrastrando y soltando las diversas dimensiones sobre las áreas de filas y
columnas. También es importante destacar que sobre
las dimensiones que tenéis en la parte superior, si desplegáis cualquiera de los combos podéis filtrar la información que se visualizará en el área de datos, donde
Aunque con esta herramienta podemos visualizar
cierta información, no es suficiente para obtener todo
el rendimiento que esperamos de la información almacenada. Simplemente la utilizaremos durante etapas
de desarrollo y modificaciones, para comprobar rápidamente los resultados.
Hay en el mercado gran variedad de herramientas
que nos facilitan el acceso a información almacenada
en cubos, aunque aquí vamos a mostrar sólo el acceso
<< dnm.servidores.sql
[ ]
SQL Server Reporting Services es una
nueva plataforma de elaboración de informes,
que también permite la creación de soluciones
Business Intelligence. Puede ser otra alternativa
muy interesante para el desarrollador a la hora
de crear informes que accedan a los datos que
tenemos almacenados en nuestros cubos.
Recuerde el lector que esta herramienta viene
incluida con SQL Server 2000, sin coste adicional.
Podemos utilizar OLE DB para OLAP o ADO MD
(ActiveX Data Objects Multidimensional) para escribir código que nos permita manipular y acceder a cubos desde
nuestras aplicaciones. También tenemos disponible ADO
MD .NET para su utilización desde la plataforma .NET.
El PTS (PivotTable Service), que es el cliente de los servicios OLAP, nos proporciona el interfaz que permite a
las aplicaciones cliente conectarse al servidor OLAP de
SQL Server, mediante los dos métodos citados anteriormente. También es importante saber que Microsoft
Excel, a partir de la versión 2000, incorpora la funcionalidad del PivotTable Service permitiendo acceder a
Analysis Services y a cualquier otra fuente de datos relacionales, proporcionándonos así una potente herramienta de análisis. PTS no es una herramienta de usuario final, no tiene una interfaz de usuario, incluso puede pasar totalmente desapercibido que lo estamos utilizando, ya que se instala tanto con las herramientas cliente de Analysis Services como con MS Excel. Es un componente oculto que proporciona la conectividad y las
interfaces para interactuar con el servidor. Además, facilita la posibilidad de poder realizar operaciones en modalidad desconectada, ya que la información que viaja al
cliente se almacena en él, y posteriormente podemos
analizarla sin requerir el acceso al servidor. Es decir,
podemos acceder, por ejemplo, desde una Excel al servidor, obtener unos datos y guardar la hoja. Esta hoja
puede ser enviada a cualquier persona, y aunque no tenga conexión con el servidor la podrá utilizar sin problemas, aunque evidentemente no podrá actualizar con
nuevos datos almacenados en el servidor, ni realizar con-
sultas ad hoc si no dispone de conectividad, sólo tendrá
acceso a los datos almacenados anteriormente, perdiendo
el dinamismo que nos ofrece cuando estamos conectados al servidor.
Comencemos a usar MS Excel para analizar la información de nuestra base de datos. Para ello utilizaremos
las Tabla Dinámicas, que son tablas interactivas que nos
permiten trabajar con datos, interactuar con ellos, y
realizar consultas ad hoc de una forma muy rápida y
sencilla. Es importante matizar que una Tabla Dinámica
no es lo mismo que PTS, sino que Excel utiliza PTS
para manipular Tablas Dinámicas. Otro detalle muy
importante es que es imprescindible tener instalado el
componente Microsoft Query de MS Office para poder
utilizar las tablas dinámicas.
Desde Microsoft Excel, iremos al menú “Datos”,
seleccionaremos “Obtener Datos Externos” y “Nueva
consulta de bases de datos”, apareciéndonos una ventana para elegir el origen de datos. Como podéis comprobar, esa ventana nos permite conectarnos a diversos orígenes de datos, en nuestro caso iremos a la pestaña “Cubos OLAP”.
Figura 3. Creación de un origen de datos para
acceder al cubo Ventas.
Allí elegiremos “Nuevo origen de datos” y pulsamos “Aceptar”, apareciéndonos una nueva ventana
donde introduciremos los datos para conectarnos a
nuestro cubo de ejemplo, dándole al origen de datos
el nombre Ventas dotNetMania, y utilizando el proveedor Microsoft OLE DB Provider for OLAP Services 8.0,
y seguidamente pulsamos el botón “Conectar”, apareciéndolos una pantalla con un asistente para la conexión, que rellenaremos según los datos que se muestran en la figura 4 (si el servidor de Analysis Services
no está en la máquina local, indicar el nombre del servidor o su dirección IP).
Pulsamos el botón “Siguiente”, y a continuación
seleccionamos la base de datos multidimensional, en
nuestro caso es dotNetMania, y pulsamos el botón
“Finalizar”.
Ahora ya podemos seleccionar el cubo que deseemos entre los disponibles en la base de datos seleccionada, que en nuestro caso será Ventas ya que es el
único que tenemos disponible. Finalmente pulsamos
el botón “Aceptar”, con lo que ya tendremos creado
<<dotNetManía
desde Microsoft Excel y Microsoft Data Analyzer, y
también accederemos desde la aplicación de ejemplo
MDX que viene con el producto para introduciros en
el lenguaje de consultas multidimensionales.
Por el momento, nos ha funcionado el acceso a la
información sin problemas, porque en la máquina donde estamos probando están instaladas las herramientas cliente de Analysis Services, pero vamos a conocer en primer lugar qué necesitamos para tener disponible la conectividad entre el cliente y el servidor
desde las diferentes herramientas y aplicaciones.
41
Figura 4. Selección del servidor de Analysis Services.
nuestro origen de datos. Es el momento de seleccionarlo y pulsar nuevamente el botón “Aceptar”. Este
proceso ya no necesitaremos volver a realizarlo cuando queramos acceder de nuevo a nuestro cubo de
ventas, simplemente tendremos que seguir los pasos
iniciales hasta llegar a esta ventana y aquí elegir el
origen Ventas dotNetMania.
<<dotNetManía
Figura 5. Elección del origen de datos
creado anteriormente.
42
Ya estamos de nuevo en nuestra hoja de cálculo
donde simplemente nos queda elegir la celda a partir de la cual se introducirá la tabla dinámica y pulsar el botón “Finalizar”.
Pues bien, ya tenemos nuestra primera tabla dinámica con acceso al cubo Ventas de nuestra base de datos
multidimensional dotNetMania. Pasaremos a explicar
brevemente la utilización de esta herramienta.
En la parte derecha aparece una ventana donde
tenemos todas las dimensiones y medidas de nuestro
cubo, y podemos pinchar en ellas y arrastrarlas a las
áreas indicadas en la figura 6. Las dimensiones
(Artículo, Cliente, Forma de Pago, Provincia y Tiempo)
están en la parte superior de la ventana, y llevan un
icono con unas líneas azules, así como el signo + que
nos permitirá ver la jerarquía con los diferentes niveles que tiene cada una de ellas, y en la parte inferior,
con iconos rellenos con ceros y unos, tenemos las medidas (Cantidad, Pr Compra y Precio). Las dimensiones
pueden ser arrastradas al área que aparece en la parte
Figura 6.Tabla dinámica en Excel lista para realizar consultas
Ad hoc sobre el cubo Ventas.
superior izquierda, en nuestro caso en la primera fila
de la hoja Excel, si queremos utilizarlas para filtrar
datos. También las podemos situar en las áreas de filas
y columnas, para ver sus miembros. Finalmente debemos arrastrar las medidas al área de datos. Así conseguimos filtrar por las condiciones que deseemos, y
cruzar los valores de las medidas seleccionadas en
función de las dimensiones elegidas en las áreas de
filas y columnas.
Vamos a ver un ejemplo de uso, explicando paso
a paso cómo obtener los datos mostrados:
• Arrastramos la dimensión Artículo al área de
filtro, desplegamos el cuadro combinado y
seleccionamos la familia Regalos [6].
• Arrastramos la dimensión Tiempo al área de
columnas.
• Arrastramos la dimensión Provincia sobre el
área de filas.
• Arrastramos la medida Cantidad sobre el área
de datos.
Con estos pasos tan simples ya tenemos de forma
dinámica en pantalla una tabla que nos representa las
cantidades de artículos de la familia Regalos vendidos
durante los años 2000 y 2001 en cada una de las provincias que han tenido ventas. Si ahora queremos ver
los resultados por trimestres, sólo tenemos que hacer
doble click sobre cada miembro de la dimensión tiempo, en nuestro caso sobre los años 2000 y 2001, apareciéndonos un detalle trimestral y manteniéndose la suma
anual. Si ahora deseamos ver los resultados totales, en
vez de los de una sola familia, debemos quitar el filtro
de la familia Regalos, y seleccionar en el cuadro combinado el valor “Todas Artículo”.
Como veis es muy sencillo el uso de estas tablas
dinámicas, utilizando las técnicas de arrastrar y soltar, desplegando los cuadros combinados, y seleccionando valores. Incluso se pueden seleccionar múl-
Figura 7. Resultado de la consulta que hemos realizado paso a paso.
Figura 8. Resultado del gráfico correspondiente a los datos de la figura 7.
celdas, y mejorar su presentación (en nuestro caso hemos
dado formato numérico con dos decimales a las columnas B, C y D) dependiendo de los conocimientos que tenga de la herramienta. Lo que sí es recomendable, es que
profundice en los conocimientos sobre tablas y gráficos
dinámicos en Excel.
Pasemos ahora a la utilización de otra herramienta
que nos permite consultar de una forma sencilla e
interactiva los datos, MS Data Analyzer. Esta herramienta nos facilita el análisis de los datos de negocio, con una interfaz muy amigable, permitiéndonos
resolver una gran cantidad de preguntas que nos
podamos hacer sobre el estado de nuestro negocio,
mediante múltiples vistas de nuestros datos.
Vamos ahora a ver un pequeño ejemplo de su utilización. Abrimos la herramienta, y elegimos “Create
a new view”, y se activa un asistente que nos permitirá configurar nuestra vista. En primer lugar debemos crear una nueva conexión, para ello pulsamos el
botón “Add”, y rellenamos los datos como se muestra en la siguiente figura.
Figura 9. Propiedades de la conexión a Analysis
Services desde Data Anlyzer.
Y pulsamos el botón “Connect”, teniendo acceso así a las bases de datos y cubos de nuestro servidor. En nuestro caso elegiremos los elementos mostrados en la figura 10, y pulsaremos el botón “OK”.
A continuación pulsamos el botón “Next >>” del
asistente, pasando así a la pantalla donde elegimos
las dimensiones con las que deseamos trabajar; en
este caso seleccionaremos Cliente, Provincia y Tiempo.
Y pulsamos el botón 'Next >>' dejando los valores
que aparecen por defecto. En la pantalla siguiente pulsamos el botón 'Finish'. Obteniendo como resultado
nuestra vista, sobre la que podremos ir haciendo las consultas ad-hoc que deseemos y cambiando las vistas de
cada uno de los paneles resultantes.
Por ejemplo, al pinchar en el elemento “MURCIA” del panel central, veréis que cambian los resultados de los otros dos paneles, ya que acabamos de
<<dotNetManía
tiples valores, para ello en el cuadro combinado debemos marcar, una vez desplegado, la opción “seleccionar varios elementos”. Adicionalmente, por
supuesto, seguimos manteniendo todas las posibilidades de Excel para hacer cálculos sobre estos datos
en otras celdas que estén fuera de la tabla dinámica,
para dar formato, o incluso crear gráficos dinámicos
de una forma tan fácil como pulsar la tecla F11. En
este caso lo más apropiado es utilizar un gráfico circular, en vez de un gráfico de barras; para hacer este
cambio, pulsamos botón derecho sobre el gráfico,
elegimos la opción “Tipo de gráfico” y allí seleccionamos “circular”, pudiendo elegir también entre diferentes formatos de gráficos circulares, en dos dimensiones, en tres dimensiones, etc…
Como podéis comprobar la utilización de las tablas
dinámicas para realizar consultas ad hoc sobre una hoja
Excel es muy sencilla, y adicionalmente, el usuario puede agregar información introduciendo fórmulas en las
43
Figura 10. Selección de la base de datos
y el cubo a analizar.
Figura 11. Selección de las dimensiones a
mostrar en las vistas.
<<dotNetManía
hacer un filtro, mostrando sólo los datos referentes
a Murcia. Si a continuación hacemos doble click sobre
el elemento “2001” del panel de la derecha, pasaremos a ver un detalle de cada uno de los trimestres del
44
Figura 12.Vistas seleccionadas, preparadas para recibir consultas Ad-Hoc.
año 2001 para la provincia de Murcia. También se
puede cambiar el formato de cada uno de los paneles, posicionando el ratón en el ojo que aparece en la
parte inferior izquierda, apareciendo tres opciones
de visualización de datos, que son, Bars (que es la que
estamos utilizando), Grid (para mostrar los datos
numéricos) y un gráfico de tarta (para mostrar los datos
en este formato).
En fin, no quiero profundizar en el uso de esta
herramienta, simplemente quiero que veáis su potencia y dinamismo a la hora de mostrar datos procedentes de un cubo. Y dejo al lector las tareas de ir
investigando y manipulando esta sencilla herramienta
que nos proporciona Microsoft dentro de la familia
de MS Office, que como el resto de herramientas de
la familia, va orientada al usuario final, le facilita enormemente el trabajo, y aumenta su productividad.
Figura 13. Resultado de las operaciones de ejemplo
indicadas paso a paso.
Pasemos ahora a ver la última herramienta de las
que estamos tratando en este artículo, que posiblemente
sea la que más interese al desarrollador que quiera iniciarse en el desarrollo de aplicaciones que accedan a los
Analysis Services. Es la aplicación de ejemplo MDX que
viene con el producto, que nos permitirá utilizar de una
forma sencilla el lenguaje de expresiones multidimensionales (MutiDimensional eXpresions). Esta aplicación
ha sido desarrollada en Visual Basic 6, y además se acompaña todo su código fuente, que puede servir de ayuda
para el desarrollador que quiera incorporar estas tecnologías en sus aplicaciones. El fuente lo podéis encontrar en la carpeta C:\Archivos de programa\Microsoft
Analysis Services\Samples\MDXSample o si habéis elegido otra ruta para la instalación en carpeta
Samples\MDXSample de vuestra instalación.
El lenguaje MDX es para las bases de datos multidimensionales lo que SQL para las bases de datos
relacionales. Además es similar en muchos aspectos
en su sintaxis, aunque siempre habrá que tener en
cuenta que cada uno está diseñado para una tecnología muy diferente. Al igual que una consulta SQL,
una consulta MDX tiene una cláusula SELECT, que
SELECT <especif-eje> [, <especif-eje>…]
FROM <especif-cubo>
WHERE <especif-filtro>
Vamos a poner un ejemplo muy sencillo ya que
aquí simplemente queremos transmitir al lector la existencia de este lenguaje, sin entrar en más detalles. Si
desea introducirse en el desarrollo de aplicaciones que
accedan a bases de datos multidimensionales, recomiendo que lea los comentarios sobre diversos libros
publicados número anterior de dotNetManía.
Comenzaremos abriendo la Aplicación de ejemplo
MDX.
Figura 14.Acceso a la Aplicación de ejemplo MDX
desde el menú Inicio.
Y escribiendo allí la instrucción que aparece en la
figura 15.
Figura 15. Resultado de la ejecución de una consulta MDX.
[
]
Si instaláis MS Data Analyzer sobre un sistema operativo Windows que no esté en inglés
debéis descargar e instalar el siguiente parche:
Microsoft Data Analyzer 3.5 International Update
(http://www.microsoft.com/downloads/details.aspx?Fa
milyID=eb2cfe79-8e39-4c18-b57aae918a13c4ac&DisplayLang=en)
Como puede comprobar se trata de una herramienta
que nos recuerda al Query Analyzer en cuanto a su
interfaz y funcionalidad, ya que nos permite escribir y
ejecutar consultas MDX. En la parte superior escribimos nuestra consulta y vemos los resultados en la parte inferior. Desde aquí, se pueden ejecutar cuantas instrucciones se deseen, y además se puede almacenar para
reutilizarlas posteriormente.
[
]
Es recomendable tener instalada la última versión de Microsoft Data Access Components,
actualmente es la versión MDAC 2.8. Podéis descargarla en:
http://www.microsoft.com/downloads/details.aspx
? Fa m i l y I D = 6 c 0 5 0 fe 3 - c 7 9 5 - 4 b 7 d - b 0 3 7 185d0506396c&DisplayLang=en
Con esta pequeña muestra finalizamos nuestra breve introducción a estas herramientas, unas para el usuario final y otras para el desarrollador.
Conclusión
Espero que os haya resultado útil esta serie de artículos, y que al menos os haya servido para familiarizaos
con el entorno de los Analysis Services. Como veis, esto
es sólo la punta del iceberg de una tecnología que cada
vez se está implantando más en nuestras empresas.
Con unas pocas horas de estudio y de práctica podréis
poner en marcha una pequeña base de datos multidimensional con información muy útil, que os permitirá
que los usuarios puedan consultar datos de forma dinámica, con muy poco tiempo de formación. Os aseguro,
que una vez desarrollados los cubos, con un par horas en
las que les expliquéis algunos conceptos básicos y les propongáis algunos ejercicios, pueden empezar a sacar partido a los datos desde MS Excel o MS Data Analayzer.
Esta formación quedará rápidamente amortizada por el
tiempo que ahorraréis en el diseño de listados estáticos,
y de las posteriores modificaciones que os solicitan los
usuarios, ya que les estamos facilitando una herramienta donde ellos mismos pueden variar cuantas veces deseen sus informes.
<<dotNetManía
pasaremos a ver a continuación. Sin embargo, es
importante que conozca el lector una serie de diferencias a nivel conceptual:
• Tiene comandos diseñados para recuperar
estructuras de datos multidimensionales.
• La cláusula SELECT define varias dimensiones del
eje.
• La cláusula WHERE filtra los datos por una dimensión o miembro específico, proporcionando un
subconjunto de datos.
Sintaxis básica:
45
dnm.legal
José Antonio Suárez
Uso no autorizado de redes WIFI:
Consecuencias en el ámbito penal
En los últimos apenas dos años hemos podido advertir la aparición de sistemas de
comunicaciones inalámbricas, que permiten el acceso a Internet en entornos más
o menos amplios, y que, en no pocas ocasiones, exceden el ámbito de establecimiento del titular de la red.
<< La creciente implantación de este sistema de acceso, que permite
dotar de una infraestructura de comunicaciones a entornos
tanto domésticos como empresariales (hoteles, aeropuertos, cafeterías y universidades) a un coste casi marginal, mueve a la reflexión. Máxime si tenemos en cuenta que buena
parte de ellos carece de un nivel de seguridad adecuado.
Esta falta de medidas de seguridad motiva que usuarios
de medios técnicos que detectan, en ocasiones sin acción
voluntaria, la existencia de una de tales redes, tengan la posibilidad de utilizarla para acceder a Internet (cuando no a la
máquina o a la red interna de su titular). Lo plantea el problema de la consideración jurídica que debe darse a la conducta de quien prevaliéndose tales posibles fallos de seguridad por acción u omisión, utiliza parte del ancho de banda única y exclusivamente para fines que no suponen una
intromisión en la esfera privada del responsable de la red,
y, singularmente, para acceder a Internet.
Quizás la primera consideración respecto de la trascendencia jurídica de quien instala una red inalámbrica que
puede rebasar el ámbito doméstico o empresarial en que se
encuentra instalada, es que tal conducta, cuanto menos, es
carente de la necesaria diligencia, por causarse un daño a
tercero, por ejemplo, puede suponer una situación de riesgo, pero en tanto no suceda el hecho lesivo, la conducta
debe ser considerada como jurídicamente neutral, y, por
otro lado, nunca las victimas son culpables del delito, algo
que no hay que perder de vista.
Calificación jurídica
José Antonio Suárez
es socio director de Suárez
de la Dehesa Abogados,
despacho especializado en
Propiedad Intelectual e Industrial
y Nuevas Tecnologías.
La calificación jurídica que deba darse a la conducta del
tercero que accede a Internet utilizado el ancho de banda
negligentemente ofrecido por el titular de la red reviste una
verdadera complejidad.
Para comenzar hay que distinguir entre dos conductas
diferentes. La del usuario de un aparato que lo conecta en
un lugar determinado, tras lo cual éste detecta un punto de
acceso no protegido, que emplea. Y de de quien pasea la
ciudad buscando activamente la existencia de puntos de acceso no protegido (conducta que se conoce como wardriving),
con objeto de utilizarlo para fines igualmente ilegítimos.
Es evidente que quien accede a una red de comunicaciones sin estar autorizado, y con independencia de si la red
está protegida o no, y emplea una parte del ancho de banda para su propio beneficio, está realizando una conducta
antijurídica. La complejidad es su tipificación.
Consecuencias penales
En el campo penal, es evidente que no nos encontramos
ante el supuesto típico del artículo 197.1 del Código Penal,
pues la intención tanto de usuario que encuentra el punto de
acceso desprotegido, como la de quien activamente lo busca, no persigue conocer los secretos o vulnerar la intimidad
de ningún tercero, lo que excluye la aplicación de este tipo.
Tampoco parece que nos encontremos en el marco del subtipo del delito de desordenes públicos del que trata el artículo 560.1, pues una red de comunicaciones privada, aunque
utilice el dominio público (lo que sucede cuando la señal rebasa los límites del edificio y es accesible desde la calle) no es
ni una línea o instalación de telecomunicaciones, ni tampoco puede calificarse de servicio público.
Descartados los anteriores tipos, hay que considerar la
posibilidad de la conducta en cuestión pueda entrañar la comisión del delito de daños por defraudación de fluido de telecomunicación al que se refiere el artículo 255. Es evidente
que el uso no autorizado de parte de la banda de un acceso a
Internet puede calificarse de fraudulento, pues hay una apropiación de un servicio ajeno, lo que genera un daño económico, en la fracción que el titular del ancho de banda contrató y paga pero no puede usar precisa y exclusivamente por
la acción fraudulenta. Por ello, es defraudatoria la conducta
de quien busca activamente el acceso desprotegido, pues está
utilizando las telecomunicaciones (la dicción del texto legal
no es precisamente afortunada) de las que es titular un tercero y, además, a dicho fin se vale de un mecanismo instala-
<< dnm.legal
ancho de banda, supone que un número indeterminado de clientes no podrá acceder a la
página Web del comerciante y, en consecuencia, éste perderá el negocio que tales clientes
habrían generado. Si a ello sumamos un hecho,
tan evidente como constatado, como es que
para el consumidor que compra por Internet
Es evidente que quien accede a una red de
comunicaciones sin estar autorizado, y emplea una
parte del ancho de banda para su propio beneficio,
está realizando una conducta antijurídica.
dos de los factores determinantes de su elección son, más allá del precio, la disponibilidad
veinticuatro horas al día y la rapidez de las transacciones, es evidente que en un mundo de
amplia oferta, la demanda de los clientes que
no pudieron acceder por estar una parte del
ancho de banda ocupado por el intruso, se derivará a otros comerciantes. Con lo que el
defraudado será perjudicado en el importe del
negocio potencial que acredite haber perdido.
Acreditación que no presenta dificultad excesiva para cualquier abogado con un mínimo
de experiencia en la materia.
El recurso a calificar la conducta como
falta, por la reducida entidad económica bien
de la defraudación, bien del daño, no es
menos problemático, dada la dicción del
número 4 del artículo 623, pues se refiere a
defraudación “en equipos terminales de telecomunicación”. Determinar qué debe entenderse por tal defraudación no es sencillo,
pues no se dice que el objeto del ilícito sea
ámbito penal. Persecución que, como queda dicho, presenta dificultades, especialmente
en el campo de la prueba del daño al perjudicado, pero también es cierto que cuanto
antes se inicie, antes se desincentivarán este
tipo de conductas. Una de cuyas consecuencias es el daño económico directo a aquella
parte del negocio del perjudicado que discurre por Internet, pero no el único.
Por no referirnos a aquellos casos en los
que el acceso fraudulento no se produce con
la intención de aprovechar un recurso disponible, que, por cierto, y como hemos visto, no debe entenderse como tal, sino para
alcanzar otros objetivos, desde la ilegal puesta a disposición de terceros de música o películas, hasta la difusión de otro tipo de conductas que inciden, per se, en el ámbito de lo
penal. Conductas defraudatorias de las que
aparecerá como responsable, al menos en
primera instancia, el propio perjudicado de
la intromisión.
<<dotNetManía
do expresamente para realizar la defraudación (el ordenador en modo de localización
de señales wifi y, en su caso, la antena que
mejora el resultado de la búsqueda). Ahora
bien, en este supuesto la posible exclusión de
la tipicidad puede venir impuesta por el hecho
de que será bastante dificultoso acreditar que
el importe defraudado, es decir el precio de
la parte del servicio cuyo uso sólo ha sido posible con el concurso del fraude, y no el perjuicio causado, excede de cuatrocientos euros,
dados los precios del servicio del que ilícitamente se está aprovechando.
Más oportunidades ofrece el artículo
256, pues sólo requiere el uso de un terminal de telecomunicaciones sin consentimiento de su titular, y causando a éste un
perjuicio superior a cuatrocientos euros. El
problema en este caso será, una vez más, probar que el perjuicio excede de 400 Euros,
puesto que los restantes requisitos del tipo
concurren, es decir la falta de consentimiento
y el uso de terminal de telecomunicaciones,
que tal es el servidor de comunicaciones del
titular, pues el único intermediario entre éste
y el exterior.
La evaluación del daño emergente, es
decir el causado al propietario del terminal
por el ancho de banda utilizado sin autorización, es el camino correcto, pero también
de escaso resultado. Al precio actual de los
abonos, llegar a acreditar un uso equivalente a 400 Euros puede ser no sólo complejo,
sino dificultoso.
La alternativa más adecuada es evaluar el
lucro cesante, especialmente en aquellas
empresas para las que Internet es su mercado,
único o relevante. Por ejemplo, las agencias de
viajes, las empresas de comercio electrónico y
aquellas otras en las que una parte de su negocio tiene lugar a distancia y mediante la red.
Es evidente que el hecho de que un intruso
irrumpa en su red y ocupe una parte de su
ni el uso ilegítimo del fluido, ni tampoco el
inconsentido del terminal, lo que puede dar
en la impunidad de la conducta, aun reconociendo su ilegalidad.
En algunos medios se ha señalado la posibilidad de incardinar estas intrusiones en el
marco del número 4 del artículo 286, pero
aquí el punto de colisión sería el hecho de que
la tecnología empelada no tiene como objeto la intrusión, sino que la misma es posible
por la concurrencia de una tecnología neutral (la que posibilita el acceso a las redes wifi),
una conducta determinada del intruso y otra
poco diligente del titular. Y sin la coincidencia de estas dos, la tecnología es neutral.
Es evidente que la adopción de medidas
de seguridad debe ser la norma de quienes
quieran instalar redes wifi empresariales, y
aún domésticas, pero ante la acción intencional o derivada del fallo propio de seguridad, una alternativa es la persecución en el
47
<< dnm.mvp.online
Jorge Serrano
Creación de bordes redondeados en
WebForms: RoundedCorners
<< En la sección MVP Online de este mes, he creído conveniente
ofrecer a los lectores una contribución que más que aportar funcionalidad a nuestros desarrollos de aplicaciones
Web con ASP.NET, nos ofrece la posibilidad de mostrar una interfaz más agradable a nuestros sitios Web,
un aspecto éste, que en muchas ocasiones y según cuáles, es casi más importante que la propia funcionalidad
de la aplicación.
En no pocas ocasiones, nos cansamos de ver que
determinados controles Web poseen un aspecto tosco. Los bordes de estos controles son ásperos y siempre terminan en un vértice puntiagudo en sus extremos, y por ello, en algunas ocasiones, nos encontramos con la necesidad de que un determinado control
posea una aspecto mucho menos rectilíneo y mucho
más redondeado. En este caso en concreto me estoy
refiriendo al control Web Panel de ASP.NET que sirve de contenedor de otros controles más.
Por lo general, en nuestros desarrollos utilizamos
controles en forma de cajas o tablas en las que insertamos otros controles, por eso, imagínese la posibilidad
de crear cajas con bordes redondeados dentro de las cuales insertar nuestros controles y dar así, un aspecto mucho
más atractivo a nuestras aplicaciones. Bueno, al menos
imagíneselo, porque hasta ahora, con ASP.NET no es
posible de forma directa... ¿o debo decir mejor dicho
que no era posible?. Veamos lo que nos sacaremos de la
chistera en esta sección este mes.
Iniciándonos en la creación de bordes
redondeados
Antes de nada, comentar que si deseamos crear
bordes redondeados para aplicarlos a nuestras páginas web, debemos diseñarlos primero con un programa de dibujo, combinando y guardando la gama
de colores adecuada e insertarlos después en nuestras
páginas Web.
Para facilitar esta tarea, utilizamos las hojas de
estilo o CSS (Cascading Style Sheets). De esta manera,
podremos añadir estilos a los controles Web de una
aplicación.
Se trata de un trabajo mucho más manual que
automático, y requiere de excesivo tiempo y dedicación. Además, cualquier pequeña modificación en el
aspecto que se le quiere dar, significa un trabajo de
mantenimiento bastante grande. Aún así, no todos
los navegadores Web lo soportan completamente, y
es por eso que entra en juego el ingenio de un desarrollador independiente como lo es Scott Mitchell,
MVP de ASP.NET y que en este caso, ha desarrollado un control de nombre RoundedCorners que no es
otra cosa que un control web tipo caja, que nos ofrece la posibilidad de crearlo con un aspecto mucho más
atractivo.
RoundedCorners, redondeando las
esquinas
El objetivo del control RoundedCorners, es el de
preparar y crear bordes redondeados a un control tipo
caja; todo ello, haciéndolo on fly, es decir, al vuelo. La
mecánica de funcionamiento es muy simple: cuando
ejecutamos nuestra página Web se generarán los bordes redondeados sino se han creado ya previamente
en otra ejecución y se mostrarán en el navegador de
forma rápida.
Esto lo consigue Scott utilizando las capacidades que
ofrece GDI+ y de esa manera, que RoundedCorners se
encargue de generar automáticamente las esquinas
redondeadas de un control si no están creadas ya.
Esta generación se realiza en el servidor, y el cliente, tan solo recibe las imágenes que debe acoplar en
las esquinas del control tipo caja como si estuviéramos usando CSS. La habilidad del desarrollador, reside en este caso, únicamente en saber el aspecto visual
que se le quiere dar a la página para que ASP.NET,
lo prepare y lo muestre correctamente.
Como vemos, este control es además el que se
encarga de generar los bordes que necesitamos, con
el color de borde y de fondo que le hemos pedido,
por lo que nos podemos olvidar de la tediosa tarea de
crear nosotros mismos esos bordes y tratar de cuadrarlos en nuestras páginas web y de ejecutar nuestra aplicación y observar si el aspecto dado es el que
buscábamos. Parece útil ¿verdad?
RoundedCorners, algunas características
que debemos conocer previamente
Antes de abordar nuestro ejemplo práctico con
este control, creo conveniente hacer un repaso gené-
<< dnm.mvp.online
Figura 1. Selección del control PrettyUI.dll para insertarlo
en la barra de herramientas
El aspecto o propiedades del control insertado dentro de nuestra página Web, tiene su fiel y automático
reflejo dentro de ésta en tiempo de diseño. Cuando
modificamos una propiedad en tiempo de diseño en
Visual Studio .NET, se muestra directamente el aspecto que tomará en tiempo de ejecución.
Otro aspecto importante a tener en cuenta a la
hora de trabajar con este control, es la generación de
imágenes o bordes redondeados en tiempo de ejecución. Esta generación se hace sobre un directorio virtual o un directorio determinado sobre el cuál le hemos
dado los permisos necesarios para generar imágenes.
Los permisos que debemos habilitar son los de escritura sobre el directorio. Además, debemos asegurarnos que el usuario ASP.NET tiene permisos sobre este
directorio, en caso contrario, no seremos capaces de
crear las imágenes en tiempo de ejecución y ASP.NET
nos indicará con un error, que no puede mostrar la
página Web.
Sobre las propiedades de este control, reflejaremos algunas de las más importantes para que tengamos alguna idea o noción previa sobre el control,
antes de ponernos a trabajar de lleno con él. Entre
estas propiedades encontramos la propiedad
BackColor que como su propio nombre indica, contiene el valor del color de fondo del control. Además
de esta propiedad, el control puede tener un color
de borde, un tamaño y un estilo; esto lo conseguimos con las propiedades BorderColor, BorderWidth y
BorderStyle respectivamente. El tamaño del contorno redondeado puede ser especificado con las propiedades CornerHeight y CornerWidth que especifica
el ancho y alto de los bordes redondeados. Su tamaño por defecto es de 13 píxeles.
Por otro lado, el control también nos permite
crear un título sobre el cual podemos modificar un
amplio conjunto de propiedades. Una propiedad
fundamental para este control es la propiedad
ImageDirectory, la cuál nos indica el directorio sobre
el cual el control generará las imágenes bajo demanda. Otra propiedad muy interesante es la propiedad Padding que nos indica el relleno alrededor del
texto del control. No menos interesante es también
la propiedad RoundedBottom que determina si en la
parte inferior del control, queremos mostrar o no
bordes redondeados. Por defecto, su valor es True
que indica que la parte inferior del control debe
generar bordes redondeados. Existen otras muchas
propiedades, pero éstas son quizás las más genéricas y relevantes en una fase inicial. Al final del artículo comento otra de sus propiedades; lo hago aparte por tratarse de una propiedad especial de aspecto avanzado.
RoundedCorners, una imagen vale más
que mil palabras
Ha llegado la hora de dejar de lado la teoría y ponerla en práctica con un ejemplo que nos muestre cómo funciona este control en nuestros desarrollos.
En nuestro ejemplo práctico, iniciaremos un nuevo
proyecto de aplicación Web en ASP.NET 1.1.
Añadiremos el control RoundedCorners a nuestra barra
de herramientas e insertaremos un control dentro de la
página Web, tal y como se muestra en la figura 2.
Figura 2. Control RoundedCorners insertado en la página Web
<<dotNetManía
rico por las características generales que este completo control nos ofrece.
En primer lugar, el código fuente del control está
disponible gracias a que su autor, Scott Mitchell ha
decidido compartirlo con todo el mundo. El ensamblado compilado PrettyUI.dll está compilado con
Microsoft Visual Studio .NET 2003. Si desea utilizarlo con ASP.NET 1.0, deberá compilarlo con
Microsoft Visual Studio .NET 2002 para usar su
ensamblado.
El control se añade a la barra de herramientas
como haríamos con cualquier otro control que no
estuviera allí. Para insertar el control a nuestras páginas Web, bastará con pinchar sobre el control en la
barra de herramientas y hacer doble clic sobre el control o arrastrar y soltarlo sobre la página Web.
49
<< dnm.mvp.online
En este punto, le recomiendo jugar con las propiedades del control, recordando que la propiedad
ImageDirectory debe tener un directorio que tenga
permisos de lectura y escritura para un usuario
ASP.NET válido.
Inserte un control RoundedCorners y modifique
alguna de sus propiedades. Un ejemplo en ejecución
de este control es el que se muestra en la figura 3.
Los formularios Web trabajan desconectados del servidor, y cada vez que
vamente, se rearma el contenido, se
envía al cliente, y se dispone de todos
Dentro del formulario Web hemos insertado dos
controles RoundedCorners y dentro de uno de ellos (el
primero de los dos), hemos insertado el control
DataGrid. Para que nos hagamos una idea más clara, la
figura 4 aclarará estos términos. A los controles
RoundedCorners, le he modificado algunas de sus propiedades. Le recomiendo que haga lo mismo para que
vea el alcance de este control.
Figura 3. Control RoundedCorners en ejecución
Ahora bien, este control nos permite muchas
más posibilidades, como la de ser contenedor de
otros controles.
RoundedCorners como contenedor de
otros controles
<<dotNetManía
En este caso en concreto, RoundedCorners nos
proporciona todas las posibilidades para ser un contenedor de otros controles como lo ofrecen también otros de ASP.NET.
El siguiente ejemplo, nos muestra a RoundedCorners
en acción, siendo contenedor de un control DataGrid.
El código de nuestro pequeño ejemplo con acceso a base de datos incluida es el que se detalla en el
fuente 1.
50
Figura 4. Controles RoundedCorners insertados
en el formulario Web
En ejecución nuestro pequeño ejemplo de demostración, es el que puede verse en la figura 5.
Private Sub Page_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
Dim strConexion As String
Dim objConexion As OleDb.OleDbConnection
Dim objComando As OleDb.OleDbDataAdapter
Dim objDS As New DataSet
strConexion="PROVIDER=MICROSOFT.JET.OLEDB.4.0;DATA SOURCE=c:\Ejemplo.mdb"
objConexion = New OleDb.OleDbConnection(strConexion)
objComando = New OleDb.OleDbDataAdapter(_
"SELECT Nombre, Apellidos FROM Tabla", strConexion)
objComando.Fill(objDS, "Ejemplo")
DataGrid1.DataSource = objDS.Tables("Ejemplo")
DataGrid1.DataBind()
objConexion.Close()
End Sub
Fuente 1
Figura 5. Aplicación en ejecución con los controles
RoundedCorners vistos en la figura 4
<< dnm.mvp.online
Mejorando los bordes en el control
RoundedCorners
A continuación. y por eso lo he hecho en un punto aparte, me gustaría hablar del efecto anti-aliasing
o de evitar la separación de líneas y curvas al pintar.
Este efecto, es el que permite suavizar las curvas y
bordes en su parte más áspera, dando así un aspecto
mucho más visible y estético.
Esto se consigue en este control, haciendo uso
de la propiedad BackgroundBackColor. Esta propiedad contendrá el valor de fondo que permitirá suavizar las curvas al usar este control. Por lo general,
el color de este control debe ser el mismo que el del
fondo sobre el que está situado. En una página Web
cualquiera, el color debe ser el mismo que el color
de fondo de ésta. Es importante indicar su color aunque éste sea el color por defecto de la página Web.
Un ejemplo gráfico de la diferencia de uso de esta
técnica y el uso por defecto del control que no utiliza
esta técnica, es la que se muestra en la figura 6.
La posibilidad de obtener el código fuente del
control, y que así podamos, si el autor nos lo permite, retocar el control para añadirle o modificarle diferentes propiedades, es otra de las ventajas
que nos proporciona RoundedCorners.
El código fuente e información adicional sobre el control, lo encontrará en los siguientes enlaces Web, que le
recomiendo visitar:
Direcciones de interés
Introducing the RoundedCorner Web Control
http://aspnet.4guysfromrolla.com/articles/072804-1.aspx
RoundedCorners Web Control Demo
http://datawebcontrols.com/demos/RoundedCorners.aspx
Improving the RoundedCorners Web Control
http://aspnet.4guysfromrolla.com/articles/081104-1.aspx
Sobre Scott Mitchell
Los formularios Web trabajan desconectados del servidor, y cadadel servidor, y cadadel servidor, y cada vez que
vamente, se rearma el contdel servidor,
y cadadel servidor, y cadaenido, se envía
al cliente, y se dispone de todos
Conclusión
En este artículo, hemos podido ver el funcionamiento de un control como RoundedCorners, que nos
ofrece la posibilidad de crear cajas contenedoras con
bordes redondeados.
Si quieres saber más sobre el programa MVP puedes consultar la página oficial de Microsoft en:
http://mvp.support.microsoft.com
<<dotNetManía
Figura 6. Diferencias de uso de suavizado de bordes
con el control RoundedCorners
El currículum de Scott es
bastante amplio, pero a groso modo, diremos de él que
reside en San Diego,
California. Es MVP en
ASP.NET desde el año 2002,
editor y primer responsable
del conocido sitio web
www.4GuysFromRolla.com
y
Scott Mitchell
durante los últimos cinco
años ha estado trabajando con
tecnologías Web de Microsoft. Profesionalmente
es un consultor independiente, es también autor
de seis libros sobre ASP.NET y XML, escritor
habitual de publicaciones técnicas como ASP.NET
Pro Magazine y MSDN Magazine, y en sitios Web
como MSDN, Web Monkey y 15Seconds.com.
También ha sido ponente en varias conferencias
e imparte formación sobre ASP.NET y servicios
Web principalmente.
Para más información sobre Scott consultar:
http://www.4guysfromrolla.com/ScottMitchell.shtml O
en su blog: http://ScottOnWriting.NET.
Podrás contactar con él en la dirección de e-mail
[email protected].
51
dnm.todotnet.qa
Dino Esposito
Diálogo concerniente a los principales sistemas mundiales y sus diseños arquitectónicos
Hoy,la mayor parte de los responsables de IT tienen que elegir entre dos sistemas principales:J2EE y .NET.No importa lo difícil que sea la elección,es importante tener claras
las implicaciones de la decisión tomada. Desgraciadamente, ninguna aplicación es una
isla, como dijo Don Box en el PDC de 2003. Eso significa que todas las aplicaciones
pueden llegar a necesitar comunicarse con otros sistemas existentes a través de protocolos estándar. Los servicios Web son una opción que, aunque totalmente independiente de Microsoft y la plataforma .NET, comenzaron a tener la atención debida solamente cuando Microsoft consiguió popularizar un mecanismo fácil para su creación.
<< La arquitectura orientada a servicios (SOA) plantea aparente-
Dino Esposito
es redactor de dotNetManía.
Formador, consultor y escritor
afincado en Roma. Miembro del
equipo de Wintellect, Dino está
especializado en ASP.NET y
ADO.NET.
Puede enviarle sus consultas a
[email protected]
mente un concepto similar que, en ocasiones, es incorrectamente interpretado como una consecuencia de los
servicios Web en .NET. ¿Cuál fue primero: el huevo de
SOA o la gallina de los servicios Web?
El título de esta columna, deliberadamente hace
referencia al libro escrito por Galileo Galilei, astrónomo y físico del siglo XVII. Galileo tuvo serios problemas con la Iglesia católica debido a su apoyo de
la Teoría Heliocéntrica, según la cual es la Tierra la
que gira alrededor del Sol y no viceversa. ¿Quién
daba vueltas alrededor de qué? La pregunta me vino
a la mente cuando abrí el correo para la columna de
este mes.
Comprender la correcta relación entre los servicios
Web, tales como los conocemos de las arquitecturas J2EE
y .NET, y la arquitectura SOA es un factor clave en el
diseño de arquitecturas distribuidas que funcionen tanto hoy como mañana, cuando Índigo haga su debut el
próximo año. (A propósito, la primera beta pública de
Índigo se espera para este Otoño).
Oigo a muchos ponentes hacer uso del término SOA en sus charlas para promocionar el uso
de servicios Web en aplicaciones distribuidas.
¿Deberíamos abandonar las prácticas orientadas
a objetos para escribir servicios Web y utilizar
XML en todas partes? ¿Y qué pasa con las aplicaciones locales? ¿Habría que utilizar servicios Web
en todas partes?
¿
Deberíamos abandonar
las prácticas orientadas a
objetos para escribir
servicios Web y utilizar
XML en todas partes
?
Sólo el texto de la pregunta me recuerda a Galileo.
Existe un extenso malentendido en el texto que la literatura acerca de los servicios Web, inconscientemente
ha alimentado. La arquitectura SOA pretende obtener
enlaces débilmente vinculados entre los componentes
que interactúan en la solución. Un sistema basado en
SOA construye su funcionalidad en forma de servicios.
¿Qué es un servicio? Puede describirse como una unidad funcional suministrada por un proveedor. Ambos,
proveedores y consumidores, exponen un bien conocido conjunto de interfaces y se comunican a través de
mensajes descriptivos regidos por un esquema. El esquema dicta qué palabras y sintaxis son aceptables y no hay
comportamiento implícito del sistema en los mensajes. Tenemos ejemplos de servicios por donde quiera
que vayamos. Por ejemplo, podemos seleccionar la forma de recibir las noticias de una serie de canales distintos de televisión, cada uno de ellos ofreciendo dis-
“
La OOP es excelente
dentro del código de la
aplicación, SOA lo es en
sus puntos límite
”
¿Deberíamos utilizar servicios Web en todas partes?
Sí, si es posible. Las modernas aplicaciones distribuidas
están orientadas a servicios en sus puntos límite y pueden utilizar servicios Web para conectar sus componentes. ¿Cuál es el rol de la OOP en este escenario?
SOA y OOP son polos opuestos. En cierto modo,
SOA es la reacción a algunas malas prácticas de diseño que han afectado a las aplicaciones distribuidas
durante años. OOP trata de la encapsulación de la
lógica y la interfaz en un único componente. SOA es
más bien lo opuesto. SOA pretende conseguir la separación (o al menos la vinculación débil o ligera) entre
la lógica y la interfaz. La OOP es excelente dentro del
código de la aplicación, SOA lo es en sus puntos límite. Cada uno de ellos es útil y de gran ayuda, pero en
el momento adecuado y en el sitio adecuado.
No debiéramos pensar en los servicios Web como
instancias de componentes remotos, una especie de
COM+ basado en HTTP, pero simplificado. El diseño debería evitar la instanciación directa o la toma de
control sobre los componentes remotos. Una vez que
optamos por un diseño SOA podemos utilizar técnicas OOP para la implementación del servicio. La OOP
es excelente si nos limitamos a la implementación de
un servicio o componente en particular, pero no lo es
cuando se trata de hacer que los componentes se comuniquen entre sí.
¿Un ejemplo rápido? Imagine a sus hijos pidiendo un DVD de “Los Increíbles”. Usted les compra el
DVD y listo, ¿no? Ni se le pasa por la cabeza comprar un nuevo dispositivo que sólo sirva para reproducir esa única película, aunque pudiera, potencialmente, ser configurado o modificado electrónicamente para reproducir otros discos.
De vuelta a la analogía de Galileo, en el mundo
real las cosas funcionan de acuerdo con los principios
establecidos por SOA y forzarlos a comportarse al estilo OOP puede ser tan incongruente como la visión
heliocéntrica del mundo vs. la antropocéntrica del
siglo XVII.
¿.NET Remoting es una buena opción para la
implementación de sistemas distribuidos hoy en
día? ¿No es más recomendable utilizar servicios
Web? ¿Y qué pasa con Índigo? He oído que no
existirá más soporte para .NET Remoting en el
futuro, tanto de .NET como de Windows.
En general, .NET Remoting es solamente una de
las opciones disponibles a la hora de construir un sistema distribuido. Existen diferentes aproximaciones
posibles, cada una con sus pros y sus contras. Son:
Remoting, Web Services, Enterprise Services (o sea,
COM+), Message queuing, sockets TCP de bajo nivel y
named pipes, y productos de terceros, tales como
ZeroC's Ice (Internet Communications Engine) o
Remoting.CORBA.
El factor clave acerca de .NET Remoting es que
sirve, exclusivamente, para interacciones entre componentes .NET. Remoting permite extender los límites impuestos por los dominios de aplicación (AppDomains), ya sea entre el mismo proceso, procesos distintos o máquinas diferentes.
¿
.NET Remoting es una
buena opción para la
implementación de sistemas distribuidos hoy en día
?
No puede usarse .NET Remoting para la comunicación con una aplicación Visual Basic 6.0 o un objeto COM, tanto si está en la misma máquina como si
se encuentra en otra. Si nuestra aplicación se presta
bien para el uso de .NET Remoting, quizá deberíamos de contrastar la solución planteada con todo el
montón de requerimientos y prerrequisitos necesarios en su implementación para hacernos una idea de
su rendimiento y escalabilidad finales. Por ejemplo,
deberíamos usar un canal HTTP con un Binary
Formatter, para obtener un buen balance entre com-
<<dotNetManía
tintos niveles de calidad, diferentes formatos, diferentes presentaciones, pero el mismo servicio esencial:
mantenernos informados.
El diseño de un sistema basado en estos principios
tiene inherentes ventajas. Por un lado, consumir un
servicio es, normalmente, más barato que construirlo. Además, los servicios pueden reemplazarse a voluntad. La complejidad de cara a los usuarios es mínima,
ya que no necesitan saber nada de emisiones de TV,
antenas, o de la estructura interna de un receptor de
televisión.
¿Cuál es la relación entre un servicio y un servicio
Web? Un servicio Web es un servicio SOA con una
serie de restricciones. Por ejemplo, un servicio Web
se estructura mediante interfaces que usan protocolos de Internet (HTTP, FTP, SMTP) y requiere que
los mensajes intercambiados se basen en SOAP. En
resumen, un servicio Web es un caso especial de servicio SOA. Un aplicación compatible con SOA puede utilizar servicios Web.
[email protected]@dotnetmania.com
<< dnm.todotnet.qa
53
54
[email protected]@dotnetmania.com
<<dotNetManía
<< dnm.todotnet.qa
pactación de datos y estabilidad. Es más, al analizar
un sistema distribuido desde el punto de vista de .NET
Remoting, nos imaginamos objetos planos, solo que
habitando en otro dominio de aplicación.
Como puede verse, este modelo no es particularmente “moderno”, desde el momento en que
establece vínculos consistentes (tightly coupled) entre
los consumidores y los servicios. Una aproximación
inteligente a las aplicaciones con .NET Remoting
consiste en un diseño de acceso remoto a las clases
como métodos de servicios Web sin mantenimiento de estado. Es mejor no asumir ningún estado, y
usar los métodos como desencadenantes de procesos y solicitudes de servicio a componentes de servidor. Los servicios Web son perfectos cuando se
necesita conectar aplicaciones ejecutándose bajo
distintas plataformas, o cuando llegamos a la conclusión de que los mensajes basados en XML es simplemente lo que se necesita.
De todas formas, como dije anteriormente, los
servicios Web son… eso, servicios, principalmente especializados en operar mediante un conjunto
de protocolos de Internet. Un diseño basado en
SOA parece la clave estos días para obtener aplicaciones distribuidas escalables y conectadas mediante vínculos ligeros. Los servicios pueden ser cualquier cosa, incluidas las conexiones tipo .NET
Remoting, servicios Web o componentes de colas
de mensajes.
¿Qué es lo que nos depara el futuro inmediato?
Índigo es una nueva generación estructuras de comunicación construida alrededor de la arquitectura de
servicios Web. Está basada en un modelo de programación orientado a objetos y construida mediante
.NET Framework para unificar un amplio abanico de
tecnologías de sistemas distribuidos dentro de una
arquitectura basada en componentes y extensible. La
estructura interna de Índigo, abarca transporte, seguridad, mensajería, codificación, topologías de red, y
modelos de alojamiento. En suma, Índigo es una nueva forma de construir la siguiente generación de aplicaciones distribuidas.
¿Y qué pasa con las aplicaciones actuales?
Continuarán ejecutándose –así que no se preocupe– y la migración, en la mayor parte de los casos,
no supondrá un gran esfuerzo. Índigo no malgastará su código actual, independientemente de la tecnología empleada –ya sean servicios Web ASP.NET,
.NET Remoting o Enterprise Services–. ¿Qué
podemos hacer hoy al diseñar los sistemas para prepararlos adecuadamente para Índigo? Construir utilizando servicios Web ASP.NET y utilizar la librería de extensiones de servicios Web (WSE 2.0) para
la seguridad, autenticación, y otras características
extendidas. Si necesita llamadas a transacciones dentro de un servicio, puede utilizar Enterprise
Services. Para la programación remota no transac-
cional, .NET Remoting es una opción válida.
Finalmente, la mensajería asíncrona debería implementarse usando la interfaz .NET para MSMQ, o
sea, las clases pertenecientes al espacio de nombres
System.Messaging. Para el resto de protocolos, Índigo suministra claras vías de migración. También
podrían utilizarse otros medios y mecanismos de
transporte, pero la migración no resultaría tan
inmediata.
En mi servicio Web, necesito determinar si
el cliente que intenta ejecutar un método Web
tiene permiso para hacerlo. Para simplificarlo,
elegí la clásica solución basada en cabeceras
SOAP y se me ocurrió otra idea: rediseñé el servicio Web para usar la dirección IP del cliente
para la autenticación. ¿Cuáles son los problemas potenciales al hacerlo de esta forma?
Funciona muy bien, pero temo haberme olvidado de algunos peligros eventuales.
Así que tienes una base de datos donde guardas
las IP de los clientes que tienen permiso para ejecutar servicios Web. Entiendo que, cuando un cliente ejecuta un método, el servicio comprueba en la
base de datos la existencia de la IP, y habilita la ejecución. La mecánica es prácticamente la misma que
la basada en la autenticación mediante nombre y
contraseña, pero me temo que deja un espacio extra
a atacantes potenciales. Desde luego, no estás
enviando el nombre y contraseña por la red, pero
la información que utilizas en la autenticación es
texto plano (la dirección IP) y disponible para cualquier sniffer. ¿Tienes la seguridad de que no hay
ningún hacker que pueda tener acceso a la red y
envíe IP's modificadas?
¿
En mi servicio Web, necesito determinar si el cliente
que intenta ejecutar un
método Web tiene permiso para hacerlo...
?
Con seguridad, el funcionamiento será bueno, pero
cualquier usuario (de una IP válida) podría legítimamente llamar a tu servicio. Probablemente, esto no
sea una amenaza seria en tu contexto de trabajo, pero,
hablando en general, suena como una puerta abierta.
Si no te gustan las cabeceras SOAP, puedes utilizar
autenticación Windows, y dar a cada usuario autorizado una entrada en la ACL (Access Control List) de la
máquina que ejecuta el servicio.
dnm.laboratorio.net
Pedro Pozo
Todos los programadores ASP .NET conocen la existencia del fichero web.config, pero lo que ya no resulta tan sencillo es conocer todos sus elementos y saberlo utilizar para configurar óptimamente una aplicación Web.
Pedro Pozo
es redactor de dotNetManía. Es
es consultor e-Bussines.
Ingeniero Técnico Informático
de Sistemas y Webmaster
del portal para desarrolladores
.NET Framework Clikear.com
ar o modificar ficheros web.config. A través de un
sencillo interfaz visual podemos ir a cada uno de
los nodos del fichero XML que conforma un fichero web.config y administrar los parámetros a nuestro gusto. Sin necesidad de ser un experto podemos modificar, de una forma visual, todos los parámetros que nos permiten configurar una aplicación ASP .NET.
Además tenemos dentro del mismo interfaz
otras dos ventanas, como podemos ver en la figura 1. En la primera ventana podemos ver el código fuente de nuestro fichero web.config, resaltado por colores cada parte de ese fichero para hacer
más fácil su visualización. En la segunda ventana
podemos ver un fichero de ayuda que nos sirve para
entender y a la vez aprender más sobre el parámetro que estemos configurando en cada momento.
Esa posibilidad de consultar en cada momento
la ayuda sobre el parámetro que estamos modificando es muy interesante, ya que no solo nos sirve para configurar nuestra aplicación sino que también nos permitirá conocer al detalle todos los parámetros de configuración que tenemos disponibles.
Esto nos permite aprender mas sobre la configuración de aplicaciones ASP .NET mientras trabajamos con Web.Config Editor.
El tratamiento que se da a cada parámetro del
fichero web.config es personalizado, mostrándonos un interfaz visual muy amigable que nos permite modificar cualquier parámetro de forma sencilla. Por ejemplo, nos permite la posibilidad de
encriptar las password en la sección de autenticación o si tratamos de configurar el parámetro
sessionState nos mostrará una pantalla en la que
podemos introducir la cadena de conexión a la base
de datos y poder testear si esa conexión a base de
datos esta funcionando correctamente.
Todas las modificaciones que realicemos serán
siempre controladas por Web.Config Editor ya que
realiza una validación automática para comprobar
que nuestro fichero de configuración tiene un formato correcto y tiene un esquema XML válido.
Además disponemos dentro de la aplicación de
una utilidad de backup que nos permite mantener
un versionado de nuestro fichero web.config y así
poder volver a recuperar en cualquier momento
versiones anteriores.
Requisitos del sistema
Los requisitos hardware y software para instalar Web.Config Editor son pocos, nos bastará con
cualquier ordenador en el que tengamos instalado
Windows 2000 ó Windows XP.
En la siguiente tabla podemos ver una configuración recomendada:
Requisitos del Sistema
Hardware
Software
Pentium III 733 Mhz
Microsoft Internet
Explorer 5.01 o superior
256 MB memoria Ram
Microsoft Windows 2000,
XP ó 2003
4 MB espacio libre en
disco
<<dotNetManía
<< Web.Config Editor se trata de una herramienta para cre-
55
<< dnm.laboratorio.net
Web.Config Editor soporta dos modalidades de
trabajo: una en modo sencillo para editar un fichero
de configuración en concreto y otra en modo complejo para editar todos los ficheros de configuración
que intervienen en una aplicación ASP.NET.
Trabajando en modo complejo tendremos un control total sobre todos los parámetros de configuración de una aplicación ASP.NET. De esta forma,
podemos configurar desde los parámetros de configuración globales para todas las aplicaciones
ASP.NET residentes en un servidor, que están el
fichero machine.config, hasta los parámetros de configuración concretos de nuestra aplicación que residen en el fichero web.config.
Cabe destacar en esta nueva versión 2.0 que han sido
añadidas 7 nuevas secciones del fichero web.config que
anteriormente no aparecían y una utilidad para poder
realizar búsquedas en el código XML de los ficheros de
configuración.
La facilidad de manejo, sencillez
de instalación y rápido aprendizaje
son las cualidades mas destacadas
de Web.Config Editor, pudiendo
considerarla una aplicación
de desarrollo y de
autoaprendizaje a la vez
Figura 1.Web.Config Editor 2.0
Conclusiones
Web.Config Editor es una sencilla herramienta para controlar hasta el
último detalle de la configuración de
nuestras aplicaciones ASP .NET. Pero
además, indirectamente nos ayudara a
ir aprendiendo cada vez mas sobre las
posibilidades que nos ofrece el fichero web.config, siendo por tanto una
herramienta que aumenta nuestros conocimientos de
ASP .NET.
Quizá los mas puristas prefieran modificar a mano
el fichero web.config, pero para el resto esta aplicación nos facilitará mucho la vida y nos ahorrará tiempo, tanto en desarrollo como en investigación para
conocer los parámetros de configuración de una aplicación ASP .NET.
Ficha técnica
<<dotNetManía
Ventajas e Inconvenientes
56
Web.Config Editor nos ofrece un entorno muy
sencillo para poder configurar nuestra aplicación
ASP .NET. Cabe destacar también la ayuda dinámica que nos proporciona dependiendo de cada
parámetro que estemos modificando, proporcionándonos un mayor conocimiento acerca del fichero web.config.
La facilidad de manejo, sencillez de instalación
y rápido aprendizaje son las cualidades mas destacadas de Web.Config Editor, pudiendo considerarla una aplicación de desarrollo y de autoaprendizaje a la vez.
Entre las desventajas de Web.Config Editor
esta quizá la falta de integración en entornos de
desarrollo mas complejos, como por ejemplo Visual
Studio .NET.
Nombre
Web.Config Editor
Versión
2.0
Fabricante
HunterStone
Web
http://www.hunterstone.com/webconfig.asp
Categoría
Herramientas de desarrollo
Licencias
Precio
Hasta 5
99$ por usuario
Hasta 10
89$ por usuario
Más de 10
79$ por usuario
Valoración
<< dnm.biblioteca.net
dnm.biblioteca.net
Introducing Microsoft .NET
David Platt
Editorial: Microsoft Press
ISBN: 0735619182
Páginas: 329
Publicado: Mayo, 2003
Como Platt utiliza Visual Basic .NET en sus ejemplos, podría servir de excelente introducción a los programadores de VB6 en fase de migración o incluso también a programadores de Java que tengan que abordar nuevos desarrollos con este lenguaje.
Inside Microsoft Visual Studio .NET
Brian Johnson, Craig Skibo, Marc Young
Editorial: Microsoft Press
ISBN: 0735618747
Páginas: 519
Publicado: Febrero, 2003
Una obra no muy común, en cuanto que va más dirigida a la herramienta que a la
plataforma. No obstante, conviene que el lector interesado la vea como “El libro
de la extensibilidad de Visual Studio .NET”, en lugar de atenerse a su título estricto. Es de lo que trata: de la construcción de complementos (Add-ins), y módulos de
extensibilidad para Office desde Visual Studio .NET 1.1, pero con más detalle y
profundidad de lo que hayamos visto en ninguna obra anterior.
En la primera parte, se analizan la gestión de proyectos, el editor de código y el
editor de macros. En la segunda –la más extensa–, todo sobre la construcción de
complementos, la programación de asistentes y el modelo de código, y, en la parte final, se agradecen detalles exhaustivos sobre la construcción de proyectos de
instalación, el uso avanzado de la ayuda y la gestión de proyectos avanzados.
Recomendable bajo los supuestos anteriores.
<< dotNetManía
<<
Esta introducción es una revisión aumentada y corregida para .NET 1.1, de su anterior “Así es Microsoft .NET”, salteada de los brotes humorísticos muy especiales de
David Platt, autor conocido también por otras obras como “The Essence of COM
and ActiveX: A Programmers Workbook”, o “Understanding COM+”. Se trata de una
introducción, simplemente. Nada es tocado en profundidad, pero nada importante deja
de comentarse de forma suficiente, desde las aplicaciones Windows y Web hasta la gestión de ficheros XML, la programación de subprocesos, y .NET Remoting.
57
<< dnm.desvan
noticias.noticias.noticias.noticias
Marino Posadas
Primeras noticias sobre Windows XP Reduced Media
Edition (RME), IE7,Windows Anti-Spyware y la herramienta de eliminación de virus
Aunque Microsoft se está planteando cambiar el nombre de
esta versión del sistema, cuya única diferencia respecto a XP
Professional es la ausencia de Windows Media Player, que
podrá ser instalado mediante descarga, configurando un
Windows XP Service Pack 2, prácticamente idéntico al original. Con esto se da cumplimiento a la normativa exigida
por la UE respecto a la inclusión del reproductor dentro del
sistema operativo.
ad/8/1/5/815d2d60-49b5-44dc-ae35fca2f2c6f0cc/MicrosoftAntiSpywareInstall.exe) se ha puesto a
disposición de los usuarios, casi al tiempo del anuncio por
parte de Redmond de la adquisición de la compañía de software de seguridad Sybari, en un claro refuerzo a la política
de aumento de seguridad que comenzó con la adhesión a la
iniciativa Trustworthy Computing. Además, la denominada
herramienta de eliminación de software malintencionado de
Windows, también está disponible para descarga en la dirección: http://www.microsoft.com/spain/technet/seguridad/herramientas/msrtool.mspx
Se confirma la aparición de la primera beta de Longhorn
para junio de este año
La noticia coincide con otros anuncios relativos a navegadores: por un lado, el anuncio del nuevo Internet Explorer
7, tal y como se recoge en el Microsoft Internet Explorer
Weblog: http://blogs.msdn.com/ie/archive/2005/02/15/
373104.aspx, donde el responsable directo del producto
comenta que el nuevo Explorer tiene como soporte base
Windows XP SP 2, –ya que está construido sobre los fundamentos de esa tecnología– y que se han tenido en cuenta
muchas sugerencias de los usuarios finales. Por otra parte,
se anunciaba también la versión beta de Netscape Browser
8.0, al tiempo que los creadores de FireFox, anuncian nuevas “Add-ons” para el producto.
Por otra parte, la versión Microsoft Windows AntiSpyware
1.0.509 Beta 1 (http://download.microsoft.com/downlo-
Documentos en la Red
Introducción a C-Omega, Estupendo artículo del especialista en
XML Dare Obasanjo, sobre el nuevo lenguaje en fase experimental
en Microsoft Research, mezcla de C#, XPath, y SQL. Visite el sitio de
O'Reilly XML en: http://www.xml.com/pub/a/2005/01/12/comega.html
Sitios Web del mes
On DotNet: C#, F#, J#: Sitio Web de la editorial O'Reilly, con artículos sobre
los lenguajes Sharp (#): http://www.ondotnet.com/topics/dotnet/csharp.net
PDC Talks:Fundamentals: sitio Web de Microsoft que aglutina algunas de las
conferencias dictadas el pasado PDC, que incluye artículos y ficheros PowerPoint.
http://msdn.microsoft.com/Longhorn/PDCMaterials/PDCTalksFundamentals/default.aspx
Así parece, finalmente, según confirma el artículo publicado en ZDNews (http://news.zdnet.com/2100-9593_225566423.html), en el que John Montgomery, Director
en la Microsoft Developer Division lo comentaba en una
entrevista en el pasado evento VSLive (http://www.ftponline.com/conferences/vslive/2005/sf/). La release será fundamentalmente para desarrolladores, por lo que no sería
de extrañar que, de alguna forma se integrara finalmente con la beta 2 de Visual Studio 2005, permitiendo probarlo de forma más directa. Montgomery añadía que
muchas de las novedades son meramente de mejoras operativas (de manejo) del sistema, incluyendo un nuevo
modelo de drivers. De pasada, se confirmaban las salidas
de Visual Studio 2005 y SQL-Server 2005 para después
del verano, así como betas posteriores de Longhorn (2)
a lo largo de la segunda mitad del año actual, y una nueva CTP (Community Technology Preview) de Avalon, para
el mes de marzo.
Utilidades recomendadas
Nice GUI for Windows: Es una pequeña herramienta que permite el control y ejecución visual de muchos de los comandos
tipo DOS del sistema. Se puede descargar directamente del
sitio http://bink.nu/files/HHv1002.zip
Joe's Tools: Conjunto de más de 30 herramientas gratuitas para
control del sistema, accesibles en el sitio de Joeware:
http://www.joeware.net/win/free/all.htm.
Para redes: Herramienta Microsoft para detectar si alguna interfaz de red está ejecutándose en modo “promiscuo”. Se puede
bajar desde http://www.microsoft.com/downloads/details.aspx?
amp;displaylang=en&familyid=1a10d27a-4aa5-4e96-9645aa121053e083&displaylang=en
<<dotNetManía
Kit de Recursos para IIS 6.0: Asistente y varias herramientas para
58
Valil.Chess: Detalles de funcionamiento, código fuente y ejecutable de un juego de
ajedrez realizado integramente con Visual C# 2005 Express Edition Beta. El motor de
ejecución está portado directamente del Java Chess Engine. Disponible en http://www.codeproject.com/csharp/chess.asp
facilitar la configuración del conocido servidor Web que incorpora Windows Server 2003. Está disponible en
http://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92
ee-a71a-4c73-b628-ade629c89499&DisplayLang=en
Suscripción a
dotNetManía
❑ Deseo suscribirme a dotNetManía por un año (11 ejemplares) y beneficiarme de la oferta del 10% de descuento por un
importe total de 60 € para España; o por 120€ para el resto del mundo (envío por avión) (IVA incluido).
❑ Deseo suscribirme a dotNetManía por un año (11 ejemplares) por un importe de 45 € por ser estudiante (IVA incluido).
Aporto fotocopia del carné de estudiante o sello del centro académico (IMPRESCINDIBLE). OFERTA VÁLIDA SÓLO
PARA ESTUDIANTES RESIDENTES EN ESPAÑA.
IMPORTES VÁLIDOS HASTA NUEVA OFERTA
DATOS DE FACTURACIÓN
CIF/NIF . . . . . . . . . . . . . . . . . . . . .Empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nombre y apellidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dirección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Población . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Código Postal . . . . . . . . . . . . . . . . . . . Provincia . . . . . . . . . . . . . . . . . . . . . . . . .
Teléfono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fax . . . . . . . . . . . . . . . . . . . . . . . . . . . email . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DATOS DE ENVÍO (sólo si son distintos de los datos de facturación)
CIF/NIF . . . . . . . . . . . . . . . . . . . . .Empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nombre y apellidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dirección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Población . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Código Postal . . . . . . . . . . . . . . . . . . . Provincia . . . . . . . . . . . . . . . . . . . . . . . . .
Teléfono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fax . . . . . . . . . . . . . . . . . . . . . . . . . . . email . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FORMA DE PAGO
❑ Talón nominativo a nombre NETALIA, S.L.
❑ Transferencia bancaria a nombre de NETALIA, S.L. a:
La Caixa - Número de cuenta 2100 4315 48 2200014696 (Indique su nombre en la transferencia)
❑ Domiciliación Bancaria (con renovación automática, previo aviso)
Indique su número de cuenta:
❑ Tarjeta de crédito
❑ VISA
❑ MASTERCARD
Número de su tarjeta:
Fecha de caducidad:
/
(imprescindible)
Firma y/o sello (imprescindible)
a
❑ Nº6
❑ Nº7
❑ Nº8
de
❑ Nº9
de 20 0
❑ Nº10
Si desea algún otro número indíquelo
Puede enviar los datos al email [email protected],
al FAX (34) 91 499 13 64 o al teléfono (34) 91 666 74 77.
También puede enviarlo por correo postal a la siguiente dirección:
Netalia, S.L
C/ Robledal, 135
28529 - Rivas Vaciamadrid
Madrid (España)
Usted autoriza a la mecanización
de estos datos. El responsable y
destinatario de éstos es Netalia,
S.L. Usted tiene derecho a acceder a sus datos, modificarlos y
cancelarlos cuando lo desee. Sus
datos no serán cedidos en ninguna de las formas posibles a terceras partes y no se utilizarán
más que para el buen funcionamiento de su suscripción a la
revista dotNetManía y para
informarle de las actividades
comerciales que realice la editorial Netalia, S.L. Si no desea
recibir información comercial de
dotNetManía marque la casilla
siguiente ❑
❑ Nº11
❑ Nº12

PON: P2P Over .NET PON: P2P Over .NET

Transcripción

Documentos relacionados

Entrevista a Jim Gray Entrevista a Jim Gray

El modelo de objetos de Visual Studio .NET El modelo de objetos

Con paso firme….

periódico Nº 11 en PDF - Dirección Nacional de Migraciones

Visual Basic • C# • Delphi • ASP.NET • ADO.NET • .NET Framework

identificación de quimiosensibilizadores de fenotipo