...._y

--

S. E. I .T. D. G . I .T. S.E.P.

CENTRO NACIONAL DE INVESTIGACI~N Y DESARROLLO TECNOL~GICO

ceniáet ,

PROTOCOLO PARA EL MANEJO COLABORATIVO DE DOCUMENTOS WEB CON SOPORTE PARA DESCONEXI~N

T E S I

PARA OBTENER EL GRADO DE M A E S T R O E N C I E N C I A S EN CIENCIAS COMPUTACIONALES

PRESENTA: VICTOR HUGO HERNÁNDEZ HERNÁNDEZ '

DIRECTOR DE TESIS: M.C. VICTOR JESÚS SOSA SOSA

CO-DIRECTOR DE TESIS: M.C. JOSÉ ANTONIO ZÁRATE MARCELENO

P CUERNAVACA, MORELOS. JULIO DEL 2002.

Centro Nacional de Investigación y Desarrollo Tecnológico FORMA C3

REVISION DE TESIS

Cuernavaca, Morelos a 19 de Junio del 2002

Dr. Raúl Pinto Elías Presidente de la Academia de Ciencias Computacionales Presente

Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis denominada: Protocolo para el manejo colaborativo de documentos web con soporte para desconexión, realizada por el C. Víctor Hugo Hernández Hernández, y habiendo cumplido con todas las correcciones que le fueron indicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de la tesis.

Sin otro particular, quedamos de usted.

Atentamente

La comisión de revisión de tesis

M.C. Moisés González García

Director de tesis

C.C.P. Dr. Rodolfo A. Pazos RángeVJefe del Departamento de Ciencias Computacionales

INTERIOR INTERNADO PALMIRA S/N. CUERNAVACA. MOR, MEXICO APARTADO POSTAL 5-164 CP 62050. CUERNAVACA. TELS.j73)12 2314.12 7613.18 7741.FAXj73) 12 2434 EMAlL cenidet

Centro Nacional de Investigación y Desarrollo Tecnológico FORMA C4

AUTORIZACION DE IMPRESIÓN DE TESIS

Cuernavaca, Morelos a 27 de Junio del 2002

C. Víctor Hugo Hernández Hernández. Candidato al grado de Maestro en Ciencias en Ciencias Computacionales Presente

Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia de Ciencias Computacionales en relación a su trabajo de tesis: Protocolo para el manejo colaborativo de documentos Web con soporte para desconexión, me es grato comunicarle, que conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.

Atentamente

Jefe del Depto. de Ciencias Computacionales

cenidet A

A mis padres José y Evelia, a mi novia Erandy, a niis hermanos José Antonio y Adan

Agradecimientos

A Dios, por permitirme culminar una más de mis metas

Muy carirlosamente a mis padres Jose y Evelia y mis hermanos José Antonio y Adán Hernández. por su amor, comprensión e invaluable apoyo.

A la persona más especial en mi vida, Erandy, por su amor, comprensión, apoyo y motivación, y p o r los grandes momentos buenos y malos que hemos pasado juntos.

: A mis amigos y compañeros del ITZ, por su cariño y amistad incondicional.

A mis amigos y compañeros del CENIDET, por su valiosa amistad y el apoyo brindado en los momentos dijiciles.

A todos y cada uno de los profesores del CENIDET, por compartir conmigo sus conocimientos y experiencias.

A mis asesores de esta investigación, Victor Sosa Sosa y Antonio Zárate Mareeleño. por sus consejos y asesorias, y sobre todo por su amistad.

A mis revisores de tesis, Juan Gabriel González Serna. Moisés González Garcia y Roda@ Pazos Rángel, cuyas valiosas observaciones permitieron el desarrollo y escritura de esta tesis.

A la Secretaría de Educación Pública, al Consejo del Sistema Nacional de Educación Tecnológica, y al Centro Nacional de Investigación y Desarrollo Tecnológico, por permitirme estudiar una maestría y haberme brindado la oportunidad de culminarla.

Cl& H4.p u* U&. Cuernavaca, Mor. México

Julio del 2002

.-

Contenido

Capítulo 1 Introducción

1.1 Motivación 1.2 Objetivo 1.3 Beneficios 1.4 Alcances 1.5 Organización del documento

Capítulo 2 Marco Teórico

2.1 Introducción 2.2 Evolución del trabajo colaborativo 2.3 Estado del arte

2.3.1 Sistemas de archivos distribuidos 2.3.2 Herramientas propietarias 2.3.3 Uso de correo electrónico para autoría colaborativa 2.3.4 Uso de FTP para autoría colaborativa 2.3.5 Protocolo para soportar autoría colaborativa

2.3.5.1 Protocolo WebDAV 2.3.5.1.1 Características del protocolo WebDAV 2.3.5.1.2 Métodos de WebDAV para colaboración

2.3.5.2.1 Código libre (clientes y servidores open source) 2.3.5.2.2 Servidores de WebDAV públicos en Internet 2.3.5.2.3 Productos comerciales 2.3.5.2.4 Productos comerciales de uso temporal libre

2.3.5.2 Implementaciones WebDAV

2.4 Operación en modo de desconexión 2.5 El problema de la actualización perdida 2.6 Control de concurrencia y bloqueos

2.6.1 Propiedades de los bloqueos 2.6.2 Bloqueos exclusivos y compartidos

Capítulo 3 Análisis y Solución Conceptual del Problema

3.1 Planteamiento general del problema

3.2 Diseño de la solución 3.1.1 Descripción del problema

3.2.1 Protocolo de publicación colaborativa remota

8

10 11 12 12 13 14 15 15 16 17 18 20 20 21 22 22 23 24 26 26 27

28

30 31 32 33

IV

3.2.1.1 Requerimientos en soporte para colaboración 3.2.1.1.1 Mismo soporte para todos los tipos de contenido 3.2.1.1.2 Soporte para control de concurrencia y mecanismo de

3.2.1.1.3 Soporte para propiedades (metadatos) 3.2.1 . I .4 Soporte para manipulación del espacio de nombres 3.2.1.1.5 Soporte para colecciones

bloqueos no orientados a conexión

3.2.2 Arquitectura cliente - servidor 3.2.2.1 Arquitectura cliente - servidor y la Web 3.2.2.2 La Web: una arquitectura distribuida

3.2.2.3 Funcionamiento del protocolo HTTP 3.2.3 Arquitectura multicapa: cliente - intermediario - servidor

3.2.3.1 Uso de la arquitectura con intermediario para soportar

3.2.4 Arquitectura para colaboración con soporte para desconexión

3.2.2.2.1 Proceso cliente - servidor dentro de la Web

desconexión

3.2.4.1 Funciones del servidor intermediario 3.2.4.1.1 El procedimiento de colaboración 3.2.4.1.2 Posibles causas de inconsistencia de información 3.2.4.1.3 Protocolo de resolución de conflictos por inconsistencia

en la información 3.2.4.2 Beneficios en los servicios de colaboración mediante la

arquitectura

Capítulo 4 Prototipo de Servidor Intermediario

4.1 Diseño de un prototipo de servidor intermediario 4.1.1 Proceso Intermediario de Enlace

4.1.1.1 Consideraciones generales 4.1.1.2 Consideraciones del método de HTTP OPTIONS 4.1.1.3 Consideraciones del método de HTTP GET 4.1.1.4 Consideraciones del método de HTTP HEAD 4.1.1 .5 Consideraciones del método de HTTP PUT 4.1.1.6 Consideraciones del método de HTTP DELETE 4.1.1.7 Consideraciones del método de WebDAV PROPFIND 4.1.1.8 Consideraciones del método de WebDAV PROPPATCH 4.1.1.9 Consideraciones del método de WebDAV MKCOL 4. I . 1.1 O Consideraciones del método de WebDAV COPY 4.1.1.1 1 Consideraciones del método de WebDAV MOVE 4.1.1.12 Consideraciones del método de WebDAV LOCK 4.1. I . 13 Consideraciones del método de WebDAV UNLOCK

4.1.2 Proceso de Actualizaciones 4.1.3 Proceso Motor de WebDAV local 4.1.4 Registro en conexión 4.1.5 Registro en desconexión 4.1.6 Registro de mapeos

33 33

34 35 37 37 38 39 40 40 41 42

44 45 48 52 53

54

56

58

60 61 62 71 71 72 73 13 74 74 74 75 75 75 77 78 81 82 84 84

V

4.2 Consideraciones de uso del lado del cliente 4.3 Consideraciones de uso del lado del servidor

85 85

87 Capítulo 5 Plan de Pruebas

5.1 Objetivo de las pruebas 5.2 Equipo y herramientas usadas para realizar las pruebas 5.3 Descripción del primer ambiente de pruebas (prueba de conexión y

métodos de HTTP y WebDAV) 5.3.1 Casos de prueba 5.3.2 Conclusiones sobre los resultados obtenidos

5.4 Descripción de un segundo ambiente de pruebas (prueba de conexión, métodos de HTTP y WebDAV, y soporte de desconexión)

5.4.1 Casos de prueba 5.4.2 Conclusiones sobre los resultados obtenidos

89 89

90 91 94

94 96

103

Capítulo 6 Conclusiones 104

6.1 Contribuciones de este trabajo 6.2 Trabajos futuros

Anexo A. Clientes de WebDAV

Anexo B. Servidores de WebDAV

Anexo C. Servidor Intermediario

106 106

108

116

123

Bibliografía y Referencias 127

Lista de Figuras

Figura I . 1 Figura 2.1

Figura 2.2

Figura 2.3

Figura 2.4

Figura 2.5

Figura 2.6

Figura 2.7

Figura 2.8

Figura 2.9

Figura 3.1

Figura 3.2

Figura 3.3

RFC 2518 Colaboradores con la misma herramienta

Interacción de Allianceweb y COARSY con PIÑAS

Colaboradores con el mismo protocolo

Cliente DAV cadaver

Fundación Apache

Servidor DAV Magi Server

Cliente Internet Explorer 5 de Microsoft

Logo Cliente Office 2000 de Microsoft El problema de la actualización perdida

Equipo de colaboración mediante la Web

Pérdida del enlace de comunicación de un miembro del equipo de colaboración

Manejo de diferentes tipos de contenido

Figura 3.4 Acceso concurrente con mecanismo de control de concurrencia

Figura 3.5 Etiquetas META en un documento en HTML

Figura 3.6 Manipulación de recursos

Figura 3.7 Figura 3.8 Figura 3.9

Figura 3.10 La World Wide Web, o simplemente Web Figura 3.1 1 Solicitud de un cliente al servidor de Web Figura 3.12 Solicitud GET de HTTP de un cliente

Figura 3.13 Respuesta afirmativa del servidor a una solicitud GET

Figura 3.14 Arquitectura cliente - intermediario -servidor

Miembros de una colección Arquitectura cliente - servidor Interacción de la arquitectura cliente - servidor con el usuario

4

13

14

16

20

20

21

22

22

24

30

31

34

34

36

37

37

38

39 40 41 42

42

43

VI1

Figura 3.15 Topología de una red LAN con direcciones Ip negra

Figura 3.16 Servidor intermediario que almacena recursos de Web

Figura 3.17 Modelo de soporte para colaboración y desconexión

Figura 3.18 Transacción de WebDAV sin enlace al servidor de Web

Figura 3.19 Arquitectura cliente - intermediario - servidor en una

Figura 3.20 Arquitectura cliente - intermediario - servidor en la que el

Figura 3.21 Representación gráfica de los procesos que componen

Figura 3.22 Solicitud - respuesta en conexión. se realiza mapeo

Figura 3.23 Solicitud - respuesta en desconexión. se realiza mapeo

Figura 3.24 Proceso de una petición con conexión

Figura 3.25 Proceso de una petición sin conexión

Figura 3.26 Proceso para editar un recurso Figura 3.27 Petición que involucra versiones Figura 4.1

Figura 4.2

para acceder a servicios de la Web

red LAN

cliente y el intermediario residen en la misma máquina

el servidor intermediario

para almacenar réplica

para recuperar réplica

Estructura del prototipo de Servidor Intermediario

Pseudocódigo del funcionamiento del Proceso Intermediario de Enlace con una petición de HTTP GET del cliente

Figura 4.3 Estructura de directorios creados en el Servidor Intermediario en donde se almacena la réplica del recurso obtenido

Figura 4.4 Sentido de comunicación entre las clases que forman el Proceso Intermediario de Enlace

Figura 4.5 Transición en la que se acepta la solicitud de un cliente y se crea un hilo de ejecución para darle servicio

Figura 4.6 Momento en el que se verifica la existencia del cuerpo de la solicitud, y en caso de existir se obtiene su tamaño

Figura 4.7 Envio de información de la solicitud del cliente a la Clase CLIENTESDAVHTTP

Figura 4.8 Envío de la respuesta a la solicitud del cliente a la Clase PROXYDAVTHREAD

Figura 4.9 Solicitud para realizar réplica local a la clase PETACTUALIZA

43

44

46

47

48

48

49

so

so SI

52

53

55 60

61

64

66

66

67

68

68

69

~i~~~~ 4.10 Respuesta sobre la réplica y terminación del hilo de

Figura 4.1 1 Clases de Java del Servidor Intermediano Y la serie de

Figura 4.12 Clases de Java del Servidor Intermediario Y la serie de

Figura 4.13 Pseudocódigo para editar un recurso dependiendo

Figura 4.14 Pseudocódigo del funcionamiento del Proceso de

Figura 4.15 Clases del Servidor Intermediario que'intervienen

Figura 4.16 Momento en que se crea el hilo de ejecución para

Figura 4.17 Envío de información para llevar a cabo una actualización

Figura 4.18 Respuesta del servidor externo a la solicitud enviada

Figura 4.19 Proceso de Actualizaciones en espera de llevar a cabo una posible actualización

Figura 4.20 Fragmento del archivo de configuración del servidor de WebDAV donde se definen y habilitan diferentes secciones

Figura 4.21 Registro de una solicitud GET en el Archivo de Registro en Conexión

Figura 4.22 Registro de una solicitud LOCK en el Archivo de Registro en Conexión

Figura 5.1 Primer escenario de pruebas

Figura 5.2 Netscape Navigator solicitando un recuso de la Web

Figura 5.3 Resultado exitoso a la solicitud del cliente Netscape Navigator para el servidor de Web h t t p : / / w . webdav.org

Figura 5.4 Resultado exitoso a la solicitud del cliente DAVExplorer para el servidor de WebDAV http://ww.cyberteams. corn

Figura 5 . 5 Selección Get Fife para obtener un recurso del servidor de WebDAV usando DAVExplorer

Figura 5.6 Escenario de pruebas en el Laboratorio de Sistemas Distribuidos de CENIDET

Figura 5.7 Distribución de los primeros elementos que participan en las pruebas

ejecución

transiciones en una transacción con conexión

transiciones en una transacción sin conexión

de la existencia de la correspondiente réplica

Actualizaciones

para el Proceso de Actualizaciones

encargarse del Proceso de Actualizaciones

por la Clase PETACTUALIZA

69

70

71

76

78

79

80

80

81

81

82

83

84

90

91

92

93

93

95

96

IX

http://whttp://webdav.orghttp://ww.cyberteams

Figura 5.8

Figura 5.9

Caja de diálogo para abrir un recurso con el cliente “Microsoft Word 2000” Momento de la edición del recurso con el cliente “Microsoft Word 2000”

Figura 5.10 Caja de diálogo para guardar el recurso con el cliente “Microsoft Word 2000”

Figura 5.1 1 Archivo proporcionado como sólo lectura al estar bloqueado por otro usuario

Figura 5.12 Servidor Intermediario en calidad de cliente en el momento de realizar actualizaciones

91

97

98

101

102

X

Lista de Tablas

Tabla 2.1

Tabla 2.2

Tabla 2.3

Tabla 2.4

Tabla 3.1

Nuevos métodos de HTTP

Métodos de HTTP/I . I actualizados semanticamente Nuevos encabezados de HTTP

Tabla de compatibilidad de bloqueos

Información y propiedades de WebDAV sobre recursos

18

19 19

21

36

XI

Capítulo 1 Introducción

Contenido del: capítulo: 1.1 Motivación 1.2 Objetivo 1.3 Beneficio 1.4 Alcances 1.5 Organización del documento

Inti I oducción Este capítulo contiene, como su nombre lo indica, la introducción del trabajo de

investigación de esta tesis. El capitulo está organizado en diferentes puntos que explican la motivación, el objetivo, los beneficios, el alcance, y como punto final, se presenta la organización del resto de este documento.

INTRODUCCION Capirirlo I

1.1 Motivación

“Aunque la interacción informática todavía está en SU infancia, ha cambiado espectacularmente el mundo en que vivimos, eliminando las barreras del tiemPo Y la distancia y pemiitiendo a la gente compartir información y trabajar en colaboración. El avance hacia la ‘superautopista de’la información’ continuará a un ritmo cada vez mas rápido. El contenido disponible crecerá rápidamente, lo que hará más fácil encontrar cualquier información en Internet. Las nuevas aplicaciones permitirán realizar transacciones económicas de forma segura y proporcionarán nuevas oportunidades para el comercio. Las nuevas tecnologías aumentarán la velocidad de transferencia de información, lo que hará posible la transferencia directa de ‘ocio a la carta’. Es posible que las actuales transmisiones de televisión generales se vean sustituidas por transmisiones específicas en las que cada bogar reciba una señal especialmente diseñada para los gustos de SUS miembros, para que puedan ver lo que quieran en el momento que quieran” [9]. Esto es io que expresa la Enciclopedia Microsoft Encarta en la edición de 1998 sobre Internet, y aunque se ha seguido avanzando a pasos agigantados en su desarrollo, aun falta mucho por hacer y en cuyo desarrollo se puede formar parte.

. .

Particularmente esta investigación fue muy motivada por el hecho de poder participar en parte del desarrollo de la tecnología que involucra Internet, y hacer partícipe de esta tecnología y sus servicios a regiones que principalmente por su ubicación geográfica y atraso tecnológico no son capaces de explorar y explotar en mayor grado los beneficios que trae consigo dicha tecnología, y es que el avance tecnológico es realizado principalmente por países que cuentan con grandes capitales para invertir en investigación y donde existen grandes vías de comunicación que no presentan tantas fallas en los servicios para las que son usadas. En México y en muchos otros países que cuentan con regiones que por su geografía dificultan las comunicaciones o que su avance tecnológico no va a la par de los grandes países del primer mundo, se tienen .que buscar alternativas que nos permitan acceder a este nuevo mundo de posibilidades que trae consigo Internet, y aprovechar al máximo nuestras capacidades y recursos de los que se dispone para lograrlo.

1.2 Objetivo

El objetivo de este trabajo de tesis está enmarcado en los desarrollos del grupo de trabajo del protocolo WebDAV [23] del IETF [I21 sobre manejo colaborativo de documentos en la Web, el cual tiene la limitante de no operar sin conexión, por lo tanto con este proyecto se busca complementar dichos desarrollos del proyecto WebDAV con un mecanismo que permita el manejo colaborativo de documentos en la Web, y que además provea de soporte para los momentos de desconexión o conectividad intermitente.

En forma más particular se tienen los siguientes objetivos específicos:

a). Permitir la interoperabilidad remota, asíncrona, y la publicación colaborativa, dar facilidades para el control de la concurrencia, para las operaciones del espacio de nombres, y para la administración de propiedades que ofrece el protocolo WebDAV,

3

INTRODUCCI~N Capitulo I

pero con soporte a fallas de comunicación.

b). Añadir con el trabajo de esta tesis el soporte necesario para permitir que las características del protocolo WebDAV mencionadas en ei punto anterior se desempeñen adecuadamente cuando se presentan fallas en la comunicación, es decir soporte para desconexión que no degrade el comportamiento de la utilización del protocolo WebDAV en dicha situación. Este soporte garantizará la consistencia de los documentos y su enfoque es buscar la compatibilidad con el protocolo del grupo de trabajo WebDAV [23] del IETF [12] en el estándar propuesto en el RFC2518 [ l l ] , figura 1.1.

c). El soporte para desconexión mencionado en el punto anterior se definirá mediante una arquitectura que involucre tanto al cliente como al servidor involucrados en el proceso de colaboración; además. se realizarán los ajustes necesarios al protocolo WebDAV para su funcionamiento bajo tal arquitectura sin que pierda sus características originales ni se degrade su funcionamiento.

d). Desarrollo de un prototipo constituido por clases de Java que permita: manejar las comunicaciones cliente - servidor mediante el protocolo WebDAV, que lleve control sobre la operación en conexión o desconexión, y que realice las actualizaciones necesarias en el servidor sobre los cambios realizados en el cliente. El propósito del prototipo consiste en verificar los puntos a), b) y c) anteriores.

I

,I

i,. ..' ., .. .. .. .. I . HTIP Extendons for D M u t e d AuIhoilng -- WEBDAV

SI- of UM Memo :>; ..

INTRODUCCION Capitulo I

1.3 Beneficios

LOS beneficios que se obtienen de este trabajo de tesis sobre el soporte a la desconexión son que se pueden obtener resultados en el trabajo colaborativo similares a 10s que se obtienen cuando se trabaja sin fallas en la comunicación, es decir que se siguen manteniendo las caractensticas para publicación de todos los tipos de contenido en la Web, se mantiene el control de concurrencia usando los mismos bloqueos de WebDAV para prevenir conflictos de sobreescritura y soportando la desconexión garantizando la edición de documentos sólo por la persona acreditada para ello por un tiempo acordado previamente durante el cual el documento en el sitio del servidor no podrá cambiarse por los demás colaboradores. Es decir, que una persona que está editando un documento compartido por todos sus colaboradores será capaz de continuar su edición y terminarla normalmente aun en presencia de fallas con la conexión, y podrá confiar en que sus modificaciones al documento no se perderán y serán disponibles a su grupo de trabajo automáticamente en cuanto se restablezca la conexión.

1

Además de que se tienen los beneficios relativos al soporte de desconexión como los mencionados anteriormente, también se heredan los beneficios que trae consigo el protocolo de autoria colaborativa incorporados al soporte de desconexión, y serán reflejados en diferentes aspectos que involucran el trabajo cotidiano cuando se comparte información y cuando se colabora con más personas dentro de un proyecto, es decir que se dispone de un mecanismo que permite publicación interoperable de todos los tipos de contenido en la Web (texto, imágenes, animación y audio), además se beneficia a los individuos y a los grupos de trabajo para que puedan usar el Protocolo de Transferencia de Hipertexto (HTTP) para publicar directamente su trabajo en la Web, buscando que los participantes de grupos de trabajo puedan editar colaborativamente sus documentos desde sitios geográficamente remotos. Debido a la naturaleza distribuida de la Web, estos grupos de trabajo pueden tener miembros dentro de la misma organización, o fuera de los límites organizacionales.

Desde un punto de vista técnico también se reflejan beneficios, esto es porque de esta forma se podrá observar y determinar el comportamiento de las transferencias de información entre los participantes del proyecto (monitoreo).

1.4 Alcances

Debido a la naturaleza del enfoque de este trabajo sobre un protocolo de colaboración inmerso con un soporte de desconexión, no es de interés el nivel de aplicación donde se encuentran las herramientas encargadas de la apertura, edición y cierre de los documentos, es decir que este trabajo sólo se centrará en el protocolo para transferir la información, mantener la congruencia de los documentos editados, administrar el espacio de nombres de los documentos y sus propiedades como lo permite el protocolo WebDAV añadiendo el soporte necesario para desconexión para el trabajo colaborativo con documentos de la Web. Por lo tanto, el resultado de este trabajo consiste en un diseño de la solución con la implementación de un prototipo constituido por varias clases de Java, cada

INTRODUCCI~N Capitulo í

una con función específica para resolver las necesidades de los problemas originados por un evento de desconexión en el que las facilidades de colaboración la provean los módulos ya implementados sobre el protocolo WebDAV.

Con el trabajo desarrollado por el grupo de trabajo WebDAV y con la aportación adicional de este proyecto, es decir, el soporte de desconexión que se proporcionara ai trabajo colaborativo, se proveerá una interfaz común para un amplio rango de repositorios, tales como administración de documentos, administración de la configuración, administración del sistema de archivos, etc. En esencia se buscará, por un lado, que la Web sea vista como un sistema de archivos accesibles por red a gran escala, y por otro lado que se permita a personas que carecen de buenas condiciones de conexión a Internet participar con este tipo de tecnología.

1.5 Organización del documento

El documento se encuentra organizado en seis capítulos, los cuales presentan la siguiente información:

El capítulo 2, denominado “Marco Teórico”, contiene una breve introducción y muestra información sobre cómo ha evolucionado el trabajo colaborativo hasta nuestros días, presenta información sobre el estado del arte incluyendo herramientas implementadas y protocolos desarrollados usados para soportar la colaboración, se amplía la información sobre el protocolo WebDAV tomado como base para este trabajo y sus características para enfrentar el problema de la actualización perdida, finalmente el capítulo concluye con el análisis de las técnicas de bloqueo y sus diferentes tipos para el control de concurrencia.

El capítulo 3, “Análisis y Solución Conceptual del Problema ”, comienza presentando el planteamiento general del problema, después continúa con la descripción del trabajo colaborativo en la Web, las características de la desconexión y posteriormente describe en forma específica el problema. Después de analizar toda la problemática, se presenta el diseño de la solución, la arquitectura cliente - servidor, la arquitectura con el servidor intermediario y sus funciones, y finaliza el capítulo con el diseño del prototipo de servidor intermediario.

El capítulo 4, denominado “Prototipo de Servidor Intermediario”, se encarga de la descripción del prototipo desarrollado en la investigación, iniciando con la presentación de las consideraciones generales que se tomaron en cuenta para su desarrollo, describe brevemente los clientes y servidores usados en el desarrollo y pruebas del prototipo; se presenta el análisis y el diseño del prototipo y sus funciones, y para terminar se presenta todo el diagrama funcional con su explicación.

El capítulo 5, “Plan de Pruebas”, se encarga de presentar el plan de pruebas usado para verificar la funcionalidad del prototipo; se comienza explicando el objetivo de las pruebas, después se describe el ambiente donde se realizaron, y se analizan los casos de

i

Capiiulo I INTRODUCCI~N

prueba representativos de las situaciones que podrían presentarse, finalmente se presentan los resultados obtenidos.

El capítulo 6 , sobre “Conclusiones ”, es la parte final del documento. En esta parte se describen las contribuciones del trabajo desarro!lado, algunas sugerencias para mejorarlo, trabajos futuros que podría realizarse para hacer más robusto el trabajo realizado hasta el momento, y se finaliza el capítulo y el documento con algunos comentarios finales.

7

Capítulo 2 Marco Teórico

Contenido del capítulo: 2.1 Introducción 2.2 Evolución del trabajo colaborativo 2.3 Estado del arte 2.3.1 Sistemas de archivos distribuidos 2.3.2 Herramientas propietarias 2.3.3 2.3.4 2.3.5 2.3.5.1 Protocolo WebDAV 2.3.5.1.1 Características del protocolo WebDAV 2.3.5.1.2 Métodos de WebDAV para colaboración 2.3.5.2 Implementaciones WebDAV 2.3.5.2.1 Código libre (clientes y servidores open source) 2.3.5.2.2 Servidores de WebDAV públicos en Internet 2.3.5.2.3 Productos comerciales 2.3.5.2.4 Productos comerciales de uso temporal libre 2.4 2.5 2.6 2.6.1 Propiedades de los bloqueos 2.6.2 Bloqueos exclusivos y compartidos

Uso de correo electrónico para autoría colaborativa Uso de FTP para autoria colaborativa Protocolo para soportar autoria colaborativa

Operación en modo de desconexión El problema de la actualización perdida Control de concurrencia y bloqueos

Marco Teórico Este capítulo contiene lo referente al marco teórico, y comienza haciendo una breve

introducción seguida de un poco de historia y evolución del trabajo colaborativo. Después se presenta el estado del arte, incluyendo herramientas propietarias y de código libre (open source) y protocolos usados como soporte para la colaboración, en los que están los protocolos de correo electrónico, el de transferencia de archivos, el de transferencia de hipertexto, y el de autoría y publicación colaborativa. Se presentan en el capítulo las características y lo que involucra un ambiente de trabajo colaborativo, los problemas con la desconexión y la solución mediante la técnica de bloqueos para evitar la actualización perdida

Marco Teórico Capiiulo 2

~ 2.1 Introducción *..

Colaborar se refiere a participar en forma activa con otras personas para lograr un fin, y desde los primeros pobladores se ha visto que esta actitud por realizar las actividades en conjunto ha contribuido al desarrollo de todos los aspectos de la vida y de la civilización. Se puede ver claramente como el hombre ha trabajado en conjunto para crear grandes joyas arquitectónicas, grandes descubrimientos y grandes desarrollos científicos y tecnológicos como lo es Internet.

Internet comenzó en 1969 como un experimento del gobierno para conseguir la información de las redes de radio y las basadas en los satélites del Departamento de Defensa de los E.E.U.U. Comenzaron con cuatro ordenadores conectados con módem que permitieron que los ordenadores enviaran la información de uno a otro a-través de líneas telefónicas. Esta red original llamada ARPANET, fue cambiando a Internet hasta su uso en universidades. Después de muchos cambios y progresos llegó a estar disponible para las compañías que podían conectar su ordenador a otros a pesar de los diversos sistemas operativos. Actualmente el uso de Internet se ha extendido y millones de personas entran cada día.

Los sistemas de redes como Internet permiten intercambiar información entre computadoras, y ya se han creado numerosos servicios que aprovechan esta función. Entre ellos figuran los, siguientes: conectarse a un ordenador desde otro lugar (telnet), transferir archivos entre una computadora local y una computadora remota (protocolo de transferencia de archivos, o FTP) y leer e interpretar archivos de ordenadores remotos (gopher). Uno de los servicios de Internet más importantes es el protocolo de transferencia de hipertexto (HTTP) [lo], un descendiente del servicio de gopher. El HTTP puede leer e interpretar archivos de una máquina remota: no sólo texto sino imágenes, sonidos o secuencias de video. El HTTP es el protocolo de transferencia de información que forma la base de la colección de información distribuida denominada World Wide Web [9].

La World Wide Web (también conocida como Web o WWW) es una colección de archivos, denominados lugares de Web o páginas de Web, que incluyen información en forma de textos, gráficos, sonidos y vídeos, además de vínculos con otros archivos. Los archivos son identificados por un localizador universal de recursos (URL, por sus siglas en inglés) que especifica el protocolo de transferencia, la dirección de Internet de la máquina y el nombre del archivo. Por ejemplo, un URL podría ser http://www.encarta,es/index.htm, en donde http es el protocolo de transferencia, www.encurtu.es es la dirección de Internet de la máquina y el nombre del archivo es index.htm. Los programas informáticos denominados navegadores -como Navigator, de Netscape, o Internet Explorer, de Microsoft- utilizan el protocolo HTTP para obtener esos archivos. Continuamente se desarrollan nuevos tipos de archivos para la Web, que contienen por ejemplo animación o realidad virtual (VRML). Hasta hace poco había que programar especialmente los lectores para manejar cada nuevo tipo de archivo. Los nuevos lenguajes de programación (como Java, de Sun Microsystems) permiten que los navegadores puedan cargar programas de ayuda capaces de manipular esos nuevos tipos de información [9].

i n

http://www.encarta,es/index.htm

Marco Teórico Capítulo 2

La Web se ha desarrollado sobre bases de lectura, donde se puede consultar una gran cantidad de información; en 1990 con una nueva visión Tim Bemers-Lee desarrollo el primer prototipo de navegador con capacidades de lecturdescritura, aunque la Web floreció como un medio de lectura.

2.2. Evolución del trabajo colaborativo

El colaborar entre varias personas para lograr un objetivo común ha sido esencial en la supervivencia del ser humano desde el comienzo de nuestros días. Conforme se evolucionó algunas comunidades llegaron a alcanzar formas mucho muy complejas de organización económica, social, política y religiosa, donde surgen vínculos permanentes entre las comunidades, ya sea por la necesidad de colaborar en empresas de interés mutuo, o como resultado de guerras u otros contactos.

Ahora se oye hablar de un nuevo tipo de "sociedad de la información", que transformaría prácticamente todas las esferas de la actividad humana. Para algunos, esta sociedad abarcaría todos los procesos -- lenguaje, procesamiento de la información, conocimiento -- que se pueden efectuar electrónicamente y que pueden afectar la manera en que nos comunicamos, entablamos relaciones y realizamos transacciones. Otros la ven como un nuevo paradigma "tecnoeconómico", similar a los cambios abruptos de otras épocas, como la introducción de la maquinaria que revolucionó la industria textil de algodón entre 1780-1840, permitiendo a los ingleses mantener el liderazgo económico mundial por casi un siglo; el uso del carbón, especialmente en máquinas a vapor; el acero, la electricidad y vías férreas; el desarrollo de recursos petrolíferos y petroquímicos, y el automóvil como medio de transporte masivo en la década de los 40.

Hoy en día, computadoras personales a precios accesibles y enlaces de comunicación de alta velocidad permiten que una persona con mínima capacitación (al fabetizada y con manejo del teclado) pueda obtener y manipular datos provenientes de diversas fuentes de manera simple y a bajo costo, entrando de este modo en el "universo digital", creando nuevos tipos de comunicaciones y transacciones, muchas de las cuales tienen lugar completamente en ese espacio virtual. La codificación digital ha salido de la computadora y ha penetrado en la red telefónica y el canal de radiodifusión. El costo marginal del manejo de la información en una computadora o de su transmisión a través de una red es prácticamente cero. Mejor aún, la tecnología misma es la que permite que sea casi cero: a menudo, son las reglamentaciones públicas, los contratos privados, las prácticas restrictivas y los impuestos los que imponen al usuario un costo directo y a veces significativo [ 8 ] .

Con todo este avance y desarrollo han surgido también las redes de computadoras. Las redes de computadoras, en la actualidad, son una pieza fundamental en cualquier tipo de negocio. Sin embargo, no siempre fue así, ya que la instalación y mantenimiento de una red LAN (Red de Área Local) estaba restringida a empresas grandes que debían invertir altas cifras para ello y para contratar personal especializado.

11

Marco Teórico Capitulo 2

El desarrollo y expansión tecnológica ha permitido una reducción en los costos de los productos lo que ha favorecido que las empresas de cualquier tipo y tamaño instalen una red. Las redes permiten la conectividad entre vanas computadoras de una empresa para maximizar su productividad y eficiencia a través de la optimización de recursos.

La palabra clave en una red es compartir. La implementación de una red en las empresas posibilita compartir información y recursos entre los distintos puestos de trabajo, de esta manera se obtiene una reducción de costos y un aumento en la productividad [I].

Se ha llegado a un punto en el que la necesidad de compartir información y colaborar para el éxito de las actividades resulta indispensable, pero ¿qué ha pasado con las herramientas para tal propósito? Las primeras herramientas comerciales para soportar autona Web remota aparecieron en 1995 con NaviPress de NaviSoft y FrontPage de Vermeer Technologies (las cuales lograron el interés de America Online y Microsoft, respectivamente). Desde entonces se han incrementado el número de herramientas, incluyendo procesadores de texto y ambientes de desarrollo de aplicaciones rápidas integrados a la Web, que comenzaron a ofrecer capacidades para publicar páginas en los servidores de Web [24].

2.3 Estado del arte

A través de la Web, usuarios distribuidos sobre Internet pueden acceder a una gran cantidad de información. En años recientes se han hecho esfuerzos considerables para soportar colaboración en la Web, los esfuerzos incluyen navegadores síncronos, espacios de trabajo colaborativo, ambientes de interacción casual, entre otros. Sin embargo, sólo limitados esfuerzos se han hecho para soportar autoría colaborativa de bases de documentos Web.

Aun cuando varias aplicaciones proveen funciones interactivas para navegadeditar en el ambiente Web, ninguna de ellas ofrece soporte para autoria colaborativa integrada. Esto no es sorpresa, ya que no hay un soporte adecuado en la infraestructura Web para administrar usuarios en forma sencilla, ni para identificar las acciones y contribuciones de autoría de los usuarios. Hay también la necesidad de replicar documentos para enfrentar las fallas del enlace y la desconexión del sitio de Internet. En tal situación, un ambiente de co- autoría nómada en un modo desconectado o degradado es una característica Útil para dar oportunidad de trabajo a los actuales usuarios.

2.3.1 Sistemas de archivos distribuidos

Los sistemas de archivos distribuidos [IS] como el Andrew File System (AFS), el Network File System (NFS) de Sun, y Novel1 Netware han llegado a ser populares en una gran variedad de entornos. Hay varias razones para el éxito de un sistema de archivos distribuido. Primero, facilitan compartir información entre usuarios. Segundo, incrementan la movilidad de usuarios individuales al proveer acceso a datos desde diferentes

13

Marco Teórico Capitulo 2

ubicaciones; y por último, simplifican la administración de un gran número de máquinas. ya que, tareas como respaldos de información, instalación de software, y mantenimiento son realizadas por operadores capacitados en lugar de los usuarios de forma individual.

La mayoría de los sistemas de archivos distribuidos están organizados de acuerdo al modelo cliente-servidor. Un núcleo de servidores actúa como depósito de datos, al cual los clientes acceden a través de una interfaz de sistema estándar. Para mejorar el rendimiento, los clientes mantienen archivos o partes de archivos en memoria, en el disco local o en ambos (cache). Para mejorar la disponibilidad, algunos sistemas de archivos replican archivos en múltiples sitios. El soporte para replicación varía; el acceso del cliente puede ser de sólo-lectura o de lectura-escritura, y las actualizaciones durante las particiones de la red pueden o no permitirse. Los sistemas de archivos distribuidos suponen típicamente que los clientes y servidores están fuertemente conectados; lo que no puede considerarse así en un ambiente de naturaleza distribuida como la Web.

2.3.2 Herramientas propietarias

Existen algunas herramientas que permiten realizar trabajo colaborativo en la Web, por ejemplo BSCW [2] e HYPER-G [I41 que por sus características propietarias han desarrollado comunidades de uso, esto es que todos los colaboradores necesitan usar herramientas colaborativas compatibles, como se ve en la figura 2.1. Para colaborar usando PREP [17], todos los colaboradores necesitan usar PREP, así también sucede con GROVE [7] y DUPLEX [18]. MESSIE [22] tiene como fondo SMTP (Simple Mail Transfer Protocol) [20]. CONTAC provee una interfaz de formularios Web para un sistema de soporte de colaboración, pero no proporciona el soporte HTTP de BSCW para enviar y descargar (upload/download) archivos. BSCW, MESSIE y CONTAC no comparten la visión de capacidad de edición y publicación colaborativa por sí mismas, lo que acarrea un costo extra por el cambio de herramientas para lograr la edición y publicación colaborativa.

Colatomior lI

Marco Teorico Capitulo 2

Existe también un trabajo desarrollado en Francia por el Instituto de Informática Y Matemáticas Aplicadas de Grenoble, que agrega capacidad para soportar trabajo en desconexión en forma colaborativa, el proyecto Alliance. La aplicación Alliance es un editor cooperativo estructurado basado en Internet para documentos HTML/XML. Del análisis de las ventajas y limitaciones de Alliance se derivan las directrices para el navegadodeditor Allianceweb, habilitado para trabajar sobre el ambiente de Web. Allianceweb permite a los usuarios distribuidos sobre la red InterneUWeb producir documentos HTMLiXML en una forma consistente y concertada. En su etapa de diseño se llegó a la conclusión de que la tecnología Web actual carece de soporte flexible para autoría colaborativa, así que se definieron los requerimientos de servicios que tienen que ser ofrecidos para lograrlo. Dichos requerimientos dieron origen a PIÑAS (Platform for Interaction, Naming And Storage).

Los servicios proporcionados por PINAS son apropiados no sólo para autoría colaborativa en Allianceweb, sino que podrían ser usados por otras aplicaciones con requerimientos similares como COARSY (COllaborative Asynchronous Review System), un ambiente cooperativo y distribuido para autoría, anotación y revisión de documentos en HTML [ 5 ] , la interacción de Allianceweb y COARSY con el servidor de HTTP y los servicios de la plataforma PINAS pueden observarse en la figura 2.2. Cuando un cliente realiza una petición, debe ser identificado para construir respuestas apropiadas a su petición, debido a que los documentos PINAS no pueden ser transmitidos en su formato a un navegador estándar. En este caso el servidor genera una versión monoiítica (HTML íntegro) del documento

1 Figura 2.2: Interacción de AllianceWeb y COARSY con PINAS

2.3.3 Uso de correo electrónico para autoría colaborativa

El correo electrónico permanece como la tecnología más usada para autoria colaborativa, principalmente debido a su ubicuidad, es decir, se puede estar trabajando en u n proyecto con uno o más grupos en locaciones geográficamente distantes, y con el correo

Mnrco Teórico Cnpiiulo 2

electrónico ayudar a administrar el proyecto notificando a todos cada una de las actualizaciones realizadas por cada uno de los integrantes del proyecto, quizá llenando directorios con revisiones de la información (no necesariamente bien organizada), enviando mensajes para aclarar qué está hecho y qué falta por hacer. La situación podría verse aun más caótica si se considera el hecho de agregar a toda esta información la problemática que podría presentarse con un fallo en el enlace de comunicación. Un escenano como éste no es nada atractivo para realizar autoría colaborativa entre grupos de trabajo que necesitan mayor confianza en tener actualizada su información.

2.3.4 Uso de FTP para autoría colaborativa

Con el protocolo de transferencia de archivos FTP (File Transfer Protocol) se tiene un enfoque cliente - servidor con la información centralizada; sin embargo, una sesión de FTP abre dos conexiones de red, una como canal de control usado para enviar comandos del cliente al servidor, y otra como canal de datos usado para transferir archivos de una máquina a otra. Esta diferencia con HTTP, que combina información de control y datos en un solo canal, hace que las implementaciones de clientes sean más simples para HTTP que para FTP [25]. FTP provee operaciones de espacio de nombres equivalentes a las que proporciona el protocolo WebDAV [25], aunque no soporta ninguna forma de prevención de sobreescritura, lo que lo hace inadecuado para autoría colaborativa; además, tampoco tiene facilidades para metadatos. Aparte de todo eso, una sesión FTP es con estado, lo que podría llevar a problemas de robustez para sesiones colaborativas de larga duración al tener que mantener tanto la conexión de control durante todo el tiempo que dure la sesión, como el estado en el que se encuentra dicha sesión.

2.3.5 Protocolo para soportar autoría colaborativa

La utilidad de una herramienta no depende sólo de la herramienta misma, sino de la cantidad de personas que también tienen herramientas compatibles con ella. Si hubiera sólo un teléfono en el mundo su utilidad sería nula, con dos o tres no ayudaría mucho, pero cuando millones, o cientos de millones de personas tienen teléfonos, su utilidad es inmensa. Como el teléfono, una herramienta de publicación colaborativa por si misma tiene valor colaborativo limitado, pero cuando millones de personas tienen tecnología colaborativa compatible, la utilidad de la herramienta es grandiosa.

Cuando un protocolo de red asegura interoperabilidad entre herramientas de publicación colaborativa, se incrementa el valor de los servidores que soportan el protocolo de colaboración, ya que el servidor sin una inversión adicional, puede ahora soportar una herramienta más. Lo complementario también es bueno, cuando muchos servidores se hacen disponibles, el valor de las herramientas se incrementa sin invertir adicionalmente en ellas, debido a que ahora hay más individuos y organizaciones capaces de colaborar. Esto significa que al crear un protocolo de red con enfoque en interoperabilidad, es posible generar tecnologías de publicación colaborativa compatibles.

Marco Teórico Capítulo 2

Los usuarios de aplicaciones existentes invierten mucho tiempo adquiriendo experiencia en las aplicaciones que usan frecuentemente. El costo para que los usuarios cambien a otra herramienta es alto. Sin embargo, los usuarios deben cambiar de herramientas para obtener las ventajas de sistemas de publicación colaborativa, por lo que es necesario agregar la capacidad de publicación colaborativa a las herramientas existentes.

La conjetura, entonces, sería que la mejor fcrma de generar efectos de red (interoperabilidad) y agregar capacidad de publicación colaborativa a herramientas existentes es enfocar sobre el protocolo de red el mecanismo por el cual las herramientas colaborativas se comunican, tal como se observa en la figura 2.3.

FiguraZ.3: Colaboradores con el mismo protocolo Los colaboradores en lo creocrdn de un documento usan dferentes herramientas, pero camporfen el mismo prolocolo. para soporlor coloborocidn dislrduido

2.3.5.1 Protocolo WebDAV

Cuando se está colaborando en un proyecto de ingeniería con uno o más grupos geográficamente dispersos, la forma que se tiene para ayudar a administrar el proyecto es usando correo electrónico, pero desde luego con las posibles consecuencias de las revisiones y los mensajes a los colaboradores vistas anteriormente en la sección 2.3.3. Si en lugar de hacerlo de esa forma, simplemente se editan los documentos Web (o cualquier recurso Web) en el lugar del URL teniendo un mecanismo de bloqueo de documentos, que evita sean sobrescritos, y además también se pueden limitar los derechos de acceso y asociar los documentos con propiedades (metadatos) relevantes tales como el autor y la fecha de la última modificación, se advierte un contexto completamente nuevo.

Marco Teórico Capiiula 2

La implementación de un escenario así podría cambiar la forma en que se piensa actualmente sobre la Web como medio colaborativo. Justo como los documentos estáticos evolucionaron a los documentos activos, la autona Web podría evolucionar del servidor de Web local a toda la Web como una nueva generación de herramientas que soportan autoría colaborativa fluida.

Detrás de un escenario así está la visión que tiene el grupo de trabajo WebDAV del IETF. WebDAV extiende el protocolo HTTP para proveer una infraestructura estándar para autoría colaborativa en el Internet [24].

2.3.5.1.1 Características del protocolo WebDAV

El grupo de trabajo Web Distributed Authoring and Versioning (WebDAV) del Internet Engineering Task Force (IETF) ha adoptado un enfoque centrado en el protocolo, y ha desarrollado un protocolo de red llamado WEBDAV DlSTRlBUTED AUTHORI’IC PROTOCOL (llamado después el protocolo WEBDAV), el cual soporta interoperabilidad remota, asíncrona, y publicación colaborativa. El WEBDAV es un grupo de extensiones del HTTP que proporciona servicios para control de concurrencia, operaciones del espacio de nombres, y administración de propiedades. El protocolo permite a los usuarios ser autores colaborativos directamente en un servidor de HTTP, haciendo que la Web sea vista no sólo en forma de sólo-lectura, sino también como un medio colaborativo de escritura.

Las principales contribuciones del protocolo WEBDAV son las siguientes:

Enfoque en el protocolo. El enfoque es en el protocolo de red, es decir, las abstracciones y semántica que informan la sintaxis de los octetos transmitidos durante una conexión TCP/IP. Esto contrasta con el trabajo existente sobre publicación colaborativa remota que se enfoca en la interfaz de usuario, y otros asuntos.

Ruta de migración para actualizar aplicaciones no colaborativas existentes. Hay muchas aplicaciones que no tienen soporte para publicación colaborativa remota. El protocolo WebDAV provee a estas aplicaciones una forma para agregar soporte de publicación remota sin modificar drásticamente el proceso de entrada de la aplicación.

Protocolo no orientado a conexión para control de concurrencia. Es decir que provee bloqueos de escritura de larga duración, exclusivos y compartidos, una técnica muy conocida para control de concurrencia. La duración de los bloqueos de WebDAV es independiente de cualquier conexión individual a la red con el fin de alcanzar una robusta colaboración en el Internet, donde las conexiones a la red pueden ser desconectadas arbitrariamente, y para alcanzar la escalabilidad, ya que cada conexión abierta consume recursos del servidor.

17

Marco Teórico Capitulo 2

. Soporte para manipulación remota del espacio de nombres de doc~mento?. Esto significa que el protocolo provee operaciones para copiar, mover Y listar 10s miembros de una colección de Web, similar a un listado de directorio en un sistema de archivos. Aunque estas operaciones han aparecido antes en numerosos sistemas, su aparición en sistemas de publicación colaborativa remota es inusual, reflejando la conciencia de que estos sistemas necesitan proveer mecanismos para navegación a los documentos que serán publicados, y para mantener agrupaciones lógicas de documentos en colecciones.

Satisfacción simultánea de requerimientos. El protocolo WebDAV satisface simultáneamente una amplia variedad de requerimientos difíciles; es decir, que se dirige a varios asuntos que son críticos para adoptar una tecnología de publicación colaborativa remota, y de los cuales no se ha hablado nada de ellos en la literatura de publicación colaborativa e incluso ni se mencionan. Estos asuntos incluyen seguridad en la conexión, autentificación robusta, intemacionalización; e independencia del entorno de publicación. El protocolo WebDAV adopta e integra tecnologías existentes como Transport Layer Security (TLS), Digest Authentication, y XML, para satisfacer dichos requerimientos de manera única.

Extensibilidad. El protocolo reconoce que no seria capaz de dirigirse a todas las características que un sistema de publicación colaborativa necesita. Por esto, la extensibilidad se convierte en una caracteristica crítica, El protocolo ha sido diseñado con caracteristicas de espacio de nombres muy definidas que permiten que nuevas características sean añadidas posteriormente. Los sistemas serán capaces de reconocer nuevos comandos y tener suficiente información para determinar si ignoran el comando desconocido o fallan.

2.3.5.1.2 Métodos de WebDAV para colaboración

Como ya se ha visto, el Protocolo WebDAV añade nuevos métodos al protocolo HTTP para soportar la autoría colaborativa y todas sus características. Estos nuevos métodos pueden observarse más claramente en la tabla 2.1.

Además de añadir métodos nuevos también actualiza la semántica de algunos métodos de HTTPII.1 ya existentes, la actualización principal en estos métodos consiste en

Marco Teórico Capitulo 2

I tomar en cuenta nuevos encabezados o condiciones que dan otro significado e influyen en el resultado de los métodos, estos métodos pueden verse en la tabla 2.2.

DELETE

actualizados semánticamente

Además, se muestran en la tabla 2.3 los nuevos encabezados añadidos al protocolo HTTP.

DAV: If:

Depth: Overwrite:

Destination: Lock-Token:

Timeout: Status-UN

I abla 2.3: Nuevos encabezados de H 1 TP

La descripción de los nuevos métodos de HTTP es la siguiente:

PROPPATCH: Este método procesa las instrucciones especificadas en el cuerpo de la solicitud para establecer y/o remover propiedades definidas sobre el recurso identificado por la Petición-UN.

PROPFIND: El método devuelve las propiedades definidas sobre el recurso identificado por la Petición-UN, devuelve si el recurso no tiene ningunos miembros internos, o las propiedades sobre el recurso identificado por la Petición-UN y potencialmente sus recursos miembros, o si el recurso es una colección que tiene miembros Uiüs internos.

COPY: El método crea un duplicado del recurso origen, identificado por la Petición-UN, en el recurso destino, identificado por el U iü en el encabezado “Destination”.

MOVE: La operación sobre un recurso que no es colección, es el equivalente lógico de una copia (COPY), seguida por un proceso para mantener la consistencia, seguido por el borrado del origen, y donde estas tres operaciones son realizadas atómicamente. El proceso de mantener la consistencia permite al servidor realizar actualizaciones causadas por el traslado.

Marco Teórico Capífulo 2

0

o

MKCOL: Este método se usa para crear una nueva colección

LOCK: El método es usado para realizar un bloqueo en algún tipo de acceso sobre e l recurso identificado en la Petición-URI.

UNLOCK: Remueve el bloqueo identificado por el simbolo del bloqueo en el encabezado “Lock-Token’’ de la solicitud en la Petición-URI, y de todos los otros recursos incluidos en el bloqueo.

o

2.3.5.2 Implementaciones WebDAV

En la práctica, e l trabajo que se ha desarrollado alrededor de un protocolo de publicación colaborativa incluye: código libre (open source) disponible en la red que compone servidores y clientes DAV, y algunos productos comerciales. Los proyectos realizados, divididos en categorías, están listados a continuación.

2.3.5.2.1 Código libre (clientes y servidores open source)

cadaver. Es un cliente DAV en línea de comandos. Soporta envio (upload), descarga (download), despliegue en pantalla, operaciones de espacio de nombres (mover í copiar), creación y destrucción de colecciones, y operaciones de bloqueo.

Figura 2.4: Cliente DAV cadaver

mod dav. Es un módulo para Apache que provee soporte DAV para el servidor de WebApache. Actualmente implementa un servidor que provee todas las facilidades básicas de WebDAV para manipulación de recursos en el mismo servidor de Web, y las propiedades mismas de éstos. Además maneja el establecimiento y eliminación de bloqueos sobre recursos, así que los clientes pueden tener acceso exclusivo para modificar dichos recursos.

’

r -.Apache

cI E Software Foundation h l < D ,,*r* o p a c n c o r g ,

Figura 2.5: Fundación Apache

o sitecopy. sitecopy puede ser usado para mantener copias remotas de sitios Web almacenados localmente. Puede enviar (upload), borrar, y mover archivos en el servidor para mantener el sitio remoto sincronizado con el sitio local. Los cambios en e l servidor no son reflejados en el directorio local; la sincronización es reflejada

Marco Teórico ’ Capifulo 2

en un solo sentido. sitecopy se comunica con los servidores usando FTP y WebDAV.

WebRFM (Web-based Remote File Manager). Este administrador de archivos remotos basado en Web es un programa CGI-Per1 enfocado a proveer una solución simple para la administración remota de archivos basada en Web. Es apropiado para administrar sitios Web, así como para tareas de administración de archivos de propósito más general.

Magi. Es u n servidor personal de Web que permite a los usuarios almacenar y recuperar información fácilmente. Un servidor Magi restringe quien tiene acceso a descargar y ver archivos usando una lista de “amigos”. Los usuarios pueden compartir y sincronizar información en su propia PC, laptop o palmtop usando un

0

0

servidor Magi desde donde sea como si estuvieran en un directorio loca¡ [13].

Figura 2.6: Servidor DAV Magi Server

2.3.5.2.2 Servidores de WebDAV públicos en Internet

libremente a los usuarios en Internet. La siguiente lista es de algunos servidores de WebDAV que están disponibles

0 GROUP.lounge o

o MovDAV para Apache , para detalles 0 Microsoft IIS 5: para una cuenta o Xythos server. 7

PyDAV: Servidor WebDAV Python 7

CENTRO DE INFORMAClON DGITl SEP CENIDET - 1

I

Marco Teórico Capitulo 2

2.3.5.2.3 Productos comerciales

Los siguientes productos son de tipo comercial y para usarlos se tiene que pagar la licencia correspondiente.

o Adobe GoLive. Una herramienta profesional de creación, producción y administración de sitios Web.

o Excosoft. Hay dos productos comerciales que soportan DAV. XML-Editor Documentor y un Servidor de Web

o Intraspect Knowledge Server versión 3 soporta Microsoft WebFolders implementado vía WebDAV.

0 Microsoft Internet Explorer 5 (Carpetas Web)

~~

Figura 2.7: Cliente Internet Explorer 5 de Microsoft

o DMCWebDev o Microsoft Office 2000 (Carpetas Web)

Figura2.8 LogoCliente Office 20013 de Microsoft

2.3.5.2.4 Productos comerciales de uso temporal libre

La siguiente lista se compone de productos comerciales que otorgan licencia libre para usar el producto por tiempo limitado, al término del cual se tendrá que pagar la cuota correspondiente por la licencia.

0 Dav4J. Liberado por IBM Alphaworks, es una implementación en Java de un cliente WebDAV que trabaja con Apache y mod dav, o con IBM WebSphere AppServer. Licencia libre por 90 días para evaluar,

Todos los productos anteriores implementan la mayoría de las especificaciones del grupo de trabajo de WebDAV sobre edición y publicación colaborativa, unas más que otras, pero ninguna trata el hecho específico para soportar el trabajo en modo de desconexión por lo cual el planteamiento de este trabajo es enfocarse directamente en dicha situación, desde luego sin olvidar las características que especifica el grupo de trabajo del IETF sobre WebDAV. Debido a que la especificación de WebDAV es el trabajo que más se aproxima a la solución del problema presentado, surge el interés de que se tome como base para la realización de este trabajo de tesis.

-

33

Capitulo 2 Marco Teórico

_. 2.4 Operación en modo de desconexión

La operación en modo de desconexión [15, 161 es un modo de operación en el que el cliente usa datos del cache para operar durante las fallas del servidor o de la red. También podria verse como un caso extremo de operación en modo conectado débilmente usando una red con cero ancho de banda, latencia infinita y sin costo de comunicación.

La habilidad para operar en modo de desconexión es Útil aun contando con la conexión. Por ejemplo se puede reducir el gasto de la red, una característica muy importante cuando los cargos son muy elevados, en entornos de computación móvil se puede extender la vida de la batería evitando transmisión y recepción inalámbrica. Sin embargo, la operación en modo de desconexión implica que un cliente desconectado sufra de muchas limitaciones [lS, 161 como las siguientes:

Las actualizaciones no son visibles a otros clientes. Las fallas del cache no son transparentes, porque un usuario puede ser capaz de trabajar a pesar de fallas del cache, pero ciertas pérdidas críticas pueden impedir el progreso. Las actualizaciones hechas mientras se esté desconectado están en peligro si el cliente es dañado, perdido, o robado. El peligro de conflictos de actualización (tanto de escritura-escritura como de lectura-escritura) se incrementa con desconexiones prolongadas. El agotamiento del recurso, especialmente el espacio de cache, es una preocupación durante largas desconexiones.

Hasta este momento se ha visto que la alternativa del protocolo WebDAV para trabajo colaborativo facilitaría mucho un ambiente de trabajo de esta naturaleza, pero este protocolo aún no contempla la solución al problema de la falta de comunicación entre el sitio donde trabaja una persona que requiere un documento y el sitio donde éste se encuentra para continuar el trabajo de forma normal; es decir, cuando se presenta la desconexión. Las complicaciones que acarrea esta situación podrían causar problemas no tan graves como una simple pérdida de tiempo al tener que esperar hasta que se restablezca la conexión para poder acceder nuevamente a él, o problemas más trascendentales como un caso un tanto extremo, pero posible, que detenga totalmente el proyecto, debido a que un miembro clave del grupo queda incomunicado y ya no puede seguir colaborando.

Los problemas de comunicación también afectan a aquellas redes privadas [21], como la que se usa para el desarrollo de este proyecto, debido a que tienen la dificultad de que los usuarios de la red privada no pueden comunicarse con los servidores de WebDAV directamente, y con las condiciones actuales del protocolo, una falla en la conexión implicaría la terminación del servicio para los clientes de la red privada por parte de los servidores de WebDAV externos.

Otro aspecto importante del trabajo colaborativo es que posiblemente el trabajo de un colaborador no se limita a un solo servidor, o sea el sitio donde se encuentra la información, sino a varios, En este caso existe la posibilidad de que la desconexión no sea

Marco Teórico Capitulo 2

total de todos los servidores con los que se esté trabajando, sino sólo parcial, y que únicamente un servidor sea el que no esté proporcionando servicio por un determinado tiempo. Esta situación no debería limitar el trabajo del colaborador, ya que debería dársele la posibilidad de que la recuperación de la desconexión - reconexión sea de la manera más transparente posible.

Independientemente de las consecuencias que podría originar el no poseer un documento en el momento que se necesita, al no poder accederlo. no es deseable tener que esperar por él hasta que se restablezca la conexión. Lo que se desearía es que se tenga acceso a la información necesaria en el momento que se requiera y no se sufran interrupciones en las actividades que se estén desarrollando como consecuencia de una falla de cualquier índole en las comunicaciones.

2.5 El problema de la actualización perdida

El problema de la actualización perdida ha estado presente en la mayoría de los ambientes de autoría distribuida usando características rudimentarias de HTTP/l .O. El problema de la actualización perdida puede ilustrarse con el siguiente ejemplo y verse en la figura 2.9:

1. Jose accede al documento X usando el método GET del protocolo HTTP, y comienza a editarlo.

2. María también accede al documento X usando el método GET del protocolo HTTP, y comienza a editarlo.

3. José guarda el documento X con las modificaciones que hizo.

4. María guarda el documento X pero ella no vio lo editado por José, los cambios editados por José se pierden.

I I

Figura 2.9: El problema de la actualización perdida

24

Capítulo 2 Marco Teórico

Existen diferentes formas de resolver el problema de la actualización perdida, cada una con un nivel variante de complejidad. Algunas soluciones comúnmente usadas son mutuamente exclusivas (aunque no necesariamente). Entre estas se incluyen las siguientes:

Comunicaciones fuera de banda y acuerdos sociales. Esta solución no involucra ningún mecanismo explícito del protocolo para manejar edición en un ambiente multiusuario, pero confía en las políticas y acuerdos sociales de las personas. Esto obviamente no es una muy buena medida y frecuentemente resulta en malentendidos sobre cómo manejar los conflictos cuando ocurren. Este es realmente el único modo soportado en el protocolo HTTPil .O.

0 Detección automática y solución manual de conflictos generados por la modificación sin reservación previa. El efecto de esta solución podría ser que cuando María trate de guardar sus modificaciones en el paso 4, causando potencialmente anular lo editado por José, el servidor no permitiría el éxito de la operación y en su lugar emitirá un mensaje de error. Típicamente, entonces María manejaría la fusión manualmente y reharía la operación para guardarlo cuando haya finalizado la fusión. Este es el comportamiento característico de CVS (Version Control System ) [4], por ejemplo, donde la fusión es realizada semi-automáticamente dejando que los conflictos sean resueltos por el usuario.

Advertencia prematura de futuros conflictos potenciales. La advertencia prematura puede ser implementada con “banderas de protección” como en el caso de la última versión de CVS o como bloqueos compartidos en WebDAV. Aunque las banderas de protección o los bloqueos compartidos aseguran que la actualización no suceda sin aviso, realmente no previenen el problema de actualización perdida por sí mismas como poseedoras de un bloqueo compartido, o bandera de protección, aun pudiendo hacer un alto en cada una de las otras ediciones. Sin embargo, las banderas de protección frecuentemente son usadas en conexión con la técnica del párrafo anterior.

Revisión de bloqueos reservados. El principio detrás del bloqueo exclusivo de recursos, o revisión de bloqueos reservados, es permitir que sólo una persona edite el recurso a la vez. Si José usó un bloqueo exclusivo, por ejemplo, entonces María puede ser capaz de obtener el documento para lectura, pero si ella decide comenzar a editarlo, obtendría un error al tratar de bloquear el documento, debido a que José ya lo mantiene bloqueado. Para que Mana pueda editar el documento, José primero tendría que liberar el bloqueo.

La gente acostumbrada a usar bloqueos compartidos frecuentemente encuentra que los bloqueos exclusivos son muy pesados y restrictivos. La gente que usa bloqueos exclusivos no puede coexistir con la posibilidad de repartir la incertidumbre generada con el uso de los bloqueos compartidos. En la práctica, el mecanismo más apropiado depende del contenido que se está editando y de las circunstancias bajo las cuales está siendo editado [6].

25

Capítulo 2 Marco Teórico

2.6 Control de concurrencia y bloqueos

Debido a que la Web es inherentemente multiusuario, un protocolo de autona en la Web debe mediar el acceso concurrente por múltiples autores.

Las primeras herramientas de autoría de Web se encontraron con el problema de la actualización perdida, que ocurre cuando dos o más autores simultáneos de una página Web la guardan repetidamente en el mismo UFU, sin primero unirle los cambios realizados por los demás autores. Aunque HTTP 1.1 agrega soporte para detectar actualizaciones perdidas a través del uso de identificadores únicos asociados con el estado del documento, en un principio no hubo soporte previsto para prevenirlas.

2.6.1 Propiedades de los bloqueos

En un principio, WebDAV decidió usar bloqueos de larga duración del recurso completo como su mecanismo de control de concurrencia. Esto permitió enfocar los requerimientos de WebDAV en las propiedades deseadas de los bloqueos [25]:

Independencia del bloqueo: la operación de bloqueo debe ser independiente de otras operaciones. Por ejemplo, podría no ser necesario obtener el recurso para bloquearlo. La motivación principal para este requerimiento es mantener una separación de propósitos entre bloqueos y otras operaciones de HTTP.

Bloqueos multi-recurso: el protocolo debe soportar una operación atómica para bloquear múltiples recursos en el mismo servidor. Algunos documentos frecuentemente consisten de varios archivos separados. Por ejemplo, las páginas Web se componen de texto, imágenes, y contenidos ejecutables almacenados como recursos de Web separados. De ahí que una herramienta de autoria necesite la habilidad para prevenir actualizaciones perdidas sobre todos los componentes de esos documentos multiparte, para que el documento pueda ser almacenado como una unidad. Un bloqueo multi-recurso puede garantizar esto. La restricción de atomicidad asegura que si dos personas están tratando de bloquear el mismo grupo de recursos, sólo a uno se le garantizará el bloqueo.

Bloqueos de escritura: El protocolo sólo es requerido para soportar bloqueos de escritura, y los de lectura no son necesarios. En la Web un recurso está de por sí proporcionado para lectura, aunque podría estar protegido con un control de acceso. De ahí que, HTTP no requiera que un navegador de Web obtenga un bloqueo para leer un recurso, como ocurre con las bases de datos tradicionales.

Descubrimiento del bloqueo: debe ser posible descubrir si un recurso está bloqueado. Esto permite que una interfaz de usuario sea construida para indicar si un recurso está bloqueado.

Capi1uIo 2 Marca Teórico

ESTADO ACTUAL DEL BLOQUEO COMPARTIDO Sin bloqueo Garantizado Bloqueo compartido Garantizado Bloqueo exclusivo No Garantizado

SOLICITUD DE BLOQUEO

2.6.2 Bloqueos exclusivos y compartidos

El control de concurrencia con el protocolo WebDAV es proporcionado por los bloqueos de escritura. El método LOCK soporta dos tipos de bloqueos: "bloqueos exclusivos de escritura" y "bloqueos compartidos de escritura". Debido a que cualquier tipo de protagonista (humano o robot Web) podría escribir un recurso deWeb, un bloqueo de escritura previene que cualquier protagonista diferente al propietario del bloqueo escriba en un recurso bloqueado. Un bloqueo de escritura exclusivo previene que todos los otros protagonistas escriban el recurso, mientras que un bloqueo de escritura compartido puede ser simultáneamente poseído por varios usuarios. Esta terminología difiere del típico uso de las bases de datos, donde un bloqueo compartido propiamente es obtenido antes de leer un elemento de la base de datos.

SOLICITUD DE BLOQUEO EXCLUSIVO Garantizado No Garantizado No Garantizado

La tabla de compatibilidad de bloqueos para bloqueos de escritura se muestra a continuación en la tabla 2.4.

I ab a 2.4: 'labla de compatibilidad de bloqueos

27

Capítulo 3 Análisis y Solución Conceptual del Problema

Contenido del capítulo: 3.1 Planteamiento general del problema 3.1.1 Descripción del problema 3.2 Diseño de la solución 3.2.1 3.2.1.1 3.2.1.1.1 Mismo soporte para todos los tipos de contenido 3.2.1.1.2 Soporte para control de concurrencia y mecanismo de bloqueos no orientados a

con ex i ó n 3.2.1.1.3 Soporte para propiedades (metadatos) 3.2. I . 1.4 Soporte para manipulación del espacio de nombres 3.2.1.1.5 Soporte para colecciones 3.2.2 Arquitectura cliente - servidor 3.2.2.1 Arquitectura cliente - servidor y la Web 3.2.2.2 La Web: una arquitectura distribuida 3.2.2.2.1 3.2.2.3 Funcionamiento del protocolo HTTP 3.2.3 3.2.3.1 3.2.4 3.2.4.1 Funciones del servidor intermediario 3.2.4.1.1 El procedimiento de colaboración 3.2.4.1.2 3.2.4.1.3 3.2.4.2 Beneficios en los servicios de colaboración mediante la arquitectura

Protocolo de publicación colaborativa remota Requerimientos en soporte para colaboración

Proceso cliente - servidor dentro de la Web

Arquitectura multicapa: cliente - intermediario - servidor

Arquitectura para colaboración con soporte para desconexión Uso de la arquitectura con intermediario para soportar desconexión

Posibles causas de inconsistencia de información Protocolo de resolución de conflictos por inconsistencia en la información

, ,'

Análisis y Solución Conceptual del Problema

Este capitulo contiene la descripción de la problemática y la solución aquí propuesta. Comenzará presentando el planteamiento general del problema, la colaboración y desconexión en la Web ya mencionadas en el capítulo anterior. Con estas referencias se hará una descripción más detallada y concisa del problema para pasar posteriormente al diseño de la solución y la descripción de sus componentes.

Capítulo 3 Análisis y Solución Conceptual del Problema

3.1 Planteamiento general del problema

Mucho del trabajo de oficina que la gente hace hoy en día es colaborativo. Grandes, medianas y algunas pequeñas empresas están en proceso de expansión y/o crecimiento, y muchas de ellas establecen nuevas filiales que requieren tener un contacto continuo con cada una de las nuevas representaciones de la empresa. Esto conlleva a que la gente trabaje conjuntamente, formando equipos de colaboración, sobre presentaciones, memos, reportes de producción, reportes de inventario, reportes de ventas, planes de mercadotecnia o sobre muchos documentos más. La tecnología existente no soporta que la colaboración sea muy buena y mucho menos cuando se presentan problemas en el enlace de comunicación.

AI evolucionar hasta un ambiente en el que la tecnología de colaboración está soportada por cientos, miles o quizá millones de computadoras y grandes redes de comunicación para compartir información entre diferentes sitios, muy posible geográficamente distantes, el quedar incomunicado de este mundo podría causar desde un simple retraso por la pérdida de tiempo ocasionada al no tener acceso a la información debido a fallas en la comunicación, hasta consecuencias mucho más serias, como el mantener detenido un proyecto, cuyo reflejo podría significar pérdidas económicas muy considerables.

El grupo de trabajo WebDAV está fomentando el desarrollo de tecnologías que permitan a los usuarios una colaboración más real; esto buscando hacer que el trabajo de los usuarios en la Web sea fácil de acceder, y debido' a que múltiples usuarios tendrían acceso a los mismos documentos, serán capaces de trabajar juntos.

Un equipo de colaboración formado entre varios participantes geográficamente dispersos, y cuya colaboración se lleva a cabo a través de la Web, se puede observar en la figura 3. I .

! colaboradores INTERNET colaboradores

Servidor de Web

Figura 3. I : Equipo de colaboración mediante la Web

Si uno de los participantes pierde el enlace de comunicación, como se ve en la figura 3.2, queda fuera de toda actividad realizada por los otros miembros del grupo, y más aun ya que la información de trabajo del grupo se deposita en un servidor de Web, queda

30

Capitulo 3 Análisis y Solución Conceptual del Problema

imposibilitado a continuar con su parte de trabajo, deteniendo posiblemente las actividades del equipo.

. ,,” ’ /

\ I

-. . - . .- _..-.-._ I _ _ _ -._ ’.

NTERNET ! colaboradores /: trabajodegrupo , \ por lapérdidade : ,; comunicación I ,\ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

i

I

Servidor de Web Figura 3.2: Pérdida del enlace de comunicación de un miembro

del equipo de colaboración

Basados en las propuestas del grupo de trabajo WebDAV, en este proyecto se busca ofrecer, técnicamente hablando, que se habilite a las aplicaciones para que almacenen directamente el URL (Universal Resource Locator), evitando transferencia de archivos vía FTP y también evitando los detalles de cómo el sistema de archivos y directorios mapea a los URLs. Además, con estas propuestas también se habilitará a las aplicaciones para que ayuden a la gente a que sea capaz de colaborar en cosas como anuncios, boletines, presupuestos, entre otras más. sobre la Web, aun sin contar con la conexión permanente a Internet para lograrlo. En esencia, se buscará, por un lado, que la Web sea vista como un sistema de archivos accesibles por red a gran escala, y por otro lado que se permita a personas que carecen de buenas condiciones de conexión a Internet participar con este tipo de tecnología.

3.1.1 Descripción del problema

La necesidad de colaborar entre varias personas para un fin común es cada dia más frecuente, sin embargo. también es cierto que la infraestructura actual de comunicación para un soporte de este tipo no es totalmente confiable en varios paises, principalmente por su gran susceptibilidad a fallas de diferente índole. Uno de los principales tipos de fallas tiene que ver con el enlace de comunicación, por lo que se tienen que buscar alternativas para ayudar a minimizar, en la medida de lo posible, las consecuencias producidas por dichas fallas.

Las fallas derivadas de los problemas de la desconexión ocasionan que las modificaciones y actualizaciones a un documento compartido por un grupo de colaboración no sean visibles a los otros colaboradores, y aunque es probable que un colaborador pueda seguir trabajando a pesar de dichas fallas, hay algunas fallas críticas (como la pérdida de cache) que lo impedirán. Por otro lado, las actualizaciones realizadas durante la

Capítulo 3 ~nál i s i s y Solución Conceptual del Problema

desconexión que necesiten ser reflejadas a los demás colaboradores estarán en peligro si el cliente se daña, o se pierde. La posibilidad de conflictos de actualización es otro peligro más, derivado de una desconexión; el peligro se incrementa si la duración de la desconexión también se incrementa.

El problema se acentúa aun más si se considera que las personas participantes en un grupo de colaboración pueden tener diferentes herramientas para realizar sus actividades correspondientes. Esta variedad entre herramientas puede resultar en diferentes formatos de documentos sobre el mismo tipo de información, ya sea texto, imagen, audio, o video, causando incompatibilidad entre la información manejada por las herramientas. Por ejemplo, suponiendo que una herramienta X habilitada propietanamente para trabajo colaborativo se ocupa para obtener y editar una imagen llamada dibujo.x, otra herramienta para edición de imágenes, habilitada para trabajo colaborativo en forma propietaria diferente a la anterior, no podrá abrir el formato propietario de la herramienta X.

La utilización de una sola herramienta por parte de los colaboradores obliga a que todos ellos la posean y la dominen. Si un nuevo colaborador se integra al grupo también tendrá que manejar la herramienta y aprenderla en caso de no saberla utilizar. Por otro lado, si en lugar de usar un solo tipo de herramienta se agrega a las existentes un mecanismo que permita comunicar a las diferentes herramientas unas con otras (protocolo), se obtienen mayores beneficios en soporte de colaboración, pero entonces, habrá que dar soporte a aspectos clave derivados de este enfoque. Sin embargo, como se mencionó anteriormente, redunda en mejores y mayores beneficios por lo que esta perspectiva es tomada como base para diseñar la solución expresada en las siguientes secciones. Un ejemplo sobre este enfoque, retomando la edición de una imagen, es que cuando una herramienta Y, habilitada para trabajo colaborativo con el protocolo WebDAV, guarde la imagen como dibujojpg; cuando otra herramienta W o Z que conoce el formato jpg, también habilitada para trabajo colaborativo con el mismo protocolo WebDAV, si intenta editar en forma-colaborativa el recurso dibujojpg no tendrá ningún problema en lograrlo.

3.2 Diseño de la solución

Adoptar un enfoque centrado en el protocolo de red requiere considerar aspectos clave a los que se les dé soporte, tales aspectos son: interoperabilidad remota y asíncrona, y publicación colaborativa, además debe dar facilidades para el control de concurrencia, operaciones del espacio de nombres, y administración de propiedades, permitiendo a los usuarios ser autores colaborativos directamente en un servidor contenedor del documento, lo que logra que la Web sea vista no sólo en forma de sólo-lectura, sino también como un medio colaborativo de lectura-escritura. Además de estas características se debe considerar en dar un soporte confiable para ayudar a sobrellevar los problemas ocasionados por conexiones intermitentes a Internet, con momentos de desconexión de corta, media y larga duración, y proveer un soporte para el mecanismo de resolución de los posibles conflictos que podrían llegar a presentarse en los momentos de desconexión de larga duración.

32

Capitulo 3 Análisis y Solución Conceptual del Problema

Una solución basada en las caracteristicas de interoperabilidad remota, asincrona, publicación colaborativa y las demás mencionadas en el párrafo anterior, requiere la conjunción de varios elementos como el protocolo de publicación colaborativa remota y su contexto, así como la estructura de disposición y funcionamiento de los componentes que la formarán. A grandes rasgos los partícipes de este sistema son el “protocolo de publicación colaborativa remota”, y la “arquitectura básica” de dicho sistema. El análisis de estos elementos es llevado a cabo en las siguientes secciones.

3.2.1 Protocolo de publicación colaborativa remota

El enfoque referente a centrar la atención en el protocolo de red para un sistema de publicación colaborativa remota se debe a varias razones. Desde un punto de vista técnico, enfocarse sobre el protocolo de red eleva la conducta del protocolo a través de Internet a una preocupación de primer plano. Esto asegura que cuestiones fundamentales, como lo son asegurar la eficiencia bajo condiciones de alta latencia (fuerte demanda de recursos por la observación y entrega de eventos), proveer seguridad y autentificación adecuada, y dar al protocolo buena escalabilidad y características de extensibilidad, sean afrontadas de manera primordial. Si se dejaran en segundo plano, estos factores pueden llegar a estropear la amplia expansión de la adopción de una tecnología de publicación remota.

Conforme a este planteamiento, este trabajo se desarrolla bajo un contexto definido por las características y tareas que permitan el manejo colaborativo de documentos en la Web, impulsando la compatibilidad de herramientas de manejo de tales documentos y ofreciendo el soporte para seguir accediendo a la información en un estado de desconexión, es decir que no será necesario mantener una conexión cliente-servidor para poder editar los documentos. Lo más cercano a nuestros objetivos se ve en la definición del protocolo WebDAV [ l i ] , en lo que a protocolos se refiere, con la diferencia de que el trabajo realizado hasta este momento por el grupo de trabajo WebDAV no soporta un modo de desconexión que permita continuar manipulando recursos, siendo esta característica la principal aportación del desarrollo de este trabajo de tesis.

3.2.1.1 Requerimientos en soporte para colaboración

Un protocolo de publicación colaborativa remota sugiere soporte sobre varios aspectos claves en el funcionamiento. El soporte tiene quz ver principalmente con el tipo de contenido que existe en la Web, con el control de la concurrencia, con el manejo de propiedades y del espacio de nombres, así como con colecciones de recursos. A continuación se abordarán cada uno de estos puntos.

3.2.1.1.1 Mismo soporte para todos los tipos de contenido

La Web está compuesta de documentos de texto, imágenes, y objetos de diferentes tipos de contenido, como se ve en la figura 3.3. Por lo tanto, un protocolo de autoría de Web debe tratar a todos los tipos de contenido con igualdad.

33

Análisis y Solución Conceptual del Problema Capitulo 3

~

Figura 3.3: Manejo de diferentes tipos de contenido

Un protocolo de autoría de Web el cual sólo provee operaciones para recursos de un tipo de contenido específico, tal como HTML, o el cual requiere extensiones de autoria específica para soportar características .tales como el manejo de versiones, tendría aplicabilidad limitada debido a su carencia de soporte para la amplia variedad de otros tipos de contenido. Además, ya que muchos tipos de contenido común están en constante evolución, para asegurar la estabilidad del protocolo debe mantenerse una estricta separación entre el protocolo y el formato de los objetos que operan sobre él. Por ejemplo, durante el desarrollo del protocolo WebDAV, fueron emitidos nuevos estándares para HTML 3.2, 4.0 y XML, destacando cómo rápidamente estos formatos de documentos pueden desarrollarse y evolucionar. Un protocolo de autoria y confección demasiado cerrado a cualquier otro tipo de contenido podria hacerse rápidamente obsoleto.

3.2.1.1.2 Soporte para control de concurrencia y mecanismo de bloqueos no orientados a conexión

Debido a que la Web es inherentemente multiusuario, un protocolo de autoría en la Web debe mediar el acceso concurrente por múltiples autores y proveer un mecanismo de control de concurrencia, como se muestra en la figura 3.4, capaz de agregar soporte para detectar el problema de actualización perdida mencionado anteriormente en la sección 2.5. Por otra parte, debido a que los enlaces de comunicación no son confiables y podrían presentarse fallas en cualquier momento debe existir un mecanismo de bloqueos no orientado a conexión

Figura 3.4: Acceso concurrente con mecanismo de control de concurrencia

Capítulo 3 A ~ ~ I ; s ; s ~ Solución Conceptual del Problema

Cuando un bloqueo es garantizado, el servidor devuelve un símbolo del bloqueo, es decir un identificador único global al cliente. Así que tan pronto como él lo almacene, no necesita mantener la conexión. Cuando el cliente subsecuentemente necesite realizar operaciones de escritura en el recurso bloqueado, restablece la conexión de red, y manda el identificador del bloqueo junto con la solicitud de escritura.